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

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

В этой книге автор, сам прошедший путь от разработчика до менеджера в сфере IT, рассказывает неочевидные моменты, которые являются критически важными для правильного управления. Почему разработчики увольняются после повышения зарплаты? Как делать FixedPrice проекты? Почему Scrum не упрощает менеджмент? Книга содержит ответ на эти и многие другие вопросы. В книге есть много баек, которые показывают тяжёлую, но интересную жизнь менеджера в разработке. Иллюстратор обложки: Ксения Ерощенко. Иллюстрации в тексте книги авторские.

Про эту книгу

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

Бизнес-литературы по менеджменту много, но этот “менеджмент” в области разработки программного обеспечения часто оказывается бесполезен или даже вреден.

Почему разработчики увольняются, хотя их зарплаты постоянно растут? Как делать Fixed Price проекты? Почему после внедрения Scrum’а управлять проектами не стало проще? Ответы на эти вопросы каждому приходится искать методом проб и дорогостоящих ошибок.

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

Я часто слышал, что знания без опыта не работают, и в этой книге я передаю и свой опыт тоже. Около половины книги занимают истории из жизни[1 - Во всех историях я постарался изменить обстоятельства и имена героев, чтобы не нарушать право людей на личную жизнь. Если вам кажется, что вы узнали себя или кого-то другого в какой-то из историй, то уверяю вас, вам только кажется. Если вы хотели бы поделиться какой-то своей историей (или задать вопрос), то вы можете связаться со мной через почту borisovke@gmail.com.] и кейсы с разборами. Эти истории содержат реальный опыт, и позволяют вам не делать ошибки самому, а наблюдать за ошибками других.

Про автора

Автор этой книги, Константин Борисов, имеет двадцатилетний опыт работы в индустрии разработки программного обеспечения. Участвовав в десятках проектах в российских, зарубежных и международных компаниях в роли разработчика и менеджера, он накопил опыт, которым и делится в этой книге.

Связаться с автором можно с помощью электронной почты borisovke@gmail.com.

Личный блог автора доступен по адресу https://bukov-ka.livejournal.com/ (https://bukov-ka.livejournal.com/)

Адреса в социальных сетях: ВКонтакте (https://vk.com/bukov_ka), Facebook (https://www.facebook.com/konstantin.borisov.121)

Создание обложки: Иллюстратор Ксения Ерощенко artbylulutyan (https://www.instagram.com/artbylulutyan/)

Раздел 1. Общие вопросы менеджмента

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

Особенности менеджмента в IT

Индустрия разработки программного обеспечения испытывает жуткую нехватку менеджерских кадров. Эта нехватка даже более выражена, чем нехватка разработчиков, тестировщиков, аналитиков и других исполнителей. Отчего так происходит? Дело в особенностях индустрии, которые требуют особенных (редких) менеджерских навыков и знаний. Давайте рассмотрим эти особенности.

1. В IT работают высококлассные исполнители, которые должны принимать решения сами.

Специалисты высокого уровня встречаются много где, но, пожалуй, только IT не имеет никаких протоколов и инструкций, и полагается на экспертные решения.  Технологии, методологии и бизнес-задачи слишком часто меняются, чтобы выработать какие-то реально работающие стандартные подходы. Да, многие компании имеют некоторые документы, но они описывают второстепенные вещи, а не основную работу. Описывается, как быстро надо ответить заказчику, но не описывается, что именно надо отвечать. Указывается процент покрытия юнит-тестами, но не описывается, как именно нужно реализовывать определённый функционал.

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

2. Исполнители крайне своевольны, не терпят хоть сколько-нибудь жёсткого обращения и требуют очень аккуратного управления.

Следствием предыдущего пункта и ситуации на рынке труда является то, что работники в IT требуют очень нежного менеджмента притом, что сами они ведут себя часто весьма агрессивно.

Например, только в IT менеджер сталкивается с тем, что его прямой и простой приказ не только не исполняется, но и открыто оспаривается. Для менеджера из другой области это шок, а для IT-менеджера – обычная реальность. Бесполезно говорить опытному разработчику, как именно он должен реализовать конкретный код. Его можно убедить, но им нельзя командовать.

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

Взаимодействие менеджера и подчинённого в IT – это разговор на равных, когда договорённости и взаимное уважение используются очень широко, а прямые приказы не используются вовсе (ну, почти).

3. Высокий уровень рисков.

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

4. Иностранные заказчики.

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

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

5. Техническая сложность проектов.

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

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

Из этого есть два следствия. Первое: в IT вы можете работать с удивительно классными профессионалами. Я с очень большой теплотой вспоминаю менеджеров, с которыми мне довелось работать самому. Многих из них я считаю своими учителями. Я вспоминаю и обдумываю то, как они работали, и это помогает мне и в работе, и в жизни. Когда я сам становился менеджером, я грел себя мыслью, что я смогу вырасти в такого же профессионала, как те, под началом которых я сам работал.

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

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

Почему проекты заканчиваются неудачей

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

1. Разработка ПО сейчас очень дёшева и заказчики хотят её такой оставить. Хотя разработчики имеют высокие зарплаты, а компании, разрабатывающие ПО, получают хорошую прибыль, но с каждым годом разработка ПО дешевеет. Один единственный самолёт Boeing 777 стоит больше $300 миллионов. Бюджет даже крупных проектов по разработке ПО составляет малую часть этой суммы. А самолётов серии Boeing 777 на данный момент выпущено более 1600. Стоимость ПО ничтожна по сравнению с общей ценой изделий.

В цифровых продуктах аналогично. Instagram в 2012м году был приобретён Facebook, и примерная стоимость сделки составила $1 млрд. Стоимость собственно разработки несравнима с этой суммой. Стоимость компьютерной графики фильма “Миссия невыполнима – 2” не идет ни в какое сравнение с гонорарами Тому Крузу. Хотя его можно было бы просто нарисовать.

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

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

Но деньги сами по себе не так важны, как следующий пункт.

2. У заказчика нет времени на уточнение требований. Изменение требований в процессе разработки ПО сейчас настолько распространено, что The Standish Group изменила критерии провала проекта для своего Chaos Report. Если клиент доволен, то считается, что проект успешен, несмотря на то, что сделали не то, что планировали.

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

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

проект пройдёт по плану абсолютно никаких.

Хорошая новость заключается в том, что заказчики это понимают (обычно). Большинство заказчиков имеет возможность увеличить бюджет или убрать часть функционала, чтобы проект таки принёс им какой-то осмысленный результат.

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