Agile или управление жизненным циклом
С первого взгляда Agile и гибкость предполагает в первую очередь краткосрочную расстановку приоритетов, в то время как формальное управление жизненным циклом продукта — это нечто совершенно противоположное, а именно весь спектр изменений, сопровождающих существование продукта с момента разработки до момента наступления полной непригодности. Тогда как определить связь между этими двумя категориями? Как раз в этот момент и выходит на передний план ценность продукта.
Что влияет на ценность продукта?
Если подойти к этой запутанной проблеме с точки зрения философии и начать задавать вопросы, то первым из них, и главным, будет вопрос: для кого производится продукт? Ответ на него прост: для пользователей. А с чем пользователи ассоциируют выгоду, полученную от использования продукта, за который они заплатили? Ответ снова прост: с номинальной ценностью продукта. Это базовое определение ценности продукта. За многие годы это определение отошло от своего первичного значения и превратилось в стремительно развивающуюся категорию, содержащую в себе понимание ценности продукта. Так происходит оттого, что само понятие ценности и ее определение претерпели ряд существенных изменений за последние 10 лет.
Из чего состоит ценность моего продукта?
В поисках ответа на этот вопрос (каково истинное определение стоимости продукта?) я обработал множество самых различных источников, где с разных точек зрения говорилось о процессе оценки и жизненном цикле продукта в сфере производства ПО. Но мне так и не удалось разработать комплексный подход. В результате я нашел ответ там, где меньше всего ожидал.
Все началось с ни к чему не обязывающей беседы за обеденным столом, когда я обменивался мнениями о направлениях развития отрасли с генеральным директором одной весьма известной и уважаемой компании, получающей прибыли от производства и разработки более чем на 2 млрд. долларов (говорю об этом для того, чтоб читатель получил представление об уровне серьезности мнений). Темой обсуждения было то, насколько стирается граница между продуктом и услугой на нынешнем этапе развития технологий. Вскоре я стал связывать понимание этого явления с Agile и Scrum. Все оказалось банально просто — граница стиралась не просто между продуктом и услугой самими по себе. Скорее, чувствительность и восприимчивость крайне изменчивого рынка были и остаются причинами напряженности в бизнесе, связанном с технологиями.
За прошедшие 10 лет давление на производителей продуктов и услуг в этой высоко конкурентной отрасли выросло экспоненциально. Свою лепту внесло и ужесточение экономических условий во всем мире — крупные и мелкие компании должны гораздо более гибко и динамически подходить к производству ПО.
Вы получаете то, за что заплатили!
В то время, как этот девиз может быть актуальным для других продуктов и ресурсов (где премиум-класс отвечает высоким требованиям к продукту), в сфере технологий он выглядит сомнительно и вызывает ряд забавных аналогий. Как выяснилось, исследования говорят о том, что 45% полезных свойств некоторых продуктов никогда (вообще никогда) не используются большинством людей.
Так что для производства ПО образца 90-х более подходящим слоганом был бы такой:
ВЫ ПЛАТИТЕ ЗА ТО, ЧЕМ ВООБЩЕ НЕ ПОЛЬЗУЕТЕСЬ!
Теперь, попробуйте защитить убедительность такого слогана хотя бы перед продажником, не говоря уж о покупателе!
Доказательства прилагаются:
Источник: Джим Джонсон, The Standish Group International Inc. 2002
Вы, конечно же, шутите, мистер Фейнман
Человеку непосвященному, наверное, не так очевидно, к чему это все и как оно соотносится с Agile или Scrum. Но более опытному специалисту было бы вполне понятно. Если вы добавите еще один параметр, а именно момент, с которого Agile-методология начала признаваться как приемлемая практика, то сразу станет ясно, что это не просто совпадение: гибкая методология разработки получила признание в прошлом десятилетии и из просто «неплохой теории» превратилась в широко применяемую практику. И это было именно то десятилетие, когда произошел технологический бум и когда модель водопада (waterfall) стала основной моделью разработки ПО и решений.
Не нужно быть гением, чтоб сложить все это в одну картину и понять, по какой причине с появлением модели водопада ценность продуктов для пользователей снизилась:
- Возможности продукта разрабатывались специально для целевой группы, которая менялась быстрее, чем происходил выход на рынок, — продукт обладал возможностями, которые на момент выхода уже не были востребованы.
- Отдача от продукта не соответствовала ожиданиям – многообещающие технологии оказывались на обочине, поскольку они не были достаточно гибкими, чтоб существенно менять направление по ходу разработки.
- Ценность продукта заключалась не только и не столько в количестве патентов, задействованных в его разработке, и их гениальности, — поверьте, это сыграло большую роль — сколько в том, какую часть этой ценности составляла добавленная стоимость. Это означало, что требования необходимо было менять постоянно, нельзя было позволить себе тратить по полгода на оттачивание важного решения для какой-либо проблемы. Крайне важно было уметь лавировать, чтоб провести продукт сквозь изменчивые условия на каждом из этапов его жизненного цикла.
Кривая приживаемости технологии
Y: инноваторы, первые приверженцы, раннее большинство, позднее большинство, отстающие
Х: поиск ниши, монетизация, увеличение выгоды, снятие с производства и прекращение поддержки.
Этот график весьма нагляден: процесс приживаемости технологии соотносится с ключевыми группами, применяющими ее на различных стадиях жизненного цикла продукта. Инноваторы подготавливают все для того, чтоб первые приверженцы испробовали продукт и продемонстрировали его состоятельность раннему и позднему большинству, которое вложит в продукт деньги и на смену которому в последствии придут отстающие пользователи, которые «спасут» валовую прибыль от падения благодаря своей многочисленности. На оси Х расположены стадии жизненного цикла продукта, начальным и конечным пунктами которого являются поиск ниши и снятие с производства соответственно.
Читателям, мыслящим математически, эта Гауссова кривая легко проиллюстрирует сегодняшнюю ситуацию на рынке. Для далеких от математики поясню: размах использования продукта на каждой из фаз его жизненного цикла стремительно сокращается. Если раньше можно было потратить на разработку полтора года, то сейчас эти временные рамки должны сократиться по крайней мере вдвое. Это не значит, что количество людей, занятых в разработке, надо удвоить, и не значит, что разрабатывать и внедрять новые продукты стало легче. Так что единственным параметром, который поможет восстановить баланс, являются адаптивность и, в меньшей мере, эффективность.
Выводы
Если принятие решений руководством будет ориентировано на адаптивность, и перемены будут восприниматься как нечто неизбежное — а сейчас это необходимо как никогда ранее — то останется только один способ производить работающее ПО, необходимое пользователям. И все это только благодаря Agile-методологии и использованию Scrum в качестве подспорья в процессе. Кому-нибудь есть что возразить?
