Алгоритм системного решения проблем
Допустим, упал сайт. Или у кого-то отображается не тот номер телефона в подменах. Или в рекламной кампании обнаружены лишние ключевые фразы. Реакция по умолчанию: исправить и забыть. Такая реакция приводит к плохим последствиям: сложность проекта растёт, на починку уходит всё больше времени, а на настоящую работу — всё меньше.
Я для себя пришёл к такому алгоритму:
1. Обнаружена проблема
Сработал мониторинг. Или клиент прислал. Или сами заметили.
2. Подтвердить получение проблемы и срок реакции
Записать в тикет-систему / баг-трекер / докс. Уведомить менеджера / команду / клиента. «Принял, разбираюсь прямо сейчас». «Принял, посмотрю после задачи Х через час».
Если не уведомить, остальные будут нервничать в неизвестности. Не будет ощущения, что вы контролируете ситуацию. Что за вами не надо перепроверять. Что вам можно доверить что-либо важное.
3. Оценить критичность и составить план действий
Критичность определяется не паникой, а возможными последствиями в перспективе. Нужно представить и прочувствовать все последствия, сравнить с другими задачами и принять решение. Некоторые проблемы нужно решать прямо сейчас. Некоторые можно не решать.
Обычно получается так, что проблемы вытесняют задачи по развитию и системным решениям. Это не правильно. Если хорошо прочувствовать важность проблем и важность системных решений, то найдётся баланс.
4. Убедиться, что проблема действительно есть
Чтобы решить проблему, надо сначала её воспроизвести. Иногда это сложно. Надо либо воспроизвести, либо доказать, что её нет. «У меня не воспроизводится» — не ответ.
Снять проблему может только тот, кто о ней сообщил. Пока не снял, считаем проблему актуальной.
Иногда проблема только кажется проблемой, а на самом деле так и задумано. Тут помогает документация и память участников команды.
5. Подтвердить, что проблема есть, и сказать, когда исправите
Исправить можно сразу, через час, день, неделю или никогда. Зависит от критичности проблемы и ваших процессов.
Но информировать обязательно — для прозрачности, ощущения контроля и доверия.
6. Исправить
Исправить.
7. Проинформировать
Проинформировать, что исправили и рассказать, что собираемся делать дальше.
В этот момент менеджер и клиент считают, что главное уже сделано и ждут новостей по следующей Очень Важной Проблеме. На самом деле, самое важное ещё впереди. Если работу по алгоритму не довести до конца, то ошибки будут только накапливаться. Это в интересах менеджера и клиента не давать закрыть просто исправленную ошибку.
8. Сделать контрольную проверку
Проверить, что ошибка действительно исправлена. Обязательно сделать это другим способом. Желательно на следующий день со свежим взглядом. Например, сайт посмотреть в других браузерах и в мониторинге. Рекламу посмотреть не в интерфейсе, а в поиске и в статистике.
Вы не поверите, как часто контрольные проверки на следущий день обнаруживают недоисправленные ошибки.
9. Проинформировать
Мало кто делает контрольные проверки. У всех Нет Времени. Сделать и расказать — +1 в карму.
10. Что могло сломаться рядом? Что могли сломать, пока чинили?
Починили вёрстку в одном браузере? А в других? А на мобилках? А в версии для печати?
Изменили работу калькулятора на лендинге? А на основном сайте? А в других регионах? А события не поломали?
Обнаружили лишнее ключевое слово в одной РК? А есть в других? А в SEO? А в списке услуг на сайте?
Вообще-то, это надо делать сразу, но неплохо проверять ещё раз после.
Кстати, такое внимание к деталям и умение смотреть по сторонам — один из важных критериев проверки людей на стажировке.
11. Проинформировать
Ну вы поняли.
12. Посчитать цену ошибки
Мой любимый пункт. Почему-то считать очень не хочется. Или хочется посчитать по нижней границе. Но сделать это надо обязательно и не занижать.
Во-первых, команда часто не представляет, сколько стоят ошибки. Конкретное число в рублях отрезвляет и реально влияет на действия. Поводом к написанию этого поста стала серия очень дорогих ошибок. Это цена обучения. Если не посчитать, обучение будет менее эффективным.
Во-вторых, клиенты без точных данных рисуют в голове огромные цифры. А это далеко не всегда соответствует действительности.
Внимание: если в расчётах найдётся ошибка или процесс расчёта будет непонятен, то восстановить доверие будет сложно. Повышенная Бдительность.
13. Проинформировать
Вот здесь больно, да.
14. Найти системное решение
Надо сделать так, чтобы ошибка никогда не повторялась. Тут появляются мониторинги, чек-листы, регламенты и другие бюрократические штуки. Часто их не делают, потому считают любую бюрократию злом. Бюрократия бывает проблемой, но чаще проблема в отсутствии базовых процессов и чек-листов.
Кстати, «человек ошибся» — это не разовая ошибка. Люди ошибаются всегда, поэтому людей считаем системной ошибкой.
Ещё бывают редкие ошибки и дешёвые ошибки. Их может быть дешевле не лечить и честно об этом сказать. Например, глючащий несколько дней сервис онлайн-консультанта снизит выручку на 40 т.р.. Цена смены сервиса с переобучением людей и перестройкой аналитики — ~400 т.р. и ещё не известно как на конверсию повлияет. Решение Всё Поменять здесь было бы поспешным.
15. Проинформировать
Если не спрашивают, всё равно рассказать. Системные решения — это же самое важное.
16. Сделать отчёт для себя / команды / клиента в будущем
Отчёт идёт прямо по этому формату. По этим отчётам потом хорошо искать причины похожих проблем. И учить новеньких.
17. Что осталось сделать?
Закрывать тикет можно только когда ответ на этот вопрос пуст.
Как быть уверенным, что сделано действительно всё? Доверять внутреннему чутью. Чутье — это накопленный опыт и боль.
Ещё раз алгоритм списком (можете скопировать к себе)
Резюме
По этому алгоритму можно разбираться с чем угодно. Первым на ум приходят сайты и разработка, но оно подходит и для рекламы и для других процессов, и для управление проектами, компаниями, людьми. Даже с неудачной поездкой на велосипеде можно так разбираться.
В тривиальных случаях прохожу по алгоритму в уме. В сложных — открываю докс, копирую алгоритм и иду по пунктам.
Сделал на своём проекте отчёт — очень помогло. По факту он больше нужен тебе самому при решении проблемы, потому что помогает посмотреть на проблему с разных сторон, найти разные возможные причины, а не только очевидные.
Я бы добавил пункт 6а — Проверить, действительно ли исправили.
Часто встречается, что исправленное оказывается не исправленным.
Это не отменяет пункта 8, про проверку свежим взглядом и в более широких условиях.
Это прям алгоритм по ITIL — но такое чаще работает в «махровом» энтерпрайзе (компания на 100-100 000 сотрудников, десятки — сотни ИТ-систем в корпоративной инфраструктуре, многие между собой связанны)
И такой системный подход к техподдержке редко встречается у веб-разработчиков.