Алгоритм системного решения проблем

uploadsl1owxqm0v.png

Авторская методика: адекватная последовательность действий при обнаружении ошибок в работе над проектом.

Допустим, упал сайт. Или у кого-то отображается не тот номер телефона в подменах. Или в рекламной кампании обнаружены лишние ключевые фразы. Реакция по умолчанию: исправить и забыть. Такая реакция приводит к плохим последствиям: сложность проекта растёт, на починку уходит всё больше времени, а на настоящую работу — всё меньше.

Я для себя пришёл к такому алгоритму:

1Обнаружена проблема

Сработал мониторинг. Или клиент прислал. Или сами заметили.

2Подтвердить получение проблемы и срок реакции

Записать в тикет-систему / баг-трекер / докс. Уведомить менеджера / команду / клиента. «Принял, разбираюсь прямо сейчас». «Принял, посмотрю после задачи Х через час».

Если не уведомить, остальные будут нервничать в неизвестности. Не будет ощущения, что вы контролируете ситуацию. Что за вами не надо перепроверять. Что вам можно доверить что-либо важное.

3Оценить критичность и составить план действий

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

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

4Убедиться, что проблема действительно есть

Чтобы решить проблему, надо сначала её воспроизвести. Иногда это сложно. Надо либо воспроизвести, либо доказать, что её нет. «У меня не воспроизводится» — не ответ.

Снять проблему может только тот, кто о ней сообщил. Пока не снял, считаем проблему актуальной.

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

5Подтвердить, что проблема есть, и сказать, когда исправите

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

Но информировать обязательно — для прозрачности, ощущения контроля и доверия.

6Исправить

Исправить.

7Проинформировать

Проинформировать, что исправили и рассказать, что собираемся делать дальше.

В этот момент менеджер и клиент считают, что главное уже сделано и ждут новостей по следующей Очень Важной Проблеме. На самом деле, самое важное ещё впереди. Если работу по алгоритму не довести до конца, то ошибки будут только накапливаться. Это в интересах менеджера и клиента не давать закрыть просто исправленную ошибку.

8Сделать контрольную проверку

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

Вы не поверите, как часто контрольные проверки на следущий день обнаруживают недоисправленные ошибки.

9Проинформировать

Мало кто делает контрольные проверки. У всех Нет Времени. Сделать и расказать — +1 в карму.

10Что могло сломаться рядом? Что могли сломать, пока чинили?

Починили вёрстку в одном браузере? А в других? А на мобилках? А в версии для печати?
Изменили работу калькулятора на лендинге? А на основном сайте? А в других регионах? А события не поломали?
Обнаружили лишнее ключевое слово в одной РК? А есть в других? А в SEO? А в списке услуг на сайте?

Вообще-то, это надо делать сразу, но неплохо проверять ещё раз после.

Кстати, такое внимание к деталям и умение смотреть по сторонам — один из важных криериев проверки людей на стажировке.

11Проинформировать

Ну вы поняли.

12Посчитать цену ошибки

Мой любимый пункт. Почему-то считать очень не хочется. Или хочется посчитать по нижней границе. Но сделать это надо обязательно и не занижать.

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

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

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

13Проинформировать

Вот здесь больно, да.

14Найти системное решение

Надо сделать так, чтобы ошибка никогда не повторялась. Тут появляются мониторинги, чек-листы, регламенты и другие бюрократические штуки. Часто их не делают, потому считают любую бюрократию злом. Бюрократия бывает проблемой, но чаще проблема в отсутствии базовых процессов и чек-листов.

Кстати, «человек ошибся» — это не разовая ошибка. Люди ошибаются всегда, поэтому людей считаем системной ошибкой.

Ещё бывают редкие ошибки и дешёвые ошибки. Их может быть дешевле не лечить и честно об этом сказать. Например, глючащий несколько дней сервис онлайн-консультанта снизит выручку на 40 т.р. Цена смены сервиса с переобучением людей и перестройкой аналитики — ~400 т.р. и ещё не известно как на конверсию повлияет. Решение Всё Поменять здесь было бы поспешным.

15Проинформировать

Если не спрашивают, всё равно рассказать. Системные решения — это же самое важное.

16Сделать отчёт для себя / команды / клиента в будущем

Отчёт идёт прямо по этому формату. По этим отчётам потом хорошо искать причины похожих проблем. И учить новеньких.

17Что осталось сделать?

Закрывать тикет можно только когда ответ на этот вопрос пуст.

Как быть уверенным, что сделано действительно всё? Доверять внутреннему чутью. Чутье — это накопленный опыт и боль.

Ещё раз алгоритм списком (можете скопировать к себе)

  1. Обнаружена проблема
  2. Подтвердить получение проблемы и срок реакции
  3. Оценить критичность и составить план действий
  4. Убедиться, что проблема действительно есть
  5. Подтвердить, что проблема есть, и сказать, когда исправите
  6. Исправить
  7. Проинформировать
  8. Сделать контрольную проверку
  9. Проинформировать
  10. Что могло сломаться рядом? Что могли сломать, пока чинили?
  11. Проинформировать
  12. Посчитать цену ошибки
  13. Проинформировать
  14. Найти системное решение
  15. Проинформировать
  16. Сделать отчёт для себя / команды / клиента в будущем
  17. Что осталось сделать?

Резюме

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

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

Полный текст статьи читайте на CMS Magazine