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

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

Разработчику эти правки не стоят ничего. Он говорит: “Да я их внёс прямо сейчас, пока мы разговариваем”. Оценка на них ровно 0. То есть если даже это и добавленная работа, но это работа с нулевой оценкой. Она же не может влиять на бюджет, правда?

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

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

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

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

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

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

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

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

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

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

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

Как-то, проходя мимо переговорки, я заметил большую толпу заходящего туда народа и коллегу-менеджера, Макса. Я остановился и спросил, что происходит.

– Да вот ретроспективу своего проекта проводить буду. Должно быть интересно. Мы проект завалили, в полтора раза дольше делали, чем это планировалось. Заказчик крайне недоволен да и наше руководство тоже.

– А почему завалили-то?

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

Я пожелал Максу удачи, а сам про этот случай вспоминаю периодически. Я очень благодарен коллеге, что он честно ответил “не знаю”, а не стал прикрываться обычными “команда слабая”, “заказчик сложный”, “сроки были нереальные” и т.д. Если менеджер не знает, почему его проект провалился, то стоит в этом признаться и себе, и другим.

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

Если вы внимательно читали предыдущую главу, то у вас в голове наверняка царит неразбериха: “Что же является расширением скоупа проекта? Какие просьбы заказчика нужно выполнять без вопросов, а за какие требовать дополнительный бюджет?”