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

Зато можно — расставить приоритеты, найти ключевое, то, без чего сложно обходиться уже сейчас, — и сделать начальную версию продукта (MVP). Внедрив её, вы:

• закроете горящие задачи, которые давно пора было потушить;
• начнёте получать пользу уже сейчас, а не в перспективе;
• параллельно сможете дорабатывать и улучшать продукт, доводя его до идеала.

MVP (minimum viable product, минимально жизнеспособный продукт) — это начальная, тестовая версия продукта, прототип с ограниченным функционалом, который уже несёт в себе ценность, позволяет решать ключевые на данный момент задачи без внушительных затрат на разработку и оперативно получать обратную связь от пользователей.

Концепция MVP на примере CRM-системы

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

Нужно решить проблему — сделать систему, в которой будут храниться все обращения.

Можно сразу пойти дорогим и сложным путём и разработать ту идеальную, полноценную CRM с современным интерфейсом, в которой есть ВСЁ. Заявки создаются автоматически (из чатов и форм на сайте, e-mail, социальных сетей и т. д.), разговоры менеджеров с клиентами записываются, доступна детальная статистика, внутренний чат для сотрудников и многое-многое другое.

Здорово — но долго и дорого. А главное — всё время до внедрения системы бизнес продолжает работать по-старинке, менеджеры теряют клиентов, а вы — прибыль.

А можно начать с MVP. И уже с первым релизом получить простую систему с примитивным интерфейсом, в которой каждый менеджер сможет зарегистрироваться и вручную внести все данные о клиентах, прикрепить файлы. Да, будет не весь функционал. Но вы сможете быстро внедрить систему в работу и, решив главную проблему, перестанете на пустом месте терять доход. А дальше будете заниматься развитием системы и постепенно, итерация за итерацией, масштабировать её и добавлять необходимый функционал.

2 проблемы бизнеса, которые решает гибкая разработка проектов с MVP

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

Проблема №1. Затягиваются сроки разработки (либо начало откладывается на неопределённый срок) — из-за долгого составления ТЗ, долгого принятия работы и перфекционизма

Без детально прописанного технического задания (ТЗ) невозможно получить тот продукт, который вы хотите, — ведь ни разработчики, ни бизнес-аналитики не умеют читать ваши мысли. ТЗ необходимо для начала разработки: именно оно позволяет обозначить стоимость и сроки.

Чем больше в вашей будущей системе нестандартного функционала, тем объёмнее будет ТЗ и тем больше времени понадобится на его составление.

Вот здесь и кроется ловушка. Если вы склонны к перфекционизму и хотите во что бы то ни стало приступить к разработке по всему ТЗ сразу, без разбивки на итерации, то ваше желание близко к утопии. Такая разработка может занять неоправданно много времени — вплоть до года и даже больше. И это не шутка.

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

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

Поэтому в своей работе мы используем гибкие методологии Agile, которые позволяют оперативно вносить изменения в проект. И вместо обычного ТЗ вместе с клиентами составляем высокоуровневое — Vision and Scope (документ концепции и границ).

Документ Vision and Scope включает следующие разделы: 

• проблематика;
• бизнес-цели;
• положение об образе решения;
• бизнес-правила;
• предположения и зависимости;
• бизнес-риски;
• объём функций для MVP и последующих версий;
• особенности разработки системы;
• инфраструктура;
• модули системы;
• предварительная оценка проекта.

Поэтому вам и вашим сотрудникам, как заказчикам, важно:

• дать нашей команде максимально полные вводные по проекту и быть готовыми к плодотворному сотрудничеству на протяжении всего времени разработки;
• выключить перфекционизм и приготовиться к тому, что в процессе могут потребоваться доработки;
• вместе с нашими бизнес-аналитиками расставить приоритеты: выделить основной функционал, который ляжет в основу MVP (первого релиза).

При разработке проекта по гибкой методологии с созданием MVP работа двигается куда быстрее и эффективнее в сравнении с традиционным подходом:

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

Проблема №2. Готовым ПО неудобно пользоваться, в нём не хватает необходимых функций — либо вы, наоборот, переплатили за разработку ненужного функционала

Чаще всего те, кто заказывает разработку системы, составляет ТЗ, контролирует процесс и согласовывает результат и те, кто реально будет работать в системе, — совершенно разные люди. И то, что считают важным и нужным руководители и менеджеры, может оказаться совершенно бесполезным и попросту неудобным рядовым пользователям. И наоборот: того, о чём руководители не подумали, будет не хватать.

При разработке сложного проекта с нуля, без MVP, всегда есть неопределённость и риск, что:

• изначальная идея может оказаться не слишком жизнеспособной — пусть даже разработчики и сделают всё в точности по ТЗ. Но вы узнаете об этом уже по факту в процессе внедрения, потеряв время и слив немалый бюджет;
• во время разработки многое может поменяться — и в вашем бизнесе, и в мире вокруг. В итоге вся проделанная работа окажется неактуальной;
• нужного функционала может недоставать — потому что во время разработки пользователи не тестировали продукт и не могли подсказать, какие функции стоит добавить;
• а функционал, который вы делали про запас, «на всякий случай», по итогу окажется ненужным. Но! он в любом случае «съест» бюджет и время на разработку;
• всё то, что вы не учли во время составления ТЗ, придётся дорабатывать после — за дополнительное время и бюджет.

Избежать этих рисков помогает разработка MVP:

• разработка начинается с малого — и небольшими итерациями дорабатывается и масштабируется;
• уже после первого релиза у вас есть рабочий продукт, который решает конкретные проблемы;
• вы постоянно даёте пользователям поработать с обновлёнными версиями, получаете от них обратную связь, собираете предложения — и разработка продолжается с учётом полученных корректировок;
• вы в разы быстрее (по сравнению с традиционным подходом) отдаёте корректировки, разработчики их оперативно внедряют, вы тестируете, принимаете — и работа двигается дальше;
• тестируя небольшие изменения, вы чётко видите, если что-то идёт не так, — и может вовремя и без серьёзных затрат изменить и доработать концепцию проекта.

В итоге вы платите за действительно нужное — а за ненужное не платите.

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

Чтобы добиться результата, нужна сильная команда с вашей стороны

Важно, чтобы в разработке документа Vision and Scope и дальнейшей работе над проектом принимали участие:

• менеджер проекта — человек, который будет управлять проектом в целом и сможет расставлять приоритеты, планировать и контролировать выполнение задач, общаться с нашей командой бизнес-аналитиков и разработчиков и оперативно решать возникающие проблемы;
• специалист, который знает все бизнес-процессы внутри компании и наделён полномочиями их выстраивать;
• руководители всех заинтересованных в продукте подразделений, которые знают все нюансы и проблематику бизнес-процессов в своих подразделениях — и заинтересованы в том, чтобы их улучшить.

Создание MVP — это удобный, выгодный и эффективный подход в разработке жизнеспособных и полезных для пользователей продуктов любого масштабного и сложности. Не бойтесь следовать этому подходу и двигаться маленькими шагами — в результате вы обязательно придёте к большой цели.