Статьи

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

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

Победителей, как известно, не судят. А вот если мы побеждены - что делать дальше? С чего начать, чтобы понять свои ошибки и извлечь из них полезный опыт?

Тем, кто успел поработать в крупных корпорациях (особенно в азиатских) наверняка знакома методика, которую называют Five Whys. Это методика, изначально придуманная инженерами для того, чтобы наверняка добраться до причины или источника какой-нибудь проблемы. А менеджеры часто использует ее для отказа в какой-нибудь просьбе или “отфутболивания” новой идеи. Принцип действия очень прост. Вы обращаетесь с просьбой или предложением к начальству, и оно просит вас обосновать необходимость того, что вы просите или предлагаете. И далее, слушая ваши ответы, задает вам пять вопросов “зачем” или “почему”, чтобы выяснить, насколько хорошо обоснованы ваша просьба или ваше предложение. Как правило, большинство людей теряет терпение уже где-то на третьем вопросе.

Выглядит это примерно так:
- Нам нужно приобрести 4 дополнительных монитора для этого проекта.
- Зачем?
- Мы хотим, чтобы на рабочих местах у всех, кто принимает участие в разработке продукта, было установлено по 2 монитора.
- Почему?
- Это удобно.
- Почему?
- Разработчику не нужно сворачивать и вновь разворачивать окна во время написания и исполнения кода.
- Почему это так важно?
- Потому что мы живем в XXI веке, и переключение между окнами нереально раздражает!

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

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

Итак, я сегодня не доделала этот отчет.
- Почему?
- Потому что отвлекалась.
- Почему?
- Ну… сначала был митинг, а потом мы праздновали день рождения А., поздравляли именинника, а потом я начала заниматься отчетом, но не закончила.
- Почему?
- Потеряла время, а потом поняла, что все равно не закончу задачу в срок.
- Почему?
- Потому что на митинг и празднование дня рождения ушло много времени.
- Почему?
- Ну… на митинг пригласило начальство. А не отметить день рождения как-то не очень здорово… Но и отчет не доделать тоже.

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

На следующий день отчет все-таки был доделан.

Но следующая задача, которой я занялась вскоре после отчета, снова была просрочена.

- Почему?
- Добавленный мной код выдавал ошибку, на исправление которой у меня ушло лишних 4 часа.
- В чем причина ошибки?
- Я плохо понимаю, как работают методы классов BLL.
- Почему?
- Не понимаю, в каком порядке нужно вызывать эти методы в данном случае.
- Почему?
- Плохо ориентируюсь в исходном коде всего проекта в целом.
- Почему?
- Нет необходимой документации.
Записываем потерю времени на исправление ошибок, отмечаем как пожелание: документирование системной архитектуры. Сравниваем мои “рекорды” с такими же досадными потерями моих коллег. Если затраты времени на исправление ошибок превышают время, которое нужно потратить на документирование, решение напрашивается само собой.

Итак, просто отвечая на пять вопросов, я могу достаточно точно установить причины задержек с выполнением задач. Если эти причины будут повторяться (например, вторая), то скорее всего, мы имеем дело с систематическим риском, причину которого необходимо устранить.

Метод five whys применим не только в рабочей обстановке. Что там у нас с личными целями?
- У меня была заветная мечта - съездить отдохнуть в Черногорию. Но увы, она так и не сбылась.
- Почему?
- Да срок действия загранпаспорта истекает, а новый сделать некогда…
- Почему?
- Никак не соберу все нужные документы.
- Почему?
- У них ограниченный срок действия, а дойти до паспортного стола вовремя я все равно не соберусь…
- ПОЧЕМУ?

Волшебная техника, trust me.
Главное - отвечать честно.