В 1985 году Дэвид Дойч первым описал квантовую машину Тьюринга. Позже он соединил идеи Поппера, Докинза, Эверетта и того же Тьюринга в теорию разумных объяснений. А недавно я обнаружил, что улучшаю процессы разработки банковских продуктов на основе его подхода к методологии науки.
Привет. Меня зовут Дима Мурзин.
По профессии я бизнес аналитик в сфере финансов, работаю с бизнес-стейкхолдерами и с командой разработки, в которой исполняю роль Product Owner. Третий год живу с семьёй в Нью-Йорке.
Когда я жил в Петербурге, мне посчастливилось поработать в команде, в которой был очень хорошо поставлен SCRUM процесс. Во многом, это произошло благодаря тому, что продакт менеджер со стороны заказчика очень глубоко понимал принципы Agile, а также знал, как должен быть устроен SCRUM с точки зрения всех практик и церемоний. В Одном Большом Европейском Банке (на который я работал) это было большой редкостью. Также, я должен отметить мой непосредственный менеджмент со стороны компании подрядчика. Они наняли хорошего коуча, который посвятил нас в процесс и следил за нами еще несколько недель, дали нам полную свободу дуйствий и ответственность за продукт, а после этого вмешивались лишь если возникали серьезные проблемы, что случалось редко. Кроме того, они занимались хайрингом и подбирали людей, которым подходила работа в условиях постоянных изменений.
После того как я переехал в США, ближе к заказчику (и попал в совершенно другую команду, в которой никаким Agile и не пахло), я пытался анализировать, почему моя предыдущая команда была настолько эффективной и продуктивной и почему, вообще, я знал, что команда настолько хороша? С точки зрения бизнес-результата, это было вовсе не очевидно. Продукт, который мы делали, был инфраструктурный (т.е. сам по себе он прибыль не приносил), а Один Большой Европейский банк за время, пока я в нем работал, потерял в цене акции чуть ли не вдвое, поэтому оценить пользу для бизнеса было сложно.
Может быть, я просто обманывал себя, команда была обычной, а никакой супер-продуктивности не было? Однако, у меня было учтойчивое ощущение, что это не так, и я пытался разобраться, откуда оно взялось. В это время я прочитал книгу Дэвида Дойча “Начало Бесконечности” и в ней нашел теоретическую основу, объясняющую, почему команда была продуктивной (в дальнейшей своей деятельности, я попытался определить верна ли эта теория с помощью эксперимента).
Ниже по тексту я использую Заглавные Буквы для обозначения Важных Понятий.
Для себя я коротко называю этот теоретический подход Теорией Разумных Объяснений Дэвида Дойча (ТРОДД). Я постараюсь описать его ниже, но т.к. я не теоретик, а практик, то всех желающих более точного академического изложения призываю ознакомиться с первоисточником (Дэвид Дойч — Начало Бесконечности).
Теория Разумных Объяснений Дэвида Дойча
Основное положение ТРОДД — Принцип Поиска Наилучшего Разумного Объяснения (ППНРО).
Чтобы до конца понять ППНРО, нужно вначале понять несколько определений из теории научного познания Карла Поппера.
Карл Поппер полагал, что одни теории лучше, чем другие. Больше всего он не уважал такие теории, которые невозможно было фальсифицировать, например, такие теории, которые можно очень легко варьировать и объяснять ими что угодно. Для того чтобы отделить такие теории и вообще о них не думать, Поппер предложил способ демаркации, т.е. способ отличить научное знание от ненаучного. Научная теория должна быть принципиально фальсифицируемой, т.е. допускать возможность того, что случится нечто (эксперимент), и станет понятно, что теория неверна. Так, например, теория “Все происходит по воле судьбы” не является научной, потому что не существует вообще никакого события, которое могло бы его опровергнуть.
После того, как Поппер отделил ненаучные теории от научных, он начал разбираться с научными. Большинство научных теорий можно было легко фальсифицировать каким-нибудь простым экспериментом и отбросить как неверные. Однако, оказалось что существуют некоторые теории, которые было не так-то легко фальсифицировать. Такие теории были гораздо лучше, чем неверные. Но были ли они правильными теориями? В истории науки было огромное количество примеров, когда казалось что теория верна, но потом новые наблюдения доказывали, что она неверна (канонический пример — частная и общая теории относительности заменили классическую физику Ньютона).
Тогда Поппер выдвинул еще один принцип — принцип фаллибилизма, — утверждающий, что любое научное знание носит лишь гипотетический характер и подвержено ошибкам. По сути, он сказал, что не существует идеальной теории, которая объясняла бы все наблюдаемые факты и исключала бы все не наблюдаемые факты. Таким образом, Поппер предложил шкалу оценки теорий, по которой у ненаучных теорий было ноль баллов, идеальные теории были где-то в бесконечности, а все имеющиеся научные теории болтались где-то между ними, в зависимости от того, сколько фактов объясняла и исключала теория.
В книге Дойча термин “Теория” заменен термином “Разумное Объяснение”. В одной из глав он даже говорит о том, что с удовольствием использовал бы термин “Заблуждение” вместо этих двух терминов, чтобы подчеркнуть, что любая наша теория в чем-то неверна.
Дойч использовал шкалу Карла Поппера, чтобы предложить метод или стратегию действий, которой нужно следовать, чтобы получить ответ на вопрос или решение какой-то проблемы. Эта стратегия изложена в ТРОДД и коротко описана в Принципе Поиска Наилучшего Разумного Объяснения.
Он гласит примерно о следующем:
- Когда люди ищут ответ на вопрос или решение проблемы, правильной стратегией будет Поиск Наилучшего Разумного Объяснения.
- Нужно использовать творческие способности или “Креативность” чтобы придумывать разные Разумные Объяснения (1-ый ингредиент).
- Далее, нужно пытаться опровергнуть эти Объяснения с помощью экспериментов (в том числе мысленных), это называется “Традиция критики” (2-й ингредиент).
- Если не получается опровергнуть, то Объяснение считается рабочим и используется.
- Но попытки найти другие, более хорошие Разумные Объяснения не прекращаются, т.к. согласно принципу фаллибилизма, ни одно Объяснение не может быть признано окончательно правильным.
Т.е. найти Наилучшее Разумное Объяснение невозможно, но пытаться надо, т.к. в процессе поиска можно найти лучшее Объяснение, чем рабочее. Тогда рабочее Объяснение признается ложным, и лучшее Объяснение становится рабочим.
Также, Дойч вводит понятия сферы применимости и объяснительной силы. Сфера применимости — это множество наблюдаемых фактов, которые пытается объяснить теория. Сферы применимости разных теорий могут вообще не пересекаться или пересекаться частично. Объяснительная сила — это мера множества фактов, которые объясняются или исключаются Разумным Объяснением.
Дойч пишет о том, что в большинстве случаев не получается достичь свободной конкуренции между разными Разумными Объяснениями, а происходит это из-за того, что существует много всякой разной Несостоятельной Философии. Философия является несостоятельной, когда она не позволяет реализовать стратегию, описанную в ППНРО, т.е. либо препятствует свободной генерации идей, либо препятствует традиции критики и экспериментального опровержения.
Дойч описывает много направлений Несостоятельной Философии, но два примера я хочу привести в статье, потому что мне приходится очень часто сталкиваться с ними в рабочей практике. Первый пример — это ссылка на авторитет вместо Объяснения (“Я тут менеджер, я лучше знаю!”). Такая философская позиция блокирует любые попытки критики, а также негативно влияет на креативность — процесс создания новых Объяснений. Второй пример — Постмодернизм, или идея о том, что т.к. не существует самого правильного Объяснения (принцип фаллибилизма), то все Объяснения одинаково разумны (отказ от принципа фальсифицируемости). Постмодернизм придает определенную легитимность даже самым вредным и неразумным Объяснениям. Процесс креативности при этом расцветает, но каждая из заинтересованных сторон считает свое Объяснение наиболее разумным, в результате чего критика не приводит к тому, что ложное Объяснение отбрасывается.
Примерно в таком виде я усвоил для себя Теорию Разумных Объяснений Дэвида Дойча.
Причем же тут SCRUM?
Я понял что SCRUM — это очень удобный фрэймворк для организации процессов согласно ППНРО. И ключевые процессы в нашей команде были устроены именно таким образом. Мы решали проблему “Как максимизировать пользу для бизнеса?”. Более частные проблемы, которые вытекали из основной проблемы, были:
Что нужно делать? Что делать следующее? — Основной вопрос приоритизации бэклога.
Как нужно делать? — Т.е. каким должно быть решение, какая у решения должна быть архитектура?
Как нужно работать? Каким должен быть процесс?
Для ответа на каждый из этих вопросов был устроен процесс, в котором несколько человек выдвигали свою версию Разумного Объяснения, почему делать нужно именно это. Далее происходило обсуждение, в ходе которых одна из версий принималась как рабочая и проверялась с помощью эксперимента.
Что нужно делать? Что делать следующее?
Процесс приоритизации бэклога был устроен предельно просто, по каноническому SCRUM, в котором участвовали: продакт менеджер, бизнес аналитик со стороны заказчика, 4 бизнес-аналитика со стороны подрядчика, проджект-менеджер со стороны подрядчика и архитектор. Все участники (кроме проджект-менеджера, который там был чтобы быть в курсе событий) реально влияли на результаты приоритизации. Роль продакта была в том, чтобы принимать окончательные решения, но большинство решений все равно принималось консенсусом. Наиболее приоритетные Истории шли в работу в следующем спринте и демонстрировались на Демо. Приоритизация происходила каждые две недели, поэтому возникал цикл обратной связи, когда результаты реализации каких-то Историй влияли на дальнейшую приоритизацию.
Таким образом, происходили оба необходимых, согласно принципу Поиска Наилучшего Объяснения, процесса: креативное создание новых Объяснений (почему сейчас нужно делать именно это) и традиция критики с целью фальсификации объяснения (т.е. попытки объяснить, что делать сейчас нужно что-то другое).
Как нужно делать? Какая должна быть архитектура?
Процесс принятия решений, касающихся реализации решения, был устроен довольно хитро. В нашей команде он был в виде регулярного митинга (3 раза за двухнедельный спринт), который назывался Product Backlog Refinement. В SCRUM guide нет никакой особенной спецификации того, как должен быть устроен Product Backlog Refinement (он описан вообще не как митинг, а как процесс непрерывного груминга бэклога). Видимо, устроить митинг именно таким образом нас надоумил коуч. Цель была в том чтобы успеть обсудить 3 среднего размера Истории за митинг, каждую за 20 минут. За 10 минут я давал презентацию про бизнес-ценность и необходимые технические детали. Дальше 5 минут шло быстрое обсуждение, дальше попытка оценки в Story Points с помощью техники Planning Poker. Последние 5 минут были зарезервированы на обсуждение, если оценка не сошлась. Дальше предпринималась попытка оценить Историю повторно, а если опять не получалось, то обсуждение Истории переносилось на следующий митинг. Для повторного обсуждения заводились экшн-поинты: подготовить дополнительную информацию или провести эксперимент. Таким образом, и тут опять выполнялось оба ключевых процесса согласно ТРОДД: команда предлагала различные варианты решений (а такой вариант всегда основан на Объяснении, почему именно так нужно делать), критиковала их и пыталась опровергнуть, в том числе, с помощью прототипирования.
Как нужно работать?
В SCRUM есть митинг Retrospective, который создан специально для поиска ответа на этот вопрос. И этот митинг также был устроен согласно принципу поиска Наилучшего Решения: команда пыталась выявить существующие проблемы, определить необходимые изменения в процессе, выполнить их в течение спринта, а на следующем Retrospective оценить их пользу и принять решение: отказаться от них или оставить.
Проблем было огромное множество и решались они не сразу. Но, т.к. практика Retrospective не была пустой формальностью, а реально работала, в итоге, в команде получился так называемый (мной) бесконечно улучшающийся процесс. Происходит он, во многом, с помощью автоматизации рутинных задач, благодаря чему команда фокусируется на ключевых задачах. Я представляю этот процесс так: есть две машины (команды разработки), которые исходно движутся примерно с одной и той же скоростью. Одна из машин начинает постепенно улучшаться, а в другой ничего не меняется. И вот прошло две недели, а первая машина поехала на 1 км/ч быстрее другой за счет того, что были решены какие-то проблемы. И так происходит каждые две недели, первая машина как будто бы едет с ускорением относительно второй. И на дистанции в два года оказывается что первая машина не просто проехала больше.
Оказывается, что за счет постоянной привычки выявлять и решать проблемы в процессе, команда сделала качественный скачок. В какой-то момент в команде, в которой работает бесконечно улучшающийся процесс, начинаются синергетические эффекты, когда система становится чем то большим, чем просто сумма компонентов. Такая команда не столько делает больше, чем другие (хотя и это тоже), сколько делает более качественно, более сложные и более нужные вещи. Такой команде можно закинуть любую идею, она будет обсуждена, раскритикована и проверена экспериментом.
На практике, в своей текущей работе, я руководствуюсь ППНРО для определения того, хорошо или плохо поставлен процесс, призванный решить определенную проблему. Если необходимые условия согласно ППНРО не выполнены, чаще всего это означает, что процесс поставлен плохо, и его нужно корректировать. Во всяком случае, бесконечно улучшаться он точно не будет.
Мой опыт, конечно, крайне ограничен, т.к. я всегда занимался только корпоративной заказной разработкой, причем, преимущественно, для банковских продуктов. Однако, мне кажется, что ТРОДД — это универсальная теория, которая может иметь множество областей приложения. Agile в области разработки ПО, Lean Startup в области Product Discovery, а также такой подход как Design Thinking в области дизайна, все они повторяют те же два основных положения из ППНРО: необходимость творческого (креативности) и традиции критики (фальсификации).
Я надеюсь, что люди, практикующие данные подходы, услышат достаточно “звоночков” в процессе чтения этой статьи, чтобы появилось желание обратиться к первоисточнику. Это захватывающее чтение.
Автор: bibamur
