Как анализировать ошибки в IT
Если ты работаешь в компании, которая применяет Agile — считай, у тебя нет проблем. Вы регулярно проводите ретроспективы и пост-мортемы, анализируете ошибки и учитываете их на будущее. С первого взгляда дурацкие мероприятия правда повышают результативность. Если всё работает идеально.
Если нет (или если ты хочешь прокачаться в саморазвитии) , рассказываю про метод «пяти почему».
Меня зовут Сан, я больше 9 лет в разработке и больше 5 лет — в запуске продуктов. Я пишу про софт-скиллы и развитие карьеры в своём блоге — можно подписаться на еженедельную рассылку или читать статьи прямо там. А ещё у меня есть telegram-канал fordevs. Короче, присоединяйся к комьюнити!
Кратко — у тебя есть проблема, которая уже случилась. Например, вариант из геймдева: допустили ошибку в коде и выпустили в прод, из-за чего легло всё приложение. Можно сказать — «больше ошибок не делаем», пожать руки и пойти дальше, а потом столкнуться с этим снова. Надо докопаться до глубинных проблем.
На каждую ошибку надо задать вопрос — почему так вышло.
Почему случилась ошибка
Выкатили приложение с ошибкой в коде
Почему
Не заметили ошибку при тестировании
Почему
Потому что QA не тестируют вопросы экономики
Почему
Потому что экспертиза по экономике есть только у одного специалиста
Почему
Потому что система расчёта и проверки экономики очень сложная, погружать в неё других долго и невыгодно.
Итого — ты докапываешься до проблемы. Дело не в том, что есть ошибка (это очевидная проблема) — дело в том, что вся система работает не идеально.
Потом вы договариваетесь о мерах — например, заложить время на рефакторинг или привлечь к работе аутсорс-специалистов. Тем самым снижаете риск возникновения проблемы в будущем.
Вывод простой, но важный: всегда докапывайтесь до сути проблемы. Висяки рождают неразрешимый снежный ком.