Как раз пропущенный раздел «Решения» и было бы интересно почитать.
Исходил из того, что в формулировке проблемы есть часть решения. В то же время, конкретные проектные решения могут быть очень разные. Поэтому, этот шаг за читателем.
Прекрасно продаётся — вполне да. Прекрасно живёт — под вопросом, по крайней мере с одной из сторон — это боль разработчиков, которая часто выливается в дальнейшую деградацию кода. Ещё, для HR отдела текучесть персонала, например.
Существует достаточно большое количество нишь продуктов, которые основной доход получают за счёт техподдержки и развития фич. Например, работающие на гос структуры, софт, который постоянно используется долгое время отдельными компаниями. Такой продукт может жить по десятку лет, порой меняя, во время своей жизни, ряд технологий. Очень важно, не потерять за весь этот период клиентов.
Сколь-нибудь существенно не коррелирует (...) Качество кода существенно коррелирует со стоимостью сопровождения системы
А через такие параметры, как скорость внедрения новых фич/период выпуска обновлений/возможностью пользователям получать тех поддержку? Если рассматривать весь жизненный цикл. В том числе, «любимый» legacy.
Я расцениваю это так, что 3 работодателя оплатили навязанную и бесполезную для них работу. 4-й выиграл в лотерею, но в долгосрочной перспективе может потерять больше, т.к. будет оплачивать другую навязанную и бесполезную для него работу.
На основании каких наблюдений/фактов вы делаете такие выводы?
но в долгосрочной перспективе может потерять больше, т.к. будет оплачивать другую навязанную и бесполезную для него работу.
Вы считаете, что наказания менеджеров за неуспех, (но старания — в habr.com/en/post/535114/#comment_22469234 использовалось слово корпел) разработчика оказались неэффективны и он все также будет стремиться использовать «машинное время работадателя» для своих целей?
Менеджмент не эффективен?
Вы не верите в успешность работников, которые старательно работают?
И тот и другой подход — это грань красоты/изящества кодирования?
1) Реализовать функциональность в рамках минимального бюджета. Определить минимальный функционал. Здесь, как выше упомянули в комментарии, профессионализм это, например, возможность обзора архитектур и знание многих библиотек, чтобы знать что можно использовать с минимальными затратами и где не возникнет большого технического долга на малом интервале разработки.
2) Найти эффективное/иновационное решений?
Если технический специалист разработчик? Может ли PM до деталей понимать задачу?
Почему ПМ не защищает разрабов?
Извините, на какой фрагмент комментария habr.com/en/post/535114/#comment_22468212 вы задаете вопрос? Я не понимаю цепочку диалога. Поясните, пожалуйста, на какой фрагмент вы задаете данный вопрос и почему.
Исходил из того, что в формулировке проблемы есть часть решения. В то же время, конкретные проектные решения могут быть очень разные. Поэтому, этот шаг за читателем.
Да, в том числе, проблема: наблюдаемость процесса разработки. Вы правы.
Спасибо за идею
Вы оскорбляете разработчиков фразами?:
Это газлайтинг?
Извините, это не оскорбление?
Извините, это не оскорбление?
Вы тролль?
Формирование диалога
Прекрасно продаётся — вполне да. Прекрасно живёт — под вопросом, по крайней мере с одной из сторон — это боль разработчиков, которая часто выливается в дальнейшую деградацию кода. Ещё, для HR отдела текучесть персонала, например.
Существует достаточно большое количество нишь продуктов, которые основной доход получают за счёт техподдержки и развития фич. Например, работающие на гос структуры, софт, который постоянно используется долгое время отдельными компаниями. Такой продукт может жить по десятку лет, порой меняя, во время своей жизни, ряд технологий. Очень важно, не потерять за весь этот период клиентов.
Не принесло для бизнеса сейчас? Не принесло в эти 2 недели?
Пример: фундоментальные исследования.
А фактор целеустремленная работа сотрудника? Небезразличие? ROI?
Но работал и с legacy, например.
А через такие параметры, как скорость внедрения новых фич/период выпуска обновлений/возможностью пользователям получать тех поддержку? Если рассматривать весь жизненный цикл. В том числе, «любимый» legacy.
На основании каких наблюдений/фактов вы делаете такие выводы?
Вы считаете, что наказания менеджеров за неуспех, (но старания — в habr.com/en/post/535114/#comment_22469234 использовалось слово корпел) разработчика оказались неэффективны и он все также будет стремиться использовать «машинное время работадателя» для своих целей?
Менеджмент не эффективен?
Вы не верите в успешность работников, которые старательно работают?
1) Реализовать функциональность в рамках минимального бюджета. Определить минимальный функционал. Здесь, как выше упомянули в комментарии, профессионализм это, например, возможность обзора архитектур и знание многих библиотек, чтобы знать что можно использовать с минимальными затратами и где не возникнет большого технического долга на малом интервале разработки.
2) Найти эффективное/иновационное решений?
Если технический специалист разработчик? Может ли PM до деталей понимать задачу?
Извините, на какой фрагмент комментария habr.com/en/post/535114/#comment_22468212 вы задаете вопрос? Я не понимаю цепочку диалога. Поясните, пожалуйста, на какой фрагмент вы задаете данный вопрос и почему.
Поясните, пожалуйста, вашу позицию.
Как вы будете вести диалог в рамках agile процесса?
habr.com/en/post/535114/#comment_22469272
Ваши слова ошибочны?