46 подписчиков

Как правильно задать границы и требования к проекту, чтобы в конце получить конфетку

5 минут

154 прочтения

1 ноября 2018

Поговорим о фэйлах на проектах. Каждая проблема на проекте отдается болью в сердце пиэма.

Как избежать проблемных ситуаций, как обозначить триггеры, как уловить приближение проблемы. Об этом и хочу поговорить в этом посте.

Игнор

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

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

Управляемость

Почему это важно? Потому что понимая, что именно происходит на проекте, этим можно управлять — просчитать риски, заложить бюджеты, выделить приоритеты, запустить MVP и начинать получать профит.

Например, проект разработки ПО для холдинга Welcome Group. Нами была спроектирована довольно большая многокомпонентная система, были описаны все пользователи, бизнес-задачи сервиса и показатели эффективности были определены на этапе анализа требований. После этого были просчитаны бюджет и сроки. Стало ясно, что на разработку всего времени нет. Поэтому запустили в работу только 4 основных интерфейса из 9. Это сработало, сократило сроки доставки, упорядочило контроль внутри. Хоть и была сделана не полная версия системы. Без понимания приоритетов это было бы невозможно.

Подробнее о кейсе можно прочитать в этом посте.

Возможные потери

40% потерь от непродуманной концепции в самом начале работы

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

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

Что учесть

Как определить границы проекта и продукта
Как подготовить видение
Как работать с заинтересованными лицами
Как определить пользователей
Какие проблемы должны быть решены
Для чего нужна документация

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

На одном из проектов (разработка системы доставки для ресторанного холдинга WG) мы прошли по всем пунктам, проработали каждый и документально зафиксировали. Это позволило гибко управлять компонентами проекта. И не понести потери при разработке и внедрении.

Более подробно о применяемом подходе на проекте можно почитать в этой статье.

Границы проекта

Цели и требования:

Проекта
Заказчика(инициатора)
Исполнителя
Самого продукта

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

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

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

Видение

Способы определения приоритетов, вариантов развития, целей, задач и требований существуют самые различные. Например:

Заинтересованные лица

Важно выяснить, кто влияет на проект. Почему они важны?Кто влияет и почему? Какие цели? Мотивы? Реальные потребности? Деньги? Опосредованно?

Хороший вопрос, какие могут быть заинтересованные лица на проекте разработки, например, корпоративного сайта крупного производственного холдинга и как они будут влиять?

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

Пользователи продукта

Продукт создается не просто так. Создаваемым продуктом будут пользоваться. Необходимо понять, кто наши пользователи (внешние, внутренние).

Внутренние — администраторы и менеджеры, операторы и так далее. Внешние — покупатели возможно. Сегменты аудитории, цели и задачи.

Стандартные признаки: демографические, психографические, географические, и так далее. Например, мы выявили (вместе с заказчиком) потенциальную аудиторию пользователей мобильного приложения календаря и выявили некоторые закономерности поведения в зависимости от конечных целей. Получилось три группы: не планирующие беременность, планирующие беременность, которые делятся на тех кто решительно готов и на тех кто еще только думает об этом. Естественно, сценарии потребления у них различные. И проблемы, которые они хотят решить тоже.

Решение проблемы

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

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

Документация

Не записано — значит, не было!

Переходим наверно к самому объемному вопросу. Теперь все, что мы там выяснили, определили, исследовали необходимо зафиксировать.

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