💭 В разработке редко бывают решения, где есть очевидно правильный ответ

Переписывать старый сервис или оставить как есть? Переезжать на новую базу данных или нет? Выносить функциональность в отдельный микросервис или пока рано?

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

Один из инструментов, который помогает сделать принятие решения объективным - Decision Matrix.

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

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

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

И это лишь один из инструментов принятия решений. Есть еще Pros & Cons, квадрат Декарта, а также различные методы, например правило 10/10/10, метод советника и другие подходы. Кстати, все эти инструменты мы подробно разбираем на тренинге по soft skills для разработчиков в Москве 19–20 сентября: https://balun.courses/softskills.

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

Кто я | Навигация | Спасибо