Проблемы неизбежны. Что-то ломается каждый день. Но правильно говорят: бойтесь не того, что все сломалось, а незнания, что делать. Меня зовут Сергей, я работаю в ИТ более 17 лет. В этой статье мы поговорим о таком полезном навыке, как problem solving. Если не вдаваться в пространные определения, это умение решать проблемы; даже не конкретная техника, а способ мышления.

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

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

Путь решения проблемы

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

Первая реакция - паника

Что мы делаем, когда видим, что есть большая проблема?
Паникуем: “Что же делать? Как быть?”

Важно помнить, что паника не имеет никакого отношения к решению - это всего лишь первая реакция.

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

Первый уровень решения - диагностика

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

Второй уровень - изоляция проблемы

Далее мы начинаем анализ произошедшего - собираем максимум доступной информации. Обращаемся к истории - что предшествовало возникновению проблемы? Что можно сказать по метрикам?

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

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

Третий уровень - гипотезы и тестирование

На третьем уровне мы предлагаем варианты решения проблемы и пытаемся их применить.

Если мы все еще находимся на солнце, возможно, стоит уйти в тень, чтобы не сделать хуже прямо сейчас? Где крем? Он поможет сделать не больно? Когда-то мы что-то слышали про народные средства - а они помогут?

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

Четвертый уровень - поиск устойчивого решения

Это самый мощный и полезный уровень. Что мы можем сделать, чтобы проблема не повторилась?

Возвращаясь к нашему примеру с пляжем - мы можем сделать вывод, что не надо выходить на солнце в полдень неподготовленными. Согласитесь, было бы странно, если бы я каждый день приходил на пляж без зонта, лежал там ровно с 11 до 13 и удивлялся, почему ухожу красным. Поверьте, некоторые проблемы в ИТ выглядят примерно так же.

Как правило именно в ИТ для поиска устойчивого решения используется ретроспектива.

Подходы к решению проблем

Здесь я опишу пять методов решения проблем. Сам я пользуюсь только тремя из них, но это уже дело вкуса.

Метод пяти “почему”

Довольно известный метод, предложенный основателем компании Toyota, Сакити Тоёдой в середине XX века. Этот метод стал основой бережливого производства. И хотя в целом к бережливому производству в современных реалиях есть много замечаний, отдельные подходы работают хорошо.

Сакити Тоёда рекомендовал выявлять корень проблемы, пять раз подряд задавая вопрос “почему”: “почему так получилось”?... потому что вот это произошло… “а почему это произошло?”... и так далее. Эти вопросы помогают проникнуть через поверхностные слои, докопавшись до сути проблемы.

Метод уточки

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

Как менеджер я вижу, что многие приходят к своему руководителю, начинают описывать проблему, но потом прерывают рассказ на середине: “О, я нашел решение”. Руководитель еще не успел ничего ответить - он даже не дослушал описание до конца. Однако решение уже нашлось само собой.

Метод уточки - это психологический подход, когда то, что вы делаете (или то, что вас поставило в тупик) нужно проговорить так, чтобы это было понятно условной уточке, которая вас слушает.

Два интересных факта про этот метод:

• Код-ревью побуждает нас использовать метод уточки. Мы проговариваем, что будет делать код.

• Метод уточки (правда, под другим названием) упоминался в книге “Практика программирования” еще в нулевых годах. Там идея была в том, что не стоит идти к коллеге с вопросами, пока вы не проговорили проблему медвежонку. И вот если медвежонок ответа не даст, тогда уже можно отвлекать руководителя / наставника.

Лимит времени

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

Метод ограничения времени, как и уточка, работает на уровне психологии. Для возникшей проблемы вы ставите себе лимит, допустим, в 30 минут: “Я полчаса занимаюсь задачей, а если не получится, пойду за помощью”. 

Идея метода основана на том, что время - это на самом деле ресурс. Не сливайте его бездумно. Заметили, что на дейликах обсуждаются задачи, но очень редко всплывают проблемы? Это связано с тем, что люди бояться признаться. И это плохо, поскольку проблемы всплывут позже. Признаться коллеге, что вы что-то не можете сделать, - это не слабость. Помощь в данном случае может дать хороший буст и не только в решении конкретной проблемы, но и в саморазвитии в целом. Как только поймете, что обратиться за помощью - не стыдно, вы становитесь командным игроком, причем довольно сильным.

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

Ментальные модели

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

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

Визуализация

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

Вперед и вверх

Тема решения проблем сложная. К ней приходишь, отработав в ИТ лет 7. Однако если погрузиться в существующие методики уже после 3-4 лет опыта, можно вырасти гораздо быстрее. Это тот самый путь, который поможет сэкономить время.

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

Чтобы встать на этот путь, стоит сменить парадигму - важно не кто сломал, а кто починил. Она в нашей профессиональной жизни многое меняет. Если человек ошибается, не надо над ним смеяться и всячески подчеркивать его проблему. Помогите ему, подумайте, как предотвратить такие ошибки в будущем.

Советуйтесь с более опытными коллегами, как они подходят к решению проблем. Допустим, кто-то был в отпуске и не принимал участие в решении очередного бага. Если у вас с ним хорошие отношения, можно подойти и поинтересоваться его мнением, с какой стороны он подошел бы к решению в такой ситуации? Что использовал бы для диагностики? Это хороший способ учиться.

Разбирайте проблемы после их решения. Фиксируйте результаты этого разбора. Участвуйте в ретроспективах, при этом обязательно готовьтесь к ним - это ключевой момент. Именно ретро делает вашу работу эффективнее.

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

Автор: Сергей, Максилект.

P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на нашу страницу в VK или на Telegram-канал, чтобы узнавать обо всех публикациях и других новостях компании Maxilect.