Черные дыры разработки: как решать задачи, которые не решаются

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

Я занимаюсь веб-разработкой больше десяти лет и хочу поделиться в этой статье методами, которые помогают мне и моим коллегам закрывать такие сложные задачи. Они будут полезны разработчикам, тестировщикам, SCRUM-мастерам, владельцам продукта и всем, чья работа требует креативности.
Когда классная задача имеет все шансы стать черной дырой? Когда проект большой и сложный. Когда приходится работать с не самым лучшим кодом или интегрироваться с системой, которая давно дышит на ладан (в идеальном мире такого не случается, а вот в реальном вполне). Когда не хватает практического опыта в каком-то из аспектов проекта. Когда случается творческий кризис, в конце концов.

Классика: метод утенка
Одна из самых известных в IT-среде техник для решения трудных задач — метод утенка, описанный Эндрю Хантом и Дэвидом Томасом в книге “The Pragmatic Programmer”. Он заключается в делегировании проблем мысленному помощнику: авторы советуют подробно изложить ситуацию неодушевленному объекту (например, резиновой уточке). Считается, что правильно сформулированный вопрос содержит в себе половину ответа и помогает направить мысли в нужное русло.
Метод в целом довольно рабочий, но эффективно использовать его сможет только человек с высоким уровнем эмоционального интеллекта и самоанализа. Все остальные могут пару раз обратиться к утке для проформы, не получить никаких идей и продолжить бесконечно перебирать варианты решений. Поэтому я немного адаптировал эту технику, чтобы она стала универсальнее.
Метод утенка 2.0
Вести задушевные разговоры с резиновым неодушевленным предметом сложно, а с молчаливым и понимающим товарищем — гораздо легче. Вам нужно сыграть для любимого коллеги роль резиновой уточки и внимательно выслушать все, что он скажет. Важно! Суть метода заключается не в том, чтобы дать совет, а в том, чтобы помочь человеку найти решение самостоятельно. Поэтому слушайте все до конца, не перебивайте, не предлагайте и не комментируйте. Если вам есть что добавить или рассказать — записывайте в блокнот и ждите момента, когда рассказчик закончит.
Как показывает моя практика, две трети трудных задач и затыков решаются именно на этапе изложения и осмысления проблемы. Но остается еще одна треть. Поэтому если вы не услышали крика “Эврика!”, то вооружайтесь маркерами и переходите к следующему этапу — доске для рисования.
Визуализируй это
Визуализация — еще один рабочий и действенный инструмент, поэтому я стараюсь использовать оба метода вместе. Попросите человека зафиксировать на доске все, о чем он только что рассказывал: рисунком, схемой, словами, чем угодно. Добавьте свои комментарии из блокнота. На этом этапе к обсуждению могут подключаться и другие коллеги, но постарайтесь, чтобы обсуждающих было не больше четырех, иначе возникнет шумиха. Фиксируйте все идеи, стирайте ненужное, и под конец у вас получится наглядная карта решений. Оставьте ее в таком виде на день-другой, и обязательно сфотографируйте. Проблемы, которые доходят до этой стадии, просто обязаны стать кейсами для внутреннего обучения.

Неочевидные проявления метода утенка
Многие инженерные практики разработчиков: парное и mob-программирование, test driven development, code review учитывают полезное действие метода утенка.
Например, кодинг в паре с другим программистом — это и есть работа с живой резиновой уточкой. Парное программирование повышает качество кода и продуманность решения, а еще помогает разделить базу знаний между несколькими разработчиками. Если напарники мыслят на одной волне, то в случае возникновения ступора у одного, второй понимает его с полуслова и помогает разобраться в проблеме.
Разработка через тестирование тоже отлично помогает увидеть слабые места кода: написание тестов является фактическим изложением проблемы на псевдоязыке, заставляет разработчика формулировать четче и думать чище. Чем больше тестов он напишет на разрабатываемую задачу, тем больше он увидит лишних классов и интерфейсов, классов с избыточными ответственностями, чрезмерной связанностью и многого другого.
Отдельно стоит сказать про mob-программирование, которое, как и визуализация на доске, основано на получении обратной связи от коллег. В групповом программировании за тем, как человек пишет код, наблюдает вся его команда. Это помогает не буксовать в трудных местах и (в крайних случаях) принять объективное решение о нереализуемости задачи.

В качестве вывода
Все мы работаем как минимум ради трех благих целей: причинить счастье пользователям, своей компании и себе дорогому. А потому не проходите мимо своего коллеги, который попал в замкнутый круг сансары — попробуйте выслушать его по всем правилам rubber duck method. Потратив не такое большое количество времени и сил, вы можете помочь ему найти достойное решение. А когда-нибудь он поможет вам.
