Как хорошему разработчику не стать плохим менеджером

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

Водопадная модель разработки

Периодически слышу от разных людей сожаление, что они используют водопадную модель разработки: “Мы бы и рады использовать Agile, но заказчик против”, “У нас водопад, мы к нему привыкли”, “Мы готовимся перейти на гибкие методологии, но пока у нас водопад”. Такие разговоры меня удивляют, так как встретить сейчас чистую водопадную модель разработки практически нереально.

Чтобы выяснить, почему так, давайте вспомним, что такое водопад как методология разработки, и как связаны разные этапы разработки:

Все этапы идут один за другим. Следующий этап начинается после полного окончания предыдущего этапа. Это очень-очень старая модель. Её название пошло из статьи Уинстона Уокера Ройса, опубликованной в 1970м году. Юмор заключается в том, что в той статье Ройс говорил об устарелости и ограниченности этой модели и о необходимости перехода на итеративные модели. То есть “водопад” – это то, как разрабатывали программы в 60-е годы.

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

Что делать, если заказчик на этапе интеграции захотел изменить требования, добавить отчёт? Ничего не сделаешь. В принципе отсутствовала такая опция в те далёкие времена. Можно было дождаться полной имплементации и начать новый проект по реализации этого отчёта. Либо прекратить все работы и начать всё снова. Нельзя попросить институт, который писал требования, их изменить. Потому что это физически вагон бумаги, который уже ушёл от них. И по той документации уже что-то сделано и компании не будут ничего переделывать, так как у них в контракте описана работа по изначальной версии задания и всё. Даже просто разорвать эти контракты и остановить работы часто было невозможно, так как в контрактах такая возможность могла отсутствовать. Компаниям приходилось оплачивать продолжение работ по контракту, даже когда нужда в программе отпадала. Так, например, происходило после распада СССР, когда экономическая ситуация изменилась кардинально и многие системы стали не нужны, но проекты остановить было невозможно.

Уже в 70-е годы прошлого века было понятно, что эта модель очень ограничена. Вся индустрия развивалась так, чтобы можно было в программы вносить правки, чтобы код следовал быстрым изменениям на рынке.

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

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

В обычном же проекте в настоящее время классического водопада нет. Да, возможно, не используется Scrum. Да, возможно, вообще никто не может сказать, что именно это за методология, и она нигде не описана. Но это не водопад.

Почему это вообще важно? Потому что методология разработки оказывает очень большое влияние на всё. Если вы считаете, что работаете по одной методологии, а на самом деле работаете по другой, то вы будете принимать неправильные решения.

На практике это выглядит просто и привычно. Вы думаете, что вы применяете водопадную модель. Значит, вы можете легко делать Fixed Price[3 - Fixed Price – модель работы, когда заказчик заранее договаривается о конкретной сумме за проект. Любые превышения бюджета идут за счёт компании-исполнителя. Этот термин используется в противоположность проектам Time&Material, когда заказчик оплачивает время работы разработчика на своём проекте, сколько бы этого времени не понадобилось.] проекты. Нужно только собрать требования и можно сказать, в какой бюджет вы впишетесь.

Fixed price проекты могут быть очень выгодными, поэтому вы начинаете их делать. И оказывается, что вы превышаете бюджет проекта в разы. Сперва вы подозреваете, что вы неправильно оцениваете проекты, и вы начинаете совершенствовать свой процесс оценки (параллельно теряя деньги на проваленных проектах). Потом вы видите, что требования описываются недостаточно детально, и вы начинаете совершенствовать аналитику и мучать заказчика дополнительными раундами уточнения требований (снова теряя деньги на проваленных проектах). Потом вы видите, что эти прекрасно описанные требования всё равно меняются заказчиком на более поздних этапах. Вы начинаете это ему запрещать, а заказчик возмущается, так как его бизнес уже изменился за то время, пока вы писали свою аналитику. В результате вы понимаете, что для применения чистого “водопада”, вам нужно жёстко отфильтровывать заказчиков и их проекты. После разработки и применения этих фильтров вы понимаете, что на рынке нет достаточно заказчиков, которые готовы с вами работать по “водопаду”. Но вы не переживаете, так как ваша компания вряд ли дойдёт до этого этапа. Скорее всего, денежные потери будут неприлично высоки уже на этапе попыток совершенствования оценок. Вы либо прогорите, либо измените свои подходы к проектам.

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

Виды проектного менеджмента

Роль менеджера гораздо слабее определена, чем роль разработчика. В разных компаниях разные менеджеры занимаются очень разными видами деятельности. Но так же, как backend-разработчик отличается от frontend-разработчика, разные руководители проектов отличаются друг от друга по набору знаний и умений.

Отсутствие чёткого разделения разных типов менеджеров очень мешает на практике. Если вы устраиваетесь на вакансию “руководитель проектов”, то вы не можете заранее угадать, что от вас потребуется.

Давайте пройдёмся по разным типам менеджмента. Но имейте в виду, что менеджеры, как и разработчики, бывают “fullstack” и на практике от вас наверняка потребуется знание нескольких перечисленных областей:

1. “Бумажная работа”. Самый печальный вид менеджмента, который менеджментом не является, так как не подразумевает принятия важных решений. Я бы не выделял этот пункт, если бы такой менеджмент не был настолько распространён.

Дело в том, что многие IT компании возникли как группа разработчиков, возглавляемых каким-нибудь молодым предпринимателем. Предпринимательский склад ума отличается от менеджерского, и разработческий менталитет тоже далёк от менеджерского. В результате компании живут фактически без проектного менеджмента до тех пор, пока не вырастут до размера 30-50 человек. На этом этапе уже появляется желание работать над проектами хотя бы среднего, а не мелкого размера. Владелец компании начинает понимать, что он не может выполнять функции менеджера проектов, так как у него не хватает времени. А ключевые разработчики начинают жаловаться, что 99% их времени занимают задачи, не имеющие отношения к разработке: написание писем, проведение совещаний, отчётность и т.д. Тогда решают “завести” менеджеров проектов.

Но раз компания выросла без менеджеров, то и обязанности менеджеров определяются из соображения “то, чем разработчику не хочется заниматься”, забывая, что менеджеру для эффективной работы нужно иметь возможность влиять на принятие решений. В результате менеджеру приходится добиваться результата очень косвенными методами: переговорами с владельцем компании, начальниками отделов и лидами, манипуляциями с отчётностью и отточенной риторикой.

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

2. Предпродажа/продажа. Интересный подвид проектного менеджмента, когда бойкий руководитель проекта с хорошо сработавшейся командой создаёт новый бизнес. Он общается с новым для компании заказчиком, а его команда быстро облекает все хотелки заказчика в работающий код. Начало бизнеса выглядит как череда мелких проектов и прототипов, которые быстро вырастают в большие проекты.

Такой менеджер имеет продвинутые навыки оценки проектов и ведения переговоров. А, например, нанимать junior-ов и выращивать из них senior-ов он запросто может не уметь или не любить. В его работе это не нужно. Когда бизнес из стадии зарождения переходит в более стабильную фазу, такому менеджеру становится скучно, а сам он становится неэффективным. Он передаёт подготовленную площадку другому менеджеру, а сам идёт стартовать новый бизнес с новыми заказчиками.

3. Менеджер процессов. Умение определять процессы разработки важно для любого руководителя проектов, но есть проекты, где нужны прямо гении такого управления. В больших проектах, где работает сотня и больше людей, и где есть большой заказчик со своими заморочками, процессы могут стать очень сложными. Я не говорю про бюрократию, которая мешает работать. Я говорю про сложные бизнес-требования, когда конкретный функционал должен определяться разными группами людей.

Если написанный большой кусок кода внезапно оказался не соответствующим европейским требованиям GDPR по защите персональных данных, то это катастрофа. Если требования, которые бизнес создавал полгода, оказалось невозможно реализовать ни в каком виде, то это тоже катастрофа. Чем больше проект, тем выше вероятность таких катастроф, и тем важнее роль процессов.

Но и в небольшом проекте, где работают 5 человек, очень здорово, когда разработчики не мешают тестировать, а заказчик может видеть нужную ему отчётность напрямую, без менеджера.

4. People management[4 - Вот один из примеров, когда явление настолько редкое, что даже термина нормального устоявшегося нет. Часто менеджеры занимаются “делом”, а когда нужно мотивировать, выращивать специалистов, исправлять выгорание, разрешать конфликты и осуществлять прочую нетривиальную работу с людьми, зовут HR-специалистов, которые не могут ничем помочь, потому что недостаточно погружены в конкретную проблему. Члены команд опытных People Manager’ов характеризуют их как честных, справедливых, опытных или просто говорят “нормальный руководитель, приятно с ним работать”.]. В компаниях с проектной организацией менеджеры проектов отвечают за найм, развитие и увольнение сотрудников. Даже, если менеджеры за это не отвечают, то они могут быть ключевыми людьми в деле мотивации и карьерного развития членов своих команд.

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

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

В IT у антикризисного управления есть особенности, которые сильно отличают его от антикризисного управления в других областях:

a. Невозможно сменить команду. Традиционный антикризисный подход – это начать работу “с чистого листа”. Вся команда меняется на новых людей, все процессы перезапускаются заново. В IT это сделать невозможно, так как люди слишком ценный ресурс и найти 20-30 незанятых человек просто невозможно. К тому же в “кризисных” проектах знания распределены по ключевым людям и без них нельзя продолжить работу. Да и заказчик не может терпеть задержку из-за “перезапуска” проектов.

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

b. Сложно диагностировать проблемы. “Нормальный” проект тоже имеет кучу сработавших рисков и рисков, которые могут сработать в любой момент. Тяжело отличить проект в кризисе от обычного, поэтому часто проекты заканчиваются провалом, а никто не успевает заметить, что они проваливаются, и ввести антикризисное управление.

Антикризисному менеджеру нужно очень хорошо понимать механизмы функционирования IT проекта, чтобы понять, на чём сконцентрировать изменения, а что можно оставить, как есть.

c. Демотивация команды серьёзно влияет на работу. Когда приходит антикризисный менеджер, люди уже сильно измучены неудачами, нелогичным менеджментом и пониманием, что проект далёк от нормального. А менеджеру требуется, чтобы они сделали трудовой подвиг и вывели проект из пике.

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

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

История про ответственность

На одном моем новом проекте подошли ко мне лиды двух команд, Вася и Наталья. Судя по их виду, разговор предстоял серьёзный.

– Константин, нам нужно принять серьёзное решение, – сразу перешла к делу Наталья.

– Отлично, я люблю принимать решения. В чём дело?

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

Вася и Наталья выжидающе глядели на меня. Я в ответ тоже глядел выжидающе:

– И какое решение нужно принять-то? – я пока не мог задать более осмысленного вопроса.

– Решение о переписывании модуля на новую архитектуру! – Вася и Наталья были удивительно единодушны.

– Мы можем его не переписывать?

– Нет, не можем. В том и дело. Мы не можем реализовать нужные заказчику задачи без этого.

– Так а какая альтернатива есть?