Привет. Обсуждали с коллегой, какую позицию надо выбрать софтверной компании на самой заре существования: 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
Go3DoN wrote: > 1) закрыть всё от всех, самому делать ключевую работу
Так и не набирайте никого.
> и никому не давать осознать всю полнотц идеи. Сотрудникам отдавать > только рутинную работу,
Представьте себе стоимость ошибки. Счастливо ошибиться.
> самих сотрудников иметь минимальное число,
Единственное, с чем могу согласиться в этом пункте.
> одних и тех же, и средней развитости, чтобы они тебя же не обманули.
Смеётесь? Самые талантливые как раз талантом пробьют себе дорогу. А "средней развитости" как раз и будут пользоваться интригами и прочим гамном.
> Контролировать, чтобы сотрудники не обменивались исходниками.
(ищет челюсть на полу) Вы давно программы пишете?
> Скрывать от сотрудников бизнес-связи. > 2) наоборот, как можно больше показывать сотрудникам, чтобы они > понимали цель и способы оптимизации. Работников брать самых талантливых, Да. > выжимать из них все, и не держать, когда захотят уйти -- мол, нового > найду, лучше тебя.
Нет. Никак не связано с изначальной посылкой. Наоборот, держать. И не выжимать "всё", две недели переработок - и уже эффективность работника падает, появляются ошибки, которые будут стоить больше, чем выгода от переработок.
> Организовывать в команде самообучение, способствовать пониманию > архитектуры ПО, поощрять командную работу. Да. > Открывать им бизнес-звязи
Нет. Есть информация, которую можно доверять ТОЛЬКО руководителям. В т.ч. - контакты заказчика, не предназначенные специально для сотрудничества с разработчиками.
> и держать в курсе планов, Да. > Но ведь на начальном этапе и глупо надеяться, что кто-то будет > работать лучше меня.
А не жадничайте. Удивитесь, как много есть людей, которые умеют работать лучше вас.
Читайте Йордана, Брукса... И про паранойю правильно сказали.
>> Но ведь на начальном этапе и глупо надеяться, что кто-то будет работать лучше меня.
> А не жадничайте. Удивитесь, как много есть людей, которые умеют работать лучше вас.
Хороший руководитель набирает сотрудников которые хорошо разбираются в предмете; очень хороший - которые разбираются в предмете лучше него самого.
Hello, Go3DoN!
You wrote to <ua-devtalk@googlegroups.com> on Mon, 6 Mar 2006 14:49:17 +0200:
G> Привет.
G> Обсуждали с коллегой, какую позицию надо выбрать софтверной компании на
G> самой заре существования: G> 1) закрыть всё от всех, самому делать ключевую работу и никому не давать
[Sorry, skipped] G> Этой модели придерживаюсь я.
Как Вы думаете, если Вы мне так явно не доверяете с какого перепуга я должен доверять Вам?
G> 2) наоборот, как можно больше показывать сотрудникам, чтобы они G> понимали цель и способы оптимизации. Работников брать самых талантливых,
G> выжимать из них все, и не держать, когда захотят уйти -- мол, нового найду, лучше тебя.
Наплевательское отношение просматривается - с этим нужно завязывать. К людям нужно полюдски относиться. Зачем набирать талантов чтобы сказать "хочешь уходи, не больно ты и нужен, других наберем". Какой же это талант, если их как г-на?
G> Организовывать в команде самообучение, способствовать
G> пониманию архитектуры ПО, поощрять командную работу.
Это правильно :)
G> Открывать им бизнес-звязи
А это им зачем? Им нужно правильно создавать продукт и не отвекаться на всякую херню. Создайте им эти условия и будет вам счастие. Если им нужен доступ к заказчику дайте его им, но только в том объеме, чтобы продукт делали.
G> и держать в курсе планов, чтобы они могли учитывать G> специфику заказчика.
Держать в курсе это очень правильно. Но только для Вас, как руководителя, курс выражается в одном, а для программеров в другом. Держать их в курсе нужно, только в "их" курсе, а не в Вашем. И постарайтесь дать им четкую цель, осязаемую. А то если будете коней в вакууме, то все таланты разбегуться.
G> Как защититься от своих сотрудников?
А Вы что, врагов к себе нанимаете? Может лучше, того, вообще ничего не делать. Пока у Вас только один четко видимый враг - параноя :).
G> Они ведь могут просто создать такую же компанию либо уйти к конкуренту с G> твоими наработками.
Весь вопрос в том, какого размера проект. Если вы сами можете его сделать и считаете себя наиболее компетентным, оцените, насколько действительно нужны другие члены команды. Команда, середнячков, с одним лидером, контролирующего всех и не доверяющего никому очень неэффективна, лидер тратит слишком много времени и усилий на организацию и согласование. Скорее всего, он сам напишет быстрее весь продукт. Вопрос - для чего все остальные люди? В зависимости от ответа на него рассматриваются несколько вариантов: 1. Не нужны - проект небольшой и не предполагает большого развития в ближайшем будущем 2. Делать заранее определенную и строго фиксированную часть работы - для этого необязательно открывать фирму, можно просто каждому работать по домам децентрализовано. У хорошего программиста есть много знакомых, которых можно привлечь 3. Люди нужны для того, чтобы можно было в дальнейшем развивать проект, децентрализовать полномочия и ответственность. Только этот вариант реально оправдывает организацию собственной фирмы по разработке - когда человек осознает, что он один не сможет справиться со всей работой.
Если вы выбрали 3 вариант, то тогда вам нужно думать о развитии и удержании людей, создании командной атмосферы и доверия, не сильно формальных процессах управления. Важно осознание личной заинтересованности людей в этой фирме, т.к. если от них не будет ничего зависеть, они будут уходить в другие, где будет больше возможностей роста, развития и зарплаты.
По мере роста фирмы модель управления людьми и процессами будет изменяться.
Статьи Джоэля все читали наверное? Думаю, что там можно найти несколько хороших рекомендаций.
у Joel Spolsky можно много подчерпнуть моё лично мнение - у вас оба варианта утопичны и являются крайностями оба варианта лично для меня неправильны, и неприемлимы
по поводу варианта 1 -- если вы сами все делаете, зачем вам соотрудники? и определитесь -- вам шашечки или все таки ехать? если хорошие руководители, а если хорошие специалисты так вот это разные люди, а не все намешанное в одном как у вас
бизнес вы приплели вообще не в тему - процесс правильной разработки с бизнесом пересекаться должен в одной-двух точках - и это руководитель проекта - ведущий разработчик - бизнес аналист все
все сводится к правильной организации процесса иначе можно кучу вариантов напридумать - толку все равно не будет
Многое написали но попробую дополнить, Вопрос - как найти компромисс?
У вас старт компании, значит нужны люди которые умеют что-то делать и не требуют контроля. Они должны уметь всё сразу чтоб хорошо заботиться о проекте и помочь ему в критическую минуту - в общем профи своего дела.
Но как завлечь таких профи? Самый простой путь, предложить им разрабатывать интересный продукт, я думаю что многим из них надоела своя рутинная работа.
Хорошо, но ведь профи ... раз да два и украл заказчика. Нехорошо, но с профи надо быть самому профи, если человек видит что его босс не знает как составить договор, то он скорее подумает что проще сделать это самому... и тогда зачем босс? Вы должны быть профи, или у вас должен быть профи в плане управления бизнесом.
Не думаю что много профи очень хотят составлять договора, или маяться с бухгалтерией или знакомиться с податковой. Их интересует интересная и оплачиваемая работа, и вы должны им это предложить. По этому же случаю не надо их нагружать бизнес связями и всеми вашими проблемами, дайте им работать в своей стихие. И не надо за ними всё время следить и поправлять, см. в книге Дж.Хайк Рейнвотер "Как пасти котов" есть глава о мелочной опеке. Конечно не дай бог вам ошибиться, и нанять дилетантов с хорошо подвешенными языками.
Это только один совет из миллионов которые мы можете получить. Надо больше .... был совет насчёт книжек Йордана, Брукса, (добавил бы ДеМарко). Также вам читать книжки по менеджменту, и так просто для интереса прочитаете хотя бы с 10-ок книжек по типу "Как компания Х добилась успеха", сейчас такие книги популярны.
Нет времени читать книги? Тогда пробуйте раз, два ... десять - вы получите огромный опыт, и может даже напишите книжку о том как надо делать, а как не надо :)
Olexiy Prokhorenko wrote: > у Joel Spolsky можно много подчерпнуть > моё лично мнение - у вас оба варианта > утопичны и являются крайностями > оба варианта лично для меня > неправильны, и неприемлимы
> по поводу варианта 1 -- если вы сами все > делаете, зачем вам соотрудники? > и определитесь -- вам шашечки или все > таки ехать? > если хорошие руководители, а если > хорошие специалисты > так вот это разные люди, а не все > намешанное в одном как у вас
Абсолютно согласен. Каждый должен заниматься своим делом. И надо стараться не лезть в чужой огород.
> бизнес вы приплели вообще не в тему - > процесс правильной разработки с > бизнесом пересекаться должен в > одной-двух точках - и это руководитель > проекта - ведущий разработчик - бизнес > аналист > все
А также в затратах на зарплату и обустройство офиса :) Особенно зарплата, всё таки это самая большая статья расходов IT компании.
> все сводится к правильной организации > процесса > иначе можно кучу вариантов > напридумать - толку все равно не будет
А примеры правильной организации можно почерпнуть из книг, статей, блогов, ua-devtalk :)
1) закрыть всё от всех, самому делать ключевую работу и никому не давать осознать всю полнотц идеи. Сотрудникам отдавать только рутинную работу, самих сотрудников иметь минимальное число, одних и тех же, и средней развитости, чтобы они тебя же не обманули. Контролировать, чтобы сотрудники не обменивались исходниками. Скрывать от сотрудников бизнес-связи. Этой модели придерживаюсь я.
Если вы хотите построить что-то выдающееся, это не верный подход. 1) Для того, чтобы сделать лучший в мире продукт, нужна лучшая в мире команда (не сотрудники!) 2) За лучший в мире продукт вам заплатят столько, сколько скажете и вам хватит денег на всех. У Гугля капитализация 20 милионов долларов на человека. 3) Для того чтобы сделать лучший в мире продукт, тем кто над ним работает, он должен быть интересен. А значит в такой команде не место посредственностям (а выдающийся человек в такой среде долго не задержится)
Если вы хотите заработать на квартиру в центре и лексус, то можно работать как угодно - бОльшую роль будут играть случайный факторы, такие как стоимость специалистов, наличие правильных связей, и т.п.
|
