​Разработчик в Discovery: профит для продукта

Непринуждённым движением программист переодевается в продуктового разработчика.
И вот он уже может участвовать в проработке задачи на ранних этапах.

Прорабатывая задачу, разработчик получает тонну мотивации потом её реализовать. Это теперь _его_ задача, от начала и до конца.

Чем же он может помочь?

📌 В первую очередь, технической экспертизой.

1️⃣ — Примерно оценить стоимость разработки даже сырой задачи.
Можно не тратить время на проработку космических по сложности задач с сомнительным эффектом.

2️⃣ — Предложить вариант решения продуктовой проблемы по принципу Парето.
Иногда срезание 20% объема бизнесовой задачи дают экономию 80% в ресурсах на разработку. Важно: это не должно значить снижение качества решения.

3️⃣ — Знание больных мест системы позволяет протащить задачи по рефакторингу.
После рефакторинга открывается портал в инженерный рай, из которого начинают сыпаться фичи. Мы так случайно приделали новый способ оплаты на платежную форму 🙂

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

Пунктов было больше. Для удобства читателя я разбил пост на два. Отдельно будет про то, как задействовать другое полушарие разработчика.