Про само-менеджмент и дедлайны
Исторически как-то так складывается, что я часто работаю в двух командах параллельно. Либо это временный период перехода из одного проекта в другой. Либо это временная передача моего ресурса в другую команду. Но факт в том, что иногда приходится очень много совмещать и ходить на встречи "х2" (два планирования, два дейлика и тд)
Сейчас начался спринт где у меня загрузка 50/50 на две команды. И ещё близится ревью. Что означает:
- в основной команде не хочется профакапить core-функциональность
- соседняя команда тоже хочет "всё и сразу"
Хочу проговорить про работу с дедлайнами. Формулировка "сделать задачу за спринт" и "чтобы в этом спринте оказалось в проде" - это две разных формулировки и два разных дедлайна. Если загрузки много, важно "на берегу" с менеджерами проговорить ожидания поставки в прод, прикинуть когда и что надо сделать, заложить время на риски и идти по этому плану. Например, после такого анализа выяснилось, что одну важную задачу хорошо бы начать делать прямо сегодня, а доделать край среда-четверг (с учетом тестирования, ревью и тд) чтобы уложиться.
Дальше смотрим на реальную загрузку и своевременно подсвечиваем риски. Да, если два менеджера хотят свои задачи как можно быстрее, а я понимаю, что это нереально без переработок, то надо так и сказать. Некоторые начинающие разработчики боятся говорить "нет": "Ну руководитель же сказал, надо сделать. Значит, надо сделать. Буду ночами не спать". А потом люди всё равно не успевают, да еще и выгорают. А если вовремя подсветить, можно было передоговориться и изменить ожидания.
Забавно еще держать в голове, что на дейлике каждой команды надо будет рассказывать о прогрессе, поэтому у меня бывает 2-3 параллельные задачи в работе (пока собирается, тестируется, ревьются - занимаюсь другой), чтобы было что рассказать 😁
