Групповуха

Часто в менеджменте бывает так, что делаешь все правильно, по известным методикам, да и все так делают. Но то тут, то там всплывают проблемы и придуман уже второй уровень - методики решения этих проблем. При этом не покидает чувство, что что-то не так. Ну не может правильный подход быть таким уязвимым. Пытаешься придумать как организовать по-другому, неожиданно находишь записи выступлений топ-менеджеров топ-компаний и вдруг в голове все проясняется. Пробуешь - работает. Удивляешься, почему большинство продолжает питаться кактусами. Но с другой стороны и ладно, зато у твоей компании возникает конкурентное преимущество. Конкретно имею в виду метод проверки гипотез, о котором писал ранее. Здесь же речь пойдет о групповой разработке и групповой деятельности в более широком смысле слова...

Лучше всего проблема совместной работы сформулирована одним французским профессором в далеком 1913 году:

То есть, когда все занимаются всем, являясь меленькими винтиками большой системы, чтобы элементарно не запутаться, нужна не только система контроля задач, но и драгоценное время руководителя, который при этом из ЛИДЕРА превращается в ДИСПЕТЧЕРА. А если случайные задания (по самым разным темам) даются неопытному исполнителю, то руководитель рискует вообще превратиться в НЯНЬКУ и тратить непозволительно много своих ресурсов на поиск и анализ чужих ошибок, объяснение, просьбы исправить и все новые и новые проверки. Но самое плохое в этой схеме не потеря времени, денег и даже не пресловутые сроки и дедлайны угнетающие психику.

Так как же можно решить эту проблему, как снизить влияние эффекта Рингельмана. А все просто, как всегда все дано уже придумано. В 1914 году на заводах Генри Форда начали применять конвейер. Я работал на заводе на конвейере по сборке компрессоров для холодильников и скажу вам так... Главное в этой организационной системе вовсе не то, что процесс разбит на мелкие типовые задачи, которые делаются параллельно с автоматической координацией в виде транспортной ленты. Вовсе нет. Главное то, что КАЖДЫЙ ЗАНИМАЕТСЯ СВОМ ДЕЛОМ и не отвлекает других. Еще пример приходящий на ум - музыкальный оркестр. Ну нет у них такого, что вчера ты трубач, а сегодня скрипач, так не бывает.

В офисной работе и в разработке программного обеспечения в частности, нужно тоже просто разделить работу на независимые направления и закрепить их за ответственными исполнителями. И все проблемы координации, сроков, контроля версий сразу же естественным образом решаются. Такой подход более понятен и бизнесу. Не надо объяснять, что в команду нужен еще один сотрудник. Появилось новое направление - значит, нужен. А любые спорные ситуации по пересечению зон ответственности можно легко решить просто договорившись с коллегой, не отвлекая руководителя.

Что делать с взаимозаменяемостью? Ведь если каждый будет заниматься только своим, он ничего не будет знать о работе смежников. Для бизнеса опасно, если сотрудники незаменимы. Это миф. Развеивается он следующим соображениями:

1. Если работа организована нормально (без подвигов и дедлайнов) то вряд ли что-то упадет во время отпуска ответственного. Но на всякий случай он должен быть на связи. Ведь ему НЕ ВСЕ РАВНО.
2. Нужны регулярные совещания команды по текущим делам, чтобы сотрудники понимали кто чем занимается.
3. Краткосрочно (в случае проблемы) заместить исполнителя может и должен руководитель. Это как раз одна из его обязанностей как ЛИДЕРА ответственного за несколько направлений.

Как повышать квалификацию джунов (неопытных сотрудников)? В схеме когда все занимаются всем как раз все плохо. Джунам часто попадают задачи, за которые никто не хочет браться. Типа, пусть помучается, наберется опыта, получится - молодец, нет - передадим другому. Это отвратительно. Не надо так. Это издевательство приводит к снижению самооценки и выгоранию. Наоборот, надо давать джунам простые задания по малозначимым темам, но с условием, что эти маленькие кубики будут складываться в его собственное направление. Отныне заниматься этим будет только он (она). Вплоть до тестирования на мощностях заказчика. Так новичок увидит всю картину, поймет, что в ТЗ были шероховатости, подправит их и даже может быть добавит интерфейсного удобства для пользователей. Такой джун гораздо быстрее вырастит до мидла (специалиста) и сеньора (ведущего специалиста).

На каждом проекте, где я был или руководителем, или подчиненным, шла непримиримая борьба между рассмотренными подходами. И статистика неумолима. Если система бардака (все делают все) преобразовывалась в разделение по направлениям, тут же проявлялся положительный результат. А там где лебедь, рак и щука продолжали тянуть в разные стороны, неизбежно возникали непредвиденные ошибки, требующие значительного времени на исправление.

←241 | заметка 242 | 243→