Разработка документа о концепции и границах: объем разрабатываемой версии

Хотите узнать, как определить объем при разработке документа о концепции и границах? Давайте раскроем важные аспекты этого процесса вместе!

Важность определения объема

Вот вам конкретный пример из практики: команда взялась за разработку CRM для мастерской по ремонту бытовой техники. Приступив к разработке они выстроили такую последовательность создания CRM:

1. Ядро системы;
2. Пользовательский интерфейс приемщика;
3. Воронка поступления техники на ремонт;
4. Пользовательский интерфейс мастера;
5. Канбан ремонта техники;
6. Отчеты.

Фактически, это модули всей системы, которые они не успели реализовать в срок сдачи первой версии. Они успели сделать только:

1. Ядро системы;
2. Пользовательский интерфейс приемщика;
3. Воронка поступления техники на ремонт

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

1. Ядро системы;
2. Пользовательский интерфейс мастера;
3. Канбан ремонта техники;

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

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

Как вы думаете, насколько успешен данный подход разработчиков в глазах заказчиков? Думаете ли вы, что заказчик был рад готовому функционалу в первой версии? Надеюсь, что вы ответили нет. 🙂

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

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

Монеты на фоне плана разработки. К чему бы это?

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

Как известно проекты реализуются по правилу 3Д:

1. Из-за Денег - текущее состояние приносит убытки и необходима автоматизация;
2. За Деньги - никто не выполняет работу бесплатно;
3. Ради Денег - в результате заказчик хочет получить выгоду от реализованного проекта.

Успешность вашей работы в глазах заказчика предполагает 100% функционирование данной формулы. Но что происходит, если вы не оговариваете объемы первой версии и приносите результат, как та команда, пример которой представлен выше?

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

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

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

Метод определения приоритетов за 100 рублей

Определить приоритет за 100 рублей

Это достаточно простой, но в то же время действенный способ. Его принцип такой, как представлен на изображении. Почему именно 100 рублей? Вам необходимо обзавестись рублевыми монетами в таком количестве, чтобы каждому участнику, кто участвует в принятии решения об объеме разрабатываемой версии выдать по 100 рублей.

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

Пример карты модулей, для определения приоритетности

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

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

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

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

Таблица приоритетов на разработку в текущей версии

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

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

Кстати, не забываем ставить лайки. 🙂