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