Рассматривается кейс разработки, определяются некоторые проблемы, формулируется необходимость диалога.
Кейс разработки
Разработчик «завис» над простой задачей. Занимался задачей две недели. По результатам двух недель работы внес в репозиторий изменений на 10-20 строк кода. В отчете по задаче множество технических деталей. В отчете выставил необходимость дополнительного времени на доработку задачи.
Если для вас кейс очевиден, то можно дальше и не читать.
Список проблем
Перерасход бюджета. Разработчик потратил уйму времени на простую фичу и требует дополнительное время.
Разработчик не способен аргументировать необходимость больших временных затрат на простую фичу.
Возможность конфликта с разработчиком.
Возможность демотивации разработчика. Разработчик не доволен качеством существующей системы. Разработчик старался улучшить систему. Задача полностью не решена. Но работать с некачественной системой у разработчика мало мотивации.
Возможность деградации отношения разработчика к руководителю. С точки зрения разработчика руководитель не понимает важности деталей технической аргументации в улучшении качества системы.
Возможность дальнейших прецедентов «построения замков» со стороны разработчика. Разработчик, возможно, будет игнорировать указания руководителя и самостоятельно выделять время на улучшение качества системы. За счёт основных фич, т.е. с уменьшением затрат на основную функциональность, которая приносит прибыль.
Разработчик не умеет перевести технические детали предполагаемого решения на язык преимуществ для пользователя.
Разработчик не может сформулировать почему низкое качество системы ведёт к ухудшению бизнес показателей продукта.
Разработчик не понимает, какие функции выполняет руководитель. В чем его обязанности для продвижения продукта. Разработчик не умеет выразить технические детали на языке преимуществ продукта и поэтому не пытается выйти за рамки технического диалога.
Разработчик не знаком со стратегией развития продукта. Поэтому предлагает решения, которые не нужны на текущем этапе развития продукта.
И так далее. (Прописываю только часть проблем.)
Решения
Решения для каждой из проблем не предлагаю, потому что знаю, что у читателя достаточно опыта для понимания ситуации и определения подходов и стратегий реагирования, и достаточно профессионализма для поиска возможных решений.
Спасибо.
silent_jeronimo
Как следует из моего опыта, если вслушаться в технический диалог, то внезапно можно узнать, что:
• без переписывания старого кода разработка нового будет идти дольше, и потом придётся переписывать ещё и его;
• если не переписать существующий API, то есть шанс слить все персональные данные пользователей, имеющиеся в системе, одним запросом;
• ну и тому подобное.
Если PM не может отринуть свой снобизм и вслушаться в то, что говорит разработка, то это плохой, негодный ПМ. Потому, что перевод с языка бизнес-задач в язык разработчиков и обратно — его прямые должностные обязанности, так-то.
Agat_Cyber
позвольте теперь мне крик души))
не всякий случай показывает, что плох именно РМ. Иногда разрабы просто слишком звёздные и гениальные — им как ни переводи, всё равно будут делать по-своему...«потому что он вот такой герой и лучше знает, чё рынку надо». Хотя сам даже стакан семечек в метро не сможет продать. наверное, всё-таки должен присутствовать баланс интересов и разумная дистанция с чётко очерченным кругом обязанностей.
ПС. Говорю с позиции РМ, извините)))
klizardin Автор
Извините, это не оскорбление?
Извините, это не оскорбление?
Вы тролль?
Agat_Cyber
ну, сэр, если вам тут чудятся оскорбления, то я уже понимаю, с какого у вас рейтинг -11.
всё. конкретно у нас диалога не будет.
бред какой-то пишете.
что статья, что комменты.
klizardin Автор
Это газлайтинг?
klizardin Автор
Вы оскорбляете разработчиков фразами?:
silent_jeronimo
Так и я с позиций ПМа говорю.
Зазвездился или не зазвездился, презирает всех менеджеров или молча делает то, что они говорят — вы ПМ и должны разруливать такие ситуации в пользу бизнеса.
Инструментов у вас есть.
lumini
> всё равно будут делать по-своему
За вот это очень цепляется глаз. Продакт — принимает решение о направлении развития и формирует бизнес-требования. Разработчик — реализует их (а хороший разработчик еще и предлагает технические оптимизации, не видные продакту). Если разработчик что-то кодит самовольно, это явный косяк процессов. Можно задуматься, почему так происходит и кто в этом виноват (явно не разработчик, если продакт позволяет ему делать то, что описано выше; тут либо что-то не так с авторитетом продакта, либо нежелание экскалировать ситуацию и привлечь людей выше по должности). В любом случае, такое надо исправлять.
> стакан семечек в метро не сможет продать
Звучит правда немного обидно. Все вроде бы понимают, что продавать семки в метро — не задача разработчика. Как и продакта — разбираться во внутренностях линукса.
ggo
PM — Project Manager?
Канонический проджект менеджер должен шарить «в переводе с языка бизнес-задач в язык разработчиков и обратно»?
klizardin Автор
Да.
ggo
silent_jeronimo
Я, возможно, немного отстал от жизни, и все уже переменилось…
Можете дать ссылку на гайд, фреймворк, или еще что-нибудь, чем руководствуются современные проджект менеджеры, в котором явным образом упоминается обязанность PM про перевод бизнес-требований на технический язык?
Всегда думал, что единственная обязанность PM — завершить успешно проект. А переводит на технический он сам, или отдельный специально-обученный человек, в общем случае не важно.
silent_jeronimo
ну вот взятый с полки PMBoK пятой редакции с первых страниц говорит нам о том, что управление коммуникациями — ответственность руководителя проектов.
Хм. Ну да. Но тут личный опыт сказывается. Я в низкобюджетных, до 3 млн рублей, проектах преимущественно участвую, тут кроме менеджера проектов есть только и исключительно разработчики.
Поэтому ПМ аккумулирует в себе роли аналитика, технического писателя и прототипировщика.
silent_jeronimo
Да, это его функция. Он среди прочего обеспечивает коммуникацию между стейкхолдерами и разработчиками, и чем меньше искажений в ходе коммуникации, тем, в частности, лучше ПМ. Также он с одной стороны управляет ожиданиями заказчика, а с другой стороны требованиями к проекту, и это тоже про перевод.