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

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

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

Роман Тетерин — Project Manager компании Alto. Знает, как сделать продукт для бизнеса. Если Рому закинуть на проект, он обязательно найдет способ распределить ресурсы и выполнить план в срок.

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

Разбиваю большое и сложное на простые части

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

Учиться можно на любых проектах. Покажу как я декомпозирую проекты в отрасли разработки информационных систем на 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.

Пример документа в Swagger
Пример документа в Swagger

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

Пример текст-кейса на секретном проекте
Пример текст-кейса на секретном проекте

Не превращаю приемку в тестирование

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

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

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

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

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

Все написанное в статье проверено лично мной на реальных проектах. Свой канал я пока не веду, но если вам было полезно, подписывайтесь на ТГ-канал → Иван про digital проекты, где руководитель Alto рассказывает о проектном управлении в компании.

6767
28 комментариев

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

7
Ответить

Правила хорошо работают в реальности, если их соблюдать. Часто «практики» превращают их в SCRAM, НО... Где но — что угодно: решили что-то выкинуть, адаптировав правила и методики под себя.

По проекту нужно проводить ретро. В 95% случаев ретро показывает, что правила были нарушены.

8
Ответить

пробежался по статье, после вашего комента. Все применимо на практике.

2
Ответить

А давайте соберём статистику сколько нас ПМов Ивановых В.

2
Ответить

А какие в практике не работают?

1
Ответить

Влад, я тоже встречался с таким. Но причины этого были понятны. На каком-либо из этапов цепи: Постановка задачи - Работа - Контроль - управляющее воздействие происходит потеря воли. Это я наблюдал даже при работе в достаточно известной британской компании со всеми их PMI, KPI и прочим. Воля терялась в основном на последних двух. Я знаю Ивана (как я понял, Роман работает в компании Ивана), он человек дисциплинированный, скорее всего, поэтому он не пишет об этом главном компоненте, ибо он для него сам собой разумеется. И именно поэтому я верю, что у него это работает. У меня внутри той компании тоже получился проект по похожему принципу, но я там наступил на все свои мозоли и съел всех лягушек, ибо не очень дисциплинирован, но мне очень хотелось довести на практике проектное управление до логического понятного результата. Тут скорее дело в другом - мы все время ищем какую-то универсальную таблетку (секретную систему секретного Мастера), при которой, следуя строго написанному, должен получится результат без усилий. По мне так любая система работает, при условии, что ее воспринимают не как костыль, а как объект приложения именно воли. Ну в самом деле, если совсем себя не держать в руках, диета какого Мастера может помочь?

1
Ответить

Я всегда срываю сроки, так как могу!

5
Ответить