Как человек, который работает консультантом по бесперебойной работе и техническому обеспечению надёжности в Postgres, я провел много часов, выполняя функции резинового утёнка. Теперь могу заткнуть за пояс даже самую проницательную игрушку для купания.
Метод утёнка в отладке – это распространенное шутливое обозначение для практики, в рамках которой человек вслух объясняет сложную проблему, загнавшую его в тупик. Часто простой перевод собственных затруднений в слова приводит к неожиданному прозрению, которое расчищает путь вперед. В качестве собеседника может с равным успехом выступать и неодушевленный предмет, например резиновый утёнок. Откуда и название.
Резиновые утята – это, конечно, здорово, но живой человек может дать еще больше. В этой статье я поделюсь тремя своими любимыми вопросами, которые обычно задаю, когда ко мне приходит коллега с ощущением, что наглухо застрял в попытках устранить баг. Эти вопросы работают, даже если у вас нет никаких особых знаний в области, к которой относится конкретная проблема. Освойте их, и вы быстро обзаведетесь репутацией человека, с которым полезно поговорить, когда зашел в тупик. А это отличная репутация!
В процессе размышления над проблемой наше внимание переходит с одного на другое, а потом и на третье. Мы начинаем мыслить в определенном направлении, а про другие доступные направления забываем. Мы погружаемся в детали и забываем вернуться к общей картине. Здесь очень просто утратить объективность.
Вопрос «С чего у вас началось изучение проблемы?» дает хорошие результаты, так как одно то, что ваш коллега начнет припоминать весь пройденный путь, от первых наблюдений до текущего момента, может помочь ему вернуть утерянную в процессе объективность. А предложенная формулировка избавляет вас от необходимости открыто предполагать, что собеседник, возможно, однобоко смотрит на дело – это могло бы подтолкнуть его к оборонительной позиции.
Если даже коллега вполне объективен в своих изысканиях, для вас всё равно будет не лишним послушать пересказ проделанной им работы – так вы сможете задавать более удачные вопросы и помогать ему с упорядочиванием мыслей.
При устранении багов в сложных случаях легко упустить из виду то, что вам уже известно. По мере продвижения в работе вы отмечаете множество разных вещей – мелких и крупных, интересных и скучных, важных и неважных. Удержать в голове их все просто невозможно.
Если человек забуксовал, часто бывает полезным провести обзор всех его наблюдений. Не теорий, не сложностей, не действий, а непосредственно наблюдаемых фактов.
Собрать воедино все факты стоит по нескольким различным причинам:
Пока коллега перечисляет наблюдения, записывайте их, составляя пронумерованный список. По возможности задавайте уточняющие вопросы. Например: «X всегда происходит параллельно с Y или только в некоторых случаях?» или «В чем заключается отличие от стандартного поведения?»
Это мой самый любимый вопрос.
Одна из самых распространенных причин, по которым люди попадают в тупик при устранении багов – туннельное видение. Они зацикливаются на какой-то одной версии об источнике проблемы и больше ни о чем не могут думать.
Вопрос «Предположим, ваша гипотеза неверна, как можно это доказать?» сбивает их с проторенного пути. Вместо того, чтобы напрягать извилины в попытках доказать свою правоту, они вынуждены задуматься о других возможностях. Этот вопрос может привести к нескольким разным исходам, но при любом из них ваш коллега окажется ближе к цели:
Если заглянуть под капот, то эти три вопроса – просто разные способы применения гипотетико-дедуктивного метода, о котором я уже писал в других своих статьях (Устранение багов в распределенной команде с сохранением общего контекста и Знаете, кто умный? Чертовы доктора, вот кто). Я не знаю лучшего способа стабильно получать результат при устранении багов вопреки сложности.
Если вам интересно, как применять эти техники в своей карьере или в организации, то я готов помочь. Пишите мне на почту.
Метод утёнка в отладке – это распространенное шутливое обозначение для практики, в рамках которой человек вслух объясняет сложную проблему, загнавшую его в тупик. Часто простой перевод собственных затруднений в слова приводит к неожиданному прозрению, которое расчищает путь вперед. В качестве собеседника может с равным успехом выступать и неодушевленный предмет, например резиновый утёнок. Откуда и название.
Резиновые утята – это, конечно, здорово, но живой человек может дать еще больше. В этой статье я поделюсь тремя своими любимыми вопросами, которые обычно задаю, когда ко мне приходит коллега с ощущением, что наглухо застрял в попытках устранить баг. Эти вопросы работают, даже если у вас нет никаких особых знаний в области, к которой относится конкретная проблема. Освойте их, и вы быстро обзаведетесь репутацией человека, с которым полезно поговорить, когда зашел в тупик. А это отличная репутация!
Первый вопрос: С чего у вас началось изучение проблемы?
В процессе размышления над проблемой наше внимание переходит с одного на другое, а потом и на третье. Мы начинаем мыслить в определенном направлении, а про другие доступные направления забываем. Мы погружаемся в детали и забываем вернуться к общей картине. Здесь очень просто утратить объективность.
Вопрос «С чего у вас началось изучение проблемы?» дает хорошие результаты, так как одно то, что ваш коллега начнет припоминать весь пройденный путь, от первых наблюдений до текущего момента, может помочь ему вернуть утерянную в процессе объективность. А предложенная формулировка избавляет вас от необходимости открыто предполагать, что собеседник, возможно, однобоко смотрит на дело – это могло бы подтолкнуть его к оборонительной позиции.
Если даже коллега вполне объективен в своих изысканиях, для вас всё равно будет не лишним послушать пересказ проделанной им работы – так вы сможете задавать более удачные вопросы и помогать ему с упорядочиванием мыслей.
Второй вопрос: Какие вы сделали наблюдения?
При устранении багов в сложных случаях легко упустить из виду то, что вам уже известно. По мере продвижения в работе вы отмечаете множество разных вещей – мелких и крупных, интересных и скучных, важных и неважных. Удержать в голове их все просто невозможно.
Если человек забуксовал, часто бывает полезным провести обзор всех его наблюдений. Не теорий, не сложностей, не действий, а непосредственно наблюдаемых фактов.
Собрать воедино все факты стоит по нескольким различным причинам:
- Возможно, человек рассматривает гипотезу, которая входит в противоречие с каким-то фактом, который он ранее установил, но впоследствии забыл. В таком случае он сможет смело отказаться от этой гипотезы.
- Сопоставление двух фактов может навести на новое предположение, которое до этого не приходило человеку в голову, потому что он не удерживал в голове и то, и другое одновременно.
- Перечисление наблюдений может навести на мысль о чем-то, что еще не было изучено.
Пока коллега перечисляет наблюдения, записывайте их, составляя пронумерованный список. По возможности задавайте уточняющие вопросы. Например: «X всегда происходит параллельно с Y или только в некоторых случаях?» или «В чем заключается отличие от стандартного поведения?»
Третий вопрос: Предположим, ваша гипотеза неверна, как можно это доказать?
Это мой самый любимый вопрос.
Одна из самых распространенных причин, по которым люди попадают в тупик при устранении багов – туннельное видение. Они зацикливаются на какой-то одной версии об источнике проблемы и больше ни о чем не могут думать.
Вопрос «Предположим, ваша гипотеза неверна, как можно это доказать?» сбивает их с проторенного пути. Вместо того, чтобы напрягать извилины в попытках доказать свою правоту, они вынуждены задуматься о других возможностях. Этот вопрос может привести к нескольким разным исходам, но при любом из них ваш коллега окажется ближе к цели:
- Вы обнаружите способ доказать ложность гипотезы и успешно это проделаете. Не исключено, что это на несколько часов испортит вашему коллеге настроение, но, когда он опять вернется к проблеме, то начнет продвигаться куда стремительнее.
- Вы обнаружите способ доказать ложность гипотезы, но он не сработает. Таким образом, гипотеза получит подкрепление, и станет ясно, каким должен быть следующий шаг: выделить внутри ее несколько версий и попытаться опровергнуть теперь уже их.
- Вам не удастся придумать способ проверить гипотезу на истинность. Это значит, что она, вероятно, вообще может считаться гипотезой, раз не обладает опровергаемостью. Значит, ее нужно заменить другой гипотезой. Может показаться, что это регресс, но на самом деле, только так можно продолжать движение вперед.
Собирая всё воедино
Если заглянуть под капот, то эти три вопроса – просто разные способы применения гипотетико-дедуктивного метода, о котором я уже писал в других своих статьях (Устранение багов в распределенной команде с сохранением общего контекста и Знаете, кто умный? Чертовы доктора, вот кто). Я не знаю лучшего способа стабильно получать результат при устранении багов вопреки сложности.
Если вам интересно, как применять эти техники в своей карьере или в организации, то я готов помочь. Пишите мне на почту.
