Всем привет, я Саша, инженер по тестированию ПО в Directum. Неотъемлемая часть моей работы — поиск слабых мест, недочетов системы. Фокус на недостатках оставляет отпечаток на образе мысли, взгляде. Работа требует внимания к деталям, определенного перфекционизма.
Наша айтишная реальность меняется и эволюционирует. Каждый день мы улучшаем не только процессы заказчиков, но и психологическую атмосферу в коллективе. Однако, несмотря на все блага, у этого процесса есть обратная сторона: стереотипы и ярлыки, один из которых — токсичность.
По образованию я химик, поэтому мне было очень интересно разобраться в природе психологической токсичности. Я изучил, порассуждал и написал для вас эту статью. Здесь на примерах из собственного опыта расскажу о случаях, когда тестировщику нельзя быть НЕ токсичным, а когда лучше поумерить свой пыл.
Давайте для начала определимся с терминами. Вот что нам говорит быстрый обзор от ИИ.
В психологии токсичность — это набор поведенческих моделей и эмоций, которые оказывают негативное, «отравляющее» воздействие на окружающих, вызывая стресс, дискомфорт и истощение. Чаще всего этот термин используется не в академической, а в популярной психологии для описания «токсичного человека» или отношений. Признаками токсичности считаются критика, манипуляция, обесценивание достижений, игнорирование личных границ, постоянные жалобы и эгоцентризм.
Критика может быть и мощным драйвером, и неприятной помехой для членов команды. Поэтому хочу провести грань между «деструктивной» и «полезной» токсичностью. Деструктивной токсичностью я буду считать то, что забирает силы и время у проекта и не приносит никакого результата. Полезной — то, что заставляет пройти команду/проект/человека через конфликт к принятию какого-то недостатка продукта/процесса/даже себя.
Ниже гипертрофированные примеры.
Тестировщик Х тратит на развертывание окружения 16 часов и каждый новый релиз стонет, что это никуда не годится. Сделать с этим ничего не может, поэтому идет к менеджеру проекта и просит создать инсталлятор, который сократит прописывание переменных в пятнадцати конфигурационных файлах сервисов до минимума. В идеале прикладывает экономическое обоснование. Это полезно? Полезно для всех: как для стейкхолдеров, так и для коллег — обычных тестировщиков, которые тоже тратят 16 часов в каждую версию для развертывания.
Тестировщик У каждую летучку ноет, что продукт плохой. Правда, не может рассказать, что конкретно не так. Это плохо. Это не только раздражает стейкхолдеров и коллег, но и может ударить по имиджу компании и продукта. Ведь если наш уважаемый У носит с собой эту идею на летучки, то и под кружкой-другой слабого раствора спирта в воде с добавлением органики и углексилоты он может разразиться тирадами о том, какой плохой тимлид, владелец продукта, продукт, компания и все-все-все.
А напиток-то он потребляет с кем-то из смежной сферы, вследствие чего совершенно случайно компания может нести неожиданные репутационные потери. Казалось бы, причем тут слабый рост зарплаты на перфоманс-ревью? А все просто, инфляцию работодатель покрывает, а вот рост не виден. Как говорится, «критикуешь — предлагай». Да и с таким тестером просто работать не очень хочется.
Кто себя относит к Х, кто к У, а кто действует альтернативно, как Й? Пишите в комментариях.
Что нами движет?
Давайте прослезимся, примем реальность и совершим экскурс в недалекое прошлое. Во времена, когда о токсичности почти не зарекались.
На дворе 2021 год. Ковид закончился. Из каждого утюга реклама онлайн-курсов по тестированию. На рынке кадровый голод. ИИ — больше шутка, чем реальный помощник. Именно в такое время мы начали создавать систему для КЭДО Directum HR Pro. Нашей целью было упрощение корпоративной жизни. Точнее, той ее части, которая меня лично сильно раздражала — переноса бумажек с одного места на другое.
ПО должно было поменять (и поменяло) будни всех в компании. До его создания я даже не представлял, что заявления не придется носить ногами в кабинет кадровику, а шаблоны не нужно будет искать в разных папках той же локации.
Мы делали решение для конкретных людей: простого Петровича и кадровика Джамили Фаизовны, той самой «ну распишитесь». Я точно понимал, что мы заняты важным и полезным делом. Перед глазами стояли заводские флешбэки: как сам носил документы между корпусами и слышал знакомое «Александр, почему не расписываемся?».
Я был одним из первых прикладных тестировщиков проекта. Имел богатый жизненный опыт, но абсолютно ничего не понимал в разработке. Мне было важно ничего не пропустить. Ни одного бага. Совсем вообще ни одного бага. НИ ЗА ЧТО! Был ли я чрезмерно дотошным? Определенно, да. Принесло ли это пользу продукту и моей репутации? Да. Но для меня сегодняшнего я тогда выгляжу токсиком.
Главное, что должен держать в голове любой начинающий тестировщик: он — последнее звено между потенциальными ошибками команды и конечным недовольным пользователем. Именно этот страх испортить чей-то опыт, а может и день, становится нашим профессиональным топливом.
Хочется, конечно, жить в мире розовых пони с единорогами и быть амбассадором продукта, продвигать легкий кадровый ЭДО в массы. Но на деле твоя задача другая: стать неудобным пользователем. Тем самым, что нажмет не туда, введет странные данные, поломает сценарий. Это необходимо, чтобы реальные юзеры потом не страдали от плохой автоматизации и не скатывались в луддитство с бумажками по кабинетам.
Со временем постоянный поиск несоответствий и жизнь в формате «ожидание — реальность» становятся привычкой. Начинаешь замечать мельчайшие недочёты буквально во всём. С точки зрения качества продукта — отлично. Если ты являешься катализатором качества, ищешь и находишь ошибочные векторы, особенно в момент появления идеи новой функциональности, даже ее проектирования — супер. Но если ты тратишь время на летучке на лексический разбор значения слова Statement и разъяснение причин, почему его некорректно использовать в контексте заявления на отпуск, то, дружочек-пирожочек, ты перешел грань.
А если вдобавок утверждаешь, что аналитик «творит фигню» и вообще некомпетентен, — самое время выпить активированного угля, съездить в Вавож на цифровой детокс и пересмотреть свое поведение. И больше так не делать. Н��когда.
Возмущаться или нет?
У каждого человека в команде может быть своя точка зрения, отличная от других. И у всех есть причины ее придерживаться. Например, ты можешь тысячу раз беситься, что кнопка «назад» тебя выбрасывает из приложения. Но директор продукта скажет, что фиксить ее прямо сейчас слишком дорого, в приоритете другие векторы развития. И будет по-своему прав.
Тут хочется обвинить автора в биполярке и спросить, «а что же делать, если тебя не слышат и хотят оставить в продукте какой-то крит?»
Ох, мой сахарин, все просто: если годами твои замечания игнорируют, значит, ты или не можешь донести мысль, или доносишь ее не тому. Твоим лучшим другом должен стать продукт, а ты ему — вакциной от багов, ну или на худой конец инсектицидом (средством против насекомых). Окей, тебя не слышат, не хотят дать порцию лекарства. Получается, надо подкатить к лечащему врачу и описать худшие последствия, которые произойдут, если пустить все на самотек.
Внимательный читатель скажет: как же так? Это что за прошлый век? Где вот эти вот все ваши CI/CD, left-shift, unit'ы и другие прелести. Дисахаридный мой читатель, отошлю тебя на пару абзацев назад. Мы начинали как стартап и не было никогда ни у кого 100% уверенности, что это вообще будет легально и востребовано. Конечно, сейчас мы обмазываемся этим вашим CI/CD и смотрим на зеленые галочки. В самом начале нам нужен был продукт. Здесь и сейчас. Завтра его просто могло не быть.
Итог
При работе тестировщиком токсичность и фокус на недостатках проникают в твою жизнь, мозг и нейронные связи. Но при этом в токсичности, как и во всем, должна быть мера. Нет необходимости выворачиваться ради доказательства того, что low-баг нужно править здесь и сейчас. Не нужно нарочно дестабилизировать команду. Но следует вовремя давать объективные, понятные данные для тех, кто может сделать что-то для улучшения вашего общего Продукта.
Да, на другой стороне всегда будут более объективные показатели, например время. Ты не можешь выиграть у времени, ты должен донести сквозь призму твоего негативного «токсичного» взгляда все худшие недостатки, которые ты не в силах принять в твоем Любимом Продукте.
Критикуй, но не оскорбляй. Объективно указывай на недостатки, а не ненавидь просто так. Предотвращай факапы, а не вини кого-то в них. Говори о несовершенстве, но слушай другую сторону. Помни: ты тоже человек и можешь ошибаться. И, пожалуйста, не переноси работу в повседневную жизнь.
