Мета-подходы к решению проблем

Эта статья – комбинированный перевод оригиналов на английском из подборки

Под мета-подходом я имею ввиду технику эффективного решения проблем, которую я смог со временем выделить из опыта в работе и жизни в целом.

Эффективное решение проблем

Интервальные оценки: лучший/худший вариант

Вам нужно сделать прогноз для некоторой метрики. Это сложная задача, по сути подвид предсказания будущего. Обычно поведение метрики зависит от многих факторов, что затрудняет анализ.

Вместо того, чтобы пытаться предвидеть поведение метрики может быть гораздо проще определить границы, которые она гарантированно не покинет.

Например: вы планируете вычислительные мощности для веб-приложения, целевая аудитория которого представляет собой население конкретной страны. У вас есть модель масштабирования, согласно которой условно требуется X ресурсов для обслуживания N пользователей. Вместо прогнозирования графика прироста пользователей просто используем 0 как наихудшей вариант (нет пользователей) и все население страны как лучший случай (каждый является пользователем). Такой подход тут же дает понимание какого порядка вычислительные мощности в принципе могу понадобиться для приложения.

Анализ первопричин через сравнение аналогов

Вы столкнулись с проблемой: нечто должно работать, но не работает. Более формально наблюдаемое поведение отличается от ожидаемого. Вам нужно провести анализ первопричин (root cause analysis, RCA) для их поиска и устранения.

Очень полезным будет наличие схожего, но работающего корректно кейса. Вместо разбора по винтику проблемного кейса вы сравниваете один с другим и ищете отличия.

Например: вы разворачиваете экземпляр сервера приложений и по каким-то причинам вы делаете вручную. После выполнения всей последовательности действий вы обнаруживаете, что сервер не отвечает на порту, на котором вы ожидаете. Вместо полного исследования что же могло пойти не так вы просто сравниваете настройки нового сервера с настройками другого экземпляра, который работает корректно. Идеально сравнить информацию, полученную автоматически. Это позволяет сфокусироваться на той разнице, которая и приводит к неожиданному поведению.

Walk back к первопричинам

Вы двигаетесь по плану для достижения цели или решения проблемы. Следующий шаг и/или связанные с ним решения кажутся противоречивыми или некомфортными. Вы не решаетесь продолжать.

Я нашел полезным подвергнуть сомнению исходные рассуждения, которые привели к уже выполненным действиям. В процессе работы над проблемой исходные посылки могут очень сильно измениться.

Например: вы работаете над интеграцией своего приложения с партнерской платформой. Вы обнаружили, что их процесс сверки взаимных расчетов требует наличия запутанной автоматизации с вашей стороны. Вместо реализации автоматизации сходу вы возвращаетесь к исходной гипотезе, из-за которой потребовалась интеграция. Х

Анализ первопричин через deep dive или 5 “почему”

Вы столкнулись с проблемой: что-то пошло наперекосяк. Более формально некие метрики процесса вышли из допустимого диапазона – либо метрики результата, либо самого процесса. Вам нужно выяснить как исправить ситуацию.

В этом случае полезная техника – deep dive / 5 “почему”. Вы задаете вопрос “Почему возникает эта проблема?” и записываете ответ на него. Скорее всего это будет симптом, а не первопричина, то есть вы вскрыли один слой проблемы. Затем вы задаете следующий вопрос “почему” на этот ответ, вероятно собирая и анализируя больше информации для ответа.

Повторите хотя бы 5 раз, а лучше больше. Скорее всего у вас получится отличный RCA.

Например: последнее развертывание в production содержит критический баг. Вот возможный разбор этого кейса через deep dive / 5 “почему”.

  • Почему последнее развертывание в production содержит критический баг? Потому что контроль качества (QA) не смог обнаружить его.
  • Почему QA не удалось обнаружить баг? Потому что он не воспроизвелся в staging-окружении.
  • Почему баг не воспроизвелся в staging-окружении? Потому что у QA нет тест-кейса для этого сценария.
  • Почему у QA нет тест-кейса для этого сценария? Потому что владелец продукта (PO) не предоставил этот сценарий.
  • Почему владелец продукта (PO) не предоставил этот сценарий? Потому что он не покрыт аналитикой.
  • Почему этот сценарий не покрыт аналитикой? Потому что аналитика не отслеживает всплывающие окна.

Как исправить: включить отслеживание всплывающих окон.

Выбор альтернатив для важного решения

Вам нужно принять важное решение. Варианты нечеткие и сложно выбрать. Вы не решаетесь продолжать.

Запишите все варианты, которые приходят в голову, в том числе “бессмысленные” вроде “ничего не делать” – хотя бы 2 варианта, но лучше 3 или больше. Поштурмите плюсы и минусы каждого варианта. Постарайтесь выделить факторы решения – “измерения” для плюсов и минусов. После этого выбор станет гораздо яснее.

Например: вы пытаетесь подобрать реляционную СУБД для новой системы. Вот возможный выбор альтернатив:

Какую РСУБД выбрать для новой системы?

  • Вариант 1: MySQL
    • Плюсы: средняя сложность развертывания
    • Минусы: не лучшее соответствие SQL-стандартам
  • Вариант 2: PostgreSQL
    • Плюсы: лучшее соответствие SQL-стандартам
    • Минусы: наиболее сложна в развертывании
  • Вариант 3: SQLite
    • Плюсы: самое простое развертывание
    • Минусы: нельзя развернуть на отдельном хосте

Факторы решения:

  • Трудозатраты на развертывание
  • Соответствие SQL-стандартам
  • Возможность развернуть на отдельном хосте

Мы выбираем PostgreSQL – это лучший вариант по совокупности плюсов/минусов для факторов решения в нашем случае.

Вилка целей

Вы намереваетесь сделать что-то, что кажется полезным, но вам не хватает мотивации.

Подумайте о дополнительных целях/смыслах, которые вы можете посочетать с изначальной активностью, чтобы сделать её более привлекательной.

Например: часовая прогулка будет полезна для здоровья, но вы ленитесь. Вы вспоминаете о магазине примерно в получасе хотьбы от вашего дома где вы хотели что-то купить. Так же есть проблема, о которой вам нужно поразмышлять в спокойной обстановке.

В результате у вас получается привлекательный план: прогулятся до магазина и купить то, что вы хотели, а заодно подумать о проблеме на пути туда и обратно.

Анализ первопричин через совокупность факторов

Вы столкнулись с проблемой и вам нужно найти способ решить её. В проблеме много факторов и движущихся частей, провести анализ проблематично.

Вместо выделения единственной первопричины рассмотрите множество факторов, работающих совместно для возникновения проблемы. Модель швейцарского сыра для аварии хорошо подходит для этого стиля размышлений.

Например: последнее развертывание в production содержит критический баг. Вы провели анализ первопричин и выяснили:

  • Баг возникает только при наличии определенного значения в справочнике
  • Логика хорошо покрыта тестами, которые выполняются в staging-окружении, но того самого значения нет в датасете staging-окружения
  • Существует процедура импорта обезличенных данных production в staging-окружение, но эта процедура не опубликовала то самое значение до релиза
  • То самое значение было недавно добавлено вручную, чтобы решить жалобу пользователя
  • Импорт из production в staging-окружение не выполнился после добавления значения, что совпало с релизом

Любой выбор это компромисс

Вы использовали подход, который казался поначалу безупречным, но впоследствии вы столкнулись с существенными проблемами.

Любой выбор в принципе это компромисс со своим набором плюсов и минусов. Всегда когда вам кажется, что вариант содержит только плюсы или только минусы, вы попали в слепую зону по какой-то причине. Фундаментально это восходит к закону сохранения энергии и невозможности создания вечного двигателя.

Например: вы выбираете способ взаимодействия фронтенда и бэкенда и вам кажется, что полнодуплексная связь на основе Websockets идеально подходит для вашего кейса как имеющая наименьшие задержки. При этом вы не учли следующие свойства Websockets:

  • stateful, то есть реализация масштабирования значительно сложнее, чем в случае обычного REST API
  • модель программирования значительно сложнее по сравнению с типовым подходом запрос/ответ

Dogfooding как универсальный энейблер качества

Вы только что закончили задачу и радостно передали результаты. К вашему удивлению получатели недовольны тем, что они получили.

Dogfooding означает по сути “отведай своего лекарства”: чтобы вы не делали попробуйте стать потребителем своих результатов. Сложно переоценить универсальность применимости этого принципа для контроля качества.

Например: вы разрабатываете внутренний инструмент для коллег в вашем же подразделении и ваши “клиенты” точно ценят скорость больше качества в этом конкретном случае. Тем не менее вместо простого тестирования функциональности на работоспособность вы идете дальше. Вы тестируете инструмент с точки зрения общего процесса коллег. Такой фокус привносит дополнительные инсайты в вашу работу и вы реализуете некоторые части совсем по-другому.

Вот и все! Надеюсь вы подчерпнули какие-то полезные подходы для свой каждодневной работы.