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

Сначала выстраивание рабочего процесса, потом — разработка

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

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

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

Что это дает: 

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

• Если в процессе с проекта уйдет специалист, а на его место придет другой — меньше ресурсов уйдет на понимание задачи.

От чего зависят результаты

Подход к рабочим процессам должен быть рациональным, чтобы впоследствии не переделывать ни дизайн, ни разработку, а готовый продукт не принес ущерб бизнесу. Четыре фактора, на которые стоит обратить внимание и принять в работу:

1. Выстраивание внутренней коммуникации между всеми участниками

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

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




2. Вовлеченность бизнеса в процесс реализации продукта

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

Компания должна понимать пользователя и воспринимать его как важного участника всего процесса, но в то же время вовлеченность должна быть направлена в обе стороны — важно передавать команде разработке свои ключевые потребности.




3. Уважение труда каждого специалиста

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




4. Использование инструментов для проектирования рабочих процессов и создание документаций

Полезно использовать инструменты, которые позволяют контролировать рабочие процессы. Один из таких — Scrum. Это фреймворк, который помогает командам приоритизировать задачи и работу над продуктом. Его основа — итеративная разработка и получение регулярной обратной связи от заказчиков и пользователей. 

Здесь специалисты разных направлений могут объединяться в Scrum-команду и работать над общей целью. Процессы курируют Scrum-мастера при помощи story point — единицы измерения, которая показывает оценку общих усилий, необходимых для полной реализации определенного участка работы (функциональности). Помимо прочего, новый персонал на проекте будет быстрее вникать в задачи, если вместе со всем вышеперечисленным будет документация.

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

Закрепим

1. Проектирование рабочих процессов лучше проводить, когда проект только зародился, чтобы потом дополнительно не тратить ни время, ни бюджет на исправление ошибок.
2. Коммуникация внутри команд — это важно. Сплоченность и движение к общей цели помогают достичь высокого результата. 
3. Над проектом работают и дизайнеры, и разработчики. Но это не говорит о том, что кто-то из них делает менее важную работу. Нельзя обесценивать чужой труд.
4. Для гибкого рабочего процесса полезно использовать дополнительный инструмент, который помогает наладить и проконтролировать создание ИТ-продукта.

Источник: https://habr.com/ru/post/724692/