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