Понимание бизнес-задачи
Это один из наиболее важных моментов в процессе разработки - мы считаем, что все участники процесса - и дизайн-команда, и разработчики, и команда тестирования должны понимать бизнес-задачи, которые решает проект, над которым мы работаем. Также важно понимать целевую аудиторию - кто именно будет пользоваться проектом. Понимание этих факторов позволяет избежать ошибок в разработке - так, зная кто будет пользоваться определенным отчетом разработчик может понимать в каком именно формате он должен быть создан. Кроме этого, такой подход позволяет каждому из участников процесса предлагать новые идеи по улучшению системы - независимо от того, входит ли это в их перечень ответственностей - за счет того, что все понимают для чего они делают тот или иной функционал, все намного больше вовлекаются в работу над проектом.
Общение с клиентом
Общение команды разработки с клиентом - крайне важный момент для большинства наших проектов. Там, где это возможно, мы стараемся организовать “живую” встречу у нас в офисе, чтобы клиент увидел команду, и команда, в свою очередь, увидела для кого мы делаем тот или иной проект.
Помимо обязательных моментов, таких как общение бизнес-аналитика с клиентом при формировании первичной документации по проекту, мы начали подключать дизайн-команду на этапе защиты визуальных материалов по проекту, разработчиков на этапе клиентских демо и QA-специалистов на этапе обучения команды клиента работе с системой. За счет этого, с одной стороны, клиент понимает кто решает его задачу, а команда разработки намного лучше погружается в проект.
Статусы и встречи
Обсуждение командой задач и проекта в общем - крайне важное условие качественной реализации проекта. В то же время очень важно не перейти грань - чтобы весь рабочий процесс не состоял из одних только обсуждений. В своей работе мы оставили следующие встречи:
- Ежедневный командный статус - стандартные 10 минут утром - кто в команде чем занят.
- Еженедельный статус компании - общая встреча, на которой руководители (а иногда и участники) команд рассказывают о том, с какими интересными кейсами столкнулись или планируют работать на текущей неделе. Такой подход позволяет значительно повысить уровень переиспользования решений команд и снизить время, требуемое на реализацию какого-то функционала - есть понимание к кому из коллег можно обратиться за советом;
- Встречи тимлидов - обсуждение среди технических руководителей команд общих планов развития внутренних продуктов, стандартизации каких-то решений и инструментов разработки.
- Кик-офф по проекту - встреча, с которой начинается командная работа над проектом. В рамках данной встречи собираются все участники будущего проекта - UI/UX специалисты, бизнес-аналитики, команда разработчиков, QA-специалисты и все они могут задать любые вопросы, касающиеся проекта - с точки зрения его технической реализации, но, что более важно, узнать все, что нужно о его бизнес-составляющей. Эти встречи позволяют каждому из участников понимать - зачем он делает тот или иной функционал на проекте. А понимание этого “Зачем?” наверное один из самых важных факторов успеха и качественной работы;
- Ретроспектива проекта - о ней расскажем чуть детальнее.
Ретроспективы - что сделано и что нужно было сделать
Крайне важный шаг в работе над проектом - анализ результатов выполненной работы. По факту завершения каждого из проектов мы проводим его ретроспективу - собираем всех участников проекта и обсуждаем - что мы сделали хорошо, где были допущены ошибки и как можно избежать их в дальнейшем.
Ретроспектива - отдельная церемония, для проведения которой имеется множество готовых сценариев. Анализ проекта помогает нам улучшать нашу систему, на которой мы строим все наши разработки - fdForge, дополняя ее функционалом, которого не хватает на проектах, а также накапливать коллективный опыт - все результаты фиксируются и при начале нового проекта анализируется общий перечень позитивного и негативного опыта с предыдущих подобных кейсов.
Защита результатов работ
Очень важным шагом, который значительно повлиял на качество результата стала защита определенного этапа работ внутри компании - так, при сдаче дизайн-макетов UI-команда проекта проводит внутреннюю презентацию своей работы Front-end разработчикам и бизнес-аналитику проекта - рассказывает о принятых решениях, финализирует все договоренности касательно механики реализации тех или иных моментов. Специалисты, которые принимают работу и далее будут подключаться к ней со своей стороны могут указать на недочеты или недостающие элементы для принятия работ.
Такой подход позволил нам:
- Повысить качество передаваемых материалов - команда лучше чувствовала свою ответственность и понимала, что нужно будет объяснять принятые решения;
- Улучшить коммуникацию в команде - специалисты различных направлений начали больше общаться, обсуждая помимо проекта и вопросы, которые можно улучшить в общем в процессе разработки;
- Привнести новые идеи в проекты - в процессе защиты у команд был еще один шанс предложить какие-то улучшения по проекту (в рамках сроков и бюджета), которые могли повлиять на финальный результат;
- Убрать из процесса недопонимания и внутреннее недовольство участников - пропали недосказанности, оправдания и скрытые обиды
Представленные выше пункты в значительной степени являются базовыми, но именно они позволяют нам обеспечить высокое качество реализации проектов для наших клиентов и партнеров, а также обучать и развивать команду наших специалистов, делая работу над каждым новым проектом максимально интересной и в то же время эффективной.
Надеемся, что эта информация поможет вам оптимизировать работу над вашими собственными проектами!
