Определение стоимости темы — дело сложное, и владельцы продукта в agile-проектах нередко дают туманную и по большей части бесполезную рекомендацию «приоритизировать по коммерческой стоимости». Было бы понятно, если бы советовали использовать номинальную стоимость. Но что такое коммерческая стоимость? Чтобы предложить более практичный набор рекомендаций по приоритизации, в этой главе мы рассмотрим четыре фактора, которые необходимо учитывать при расстановке приоритетов разработки новых возможностей:

1. Финансовая стоимость использования функций.

2. Затраты на разработку (и, возможно, поддержку) новых функций.

3. Объем и значимость обучения и нового знания, созданного в результате разработки функций.

4. Величина риска, ликвидированного в результате разработки функций.

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

 

Стоимость

Первым фактором при приоритизации работы является финансовая стоимость темы. Сколько денег получит или сэкономит организация в результате включения новых функций в тему? Именно это зачастую имеется в виду, когда владельцев продукта просят «определить приоритеты по стоимости для бизнеса».

Нередко идеальным способом определения стоимости темы является оценка ее финансового эффекта в течение определенного периода времени — обычно следующих нескольких месяцев, кварталов, а может быть, и лет. Это можно сделать, если продукт продается на коммерческой основе, например новый текстовый процессор или калькулятор, представляющий собой часть встроенной системы. Это также можно сделать для приложений, которые будут использоваться в разрабатывающей их организации. В главе 10 «Приоритизация по финансовой отдаче» описываются различные подходы к оценке финансовой стоимости тем.

Оценка финансовой отдачи темы может вызывать затруднения. Для этого обычно определяют ряд новых продаж, среднюю стоимость одной продажи (включая последующие продажи и соглашения на обслуживание), динамику увеличения продаж и т. д. Из-за сложности такого подхода нередко полезно иметь альтернативный метод оценки стоимости. Поскольку стоимость темы связана с ее желательностью для новых и существующих пользователей, для представления стоимости можно использовать нефинансовые показатели желательности. Этому методу посвящена глава 11 «Приоритизация по желательности».

 

Затраты

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

Темы нередко кажутся ценными, если смотреть на них только с точки зрения времени реализации. Как это ни банально, очень важно помнить, что время — это деньги. Нередко самым действенным способом добиться этого во время приоритизации является примерный перевод пунктов или идеальных дней в деньги. Предположим, вы повышаете заработную плату всех участвовавших в проекте в течение последних 12 недель и получаете суммарные затраты $150 000. Сюда входят владелец продукта и руководитель проекта, а также все программисты, тестировщики, администраторы баз данных, аналитики, дизайнеры пользовательских интерфейсов и т. д. В течение этих 12 недель команда реализовала 120 пунктов. Тогда можно сказать, что совокупная себестоимость составляет $150 000, а себестоимость пункта — $1250. Допустим, владелец продукта пытается решить, стоит ли включать в следующий релиз функцию размером 30 пунктов. Один из подходов к принятию решения — определить, оправдывает ли новая функция вложения в размере $37 500 (30 × 1250 = 37 500).

В главе 10 «Приоритизация по финансовой отдаче» мы более подробно поговорим о себестоимости и приоритизации на основе финансового вознаграждения относительно затрат.

 

Новые знания

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

• Знания о продукте.

• Знания о проекте.

Знания о продукте — это знания о том, что должно разрабатываться. Это знания о тех функциях, которые должны включаться, и о тех, которые не должны включаться. Чем больше знаний о продукте имеет команда, тем лучше она принимает решения о характере и функциях продукта.

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

Другой стороной приобретения знаний является уменьшение неопределенности. В начале проекта существует неопределенность в отношении того, какие функции должен иметь продукт. Существует также неопределенность, связанная с тем, как мы будем создавать продукт. Лауфер (Laufer, 1996) называет эти типы неопределенности конечной неопределенностью и неопределенностью средств. Конечная неопределенность снижается путем приобретения дополнительных знаний о продукте, неопределенность средств снижается путем приобретения дополнительных знаний о проекте.

В проекте, где используется каскадный подход, все неопределенности, связанные с тем, что создается, пытаются устранить до решения проблемы неопределенности того, как это будет создаваться. Именно отсюда проистекает распространенное представление о том, что анализ связан с тем, чтó создается, а дизайн — с тем, как это создается. На рис. 9.1 представлены каскадный подход и agile-подход к устранению неопределенности.

В левой части рис. 9.1, где показан каскадный подход, направленная вниз стрелка представляет попытку традиционной команды полностью устранить конечную неопределенность в начале проекта. Это означает, что уже до начала разработки неопределенность, связанная с конечной целью, полностью отсутствует. Продукт полностью определен. Стрелка, направленная вправо, показывает, что неопределенность средств (того, как продукт будет создаваться) снижается по мере осуществления проекта. Разумеется, полное предварительное устранение конечной неопределенности недостижимо. Клиенты и пользователи не имеют точного представления о том, что им нужно, до тех пор, пока им не начинают представлять части продукта. После этого они постепенно уточняют свои потребности.

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

Я изобразил кривую в правой части рис. 9.1, чтобы показать предпочтительность раннего снижения конечной неопределенности. Почему, спрашивается, я не провел прямую линию или не построил кривую, свидетельствующую о предпочтительности раннего снижения неопределенности средств? Моя линия отражает важность как можно более раннего снижения неопределенности, связанной с тем, каким должен быть продукт. Нет необходимости устранять конечную неопределенность в самом начале (как предполагает традиционный подход), даже при желании это невозможно. Вместе с тем один из самых серьезных рисков в большинстве проектов — это риск создать несоответствующий продукт. Данный риск можно резко снизить через разработку на раннем этапе тех функций, которые быстрее всего позволяют представить или передать работающую программу реальным пользователям.

 

Риск

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

• Риск срыва графика («Мы можем не успеть завершить работу к октябрю»).

• Риск увеличения затрат («Мы можем не найти аппаратные средства с подходящей ценой»).

• Риск функциональности («Мы не обязательно сможем реализовать это»).

Помимо этого, риски можно классифицировать как технологические или деловые.

Классическое противоборство в проекте наблюдается между функциями с высоким риском и функциями с высокой стоимостью. Следует ли проектной команде сначала сконцентрироваться на функциях с высоким риском, которые могут пустить под откос весь проект? Или ей лучше сосредоточить внимание на том, что Том Гилб (Tom Gilb, 1988) назвал «сочными кусками», — на функциях с высокой стоимостью, которые приносят больше всего клиентских долларов?

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

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

Наиболее целесообразная последовательность разработки функций показана на рис. 9.3. Функции с высокой стоимостью и высоким риском следует разрабатывать в первую очередь. Эти функции приносят наибольшую стоимость, а работа над ними устраняет значительные риски. Следующие на очереди — функции с высокой стоимостью и низким риском. Они приносят такую же стоимость, как и предыдущие, но менее рискованны. Как результат, ими можно заняться позднее. Возьмите за правило заниматься сначала функциями с высокой стоимостью, а риск используйте в качестве дополнительного фактора.

Затем идут функции с низкой стоимостью и низким риском. Ими занимаются в третью очередь, поскольку они меньше влияют на совокупную стоимость продукта в случае отказа от них и связаны с низким риском.

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

 

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

 

Создание инфраструктуры

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

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

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

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

 

Дизайн пользовательского интерфейса

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

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

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

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

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

 

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

 

Новый доход

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

 

Прирост дохода

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

• Создает стимулы для приобретения дополнительных лицензий существующими клиентами.

• Содержит опциональные модули расширения, которые можно продавать отдельно.

• Содержит функции, которые позволяют устанавливать более высокую цену.

• Создает стимулы для использования консультационных услуг (например, по интегрированию с приложением стороннего производителя).

 

Сохраненный доход

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

 

Операционная эффективность

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

Зачастую побудительным мотивом повышения операционной эффективности является ожидаемый рост. Неэффективность, которая может не слишком беспокоить вас сегодня, быстро превращается в проблему, когда компания становится значительно крупнее. Предположим, например, что ваша компания создала веб-сайт по продаже рам для картин. Вы предлагаете на продажу не только огромный набор стандартных рам, но и рамы, изготовленные на заказ. Бизнес развивается хорошо, и компания ожидает значительного роста в течение ближайших двух лет. Точнее, она ожидает десятикратного роста продаж за этот период. Как и в любом бизнесе, определенный процент проданных товаров возвращается компании. Автоматизация учета возвращенного товара никогда не имела высокого приоритета, и в настоящий момент возвратом занимается один человек в течение двух часов в день, включая учет запасов и перечисление средств на кредитную карту покупателя. Два часа, потраченные на этот процесс, могут не представлять проблемы сегодня. Однако с увеличением объема продаж на 1000 % объем возврата, скорее всего, также вырастет на 1000 %, и на его обработку потребуется уже 20 человеко-часов в день. В такой ситуации есть все основания задуматься, не приводит ли этот процесс к неэффективности, которую необходимо устранить.

При поиске возможностей повышения операционной эффективности следует обращать внимание на следующее:

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

• Улучшение интеграции или коммуникации между отделами.

• Снижение текучести кадров.

• Сокращение времени обучения новых сотрудников.

• Любые чувствительные к срокам выполнения процессы.

• Объединение нескольких процессов.

• Все, что повышает точность и уменьшает переделку.

 

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

В текущий момент мы говорим клиентам, что они должны вводить информацию о заработной плате на наш веб-сайт за три дня до момента выдачи чеков работникам. Наша цель в новой системе — предложение услуги с исполнением на следующий день. Если информация о заработной плате будет введена на сайт WebPayroll до 17:00, то мы сможем сгенерировать чеки, распечатать их и поставить заказчику на следующий рабочий день. Чеки будут вручены клиентам на следующее утро.

Прежде чем начинать оценку дохода от проекта обслуживания на следующий день, необходимо определить, когда он будет реализован. Допустим, разработчики уже оценили истории в этой теме в 150 пунктов. При исторической скорости команды, равной 20 пунктам за двухнедельную итерацию, разработка темы займет 150 / 20 = 7,5 ≈ 8 итераций. Это означает, что повышения дохода и операционной эффективности можно ожидать только после восьмой итерации (если, конечно, нам не удастся поставить частичное решение, что всегда должно быть одной из целей).

 

Определение нового дохода

Предложение обслуживания на следующий день вместо обслуживания через три дня открывает возможности получения нового дохода. Чтобы оценить эти возможности количественно, оценим сначала число новых клиентов, которых мы сможем приобрести. Надежных данных у нас нет. Однако наш торговый представитель Терри говорит, что примерно треть клиентов, с которыми она общается, отказываются от WebPayroll из-за необходимости подавать информацию за три дня. На основе текущих прогнозов по продажам Терри считает, что сможет привлекать в этом году 50 новых клиентов в квартал, а в следующем году — 100 клиентов в квартал. Эти значения включены в колонку «Новые клиенты» табл. 10.3. Хотя функция обслуживания на следующий день появится лишь в середине второго квартала, Терри уверена, что уже в этом квартале привлечет 50 новых клиентов.

Теперь оценим доход на клиента. Это можно сделать, опираясь на данные по существующим клиентам. Нам известно, например, что средний клиент WebPayroll платит нам $400 в год. Однако мы считаем, что услуга с исполнением на следующий день будет наиболее привлекательна для мелких клиентов, тех, которые платят нам в среднем $200 в год. На наш взгляд, можно рассчитывать на дополнительные $100 в год от каждого такого клиента. Совокупная стоимость каждого нового клиента, таким образом, составляет $300 в год, или $75 в квартал. Поскольку обслуживание на следующий день будет доступно на протяжении лишь двух третей второго квартала, доход на клиента в этом квартале пропорционально уменьшается. Эти величины добавляются в колонку «Доход на клиента» в табл. 10.3, которая позволяет определить значения для колонки «Новый доход».

 

Определение прироста дохода

Под приростом дохода понимается дополнительный доход, который мы можем получить от существующих клиентов. На основе наших знаний о существующих клиентах — как часто они опаздывают с подачей информации о заработной плате и т. д., мы считаем, что сможем привлекать примерно по 100 клиентов в квартал до тех пор, пока все 400 существующих клиентов не перейдут на обслуживание на следующий день. Что касается новых клиентов, то услуга будет генерировать примерно по $100 в год, или $25 в квартал после того, как она появится во втором месяце второго квартала. Для расчета совокупного прироста дохода в квартал на основе этих данных сформирована табл. 10.4.

 

Определение сохраненного дохода

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

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

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

 

Определение операционной эффективности

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

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

Бухгалтеры стоят в среднем $20 000 в год. Каждому из них, кроме того, предоставляется место в офисе, определенное оборудование, программное обеспечение и компенсационные выплаты. В сумме эти дополнительные скрытые расходы составляют примерно еще 50 % заработной платы работника. Иными словами, реальная стоимость бухгалтера ближе к $30 000 в год. Это называют полной заработной платой. Количество бухгалтеров, которые не были наняты, и полная заработная плата дают при перемножении операционную эффективность для каждого квартала, как показано в табл. 10.6.

 

Определение затрат на разработку

Для завершения формирования инвестиционного профиля проекта WebPayroll по обслуживанию на следующий день нам необходимо оценить ожидаемые затраты на разработку темы. Чтобы сделать это, посмотрим на заработную плату всех участников проекта (табл. 10.7).

Полная заработная плата в табл. 10.7 рассчитывается путем увеличения заработной платы каждого работника на 50 %. Поскольку итерация занимает две недели, полная заработная плата на итерацию составляет 1/26 величины полной заработной платы. В колонке «Время в проекте» указана доля времени, которая приходится на каждого члена команды в проекте. Все заняты полностью, за исключением одного программиста. В колонке «Скорректированные затраты на итерацию» приведены затраты на проект по каждому участнику с учетом полной заработной платы и времени участия в проекте. В целом затраты команды на итерацию составляют $13 550. Округлим эту величину до $13 500.

Зачастую полезно знать затраты на один пункт (или один идеальный день). Для определения этой величины разделите скорректированные затраты на итерацию на среднюю или ожидаемую скорость команды. Учитывая, что средняя скорость команды WebPayroll составляет 20 пунктов на итерацию, ее стоимость пункта будет равна 13 500 / 20 = 675. Эта информация полезна потому, что, если команду спрашивают, во сколько обойдется разработка элемента, оцениваемого в 100 пунктов, она может сразу дать ответ — $67 500 (100 × 675).

Затраты команды WebPayroll обобщены в табл. 10.8.

 

Сведение всех статей вместе

Результаты анализа затрат, нового дохода, прироста дохода и операционной эффективности сведены вместе в табл. 10.9.

Реализацию функции обслуживания на следующий день предполагается осуществить за восемь итераций, или через 16 недель. На первый квартал приходятся затраты 13 недель в размере $87 750 (13 × 6750). На второй квартал приходятся затраты еще трех недель в размере $20 250.

 

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

 

Временнáя стоимость денег

В одном из первых мультфильмов о моряке Попайе один из персонажей, Вимпи, говорил: «Я с радостью заплачу тебе во вторник за гамбургер, съеденный сегодня». Лишь простофиля мог клюнуть на это предложение Вимпи, поскольку деньги сегодня стоят больше, чем в следующий вторник.

Сегодняшнюю стоимость будущих денег мы определяем с точки зрения того, сколько нужно положить в банк сегодня, чтобы получить будущую сумму. Чтобы купить гамбургер стоимостью $5 в следующий вторник, мне необходимо сегодня положить в банк $4,99. Сумму, которую я должен инвестировать сегодня, чтобы получить известную сумму в будущем, называют приведенной стоимостью. Скажем, если я могу заработать 10 % на вложения и хочу получить $1,00 через год, то сегодня мне необходимо вложить $0,91. Другими словами, при ставке 10 % $0,91 — это приведенная стоимость $1,00 через год. Если бы я мог заработать на мои деньги 20 %, то мне сегодня пришлось бы вкладывать только $0,83.

Процесс приведения будущих сумм к их нынешней стоимости называют дисконтированием. Понятно, что процентная ставка, используемая для дисконтирования будущих сумм, критически важна для определения приведенной стоимости. Ставка, по которой организации дисконтируют будущие деньги, называется альтернативными издержками и отражает процентный доход, от которого отказываются, осуществляя данное вложение. У всех нас — физических и юридических лиц — есть разные возможности инвестирования денег. Я могу разместить деньги на сберегательном счете в банке или вложить в акции, инвестировать их в недвижимость или положить под матрас. Организации могут инвестировать деньги аналогичным образом или вкладывать их в проекты. Если в прошлых проектах организация обычно зарабатывала 20 %, то новые проекты оценивают по такой же ставке — 20 %. Альтернативные издержки организации составляют 20 %, поскольку вложение средств в новый проект означает, что организация отказывается от возможности инвестировать их в какой-либо другой проект, который принесет 20 %.

 

Чистая приведенная стоимость

Первым показателем, который мы рассмотрим в целях оценки темы, является чистая приведенная стоимость (net present value — NPV). Для определения NPV суммируют приведенные стоимости каждой статьи в потоке будущих стоимостей. Для этого используется следующая формула:

где i — процентная ставка, а Ft — чистый денежный поток периода t.

Чтобы понять, как это работает, вернемся к нашему примеру WebPayroll. Как уже говорилось, ожидаемые затраты на проект обслуживания на следующий день составляют $108 000, а генерируемые в результате его реализации доходы и экономия обобщены в табл. 10.9 и воспроизводятся в колонке «Чистый денежный поток» табл. 10.10. Колонка «Коэффициент дисконтирования» в этой таблице представляет собой множитель (1 + i)—t из формулы для расчета NPV и отражает величину, на которую будет дисконтироваться будущий денежный поток. Последняя колонка «Приведенная стоимость» — это произведение чистого денежного потока и коэффициента дисконтирования. Она, например, показывает, что приведенная стоимость $18 250 в конце третьего квартала года составляет $16 701. Сумма значений в колонке «Приведенная стоимость» дает совокупную NPV, равную в нашем случае $46 341.

Достоинством чистой приведенной стоимости при ее использовании для сравнения и приоритизации тем является простота расчета и понятность. Главный недостаток NPV заключается в том, что результаты сравнения значений двух разных денежных потоков могут вводить в заблуждение. Допустим, у нас есть два проекта для выбора. Первый проект требует огромных первоначальных вложений, но имеет NPV, равную $100 000. Второй проект не требует значительных первоначальных вложений и также имеет NPV, равную $100 000. Понятно, что мы предпочтем вложить средства в тему, которая связывает меньше денежных ресурсов и имеет ту же NPV. На самом деле нужно представить доход от темы в процентах, чтобы можно было сравнивать темы напрямую.

 

Внутренняя ставка доходности

Внутренняя ставка доходности (internal rate of return — IRR), которую иногда называют рентабельностью инвестиции (return on investment — ROI), позволяет представить доход от проекта в процентном выражении. Если NPV показывает, сколько денег можно получить от проекта (в сегодняшней, приведенной стоимости), то IRR говорит о том, как быстро растут деньги, вложенные в проект. IRR облегчает сравнение проектов, как это видно из табл. 10.11. Какой проект вы бы выбрали?

Большинство, надо думать, предпочтут получать 43 % на свои вложения, несмотря на то, что у проекта А выше NPV (он к тому же требует более высоких первоначальных вложений). Денежные потоки для этих двух проектов представлены в табл. 10.12.

Многие организации определяют минимально привлекательный уровень доходности (minimum attractive rate of return — MARR). Финансируются только те проекты или темы, у которых IRR превышает MARR. Для NPV такой порог устанавливать нецелесообразно, поскольку значения NPV сильно зависят от масштаба проекта. В случае введения порогового значения для NPV небольшие (но ценные) проекты никогда не получат одобрения.

IRR определяется как процентная ставка, при которой NPV денежного потока равна нулю. Другими словами, это значение i*, при котором

Формула для расчета IRR сложная, и ее рассмотрение выходит за рамки настоящей книги. К счастью, большинство электронных таблиц содержат удобную для использования функцию определения IRR. Если вы хотите рассчитать IRR вручную, обратитесь к работе Стива Токи (Steve Tockey, 2004), который, пожалуй, лучше других объясняет, как это сделать. Вместе с тем даже при использовании электронных таблиц необходимо помнить о нескольких важных предварительных условиях:

• Первая одна или несколько статей денежного потока должны быть расходами. (Обратите внимание на то, что должна быть как минимум одна такая статья.)

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

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

Поскольку денежный поток темы обслуживания на следующий день на сайте WebPayroll удовлетворяет этим условиям, мы можем рассчитать IRR. Чтобы сделать это в Excel, введите в ячейку такую формулу:

+IRR({0, –85750, –14150, 18250, 20750, 29000, 36500, 36500}).

Числа в фигурных скобках — это денежные потоки для каждого из восьми кварталов. Ноль в начале показывает, что предварительные затраты в первый день проекта отсутствуют (они вполне могут и присутствовать, если WebPayroll купит дополнительные серверы для осуществления проекта). Для проекта обслуживания на следующий день на WebPayroll IRR составляет 12 %, т. е. ожидаемый денежный поток эквивалентен получению годового дохода на вложения компании в размере 12 %.

Первым преимуществом использования IRR является отсутствие необходимости определить (или, в худшем случае, угадать) ставку дисконтирования для организации, как это требуется при расчете NPV.

Второе преимущество заключается в том, что с помощью IRR можно напрямую сравнивать проекты. Проект с IRR, равной 45 %, имеет более высокую рентабельность инвестиций, чем проект с IRR, равной 25 %. Впрочем, обычно нельзя использовать для принятия решений только одну IRR. Допустим, проект с отдачей 45 % очень маленький, поэтому 45 % мы получаем от маленькой инвестиции, тем не менее этот проект связывает критически важного разработчика. Предположим далее, что другой проект с отдачей 25 %, но крупной инвестицией также требует участия того же самого разработчика. В этом случае вы можете заработать больше денег на втором проекте, том, где IRR более низкая.

Еще один пример: вы можете выбрать проект с IRR 45 %, который, однако, начинает приносить выдающуюся отдачу только через два года. А проект с IRR 25 % начинает приносить деньги уже через год. Если организация не может позволить себе двухлетние инвестиции, то проект с более низкой IRR становится привлекательным.

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

 

Срок окупаемости

С помощью NPV мы можем представить денежный поток в виде одного показателя — приведенной стоимости. Альтернативно денежный поток можно представить в виде процентной ставки — IRR. Третьим вариантом представления денежного потока является время, необходимое для возврата первоначальной инвестиции. Этот показатель называют сроком окупаемости. Чтобы понять, как его определяют, в табл. 10.13 приведены расчеты срока окупаемости для проекта обслуживания на следующий день WebPayroll.

В первом квартале WebPayroll вкладывает в проект $85 750. Во втором квартале компания делает дополнительное вложение в размере $14 150. В третьем квартале она начинает возвращать вложенные средства и получает $18 250. В какой-то момент в седьмом квартале чистые вложения становятся положительными, поэтому говорят, что срок окупаемости проекта составляет семь кварталов.

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

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

 

Дисконтированный срок окупаемости

Первый недостаток срока окупаемости устранить довольно легко. Для этого нужно просто умножить каждую статью денежного потока на соответствующий коэффициент дисконтирования. Как это делается, показано в табл. 10.14 для проекта обслуживания на следующий день WebPayroll.

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

 

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

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

• линейные функции;

• привлекательные функции.

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

Линейными функциями считаются те, для которых справедливо правило «чем больше, тем лучше». Чем просторнее гостиничный номер, тем лучше. Их называют линейными потому, что удовлетворенность клиентов линейно связана с количеством данных функций. Чем лучше эти функции работают (или чем больше их имеется), тем выше будет удовлетворенность клиентов. Из-за этого цена продукта нередко привязывается к линейным атрибутам. Если в гостинице есть гантели и пара хороших тренажеров «беговая дорожка», то я буду более счастлив, чем при наличии лишь одного старинного тренажера «лестница». Я буду еще более счастлив, если обнаружу там еще силовой тренажер и велотренажер. Для гостиницы в этом важно то, что я с большей вероятностью остановлюсь в ней еще раз и заплачу более высокую цену за номер.

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

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

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

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

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

Учтите, что функции на диаграмме Кано со временем смещаются вниз. Еще совсем недавно беспроводной доступ в интернет в гостиничном номере был привлекательной функцией. Сейчас это уже линейная функция, которая вот-вот станет пороговой.

 

Оценка тем по модели Кано

Самый простой подход к использованию модели Кано в agile-проекте — анализ всех тем и их грамотная разбивка по типам. Намного лучше, однако, определить тип каждой темы совместно с клиентами или пользователями. Это на удивление легко, поскольку можно использовать письменный опросный лист. Для точной приоритизации требований опросный лист, возможно, придется направить 20–30 пользователям (Griffin and Hauser, 1993).

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

1. Мне это нравится.

2. Я ожидал, что это будет выглядеть так.

3. Мне безразлично.

4. Я могу смириться с этим.

5. Мне это не нравится.

В качестве примера вспомним наш веб-сайт SwimStats. Допустим, мы собираемся добавить три новые функции:

• Возможность видеть график результатов пловца в соревнованиях прошлого сезона.

• Возможность для пловцов размещать информацию о своей специализации.

• Возможность для любого зарегистрированного члена сайта загружать фотографии.

Чтобы определить типы этих функций, мы проводим опрос потенциальных пользователей, задавая им следующие вопросы:

• Если бы была возможность построить график результатов пловца в соревнованиях прошлого сезона, как бы вы к этому отнеслись?

• Если бы не было возможности построить график результатов пловца в соревнованиях прошлого сезона, как бы вы к этому отнеслись?

• Если бы у пловцов была возможность размещать информацию о своей специализации, как бы вы к этому отнеслись?

• Если бы у пловцов не было возможности размещать информацию о своей специализации, как бы вы к этому отнеслись?

• Если бы была возможность загружать фотографии, как бы вы к этому отнеслись?

• Если бы не было возможности загружать фотографии, как бы вы к этому отнеслись?

Первая пара этих вопросов и гипотетические ответы одного из пользователей приведены на рис. 11.2.

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

 

Категоризация ответов

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

Если повторить этот процесс с 20–30 пользователями, то их ответы можно сгруппировать и определить распределение, как показано в табл. 11.1. Анализ таблицы показывает, что построение графика результатов соревнований является одномерной (линейной) функцией, а загрузка фотографий — обязательной функцией.

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