Четвертый шаг - root cause analysis, т.е. попытки выяснить поч | Shoo and Endless Agony
Четвертый шаг - root cause analysis, т.е. попытки выяснить почему именно возникает эта проблема.
Зашкаливающий re-open rate у задач может возникать по многим причинам: неясные требования, высокая связанность кода, отсутствие sanity проверок перед пушем в мастер, отсутствие понимания что и зачем нужно делать, вечно горящие дедлайны и необходимость сделать "прям щас" и т.д.
Часто причиной может быть сразу несколько факторов, каждый из которых определенным образом аффектит то, что создает команда.
Выделив наиболее частые и значимые из таких факторов можно понять, где и что нужно менять в процессах или системе.
Как и в предыдущих шагах здесь есть свои сложности.
В первую очередь - это способность и готовность честно разбираться в причинах возникновения проблем.
Не стараясь переложить ответственность на других, не подменяя реальные проблемы желаемыми и объективно оценивая что пошло не так.
Не скатываясь в генерализацию и глобальные проблемы разбирать конкретную ситуацию.
Не все могут честно сказать "Ну, тут я не правильно понял описание, поэтому сделал фигню", ведь мало кому нравится признавать свои ошибки, несмотря на то, что все мы их совершаем.
Второй момент - необходимость отслеживать цепочку причин и умение вовремя остановиться.
Разбираясь в том, что пошло не так можно копать всё глубже и глубже, переходя от частных проблем к более общим.
С одной стороны, это может подсветить глобальные проблемы и узкие места в процессах и продукте, с другой стороны это может увести от проблем, которые можно решить быстро и просто, в сторону глобальных историй, которые не получится поменять за один день, месяц или год.
Здесь важно поддерживать баланс и отслеживать точки, в которых ты действительно можешь что-то поменять.
Пятый шаг - формирование ожидаемого результата для решения.
Благодаря предыдущим шагам у нас уже есть понимание того, как выглядит "плохо" работающее решение и того, как оно влияет на конечный результат работы.
Теперь задача в том, что бы сформировать понятное представление о том, как выглядит "целевое" решение, т.е. точка в которую нам хочется придти, что бы процессы или продукт работали лучше.
Вместе с этим мы формируем и критерии оценки этого решения - как мы будем отличать "плохое" от "хорошего" и какие метрики покажут, что вносимые изменения действительно приближают нас к целевому результату.
Как и с любыми целями - важно, что бы у вас были конкретные и измеримые метрики, с которыми можно будет сравнить результат.
Без этого понять стало ли лучше, или вы только усугубили проблему внесенными изменениями, невозможно.
Шестой шаг - формирование решений.
Каждую проблему, будь то инженерная или процессная задача, можно решить разными способами.
На основе всех данных, которые были собраны выше, мы можем сформировать несколько решений и оценивать их по ответам на ряд вопросов:
- Как это решение поможет устранить, или по крайней мере снизить, количество проблем в точках A, B и C?
- Какой результат мы ожидаем получить, т.е. насколько сформированные ранее метрики должны сдвинуться в сторону целевого состояния?
- Насколько масштабные и трудоемкие изменения требуются, что бы это сделать?
- Какие есть возможные проблемы и сайд-эффекты от реализации?
Обладая таким набором данных по каждому из возможных решений, выбрать то или иное становится значительно проще, а шансы получить позитивный эффект от реализации возрастают, просто потому, что часть гипотез, на самом деле не способных помочь в решении этой проблемы, отвалится на этапе обсуждения и оценки.
Нужно помнить, что совсем не обязательно браться сразу за самое "эффективное" решение.
Выбирая между масштабным изменением процессов, которое замедлит весь цикл разработки, но позволит
снизить re-open rate почти до нуля, и примитивным, быстрым решением, которое поможет снизить его на 20% - довольно часто стоит начать со второго.
Просто потому, что ты получишь положительный эффект быстро и относительно безболезненно, после чего сможешь переключиться на более приоритетные проблемы, или продолжить постепенно двигаться в нужном направлении.
