Как победить хаос в разработке продукта?
Заказчик меняет требования: это норма?
Мы провели опрос среди наших клиентов — руководителей eCommerce-направлений, в котором поинтересовались, какие проблемы, по их мнению, чаще всего встречаются в проектах разработки и имеют негативное влияние на ход проекта. Результаты опроса показали, что чаще всего это изменение требований в ходе проекта (25% опрошенных) и нечеткие изначальные требования (24%). Похожую статистику мы наблюдаем и в опросе Инфостата.
Проработка каждого нового требования и их внедрение в архитектуру проекта может значительно затянуть разработку и выбить команду из графика. Но и игнорировать требования тоже не получится, иначе конечный продукт не будет соответствовать ожиданиям заказчика, а также не принесет пользу для пользователей и прибыль для компании.
Требования могут меняться по нескольким причинам. Например, когда выстраивание бизнес-процессов идет параллельно с разработкой —можем взять офлайн-магазины, у которых бизнес в онлайне только начинает развиваться и, пока не налажена логистика, стоит вопрос о развитии собственной курьерской службы.
Другая частая причина изменения требований — конечное видение необходимого продукта рождается уже в ходе проекта, а не на старте. На старте есть цели, которые должен выполнять продукт, но подход к их достижению может быть разным и какой именно стоит выбрать и каким должен получиться продукт, становится понятно при детальной проработке разных блоков функциональностей.
Гибкость и открытый диалог с заказчиком помогают команде разработки выявлять действительно нужные требования и создавать продукт, полностью соответствующий задачам клиента. То, что требования меняются, это нормально. Мы с заказчиком — единая команда и преследуем одни и те же цели, поэтому важно не бороться с изменениями, а адаптироваться, приоритизировать и учиться управлять ими.
Как фиксируются требования на проекте?
Существует несколько подходов к фиксации требований. В первом случае на начальном этапе проекта создается максимально подробное техническое задание, которому команда будет следовать от первого и до последнего этапа проекта. С одной стороны, структурность помогает — когда у вас уже есть четкий план с разграничением зон ответственности каждого участника команды, всем понятен алгоритм создания проекта. С другой стороны, на начальном этапе четко всё описать во всех подробностях без прототипов и дизайн-макетов невозможно, особенно когда мы создаем уникальный продукт. Так оценка проекта будет обманчива.
Второй подход — работать вовсе без ТЗ. Этот вариант возможен только в маленьких продуктовых командах, но если команда большая (более пяти человек), есть риск возникновения хаоса — члены команды не будут понимать, к кому обращаться на том или ином этапе проекта. Тестировать продукт без ТЗ также гораздо сложнее из-за отсутствия единой структуры и понимания, что сделано. Чем больше команда или продукт, тем выше потребность в документации.
Оба подхода — это две крайности, поэтому лучше выбирать золотую середину. Техническая документация необходима, но сначала важно исследовать и сформировать примерное видение проекта, создать прототипы с дизайн-макетами и только потом приступать к составлению ТЗ. При таком подходе становится понятно, где возникли расхождения и что нужно изменить, перед тем как приступить к реализации проекта.
На начальном этапе создания крупного продукта прописывать ТЗ не имеет смысла, так как есть большая вероятность потратить много финансовых и временных ресурсов, а в итоге созданный документ не поможет нам достичь желаемой цели. Когда же документация пишется по несколько месяцев, возникают риски, что ТЗ будет сложно визуально представить и согласовать — можно упустить важные детали. Если ТЗ пишется уже в момент разработки, могут произойти изменения, которые приведут к переработке документации, и достичь целей, поставленных перед продуктом, будет сложнее.
В самом начале важно понять, из чего будет состоять продукт и для кого он, чтобы составить предполагаемый список фичей и требований с учетом целей и задач продукта. Далее проанализировать, все ли функциональности нужны и как с ними работать, — в этом помогут количественные и качественные исследования. Только когда уже готов дизайн-макет, приступаем к составлению технической документации, которая нужна разработчикам и тестировщикам.
Чек-лист: как составить грамотное ТЗ к проекту?
На основе собственного опыта мы собрали ключевые принципы, которых стоит придерживаться, чтобы составить рациональный и понятный для всех участников план проекта.
1. Проанализируйте, для кого вы пишете документацию. Техническая документация — тоже своего рода продукт, и важно понимать, кто его потребитель. Например, документация для разработчиков и клиентов будет отличаться даже в рамках одного и того же проекта, ТЗ должно быть адаптировано под каждого.
2. Дополняйте текстовую часть документации визуальным сопровождением. Во-первых, визуал забирает на себя часть информации и ее можно не прописывать текстом. А во-вторых, с графическими элементами гораздо легче воспринимать алгоритм проекта.
3. Соблюдайте баланс информации. Большой алгоритм с множеством цепочек важно прописать детально для понимания общей логики и этапов разработки продукта. При этом злоупотреблять деталями тоже не стоит — если информация уже показана на макете, не нужно дублировать ее словами, прописывайте только то, чего на макете нет. Избыточную документацию сложно воспринимать, поэтому ТЗ должно содержать только конкретику.
4. Поставьте себя на место читателя документации — всё ли понятно, достаточно ли информации для работы над продуктом на каждом из этапов? Если да, можете смело отдавать ТЗ команде.
5. Актуализируйте документацию, собирая обратную связь, — удобна ли она в использовании и что можно улучшить. Таким образом, раз за разом вы сможете улучшать документацию и подстраивать ее под восприятие всех членов команды.
Опубликовано 11.11.2023
