эм... как разработчику можно вменить в ответственность некачественный код, так и конечному руководителю - проблемы в ходе разработки.
мне кажется несколько неэтично руководителю говорить о том, что исполнители недостаточно талантливы или боятся брать на себя ответственность. тем самым он как бы поднимает руки и признает что не может решить свои задачи.
мне кажется это вообще характерная проблема для многих организаций, попытка использовать исполнителей в рабочем процессе, как некие функциональные модули. с людьми надо говорить и говорить часто.
только когда каждый исполнитель увидит что его работу ценят и она значима, он начнет брать на себя ответственность.
ну это просто замечание по теме. не применительно к твоему примеру конечно.
Социология проекта не всегда позволяет полагаться на ответственность отдельных участников.
Можно схему задач применить в качестве инструмента минимизации этих проблем. Ответственность конкретного исполнителя за конкретную задачу и самостоятельность в рамках задачи, постановщика соответственно за исходные данные и прием результата.
А не предполагается, что новые сервисы тоже предварительно проектируются хотя бы в минимальном объеме?
Без разницы через три месяца после запуска или через 3 года. Если речь, конечно, о проектах с долгим жизненным циклом. В таком случае, чем дешевле и быстрее прикручен новый сервис, тем дороже будет поддержка и последующее наращивание.
А вообще для такого спора нужно хоть какие-то данные о проекте привести (это я о посте щас). Рассматривать проблему качества разработки в целом просто смысла не имеет. Юрий бы хоть примерно осведомил общественность о масштабах и условиях чтоли. А то это все круто про слабости ума и прочее, чувствуется наболело у человека, но однако как-то голословно.
Подходы к построению работы и внутрикомандных взаимодействий сильно отличаются в зависимости от параметров проекта. Где-то выгоднее проявить гибкость, минимум правил и несколько ответственных профессионалов. Где-то без определенных затрат на проектирование проект будет слишком дорог в поддержке или вообще развалится на пол дороги. Довольно часто наблюдаю случаи, когда все завязано на ответственности грамотных людей, которой проектную документацию не заменишь. А в таком случае, нет человека - хана проекту.
ура консенсус
гибкости мышления всем нам
мне кажется несколько неэтично руководителю говорить о том, что исполнители недостаточно талантливы или боятся брать на себя ответственность. тем самым он как бы поднимает руки и признает что не может решить свои задачи.
мне кажется это вообще характерная проблема для многих организаций, попытка использовать исполнителей в рабочем процессе, как некие функциональные модули. с людьми надо говорить и говорить часто.
только когда каждый исполнитель увидит что его работу ценят и она значима, он начнет брать на себя ответственность.
ну это просто замечание по теме. не применительно к твоему примеру конечно.
Можно схему задач применить в качестве инструмента минимизации этих проблем. Ответственность конкретного исполнителя за конкретную задачу и самостоятельность в рамках задачи, постановщика соответственно за исходные данные и прием результата.
Без разницы через три месяца после запуска или через 3 года. Если речь, конечно, о проектах с долгим жизненным циклом. В таком случае, чем дешевле и быстрее прикручен новый сервис, тем дороже будет поддержка и последующее наращивание.
А вообще для такого спора нужно хоть какие-то данные о проекте привести (это я о посте щас). Рассматривать проблему качества разработки в целом просто смысла не имеет. Юрий бы хоть примерно осведомил общественность о масштабах и условиях чтоли. А то это все круто про слабости ума и прочее, чувствуется наболело у человека, но однако как-то голословно.
Подходы к построению работы и внутрикомандных взаимодействий сильно отличаются в зависимости от параметров проекта. Где-то выгоднее проявить гибкость, минимум правил и несколько ответственных профессионалов. Где-то без определенных затрат на проектирование проект будет слишком дорог в поддержке или вообще развалится на пол дороги. Довольно часто наблюдаю случаи, когда все завязано на ответственности грамотных людей, которой проектную документацию не заменишь. А в таком случае, нет человека - хана проекту.
классическое проталкивание своего мнения, говорите.
а вы что, простите, обычно чужие мнения пытаетесь "проталкивать"?