Все стартапы связаны с определённым уровнем риска, особенно когда у вас есть идея, но нет технического сооснователя. Atlas — компания по разработке индивидуального программного обеспечения — в прошлом выполняла роль такого недостающего технического сооснователя для стартапов. Ниже представлены наши рекомендации о том, как стартапам снизить риски программного проекта, обращаясь к компании-разработчику за поддержкой в качестве технического партнёра.
Atlas работает более 10 лет, и за это время мы выяснили, что помогает, а что мешает снизить риски провала программных проектов. Лично мы предпочитаем использовать методологию Agile для разработки индивидуального ПО, и ниже мы объясним почему. Важно понимать, что Agile может выявлять проблемы управления проектом в некоторых случаях, но сам по себе не решает их.
Прежде чем подробно рассматривать Agile, давайте кратко остановимся на традиционном подходе к разработке ПО, который чаще всего запрашивают клиенты Atlas — модель Waterfall.
Каскадная модель (англ. waterfall model, иногда переводят как модель «Водопад») — модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки.
Wikipedia
Модель Waterfall, несмотря на все свои недостатки, успешно применялась в различных отраслях, включая военную сферу, космическую индустрию и здравоохранение. Это строго контролируемые и регулируемые среды, где решения принимаются экспертами, а жизни людей зависят от того, чтобы решения были правильными с первого раза. Здесь нет места для…
Ой, это не сработало — оставим это в стороне и попробуем изложить иначе.
На этой схеме представлена визуальная модель Waterfall. Вы сразу заметите, что после начала процесса разработки программного обеспечения невозможно вернуться к исходной точке, и именно в этом заключается главная проблема Waterfall. Многие проекты по разработке приложений, которые будут начаты и профинансированы в этом и следующем году, выполняются людьми, не до конца понимающими все сложности написания программного обеспечения и не знающими всех требований к ПО заранее. Сколько бы методов сбора требований мы ни применяли в Atlas для получения полных спецификаций от клиентов, если владелец продукта не знает того, чего он не знает, он не сможет предоставить корректную информацию. Это не их вина, к сожалению, это просто факт.
Теперь давайте представим, что команда разработчиков игнорирует вышеописанные проблемы, ведь клиент машет перед ними кучей долларов. Они собирают неполные требования к ПО, насколько могут, и бросаются вниз по водопаду (модели), используя функциональную спецификацию размером с полную «Британскую энциклопедию» в качестве спасательного круга. Клиент стоит рядом с водопадом (моделью) и воодушевлён. Он уверен, что вместе с командой разработчиков они учли все требования, но БАЦ — они достигают дна водопада и начинают «тонуть». Оказывается, в функциональной спецификации были пробелы, и никакое гребля или откачка воды не помогут. Более того, клиент уже видел предварительный вариант приложения и у него есть целая куча последних изменений, которые он хочет внести.
Под давлением фиксированного срока и бюджета команда разработчиков вынуждена ещё усерднее «гребсти и откачивать воду», чтобы уложиться в сроки. В результате создаётся субоптимальное приложение, которое формально соответствует спецификации клиента, но могло бы быть значительно лучше, если бы использовался более итеративный подход.
Одна из основных проблем метода Waterfall — это его отсутствие гибкости. При постоянно меняющихся потребностях современной разработки ПО часто требуется более динамичный подход. Невозможность вернуться к предыдущим этапам процесса приводит к потере ресурсов и упущенным возможностям для оптимизации или инноваций. Именно здесь приходит на помощь Agile. Методология Agile строится на принципах непрерывного совершенствования, сотрудничества и гибкости, позволяя командам адаптироваться по мере развития проекта и обеспечивая, что конечный продукт лучше соответствует изменяющимся потребностям клиента.
Итак, это подводит нас к методологии Agile, как показано на схеме. Считаете ли вы, что Agile — это путь вперёд? На самом деле Agile может быть столь же рискованным, если его неправильно применять, и определённо не решает всех описанных здесь проблем. Чтобы методология Agile работала эффективно, всё равно требуется общий план, а для каждой итерации необходимо заранее определить задачи до начала разработки. Agile обеспечивает, что процесс разработки становится совместным усилием и риски распределяются более равномерно между обеими сторонами. Другими словами, команда разработчиков всё ещё может «бросаться в реку», но в этом случае клиент находится в лодке, помогая грести и откачивать воду. Всё это сводится к сотрудничеству.
Кроме того, Agile способствует культуре прозрачности и постоянного общения между командой разработчиков и клиентом. Это означает, что владелец продукта активно участвует в процессе разработки, помогая направлять проект в правильное русло, вносить необходимые корректировки и обеспечивать, чтобы конечный продукт максимально соответствовал его первоначальному видению. Такое участие укрепляет доверие и минимизирует недопонимания, которые могли бы возникнуть на более поздних этапах разработки.
Компания Atlas перевела большинство наших проектов с метода Waterfall на методологию Agile ещё в 2011 году, и мы намерены по возможности использовать Agile исключительно в будущем. Вот наши лучшие советы и приёмы, которые мы применяем, чтобы все наши проекты по разработке ПО, независимо от их размера и уровня риска, имели наилучшие шансы быть выполненными в срок и в рамках бюджета:
- Если к нам обращается клиент, желающий создать веб-приложение, и это его первый проект такого рода или он выходит на новую отрасль, мы настоятельно рекомендуем сначала создать MVP (Minimum Viable Product — минимально жизнеспособный продукт). Попытки создать приложение со всеми «наворотами» обычно необоснованно дороги и чаще всего обречены на провал.
- Иногда мы рекомендуем создание proof of concept (доказательства концепции). Это особенно полезно, если один или несколько элементов требований к приложению представляют высокий риск из-за технической сложности или зависимости от сторонней системы.
- Продолжая мысль из пункта 2: если мы создаём proof of concept, мы показываем его как можно большему числу людей, прежде чем двигаться дальше. Если приложение внутреннее — показываем его сотрудникам. Если планируется коммерческая продажа — демонстрируем его максимально возможному количеству потенциальных клиентов. Да, это занимает время и требует усилий, но выявить ошибку на раннем этапе гораздо дешевле, чем исправлять её позже.
- Если proof of concept не нужен, мы всегда рекомендуем хотя бы создать wireframes (Balsamiq — наш инструмент выбора, если только прототип на HTML не будет более уместен). Даже самые простые wireframes помогают владельцу продукта визуализировать детали, которые могли быть упущены ранее. Поскольку одна картинка стоит тысячи слов, wireframes включаются в планы итераций — они труднее для неправильного толкования и помогают минимизировать неоднозначность.
- Мы используем клиентский портал для повышения прозрачности. В частности, мы обеспечиваем возможность клиентам отслеживать, над чем мы работаем в рамках текущей итерации. В Европе стартапы, стремящиеся быстро проверить свои идеи, часто обращаются к компаниям по разработке MVP, используя минимально жизнеспособные продукты для снижения рисков и эффективного масштабирования. Любые потенциальные проблемы мы сразу добавляем в портал для обсуждения, не дожидаясь следующей встречи.
- Говоря о встречах — мы настаиваем, чтобы ключевые заинтересованные стороны продукта участвовали во всех встречах по окончании спринта для предоставления обратной связи. Мы настолько серьёзно относимся к этому пункту, что включаем его в наш контракт по разработке ПО по методологии Agile.
- Мы никогда не застреваем в долгих обсуждениях контрактов. Разработка ПО — это совместная работа с разделением рисков, и наше соглашение о разработке отражает этот подход. Вместо того чтобы углубляться в детали контрактов, мы предпочитаем сосредоточиться на создании приложения для наших клиентов.
С методологией Agile или без неё эти советы и приёмы сэкономили нам тысячи часов бесполезной работы. Надеемся, они помогут и вам.
