Фёдор Борщёв

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

Менеджер слышит то, что хочет услышать

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

Когда программисты называют сроки в виде вилки, типа «2–4 дня», многие менеджеры слышат только первую часть вилки — «2 дня». Если сказать «во второй половине мая», менеджер услышит «15 мая» вместо «между 15 и 30 мая». Если сказать «не меньше трёх дней», менеджер услышит «три дня».

Что с этим делать? Если вы программист — называйте абсолютные, а не относительные сроки. Не «2–4 дня», а «будет в следующий понедельник». Не «во второй половине мая», а «1 июня». Не «не меньше трёх дней», а «через три дня назову срок».

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

Личные привычки: целиться в процесс, а не в результат

Меня пугают большие амбициозные цели. Я могу согласиться пару раз в неделю ходить в спортзал, но вряд ли смогу когда-нибудь «подтянуть мышечный каркас» или «стать здоровым/накачанным». Со второй целью, всякий раз, когда я пропущу спортзал (а такое рано или поздно случится даже если я — биоробот), я начну думать: «а накачаю ли я теперь мышцы? А не потерял ли я в результате?». Это тяжело.

Имея простую нестрашную цель «ходить в зал несколько раз в неделю», я пропускаю спортзал гораздо спокойнее — никто же не умрёт, если я на этой неделе схожу не три раза, а два или даже один раз?

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

Может и вам поможет? Если часто не достигаете больших целей, попробуйте ставить маленькие цели на процесс, а не большие цели на результат, мне помогает.

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

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

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

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

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

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

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

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

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

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

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

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

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

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