Ну так давай, расскажи, какие бывают роли, кто какие задачи решает, кто за что отвечает, кто с кем взаимодействует по каким вопросам? А то на практике - действительно каша у некоторых выходит.
Ну и заодно, опыт разработки масштабных проектов, состоящих из сотен компонентов, в нескольких поддерживаемых ветках продукта, возможно под различные платформы, чтобы имел место быть. В условиях недостатка ресурсов, сомнительного целеполагания и перекидывания эффективными менеджерами разработчиков с проекта на проект или с одной задачи на другую. В общем в условиях, когда автоматизация производства и повышение эффективности выходят на первый план, а "эффективные" менеджеры - даже не понимают способов и инструментов решения таких задач в силу того, что требования к качеству и надежности системы никто не отменял. Если просто давать людям больше работы - люди начнут делать ошибки на всех этапах разработки, так как думать будет некогда, внимательно напечатать код программ - тоже будет некогда. Другими инструментами, кроме как раскидать задачки по сотрудникам - манагер не умеет оперировать, а они есть.
Возможно манагер должен как-то взаимодействовать с архитектором, но при консолидации различных продуктов в подсистемы - такого архитектора консолидации может и не быть физический, либо его фактический уровень может оказаться недостаточным, чтобы консолидировать уже существующих архитекторов подсистем. Я не говорю, что это нормально - но такое встречается, и в такие времена фактический контроль по управлению проектом осуществляет не архитектор, а тот самый пресловутый менеджер.
Кто у вас рулит ветвлением проекта например, на основании каких критериев? Есть ли фазы в процессе разработки и снятие старых веток с поддержки или все ветки разрабатываются и поддерживаются параллельно? Кто оценивает увеличение нагрузки на разработчиков при ветвлении проекта и оценивает ли? Режете функционал или увеличиваете сроки, или как у Коперфильда - прогнозы всегда совпадают? Кто собственно делает прогнозы и почему?
Поясняю ещё раз, лично у меня нет проблем, с организацией производства любого уровня, но эти проблемы есть у других людей, в частности у руководства - которое обычно плохо разбирается в разработке ПО, потому что ни одной серьезной программы или системы в своей жизни - не написали.
По сути, речь идет конечно о внятной методологии разработки, но есть момент - методология работает, когда люди, которые занимают какие-то роли в разработке ПО - соответствуют этим ролям, то есть имеют соответствующие образование, способности и опыт - в большинстве случаев это не так и происходит дисбаланс теории и практики. Это не считая концептуальной лажи в самой методологии, если такая имеет место быть вообще и применяется.
Чтобы оценить профпригодность - нужно сперва определить должностные обязаности.
Что касается поддержки, обработка запросов заказчиков - тут всё понятно, чем может заниматься PM. Но меня интересует PM на разработке, а не на поддержке.
Фигня начинается тогда, когда разные кастомеры - хотят разного, тут уже думать надо - что и как делать. Ещё может быть ситуация, что кастомеров ещё нет, а продукт делать уже надо.
У нас для понять - уже завелись аналитики - отдельная тема для обсоса.
кто за что отвечает, кто с кем взаимодействует по каким вопросам?
А то на практике - действительно каша у некоторых выходит.
Ну и заодно, опыт разработки масштабных проектов, состоящих из
сотен компонентов, в нескольких поддерживаемых ветках продукта,
возможно под различные платформы, чтобы имел место быть. В условиях
недостатка ресурсов, сомнительного целеполагания и перекидывания
эффективными менеджерами разработчиков с проекта на проект или
с одной задачи на другую. В общем в условиях, когда автоматизация
производства и повышение эффективности выходят на первый план,
а "эффективные" менеджеры - даже не понимают способов и инструментов
решения таких задач в силу того, что требования к качеству и
надежности системы никто не отменял. Если просто давать людям
больше работы - люди начнут делать ошибки на всех этапах разработки,
так как думать будет некогда, внимательно напечатать код программ -
тоже будет некогда. Другими инструментами, кроме как раскидать
задачки по сотрудникам - манагер не умеет оперировать, а они есть.
Возможно манагер должен как-то взаимодействовать с архитектором,
но при консолидации различных продуктов в подсистемы - такого
архитектора консолидации может и не быть физический, либо его
фактический уровень может оказаться недостаточным, чтобы
консолидировать уже существующих архитекторов подсистем.
Я не говорю, что это нормально - но такое встречается, и
в такие времена фактический контроль по управлению проектом
осуществляет не архитектор, а тот самый пресловутый менеджер.
Кто у вас рулит ветвлением проекта например, на основании каких
критериев? Есть ли фазы в процессе разработки и снятие старых веток
с поддержки или все ветки разрабатываются и поддерживаются
параллельно? Кто оценивает увеличение нагрузки на разработчиков
при ветвлении проекта и оценивает ли? Режете функционал или увеличиваете
сроки, или как у Коперфильда - прогнозы всегда совпадают? Кто собственно
делает прогнозы и почему?
Поясняю ещё раз, лично у меня нет проблем, с организацией производства
любого уровня, но эти проблемы есть у других людей, в частности
у руководства - которое обычно плохо разбирается в разработке ПО,
потому что ни одной серьезной программы или системы в своей жизни -
не написали.
По сути, речь идет конечно о внятной методологии разработки, но есть
момент - методология работает, когда люди, которые занимают какие-то
роли в разработке ПО - соответствуют этим ролям, то есть имеют соответствующие образование, способности и опыт - в большинстве случаев
это не так и происходит дисбаланс теории и практики. Это не считая
концептуальной лажи в самой методологии, если такая имеет место быть
вообще и применяется.
Reply
Ты пишешь про профнепригодных сотрудников на роли PM.
Это не значит, что само понятие PM - плохое.
PM, конечно же, должен быть в теме. Не глубоко, но широко. И он должен быть в теме с обеих сторон - и разработчиков, и кастомеров.
Reply
Что касается поддержки, обработка запросов заказчиков - тут всё
понятно, чем может заниматься PM. Но меня интересует PM на разработке,
а не на поддержке.
Reply
Задача PM, грубо говоря - понять, что надо заделиверить, ну и обеспечить создание продукта.
Reply
У нас для понять - уже завелись аналитики - отдельная тема для обсоса.
Reply
Leave a comment