MVP. Как выводить на рынок товары и услуги, которые нравятся покупателям - Дэн Олсен

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

Часть III

Создание и оптимизация продукта

Глава 12

Создание продукта с помощью методов Agile-разработки

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

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

Agile-разработка

До этого момента мы успешно применяли итеративный подход, поэтому вполне логично будет использовать его и при непосредственном создании продукта. «Agile-разработка» – это термин, используемый для описания различных итеративных и поэтапных методов создания продукта. До внедрения Agile-разработки большинство программных продуктов создавались с использованием «водопадного» подхода, суть которого состоит в последовательном выполнении ряда шагов. При нем команда разработчиков сначала определяет все требования технического задания, и лишь затем приступает к разработке продукта. Далее проводится внедрение и тестирование, чтобы убедиться, что все работает так, как было задумано. Ключевой особенностью «водопадного» подхода является то, что разработчики не переходят к следующему шагу до тех пор, пока предыдущий этап не будет завершен на 100 %. Другими словами, никакого проектирования не происходит до тех пор, пока не будут определены все требования, и никакой программный код не пишется до тех пор, пока не будет спроектирован весь продукт. Такой подход также называют BDUF (Big Design Up Front)[22].

В свою очередь, разработчики, практикующие Agile-подход (сам термин Agile означает «гибкий», – прим. пер.), разбивают проект на более мелкие составляющие, для реализации которых требуются короткие циклы определения требований, проектирования и кодирования. У Agile-разработки имеется несколько преимуществ. Во-первых, тактика продвижения мелкими шагами позволяет быстрее реагировать на рыночные и прочие внешние изменения. Во-вторых, в процессе разработки продукт быстрее выносится на суд пользователей, что означает более раннее получение обратной связи, которая помогает концентрировать последующие усилия в правильном направлении. В-третьих, разработчикам проще выявлять и ликвидировать ошибки за счет одновременного выполнения меньшего объема работ.

Я упоминал выгоды концепции бережливого производства небольших партий в главе 6, но давайте рассмотрим, почему она так полезна при разработке программного обеспечения (или при любой другой разработке, осуществляемой в условиях с высокой степенью неопределенности). Когда разработчики оценивают количество времени, которое им потребуется для создания новой функции, в их оценке присутствует некоторая неопределенность. Наличие такой неопределенности приводит к тому, что произведенная оценка затрат оказывается ошибочной и фактическая продолжительность разработки отличается от расчетной. Хороший способ сравнения фактической и расчетной продолжительности разработки заключается в количественном измерении их соотношения. Если реализация проекта заняла в два раза больше времени, чем ожидалось, величина такого соотношения будет равна 2x; если же на реализацию ушло вдвое меньше расчетного времени, соотношение будет равно 0.5x.

Стив Макконнелл[23] создал диаграмму под названием «Конус неопределенности», которая характеризует диапазон величины ожидаемой ошибки при оценке затрат на протяжении всего срока реализации проекта. На его диаграмме верхняя и нижняя границы ошибки оценки представляют собой симметричные кривые, которые начинаются с уровней 4x и 0.25x, соответственно, в начале проекта, и плавно опускаются по мере продвижения разработки, сходясь в конце на нулевой отметке. Это иллюстрирует интуитивно понятный и подтвержденный практическим опытом факт, что в начале разработки величина ошибки при оценке затрат потенциально выше, чем ближе к завершению проекта.

Однако на практике я не сталкивался с тем, чтобы подобные ошибки оказывались симметричными. Другими словами, я не замечал, чтобы разработчики с одинаковой вероятностью опаздывали и завершали задачи раньше намеченного срока. В большинстве случаев задачи по разработке программного обеспечения занимают больше времени, чем предполагалось изначально. И хотя некоторые действительно выполняются досрочно, количество сэкономленного времени, как правило, оказывается намного меньшим, чем масштабы отрицательных сюрпризов. Почему так происходит? Чтобы объяснить асимметричную природу ошибок в оценке затрат на создание программного обеспечения, я процитирую эпистемолога и бывшего министра обороны США Дональда Рамсфелда:

«Существуют известные нам известные. Это вещи, о которых мы знаем, что мы о них знаем. Мы также знаем о существовании известных нам неизвестных. То есть мы знаем, что есть некоторые вещи, о которых мы не знаем. Но есть и неизвестные нам неизвестные. Это то, о чем мы не знаем, что мы о них не знаем».

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

Допустим, я подсчитал, что выполнение задачи A займет у меня пять минут, а выполнение задачи B – пять месяцев. С обеими задачами могут быть связаны неизвестные мне неизвестные. Однако неопределенность не является линейной при увеличении масштаба задачи, о чем