{"id":14255,"url":"\/distributions\/14255\/click?bit=1&hash=285b001e00cf7484224a6ff681b6d172d7d7337a0afbdd4342d725cf62cb249b","title":"\u0411\u044b\u043b\u0438 \u0432 \u0434\u0435\u0441\u044f\u0442\u043a\u0430\u0445 \u043e\u0442\u0435\u043b\u0435\u0439, \u043d\u043e \u043d\u0438 \u043e\u0434\u0438\u043d \u043d\u0435 \u0432\u043f\u0435\u0447\u0430\u0442\u043b\u0438\u043b?","buttonText":"\u0427\u0442\u043e \u0434\u0435\u043b\u0430\u0442\u044c","imageUuid":"4c6db631-4d4c-530c-9750-cf992e251f9d"}

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

В самом начале я думал, что буду просто ставить задачи, следить за временем, общаться с заказчиком — а проекты будут завершаться в срок. Я был слишком наивен. Поэтому стал искать решения проблемы. И нашел. Последние два года в 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

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

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

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

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

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

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

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

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

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

0
27 комментариев
Написать комментарий...
Влад Иванов

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

Ответить
Развернуть ветку
Иван Ярославцев
Автор

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

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

Ответить
Развернуть ветку
Петр Любицин

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

Ответить
Развернуть ветку
Саша Антипов

Как по мне, рабочая схема, автору спасибо за повторение мать учения.

Ответить
Развернуть ветку
Слава Григорьев

я запутался, одни говорят, что это применимо, другие что нет. Кто прав?

Ответить
Развернуть ветку
Саша Антипов

Тот кто берёт и что-то делает, тот кто ничего не делает, всегда будет говорить что это всё не то!

Ответить
Развернуть ветку
Виктор Лешков

Все правы. И то и то видел в реализации. Зависит от отношения и целесообразности. Вы задаете вопрос про сразу 2 группы: 1. Кому нужно 2. Кому не нужно (модно, "так все делают" и т.п.), мне потребовалось примерно 30 лет, чтобы понять, что я - не выдающийся руководитель, именно поэтому мне всегда было неуютно на руководящих местах и результаты не звездные получались (единственное, что вот с коллективом всегда клеилось на 5). Но ведь "быть начальником" - единственно правильное устремление ;)
Оказывается, я очень хороший и нужный специалист, который нужен всем. После осознания сего, начали искать уже меня.
Вывод: начальником мне не очень хотелось быть, отсюда и результаты.

Ответить
Развернуть ветку
Apex Shootnik

Вы с товарищем выше из одной секты охотников на уток?

Ответить
Развернуть ветку
Vitaliy Ivanov

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

Ответить
Развернуть ветку
Макс Симченко

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

Ответить
Развернуть ветку
Виктор Лешков

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

Ответить
Развернуть ветку
Alex Gunt

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

Ответить
Развернуть ветку
Макс Симченко

Вы приняты

Ответить
Развернуть ветку
Владислав Шадрин

Хорошая статья, благодарю!

Считаю, что комментарии вида "на практике не работает" и "это база, все и так знают" вызваны непониманием основного посыла.
Роман нигде не пишет, что это какой-то инновационный и универсальный материал. Напротив, чётко указывает: "что МНЕ помогло", "как МНЕ удалось".

То есть статья о личном профессиональном опыте нашего коллеги. И опыт этот — качественный.
А применить на практике можно всё, вопрос лишь в том: будет ли это уместно для конкретной компании/проекта/ситуации.

В самой статье заметил пару моментов:
1. Изображение "Тест-кейс одного из проектов". Везде убрали ссылки, но пропустили во втором кейсе, в "Последовательность действий". Не подсвечена, поэтому можно было не заметить.
2. Мне кажется, что пример в изображении "Описание бизнес-логики на одном из проектов" - не самый удачный для статьи, в которой очень большое внимание уделяется декомпозиции. Тут же в "Что нужно сделать" объём логики потянет на пару-тройку отдельных подзадач. Мне кажется, задачу стоит декомпозировать :)

Ответить
Развернуть ветку
Роман Тетерин

Коммент принят)

1. Думали успеем убрать быстрее, чем кто-то заметит, уже пофиксили :)
2. Изначально так и хотели, но исполнитель настоял, чтобы описание всего процесса было в одной задаче. Обычно стараемся не делать задачу больше 1 рабочего дня (6-8 часов), но бывают исключения. Конкретно в этом кейсе принял аргументы лида и не стал разбивать задачу.

Ответить
Развернуть ветку
Тимон

не волшебная таблетка конечно, но по фактам раскидано

Ответить
Развернуть ветку
Ольга Васильева

все очень красиво написано, но вот есть одно но, на практике это не всегда работает

Ответить
Развернуть ветку
Sano

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

Ответить
Развернуть ветку
Иван Ярославцев
Автор

Будет классно, если конкретизируете, что именно не работает?

Ответить
Развернуть ветку
Виктор Лешков

Давно не писал видимо - мысль не донес. Представим человека, который хочет похудеть и хочет машину. Машина у него появится через неделю, а что похудеет - не факт. Ибо покупка машины мобилизует волю (любую) и удерживает ее в тонусе до выезда из автосалона. А похудение требует постоянного преодоления без очевидных гарантий комфортного будущего.
Так же и с любой системой - если необходимость ее применения осознанна, система будет работать. Если это дань моде, рецепт как достичь результата не напрягаясь, либо цель применения размыта - не сработает.
Это я как бы от себя говорю, что верю, что у тебя это работает, хотя не все уверены в этом и утверждаю, что и в моем случае проектный подход работал. Я могу понять, почему в это верят не все. Зачастую пытаемся решить производственные задачи, а задачи по самодисциплине и умении видеть цель решать не пытаемся. Т.е. как бы подразумевается, что мы дисциплинированны и точно знаем зачем нам это. Вот так и случаются холивары вокруг работоспособности систем управления, хотя по мне так даже предмета спора нет. Бывает, что дома прибрать не можем нормально - какая уж там проектная работа!

Ответить
Развернуть ветку
Иван Ярославцев
Автор

Глубоко, соглашусь, спасибо тебе за мысль

Ответить
Развернуть ветку
Виктор Лешков

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

Ответить
Развернуть ветку
Иван Ярославцев
Автор

напишем:)

Ответить
Развернуть ветку
Юлия Дорофеева

подскажите, а сколько проектов ведете одновременно?

Ответить
Развернуть ветку
Роман Тетерин

Сложно ответить в абсолютных значениях, зависит от объема проектов. Если это объемные проекты, на которых требуется активное участие ПМа, то больше то больше 3х таких проектов вести не получится. Если проекты в формате технической поддержки с небольшим бэклогом задач, то при 5-8 проектах получается доставлять задачи быстро и оставлять всех клиентов довольными.

Ответить
Развернуть ветку
Виктор Лешков

Я тут пописал в комментариях в виде ответов, но разрешите привести бытовой пример, как я вижу причины работы/не работы любой системы и места волевого усилия в этом вопросе.
Давайте распишем по действиям какое их количество совершается при скажем, покупке машины в кредит. Думаю, если детально, насчитаем минимум 20, 5 из которых окажутся весьма энергетически затратными. Кроме того, требуется определенный ресурс времени. И это не 1 час. В общем, проект этак на недельку.
У всех "лентяев", которых я знаю, есть автомобили. Результат налицо независимо от сложности и наличия времени.

Ответить
Развернуть ветку
Иван Ярославцев
Автор

ты к тому, что машина не экономит время по факту?

Ответить
Развернуть ветку
24 комментария
Раскрывать всегда