Фёдор Борщёв

Заметки с тегом «План»

Не сомневаться в принятых решениях

Важный принцип из ГТД — нужно отделить принятие решения от его выполнения. Скажем, хочу я пробежать Московский Марафон. Если я просто поставлю себе в календаре напоминалку за месяц до старта, что пора бы зарегиться на марафон, то в день напоминалки меня начнут одолевать сомнения: а надо ли оно мне? А смогу ли?

Если же я перенастрою голову и перестану сомневаться в принятых решениях, то я подумаю над этими вопросами только один раз — когда буду ставить задачу. Да и саму задачу я поставлю попроще, не «зарегистрироваться на марафон», а «открыть форму по такой-то ссылке». Когда придёт время, я просто потрачу 5 минут на регистрацию — ведь я уверен, что тот я, который ставил месяц назад задачу, подумал достаточно хорошо.

Тот же принцип и на работе — если вы с коллегами что-то решили, то нужно либо это сделать, либо решить заново. Сомневаться по пути — глупо: только силы потратите.

Почему я не люблю оценивать задачи

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

Почему я не даю оценок маленьких задач? Во-первых потому, что если в задаче указано сколько её нужно делать, это подрывает саму основу контракта с исполнителем: ведь я же, отдавая задачу, ожидаю получить не 5 часов работы по написанию кода, а работающую фичу на проде.

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

Почему я не люблю оценивать задачи

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

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

Хороший план исходит от команды

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

В плане менеджеров обычно все завязано на цифры: берем беклог, оцениваем каждую задачу в часах, а затем всё как в бухгалтерии: в двухнедельном спринте у нас 80 часов, 20 оставляем про запас, а остальные 60 — забиваем задачами. От такого плана исполнители уже не отвертятся — раз оценил задачу в трекере на 4 часа, значит 4 часа над ней и работай.

Хороший план исходит от команды

Когда спринт планируют исполнители, мозг перестраивается — вместо накидывания задач, чтобы забить ёмкость, люди начинают под них подписываться. Внутренний диалог ведётся совсем по-другому: не «верно ли я оценил эту задачу», а «успею ли я выполнить вот эти обещания в срок?».

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

Планирование спринта: буфер

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

Самое главное правило — не обманывать себя при планировании и помнить, что планы без запаса не сбываются.

Свой запас я держу в буфере, который называется «можно проебать» — это прям такой лейбл в трекере. Лейбл ставится на задачи, которые мы будем делать только, если успеем закончить более важные.

Прямо в трекере написано, что задача — буферная
Прямо в трекере написано, что задача — буферная

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

Если спринт спланирован хорошо, то примерно половина из буферных задач успешно закрывается. Если плохо — закрываются или все, или ни одной.

Проектный план: краткость, проверяемость и постоянство

Хороший план толкает вперед любой проект — от подвисших продуктовых фич до собственного бизнеса и домашних дел. В продолжение заметки об отличиях диаграммы Ганта от проектного плана, приведу 3 правила, которыми пользуюсь сам при составлении проектных планов.

Краткость

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

В проектном плане — одно предложение для одной задачи

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

Проверяемость

Каждый пункт плана содержит глагол в совершенной форме и обещает что-нибудь сделать:

Обещание Хуйня
Сделаем Будем делать
Починим Посмотрим
Доработаем Приступим к доработкам
Назовем сроки Начнем

Я сделяль проектный план

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

  • Починили отправку СМС, вот скриншоты с телефона;
  • Сделали отчет по пропущенным звонкам, файл во вложении;
  • Избавились от падений сервера, вот график мониторинга.

Постоянство

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

Если хоть один понедельник проебался — проект разваливается. Хочешь отдохнуть — запланируй поменьше дел, но не пропускай понедельник*.

Потратить 10 минут на еженедельный план легче, чем не съесть тортик в кофейне

Писать письма по понедельникам — не больно. Весь процесс планирования и рефлексии занимает не больше 10 минут — не съесть тортик, проходя мимо кофейни, сложнее, чем написать хороший план. И уж точно 10 минут стоят спокойной и результативной недели.

Вместо выводов

  1. Короткий и проверяемый план сжигает мосты и мотивирует. Все просто — если план не выполнен, то я плохой менеджер: дал конкретные обещания и сам же их проебал.
  2. Постоянная и публичная проверка выполнения плана держит команду в тонусе, а пульс проекта — в ритме 52 отгрузки в год.

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