Как поставить реалистичный дедлайн и не сорвать его

Дедлайн похож на гильотину для руководителя проекта, его команды и клиента. Менеджеры компании Лайв Тайпинг захотели поделиться с коллегами опытом, который помогает им сохранить головы на месте.

Итак, что нужно сделать, чтобы не сорвать дедлайн.

Посмотреть, что за люди рядом с тобой

Люди отличаются характерами, а проекты — сложностью идеи и бюджетом. Менеджеру нужно учесть эти вещи, когда он будет мотивировать членов команды. А мотивация нужна почти всем.

Условно сотрудники студии делятся на спокойно решающих задачи, беспокойных и эмпатичных. Первому типу и говорить ничего не нужно — они просто работают и не ставят в прямую зависимость друг от друга свою работоспособность и сложность проекта. Коллеги второго типа требуют большего внимания к себе: кому-то помогает жёсткий контроль, кому-то — слова, внушающие, что на проекте всё в порядке и можно работать спокойно. Третьи лучше вовлекаются в проект, когда во всех деталях раскрываешь перед ним задачу.

Хорошо, если вы уже знаете способности члена команды. А если нет? Тогда придётся перепробовать несколько подходов в поиске нужного.

«Я работала с одним разработчиком, который переоценивал свои силы в два раза. То есть я умножала его оценку на два и получала более-менее верную дату окончания задачи. Люди часто слишком уверены в себе».

— Любовь Тимошенко, менеджер проектов Лайв Тайпинг (Security Pulse)

Но на одной мотивации не уедешь: важен опыт. Разные члены команды с разной скоростью решают одну и ту же задачу. Поэтому распределять задачи нужно в соответствии с коэффициентом производительности сотрудника. Чем быстрее он справляется с задачей, тем выше его коэффициент.

Логично, что нанятый вчера джуниор не может работать так же, как мидл. Значит, чтобы получить быстрый результат, ему лучше давать что-то простое. Но мы заинтересованы в развитии начинающих разработчиков, и им порой нужны сложные задачи. Скорость их решения — это риск, который менеджер берёт на себя.

Учтите человеческий фактор, иначе план работ останется идеальным только на бумаге.

Понимать задачу

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

О чём речь?

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

Гипотетическая ситуация. Разработчик делает задачу по регистрации. На макетах есть поля для имени, пароля и имейла. В рамках задачи нужно настроить валидацию полей. Разработчик подозревает, что клиенту важно настоящее имя. Значит, надо найти где-нибудь базу имен и подключить ее к полю, чтобы поле отвечало ошибкой на разного рода бред. Если пользователь случайно напишет имя латиницей, должен быть плагин, который переводит латиницу на кириллицу и потом сравнивает. И так далее, и так далее. А на самом деле клиенту не важно, что именно напишет пользователь в поле для имени. Важнее, чтобы в письме к пользователю с ним можно было поздороваться. В результате время будет потрачено впустую и на горизонте замаячит выход за сроки.

Сама по себе супергибкая система — это не плохо. Плохо, когда она не нужна, но время на неё потрачено.

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

— Владислав Сиренко, менеджер проектов Лайв Тайпинг (RocketGo, ВсеПлатежи)

Сейчас коммуникация в командах Лайв Тайпинг отлажена настолько хорошо, что подобные случаи даже сложно вспомнить. Но бывают мелочи, обсуловленные тем, что менеджер не может держать в голове всё.

«Есть ребята, которые постоянно работают на одном проекте. Время от времени я присоединяюсь к ним, и менеджер неосознанно — я думаю — подразумевает, что я в курсе всех событий. Недавно я потратил два часа на то, чтобы понять, почему мне приходит неверный ответ от сервера. Оказалось, что поменялась версия API, а менеджер забыл об этом упомянуть, думая, что мне всё известно. Два часа я потратил просто так».

— Павел Разуваев, iOS-разработчик, менеджер проекта Yodel

Местом, где фиксируются чёткие цели, является ТЗ и карточка задачи в таск-менеджере. Пропишите их, и команда будет искать самые простые решения и быстрее выполнять задачи.

Наладить процессы

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

Каждая задача занимает своё время: одна три часа, другая — тридцать. Оценка даётся членом команды. На проектировочном митинге все получают задачи от менеджера. Если вы работаете по Scrum, то предположим, что ваш спринт — сорокачасовая рабочая неделя. Этот спринт забивается задачами. Учтём, что у вашего коллеги будут свои митинги, и добавим задач, скажем, на 30 часов вместо 40. Это основа нормального, подконтрольного процесса.

Сверяться с планами нужно на регулярных митингах. Если на одном из них становится понятно, что кто-то выбивается из собой же поставленных сроков, нужно искать причины. Они могут быть разовыми или систематическими, зависящими от нас и независящими. Отключение интернета на весь день, страсть разработчика к слишком оптимистичным оценкам или его болезнь — это разные вещи, и меры должны приниматься разные.

Один из универсальных способов не сорвать сроки — найти задачу и применить к ней такие решения, которые помогут выполнить её быстрее и тем самым выровнять поехавший срок. Коротко это называется флексом. Это может быть, например, отказ от кастомного дизайна — ведь он создаётся дольше, потому что не опирается на практичные и экономящие время дизайнеров и разработчиков гайдлайны Apple и Google или UI-библиотеки. Решение есть, и дело за малым: убедить клиента, что сделать стандартный дизайн сейчас — это вполне себе рабочий вариант, который способствует тому, чтобы вовремя сдать адекватную работу.

Снизить вероятность неправильно оценить задачи и упростить контроль за ними помогает декомпозиция — разбиение больших задач на более маленькие. Скажем, регистрация — большая задача с первоначальной оценкой в 40 часов. Но с декомпозицией выяснится, что регистрация, как матрёшка, умещает в себе другие задачи, и их не 10 по 4 часа каждая, а 15, и неделя превратится в полторы. Пропустив мелочи при первичной и вторичной оценке, не удивляйтесь полетевшим срокам.

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

Предвидеть риски

Какими бывают риски? Менеджеры Лайв Тайпинг разбили их на две группы: внешние и внутренние. Риски из первой группы не зависят от команды разработки: бэкенд делает другая команда, меняются требования к продукту, клиент что-то должен предоставить, но задерживается — команда не отвечает за это. Риски из второй группы зависят от команды: разработчики заняты на других проектах, меняется команда или продукт доводится до приемлемого уровня.

От таких вещей нужно страховаться: разбивать большое и сложное на мелкое и простое, запросить у клиента заранее то, что потребуется команде для решения задачи (актуальную документацию к API, тексты, пользовательские соглашения, фотографии, логотипы) и просто слушать, слышать, говорить и разговаривать. Кстати, в своей статье на Хабре наш экс-менеджер Ирина Мещерякова даёт 11 советов для эффективного общения с клиентом и командой.

Когда задача становится проблемой, нужно инициировать разговор с клиентом и командой и принять решение. Вариантов четыре:

• делать, как делается, и кровь из носу уложиться вовремя. В таком случае страдает команда;
• призвать кого-то на помощь. В таком случае страдает бюджет;
• упростить. Решение подходит от случая к случаю;
• не делать. Такие задачи тоже бывают. Их можно не делать вообще или в ближайшую неделю. Часто они завязаны на участии клиента, но если клиент не доступен, то что тут поделаешь. У одного из наших менеджеров даже есть тэг wait в YouTrack: им помечаются задачи, от решения которых не зависит основной поток задач и которые могут подождать. Использовать такой вариант нужно аккуратно, чтобы не пострадал продукт.

Перезаложиться

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

Ждать следующих статей

Мы разобрались, как не допустить провала дедлайна. Но что, если дело к этому идёт? Или, что ещё хуже, вы уже вышли за сроки? Тема оказалась большой и интересной, и мы продолжим раскрывать её в других публикациях.