Фон
Я работаю в ИТ-консалтинговой компании около 200 человек. Как и во многих других компаниях, мы работаем над несколькими проектами, в сжатые сроки, с большим давлением, как со стороны внутренних менеджеров, так и со стороны клиентов и т. д.
На прошлой неделе коллега (B) другой команды разозлился во время звонка на человека из отдела тестирования/QA и сердито сказал: «Вам платят не за то, чтобы вы думали, а за то, чтобы проводить тесты». Суть дела заключалась в том, что главный тестировщик на проекте заваливал задачи Jira сотнями комментариев с предложениями типа «я так думаю», «я об этом думал», «предлагаю эту разработку» и т.д. много раз только слабо связанные с ошибкой. Из-за внутренней политики только после устранения всех комментариев ошибки могут быть закрыты, поэтому этот тестер взял в заложники и задержал уже отложенный проект.
В звонке участвовали: Б, другие члены команды разработки, менеджер проекта (и непосредственный руководитель Б), вышестоящий менеджер, тестировщик и часть его команды и непосредственный руководитель тестировщика: об этом предложении никто ничего не сказал.
Вопросы
Мы обсудили предложение между нами, и широко распространено мнение, что это приемлемое предложение при таких или подобных обстоятельствах, но предпочтительно ограничить его использование. Я также поговорил с некоторыми друзьями из разных отраслей / областей, которые вместо этого сказали, что все убеждены, что это предложение неприемлемо на рабочем месте. Тогда как друзья из IT в целом согласны с нашим выводом.
Является ли это приемлемым приговором при некоторых обстоятельствах? Это всегда неправильно на рабочем месте? Может ли это подвергнуть того, кто это говорит, каким-либо последствиям?
PS: никаких последствий на B для этого предложения, а также нежелательные комментарии со стороны тестировщика прекращены, и все ошибки закрыты (обычно непосредственно менеджером тестировщика)
обновление - 12.05
Большое спасибо всем, кто ответил на мой вопрос, я имел возможность прочитать много предложений и интересных точек зрения.
У меня также была короткая беседа с B вчера, и он объяснил, что непосредственный менеджер тестировщика прислал электронное письмо с извинениями за поведение тестировщика. Этот менеджер также занял место тестировщика в проекте, и теперь все ошибки закрыты, а продукт выпущен. В конце концов этот менеджер перевел (понизил?) тестировщика с должности руководителя группы тестирования/контроля качества на должность простого тестировщика интеграции в другом проекте.
Согласно вам и вашему опыту, является ли это приемлемым приговором при некоторых обстоятельствах? Это всегда неправильно на рабочем месте?
Когда кто-то говорит: «Вам платят не за то, чтобы вы думали, а за то, чтобы делать X», вы не должны воспринимать это буквально. В любом случае вам платят за то, чтобы вы хоть немного подумали, иначе вашу работу выполнял бы робот.
Обычно эта фраза используется, чтобы прекратить повторяющиеся непродуктивные аргументы и как указание начать работу.
По моему опыту, это глупое утверждение для кого-то. Это не означает, что подразумеваемая причина («слишком много споров, недостаточно работы») неверна, просто обычно есть лучшие способы выразить это.
В этом конкретном случае тестер явно неуместно вводил мнения в задачи Jira, а не тестировал и сообщал об ошибках, как ожидалось. Коллега из другой команды, сделавший такое заявление, тоже был неуместен.
Менеджмент должен помогать каждому понять свою роль и насколько личное мнение должно быть задействовано. Если бы я был QA-директором, я бы долго разговаривал и с тестировщиком, и с коллегой. Они должны работать для достижения одной цели, а не пассивно-агрессивно стрелять друг в друга.
Если вы работаете в IT, вам платят за то, чтобы вы думали.
Предложение, которое вы описываете, может быть самой неправильной вещью, которую я когда-либо слышал в своей карьере в области ИТ. Ни одному ИТ-персоналу никогда не платят за то, чтобы он думал, иначе их работа была бы автоматизирована.
Похоже, что реальная проблема заключается в том, что ваш коллега просто не использует нужные каналы для сообщения о возможных улучшениях, предпочитая размещать их в темах, связанных с отслеживанием ошибок, а не в темах с предложениями/улучшениями.
Некоторые возможные альтернативные предложения, которые вы могли бы использовать.
Есть много других предложений, которые можно использовать, чтобы донести свою точку зрения, не заставляя коллегу чувствовать себя неоцененным.
Это непродуктивный ответ по нескольким причинам:
Из-за этой вспышки возможно, что QA-специалист заметит что-то серьезное, что выходит за рамки его должностных обязанностей, и не сообщит об этом, и вся компания может пострадать.
Сотрудник Б прав в том, что специалист по обеспечению качества не выполняет свои должностные обязанности должным образом, и это влияет на других работников и на саму компанию. Сотрудник Б был неправ, говоря эту фразу. Они должны принести извинения, а затем должна быть какая-то встреча, чтобы уточнить, как следует вносить предложения и комментарии, чтобы убедиться, что проект продвигается вперед.
«Вам платят не за то, чтобы думать, а за то, чтобы делать Х» — всегда неправильно на рабочем месте?
Может быть, нет, но это всегда красный флаг. Где-то что-то может быть не так, и эту ошибку нужно устранять.
Если эта фраза время от времени «ускользает», возможно, это не конец света, но если она становится мантрой, «корабль», вероятно, тонет. Найдите более здоровый и сильный корабль.
Конечно, есть и другая сторона вопроса — обилие комментариев, их качество и что с ними делать профессионально.
Первое, что нужно сделать, это объективно проанализировать комментарии : действительно ли они полезны для улучшения процесса/тестирования/продукта?
Следующее, что нужно сделать, это проанализировать влияние и актуальность комментариев. На основании этого будет сделана расстановка приоритетов. После этого действия, полученные из комментариев, должны быть запланированы для реализации в проекте.
Итог: ИТ без размышлений — это путь к катастрофе . Рано или поздно. Так или иначе. Примеров в изобилии в бесчисленных печатных книгах и в Интернете.
«Вам платят не за то, чтобы вы думали, а за то, чтобы проводить тесты»
Такие комментарии всегда неприемлемы. Решение проблем, критическое мышление и синтез — вот причины, по которым организации нанимают людей — предполагать, что это неважный вклад коллеги, — бесправно и неуважительно.
Ваш коллега, возможно, пытался выразить разочарование или провести инструктаж, но этот конкретный комментарий не был продуктивным способом сделать это. Мне жаль, что вы столкнулись с этим.
Так говорить грубо, это очевидно. Лучше было бы сказать: «Вы не выполняете свою работу. То, что вы делаете, тратит впустую все время и стоит денег компании». (Это также было фактически неправильно. QA платят за то, чтобы они думали. Правильное мышление позволило бы избежать этих JIRA, которые тратят время и деньги впустую).
Но работа QA заключается в том, чтобы убедиться, что продукт имеет достаточное качество для продажи / доставки. Они будут создавать JIRA, если есть проблемы, которые разработчику необходимо исправить.
Если этот QA-сотрудник наводняет разработчиков предложениями, основанными исключительно на мнении, это контрпродуктивно. Разработчик не будет и абсолютно не должен вносить изменения из-за такого предложения. Это должно перейти к менеджеру по продукту, который должен решить, что нужно сделать, и создать задачи для внесения таких изменений или не создавать такие задачи.
Так что похоже, что этот QA сотрудник зря тратит время разработчика. Я ожидаю, что QA получит JIRA, если что-то не работает так, как должно работать. А иногда получить JIRA, когда что-то работает как задумано, но то, как это спроектировано, не годится. Я не ожидаю, что меня завалят сотнями JIRA, которые я все отвергну.
Так что может быть момент, когда трата чьего-то времени приведет к грубости. Как вы далее сказали, похоже, это сработало. Сотрудник QA не понял свою работу, не выполнил свою работу, с плохими последствиями (задержками) для компании, а хамство вызвало результат - причина хамства была устранена. Кто-то, я полагаю, объяснил ему его работу.
PS. Если специалист по обеспечению качества не только потратил время впустую, но и задержал весь проект, добавив комментарий «Я думаю, что эта кнопка должна быть зеленой, а не синей», после того, как ему неоднократно говорили не делать такого рода глупости, тогда ему говорили: «Вам не платят за то, чтобы вы думали». ” понятно.
Суть дела заключалась в том, что главный тестировщик на проекте заваливал задачи Jira сотнями комментариев с предложениями.
Лично я вижу, как это будет раздражать, если вам придется читать каждую строку, чтобы выяснить, есть ли ошибка. Кроме того, это будут крайне непродуктивные комментарии, если идея уже продана бизнесу, и бизнесу придется снова оценивать комментарии.
Я просто хотел бы отметить, что комментарии непродуктивны, поскольку идея уже продана, и бизнес хочет, чтобы это было сделано именно так. Я также хотел бы отметить, что написание сотен комментариев было бы контрпродуктивно, потому что трудно отличить настоящие ошибки от просто комментариев.
Я думаю, кричать, что ему не платят за то, что он думает, было бы непродуктивным, но вполне объяснимым порывом. Я хотел бы использовать эту возможность, чтобы выявить суть вопроса.
Держите каналы связи открытыми
Хороший QA-тестер будет глубоко погружаться в разрабатываемую вами систему и замечать вещи, которые им специально не было сказано искать. Они имеют опыт изучения программного обеспечения и могут внести ценный вклад. Вы действительно не хотите закрывать этот канал информации.
... Но держите их организованными
Однако в вашей компании есть процесс отслеживания ошибок (хорошо) с правилами, согласно которым ошибка не может быть закрыта до тех пор, пока не будут устранены все комментарии (хорошо), а тестер оставляет комментарии не по теме (плохо). Вам нужно направить тестировщика на то, чтобы он вносил свои данные в нужное, а не в неправильное место. В качестве сокращения вы можете начать использовать такой текст, как:
«Комментарий закрыт, не по теме. Пожалуйста, поднимите для этого отдельный вопрос в (соответствующем месте)».
Вы должны убедиться, что подходящее место действительно существует и работает. Если у вашего тестировщика нет подходящего места для сообщения «Я также заметил это», на что люди реагируют, значит, вы навлекли эту проблему на себя.
Интересно, ваш текущий процесс общения состоит только из того, что вы задаете конкретные вопросы (тестовые случаи)? Куда должен идти тестер, если у него есть что сообщить, о чем не спрашивали? Этот канал воспринимается всерьез? Помещение комментариев в отчеты об ошибках «необходимо рассмотреть все комментарии перед закрытием» может быть криком о помощи.
Объясните "не пойдет"
В обязанности QA не входит решать, какие функции добавить в продукт. Чтобы сделать успешный продукт, вы также должны решить, какие функции вы не будете использовать. Потому что они не нужны или недостаточно ценны, чтобы добавлять их в последний момент и рисковать истечением крайнего срока. Вы должны объяснить своему тестировщику, что, хотя вы цените предложения, это не означает, что вы на самом деле примете их все.
Сделайте разницу между вниманием к предложениям и принятием их. Если тестер предлагает функцию или улучшение, а вы решили не делать этого, подтвердите это, а не делайте вид, что вы даже не видели предложения.
Эта фраза приемлема только в том случае, если вы пытаетесь играть роль тирана и обычно используется плохим менеджером. Обычно это просто указывает на то, что человек, использующий его, либо не может справиться с аргументом, либо не может слушать других людей. Другая форма этой фразы — «потому что я так сказал». В вашем случае это звучит как простой способ отрезать другого человека. Не выбирая ни одну сторону в борьбе, но я вижу ее с обеих сторон (как QA или как разработчик, так как у меня есть опыт и в том, и в другом). Лично я в описанной вами ситуации обнаружил, что гораздо продуктивнее открывать отдельный тикет по каждому пункту: для QA открытие отдельного тикета позволяет убедиться, что поднятый вопрос будет рассмотрен. Как разработчик, я предпочитаю, чтобы заявка, над которой я сейчас работаю, не переросла в область расширения масштаба.
Тем не менее, есть несколько редких случаев, когда функция была реализована, работает как положено и на бумаге выглядит фантастически, в реальной жизни не имеет никакого смысла. Большинство из них, как правило, ловит хороший QA и самые жесткие, так как все старались, но результат либо нулевой, либо отрицательный. Я всегда слежу за любым намеком на такую обратную связь от QA и стараюсь вернуться к чертежной доске. Обычно такой отзыв выходит как не относящийся к делу комментарий в тикете. В таком случае я бы предпочел поговорить с человеком, предоставившим такую информацию, чтобы выяснить, так это или нет. Если разговоры с человеком, делающим такой комментарий, действительно заканчиваются таким случаем, то вы должны реагировать таким образом, иначе либо попросите человека создать тикет, либо создайте его для него.
По сути, когда вы доходите до точки, когда разговор может стать немного накаленным, более продуктивно сделать вдох, выдох и сказать что-то вроде «Мне нужно подумать об этом, и я отвечу в билете», восстановить свое спокойствие, напишите, и если вы уверены, что вы правы, напишите свои доводы в тикете, почему это сейчас неактуально/недействительно/не имеет значения. Однако это палка о двух концах, поскольку, если другой человек был прав, а вы нет, вы задокументировали это сейчас.
И имейте в виду, что все подобные вещи не следует рассматривать как разработчиков (dba против бэкенда против пользовательского интерфейса) против QA против клиента против кого бы то ни было. Отношения должны быть такими devs + QA + client + whoever = great product. Я был в среде с сильной «свободной для всех» средой, где я действовал в духе сотрудничества, а взамен обращался так же.
Тесты — это особый случай, когда речь идет об ИТ-работе. Особенно формальные, особенно регрессионные тесты.
Если тест предварительно задокументирован (что делается для тестирования), а результаты в конце сводятся к ПРОШЕЛ или НЕ ПРОШЕЛ, конечный результат все равно говорит: «X, Y, Z… было сделано, к результату… .".
Тестируемые X, Y, Z могут быть определены спецификацией контракта с заказчиком, изменение тестов может очень неудачно перераспределить ответственность, если всплывет дефект (или, в худшем случае, нанесет реальный ущерб), который БЫЛ бы обнаружен, если бы процедура тестирования была точно соблюдена. Оборотная сторона этой медали заключается в том, что если дефект не будет обнаружен в результате предписанных и согласованных испытаний, в зависимости от контракта, продукт все равно может быть продан и выставлен счет как соответствующий спецификации, а средний палец включен в качестве бонуса.
С более широкой точки зрения, работа (в соответствии со спецификацией) уже могла быть описана, предложена, рассчитана и ПРОДАНА. В то время как постфактум модификация может повысить эффективность (уже рассчитано!), она также повышает риск (уже рассчитано!).
Ниос