«Уже два года не срываю сроки проектов» — как мне это удалось
В самом начале я думал, что буду просто ставить задачи, следить за временем, общаться с заказчиком — а проекты будут завершаться в срок. Я был слишком наивен. Поэтому стал искать решения проблемы. И нашел. Последние два года в 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.
3. Описание тест-кейсов, содержащее понятные и воспроизводимые результаты.
Не превращаю приемку в тестирование
На этапе приемки сайта также есть риск не уложиться в сроки. Если заказчик присылает вам по одному багу, ждет исправления, после чего присылает следующий — так проект никогда не закончится.
Поэтому количество доработок, их стоимость закладываю на этапе планирования. Обычно хватает 1-3 итерации. Главное не забыть внести соответствующие пункты в договор.
Как в идеале должна выглядеть приемка:
- PM передает проект заказчику на проверку;
- Заказчик в течении нескольких дней собирает правки;
- Разработчик вносит правки на сайт;
- PM следит, чтобы правки вносились в рамках одной итерации;
- PM представляет заказчику обновленную версию и собирает обратную связь.
Трудности возникают, когда клиент выходит за рамки договора. Это происходит, когда заказчик считает багами то, что на самом деле ими не является. Именно поэтому проговариваю все ограничения перед началом проекта. Если нужна верстка пиксель в пиксель – закладываю риски и стоимость в договоре. Это спасает меня от замечаний, вроде: «а почему тут 16, а не 18 пикселей? На макете же иначе».
Я-то думал, что-то новенькое. Но, нет. Это я вам как практик говорю. 10 лет назад, когда начинал работал по точно таким же правилам. И, как обычно, они очень хорошо работают для большинства проектов в теории, но не в реальности.
Правила хорошо работают в реальности, если их соблюдать. Часто «практики» превращают их в SCRAM, НО... Где но — что угодно: решили что-то выкинуть, адаптировав правила и методики под себя.
По проекту нужно проводить ретро. В 95% случаев ретро показывает, что правила были нарушены.
пробежался по статье, после вашего комента. Все применимо на практике.
Как по мне, рабочая схема, автору спасибо за повторение мать учения.
я запутался, одни говорят, что это применимо, другие что нет. Кто прав?
Тот кто берёт и что-то делает, тот кто ничего не делает, всегда будет говорить что это всё не то!
Все правы. И то и то видел в реализации. Зависит от отношения и целесообразности. Вы задаете вопрос про сразу 2 группы: 1. Кому нужно 2. Кому не нужно (модно, "так все делают" и т.п.), мне потребовалось примерно 30 лет, чтобы понять, что я - не выдающийся руководитель, именно поэтому мне всегда было неуютно на руководящих местах и результаты не звездные получались (единственное, что вот с коллективом всегда клеилось на 5). Но ведь "быть начальником" - единственно правильное устремление ;)
Оказывается, я очень хороший и нужный специалист, который нужен всем. После осознания сего, начали искать уже меня.
Вывод: начальником мне не очень хотелось быть, отсюда и результаты.
Вы с товарищем выше из одной секты охотников на уток?
А давайте соберём статистику сколько нас ПМов Ивановых В.
А какие в практике не работают?
Влад, я тоже встречался с таким. Но причины этого были понятны. На каком-либо из этапов цепи: Постановка задачи - Работа - Контроль - управляющее воздействие происходит потеря воли. Это я наблюдал даже при работе в достаточно известной британской компании со всеми их PMI, KPI и прочим. Воля терялась в основном на последних двух. Я знаю Ивана (как я понял, Роман работает в компании Ивана), он человек дисциплинированный, скорее всего, поэтому он не пишет об этом главном компоненте, ибо он для него сам собой разумеется. И именно поэтому я верю, что у него это работает. У меня внутри той компании тоже получился проект по похожему принципу, но я там наступил на все свои мозоли и съел всех лягушек, ибо не очень дисциплинирован, но мне очень хотелось довести на практике проектное управление до логического понятного результата. Тут скорее дело в другом - мы все время ищем какую-то универсальную таблетку (секретную систему секретного Мастера), при которой, следуя строго написанному, должен получится результат без усилий. По мне так любая система работает, при условии, что ее воспринимают не как костыль, а как объект приложения именно воли. Ну в самом деле, если совсем себя не держать в руках, диета какого Мастера может помочь?
Я всегда срываю сроки, так как могу!
Вы приняты
Хорошая статья, благодарю!
Считаю, что комментарии вида "на практике не работает" и "это база, все и так знают" вызваны непониманием основного посыла.
Роман нигде не пишет, что это какой-то инновационный и универсальный материал. Напротив, чётко указывает: "что МНЕ помогло", "как МНЕ удалось".
То есть статья о личном профессиональном опыте нашего коллеги. И опыт этот — качественный.
А применить на практике можно всё, вопрос лишь в том: будет ли это уместно для конкретной компании/проекта/ситуации.
В самой статье заметил пару моментов:
1. Изображение "Тест-кейс одного из проектов". Везде убрали ссылки, но пропустили во втором кейсе, в "Последовательность действий". Не подсвечена, поэтому можно было не заметить.
2. Мне кажется, что пример в изображении "Описание бизнес-логики на одном из проектов" - не самый удачный для статьи, в которой очень большое внимание уделяется декомпозиции. Тут же в "Что нужно сделать" объём логики потянет на пару-тройку отдельных подзадач. Мне кажется, задачу стоит декомпозировать :)
Коммент принят)
1. Думали успеем убрать быстрее, чем кто-то заметит, уже пофиксили :)
2. Изначально так и хотели, но исполнитель настоял, чтобы описание всего процесса было в одной задаче. Обычно стараемся не делать задачу больше 1 рабочего дня (6-8 часов), но бывают исключения. Конкретно в этом кейсе принял аргументы лида и не стал разбивать задачу.
не волшебная таблетка конечно, но по фактам раскидано
все очень красиво написано, но вот есть одно но, на практике это не всегда работает
на практике это не работает если в команде нет людей, которые могут организовать процесс, объяснить каждому его роль, наладить результативное общение с клиентом.
Будет классно, если конкретизируете, что именно не работает?
Давно не писал видимо - мысль не донес. Представим человека, который хочет похудеть и хочет машину. Машина у него появится через неделю, а что похудеет - не факт. Ибо покупка машины мобилизует волю (любую) и удерживает ее в тонусе до выезда из автосалона. А похудение требует постоянного преодоления без очевидных гарантий комфортного будущего.
Так же и с любой системой - если необходимость ее применения осознанна, система будет работать. Если это дань моде, рецепт как достичь результата не напрягаясь, либо цель применения размыта - не сработает.
Это я как бы от себя говорю, что верю, что у тебя это работает, хотя не все уверены в этом и утверждаю, что и в моем случае проектный подход работал. Я могу понять, почему в это верят не все. Зачастую пытаемся решить производственные задачи, а задачи по самодисциплине и умении видеть цель решать не пытаемся. Т.е. как бы подразумевается, что мы дисциплинированны и точно знаем зачем нам это. Вот так и случаются холивары вокруг работоспособности систем управления, хотя по мне так даже предмета спора нет. Бывает, что дома прибрать не можем нормально - какая уж там проектная работа!
Глубоко, соглашусь, спасибо тебе за мысль
А тебе спасибо, что делишься. Причем, систематизируешь для других. Мне сейчас хочешь-не хочешь, снова в эту лямку влезать, так что жду еще опыта )
напишем:)
подскажите, а сколько проектов ведете одновременно?
Сложно ответить в абсолютных значениях, зависит от объема проектов. Если это объемные проекты, на которых требуется активное участие ПМа, то больше то больше 3х таких проектов вести не получится. Если проекты в формате технической поддержки с небольшим бэклогом задач, то при 5-8 проектах получается доставлять задачи быстро и оставлять всех клиентов довольными.
Я тут пописал в комментариях в виде ответов, но разрешите привести бытовой пример, как я вижу причины работы/не работы любой системы и места волевого усилия в этом вопросе.
Давайте распишем по действиям какое их количество совершается при скажем, покупке машины в кредит. Думаю, если детально, насчитаем минимум 20, 5 из которых окажутся весьма энергетически затратными. Кроме того, требуется определенный ресурс времени. И это не 1 час. В общем, проект этак на недельку.
У всех "лентяев", которых я знаю, есть автомобили. Результат налицо независимо от сложности и наличия времени.
ты к тому, что машина не экономит время по факту?