А чем, собственно, не нравится вторая модель? У нас в конторе
используется именно она и проблем нет никаких.
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: mi...@malva.ua
Правильный ответ: «зависит от». J
Как минимум, выбирать процесс в котором тебе самому будет удобно.
Сложно сказать конкретнее – зависит и от психологии владельцев и членов команды и от разрабатываемых продуктов/проектов. Если проекты/продукт уникальный и требует творческого похода – возможно стоит привлекать как можно меньше сотрудников но дать им солидные опции/максимум свободы. Если «поток» - можно наверное набрать и «середнячков» и четко ставить задачи. Как компромисс – можно попробовать выделить «ядро» разработчиков и «остальных» команду. Только не забывайте: люди не машины, чтобы нормально шла работа должна быть нормальная обстановка и общение в команде.
From: ua-de...@googlegroups.com [mailto:ua-de...@googlegroups.com] On
Behalf Of Go3DoN
Sent: Monday, March 06, 2006 2:49 PM
To: ua-de...@googlegroups.com
Subject: Процесс становления: защита от своих сотрудников.
Привет.Обсуждали с коллегой, какую позицию надо выбрать софтверной компании на самой заре существования:1) закрыть всё от всех, самому делать ключевую работу и никому не давать
Этой модели придерживаюсь я.2) наоборот, как можно больше показывать сотрудникам, чтобы они понимали Это мысль партнера.
Понимаю, что оба способа-- не годятся. Но как найти компромис.У меня узкое место -- централизация. Но ведь на начальном этапе и глупо надеяться, что кто-то будет работать лучше меня.
С другой стороны, он приводит веские доводы, что его старый конкурент-полиграфис вел себя с работниками открыто и преуспел. Но можно ли программирование сравнить с полиграфией? Как защититься от своих сотрудников? Они ведь могут просто создать такую же компанию либо уйти к конкуренту с твоими наработками.Что сообщество скажет?
1) закрыть всё от всех, самому делать ключевую работу
и никому не давать осознать всю полнотц идеи. Сотрудникам отдавать только рутинную работу,
самих сотрудников иметь минимальное число,
одних и тех же, и средней развитости, чтобы они тебя же не обманули.
Контролировать, чтобы сотрудники не обменивались исходниками.
Скрывать от сотрудников бизнес-связи.
2) наоборот, как можно больше показывать сотрудникам, чтобы они понимали цель и способы оптимизации. Работников брать самых талантливых,
выжимать из них все, и не держать, когда захотят уйти -- мол, нового найду, лучше тебя.
Организовывать в команде самообучение, способствовать пониманию архитектуры ПО, поощрять командную работу.
Нет. Есть информация, которую можно доверять ТОЛЬКО руководителям. В т.ч. - контакты заказчика, не предназначенные специально для сотрудничества с разработчиками.Открывать им бизнес-звязи
и держать в курсе планов,
Но ведь на начальном этапе и глупо надеяться, что кто-то будет работать лучше меня.
Весь вопрос в том, какого размера
проект. Если вы сами можете его сделать
и считаете себя наиболее компетентным,
оцените, насколько действительно
нужны другие члены команды. Команда,
середнячков, с одним лидером,
контролирующего всех и не доверяющего
никому очень неэффективна, лидер
тратит слишком много времени и усилий
на организацию и согласование. Скорее
всего, он сам напишет быстрее весь
продукт. Вопрос - для чего все
остальные люди?
В зависимости от ответа на него
рассматриваются несколько вариантов:
1. Не нужны - проект небольшой и не
предполагает большого развития в
ближайшем будущем
2. Делать заранее определенную и строго
фиксированную часть работы - для этого
необязательно открывать фирму, можно
просто каждому работать по домам
децентрализовано. У хорошего
программиста есть много знакомых,
которых можно привлечь
3. Люди нужны для того, чтобы можно было
в дальнейшем развивать проект,
децентрализовать полномочия и
ответственность. Только этот вариант
реально оправдывает организацию
собственной фирмы по разработке -
когда человек осознает, что он один не
сможет справиться со всей работой.
Если вы выбрали 3 вариант, то тогда вам
нужно думать о развитии и удержании
людей, создании командной атмосферы и
доверия, не сильно формальных
процессах управления. Важно осознание
личной заинтересованности людей в
этой фирме, т.к. если от них не будет
ничего зависеть, они будут уходить в
другие, где будет больше возможностей
роста, развития и зарплаты.
По мере роста фирмы модель управления
людьми и процессами будет изменяться.
Статьи Джоэля все читали наверное?
Думаю, что там можно найти несколько
хороших рекомендаций.
по поводу варианта 1 -- если вы сами все
делаете, зачем вам соотрудники?
и определитесь -- вам шашечки или все
таки ехать?
если хорошие руководители, а если
хорошие специалисты
так вот это разные люди, а не все
намешанное в одном как у вас
бизнес вы приплели вообще не в тему -
процесс правильной разработки с
бизнесом пересекаться должен в
одной-двух точках - и это руководитель
проекта - ведущий разработчик - бизнес
аналист
все
все сводится к правильной организации
процесса
иначе можно кучу вариантов
напридумать - толку все равно не будет
Многое написали но попробую дополнить,
Вопрос - как найти компромисс?
У вас старт компании, значит нужны люди которые умеют что-то делать и не
требуют контроля. Они должны уметь всё сразу чтоб хорошо заботиться о
проекте и помочь ему в критическую минуту - в общем профи своего дела.
Но как завлечь таких профи?
Самый простой путь, предложить им разрабатывать интересный продукт,
я думаю что многим из них надоела своя рутинная работа.
Хорошо, но ведь профи ... раз да два и украл заказчика. Нехорошо,
но с профи надо быть самому профи, если человек видит что его босс не
знает как составить договор, то он скорее подумает что проще сделать это
самому... и тогда зачем босс? Вы должны быть профи, или у вас должен
быть профи в плане управления бизнесом.
Не думаю что много профи очень хотят составлять договора, или маяться с
бухгалтерией или знакомиться с податковой. Их интересует интересная и
оплачиваемая работа, и вы должны им это предложить.
По этому же случаю не надо их нагружать бизнес связями и всеми вашими
проблемами, дайте им работать в своей стихие. И не надо за ними всё
время следить и поправлять, см. в книге Дж.Хайк Рейнвотер "Как пасти
котов" есть глава о мелочной опеке. Конечно не дай бог вам ошибиться, и
нанять дилетантов с хорошо подвешенными языками.
Это только один совет из миллионов которые мы можете получить.
Надо больше .... был совет насчёт книжек Йордана, Брукса, (добавил бы
ДеМарко). Также вам читать книжки по менеджменту, и так просто для
интереса прочитаете хотя бы с 10-ок книжек по типу
"Как компания Х добилась успеха", сейчас такие книги популярны.
Нет времени читать книги? Тогда пробуйте раз, два ... десять - вы
получите огромный опыт, и может даже напишите книжку о том как надо
делать, а как не надо :)
--
С уважением,
Дмитрий Сенников.
Olexiy Prokhorenko said the following on 07.03.2006 8:57:
> бизнес аналист
Звучит как бизнес-проктолог...
--
Oleg
>
> бизнес вы приплели вообще не в тему -
> процесс правильной разработки с
> бизнесом пересекаться должен в
> одной-двух точках - и это руководитель
> проекта - ведущий разработчик - бизнес
> аналист
> все
А также в затратах на зарплату и обустройство офиса :)
Особенно зарплата, всё таки это самая большая статья расходов IT компании.
>
>
> все сводится к правильной организации
> процесса
> иначе можно кучу вариантов
> напридумать - толку все равно не будет
А примеры правильной организации можно почерпнуть из книг, статей,
блогов, ua-devtalk :)
>
>
Если вы хотите построить что-то
выдающееся, это не верный подход.
1) Для того, чтобы сделать лучший в мире
продукт, нужна лучшая в мире команда
(не сотрудники!)
2) За лучший в мире продукт вам заплатят
столько, сколько скажете и вам хватит
денег на всех. У Гугля капитализация 20
милионов долларов на человека.
3) Для того чтобы сделать лучший в мире
продукт, тем кто над ним работает, он
должен быть интересен. А значит в такой
команде не место посредственностям (а
выдающийся человек в такой среде долго
не задержится)
Если вы хотите заработать на квартиру
в центре и лексус, то можно работать
как угодно - бОльшую роль будут играть
случайный факторы, такие как стоимость
специалистов, наличие правильных
связей, и т.п.