Автономия управления в малых коллективах
Обычно принято считать, что сложность управления повышается при увеличении коллектива, однако, я все больше уверяюсь в том, что организовать автономию (в кибернетическом смысле) в малом коллективе гораздо труднее.
В качестве примера не будем рассматривать коммерческую компанию - там довольно большая "фиксированная составляющая" (бухгалтерия, продажи, кадры, хозяйственная часть), которая все объясняет. Возьмем просто группу программистов.
Если у в группе больше 8 человек, то вполне можно выделить отдельного человека для ролей:
- Руководитель проекта (общается с заказчиком, следит за выполнением плана, выполняет организационную работу)
- Системный архитектор (преобразует требования заказчика в техническое задание программистов)
- Технический писатель
- Ведущий программист (руководит непосредственно разработкой)
- Программисты (чтобы держать такой штат было рентабельно, их должно быть не меньше 3-5 человек)
- Тестировщик - 1-2 человека
Эта система достаточно стабильна, при временном отсутствии любого из членов, остальные его вполне могут заменить, хоть и с меньшей производительностью, задача каждого участника уже, ее проще описать в должностных инструкциях (прочитать и запомнить которые под силу среднестатистическому человеку), поэтому кадры легче подобрать и обходятся дешевле. И еще один важный момент - при работе в такой команде, знание о проекте невольно распределяется, оно уже не хранится полностью в одной голове, волей-неволей создается больше документации, тем более что для этого есть специальные люди.
Когда группа меньше, роли приходится совмещать. А это само по себе требует более квалифицированных, талантливых, подготовленных кадров. Их труднее найти, они дороже стоят, один человек не способен одинаково хорошо делать разные виды работ: человека, склонного к работе системного архитектора, может раздражать административная работа, программист может ненавидеть работы технического писателя (одно дело написать комментарий или пояснения "для своих" - другое, полноценное руководство пользователя, со скриншетами) и т.д.
В итоге получаем "незаменимых людей", должностные обязанности которых плохо описаны. Эти люди перегружены работой, а в случае выбытия любого из них - работа останавливается. Таким образом, принципы автономии не работают, управленческие каналы перегружены информацией, сами управленцы перегружены работой, система функционирует неэффективно и плохо поддается стратегическому управлению, потому что руководителю уже не до стратегии, у него не хватает времени "думать вперед", принимать решения по "перенастройке" рабочих процессов и контроля исполнения таких решений.
"А как же гибкие методологии?" - спросите вы. Вероятно, они как раз и разрабатывались для таких случаев, реализуя одноранговые протоколы управления. По аналогии с одноранговыми сетями, которые уместны в небольших рабочих группах, но теряют эффективность при их увеличении. Но для применения таких методологий нужно соблюдение ряда условий: достаточно высокая квалификация каждого участника, высокий уровень инициативы и ответственности каждого из них и высокий уровень доверия участников друг к другу. Еще один момент - не каждый заказчик согласится распределить ответственность между несколькими соисполнителями - это создает ему дополнительные трудности. Заказчик предпочтет иметь дело с одним ответственным представителем исполнителя, с которого в случае проблем можно спросить. Частично решают проблему коллективы в форме "полных товариществ", когда заказчик может спросить с любого из членов товарищества полностью под всем обязательствам товарищества. Однако все ли захотят быть ответственным "за того парня" и много ли вы найдете программистов в свой коллектив, которые согласятся отвечать за вас и за которых согласитесь отвечать вы?
В качестве примера не будем рассматривать коммерческую компанию - там довольно большая "фиксированная составляющая" (бухгалтерия, продажи, кадры, хозяйственная часть), которая все объясняет. Возьмем просто группу программистов.
Если у в группе больше 8 человек, то вполне можно выделить отдельного человека для ролей:
- Руководитель проекта (общается с заказчиком, следит за выполнением плана, выполняет организационную работу)
- Системный архитектор (преобразует требования заказчика в техническое задание программистов)
- Технический писатель
- Ведущий программист (руководит непосредственно разработкой)
- Программисты (чтобы держать такой штат было рентабельно, их должно быть не меньше 3-5 человек)
- Тестировщик - 1-2 человека
Эта система достаточно стабильна, при временном отсутствии любого из членов, остальные его вполне могут заменить, хоть и с меньшей производительностью, задача каждого участника уже, ее проще описать в должностных инструкциях (прочитать и запомнить которые под силу среднестатистическому человеку), поэтому кадры легче подобрать и обходятся дешевле. И еще один важный момент - при работе в такой команде, знание о проекте невольно распределяется, оно уже не хранится полностью в одной голове, волей-неволей создается больше документации, тем более что для этого есть специальные люди.
Когда группа меньше, роли приходится совмещать. А это само по себе требует более квалифицированных, талантливых, подготовленных кадров. Их труднее найти, они дороже стоят, один человек не способен одинаково хорошо делать разные виды работ: человека, склонного к работе системного архитектора, может раздражать административная работа, программист может ненавидеть работы технического писателя (одно дело написать комментарий или пояснения "для своих" - другое, полноценное руководство пользователя, со скриншетами) и т.д.
В итоге получаем "незаменимых людей", должностные обязанности которых плохо описаны. Эти люди перегружены работой, а в случае выбытия любого из них - работа останавливается. Таким образом, принципы автономии не работают, управленческие каналы перегружены информацией, сами управленцы перегружены работой, система функционирует неэффективно и плохо поддается стратегическому управлению, потому что руководителю уже не до стратегии, у него не хватает времени "думать вперед", принимать решения по "перенастройке" рабочих процессов и контроля исполнения таких решений.
"А как же гибкие методологии?" - спросите вы. Вероятно, они как раз и разрабатывались для таких случаев, реализуя одноранговые протоколы управления. По аналогии с одноранговыми сетями, которые уместны в небольших рабочих группах, но теряют эффективность при их увеличении. Но для применения таких методологий нужно соблюдение ряда условий: достаточно высокая квалификация каждого участника, высокий уровень инициативы и ответственности каждого из них и высокий уровень доверия участников друг к другу. Еще один момент - не каждый заказчик согласится распределить ответственность между несколькими соисполнителями - это создает ему дополнительные трудности. Заказчик предпочтет иметь дело с одним ответственным представителем исполнителя, с которого в случае проблем можно спросить. Частично решают проблему коллективы в форме "полных товариществ", когда заказчик может спросить с любого из членов товарищества полностью под всем обязательствам товарищества. Однако все ли захотят быть ответственным "за того парня" и много ли вы найдете программистов в свой коллектив, которые согласятся отвечать за вас и за которых согласитесь отвечать вы?