Как воплотить идеи в жизнь, не нарушая график и бюджет

Я работаю в аутсорсинговой компании техническим директором. К нам обращаются клиенты чтобы получить готовую систему по исходному описанию: от концепта на 1-2 страницах или одной схеме в Miro и до ТЗ на 100500 страницах с макетами в фигма. При этом клиенты ждут от нас КП с указанием цены и сроков реализации. Стоимость получается из трудочасов путем умножения на ставку задействованных специалистов. В этом месте возникает необходимость сделать оценку проекта по часам, разбить на роли и оценить срок реализации. В этом материале я хочу рассказать о том, как мы научились в 78% случаев укладывается в исходные оценки и в 100% случаев в моменте видеть, когда мы отклоняемся.

Многие технические специалисты считают, что:

Я тоже разделяю эти взгляды и поэтому не буду утверждать, что мы научились безошибочно оценивать. Но расскажу о том как мы управляем проектами в условиях строгих ограничений (по времени и трудоемкости) и высокой неопределенности (по конечному результату).

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

Отдельно отмечу, что при реализации проекта мы преследуем следующие цели:

1. клиент по завершению проекта получает именно то, что ему нужно;

2. не нагружаем клиента проблемами необходимости пересмотра бюджета или сроков реализации;

3. в любое время и нам, и клиенту понятна стадия готовности системы в целом и ее отдельных компонентов;

4. команда работает планово, без авралов.

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

Наша компания любит использовать GitHub как удобный и простой инструмент “все в одном” для управления задачами (issues), кодом, сборкой и развертывания решения. Когда мы были начинающими шахматистами, то следили только за временем: наладили интеграцию GitHub и Everhour. В результате каждый разработчик отмечал сколько часов он потратил на ту или иную Issue, а Project Manager (далее PM) следил за тем, чтоб все время было отмечено. По ходу реализации проекта мы видели как расходуется бюджет, но плохо понимали успеваем все доделать в соответствии с договоренностями или нет. Иногда выигрывали, иногда проигрывали. Не хватало управляемости ситуацией.

После нескольких посмертных ретроспектив на тему “что пошло не так и когда свернули не туда?” мы пришли к выводу, что контроль попадания в исходные оценки необходимо осуществлять постоянно по ходу проекта. Он должен быть максимально точным, наглядным и понятным для всей команды.

Оттолкнувшись от целей мы сформировали критерии успешности для команды. Команда молодец если:

Для контроля хода проекта и принятия управленческих решений мы разработали регламент ведения проекта для PM, тимлидов и разработчиков, а также создали инструмент поверх Github и Everhour, который назвали “Отчет по эпикам”.

На первом этапе реализации проекта мы составляем исходную стратегию на шахматную партию: PM разбивает всю продолжительность проекта на итерации (в терминах githab - milestone) и для каждой итерации прописывает, какие результаты команда должна реализовать по ее окончанию. Каждый результат - это Issue с меткой epic. Тимлиды, участвующие в проекте, проверяют данный план на достижимость и непротиворечивость зависимостям (понимая зависимости одних работ от других). Тимлиды включают в план поставки технические результаты, которые явно не демонстрируются клиенту, но необходимы для дальнейшего движения команды. Тимлиды проставляют оценки на все заведенные эпики так, чтобы их сумма не превышала исходную оценку (обычно оставляем резерв на непредвиденные расходы в 10% от всего объема - “хороший PM всегда не доливает”).

После создания плана в Github PM проверяет его в инструменте “Отчет по эпикам” на соблюдение следующих правил:

Пример фрагмента отчета, прошедшего сверку:

По итогам создания эпиков получается примерно такой план:

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

Пример эпика, который имеет четыре подзадачи:

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

В любой момент времени мы готовы ответить на вопрос, насколько проект реализован:

В заключении тезисно обо всем вышесказанном:

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