Сегодня поговорили с тимлидом IQ Dev Настей Обливанцевой о том, какие рекомендации она может дать коллегам с «той стороны».

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

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

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

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

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

Гайд “Как организовать разработку IT продукта с привлечением внешней команды”

Получить гайд

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

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

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

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

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

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

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

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

Боевой сервер доступен только тимлиду — это «хороший тон»

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

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

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

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

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