Большие проблемы маленьких проектов и их решение

Tweet

Despite the inability of most software developers to become people managers, it seems that the selection of non-technical people is an even worse choice for management of technical people.

Jurgen  Appelo Blog

Интернеты пестрят статьями о том, что менеджеры-технари – это ошибка природы. Последние исследования Google показали, что технические навыки – наименее востребованные из навыков менеджера. В последнее время заметен однозначный тренд в сторону «нетехнических» менеджеров проектов. Причин тому много – например возвращение менеджеров-технарей на техническую стезю. Индустрия научилась делать работу «нетехнических» менеджеров эффективной даже в технически очень сложных проектах. Исследования, проведенные PMI в далеком 2004 году, показывают, что уже тогда среди группы менеджеров-респондентов более 95% руководили техническими проектами, но меньше половины из них имели технические навыки в соответствующей области.

Но какой ценой все это далось? Саша Орлов в своем блоге высказал интересную мысль:

Оглядываясь назад и по сторонам, я заметил, что во всех знакомых мне успешных командах, где менеджер был не техническим человеком, всегда был сильный технический лидер. Это очевидное наблюдение. Неочевидное же заключается в том, что менеджер и тех.-лид работали в плотном тандеме. Тех.-лид, например, в публичных обсуждениях никогда не подвергал сомнению авторитет менеджера. Более того, своим поведением тех.лид как бы говорил: «Мы работаем вместе, я силен в технической части, ты силен в других вещах – отношениях с клиентами, администрировании бизнеса и т.д.»

То есть получается, что всё-таки нужны и технические, и управленческие, административные, коммуникативные – если хотите, менеджерские навыки, просто их сложно совместить в одном человеке. Это подтверждает и Скотт Беркун:

Of course there is nothing mutually exclusive between being a great programmer and being a great manager. These people exist. But they’re rare.

Но, всё-таки такие менеджеры встречаются! В отчете PMI всего 50% были не технарями…

Да, в начале менеджерского пути у бывших технарей куча проблем. Об этих проблемах писали уже все кому не лень, даже я (см. заметку «Менеджер-начинашка» и серию «Случаев из жизни…»: случай #1,случай #2 и случай #3). Но большинство этих проблем – неспецифические, это просто проблемы неопытного менеджера! Программистское прошлое на начальном этом этапе значения не имеет или даже работает «в плюс». А вот дальше ситуация меняется…

В приведенной цитате из блога Саши Орлова у менеджера-профессионала и технического lead’а формируется тандем, который позволяет им мирно и эффективно вести проект. А как быть тому несчастному, который из опытного, хорошего team lead’а, пройдя все тернии и горнила, стал-таки классным менеджером проекта? С одной стороны, он счастливчик – и нашим, и вашим… Но получается ли у него так же эффективно наладить процесс коммуникации с собственной командой, построить отношения с другим team lead’ом? Об этом моя заметка.

Вообще говоря, у менеджера проекта, который при этом является и классным программистом, диапазон возможностей больше. Это сильная сторона, а не недостаток (как думают многие!), которым необходимо умело воспользоваться в реальном проекте.

Disclaimer: Подразумевается, что менеджер уже овладел soft-n-hard skills (процесс, планирование, управление рисками, коммуникация внешняя, коммуникация внутренняя, постановка задачи и т. д.). Речь идет именно о внутреннем конфликте между приобретенными ПМ-скими (project manager, менеджер проекта) навыками и высокой программистской квалификацией.

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

А. Технический микроменеджмент:

Суть – вмешательство в зону ответственности team lead’а на проекте, подрыв его авторитета, ограничение полномочий. Иногда эта форма может выглядеть очень невинно – например, менеджер в какие-то моменты отвечает на технические вопросы или делает технические выводы самостоятельно (а ведь он может это сделать в силу технической квалификации!), но это лишь первый шаг.

Б. Попустительство team lead’у:

Начитавшись менеджерской литературы, в порыве быть «хорошим менеджером» ПМ может предоставить dev lead’у полную свободу творчества в технических вопросах и организации работы с командой разработчиков. Что, с одной стороны, является неплохим мотивирующим фактором, а с другой – может оказаться фатальным для результата проекта, за который ПМ несет ответственность.

Истина, как обычно, где-то между этими полюсами «Невырожденные» ответы на вопрос о разделении полномочий между dev lead’ом/team lead’ом описаны в литературе. Например, в книге С. Макконнелла «Rapid Development»  (не переведенной на русский язык, уж не знаю, по какой причине), в книгах и статьях Л. Константина (например, «Человеческий фактор в программировании») и других. В общем случае водораздел (а также и другие факторы – например, стиль управления ПМ‘а) зависит от структуры команды, которая, в свою очередь, является производной от типа проекта. Этой зависимости будет посвящена одна из следующих заметок. В текущей же – мои мысли насчет общих правил поведения менеджера-программиста.

Точка отсчета. Договориться на берегу и соблюдать договоренности (привет, Кэп)

В случае если в команде есть team lead (что может быть далеко не всегда) этот team lead зачем-то ПМ‘у нужен… В такой ситуации в начале проекта ПМ‘у необходимо, с учетом пожеланий team lead’а определить для себя самого цели существования team lead’а на проекте (в конце концов, решать именно ПМ‘у), а затем обсудить эти полномочия с командой и team lead’ом в том числе.

После того как договоренности достигнуты и зона ответственности очерчена, внесение изменений в эти договоренности может быть вызвано лишь чрезвычайными обстоятельствами и представляет собой крайнюю меру, когда другие методы исчерпаны. ПМ должен четко соблюдать эти границы, не подрывая авторитет team lead’а.

Но! Стоит помнить, что такие чрезвычайные обстоятельства вполне реальны. Например, в случае срыва выпуска нескольких промежуточных версий подряд может возникнуть вопрос, справляется ли team lead со своими обязанностями. Возможно, стоит пересмотреть границы ответственности.

Совет 1. Если таблетки от жадности не помогают – откусите кусочек

ПМ – не team lead, это другая роль со своими достоинствами и недостатками. Опытный ПМ это понимает. Но также ПМ‘у не стоит забывать, зачем он стремился к этой роли.

Если же у ПМ‘а всё-таки есть желание сохранить техническую квалификацию (желание доказать самому себе, что всё еще можешь, подтвердить авторитет перед командой),  при этом также имеется уверенность в собственных силах и достаточно времени, это можно сделать, не переходя дорогу team lead’у в целом.

ПМ может оставить за собой разработку какого-то сложно модуля либо проектирование архитектуры, какие-то исследования. Участие в этом «куске», с одной стороны, позволит ПМ‘у быть ближе к коду, непосредственно участвуя в разработке, а с другой – в остальной части проекта полномочия team lead’а могут быть расширены.

Совет 2. Лучшее средство от невроза – больше работать

Управление проектами – это высокострессовое занятие. Как следствие, может случиться истощение нервной системы, и в голову начнут приходить черные мысли о микроменеджменте: «Что же делают конкретные разработчики сейчас? А вдруг они делают что-то не то, а за проект в целом отвечаю я сам? А вдруг приоритетные требования не были учтены? А вдруг есть архитектурные просчеты? Как же тогда я буду сдавать этот проект?»

Если при этом ПМ переходит к конкретным действиям с целью успокоению своих нервов, фактически вмешиваясь в работу team lead’а, то надо что-то менять.

На эти проверки можно посмотреть вот под каким углом: если ПМ делает работу team lead’а, значит, ему хватает на это времени. Если так, то, может быть, ПМ не совсем должным образом выполняет какие-то свои обязанности? Есть недочеты по коммуникации с заказчиком, по уточнению требований, по работе с рисками, по организации тестирования?
Если ПМ‘у хватает самоуверенности отрицательно ответить на эти вопрос,  значит, он элементарно «недогружен». Чтобы справиться с неврозом и позывами к микроменеджменту, в качестве крайней меры такому ПМ-у можно порекомендовать ведение параллельного (второго, N+1’ого) проекта (например, внутреннего).

Совет 3. Вы с team lead’ом – разные люди

ПМ’у стоит помнить, что его карта мотивации отличается от карты мотивации team lead’а. То, что для ПМ’а важно сейчас, еще не интересно team lead’у. Как образно выразился Слава Панкратов, team-lead еще не стал менеджером-циником.

Если ПМ вспомнит, как он думал, когда был team lead’ом, возможно, сможете понять вашего team lead’а глубже и, в частности, заранее обойти острые углы, связанные с его желанием сделать как лучше – например, использовать новую версию библиотеки или построить универсальный движок.

Но не стоит перегибать палку. Team lead может подходить к решению проблемы не так, как к той же проблеме подошел бы ПМ-разработчик. В такой ситуации, чтобы очередной раз не наехать на team lead’а беспочвенно, стоит применить подход тестировщиков.

Если ПМ видит какую-то задачу, решенную иначе, – найдите формально зафиксированное требование, которому не удовлетворяет выбранный способ реализации. Если такое требование не найдено, претензии ПМ’а INVALID и team lead прав.

Именно по этой же причине, так как team lead мог выбрать иной подход к реализации, ПМ‘у не стоит делать предположений о внутреннем устройстве продукта, например, отвечая на  вопросы заказчика/спонсора о поведении продукта и пр.

Совет 4. Используйте свой опыт – помогите тестировщикам

Если зуд неуверенности по отношению к тому, делает ли team lead всё правильно, не проходит, у ПМ’а есть легальный способ удовлетворить собственное беспокойство, не скатываясь до микроменеджмента и не нарушая зоны ответственности team lead’а. Таким способом является помощь тестировщикам.

Если ПМ’а, с учетом его высокой технической квалификации, не покидают мысли, были ли учтены те или иные технические риски, нет ли архитектурных просчетов, правильно ли интерпретированы требования, – ПМ’у стоит спроектировать тесты, которые позволят команде QC проверить опасения. Команда тестирования точно будет благодарна. А если ПМ сможете показать эти тесты team lead’у и команде по разработке до начала кодирования или на начальных этапах, скорее всего, отрицательной реакции с их стороны не будет.

Совет 5. Приоритизация на высоком уровне – прерогатива ПМ‘а.

Даже если вопросы архитектуры,  тактики разработки, распределения задач между программистами находятся в зоне ответственности team lead’а, приоритизацию крупных задач разработки следует делать ПМ’у.

Если нет тесных связей между разработкой крупных модулей (а обычно ее нет, если интерфейсы взаимодействия между модулями определены на ранних этапах), то team lead’у по большому счету будет всё равно, в каком порядке эти модули разрабатывать. А раз так, ПМ может повлиять на сортировку.

ПМ-программист понимает технические риски разработки, а также то, какие элементы системы представляют собой ее центральные части (ядро, основные workflows/фичи). Именно эти задачи и должны разрабатываться в первую очередь.  Такая приоритизация не нарушает полномочий team lead’а в технических составляющих проекта, но, в то же время, является эффективной стратегией минимизации рисков.

Совет 6. Промежуточные билды – оружие тройного действия

Наличие у team lead’а широких полномочий в принятии решений не означает отсутствие его ответственности перед ПМ‘ом. Причем, вследствие технической квалификации ПМ‘а, реализация этой ответственности может осуществляться без дополнительных бюрократических методов (например сбора данных и вычисления метрик), так как ПМ в состоянии получить гораздо больше непосредственной информации, просто «поиграв» с промежуточным билдом.

Если проект выполняется по каскадному процессу, имеет смысл разбить процесс разработки на несколько итераций с выпуском промежуточных билдов. Эти промежуточные билды будут иметь двойной смысл: с одной стороны, ПМ сможет формально отслеживать прогресс по проекту, наблюдая самолично, как реализована та или иная функциональность из билда к билду, и имея возможность среагировать на ранних стадиях. С другой стороны, эти билды могут использоваться также для промежуточных демонстраций прогресса заказчику/спонсору проекта и управления ожиданиями.

Баги, найденные тестировщиками в процессе тестирования промежуточных билдов могут использоваться как система раннего оповещения для ПМ-а. При опытной команде тестирования на проекте, ПМ-у особое внимание стоит обращать на баги переоткрытые несколько раз, так как это позволит не только пресечь в зародыше конфликт между командами разработчиков и тестировщиков а также возможно обнаружить некоторые проблемы архитектуры на ранних стадиях (см. подробнее в заметке «О метриках и переоткрытых багах»).

Вот такие получились шесть советов. Мне кажется, они должны помочь ПМ-у успешно выполнить проект и в то же время дать team lead’у сделать свою работу. В следующей заметке серии будут приведены конкретные рекомендации по организации взаимодействия ПМ – team lead в проектах разных типов. To be continued…