В 1985 году Дэвид Дойч первым описал квантовую машину Тьюринга.
Позже он объединил идеи Поппера, Докинза, Веретта и Тьюринга в теорию разумных объяснений.
А недавно я обнаружил, что совершенствую процессы разработки банковских продуктов на основе его подхода к научной методологии.
Привет. Меня зовут Дима Мурзин.
По профессии я бизнес-аналитик в сфере финансов, работаю с заинтересованными сторонами бизнеса и с командой разработчиков, в которой исполняю роль Product Owner. Я живу в Нью-Йорке со своей семьей уже три года.
Когда я жил в Санкт-Петербурге, мне посчастливилось работать в команде, у которой был очень хороший SCRUM-процесс.
Во многом это произошло из-за того, что продакт-менеджер со стороны заказчика очень глубоко понимал принципы Agile, а также знал, как должен быть структурирован SCRUM с точки зрения всех практик и церемоний.
В One Big European Bank (в котором я работал) такое случалось очень редко.
Также отмечу мое непосредственное руководство со стороны компании-подрядчика.
Они наняли хорошего тренера, который провел нас через весь процесс и следил за нами еще несколько недель, дал нам полную свободу действий и ответственность за продукт, а затем вмешивался только в случае возникновения серьезных проблем, что случалось редко.
Кроме того, они занимались наймом и отбирали людей, подходящих для работы в условиях постоянных изменений.
После того, как я переехал в США, поближе к заказчику (и попал совсем в другую команду, в которой Agile и не пахло), я попытался проанализировать, почему моя предыдущая команда была такой эффективной и продуктивной и почему вообще Я знал, что команда настолько хороша? С точки зрения результатов бизнеса это было совсем не очевидно.
Продукт, который мы сделали, был инфраструктурным (т. е.
сам по себе он не приносил прибыли), а Один Большой Европейский Банк потерял почти половину стоимости своих акций за время, пока я в нем работал, поэтому оценить выгоду для бизнеса было сложно.
Может я просто обманывал себя, команда была обычная, но суперпроизводительности не было? Однако у меня было стойкое ощущение, что это не так, и я попытался разобраться, откуда это взялось.
В это время я прочитал книгу Дэвида Дойча «Начало бесконечности» и в ней нашел теоретическую основу, объясняющую, почему команда продуктивна (в дальнейшей работе я пытался экспериментальным путем определить, верна ли эта теория).
Ниже я использую заглавные буквы для обозначения важных понятий.
Лично я кратко называю этот теоретический подход «Теорией разумных объяснений» Дэвида Дойча (DDE).
Постараюсь описать это ниже, но.
Я не теоретик, а практик, тогда призываю всех, кто хочет более точного академического изложения, ознакомиться с первоисточником( Дэвид Дойч - Начало бесконечности ).
Теория разумного объяснения Дэвида Дойча
Основным положением ТРОДД является Принцип поиска наилучшего разумного объяснения (ППНРО).Чтобы полностью понять PPNRO, вы должны сначала понять несколько определений из теории научного познания Карла Поппера.
Карл Поппер считал, что некоторые теории лучше других.
Больше всего он не уважал те теории, которые нельзя было фальсифицировать, например те теории, которые можно было очень легко варьировать и с их помощью объяснять что угодно.
Чтобы отделить такие теории и вообще о них не думать, Поппер предложил метод демаркации, т.е.
способ отличить научное знание от ненаучного знания.
Научная теория должна быть принципиально фальсифицируемый , т. е.
допустить возможность того, что что-то произойдет (эксперимент) и станет ясно, что теория неверна.
Например, теория «Все происходит по воле судьбы» не является научной, потому что вообще не существует события, которое могло бы ее опровергнуть.
После того как Поппер отделил ненаучные теории от научных, он стал заниматься научными.
Большинство научных теорий можно легко фальсифицировать с помощью простого эксперимента и отбросить как неправильные.
Однако оказалось, что существуют теории, которые не так-то просто фальсифицировать.
Такие теории были гораздо лучше неверных.
Но были ли они правильными теориями? В истории науки было огромное количество примеров, когда казалось, что теория верна, но затем новые наблюдения доказывали, что она неверна (канонический пример – специальная и общая теории относительности заменили классическую физику Ньютона).
Тогда Поппер выдвинул еще один принцип – принцип фаллибилизма , - утверждая, что все научные знания лишь гипотетичны и подвержены ошибкам.
По сути, он сказал, что не существует идеальной теории, которая объясняла бы все наблюдаемые факты и исключала бы все ненаблюдаемые факты.
Так, Поппер предложил шкалу оценки теорий, по которой ненаучные теории имели нулевой балл, идеальные теории находились где-то на бесконечности, а все существующие научные теории болтались где-то посередине, в зависимости от того, сколько фактов теория объясняла и исключала.
В книге Дойча термин «Теория» заменен термином «Разумное объяснение».
В одной из глав он даже говорит, что с радостью использовал бы вместо этих двух терминов термин «Заблуждение», чтобы подчеркнуть, что любая из наших теорий в чем-то неверна.
Дойч использовал шкалу Карла Поппера, чтобы предложить метод или стратегию действий, которым необходимо следовать, чтобы получить ответ на вопрос или решение проблемы.
Эта стратегия изложена в ТРОДД и кратко описана в Принципе поиска наилучшего разумного объяснения.
Это выглядит примерно так:
- Когда люди ищут ответ на вопрос или решение проблемы, правильной стратегией является поиск наилучшего разумного объяснения.
- Вам нужно использовать творческий подход или «Творчество», чтобы придумать различные разумные объяснения (1-й ингредиент).
- Далее нужно попытаться опровергнуть эти Объяснения с помощью экспериментов (в том числе и мысленных), это называется «Традиция Критики» (2-й ингредиент).
- Если опровергнуть не удается, то Объяснение считается рабочим и используется.
- Но попытки найти другие, лучшие Разумные Объяснения не прекращаются, потому что.
Согласно принципу фаллибилизма, ни одно Объяснение не может считаться окончательно правильным.
Лучшее Разумное Объяснение найти невозможно, но надо постараться, потому что.
в процессе поиска можно найти Объяснение лучшее, чем рабочее.
Тогда рабочее Объяснение признается ложным, а лучшее Объяснение становится рабочим.
Кроме того, Дойч вводит понятия объема и объяснительной силы.
Объем — это набор наблюдаемых фактов, которые теория пытается объяснить.
Сферы применимости различных теорий могут не пересекаться вообще или пересекаться частично.
Объяснительная сила — это мера набора фактов, которые объясняются или исключаются Разумным объяснением.
Дойч пишет, что в большинстве случаев невозможно добиться свободной конкуренции между различными Разумными Объяснениями, и это происходит потому, что существует множество различных Несостоятельных Философий.
Философия несостоятельна, когда она не позволяет реализовать стратегию, описанную в ППНРО, т.е.
либо тормозит свободное генерирование идей, либо препятствует традиции критики и экспериментального опровержения.
Дойч описывает множество областей несостоятельной философии, но я хочу привести в статье два примера, поскольку мне приходится очень часто сталкиваться с ними в своей рабочей практике.
Первый пример — это ссылка на авторитет вместо объяснения («Я здесь менеджер, я знаю лучше!»).
Эта философская позиция блокирует любые попытки критики, а также отрицательно влияет на творчество – процесс создания новых Объяснений.
Второй пример — Постмодернизм, или идея о том, что поскольку… не существует наиболее правильного Объяснения (принцип фаллибилизма), то все Объяснения одинаково разумны (отказ от принципа фальсифицируемости).
Постмодернизм придает определенную легитимность даже самым вредным и необоснованным Объяснениям.
Процесс творчества процветает, но каждая из заинтересованных сторон считает свое Объяснение наиболее разумным, в результате чего критика не приводит к тому, что ложное Объяснение отбрасывается.
Примерно так я узнал «Теорию разумных объяснений» Дэвида Дойча.
При чем здесь SCRUM?
Я понял, что SCRUM — это очень удобный фреймворк для организации процессов по PPNRO. И ключевые процессы в нашей команде были выстроены именно так.Мы решили проблему» Как получить максимальную выгоду для бизнеса? «Более конкретными проблемами, вытекающими из основной проблемы, были: Что мы должны делать? Что я должен делать дальше? — Главный вопрос — приоритизация отставания.
Как я должен это делать? — То есть каким должно быть решение, какую архитектуру должно иметь решение? Как вам следует работать? Каким должен быть процесс? Для ответа на каждый из этих вопросов был организован процесс, в ходе которого несколько человек выдвигали свою версию Разумного Объяснения, почему необходимо было сделать именно этот поступок.
Далее состоялось обсуждение, в ходе которого одна из версий была признана рабочей и проверена в ходе эксперимента.
Что мы должны делать? Что я должен делать дальше?
Процесс приоритизации бэклога был организован предельно просто, по каноническому SCRUM, в котором участвовали: менеджер продукта, бизнес-аналитик со стороны заказчика, 4 бизнес-аналитика со стороны подрядчика, менеджер проекта со стороны подрядчика и архитектор.Все участники (кроме руководителя проекта, который был рядом, чтобы быть в курсе событий) действительно повлияли на результаты расстановки приоритетов.
Роль продукта заключалась в принятии окончательных решений, но большинство решений по-прежнему принималось консенсусом.
Истории с наивысшим приоритетом были задействованы в следующем спринте и продемонстрированы на демо-версии.
Расстановка приоритетов происходила каждые две недели, поэтому возникала петля обратной связи, когда результаты реализации некоторых Stories влияли на дальнейшую расстановку приоритетов.
Таким образом, имели место оба необходимых по принципу Поиска Лучшего Объяснения процесса: творческое создание новых Объяснений (почему это необходимо делать именно сейчас) и традиция критики с целью фальсификации объяснения ( т. е.
пытаюсь объяснить, что сейчас нужно сделать что-то еще).
).
Как я должен это делать? Какой должна быть архитектура?
Довольно хитрым образом был устроен процесс принятия решения по поводу реализации решения.В нашей команде это проходило в форме регулярного совещания (3 раза за двухнедельный спринт), которое называлось «Уточнение бэклога продукта».
В руководстве по SCRUM нет специальной спецификации того, как должно быть организовано уточнение бэклога продукта (оно описывается вовсе не как собрание, а как процесс непрерывного ухода за бэклогом).
Видимо, тренер посоветовал нам организовать розыгрыш именно таким образом.
Целью было успеть обсудить 3 истории среднего размера за встречу, каждую за 20 минут. За 10 минут я провел презентацию о ценности бизнеса и необходимых технических деталях.
Затем последовало быстрое обсуждение в течение 5 минут, за которым последовала попытка подсчитать Story Points с помощью техники «Покер планирования».
Последние 5 минут отводились для обсуждения, если счет не совпадал.
Затем предпринималась попытка оценить Историю еще раз, и если она снова не получалась, то обсуждение Истории переносилось на следующее заседание.
Для повторного обсуждения вводились пункты действий: подготовить дополнительную информацию или провести эксперимент. Таким образом, и здесь оба ключевых процесса были проведены по ТРОДД: команда предлагала различные решения (а этот вариант всегда основывается на Объяснении, почему именно это нужно сделать), критиковала их и пыталась опровергнуть, в том числе посредством прототипирования.
Как вам следует работать?
В SCRUM есть Ретроспектива, которая была создана специально для того, чтобы найти ответ на этот вопрос.И эта встреча тоже была организована по принципу поиска Лучшего Решения: команда старалась выявить существующие проблемы, определить необходимые изменения в процессе, реализовать их в ходе спринта, а на следующей Ретроспективе оценить их преимущества и принять решение.
: бросить их или оставить их.
Проблем было огромное количество и они не были решены сразу.
Но, потому что практика Ретроспективы не была пустой формальностью, а реально работала, и в результате в команде возник так называемый (мной) бесконечно улучшающийся процесс.
Во многом это происходит за счет автоматизации рутинных задач, благодаря чему команда концентрируется на ключевых задачах.
Я представляю этот процесс так: есть две машины (команды разработчиков), которые изначально движутся примерно с одинаковой скоростью.
Одна из машин начинает постепенно улучшаться, а в другой ничего не меняется.
А потом прошло две недели, и первая машина поехала на 1 км/ч быстрее другой из-за того, что были решены какие-то проблемы.
И это происходит каждые две недели, первая машина как будто ускоряется относительно второй.
И по прошествии двух лет оказывается, что первая машина не просто больше ездила.
Оказывается, благодаря постоянной привычке выявлять и решать проблемы в процессе команда совершила квантовый скачок.
В какой-то момент в команде, которая осуществляет процесс бесконечного совершенствования, начинает проявляться синергия, когда система становится чем-то большим, чем просто сумма ее частей.
Такая команда не столько делает больше, сколько другие (хотя и это тоже), а, скорее, делает вещи качественнее, сложнее и нужнее.
Такой команде можно подкинуть любую идею, она будет обсуждаться, критиковаться и проверяться экспериментом.
На практике в своей нынешней работе я руководствуюсь PPNRO, чтобы определить, хорошо или плохо спроектирован процесс, предназначенный для решения конкретной проблемы.
Если необходимые условия по ППНРО не выполняются, чаще всего это означает, что процесс плохо поставлен и требует корректировки.
В любом случае, бесконечно улучшаться оно точно не будет. Мой опыт, конечно, крайне ограничен, потому что.
Я всегда занимался только корпоративными заказными разработками и в основном банковскими продуктами.
Однако мне кажется, что ТРОДД — это универсальная теория, которая может иметь множество областей применения.
Agile в сфере разработки программного обеспечения, Lean Startup в сфере Product Discovery, а также такой подход, как Design Thinking в сфере дизайна, все они повторяют одни и те же два основных положения из ППНРО: необходимость креативного мышления (креативности) ) и традиция критики (фальсификации).
Я надеюсь, что люди, практикующие эти подходы, услышат в процессе чтения этой статьи достаточно «звоночков», которые захотят обратиться к первоисточнику.
Это увлекательное чтение.
Теги: #Управление разработкой #agile #scrum #управление продуктом #управление проектами #разработка продукта #дизайн-мышление #бережливый стартап
-
Подробное Исследование Microsoft Mcse
19 Oct, 24 -
Базовое Онлайн-Обучение Java
19 Oct, 24 -
Linux-Версия Клиента Quake Live
19 Oct, 24 -
Как Написать Хороший Sla
19 Oct, 24
