Важность диалога между PM-ом и разработчиком

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

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

Кейс разработки.
Разработчик «завис» над простой задачей. Занимался задачей две недели. По результатам двух недель работы внес в репозиторий изменений на 10-20 строк кода. В отчете по задаче множество технических деталей. В отчете выставил необходимость дополнительного времени на доработку задачи.

Если для вас кейс очевиден, то можно дальше и не читать.

Список проблем.

Перерасход бюджета. Разработчик потратил уйму времени на простую фичу и требует дополнительное время.

Разработчик не способен аргументировать необходимость больших временных затрат на простую фичу.

Возможность конфликта с разработчиком.


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

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

Возможность дальнейших прецедентов «построения замков» со стороны разработчика. Разработчик, возможно, будет игнорировать указания руководителя и самостоятельно выделять время на улучшение качества системы. За счёт основных фич, т.е. с уменьшением затрат на основную функциональность, которая приносит прибыль.

Разработчик не умеет перевести технические детали предполагаемого решения на язык преимуществ для пользователя.

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

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

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


И так далее. (Прописываю только часть проблем.)

Решения.


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

Спасибо.

Источник: https://habr.com/ru/post/535278/


Интересные статьи

Интересные статьи

Всем привет. Если вы когда-либо работали с универсальными списками в Битрикс24, то, наверное, в курсе, что страница детального просмотра элемента полностью идентична странице редак...
Bump maps (рельефные текстуры), Normal maps (карты нормалей), Displacement и Vector Displacement — вероятно, вы уже сталкивались хотя бы с одним из этих терминов. Несмотря на то, чт...
Возможность интеграции с «1С» — это ключевое преимущество «1С-Битрикс» для всех, кто профессионально занимается продажами в интернете, особенно для масштабных интернет-магазинов.
Мы уже далеко не первый год выпускаем планшеты и компьютеры серии Rugged – максимально защищённые устройства для работы в откровенно экстремальных условиях. Но рассказываем о них не так часто, ка...
Существует традиция, долго и дорого разрабатывать интернет-магазин. :-) Лакировать все детали, придумывать, внедрять и полировать «фишечки» и делать это все до открытия магазина.