Привет. Обсуждали с коллегой, какую позицию надо выбрать софтверной компании на самой заре существования: 1) закрыть всё от всех, самому делать ключевую работу и никому не давать осознать всю полнотц идеи. Сотрудникам отдавать только рутинную работу, самих сотрудников иметь минимальное число, одних и тех же, и средней развитости, чтобы они тебя же не обманули. Контролировать, чтобы сотрудники не обменивались исходниками. Скрывать от сотрудников бизнес-связи. Этой модели придерживаюсь я. 2) наоборот, как можно больше показывать сотрудникам, чтобы они понимали цель и способы оптимизации. Работников брать самых талантливых, выжимать из них все, и не держать, когда захотят уйти -- мол, нового найду, лучше тебя. Организовывать в команде самообучение, способствовать пониманию архитектуры ПО, поощрять командную работу. Открывать им бизнес-звязи и держать в курсе планов, чтобы они могли учитывать специфику заказчика. Это мысль партнера.
Понимаю, что оба способа-- не годятся. Но как найти компромис. У меня узкое место -- централизация. Но ведь на начальном этапе и глупо надеяться, что кто-то будет работать лучше меня. С другой стороны, он приводит веские доводы, что его старый конкурент-полиграфис вел себя с работниками открыто и преуспел. Но можно ли программирование сравнить с полиграфией? Как защититься от своих сотрудников? Они ведь могут просто создать такую же компанию либо уйти к конкуренту с твоими наработками.
> Привет. > Обсуждали с коллегой, какую позицию надо выбрать софтверной компании на > самой заре существования: > 1) закрыть всё от всех, самому делать ключевую работу и никому не давать > осознать всю полнотц идеи. Сотрудникам отдавать только рутинную работу, > самих сотрудников иметь минимальное число, одних и тех же, и средней > развитости, чтобы они тебя же не обманули. Контролировать, чтобы сотрудники > не обменивались исходниками. Скрывать от сотрудников бизнес-связи. > Этой модели придерживаюсь я. > 2) наоборот, как можно больше показывать сотрудникам, чтобы они понимали > цель и способы оптимизации. Работников брать самых талантливых, выжимать из > них все, и не держать, когда захотят уйти -- мол, нового найду, лучше тебя. > Организовывать в команде самообучение, способствовать пониманию архитектуры > ПО, поощрять командную работу. Открывать им бизнес-звязи и держать в курсе > планов, чтобы они могли учитывать специфику заказчика. Это мысль партнера.
> Понимаю, что оба способа-- не годятся. Но как найти компромис. > У меня узкое место -- централизация. Но ведь на начальном этапе и глупо > надеяться, что кто-то будет работать лучше меня. > С другой стороны, он приводит веские доводы, что его старый > конкурент-полиграфис вел себя с работниками открыто и преуспел. Но можно ли > программирование сравнить с полиграфией? Как защититься от своих > сотрудников? Они ведь могут просто создать такую же компанию либо уйти к > конкуренту с твоими наработками.
> Что сообщество скажет?
А чем, собственно, не нравится вторая модель? У нас в конторе используется именно она и проблем нет никаких.
G> Обсуждали с коллегой, какую позицию надо выбрать софтверной компании на G> самой заре существования: G> 1) закрыть всё от всех, самому делать ключевую работу и никому не давать G> осознать всю полнотц идеи. Сотрудникам отдавать только рутинную работу, G> самих сотрудников иметь минимальное число, одних и тех же, и средней G> развитости, чтобы они тебя же не обманули. G> Контролировать, чтобы сотрудники не обменивались исходниками. Скрывать G> от сотрудников бизнес-связи.
Я работал на такую компанию, правда давно уже. Мерзкое ощущение до сих пор, когда вспоминаю. Кончилось это моим уходом, с их долгом мне по зарплате. Через пол года эти параноики начали мне еще и угрожать, чтобы я вдруг не вздумал ломал их продукты в качестве отместки. Мысль мне понравилась, до этого в голову не приходила, поломал, все что смог. Краки раздавал на халяву.
G> Этой модели придерживаюсь я. G> 2) наоборот, как можно больше показывать сотрудникам, чтобы они понимали G> цель и способы оптимизации. Работников брать самых талантливых, выжимать G> из них все, и не держать, когда захотят уйти -- мол, нового найду, лучше G> тебя. Организовывать в команде самообучение, способствовать пониманию G> архитектуры ПО, поощрять командную работу. Открывать им бизнес-звязи и G> держать в курсе планов, чтобы они могли учитывать специфику заказчика. G> Это мысль партнера.
Отлично мыслит.
G> Понимаю, что оба способа-- не годятся.
На периоде становления нужна вторая модель, для того, чтобы сформировать костяк, а вот потом внутри рабочих груп, можно уже и частично придерживаться первой модели.
G> Но как найти компромис. У меня узкое место -- централизация. Но ведь на G> начальном этапе и глупо надеяться, что кто-то будет работать лучше меня.
Гы. Неправильная мысль.
G> Что сообщество скажет?
Попытаться избавиться от паранои.
With best regards, Mike Gorchak. E-mail: m...@malva.ua
Как минимум, выбирать процесс в котором тебе самому будет удобно.
Сложно сказать конкретнее – зависит и от психологии владельцев и членов команды и от разрабатываемых продуктов/проектов. Если проекты/продукт уникальный и требует творческого похода – возможно стоит привлекать как можно меньше сотрудников но дать им солидные опции/максимум свободы. Если «поток» - можно наверное набрать и «середнячков» и четко ставить задачи. Как компромисс – можно попробовать выделить «ядро» разработчиков и «остальных» команду. Только не забывайте: люди не машины, чтобы нормально шла работа должна быть нормальная обстановка и общение в команде.
_____
From: ua-devtalk@googlegroups.com [mailto:ua-devtalk@googlegroups.com] On Behalf Of Go3DoN
Sent: Monday, March 06, 2006 2:49 PM
To: ua-devtalk@googlegroups.com
Subject: Процесс становления: защита от своих сотрудников.
Привет.
Обсуждали с коллегой, какую позицию надо выбрать софтверной компании на самой заре существования:
1) закрыть всё от всех, самому делать ключевую работу и никому не давать осознать всю полнотц идеи. Сотрудникам отдавать только рутинную работу, самих сотрудников иметь минимальное число, одних и тех же, и средней развитости, чтобы они тебя же не обманули. Контролировать, чтобы сотрудники не обменивались исходниками. Скрывать от сотрудников бизнес-связи.
Этой модели придерживаюсь я.
2) наоборот, как можно больше показывать сотрудникам, чтобы они понимали цель и способы оптимизации. Работников брать самых талантливых, выжимать из них все, и не держать, когда захотят уйти -- мол, нового найду, лучше тебя. Организовывать в команде самообучение, способствовать пониманию архитектуры ПО, поощрять командную работу. Открывать им бизнес-звязи и держать в курсе планов, чтобы они могли учитывать специфику заказчика. Это мысль партнера.
Понимаю, что оба способа-- не годятся. Но как найти компромис.
У меня узкое место -- централизация. Но ведь на начальном этапе и глупо надеяться, что кто-то будет работать лучше меня.
С другой стороны, он приводит веские доводы, что его старый конкурент-полиграфис вел себя с работниками открыто и преуспел. Но можно ли программирование сравнить с полиграфией? Как защититься от своих сотрудников? Они ведь могут просто создать такую же компанию либо уйти к конкуренту с твоими наработками.
Что сообщество скажет?
</BODY
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 268.1.2/274 - Release Date: 03.03.2006
естественно, готового рецепта нет (скорее всего). Вот интересный феномен - это организации типа OASIS. Открытость во всём. Colaboration такого масштаба, что дух захыватывает. Может, вам с коллегой посмотреть на их опыт и ещё и его обсудить и проанализировать? У меня пока опыта (succes story) нет - присматриваюсь только... Промышленные гиганты теперь стремятся быть OASIS-compliant... Там же и рабочие группы по имплементации "идей". Тоже открытые.
> Привет. > Обсуждали с коллегой, какую позицию надо выбрать софтверной компании на > самой заре существования: > 1) закрыть всё от всех, самому делать ключевую работу и никому не давать
[...]
> Этой модели придерживаюсь я. > 2) наоборот, как можно больше показывать сотрудникам, чтобы они понимали > Это мысль партнера.
[...]
> Понимаю, что оба способа-- не годятся. Но как найти компромис. > У меня узкое место -- централизация. Но ведь на начальном этапе и глупо > надеяться, что кто-то будет работать лучше меня.
Может, узкое место - именно в этой идее - "глупо надеяться"?
С другой стороны, он приводит веские доводы, что его старый
> конкурент-полиграфис вел себя с работниками открыто и преуспел. Но можно ли > программирование сравнить с полиграфией? Как защититься от своих > сотрудников? Они ведь могут просто создать такую же компанию либо уйти к > конкуренту с твоими наработками.
> Что сообщество скажет?
-- with best regards, Wit Serdakovskij, Oracle DBA/Developer, Hostmaster ltd, .UA ccTLD
