«Уже два года не срываю сроки проектов» — как мне это удалось

В самом начале я думал, что буду просто ставить задачи, следить за временем, общаться с заказчиком — а проекты будут завершаться в срок. Я был слишком наивен. Поэтому стал искать решения проблемы. И нашел. Последние два года в Alto не срываю сроки проектов (но это не точно). Для экономии времени на чтение расскажу только о том, что помогло.

Содержание статьи:

1. Разбиваю большое и сложное на простые части
2. Составляю план-график + делюсь шаблоном
   
3. Назначаю еженедельные встречи
   
4. Изолирую блоки задач друг от друга
   
5. Назначаю технические встречи с командой
   
6. Подготавливаю техническую документацию
   
7. Не превращаю приемку в тестирование
   

Разделение целого на части я называю «декомпозицией». Этим методом пользуется каждый человек в работе или в личной жизни. Единственный способ улучшить навык декомпозиции — это постоянная практика. Разбивайте большие задачи на маленькие. Чем чаще будете применять декомпозицию, тем быстрее научитесь.

Учиться можно на любых проектах. Покажу как я декомпозирую проекты в отрасли разработки информационных систем на 1С-Битрикс / Laravel / React.

Проект всегда начинается со сбора бизнес требований и аналитики вместе с Tech Lead. Сюда относится все, что касается логики работы — как должен работать веб-сервис, какие будут функции. Чем больше требований соберете, тем меньше вопросов и споров у вас появится на проекте.

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

Как я поступал раньше: резал проект на крупные блоки, эти блоки — на экраны, а экраны — на элементы.

Как я делаю сейчас: разбиваю проект на этапы, эти этапы — на задачи, понятные заказчику. Затем декомпозирую их на задачи для разработчика.

1 уровень. Этапы разработки.

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

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

2 уровень. Уровень заказчика.

Этапы разработки можно разбить на более мелкие сущности. Например, этап «оформление заказа» делим на проектирование скелета приложения, интеграции с внешними сервисами (dadata, мтс-маркетолог), получение предварительной стоимости заказа и т.д.

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

3 уровень. Уровень разработчика.

Теперь задачи с языка бизнес-требований нужно перевести на язык функциональных требований. Например, задачу по получению предварительной стоимости заказа разбиваем на подзадачи:

• написать endpoint приема данных с формы заказа;
• проработать валидацию входящих данных из формы заказа;
• написать класс расчета предварительной стоимости заказа, покрыть тестами;
• в frontend интегрировать endpoint расчета предварительной стоимости заказа.

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

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

План-график не будет работать, если его составить только один раз. Его нужно пересматривать на протяжении всего проекта. Это единственный способ получить контроль над проектом.

Минимум того, что стоит отразить в плане:

• Название задачи. Без понятных названий запутаетесь. Просто добавьте, так удобнее.
• Ссылка на карточку с задачей. Получите быстрый доступ к задаче – сильно экономит время.
• Статус задачи, дата начала и конца. Подскажет вам состояние задачи, освободит от лишних вопросов.

Либо просто скачайте мой шаблон по этой ссылке. План-график.xlsx (18 КБ)

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

Результат каждой встречи фиксирую в чате с заказчиком. Это помогает через 3 месяца вспомнить договоренности.

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

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

• Блок можно принять и проверить целиком — не зависит от не реализованного функционала.
• Результат понятен заказчику, его можно проверить без технических навыков. Но и здесь есть исключения. Например, разработка API.

У нас есть технические встречи, где Tech Lead помогает выбирать решения, а PM объясняет бизнес-логику конкретных узлов функционала. Без технических встреч задачи зависают и откладываются.

Мой план-минимум на встречу:

• Команда понимает, какой конечный результат ожидает получить заказчик в рамках этапа;
• Есть перечень вопросов, которые вы собираетесь обсуждать;
• Встреча не должна занимать больше 30 минут;
• Все результаты фиксируем в карточках задач или в чате проекта.

Еще заметил, что без документации время разработчика, QA-инженера увеличивается в 5-10 раз. Поэтому, я убежден, что проект должен быть задокументирован. Это значит, что у каждой задачи есть :

1. Описание бизнес-логики и ожидаемого результата.

2. Техническое описание разработчика, который реализовал задачу. Оно может быть задокументировано в Swagger или в карточке задачи. При условии, что речь не про endpoint.

3. Описание тест-кейсов, содержащее понятные и воспроизводимые результаты.

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

Поэтому количество доработок, их стоимость закладываю на этапе планирования. Обычно хватает 1-3 итерации. Главное не забыть внести соответствующие пункты в договор.

Как в идеале должна выглядеть приемка:

1. PM передает проект заказчику на проверку;
2. Заказчик в течении нескольких дней собирает правки;
3. Разработчик вносит правки на сайт;
4. PM следит, чтобы правки вносились в рамках одной итерации;
5. PM представляет заказчику обновленную версию и собирает обратную связь.

Трудности возникают, когда клиент выходит за рамки договора. Это происходит, когда заказчик считает багами то, что на самом деле ими не является. Именно поэтому проговариваю все ограничения перед началом проекта. Если нужна верстка пиксель в пиксель – закладываю риски и стоимость в договоре. Это спасает меня от замечаний, вроде: «а почему тут 16, а не 18 пикселей? На макете же иначе».