1. Поймите цель
Давайте разберём типичный для разработки ПО случай.
Допустим, заказчик хочет повысить доходы. Он решает добиться этого за счёт увеличения количества заказов в 2 раза. Это его цель, она обозначена на рисунке зелёным кружком с правой стороны.
Далее заказчик начинает перебирать возможные пути достижения этой цели. Как правило, всегда есть несколько вариантов решения (правый столбец из пунктирных кружков): расширение ассортимента, снижение цены, дополнительные услуги. Выбрав один из таких вариантов заказчик окажется перед очередным выбором (средний столбец из пунктирных кружков): за счёт чего расширить ассортимент, насколько снизить цены, какие услуги предложить. Последовательность принятых решений составляет цепочку рассуждений заказчика (голубые стрелки). В какой-то момент эта цепочка приводит заказчика к формулированию задачи для разработчиков ПО (сиреневый кружочек с левой стороны).
Здесь и возникает распространённая проблема: разработчикам доводится только формулировка задачи, а цель и цепочка рассуждений остаются неизвестными.
Подсознательно заказчик ожидает от разработчиков, что они пройдут его цепочку рассуждений в обратном порядке, что и приведёт к цели. Фактически же разработчики, как и заказчик ранее, почти всегда имеют возможность выбора из нескольких вариантов решения. Последовательность таких выборов складывается в цепочку рассуждений разработчика (жёлтые стрелки).
Без знания цели цепочка рассуждений разработчика может не совпасть с цепочкой рассуждений заказчика, и в итоге не привести к поставленной цели (красная стрелка).
Метод пяти «для чего»?
Лет сто назад Сакити Тоёда (человек, во многом благодаря которому появилась Производственная система «Тойоты», из которой выросли Канбан, бережливое производство и методики гибкой разработки) сформулировал правило пяти почему для поиска первопричины какой-либо проблемы.
Правило очень простое: чтобы найти первопричину надо пять раз повторить вопрос «почему?», при этом каждый последующий вопрос задаётся к ответам на предыдущий. Суть в том, что часто настоящая причина не лежит на поверхности, но до неё можно докопаться вот таким последовательным углублением.
Принцип, положенный в основу этого подхода, даёт хорошие результаты и во многих других случаях. В частности он прекрасно подходит для выяснения цели задачи. Как это работает?
Пример из жизни. Нам поступил заказ — разработать язык описания кредитных правил для предварительного расчёта условий кредита. При этом программисты заказчика уже разработали прототип, который нам предлагалось довести до рабочего состояния. Прототип был написан технически грамотно, использовал функциональную парадигму и содержал набор предикатов из которых и строились кредитные правила. В целом решение вполне соответствовало поставленной задаче.
Но мы начали с выяснения конечной цели. Для этого мы использовали метод пяти «для чего?» и упрощённо наше общение с заказчиком выглядело так.
Обычно, как только сказано слово «деньги», можно останавливаться.
Итак, что же мы узнали?
Язык нужен для минимизации рисков финансовых потерь из-за неправильного расчёта условий кредита.
Языком будут пользователя аналитики.
Важно минимизировать время, уходящее на обновление правил.
Из этого мы сделали следующие выводы.
Язык должен быть максимально простым. Во-первых, потому что им будут пользоваться люди, далёкие от программирования. Во-вторых, чтобы минимизировать риск ошибок и время на внесение изменений.
Парадигма, заложенная в прототип, не подходит, т. к. слишком сложна для аналитиков и они, скорее всего, изменения будут вносить долго, а ошибаться часто.
В итоге мы полностью изменили парадигму языка и весь подход к работе с кредитными правилами.
Если бы мы не докопались до глубинных целей и не получили сопутствующие сведения, то получившийся язык не помог бы заказчику достичь желаемых целей. Вместо уменьшения ошибок и сокращения времени на внесение изменений, велика была вероятность получить прямо противоположный результат.