Фёдор Борщёв

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

Не написано, значит, не было

Это — тупое правило, которое здорово помогает во всех спорных ситуациях.

Программист не сдал задачу вовремя, потому что не знал? Покажи, где это было написано. Если не нашёл — значит, дедлайна не было.

На встрече договорились что-то сделать и не записали? Значит, никому не надо.

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

Не продавливать по срокам

Неопытные менеджеры часто строят разговоры с программистами на давлении. Начиная от банального «5 дней, говоришь? А может, давай за 4, но без тестов?» и заканчивая манипулятивными просьбами расписать подробную смету по часам на каждое требование.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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