Hypothesis-Driven Problem Solving звучит так, будто сейчас в комнату войдёт консультант...
Hypothesis-Driven Problem Solving звучит так, будто сейчас в комнату войдёт консультант с ноутбуком под мышкой и спросит с порога: «А вы это гипотезой проверяли?» На деле за термином стоит принцип, которым люди иногда пользуются и без названия: не собирать сразу все версии происходящего, а выдвинуть одну, довести её проверку до конца и только потом переходить к следующей. Термин выглядит как что-то из мира консультантов с презентациями и слайдами по 40 пунктов. Кажется, что без диплома MBA и доступа к аналитикам туда лучше не соваться. Путаница возникает из-за упаковки, а не из-за содержания: консалтинговые фирмы заворачивают простую мыслительную операцию в рамки и терминологию, потому что это часть их продукта. Сама операция внутри упаковки устроена проще, чем её название. Но у неё есть чёткая структура из семи шагов, и без неё разговор про этот метод превращается в анекдот в духе «мне сосед Рабинович напел»: вроде бы про метод, а на деле пересказ одной идеи чужими словами. Вот все семь шагов целиком, на примере ремонта моста. 1. Определить проблему. Не абстрактное сомнение, а точный вопрос. В этом проекте вопрос звучал так: за счёт чего экономически оправдана модернизация именно этого участка. Дома вопрос был бы таким же конкретным: откуда капает вода. 2. Разложить проблему на гипотезы. Крупный вопрос делят на конкретные, проверяемые версии – дерево вариантов, а не одна догадка. У моста таких версий было минимум две: ценность в приросте трафика или в предотвращённом обрушении. Дома дерево ещё короче: свой кран, стояк, звуковая галлюцинация. 3. Расставить приоритет. Из всех версий выбирают одну – самую вероятную или самую дорогую в случае ошибки. Рост трафика был самой очевидной гипотезой, с неё и начали. Дома точно так же: свой кран проверяют первым, а не сразу бегут к соседям. 4. Составить план проверки. Прежде чем считать, решают, какие данные нужны и откуда их взять. Для первой гипотезы это были данные о трафике и прогноз его прироста. Дома план ещё короче: дойти до крана и посмотреть, закрыт ли он. 5. Довести анализ до конца. Это тот самый шаг, где чаще всего срываются. Расчёт по первой гипотезе довели до конца, а не бросили на середине: цифры показали, что прирост трафика слишком мал для окупаемости. Дома это значит не поверить соседу на слово, если он с порога говорит «у меня всё в порядке», а зайти и проверить самому: уверенный тон – не доказательство, доказательство – то, что вы увидели своими глазами. 6. Собрать выводы воедино. Результат первой гипотезы не означал «проекта не будет» – модернизация была объективно нужна. Он означал «причина в другом», и это подтолкнуло к следующей версии: ценность не в потоке машин, а в том, что случится при износе опор. Дома то же самое: если все свои краны закрыты, вода всё равно капает – значит, причина не у вас, а дальше по цепочке. 7. Сформулировать рекомендацию. Вторую гипотезу проверили тем же способом – до конца, несмотря на предложения посчитать быстрее и удобнее, которые ещё неизвестно, что бы показали, доведи их кто-то до конца. Расчёт подтвердил: при определённом износе опор риск обрушения моста становился реальным, а не теоретическим. Итоговое экономическое обоснование построили именно на этом, а не на приросте сборов. Дома рекомендация была бы такой же конкретной: идти к соседу с проверенным фактом, а не с догадкой, а если не поможет – вызывать сантехника. Семь шагов, и ни один нельзя пропустить без потери смысла. Пропустите четвёртый – останетесь без данных для проверки. Бросите пятый на середине – получите не метод, а гадание с научной репутацией. У Hypothesis-Driven Problem Solving нет одного автора и одной даты рождения – в отличие, например, от пирамиды Минто, у которой есть конкретный автор, Барбара Минто, и даже год выхода книги, 1985 (про неё был отдельный пост: https://t.me/TagnaFinance/33). Корень метода – в научном методе: сформулировать проверяемую гипотезу до того, как начать собирать данные, а не подгонять объяснение под уже собранный ворох