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

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

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

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

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

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

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

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

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

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

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

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

Многим программистам (и менеджерам) не хватает простого навыка — проверить через два дня.

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

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

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

Кто должен проверять через два дня, если задачу делали впятером? Конечно ты.

Во всех своих командах я избавляюсь от срочных задач. Люблю, когда даже в трекере такого флага нет.

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

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

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

Вот вам три шага, чтобы победить срочные задачи в вашей команде:

• Разберитесь с техническими и управленческими долгами. Чаще всего срочные задачи возникают на уровне «я выкатил, а оно упало», и «я выкатил, а через неделю поняли, что нихуя не работает». Чтобы привести долги в порядок, нужна сила воли и пара месяцев. Если вы понимаете, что за два месяца не разберетесь — значит что-то в вашем проекте серьезно не в порядке, нужно все бросать и лечить.
• Перестаньте оценивать задачи в часах. Если в вашей команде меньше 5 человек — совсем не оценивайте. Если больше, и план на неделю не удается обсудить с каждым лично — попробуйте оценивать днями.
• Возьмите комфортный интервал планирования, на который вы можете построить четкий план, к примеру 1 неделю. Заложите запас и не трогайте ребят в течение этого интервала.

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

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

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

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

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

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

Давайте экономить деньги и не любить фичи.