Comments 5
Что же вы предпримете?
Вернусь в начало и еще раз представлю, что я принял руководство новой командой....
Очень странный вопрос в начале. Откуда мы узнали что команда сейчас непродуктивна, а плотность ошибок слишком высока? Может просто слишком много задач и проблема не в команде?
На моей практике два из трех случаев "плохой продуктивности команды" заключается в количестве задач, а не в самой продуктивности.
Ставку на технические решения мы делаем как раз потому, что контролировать другие аспекты работы зачастую не можем. Попробуйте директору объяснить, что вам надо отказаться от переработок чтобы повысить продуктивность, когда сроки уже завалены.
Соглашусь. Я бы сказал, что в моей практике самое важное средство повышения качества — это повышение квалификации исполнителей. Повышение во всех смыслах — технического уровня владения инструментом, софт скиллов, уровня понимания бизнеса. Как минимум, высокая квалификация позволяет повышать качество так, чтобы при этом сразу не страдали сроки (повышение стоимости все равно будет).
Но измерять это повышение мы не можем. Можно послать человека на курсы — но нельзя измерить, насколько он после курсов стал умнее.
Всё возможно измерить, если очень захочется. Вопрос только времени и денег.
Ну и показатели вы всегда получите - относительные. К примеру, берете типовую задачу с ограниченным контекстом, даете её своему разрабу и на аутсорс. Сравниваете результаты, сроки исполнения. Отправляете разраба на курсы, повторяете процесс. Так у вас будет объективная оценка конкретного разраба относительно конкретного аутсорса.
В идеале нужно проверить все комбинации, но конечно никто этим обычно не занимается. Было бы желание и возможности, как говорится.
Эпистемология качества программного обеспечения