[Управление разработкой] Важность диалога между PM-ом и разработчиком
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Рассматривается кейс разработки, определяются некоторые проблемы, формулируется необходимость диалога. Кейс разработки.
Разработчик «завис» над простой задачей. Занимался задачей две недели. По результатам двух недель работы внес в репозиторий изменений на 10-20 строк кода. В отчете по задаче множество технических деталей. В отчете выставил необходимость дополнительного времени на доработку задачи. Если для вас кейс очевиден, то можно дальше и не читать. Список проблем.
Перерасход бюджета. Разработчик потратил уйму времени на простую фичу и требует дополнительное время. Разработчик не способен аргументировать необходимость больших временных затрат на простую фичу. Возможность конфликта с разработчиком.
Возможность демотивации разработчика. Разработчик не доволен качеством существующей системы. Разработчик старался улучшить систему. Задача полностью не решена. Но работать с некачественной системой у разработчика мало мотивации. Возможность деградации отношения разработчика к руководителю. С точки зрения разработчика руководитель не понимает важности деталей технической аргументации в улучшении качества системы.
Возможность дальнейших прецедентов «построения замков» со стороны разработчика. Разработчик, возможно, будет игнорировать указания руководителя и самостоятельно выделять время на улучшение качества системы. За счёт основных фич, т.е. с уменьшением затрат на основную функциональность, которая приносит прибыль. Разработчик не умеет перевести технические детали предполагаемого решения на язык преимуществ для пользователя.
Разработчик не может сформулировать почему низкое качество системы ведёт к ухудшению бизнес показателей продукта. Разработчик не понимает, какие функции выполняет руководитель. В чем его обязанности для продвижения продукта. Разработчик не умеет выразить технические детали на языке преимуществ продукта и поэтому не пытается выйти за рамки технического диалога.
Разработчик не знаком со стратегией развития продукта. Поэтому предлагает решения, которые не нужны на текущем этапе развития продукта.
И так далее. (Прописываю только часть проблем.)
Решения.
Решения для каждой из проблем не предлагаю, потому что знаю, что у читателя достаточно опыта для понимания ситуации и определения подходов и стратегий реагирования, и достаточно профессионализма для поиска возможных решений.
Спасибо.
===========
Источник:
habr.com
===========
Похожие новости:
- [Управление разработкой, Управление проектами, Фриланс, Производство и разработка электроники, Электроника для начинающих] Как разработать корпус силами фрилансеров — промдизайнеров и конструкторов
- [Профессиональная литература, Управление разработкой, Управление проектами, Управление персоналом, Карьера в IT-индустрии] 10 полезных книг для менеджера и лидера в IT секторе
- [GTD, Лайфхаки для гиков] Опуститься до уровня руководителя?
- [IT-стандарты, Service Desk] Управлять знаниями это не только хранить документацию (перевод)
- [Облачные вычисления, Серверное администрирование, Управление разработкой, Облачные сервисы] CloudMaster — это про самообслуживание разработчиков в корпоративном ЦОДе и облачных сервисах
- [Python, Управление разработкой, Управление проектами, Управление персоналом, Карьера в IT-индустрии] Я единственный из 1400, или самый крутой рекрутинг, что я проходил
- [Управление разработкой] На пути к Canary
- [Управление разработкой, Развитие стартапа, Управление продуктом, Управление продажами, Управление персоналом] Как перестать впаривать и начать развивать продукт, привлекая новых клиентов
- [JavaScript, Google Chrome, Расширения для браузеров, Хранение данных, Хранилища данных] Использование Redux в MV3 расширениях Chrome (перевод)
- [Программирование, Разработка мобильных приложений, Dart, Flutter] Как мы сделали миграцию пользовательских данных с нативного приложения на Flutter
Теги для поиска: #_upravlenie_razrabotkoj (Управление разработкой), #_development, #_dialog, #_management, #_manager, #_upravlenie_razrabotkoj (
Управление разработкой
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 23-Ноя 01:38
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Рассматривается кейс разработки, определяются некоторые проблемы, формулируется необходимость диалога. Кейс разработки. Разработчик «завис» над простой задачей. Занимался задачей две недели. По результатам двух недель работы внес в репозиторий изменений на 10-20 строк кода. В отчете по задаче множество технических деталей. В отчете выставил необходимость дополнительного времени на доработку задачи. Если для вас кейс очевиден, то можно дальше и не читать. Список проблем. Перерасход бюджета. Разработчик потратил уйму времени на простую фичу и требует дополнительное время. Разработчик не способен аргументировать необходимость больших временных затрат на простую фичу. Возможность конфликта с разработчиком. Возможность демотивации разработчика. Разработчик не доволен качеством существующей системы. Разработчик старался улучшить систему. Задача полностью не решена. Но работать с некачественной системой у разработчика мало мотивации. Возможность деградации отношения разработчика к руководителю. С точки зрения разработчика руководитель не понимает важности деталей технической аргументации в улучшении качества системы. Возможность дальнейших прецедентов «построения замков» со стороны разработчика. Разработчик, возможно, будет игнорировать указания руководителя и самостоятельно выделять время на улучшение качества системы. За счёт основных фич, т.е. с уменьшением затрат на основную функциональность, которая приносит прибыль. Разработчик не умеет перевести технические детали предполагаемого решения на язык преимуществ для пользователя. Разработчик не может сформулировать почему низкое качество системы ведёт к ухудшению бизнес показателей продукта. Разработчик не понимает, какие функции выполняет руководитель. В чем его обязанности для продвижения продукта. Разработчик не умеет выразить технические детали на языке преимуществ продукта и поэтому не пытается выйти за рамки технического диалога. Разработчик не знаком со стратегией развития продукта. Поэтому предлагает решения, которые не нужны на текущем этапе развития продукта. И так далее. (Прописываю только часть проблем.) Решения. Решения для каждой из проблем не предлагаю, потому что знаю, что у читателя достаточно опыта для понимания ситуации и определения подходов и стратегий реагирования, и достаточно профессионализма для поиска возможных решений. Спасибо. =========== Источник: habr.com =========== Похожие новости:
Управление разработкой ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 23-Ноя 01:38
Часовой пояс: UTC + 5