На мой взгляд, для ответа на этот вопрос нужно копнуть глубже. Природа человека в том, чтобы избегать опасности, вкусно есть и много спать, не затрачивая при этом лишних усилий. Многие разработчики пользуются тем, что менеджмент не понимает всех тонкостей их работы для того, чтобы избежать ответственности. Ответственности за свои обещания, оценку времени, баги. Причем часто это происходит неосознанно, в момент принятия решения или разговора с менеджером. Задайте себе вопрос и ответьте на него честно: что проще - списать ошибку на баг и взять еще месяц на доработку или повиниться и отдать половину зарплаты? А ещё всегда можно кивать на ТЗ, которое было недостаточно точным.
Есть еще один путь, довольно сложный, но эффективный. Как говорил маэстро Куклачев - не надо заставлять ходить кота на задних лапах, надо искать кота, который любит ходить на задних лапах и поощрять. Айтишники - они же тоже котики - на рутинные задачи нельзя сажать человека с шилом в жопе и наоборот.
"Айтишники - они же тоже котики" никогда не видела сравнение милее)
Все логично. Только тут трабл - нужен хр, который умеет искать соответствующих людей. И желание компании давать зп по рынку. Эти два компонента редко встречаются вместе, а чаще полностью отсутствуют.
Как и в любой сфере нашей жизни, нельзя уповать на что-то одно. Хорошая система никогда не будет работать с неподходящими исполнителями, а с хорошими будет работать еще лучше.
Но и хорошие исполнители, как показывает практика, не роботы и если не выстроить четкие правила то могут быть конфликты и перекосы.
Комментарий недоступен
Почитайте про команду программеров "Бурана".
Ну я бы поспорил с тезисом про советских инженеров, бо я сам из такой семьи, и прекрасно знаю, как работали познесоветские НИИ (большинство их): без сроков, без ответственности, без денег.
В остальном, данная задача всегда решается таймтрекингом в тоже же джире.
Если разраб сам хронически не попадает в свои сроки, там это видно.
Для проверки качества есть КУА. Если разработчик косячит, нормальное куа это видит. Есди это доходит до потребителя - это плохое, негодное куа.
Ну и еще тезисну, что на моем опыте на плохое тз разработчики ссылаются, как правило, когда оно и правда плохое :)
Тз все таки должно быть хорошим, чтобы оценки были точными, а не +-50%
Но дальше мы попадаем на вопрос, а до какой степени должно детализироваться тз? :)