Несколько лет я работал в продуктовой разработке, и у меня выработалось виденье, которое я бы хотел обсудить с вами.
Сроки — это миф
Наверное, все, кто изучают управление командой или методологии разработки, знают или хотя бы слышали, что сроки — это миф. По этой теме уже написано множество статей, но я вкратце опишу ситуацию, как её вижу я. Описывать её я буду на примере художников. Ты подходишь к художнику на какой-нибудь главной улице города, у него рядом стоит десяток портретов разных людей, разного возраста, он приглашает вас сесть на его маленький стульчик и говорит, что нарисует вас за час, и это будет стоить 5000 рублей. Действительно, через час вы получаете готовый портрет, не факт, конечно, что он будет очень хорошего качества, но на портрете точно вы, и вы довольны. Но что, если вы хотите, чтобы художник нарисовал вам персонажа? Вы хотите персонажа, который будет лучше, чем персонаж из вашей любимой игры, но художник никогда не рисовал персонажей из игр, вы ему досконально описываете все детали, и вот, потратив час и 5 тысяч рублей, художник отдает вам полотно, но на нём совсем не то, что вы хотели, даже не близко. Художник оправдывается, говорит, он никогда этого не делал и ничего не может с собой поделать, тогда он говорит: давайте я вам нарисую этого персонажа ещё раз, на это мне понадобится ещё 3 часа. И вот, спустя три часа, у него под ногами уже десяток скомканных листов, но у него всё равно не получается нарисовать вашего персонажа.
Смысл этой истории в том, чтобы показать два типа работы. Про них еще писал Хононов в своей книге про DDD, там он это называет основной, вспомогательный и универсальный поддомены. Вспомогательный или универсальный поддомены — это уже что-то известное, например, очередной интернет-магазин, там всё понятно, и ожидать чего-то нового неразумно. Основной же поддомен приносит бизнесу конкурентное преимущество — именно то, благодаря чему бизнес зарабатывает деньги. Так вот, вспомогательный поддомен — это ваш портрет, портреты художник рисовал, возможно, уже ни одну тысячу раз, а основной поддомен — ваш персонаж.
Бесполезно прогнозировать сроки у основного поддомена, с такой задачей даже ваш самый опытный разработчик, скорее всего, не сталкивался, а значит, будет как котёнок сначала тыкаться носом в стену, пытаясь решить задачу.
На моём скромном опыте многие менеджеры этого не понимают, они начинают спрашивать сроки, разработчики называют, далее всё это умножается на неизвестные коэффициенты, становится в три или даже в четыре раза больше. Ошибки перемножаются, складываются, но приближённых к реальности сроков не появляется. Разработка основного поддомена — это не работа на станке, у которого фиксированная производительность, это, скорее, ещё одна маленькая студия Pixar, которая отчаянно пытается найти правильную дверь в тёмной комнате и заставить бизнес зарабатывать деньги.
С другой стороны, существует ещё один эффект, который очень мешает прогнозировать бюджет даже у вспомогательного поддомена. Давайте посмотрим на разработку так же, как это, скорее всего, делают экономисты. Возьмём разработчика в вакууме, он, как и любой разумный человек, стремится к максимизации результата, при этом стараясь затратить как можно меньше усилий. Человек хочет заработать денег, а работать как можно меньше, ведь работа ради самой работы — бессмысленна. Руководству же хочется заработать как можно больше денег, вложив при этом как можно меньше. Руководству нужно планировать бюджет, и кажется логичным требовать с разработчиков сроки. Но как только начинают спрашивать сроки, возникает один известный феномен, который называется "выпрямление сроков". Допустим, при разработке очередной задачи программист по требованию менеджера называет срок 4 дня, но на самом деле шанс, что он выполнит задачу быстрее — 10 %, при этом менеджер ожидает, что в реальности половину задач он будет выполнять быстрее, а половину — медленнее, чем называл изначально. Программист же, как разумный человек, начинает растягивать задачу, зная, что он назвал 4 дня, а значит, можно выполнить к этому сроку и не раньше. Соответственно, бюджет, выделенный на эту задачу, также вырастает в два раза. Если бы менеджер не спросил сроков, то задача была бы сделана быстрее, а может — медленнее, но точно не растягивалась бы специально.
Резюмируя:
из-за установки сроков бюджет вырастает почти в два раза
сроки у основного поддомена все равно узнать невозможно
Как тогда управлять разработкой?
Ставить приоритеты.
С этого момента давайте ограничим наш контекст тремя действующими лицами:
менеджер (топ-менеджер) — руководство, которому нужно получить сделанный проект, кнопку на сайте или важное поле в сгенерированном отчёте, его задача — заработать денег, вложив как можно меньше денег
тимлид – связующее звено между менеджером и командой
программист — член команды тимлида, его задача — как можно меньше работать и чтобы его не уволили
Менеджеру очень хочется знать, через сколько будет сделано то, что он просит, но этот срок, на самом деле, должен задавать не тот, кто делает задачу, и даже не консилиум разработчиков на очередной встрече, называемой "груминг". Этот срок должен называться только тимлидом. Тимлидом должен быть очень опытный разработчик, и он может и даже должен консультироваться с членами команды по срокам, но сами сроки, которые у него получились, не должны нигде мелькать — ни в Jira, ни даже устно, их нигде не должно быть перед глазами. Эти сроки должны использовать только, чтобы хотя бы попытаться спрогнозировать бюджет, и если у бизнеса может не хватить бюджета на эту задачу, то сообщить ему об этом сразу.
Тимлид, как большой брат, должен знать, что и где происходит, кто чем занимается, но это не обязательно должен быть микроменеджмент. Тимлид должен построить ровно такую атмосферу, чтобы каждому члену команды должно быть стыдно, если на дейли он начинает выдумывать несуществующие или незначительные проблемы или говорит, что он продолжает делать задачу, хотя весь вчерашний день он играл в CS. Как это сделать? Это вопрос не этой статьи, но я был в командах, где тимлидам удавалось построить такую атмосферу.
Тимлид не должен открыто всё обкладывать метриками, задача тимлида — наблюдать, и если он чувствует, что где-то что-то идёт не так, то оказывать давление. Давно известен принцип, согласно которому, если метрика становится целью — она перестаёт быть хорошей метрикой, поэтому важно, чтобы тимлид никогда не показывал свои метрики, которыми он пользуется. Если он кому-то сообщает про метрику, то следует от неё отказаться, так как внутри команды слухи разлетаются быстро, и люди быстро начнут искусственно подгонять эту метрику.
Есть бесчисленное количество способов померить перформанс разработчика, в конце концов, можно посмотреть самому МРы, на дейли лишний раз спросить, уточнить подробности задачи. Задача тимлида — не мерить KPI, а чувствовать, работает человек или симулирует. И если кажется, что что-то не так — очень важно сразу это сказать, даже если может показаться, что это пустое обвинение. Многие люди нормально реагируют на такое, ведь бизнесу важно видеть результат, а если человек с агрессией реагирует на такие вопросы — значит, точно что-то идёт не так, и надо искать проблему. В конце задачи необходимо смотреть, что сделал каждый человек, и если, по меркам тимлида, этого оказывается слишком мало, то предпринимать действия, вплоть до расставания с человеком.
Что делать с тимлидом?
Я уверен, после прочтения прошлого параграфа возник очевидный вопрос, и я постараюсь на него дать ответ. Почему тимлид не будет саботировать процесс? Почему бы ему не спускать с рук все недоработки, нанять себе команду таких же, как он, и сидеть на зарплате, передёргивая таски в Jira? Это как раз главная задача менеджера — избежать этого. Как это сделать? Пока что я придумал только один способ, но, по-моему, он надёжный.
Нужно дать тимлиду долю. Тимлидом нужно выбирать человека, который не только обладает необходимыми навыками, но и больше всего волнуется за проект. Навыкам тимлида можно обучить, а вот заставить любить проект невероятно трудно. Только дав тимлиду долю от прибыли конкретного продукта, а не, например, всего бизнеса, как делают в некоторых компаниях, можно действительно получить невероятные результаты. Какой смысл делать больше, чем симулировать работу, если от этого ничего не зависит? Ну, дадут тебе премию на один оклад больше, даже если продукт заработает миллионы, но стоит ли он того, чтобы весь год рвать жопу, надрываться? Я думаю, нет. Именно процент от прибыли — вот что по-настоящему замотивирует человека. Пусть он разделит риск с бизнесом, если продукт не принесёт прибыли, то человек получит меньше, но он всё равно получит свою заслуженную зарплату за работу. Но так у него есть шанс получить значительно больше, что точно добавляет азарт и зажигает, возможно, уже давно потухшие глаза. Тимлид — это опора команды, а если он делает основной поддомен, то эта опора должна быть железобетонной. Главное — не бояться говорить правду и принимать решения.
В комментариях можно снять мне розовые очки, ссылки на тг-канал не будет.