Как вести журнал ошибочных решений в команде

Как вести журнал ошибочных решений в команде: от простого к сложному Цель журнала в том, чтобы фиксировать и показывать паттерны ваших ошибок на всём протяжении изменяющейся жизни а) продукта; б) команды и устранять именно их (паттерны-причины), которые создают следствия (ошибки). – Тегируйте каждую запись по типу ошибки: неверные изначальные данные, неправильная оценка, спешка, избегание конфликта, и т.п. причины. Анализируйте ошибки, ищите повторы, устраняйте причины ошибок, чтобы не лечить следствие ошибок каждый раз. Разделяйте плохое решение и плохой исход Четыре разных типа задач: хорошее решение и хороший исход / хорошее и плохой исход / плохое решение, но хороший исход / плохое решение и плохой исход. Самый недооценённый тип: «плохое решение / хороший исход», при правильном заполнении и поиске тех самых причин, в таких идеях спрятан ключ как вам прийти к самым успешным решениям. Пишите «пре-мортемЫ» заранее, а потом сравнивайте с настоящей причиной. Помогает подложить ту самую соломку где надо, знаю команду, в которой есть чел с отдельной ролью именно под это.

«Мы ожидаем изменение метрики на X%, уверенность в этом 70%». Это два разных ощущения, понимание их помогает калибровать общее ощущение вашей реальности

– Обогащайте пост-контекст принятого ранее ошибочного решения отдельным полем «Что мы проигнорировали / не заметили / поняли не так» + состояние, в котором принимаете решения: стресс, дедлайн, кто был в комнате, какой информации не хватало. Фиксируйте, какие данные вы не стали собирать и почему Потому что уже через полгода каждая ошибка вспоминается как очевидная, а состояние и условия в которых она возникла забываются. Так, спустя время, ошибку можно легко приписать глупости, хотя причина в была условиях (ошибка после ошибки – точно глупость).

Записывайте, какую историю вы рассказали о решении с ошибкой (совет на будущее из прошлого: старайтесь избегать одной яркой истории)

– Самое полезное поле: «первые звоночки или первый момент, когда мы заметили/могли заметить ошибку». Ловите самые ранние сигналы ошибок. И эти сигналы могут приходить ощущениями ещё на стадии планирования (и даже раньше). – Второе по полезности поле: «что мы защищали»: утверждённый ранее родмэп, упрямство, личное авторство, бюджет, обещание СЕО/инвесторам, красивую историю-презу. Ошибки держится на подобном, пойми на чём именно. – Добавьте поле «Чья это была ошибка: человек / процесс / Система». Люди – без имён, это не поиск виноватых! Видя как ошибка живет на каждом из этапов, вы сможете лучше видеть слабые и сильные места в командных и продуктовых процессах и понимать, как на них влиять. Ещё одно недооцененное поле «Кто возражал и чем закончилось» для фиксации возражений которые вы систематически игнорите и недослушиваете (почему?). Часто, те кто возражают это: 1) люди с низким статусом в команде; 2) те, кто говорит осторожно; 3) тот, кто говорит самую больную правду и именно они часто оказываются правы. Ещё раз – без имён! – История побочных эффектов ошибок – то, что решение сломало в соседних фичах/механиках/процессах/метриках. Помогает видеть и лучше понимать связи внутри продукта. – Ведите журнал и по ошибкам конкурентов, это а) чужие; б) бесплатные уроки, и они могут делают вас лучше, чем собственные провалы, потому что в них нет эго, которое защищается. – Статус: «ошибка признана / решение пересмотрено / отменено» превращает журнал из архива в рабочий инструмент. Раз в год перечитывайте журнал и ищи решение, которое тогда казалось ошибкой, а теперь нет (или наоборот). Время переворачивает оценки чаще, чем кажется и является лучшим лекарством от уверенности в собственных суждениях (о времени). Будьте абсолютно честны, только так этот журнал будет работать. Честность в том, чтобы записывать даже те ошибки, которые страшно/некомфортно признавать. Свежий взгляд в журнал продукт возвращает честность. Spend ten minutes every day deliberately writing down what you got wrong. Not journaling about ego gratitude lists, but a f***ing. daily. error. log.