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

И, конечно, скрам никак не помогает в ситуации, когда проект заходит в тупик по какой-то причине.

Список ограничений можно продолжать долго. Проще сказать, что скрам не закрывает ни одной функции менеджера. Значит ли это, что менеджеры должны его игнорировать? Ни в коем случае! Я считаю, что сейчас каждый работающий в сфере разработки ПО должен хорошо представлять, что такое скрам и уметь работать с ним. Но относиться к скраму нужно не как к инструменту менеджмента, а как к набору идей, которые расширяют сознание и вырабатывают полезное отношение ко всему процессу разработки.

Для чего нужен Scrum

После предыдущей главы у кого-то, возможно, в голове возникает вопрос: “Ну и зачем этот скрам вообще тогда нужен?!” На самом деле, существование скрама очень полезно для всех.

Во-первых, давайте рассмотрим, почему скрам вообще возник. Скрам объявляет эмпиризм своей основой, то есть он полностью ориентирован на практику. А какая самая заметная черта проектов в IT? Самая заметная черта – это то, что они, в основном, проваливаются.

В соответствии с Chaos Report от Standish Group в 2015м году процент успешных проектов в IT был всего лишь 29% Причём, этот процент мало изменился с 1996го года (тогда он был 27%). Что это значит? По большому счёту, это значит, что менеджмент проектов в IT не работает. Если проект провалился, то это провал руководителя проекта.

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

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

А вторая особенность заключается в том, что маленькие проекты завершаются успехом гораздо чаще, чем большие. Среди успешных проектов 62% было маленького размера и 21% “небольшого” размера (moderate, что меньше medium).

Теперь становится понятней, почему Scrum “работает”. Он во-первых, ограничивает количество людей в команде. А во вторых, требует постоянно актуальный и отсортированный баклог и всегда доступного Product Owner’а, который как раз обеспечивает необходимое участие заказчика в проекте.

Прелесть Scrum’а в том, что он уже является своего рода стандартом разработки. Все заказчики его знают и понимают. Поэтому, менеджеру очень легко пользоваться им как инструментом.

Например, сроки горят и заказчик требует увеличить команду с семи человек до двадцати. Ситуация стандартная и, обычно, менеджеру приходится прилагать много усилий, чтобы отговорить заказчика от этой идеи. А тут можно очень просто сформулировать: “Это противоречит Scrum Guide и может привести к непредсказуемым последствиям. Оно вам правда надо?” Слово “Scrum” для заказчиков является аргументом, потому что они знают, что это Best Practice отрасли . Иногда даже использование Scrum прописывается в контракте. Тогда всё ещё проще.

Или вот тоже распространённая проблема, когда заказчик затягивает с ответами на вопросы команде. Раньше приходилось всю ночь вылавливать заказчика в его часовом поясе и выслушивать какие-то отговорки. А сейчас можно просто отправить грозное письмо: “В соответствии со Scrum для работы команды необходим Backlog с чётким описанием каждого элемента. Сейчас мы такого баклога не имеем. Последствия могут быть любыми”. В кратчайшие сроки заказчик сам выйдет на связь и сделает со своей стороны нужную работу.

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

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

История про удовлетворённость клиентов

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

Однажды в компанию Rolls Royce пришла жалоба от клиента, которая звучала примерно так: “Вы называете свои автомобили лучшими, но их качество разочаровывает. В недавно купленном автомобиле полно явных инженерных просчётов. Наиболее раздражающий – это часы. Их тиканье настолько громкое, что я его отчётливо слышу, даже на скорости в 60 миль в час! Это просто позор!”

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

Но зато известно, что именно из этой претензии родился известный слоган компании Rolls Royce: “На скорости 60 миль в час самый громкий шум в салоне – это тиканье часов”. Этот слоган наполняет гордостью работников и привлекает новых клиентов. Этот слоган показывает качество.

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

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

Оценки задач

Я написал несколько глав про оценки: про PERT, про то, как проверять оценки, про оценку рисков. Но меня не оставляло ощущение, что эти главы малополезны и я их убрал из окончательного варианта книги, оставив только пару неочевидных моментов.

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

В моей практике был забавный случай, когда я пришёл на новый проект, где вроде бы были проблемы с оценками, и поэтому случился кризис. Когда я стал разбираться, то выяснилось, что изначальные оценки были сильно уменьшены, так как заказчику они показались большими. И параллельно объём требований увеличился в десять (!) раз. После такого адекватность самих изначальных оценок можно было и не проверять. Там могли бы быть случайные числа, на “успех” проекта это не повлияло бы.

В общем, все эти, показавшиеся мне очевидными, рассуждения об оценках я убрал. Но, возможно, я был неправ. Если вам не хватает информации об оценивании задач и проектов, напишите мне, пожалуйста, о том, что именно вам хотелось бы знать: [e-mail].

Оценка субъективна

Но один момент в оценивании необходимо упомянуть, так как я часто вижу, что его игнорируют и попадают в беду. Важно понимать, что оценка – это субъективная величина. Про это легко забыть, когда смотришь на результат оценки в долларах. Кажется, что если проект оценён в $1’000’000, то это объективно. Ведь величина бюджета – это объективная величина! Как будто у нас есть некий мешок работы и мы его взвесили. Всё точно!

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

Кажется, что это не так важно, когда мы уже получили проект. Ведь мы знаем, как наша компания работает. С новым проектом мы будем работать, как обычно. И оценка сделана из этого предположения. То есть в рамках одной компании можно оценку считать объективной?

Совсем нет. Например, если вы спросите оценщика, на какую команду он рассчитывал оценку, то он скажет либо конкретные фамилии, либо уровень. Разумно в оценку сразу закладывать определённую структуру команды: один тимлид, три senior-разработчика, 5 middle-разработчиков. Но нужно понимать, что здесь тоже заложена субъективность.

Даже одинаковые по структуре команды могут сильно отличаться по производительности, просто за счёт того, что отдельные люди не могут сработаться. А отдельные могут так сработаться, что пожениться и сбежать из компании в отпуск на Багамы.Опытный менеджер может это выровнять, а может и не выровнять. Я уж не говорю о том, что вместо планируемых middle-разработчиков обязательно в команду вкинут junior-ов. Реальный бюджет при этом изменится и не в меньшую сторону.

Но, предположим, команду вы получили ту, какую планировали и какую указали в оценке. Теперь-то оценка стала объективной? Ничуть. Сам менеджер является также критичным условием валидности оценки.

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

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

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

Бесплатные буферы

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

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

Предположим, вы оценили этот релиз и получилось, что он будет готов через 6 месяцев. Так вот тут очень важно запланировать дату этого релиза на неделю (а может и на две) дальше. Этот буфер заказчику не будет стоить ничего, потому что на объём работ он не влияет. Но вам и команде будет гораздо проще жить.

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

Другой вид бесплатных буферов – это когда вы подстраховываетесь от действий других. По вашему плану нужно, чтобы требования были готовы 10 июня? Сообщите заказчику, что вы ждёте требования 1 июня. Тогда у вас хотя бы будет шанс не понести потери, когда вы получите требования плохого качества или с задержкой.

Или вам нужно интегрироваться с ещё не разработанным сервисом, который будет готов в декабре. Сообщите заказчику, что вам нужна документация по API хотя бы в ноябре. Явно она уже должна быть готова. Если вы не получите документацию в ноябре, то самой системы в декабре вы точно не получите. Ну и, конечно, даже если заказчик очень уверен, что это API будет готово 1го декабря, то никак нельзя ставить задачи, зависимые от него на 2е декабря. Обязательно нужен  такой же “бесплатный” буфер в плане, который подстрахует вас от неудачи другой команды.

Привычка раскидывать везде такие буферочки должна стать постоянным рефлексом любого менеджера. Если разработчик говорит мне, что уже сделал задачу и осталось только проверить, то я говорю, что задача будет сделана завтра (или сегодня, если повезёт). Если разработчик уверенно говорит, что задача будет сделана завтра, то я говорю заинтересованным лицам, что она будет готова послезавтра.

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

Цена бесплатных буферов

Хотя я и называю сдвиг промежуточных дат в плане “бесплатным” буфером, но менеджер прекрасно знает, что за всё надо так или иначе платить. Где подвох с бесплатными буферами?

Самая основная проблема заключается в том, что менеджер включает в план только “безопасные даты” и забывает, что плановые даты были другими. То есть менеджер забывает, что релиз должен быть готов не через 6.5 месяцев, а через 6. Заказчик тоже этого не знает. Поэтому, когда релиз выходит через 6.5 месяцев (по плану!), то ни менеджер, ни заказчик не осознают, что проект запаздывает на две недели.

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

Но менеджеру всё равно не так легко объяснить заказчику, что на проекте проблемы. Заказчик же видит, что всё идёт по плану. Тут можно достать этот “внутренний” план и объяснить, когда релиз должен был быть закончен на самом деле. Заказчики очень спокойно относятся к заложенным буферам, а особенно к буферам в виде сдвига дат. Ведь они им ничего не стоят!

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

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

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

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

История про проведение ретроспективы

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

Чтобы понять, почему так произошло, организовали ретроспективу. Руководитель проекта, в лучших традициях скрама, давал всем высказаться и выписывал на доску длинный список всех проблем, которые команда называла. Опять же в лучших традициях ретроспектив, сперва давали высказываться junior-ам, чтобы более опытные члены команды не давили своим авторитетом. Самым последним слово досталось лиду разработки, очень опытному архитектору, Петру. Пётр был краток:

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

Команда тестирования, не веря своим ушам, дружно стала возмущаться, но Пётр поднял руку, призывая всех к тишине.

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

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

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

Раздел 5. Становление менеджера

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

Менеджмент: начало

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

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

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

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

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

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

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

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

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

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

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

История про менеджмент не в IT

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

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

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