Проблемы отдела разработки и их решение

Недавно я обнаружил себя в состоянии сидения с удрученным выражением лица. Причиной столь печальной ситуации было то, что я задумался о своей продуктивности как программиста и “руководителя отдела” программистов (возьмем пока эту должность в кавычки). А задумался я об этом потому, что производительность моя неудовлетворительна. Вряд ли кто-то размышляет о своей продуктивности, если она достаточно высока.

В общих чертах проблема выглядит следующим образом: у меня много идей, которые не получают развития. За те 9 месяцев, что я являюсь руководителем отдела, никаких значимых продвижений в плане развития отдела не наблюдается. Хотя некоторые люди успевают родить за тот же срок. В то же время я не развиваюсь и в личном плане, как специалист. Плюс постоянное состояние аврала и ощущение, что работа - это река без начала и конца. Прямой путь в выгорание.

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

Для ответа на этот вопрос вернемся в начало моего путешествия в данной компании.

Раньше я был обычным программером, который занимался разработкой одного или двух проектов. И все было хорошо - каждый день я выдавал какой-то результат, достаточно быстро продвигался в самообучении и был в общем и целом доволен таким положением дел.

Но далее случилось страшное - я стал руководителем отдела мобильной разработки.

Появилась ежедневная текучка - оценить проект, провести грейдинг, созвоны по орг. вопросам, мониторинг состояния сотрудников, и т. д. На меня посыпались задачи проектного характера, выросшие из хороших идей - разработка приложения в R&D, разработка библиотеки компонентов, разработка showcase-приложения, и т. д. и т. п.

И тут становится очевидно, что моя производительность падает не линейно в зависимости от количества задач и проектов, а логарифмически:

Куда делись 20%? Ушли на рессеивание внимания между задачами и вхождение в контекст после перерыва. Причем с нарастанием количества задач эта проблема усугубляется. Условно: 3х22=68, 4х15 = 60, и так далее.

Также следует заметить, что задачи неравнозначные: руководство разработкой проекта требует совершенно иного погружения, нежели задачи организационного характера. Это приводит к снижению качества и текущего проекта.

В итоге ситуация деградирует до того момента, когда выполняются только срочные задачи, а все остальное откладывается на потом. Типичный диалог: “Есть продвижения по задаче N?” - “-Нет, пока времени нет”.

То есть мы застреваем в одном из квадратов матрицы Эйхенхауэра:

А, как известно, самые срочные дела обычно не важны в стратегической перспективе. И наоборот - важные дела практически никогда не срочные.

Выходит, что если ничего не изменить в этой системе, то значимых продвижений в отделе мобильной разработки ждать бессмыссленно - этого не произойдет никогда.

Наш техдир выполняет миллион задач ежедневно, из них значительная часть совпадает с задачами руководителя отдела мобильной разработки просто в силу орг. причин: кого из исполнителей определить на какой проект - лучше видно, когда все ресурсы доступны к оценке. А эта информация доступна только техдиру. Либо мне нужно заниматься постоянным мониторингом кто в каком проекте чем занят. Что нереалистично с учетом наличия других задач. К слову сказать, на мой взгляд, наш техдир является самым эффективным сотрудником нашей компании. По крайней мере, среди тех сотрудников, с чьей работой я имел возможность ознакомиться.

Очередное почему: почему техдир эффективен, в руководитель отдела мобильной разработки - нет? Потому что техдир является хорошим менеджером и выполняет менеджерские задачи. Чем же занимается глава отдела? Он пытается одновременно быть эффективным менеджером и программистом.

Принцип Питера говорит нам, что хороший программист - это плохой менеджер.

То есть, если у нас много орг. задач и нам нужен результат, то у нас два пути:

1. Назначить на роль менеджера - менеджера

2. Назначить на роль менеджера - программиста. Тогда два варианта:

В то же время, строго с экономической точки зрения, использовать программиста в качестве менеджера нецелесообразно - программист стоит гораздо дороже и найти его сложнее. Не говоря уже о посредственной продуктивности в качестве менеджера.

Повторю ключевые постулаты:

1. Программист неэффективен в качестве менеджера, и потому фрустрирован.

2. Техдир частично дублирует задачи руководителя отдела, причем в значительной части.

3. Самое важное - нет результатов.

Решение первое: нанять менеджера, а программиста отправить на выполнение тех задач, где он эффективен.

Решение второе: в качестве эксперимента перейти от иерархической (классической) системы управления к проектной (экспериментальной).

Суть состоит в следующем:

1. Убрать промежуточное звено между техдиром и программистами в виде руководителя отдела.

2. Все задачи, которые висели на нем, распределить между программистами в соответствии с опытом каждого. Исполнители отчитываются о прогрессе техдиру (например, еженедельно).

3. Задачи распределять из принципа “не более одной задачи на человека”. Иначе пойдем по кругу неисполнения.

Это не универсальное решение, подходит не ко всем отделам и сильно зависит от количества сотрудников. Но, думаю, в данный момент времени это позволит компании преодолеть вялотекущее болото, в которое превратилась работа отдела.