{"id":13465,"url":"\/distributions\/13465\/click?bit=1&hash=1e6228dc4e5e22730d5108e1c30ee96b3462205737e7a3fe7ce4c965aaacfe57","title":"\u041a\u043e\u043d\u0444\u0435\u0440\u0435\u043d\u0446\u0438\u044f Ozon \u2014 \u043a\u043e\u043c\u0443, \u0447\u0442\u043e \u0438 \u043a\u0430\u043a \u043f\u0440\u043e\u0434\u0430\u0432\u0430\u0442\u044c \u0432 \u043a\u0440\u0438\u0437\u0438\u0441","buttonText":"\u0423\u0437\u043d\u0430\u0442\u044c","imageUuid":"6b1e0c55-41d3-56c2-84e2-fe6f447e3825","isPaidAndBannersEnabled":false}
IQ DEV

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

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

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

Закладывать время на риски и тестирование задач

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

Закладывать время на погружение в задачу/проект

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

Не жалеть времени на ТЗ

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

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

  1. Цель
  2. Что планируется в логической структуре
  3. Описание поведение системы и пользовательские сценарии
  4. Функциональные требования (откуда берутся данные, будут ли новые сущности и тд )
  5. AS IS (что было) и TO BE (что мы ожидаем)

PM должен знать базовые статусы по задачам, но не детально

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

Не ставить сроки релиза на пятницу

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

Боевой сервер доступен только тимлиду - это “хороший тон”

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

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

  1. Эти изменения могут не сохраниться
  2. Изменения повлияют на релиз

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

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

0
Комментарии
Читать все 0 комментариев
null