Как завершить разработку в срок и не выйти за рамки бюджета: главные секреты управления проектами
Привет, это PMP Tech, разработчики IT-продуктов. Сегодня мы раскроем карты и покажем наши бизнес-процессы. Как попадать в сроки через качество, не нагружать клиентов звонками и подходить к разработке с готовыми протестированными требованиями — рассказали в статье.
Начнем с легкой теории. Проектный треугольник представляет собой своего рода искусство управления проектами, основанное на балансе между объемом работ, стоимостью и временем.
Треугольник показывает, как эти три элемента связаны между собой: изменение одного из них влечет за собой изменения двух других, чтобы обеспечить согласованность проекта. Нарушение баланса в треугольнике может привести к снижению качества проекта.
Теория и практика управления проектами имеют много общих моментов, и важно понимать, как и что применить на практике для достижения результата.
В компании PMP TECH мы объединяем базовые принципы управления проектами с гибкими методологиями, такими как Agile и фреймворк Scrum. Это позволяет нам быть гибкими, но при этом иметь структуру, необходимую для обеспечения качества и результативности проектов.
Один из ключевых подходов в нашей компании — это разделение работы на “подготовительную” и “спринты” с последующей разработкой и тестированием функциональности.
Для того чтобы соблюсти сроки и обеспечить качество, мы следуем нескольким ключевым практикам:
- Готовые и протестированные требования: Это помогает избежать недоразумений и уточнений в процессе разработки.
- Структурированные подходы: Мы используем Agile и Scrum для обеспечения структуры и гибкости. Эти методологии позволяют нам разбить проект на мелкие итерации, что способствует управлению рисками и улучшает видимость прогресса.
- Коммуникация: Мы активно общаемся с заказчиками и членами команды, чтобы убедиться, что все понимают, что и когда должно быть сделано. Это помогает избежать недопониманий и уточнений в последующих этапах работы.
- Тестирование: Мы уделяем особое внимание тестированию функциональности на каждом этапе разработки. Это позволяет выявлять и устранять проблемы на ранних стадиях и обеспечивает высокое качество конечного продукта.
Сочетание этих подходов позволяет нам не только соблюдать сроки, но и достигать высокого качества в проектах.
Вашему вниманию наш бизнес-процесс из Jira, который помогает построить бесперебойный процесс доставки фичей из головы заказчика (Product Owner) до пользователя в Production.
Доски:
На проектах в PMP.TECH в Jira мы используем две доски: Канбан и Спринт.
Канбан-доска состоит из следующих полей/статусов:
- К работе БА – Задачи, которые требуют описания.
- Анализ БА и QA – Задачи, над которыми работает Бизнес-Аналитик для описания требований. На этом этапе также подключаются лиды или разработчики для выявления рисков и технических аспектов.
- Готово к Дизайну – Задачи, для которых уже описаны требования и необходимо разработать дизайн-макеты.
- Дизайн – Задачи, над которыми работает дизайнер для создания дизайн-макетов.
- Готово к тестированию требований – Задачи, для которых выполнено описание и создание дизайна и которые готовы к ревью (тестированию требований) QA.
- Тестирование требований – Задачи, проходящие тестирование требований QA.
- Готово к PBR – Задачи, прошедшие тестирование и готовые к PBR (Product Backlog Review) с командой.
- Готово к согласованию – Задачи, описанные с дизайном и понятные команде, которые нужно согласовать с заказчиком.
- Готово к оценке – Задачи, согласованные с заказчиком и готовые к оценке.
- Готово к работе – Полностью подготовленные, согласованные и оцененные задачи, которые можно брать в работу на спринты.
Каждый этап имеет свою функцию и обеспечивает последовательное продвижение задач по процессу разработки. На каждом этапе предусмотрена коммуникация между членами команды с учётом строго отведенных временных рамок, что позволяет всем быть в курсе происходящего и избежать необходимости частых звонков.
Особое внимание уделяется 6-му этапу — "тестированию требований". Заранее разрабатываются тест-кейсы для покрытия функциональности и выявления неточностей, что позволяет внести коррективы в требования с согласованием заказчика и обеспечить максимально эффективную разработку.
Преимущества подготовительной доски:
- Точная оценка времени и бюджета на каждую функциональность.
- Согласованный дизайн.
- Четкие и протестированные требования.
- Понимание со стороны разработчиков, что им нужно сделать.
Доска спринтов
Для управления процессом разработки в PMP TECH мы используем доску спринтов, которая состоит из следующих полей/статусов:
- К работе (Готово к работе) – Задачи, запланированные для выполнения в рамках текущего спринта.
- В работе – Задачи, над которыми в данный момент работают члены команды.
- Код ревью – Задачи, которые выполнены и ожидают проверки со стороны технического лидера.
- Готово к тестированию – Задачи, которые прошли проверку технического лидера и готовы к тестированию QA.
- Тестирование – Задачи, находящиеся в процессе тестирования QA.
- Готово с дефектами – Задачи, которые имеют минорные дефекты, не блокирующие функционал, но требующие доработки до полного соответствия требованиям и дизайну.
- Релиз-кандидат – Задачи, готовые к релизу в продакшн.
- Готово – Задачи, полностью завершенные и закрытые.
Этот процесс разработки предоставляет ряд преимуществ:
- Структурированный процесс и эффективное взаимодействие: Каждый участник команды понимает, на каком этапе находится задача, и какие действия необходимо предпринять далее. Это обеспечивает скоординированную работу и возможность оперативно реагировать на изменения.
- Повышение качества работы: Задачи проходят несколько этапов проверки, включая код-ревью и тестирование, что позволяет выявить и исправить ошибки на ранних этапах и обеспечить высокое качество продукта.
- Эффективное планирование: Оценка задач в рамках спринта позволяет более точно планировать их выполнение и управлять временными ресурсами.
- Прозрачность и контроль: Видно текущее состояние каждой задачи, что позволяет контролировать процесс разработки и своевременно реагировать на возникающие проблемы.
- Минимизация рисков: Благодаря тестированию и код-ревью риски недоработок и ошибок минимизируются, что способствует стабильной и надежной работе приложения.
- Своевременный релиз: Задачи, прошедшие все этапы проверки, быстро переходят в статус "Релиз-кандидат", что позволяет выпустить их в продакшн вовремя.
- Учет отклонений и дефектов: Обнаружение дефектов и несоответствий требованиям фиксируется на этапе "Готово с дефектами", что позволяет внести коррективы и улучшить качество продукта.
- Улучшенная коммуникация с заказчиком: Все этапы разработки основаны на четких требованиях и дизайне, что улучшает взаимопонимание между командой и заказчиком и уменьшает вероятность недопонимания.
Используя этот процесс, мы достигаем более эффективной и прозрачной разработки, что способствует улучшению качества продукта и удовлетворению потребностей заказчика. Выглядит трудоемко, нагружено, но в тоже время, отработав по данному бизнес-процессу 2-3 спринта, вам уже не захочется от него отказываться.
Как бонус, некоторые команды в дополнение к доскам используют MIRO, в котором по дням расписывают активности и ведут учет по проделанной работе (Daily).
Используя структуру "Риски - Ресурсы - Результат", мы можем подытожить преимущества разделения процесса разработки на этапы.
Риски:
- Неоднородные требования: Без четкого описания и согласования требований могут возникнуть недопонимания и разногласия в процессе разработки, что приведет к увеличению времени и ресурсов на исправление.
- Технические сложности: Возможны технические проблемы, которые могут замедлить процесс разработки и увеличить риск просрочки сроков.
- Неэффективная коммуникация: Недостаточная коммуникация с заказчиком может привести к непониманию требований и ожиданий, что в свою очередь может привести к неудовлетворенным ожиданиям и конфликтам.
Ресурсы:
- Четкие требования и дизайн: Благодаря предварительной подготовке требований и дизайна, ресурсы тратятся более эффективно, поскольку разработчики могут сосредоточиться на выполнении задач, а не на уточнении требований.
- Структурированный процесс: Разделение процесса на этапы обеспечивает более эффективное использование ресурсов и оптимизацию рабочего времени, так как каждый участник знает, на каком этапе находится задача и что ожидается от него.
- Коммуникация с заказчиком: Четкость и своевременность коммуникации позволяют избежать недопониманий и конфликтов, что способствует более эффективному использованию ресурсов и улучшению качества проекта.
Результат:
- Улучшенное качество продукта: Четкие требования и предварительная подготовка дизайна позволяют минимизировать ошибки и недоразумения, что ведет к повышению качества конечного продукта.
- Эффективное использование времени: Разделение процесса на этапы позволяет эффективнее планировать и использовать время, что приводит к более быстрой доставке продукта и соблюдению сроков.
- Улучшенная коммуникация и удовлетворенность заказчика: Благодаря четкой и своевременной коммуникации заказчик имеет ясное представление о процессе разработки и может активно влиять на результат, что повышает его удовлетворенность и доверие к компании.
- Минимизация рисков: Предварительное тестирование требований и минимизация технических рисков позволяют избежать проблем в процессе разработки и уменьшить вероятность просрочки сроков или неудовлетворенности заказчика.
Интересно, очень интересно
Спасибо, мы старались )
Нам бы такого грамотного проджект менеджера