6 советов проджект-менеджеру от тимлида

Сегодня поговорили с нашим тимлидом Настей Обливанцевой о том какие рекомендации она может дать коллегам “с той стороны”.

Первая и главная ремарка - нет никакой “той стороны” Мы на одной стороне и цель у нас одна: выкатить новый релиз, mvp, исправить баг и тд. Когда приступаем к проекту – наша задача стать командой, где каждый участник четко отвечает за свои задачи, но видит как эти задачи отражаются на коллегах и к чему его работа приведет.

Иногда в задаче описан один функционал, но в процессе работы появляются доп. требования и задача удлиняется по времени и объему работ. Часто релиз отодвигает устранение багов, которые в первой итерации не заявлены от QA. Задачу по ТЗ полностью выполнили, но после тестирования выявлены доп. баги, которые не были заявлены, оперативно устранили и выкатили релиз.

Изучение проекта, логики работы того или иного функционала, погружение в пользовательский опыт, поведение системы, чтение кода - это требует времени. Да, мы быстро интегрируемся в проекты, тк четко знаем какую информацию запрашивать и даже можем порекомендовать бизнесу провести дополнительную аналитику. Но так было не всегда, IQ Dev пришли к этому за 5 лет и большое количество реализованных проектов в разных сферах бизнеса от e-commerce, fintech, страхования до гос.сектора и тд. Что важно: так происходит не везде, поэтому PM крайне важно с тимлидом оговорить сроки на изучение задач или проекта.

Сколько бы не было написано статей о том как грамотно составить ТЗ разработчику - все равно часто сталкиваешься с ТЗ в 2 строчки, из которых не понятно какие задачи должна решить команда разработки. Также важно видеть в ТЗ ради чего, собственно, все затевалось. Видя что бизнес в итоге хочет, тимлид может предложить вариант адаптивнее или быстрее. У меня была ситуация, когда на проекте аналитик описал логику, при которой контент-менеджеру вручную пришлось бы вносить большое количество информации. Но мы, зная детали проекта, предложили альтернативный путь, при котором физически ничего вносить не нужно было, вся инфа автоматически подтягивалась и давала контентщику возможность выбрать нужные блоки из предложенного списка.

Важно отразить в ТЗ хотя бы эти требования к задаче:

Иногда представители бизнеса считают, что PM должен знать досконально задачи разработки, чтобы четко их контролировать. Контролировать - однозначно нужно. Знать досконально - вряд ли. По статусам задач тимлид отчитывается на заранее согласованных митапах. Кроме того, при работе мы стараемся запараллелить задачи, чтобы сократить время до окончательного релиза, и погружаться в каждую деталь и подзадачу у PM не хватит ни времени, ни терпения. Да и зачем? Тимлид на то и нужен, чтобы организовать грамотный процесс работы разработки.

Впереди выходные, и да, мы подготовимся по максимуму, но если вдруг что-то “вылезет” за выходные - подключимся и решим, но не факт, что “здесь и сейчас” (разработчики тоже иногда отдыхают), а для бизнеса это будут дополнительные затраты. Бывали ситуации, когда команда выкатывала релиз в пятницу по настоятельной просьбе заказчика, но сразу же закладывали затраты на дежурство. В этой ситуации тимлид сидел у компьютера в выходные и был на связи с PM, чтобы оперативно поправить баги. Идеальный вариант релизиться в среду-четверг. За пятницу есть возможность отладить, протестировать, убедиться, что сайт работает и спокойно уйти на выходные.

Когда работаем только командой IQ Dev подобных вопросов не возникает от слова "совсем", но также часто мы интегрируемся и в существующие команды заказчика и вот тут нужно четко согласовать любые изменения. Вносить правки на боевом сервере - это в принципе чревато, но если разработчик заказчика внес любые, незначительные на его взгляд, изменения на боевом сайте, то при новом релизе:

Вносить правки на боевом сервере - это в принципе чревато, но если разработчик заказчика внес любые, незначительные на его взгляд, изменения на боевом сайте, то при новом релизе:

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

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