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

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

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

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

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

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

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

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

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

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

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

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

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

История про самую распространенную причину провала проекта

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

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

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

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

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

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

Так что же является новым скоупом?

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

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

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

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

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

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

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

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

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

Так и с проектами. У менеджера есть выбор: либо продемонстрировать клиентоориентированность и гибкость и сделать, что просит заказчик, либо напомнить про бюджет и пойти на потенциальный конфликт. Менеджеры не враги себе, они выбирают “простой” вариант. Особенно при подходе Time&Material, когда все дополнительные хотелки всё равно будут выполнены за счёт заказчика.

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

То есть менеджеру, чтобы эффективно контролировать scope creep, нужно как чётко понимать, какие работы были запланированы изначально и что добавилось позже, так и иметь хорошие навыки в переговорах/продажах. Однако такая ситуация имеет и плюсы. Если вы имеете мощные переговорные навыки, то некоторые упущения в контроле объёма работ, могут не быть такими критичными. И наоборот, если вы очень хорошо умеете планировать и отслеживать, что делает ваша команда, это даст вам отличные аргументы в переговорах с заказчиком.

История про предугадывание желаний

Однажды я пришёл в новую парикмахерскую. Мне нравится пробовать разные образы, и мне интересно давать свободу мастеру, поэтому стрижку я заказал, как обычно: "На ваше усмотрение, но чем безумнее, тем лучше". Мастер позадавал наводящие вопросы и пообещал сделать стрижку, "как в Омске точно не стригут" и "за эту стрижку из соседнего барбершопа мастера выгнали". Результат мне понравился, но я был немного удивлён. Мастер не использовал длину моих волос, а сделал очень короткую стрижку. Она была довольно сложная в исполнении, но не “безумная”, как я формулировал, а скорее “практичная”. Спортсмены и военные что-то подобное носят.

Я спросил у него, почему он сделал именно такую стрижку. Ответ сделал мой день: "Ну ты же программист, вряд ли хочешь сильно с укладкой париться". Мастер при этом улыбался знающей улыбкой, искоса поглядывая на меня, как бы говоря: “Здорово я угадал, правда?”

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

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

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

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

Секреты успешных Fixed Price проектов

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

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

Fixed Price проекты – самые жёсткие. У заказчика есть фиксированный бюджет и в него нужно уложиться при любом раскладе.

Все аутсорсные компании хотят научиться делать Fixed Price проекты (и практически никто не умеет это делать). Дело не в том, что эти проекты дают больше прибыли (хотя это и так). Дело не в том, что успехи в Fixed Price проектах означают высокий профессионализм команд и совершенство процессов (хотя это тоже так). Дело в том, что Fixed Price проекты не могут быть сделаны никак иначе. У заказчика есть некоторый бюджет и требования, которые ему нужно реализовать. Он не может превысить бюджет по соображениям бизнеса. Он готов платить больше, чем он заплатил бы по Time&Material, но ему нужны гарантии, что он уложится в бюджет. Это требование бизнеса. И такие проекты могут получать только те, кто умеет делать Fixed Price.

Я видел достаточно успешных и неуспешных Fixed Price проектов, чтобы утверждать, что секрет их выполнения – это контроль скоупа проекта. Я уже писал в главе “Куда ползёт scope” про те источники превышения бюджета, о которых обычно забывают. Но с Fixed Price проектами описанное там приобретает на порядок большую важность.

Что будет, если менеджер на проекте Time&Material допустит превышение бюджета? Аутсорсер получит больше денег! Потому что, чтобы довести проект до конца, заказчик будет вынужден найти больше денег и компания-аутсорсер получит больше прибыли6. Что будет, если менеджер на проекте Fixed Price допустит превышение бюджета? За это придётся заплатить компании, и она потерпит убытки.

Часто на проектах Time&Material даже ставятся задачи найти какой-то дополнительный объём работы и “допродать” его заказчику. Это фактически управляемый scope creeping. При Fixed Price дополнительные объёмы всегда идут по одной схеме: закончите этот проект качественно и в срок, и мы будем дальше с вами работать.

Подходы эти настолько разные, что я бы даже не рекомендовал одному менеджеру вести одновременно Fixed Price и Time&Material проекты. Потому что нужно иметь совсем разный настрой и по-другому общаться с заказчиком. Конечно, менеджерские навыки там и там нужны одинаковые, но их использование сильно отличается.

Но дело даже не только в настрое менеджера и его квалификации. К команде тоже предъявляются другие требования. Я видел компании, где для менеджеров проводятся тренинги по Fixed Price проектам и ведётся анализ успехов и неудач, но на разработчиков очень редко обращают внимание. А это важно.

Помните ту историю, которую я рассказал в главе “Куда ползёт scope” о разработчике, который прямо не митинге с заказчиком реализовал какие-то требования? Так вот, если бы в проекте Fixed Price такое произошло, то наверняка бы раздался звук чего-то тяжёлого, брошенного менеджером в голову этого разработчика, чтобы вывести того из переговорного процесса. Потому что в bodyshop-проекте такое поведение является желаемым (инициатива полезна!), в Time&Material – иногда терпимым (путает процесс, но работает на удовлетворение заказчика), а вот в Fixed Price – категорически вредным.

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

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

В Fixed Price проектах команда должна понимать всю сложность проекта и очень осторожно действовать с требованиями, оптимизациями, предложениями и замечаниями заказчика.

Тут меня могут спросить: “А как же Agile?! Мы же все такие гибкие и ориентированные на изменения под требования заказчика!” Всё так и есть. Здесь Fixed Price проекты не выделяются. Я успешно делал Fixed Price проекты по Scrum (и это было весело). Но надо учитывать, что высший приоритет заказчика – это бюджет. Любые предложения что-то добавить ведут к необходимости что-то выкинуть. Это можно сделать и реально делается, но надо быть осторожным.

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

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

Жёсткое отслеживание объёма работы в случае Fixed Price проектов – это не агрессия и жажда денег, это проявление профессионализма и уважения к заказчику.

История про объединение оценок

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

– Так, первый пункт “Экран ввода данных”, у Дмитрия общая оценка получилась 200 часов. Посмотрите ваши оценки, у вас такие же часы получились по подзадачам?

– Нет, у меня больше на создание БД. 32 часа вместо 24. Мне кажется мы там провозимся, – озвучивал я свои отличия.

– Отлично, ставлю 32 на создание БД, – Владимир не спорил.

– А у меня ещё там есть подзадачка обновление юнит-тестов на 6 часов. Но её Дима, наверное, по другим раскидал, – заметил другой разработчик, Алексей.

– Хорошо, добавляю задачку на юнит-тесты на 6 часов, – Владимир обновлял оценку, пока говорил ответ. – Всё по этой задаче? Следующая: “Отчёт по премиям”.

– У меня там на дизайн формы в два раза больше времени…

– А у меня ещё на экспорт и отправку почты маленькие задачи.

– Добавлено, – оценка росла как на дрожжах. – Двигаемся дальше.

Так мы очень быстро проходили по всем пунктам, выбирая максимальные оценки и добавляя максимальное число задач. Я не выдержал:

– Владимир, а почему ты выбираешь максимальные оценки и, не разбираясь, добавляешь задачи в список? Как-то бездумно получается.

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

Почему Scrum не решает менеджерских задач

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

Сложность. В официальном “The Scrum Guide” Scrum определяется как нечто, что “легко понять”, но “трудно овладеть”. То есть если у вас Scrum не заработал, то это нормально. Scrum указывает некоторое направление, но совсем мало помогает в достижении ваших целей. Это не инструмент в обычном понимании.

Оценка и планирование. Что хочет знать заказчик, который приходит с некоторым проектом? Ему интересно знать, сколько будет стоить реализация его проекта, и когда будет результат.  Какие ответы даёт на это скрам? Никаких. Это гениально, на самом деле, но ответа скрам не даёт. Сейчас даже про story point никаких упоминаний нет.

А как планировать какие-то даты? Если, например, нужно будет код интегрировать с куском, разрабатываемым другой командой, то на какую дату можно ставить эту интеграцию? Неизвестно.

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

От руководителя проектов больше всего требуют конкретные сроки и прогнозы по их выполнению. Скрам тут не помощник.

Командообразование. Может быть, скрам как-то помогает сколотить команду в единое целое? Отнюдь. По скраму команда является самоорганизующейся (self-organizing), а скрам-мастер может только заниматься коучингом (coaching). А коучинг, между прочим, является сложнейшей менеджерской техникой, когда менеджер, абсолютно не высказывает своего мнения и помогает человеку прийти к решению самому. Как овладеть скрам-мастеру такой техникой? Ответа нет. Что делать, если в команде конфликты, если часть команды ведёт себя контрпродуктивно, если разные члены команды действуют неслаженно? Ответа нет.

Даже самые простые вопросы координации скрам не освещает. Например, у вас есть разработчики, тест-дизайнеры, автоматизаторы и ручные тестировщики. Как они должны работать, чтобы никто не простаивал, а спринт выдавал качественный результат? В начале спринта у тестировщиков нет тест-плана, а в конце спринта у тест-дизайнеров нет работы. Скраму это безразлично.

Управление большими командами скрам тоже не поддерживает, указывая, что команды больше 9 членов “нуждаются в слишком большом объёме координации”. А ведь размер команды как раз является одним из показателей мастерства менеджера. Скрам это не покрывает.

People management. Очевидно, скрам игнорирует более сложные вопросы стратегического управления людьми, как, например, мотивацию, профессиональный рост, повышение самооценки, обучение.

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