Метод проверки гипотез
В нескольких предыдущих статьях критиковал популярные подходы в работе: ТЗ, сроки, совещания и иногда даже тестирование. Не на шутку раздраженный читатель спросит: "А делать то что? Чем это заменить? Критикуешь - предлагай!" А выход есть, он очень простой и подсказывает его сама жизнь...
Начну опять с будней автолюбителя. Напомню, что родом я из Сибири и там провел большую часть жизни. А что важнее всего для эксплуатации автомобиля холодными зимами - чтобы заводился и не буксовал на скользкой дороге. Одно время покупал дорогие, мощные аккумуляторы. Продавец не стеснялся показывать как бодро стрелка измерительного прибора доходит до необходимого значения и даже зашкаливает. Но через год состояние становилось ровно таким же, как у дешевых собратьев. Как говорилось в старой рекламе: "Если нет разницы, зачем платить больше". Сделал вывод, что к аккумулятору надо относиться как к расходному материалу, главное, чтобы ставить новый перед холодами. Пробовал шины разных производителей и однажды решил, что финны о зиме знают побольше, чем жители более южных стран, купил финскую резину и она подошла моей машине оптимально. Ну то есть не надо верить рекламе и продавцам. Надо пробовать и выбирать наиболее подходящее.
Во всех других бытовых делах мы тоже пробуем и выбираем. Ну нет такого, чтобы составили техническое задание на ужин в ресторане, долго читали отзывы, выбирали блюда по картинкам на сайте, наконец решились, пришли и все понравилось. Мы ходим в самые разные заведения общепита, сравниваем, а потом в понравившиеся ходим чаще. Мы пробуем разную одежду, обувь, продукты, магазины, службы доставки, банки и все остальное.
А теперь перейдем к бизнес-процессам и учетным системам. Заказчик никогда не знает, чего конкретно он хочет, ему просто надо чтобы все работало, чтобы было удобно и сотрудникам, и покупателям. Да и кто такой этот заказчик? Директор, принимающий решение, но не знающий как включить компьютер или пользователь, который непосредственно будет вводить данные? Почему мнение одного важнее мнения другого? И вот однажды, в одной статье (сейчас не найду) прочитал про разработку через гипотезы. Изначально никто не знает как правильно, как будет лучше. Поэтому разрабатываем два или больше вариантов, проверяем их в эксплуатации и на основании понятных метрик, лучше количественных, еще лучше денежных, делаем вывод и используем то что понравилось. Чтобы избежать влияния сезонности спроса, проверять можно параллельно на разных филиалах. Можно проводить более одной итерации проверки.
Задумался. И вдруг понял, что так всегда и делал сам и старался работать в компаниях практикующих подобный подход. Да скорее всего неосознанно такое применяют многие, но по мелочи. Я же предлагаю использовать метод проверки гипотез вообще всегда и везде, ну конечно кроме реализации требований государства. И даже при неудачной попытке внедрения дорогостоящей модной системы, когда вы вдруг поняли, что эксплуатацию этого чуда вам не потянуть и не прокормить. Ничего страшного, признайте ошибку, купите более дешевый аналог и попробуйте его. Самое интересное, что вы вовсе не выбросили деньги не ветер. Вы заплатили за хорошее практическое обучение. А финансовые потери будут, если с упорством продолжите использовать то, что не подходит.
Метод проверки гипотез в простонародье называется методом проб и ошибок. В англоязычной бизнес-культуре он имеет два терминологических варианта:
- Test & Learn (Проверяем и учимся).
- HADI-циклы: Hypothesis, Action, Data, Insights - Гипотезы, Действие, Данные (сбор данных), Инсайты (озарение, понимание, знание, выводы).
При использовании метода проверки гипотез органично исправляются все недостатки других современных подходов. Все встает на свои места.
- Не надо подолгу заниматься словесными дуэлями на совещаниях. Просто решаем реализовать обе альтернативы и посмотреть, что лучше.
- Невозможно составить точное ТЗ? Оно и не нужно. Достаточно примерного. При проверке гипотез требования естественным образом уточнятся.
- Невозможно полное тестирование перед внедрением? Не беда. Проверочная эксплуатация все протестирует.
- Становятся бессмысленными жесткие строки. Действительно, что имеется в виду: время разработки, период тестовой эксплуатации, исправление обнаруженных ошибок, запуск в работу? Если на проверку мы отводим месяц, то сколько должна быть разработка, две недели? Почему мы на этой стадии торопимся? А если мы получим ответ на поставленный вопрос быстрее запланированного, то не надо ждать срока, можно спокойно прервать эксперимент. Дедлайн у гипотез может быть только гипотетическим :-)
- Самое главное - как класс отсутствует негатив от отрицательного результата. Ведь мы просто проверяли. Не получилось - выяснили очень важные причины, например отсутствие в системе необходимых данных, о котором даже не предполагали. Засучили рукава, на следующей итерации HADI-цикла внесли необходимые корректировки и снова проверяем и учимся...
Какие есть минусы. Я вижу только два.
- Метод проб и ошибок неприменим, если результат невозможно исправить. Например, попробовали стоматологию, в которой зубы умеют только удалять. Назад уже не вернуть.
- Необходимо чувство меры. Нельзя кошмарить сотрудников непрерывным изменением бизнес-процессов. А менеджмент иногда может превратить любую хорошую идею в водевиль.
Эта статья является ответом на проблемы поставленные в других моих статьях. Поэтому собственный вывод тут наверно не нужен. Скажу кратко, метод проверки гипотез тоже всего лишь гипотеза. Попробуйте и сделайте собственный вывод.
P.S. А еще мутация и естественный отбор в эволюции - это все тот же метод проб и ошибок...