Есть специальности, враждебные по самой своей сути. Например, маркетолог и бухгалтер. Или нормировщик и рабочий. Или тестировщик и программист. Почему так бывает?
Начнем с признания. Отделы технического контроля есть дай бог на каждом сотом предприятии. Нужны немалые средства, политическая воля и длинный горизонт планирования, чтобы заниматься техническим долгом на уровне профилактики, а не по мере возникновения проблем. Большинство веб-студий не позволяют себе подобной роскоши, сначала по нехватке средств, а потом "экономии" ради.
Возьмем уровень повыше. Многомиллионные порталы, производители коробочного ПО, студии ТОП50 вынуждены бороться с "грязным" кодом, применяя контроль качества.
И чаще всего получают одни и те же ситуации:
1. Тестировщиков за найденные ошибки поощряют, программистов наказывают. Решение кажется очевидным, но на деле эта системная ошибка порождает непрекращающийся конфликт. В результате:
2. Тестировщики злобно радуются каждому найденному багу как источнику проблем программистов. Чаще всего "образ врага" инициирует и поддерживает старший по должности или "сроку службы" работник ОТК. Не со зла. Но представлять смежников бракоделами почему-то морально проще.
3. Программисты отрицают ошибки. Как говорится, "это не баг, это фича". Программист переносит критику ошибки на себя, любимого, обижается сам и обижает в ответ тестировщиков, доходя до публичный обвинений в неграмотности и некомпетентности.
Дальше - больше. Программисты перестают проверять код перед сдачей, пусть придиры "ловят блох". Тестировщики перестают контролировать тикеты ошибок, пусть бракоделы "исправляют свои косяки". А код становится все хуже и хуже.
Не делайте очевидные решения должностными инструкциями.
Назад в раздел
Начнем с признания. Отделы технического контроля есть дай бог на каждом сотом предприятии. Нужны немалые средства, политическая воля и длинный горизонт планирования, чтобы заниматься техническим долгом на уровне профилактики, а не по мере возникновения проблем. Большинство веб-студий не позволяют себе подобной роскоши, сначала по нехватке средств, а потом "экономии" ради.
Возьмем уровень повыше. Многомиллионные порталы, производители коробочного ПО, студии ТОП50 вынуждены бороться с "грязным" кодом, применяя контроль качества.
И чаще всего получают одни и те же ситуации:
1. Тестировщиков за найденные ошибки поощряют, программистов наказывают. Решение кажется очевидным, но на деле эта системная ошибка порождает непрекращающийся конфликт. В результате:
2. Тестировщики злобно радуются каждому найденному багу как источнику проблем программистов. Чаще всего "образ врага" инициирует и поддерживает старший по должности или "сроку службы" работник ОТК. Не со зла. Но представлять смежников бракоделами почему-то морально проще.
3. Программисты отрицают ошибки. Как говорится, "это не баг, это фича". Программист переносит критику ошибки на себя, любимого, обижается сам и обижает в ответ тестировщиков, доходя до публичный обвинений в неграмотности и некомпетентности.
Дальше - больше. Программисты перестают проверять код перед сдачей, пусть придиры "ловят блох". Тестировщики перестают контролировать тикеты ошибок, пусть бракоделы "исправляют свои косяки". А код становится все хуже и хуже.
Не делайте очевидные решения должностными инструкциями.
Назад в раздел
Подписаться на новые материалы раздела:
