"Бритва Оккама": ACC-методология от Google

Давайте я покажу вам, как выглядят мечты и амбиции среднестатистического фаундера(заказчика) при планировании продукта: 

Продукт его мечты - эдакий супермультитул, с помощью которого можно решить любую проблему. Еще и ногти подстричь. 

А теперь давайте посмотрим, как выглядит в представлении tech-lead'а работа по планированию такого проекта:

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

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

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

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

Итак, погнали.

Еще раз взглянем на то, как наш заказчик видит продукт мечты:

Но давайте задумаемся, нужен ли подобный продукт пользователю? 

• Удобен ли он в использовании? 
• Надежен ли продукт, состоящий из огромного количества связанных между собой компонент?
• Является ли необходимым использование широкого спектра возможностей, если, согласно анализу рынка, пользователям продукта-конкурента необходимо решение только узкого круга задач?
• Сказывается ли излишняя функциональность на цене продукта?
• Насколько легок продукт в поддержке при непредвиденных ситуациях? 

Можно сформулировать еще уйму подобных вопросов, ответив на которые, мы осознаем, что в отличии от видения заказчика, клиент хочет пользоваться примерно таким продуктом: 

а в некоторых случаях, даже вот таким: 

Итак, давайте попробуем превратить то, что видит заказчик в то, что любо сердцу и кошельку пользователя.
И поможет нам в этом АСС-методология.

АСС - это аббревиатура, состоящая из трёх слов: Attribute, Component, Capability(Атрибут, Компонента, Способность). 

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

И, раз уж мы заговорили об оружии, давайте рассмотрим всю эту историю на примере туристического ножа.

Будь я производителем туристических ножей, для меня атрибутами продукта были бы: 

• Надежность
• Безопасность
• Комфорт
• Стильность
• Долговечность

Пройдемся подробнее по каждому из атрибутов: 

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

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

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

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

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

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

Не стоит растекаться мыслью по древу. Выделите до десятка самых необходимых атрибутов и работайте с ними. 

Когда атрибуты системы описаны, приходит время переходить к описанию компонент. Итак, компоненты — это составляющие части, определяющие наш продукт, как единое целое.

Мой туристический нож состоит из таких компонент: 

• Лезвие
• Ручка
• Стеклобой
• Петля под темляк

Конечно, список можно было бы урезать до лезвия и ручки, но, как было сказано раньше, наш нож должен быть комфортным. А значит, последние два пункта must be.

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

А теперь самое интересное. :)
Способности продукта рождаются на пересечении его атрибутов и компонент. Тогда, когда прилагательное встречается с существительным. Давайте попробуем сообразить небольшой списочек способностей нашего туристического ножа: 

• Надежность + лезвие = устойчивость к воздействию плотных металов и камня.
• Комфорт + петля под темляк = возможность использования шнура разной ширины в качестве темляка.
• Стильность + лезвие = персональная гравировка лазером на каждом клинке. 
• Комфорт + ручка = эргономичная конструкция ручки
• Комфорт + ручка = приятный для хвата материал ручки

И так далее... 

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

После того, как все пересечения-способности прописаны, начинается следующий этап планирования - оценка рисков.
Допустим, что в результате определения ACC-составляющих, у нас получилась следующая матрица:

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

Рассмотрим этот шаг подробнее. Допустим, если на пересечении атрибута безопасность и компоненты ручка стоит цифра "1". Это значит, что всего в плане у нас есть одна способность функционала продукта, связанная с безопасностью ручки. 

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

Можно слегка упростить себе работу, и сделать "тепловое" покрытие по данной таблице, упростив визуальное восприятие содержимого. 

Наиболее "сочным" цветом обозначены области с наибольшими рисками, на которых необходимо сосредоточиться. Почему риски наибольшие? Потому что для обеспечения качества данной связки атрибут + компонент необходимо сделать больший объем работы. 

Чем тусклее цвет, тем меньше приоритет в проработке именно этих частей продукта. 

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

Подводим итоги 

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

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

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

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

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

И напоследок, хочу пожелать всем, кто планирует заниматься бизнесом в IT, только одно: 

Хороших выходных, котаны! :)