Время чтения:
3 мин.Время чтения:
3 мин.Сегодня поговорили с тимлидом IQ Dev Настей Обливанцевой о том, какие рекомендации она может дать коллегам с «той стороны».
Первая и главная ремарка — нет никакой «той стороны». Мы на одной стороне и цель у нас одна: выкатить новый релиз, mvp, исправить баг и тд. Когда приступаем к проекту — наша задача стать командой, где каждый участник четко отвечает за свои задачи, но видит как эти задачи отражаются на коллегах и к чему его работа приведет.
Иногда в задаче описан один функционал, но в процессе работы появляются доп. требования и задача удлиняется по времени и объему работ. Часто релиз отодвигает устранение багов, которые в первой итерации не заявлены от QA. Задачу по ТЗ полностью выполнили, но после тестирования выявлены доп. баги, которые не были заявлены, оперативно устранили и выкатили релиз.
Изучение проекта, логики работы того или иного функционала, погружение в пользовательский опыт, поведение системы, чтение кода — это требует времени. Да, мы быстро интегрируемся в проекты, т.к. четко знаем какую информацию запрашивать и даже можем порекомендовать бизнесу провести дополнительную аналитику. Но так было не всегда, IQ Dev пришли к этому за 5 лет и большое количество реализованных проектов в разных сферах бизнеса от e-commerce, fintech, страхования до гос.сектора и т.д. Что важно: так происходит не везде, поэтому PM крайне важно с тимлидом оговорить сроки на изучение задач или проекта.
Сколько бы не было написано статей о том, как грамотно составить ТЗ разработчику — все равно часто сталкиваешься с ТЗ в 2 строчки, из которых не понятно, какие задачи должна решить команда разработки. Также важно видеть в ТЗ ради чего, собственно, все затевалось. Видя, что бизнес в итоге хочет, тимлид может предложить вариант адаптивнее или быстрее. У меня была ситуация, когда на проекте аналитик описал логику, при которой контент-менеджеру вручную пришлось бы вносить большое количество информации. Но мы, зная детали проекта, предложили альтернативный путь, при котором физически ничего вносить не нужно было, вся инфа автоматически подтягивалась и давала контентщику возможность выбрать нужные блоки из предложенного списка.
Важно отразить в ТЗ хотя бы эти требования к задаче:
Иногда представители бизнеса считают, что PM должен знать досконально задачи разработки, чтобы четко их контролировать. Контролировать — однозначно нужно. Знать досконально — вряд ли. По статусам задач тимлид отчитывается на заранее согласованных митапах. Кроме того, при работе мы стараемся запараллелить задачи, чтобы сократить время до окончательного релиза, и погружаться в каждую деталь и подзадачу у PM не хватит ни времени, ни терпения. Да и зачем? Тимлид на то и нужен, чтобы организовать грамотный процесс работы разработки.
Впереди выходные, и да, мы подготовимся по максимуму, но если вдруг что-то «вылезет» за выходные — подключимся и решим, но не факт, что «здесь и сейчас» (разработчики тоже иногда отдыхают), а для бизнеса это будут дополнительные затраты. Бывали ситуации, когда команда выкатывала релиз в пятницу по настоятельной просьбе заказчика, но сразу же закладывали затраты на дежурство. В этой ситуации тимлид сидел у компьютера в выходные и был на связи с PM, чтобы оперативно поправить баги. Идеальный вариант релизиться в среду-четверг. За пятницу есть возможность отладить, протестировать, убедиться, что сайт работает и спокойно уйти на выходные.
Когда работаем только командой IQ Dev подобных вопросов не возникает от слова «совсем», но также часто мы интегрируемся и в существующие команды заказчика и вот тут нужно четко согласовать любые изменения.
Вносить правки на боевом сервере — это в принципе чревато, но если разработчик заказчика внес любые, незначительные на его взгляд, изменения на боевом сайте, то при новом релизе:
Если правка уж очень необходима здесь и сейчас, то выходом будет отдать ее разработчику, который готовит новый релиз, он выполнит задачу в рамках workflow проекта. Так при новом релизе никто ничего не потеряет и, что важнее, не сломает.
Конечно, здесь собраны далеко не все советы, т.к. любой проект уникален, как и любой PM и тимлид, но я постаралась охватить базовые вещи, которые важны на любом проекте без исключения. Какой бы ни была задача, главное помнить, что цель тимлида на аутстафе — стать частью команды заказчика, подобрать hard и soft skills разработчиков под задачи и организовать работу так, чтобы задачи бизнеса были решены в заданные сроки.