Прошлый результат команды имеет смысл использовать в следующем плане вместе с условиями, при которых его получили. Если часть работы закончили по вечерам и в выходные, повторить тот же объём в обычном графике может не получиться. Переработки легко потерять при подсчёте закрытых задач, а затем незаметно включить их уже в следующее обещание.
Собственная разработка техлида занимает то же время, на которое команда рассчитывает для ревью, помощи и общих решений. Поэтому полезность его задачи ещё не объясняет, стоит ли ему браться за неё сейчас. В план придётся включить и работу, которую без его участия не могут закончить другие, а затем разобраться, какая из этих зависимостей действительно необходима.
Уже обещанная дата делает оценку работы неудобным разговором: любой более поздний срок звучит как отказ от обязательства. Но сама дата ничего не говорит о том, что к ней должно быть готово. Пока это не определено, разработчик и заказчик могут соглашаться с одним сроком, имея в виду разные результаты.
Разработчику могут предложить возглавить команду в знак доверия к его опыту. Но интерес к более сложным задачам в разработке ещё не означает желания управлять людьми. Повышение может увести от задач, в которых как раз хотелось расти.
На встрече один на один руководитель не всегда может сразу предложить решение. Но уже можно договориться, кто продолжит разбираться с проблемой и когда вернётся с ответом. Без такой договорённости даже внимательный разговор оставляет собеседника в неопределённости: ждать помощи, напоминать о себе или действовать самому.
Мне удобно, когда за задачу отвечает один человек: у него можно узнать, что сделано, чего не хватает и как продолжить работу. Ему могут понадобиться знания и помощь всей команды, и это не снимает с него ответственности за результат.
— Джеффри К. Лайкер
Сейчас читаю Getting Real книжку написанную компанией 37Signals. Очень нравится. Многие вещи такие как «делать меньше», «быть проще», «стартовать с базового функционала» очень мне по душе.