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

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

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

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

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

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

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

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

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

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

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

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

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