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

Gems Development
Nov 8 · 4 min read

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

Дмитрий Ульянов, веб-разработчик

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

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

Нам всегда было свойственно преодолевать невозможное…

Классика: метод утенка

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

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

Метод утенка 2.0

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

Как показывает моя практика, две трети трудных задач и затыков решаются именно на этапе изложения и осмысления проблемы. Но остается еще одна треть. Поэтому если вы не услышали крика “Эврика!”, то вооружайтесь маркерами и переходите к следующему этапу — доске для рисования.

Визуализируй это

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

визуализируем проблему в нашей LeSS-команде

Неочевидные проявления метода утенка

Многие инженерные практики разработчиков: парное и mob-программирование, test driven development, code review учитывают полезное действие метода утенка.

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

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

Отдельно стоит сказать про mob-программирование, которое, как и визуализация на доске, основано на получении обратной связи от коллег. В групповом программировании за тем, как человек пишет код, наблюдает вся его команда. Это помогает не буксовать в трудных местах и (в крайних случаях) принять объективное решение о нереализуемости задачи.

разработчик Антон пишет код при участии аналитика Иры и дизайнера Тони

В качестве вывода

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

    Gems Development

    Written by

    Разрабатываем GIS для городов и делимся опытом

    Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
    Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
    Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade