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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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