Спасибо за статью!
Данная классификация полезна, на мой взгляд, при поиске слабых мест в команде. Кого наградить, кого наказать.
За логические ошибки должен отвечать составитель ТЗ, а при отсутствии ТЗ — руководитель разработки, как допустивший разработку без ТЗ.
За технические — непосредственно программист.
За дизайнерские — дизайнер.
За ошибки соотношения (я бы их назвал ошибками интеграции) — системный архитектор, а при отсутствии такового — руководитель разработки, не наладивший взаимодействие между разными людьми.
За ошибки документации — составитель ТЗ или тех. писатель
За комбинированные ошибки — совокупность тех людей, которые их допустили. Например, за дизайнерско-техническую ошибку должны отвечать дизайнер и программист.
Остаются локализированные ошибки. В них виноваты третьесторонние разработчики, не обеспечившие одинаковые стандарты работы своего ПО
Послушаю, спасибо. Я согласен, что если в команде налажено взаимодействие, то бюрократии меньше, особенно если члены команды находятся рядом друг с другом, и можно прийти и лично поговорить. Но ситуации бывают разными, а жестокая бюрократия помогает в жестоких ситуациях :)
Тут еще имеет место забота о человеке, который занимается первичной сортировкой багов (пофиксить / отложить / не фиксить). Если баг с длинной историей переоткрытий, и каждый раз в него вставлялись новые скриншоты, аттачились новые логи и указывалась информация о той инсталляции, где он был найден, то найти нужные скриншоты в жире, например, это трата времени. А поскольку сортировкой багов занимается в основном начальство, оно требует повышенного к себе внимания и заботы. Свежий баг ему читать легче.
В простейшей ситуации это хорошо, баги не плодятся. Но если оригинальный баг был, к примеру, блокером (к примеру, кнопка добавления пользователя отсутствовала вообще), то после фикса он вполне может стать менее серьезным (критикал или мажор) — кнопка все-таки появилась, но не во всех местах. Получается, переоткрывать блокер некрасиво. Ну, можно снизить серьезность (severity) и потом переоткрыть, да, согласен.
Тут, на мой взгляд, когда находится баг в старом функционале, надо его написать в виде отдельного репорта. А при чьей-либо попытке задубликатить его на какую-то задачу нужно подходить к этому человеку, смотреть на него с укоризной и говорить неприятные слова.
Данная классификация полезна, на мой взгляд, при поиске слабых мест в команде. Кого наградить, кого наказать.
За логические ошибки должен отвечать составитель ТЗ, а при отсутствии ТЗ — руководитель разработки, как допустивший разработку без ТЗ.
За технические — непосредственно программист.
За дизайнерские — дизайнер.
За ошибки соотношения (я бы их назвал ошибками интеграции) — системный архитектор, а при отсутствии такового — руководитель разработки, не наладивший взаимодействие между разными людьми.
За ошибки документации — составитель ТЗ или тех. писатель
За комбинированные ошибки — совокупность тех людей, которые их допустили. Например, за дизайнерско-техническую ошибку должны отвечать дизайнер и программист.
Остаются локализированные ошибки. В них виноваты третьесторонние разработчики, не обеспечившие одинаковые стандарты работы своего ПО
Перефразируя Черчилля, можно сказать, что бюрократия — очень плохая система ведения дел, проблема в том, что все остальные — еще хуже.
Категорически согласен!