![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Рост "команды" идёт по своим законам - и никак не связан с увеличением, или уменьшением фронта работ (из законов Паркинсона) ;)
В условиях полного отсутствия менеджеров (предельный случай :) ), двое разработчиков будут тратить на согласование от одного до десяти процентов рабочего времени (это зависит даже не столько от характера работы, как от их опыта, умения, сработанности). Причём, время, уходящее на "организационные вопросы, включая выработку стандартов) будет расти экспоненциально - с числом разработчиков. Максимальные затраты на согласование могут достигнуть ста процентов (полный останов работ) уже в коллективе до десяти человек. Минимальное - в коллективе более дюжины (гарантированное отсутствие результативности). Но это, напоминаю - в условиях отсутствия менеджмента.
Руководитель группы из трёх-пяти разработчиков может взять на себя все "расходы на согласования" - кроме одного-десяти процентов времени каждого из своих разработчиков - потраченных на совещания и "беседы" с самим руководителем. Цена, кроме зарплаты руководителя группы - вдвое возросшее минимальное - и вчетверо - максимальное разумное время согласование простой детали, или изменения проекта.
Руководитель отдела, куда входят три-пять групп разработчиков - может взять на себя все "расходы на согласования" - кроме одного-десяти процентов времени каждого из своих руководителей групп. Время согласования одной детали/изменения - растёт ещё на пятьдесят процентов.
И так далее. Модель - скалируемая.
- А где же в модели - теневые связи и структуры?
- Они, пока, не учтены.
Каждая теневая структура не только лишает формальное описание проекта подобия практической ценности. Она ещё и удваивает долю времени каждого своего члена, потраченную на "согласования". При этом, она уменьшает время согласования одной детали. Иногда. Немного. Если на это согласование ещё осталось время в расписании...
В условиях полного отсутствия менеджеров (предельный случай :) ), двое разработчиков будут тратить на согласование от одного до десяти процентов рабочего времени (это зависит даже не столько от характера работы, как от их опыта, умения, сработанности). Причём, время, уходящее на "организационные вопросы, включая выработку стандартов) будет расти экспоненциально - с числом разработчиков. Максимальные затраты на согласование могут достигнуть ста процентов (полный останов работ) уже в коллективе до десяти человек. Минимальное - в коллективе более дюжины (гарантированное отсутствие результативности). Но это, напоминаю - в условиях отсутствия менеджмента.
Руководитель группы из трёх-пяти разработчиков может взять на себя все "расходы на согласования" - кроме одного-десяти процентов времени каждого из своих разработчиков - потраченных на совещания и "беседы" с самим руководителем. Цена, кроме зарплаты руководителя группы - вдвое возросшее минимальное - и вчетверо - максимальное разумное время согласование простой детали, или изменения проекта.
Руководитель отдела, куда входят три-пять групп разработчиков - может взять на себя все "расходы на согласования" - кроме одного-десяти процентов времени каждого из своих руководителей групп. Время согласования одной детали/изменения - растёт ещё на пятьдесят процентов.
И так далее. Модель - скалируемая.
- А где же в модели - теневые связи и структуры?
- Они, пока, не учтены.
Каждая теневая структура не только лишает формальное описание проекта подобия практической ценности. Она ещё и удваивает долю времени каждого своего члена, потраченную на "согласования". При этом, она уменьшает время согласования одной детали. Иногда. Немного. Если на это согласование ещё осталось время в расписании...
