Изнутри: как бизнес-процессы компании гарантируют вам качество и точные сроки разработки

Привет, это PMP Tech, разработчики IT-продуктов. Сегодня мы раскроем карты и покажем наши бизнес-процессы. Как попадать в сроки через качество, не нагружать клиентов звонками и подходить к разработке с готовыми протестированными требованиями — рассказали в статье.  

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

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

Теория и практика управления проектами имеют много общих моментов, и важно понимать, как и что применить на практике для достижения результата.

В компании PMP TECH мы объединяем базовые принципы управления проектами с гибкими методологиями, такими как Agile и фреймворк Scrum. Это позволяет нам быть гибкими, но при этом иметь структуру, необходимую для обеспечения качества и результативности проектов.

Один из ключевых подходов в нашей компании — это разделение работы на “подготовительную” и “спринты” с последующей разработкой и тестированием функциональности.

Созвон команды

Для того чтобы соблюсти сроки и обеспечить качество, мы следуем нескольким ключевым практикам:

1. Готовые и протестированные требования: Это помогает избежать недоразумений и уточнений в процессе разработки.
2. Структурированные подходы: Мы используем Agile и Scrum для обеспечения структуры и гибкости. Эти методологии позволяют нам разбить проект на мелкие итерации, что способствует управлению рисками и улучшает видимость прогресса.
3. Коммуникация: Мы активно общаемся с заказчиками и членами команды, чтобы убедиться, что все понимают, что и когда должно быть сделано. Это помогает избежать недопониманий и уточнений в последующих этапах работы.
4. Тестирование: Мы уделяем особое внимание тестированию функциональности на каждом этапе разработки. Это позволяет выявлять и устранять проблемы на ранних стадиях и обеспечивает высокое качество конечного продукта.

Сочетание этих подходов позволяет нам не только соблюдать сроки, но и достигать высокого качества в проектах.

Вашему вниманию наш бизнес-процесс из Jira, который помогает построить бесперебойный процесс доставки фичей из головы заказчика (Product Owner) до пользователя в Production.

Доски: 

На проектах в PMP.TECH в Jira мы используем две доски: Канбан и Спринт.

Канбан-доска состоит из следующих полей/статусов: 

1. К работе БА – Задачи, которые требуют описания.
2. Анализ БА и QA – Задачи, над которыми работает Бизнес-Аналитик для описания требований. На этом этапе также подключаются лиды или разработчики для выявления рисков и технических аспектов.
3. Готово к Дизайну – Задачи, для которых уже описаны требования и необходимо разработать дизайн-макеты.
4. Дизайн – Задачи, над которыми работает дизайнер для создания дизайн-макетов.
5. Готово к тестированию требований – Задачи, для которых выполнено описание и создание дизайна и которые готовы к ревью (тестированию требований) QA.
6. Тестирование требований – Задачи, проходящие тестирование требований QA.
7. Готово к PBR – Задачи, прошедшие тестирование и готовые к PBR (Product Backlog Review) с командой.
8. Готово к согласованию – Задачи, описанные с дизайном и понятные команде, которые нужно согласовать с заказчиком.
9. Готово к оценке – Задачи, согласованные с заказчиком и готовые к оценке.
10. Готово к работе – Полностью подготовленные, согласованные и оцененные задачи, которые можно брать в работу на спринты.

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

Особое внимание уделяется 6-му этапу — "тестированию требований". Заранее разрабатываются тест-кейсы для покрытия функциональности и выявления неточностей, что позволяет внести коррективы в требования с согласованием заказчика и обеспечить максимально эффективную разработку.

Преимущества подготовительной доски:

1. Точная оценка времени и бюджета на каждую функциональность.
2. Согласованный дизайн.
3. Четкие и протестированные требования.
4. Понимание со стороны разработчиков, что им нужно сделать.
5. Тестирование – Задачи, находящиеся в процессе тестирования QA.
6. Готово с дефектами – Задачи, которые имеют минорные дефекты, не блокирующие функционал, но требующие доработки до полного соответствия требованиям и дизайну.
7. Релиз-кандидат – Задачи, готовые к релизу в продакшн.
8. Готово – Задачи, полностью завершенные и закрытые.

Доска спринтов 

Для управления процессом разработки в PMP TECH мы используем доску спринтов, которая состоит из следующих полей/статусов:

1. К работе (Готово к работе) – Задачи, запланированные для выполнения в рамках текущего спринта.
2. В работе – Задачи, над которыми в данный момент работают члены команды.
3. Код ревью – Задачи, которые выполнены и ожидают проверки со стороны технического лидера.
4. Готово к тестированию – Задачи, которые прошли проверку технического лидера и готовы к тестированию QA.
5. Тестирование – Задачи, находящиеся в процессе тестирования QA.
6. Готово с дефектами – Задачи, которые имеют минорные дефекты, не блокирующие функционал, но требующие доработки до полного соответствия требованиям и дизайну.
7. Релиз-кандидат – Задачи, готовые к релизу в продакшн.
8. Готово – Задачи, полностью завершенные и закрытые.

Этот процесс разработки предоставляет ряд преимуществ:

1. Структурированный процесс и эффективное взаимодействие: Каждый участник команды понимает, на каком этапе находится задача, и какие действия необходимо предпринять далее. Это обеспечивает скоординированную работу и возможность оперативно реагировать на изменения.
2. Повышение качества работы: Задачи проходят несколько этапов проверки, включая код-ревью и тестирование, что позволяет выявить и исправить ошибки на ранних этапах и обеспечить высокое качество продукта.
3. Эффективное планирование: Оценка задач в рамках спринта позволяет более точно планировать их выполнение и управлять временными ресурсами.
4. Прозрачность и контроль: Видно текущее состояние каждой задачи, что позволяет контролировать процесс разработки и своевременно реагировать на возникающие проблемы.
5. Минимизация рисков: Благодаря тестированию и код-ревью риски недоработок и ошибок минимизируются, что способствует стабильной и надежной работе приложения.
6. Своевременный релиз: Задачи, прошедшие все этапы проверки, быстро переходят в статус "Релиз-кандидат", что позволяет выпустить их в продакшн вовремя.
7. Учет отклонений и дефектов: Обнаружение дефектов и несоответствий требованиям фиксируется на этапе "Готово с дефектами", что позволяет внести коррективы и улучшить качество продукта.
8. Улучшенная коммуникация с заказчиком: Все этапы разработки основаны на четких требованиях и дизайне, что улучшает взаимопонимание между командой и заказчиком и уменьшает вероятность недопонимания.

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

Как бонус, некоторые команды в дополнение к доскам используют MIRO, в котором по дням расписывают активности и ведут учет по проделанной работе (Daily).

Используя структуру "Риски - Ресурсы - Результат", мы можем подытожить преимущества разделения процесса разработки на этапы.

Риски: 

1. Неоднородные требования: Без четкого описания и согласования требований могут возникнуть недопонимания и разногласия в процессе разработки, что приведет к увеличению времени и ресурсов на исправление.
2. Технические сложности: Возможны технические проблемы, которые могут замедлить процесс разработки и увеличить риск просрочки сроков.
3. Неэффективная коммуникация: Недостаточная коммуникация с заказчиком может привести к непониманию требований и ожиданий, что в свою очередь может привести к неудовлетворенным ожиданиям и конфликтам.
4. Минимизация рисков: Предварительное тестирование требований и минимизация технических рисков позволяют избежать проблем в процессе разработки и уменьшить вероятность просрочки сроков или неудовлетворенности заказчика.

Ресурсы: 

1. Четкие требования и дизайн: Благодаря предварительной подготовке требований и дизайна, ресурсы тратятся более эффективно, поскольку разработчики могут сосредоточиться на выполнении задач, а не на уточнении требований.
2. Структурированный процесс: Разделение процесса на этапы обеспечивает более эффективное использование ресурсов и оптимизацию рабочего времени, так как каждый участник знает, на каком этапе находится задача и что ожидается от него.
3. Коммуникация с заказчиком: Четкость и своевременность коммуникации позволяют избежать недопониманий и конфликтов, что способствует более эффективному использованию ресурсов и улучшению качества проекта.
4. Минимизация рисков: Предварительное тестирование требований и минимизация технических рисков позволяют избежать проблем в процессе разработки и уменьшить вероятность просрочки сроков или неудовлетворенности заказчика.

Результат: 

1. Улучшенное качество продукта: Четкие требования и предварительная подготовка дизайна позволяют минимизировать ошибки и недоразумения, что ведет к повышению качества конечного продукта.
2. Эффективное использование времени: Разделение процесса на этапы позволяет эффективнее планировать и использовать время, что приводит к более быстрой доставке продукта и соблюдению сроков.
3. Улучшенная коммуникация и удовлетворенность заказчика: Благодаря четкой и своевременной коммуникации заказчик имеет ясное представление о процессе разработки и может активно влиять на результат, что повышает его удовлетворенность и доверие к компании.
4. Минимизация рисков: Предварительное тестирование требований и минимизация технических рисков позволяют избежать проблем в процессе разработки и уменьшить вероятность просрочки сроков или неудовлетворенности заказчика.

Если хотите узнать больше о разработке, дизайне и внутренней кухне — добро пожаловать в наш телеграм!

Нужна разработка? Тогда заходите к нам на сайт, чтобы оставить заявку.