Заметки с тегом «Проекты»

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

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

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

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

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

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

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

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

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

В отношениях с людьми я руководствуюсь простым правилом — я не работаю с мудаками.

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

Недавно я отменил заказ сантехника, который за три минуты до назначенного времени прислал СМС, что опаздывает на час, а потом опоздал ещё на два.

Расставаясь с такими людьми, я делаю лучше и им, и себе.

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

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

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

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

Поведение микроменеджера проще всего осознать и побороть через полную противоположность — доверие.

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

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

Если вы занимаетесь микроменеджментом, значит вы не доверяете коллегам. А есть ли смысл садиться в одну лодку с людьми, которым вы не доверяете?

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

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

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

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

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