Home

Оригинальная публикация

Всем привет! Меня зовут Фефилов Александр, я работаю в QA с 2017 года. По большей части это были компании, которые занимались аутсорсингом, но затем я присоединился к SM Lab.

Как вы уже поняли из названия поста, я расскажу о том, как взаимодействовать с заказчиком (а иногда и с заказчиками) с позиции QA-эксперта.

Под катом личный опыт работы в разных крупных компаниях и ответы на вопросы:

• как работать с двумя представителями заказчика в случае, когда их требования часто противоречат другу другу, а сами они между собой не общаются

• что делать, если ваш заказчик живёт в парадигме «Я плачу деньги, а ты просто делаешь всё, что я говорю»

• как решать процессные задачи

• как находить продуктовые проблемы

• кто такой QA-эксперт и как им стать

• полезная методика, которая может пригодиться вам в работе.

Итак, начнём по порядку.

В качестве вводной — когда я сталкивался по работе с заказчиками, я частенько попадал в ситуацию, когда заказчик сам, явно или не осознавая того, мешал процессам или качеству продукта. Когда я пытался донести это до него, то встречал неожиданное сопротивление — мол, куда ты лезешь, тут без тебя все всё прекрасно знают, и вообще этим делом занимаются лучшие умы. Иди-ка своей работой займись для разнообразия.

Так что приходилось действовать нестандартно и немного хитрить, предпринимая шаги, которые могли бы сподвигнуть заказчика к чему-то хорошему, пересмотреть процессы или что-то поменять. Для этого я выработал небольшой алгоритм. начну рассказ с тех моментов, которые и научили меня взаимодействию с заказчиками.

История первая, «Два босса»

Как-то я работал с одной американской компанией, МФО, дочкой большого американского банка, которая выдавала микрокредиты.

В какой-то момент вышло так, что два члена нашей русской команды синхронно ушли в отпуск, причём это были лид и один из тестировщиков. Я остался один, скоуп задач, висящих на мне, был небольшой, так что решили, что ОК, справлюсь. Со стороны заказчика со мной взаимодействовали два человека — QA-лид и ведущий тестировщик. 

И всё бы ничего, но эти ребята начали давать мне задания, которые не то чтобы сильно противоречили друг другу, но выходило так, что в одиночку их не решить — надо было тратить очень много времени, чтобы вообще понять, как уложить две такие задачи в единую канву. Конечно, я пошёл уточнять при первом такому случае, чью же задачу мне делать, если смысл расходится. И конечно, каждый из представителей отвечал, что делать надо именно его задачу. Что немножечко странно.

Я понял, что у ребят нарушена коммуникация и задался вопросом — как же это починить. Может, у них там ссора какая-то произошла, кто-то занял чью-то позицию, в общем — взаимодействия у них не было. Я сходил к куратору и поднял этот вопрос, куратор сказал, что будет разбираться и искать решение. Разбирательство и поиска решения затянулись, а мне-то всё это время приходилось работать в таких условиях. Задачи продолжают сыпаться, что с ними делать в таких условиях — не очень понятно, с какой начинать — тем более.

Плюс ещё тот фактор, что у нас была разница во времени 8 часов — когда у нас в России рабочий день заканчивался, у них он только начинался, и пересекались мы от силы часа на два.

Вот что я сделал.

Я создал общий чат на нас троих под названием «Собираюсь делать». Там я писал, какую именно задачу буду делать завтра. Если ответа не было — я считал это за молчаливое согласие и шёл делать ту задачу, что выбрал и о которой уведомил. Если молчаливого согласия не было, они в чате начинали между собой спорить, и им наконец-то приходилось нормально дискутировать. Понимаю, что выглядит это так, будто я хотел столкнуть их лбами, но с другой-то стороны, работать надо, на меня падают эти задачи и их надо делать.

Решение отчасти спорное — вроде как я скинул с себя бремя, но, возможно, в среде заказчика и членов его команды возникло напряжение.

История вторая, «Нам лучше знать»

Место действия — та же компания.

Я так работаю, что всегда во время тестирования стараюсь смотреть на бизнес-логику. И не просто на бизнес-логику — хочется понять, для чего это делается, как и почему именно так, а не иначе. Порой у меня появляются какие-то полезные предложения по делу, если какая-то часть процесса кажется мне нелогичной. 

Так был и тут. Я обнаружил, что по условиям договора агент, который оформлял микрокредиты, получал деньги за открытие счёта. Где тут логическая ошибка? Правильно — клиент может не начать пользоваться этими деньгами. А агент уже получил свою комиссию просто за открытие счёта.

С этим знанием я сходил на собрание, где были все большие шишки, отвечающие за проект. Сказал им, мол, ребята, как-то нелогично выходит. Мне ответили, что вообще всё ОК. Я в шутливой форме предложил им взять меня в качестве агента и объяснил, что будет — я приведу 1000 человек и открою каждому счёт. За 1000 открытых счетов я получу 2 000 000 долларов комиссионных. Никто из приведённых мною не воспользуется деньгами на счёте, деньги будут висеть, процесса зарабатывания нет. А у меня есть 2 миллиона и я с чистой совестью уезжаю в отпуск.

Там подумали. Ещё подумали. А потом решили всё же внести изменения в этот алгоритм. Лично я не получил никаких преференций для себя, но на рынке и в финтех-среде наша компания стала выглядеть более экспертной — потому что даже тестировщик у этих ребят знает, как строить бизнес. Ну и определённый рост в глазах заказчика и среди компания я тоже получил.

История третья, «Если я плачу деньги, вы делаете всё, что я скажу»

Пожалуй, самый жёсткий вариант на моей памяти. Мне пришлось полидить один проект, который хорошо прокачал меня как тестировщика.

Заказчиком была звукозаписывающая компания Warner Music Group. Мы делали приложение, которое было по сути маркетплейсом аудиозаписей. Суть в чём — человек мог набрать себе плейлисты из треков, авторские права на которые у WMG, например, куда-то себе для видео, для фильмов, для рекламы и прочего. Главное тут то, что песни обычно покупались пачками, не пара треков, а вот прям хорошим таким набором. 

Выглядело это так — выбираешь все нужные тебе композиции, через кнопку «Заказать» даёшь агенту знать, что ты хочешь сделать заказ. В зависимости от штата тебе высчитывают, сколько и кому ты должен заплатить (потому что отдельный платёж самой WMG, отдельно — налоги, для каждого штата разные, и много-много прочего). 

Я пришёл на этот проект на короткое время для усиления в первый раз, а потом во второй раз, когда два тестировщика проекта запросили ротацию и меня сразу сделали лидом проекта. Мне причём сразу сказали — «Тебе тут будет плохо, тут выгорают вообще на ура, угадай, где QA и веб-команда проекта? Да, они тоже». Да и проджект-менеджер ходил понурый. Я, естественно, спросил — а что не так?

Ответом была история про то, что заказчик постоянно меняет требования. Мол, он считает, что раз он платит деньги, то может делать всё, что захочет.

В общем, проблема. Как решать, как сделать так, чтобы заказчик перестал себя так вести? Подумал, сходил к куратору, спросил у него, не планируем ли мы сделать автоматизацию. Куратор ответил, что вообще в перспективе можно. Я соглашаюсь, пишу требования в стиле GWT, прихожу к заказчику. Говорю ему, что уже написал критерии приемки (acceptance criteria), прошу подтвердить, что всё ОК. И получаем диалог вида:

— А зачем мне это аппрувить?

— Если вы это зааппрувите, то в перспективе получите отличную почву для автоматизации, почти готовую. Вам останется только продлить контракт, чтобы от нашей компании выделили автоматизаторов, и всё. Поэтому вот вам отличные требования.

— Круто, давай попробуем! Мне нравится.

В общем, он всё заапрувил, хоть нам и пришлось кое-что пересмотреть, но головная боль была снята. И если что вдруг, любое изменение, любой каприз — ОК, идём и пересматривает сумму, сроки, ведь проект теперь фиксированный (Fixed Bid) и каждое движение оплачивается. Заказчик, понятное дело, стал вести себя уже поскромнее.

На этом же проекте я нашёл одну занятную форму. Пользователь, то есть агент этой компании, должен был заполнять поля — сумма, процент налога, дополнительные траты и прочие бюрократические изыски. После этого он нажимал кнопку Save. И только потом видел на экране калькуляцию всего этого добра. Я пошёл к разработчику форму и сказал ему, что это странно — зачем сначала вводить сумму, потом процент налога, потом ещё 10 пунктов, и в итоге я увижу то, что насчиталось, только после того, как это всё сохранится в базе? Разработчик ответил, что всё нормально и вообще так и задумывалось.

Но люди-то часто ошибаются. Одна маленькая опечатка на любом шаге этой монструозной формы — и полдня, потраченные на оформление, со свистом вылетают в трубу.

Разработчик приводит аргумент вида «Ну в требованиях-то не было такого». Я уточнил, сколько времени займёт всё исправить, он ответил, что около 4 часов. Договорились на том, что я уломаю PM на дополнительный выходной для разраба, если он это сделает.

Иду к PM, рассказываю ему всю эту историю, говорю, что в целом-то всё сделано по требованиям и вообще, но некрасиво и неудобно. PM уточняет у меня оценку трудозатрат, договариваемся на том, что сделаем это в качестве эксперимента (если что — откатимся), и что заказчику это в итоге должно понравиться.

Всё сделали, стало удобно и красиво, пошли с этим на недельное демо. И вот этот заказчик (тот самый вредный дядька, постоянно меняющий требования) хлопал нам в ладоши и всячески хвалил, потому что вышло лучше, чем он ожидал.

Я это всё вообще к чему — всегда надо смотреть на то, что можно улучшить и что можно исправить.

История четвёртая, In people we trust

Это была крупная медийная группа компаний из Великобритании, я работал на проекте, который занимался бухгалтерской аналитикой, а также прогнозированием затрат и доходов. Было очень интересно, потому что ранее я никогда не встречал настолько неторопливых проектов. Всё еле-еле — медленно катится само по себе, процессы не настроены, да ничего не настроено, документации нету, народ просто ходит и откровенно пинает балду. Один проект, например, только три месяца собирались начать делать.

Пока я там работал, всю документацию сам и написал. Потом пришёл аналитик и попросил взять её себе, чтобы переписать. Аналитик, ага. Было весело, в общем.

Но во что самое интересное. Бухгалтерские проекты — они всегда про деньги. И приложение-то само по себе было вполне ОК, оно всё считало, прогнозировало, в общем, жить можно.

Но там не была настроена валидация.

Что это значит для такого приложения? Например, можно было поставить агентскую комиссию 10%. А можно было 110%. А можно было -10%, и система бы всё приняла и считала бы это нормой, от которой стоит плясать дальше. То есть при 110% агент всегда получает больше комиссионных, чем он принёс прибыли компании. А при -10% агент ещё и должен оказывается при каждой сделке.

Круче всего, что такая же петрушка была с налогами. А налоги в западных странах это прям больно. За неправильную финансовую отчётность и неправильно оформленные налоговые отчисления можно выхватить срок больше, чем за убийство, например.

Само собой, я пошёл к оунеру и всё ему рассказал. Оунер ответил, что у них работают умные ребята, они опытные, всё знаю, да и вообще. Тогда я решил пообщаться с кем-то из финансового отдела. Был конец осени, там все уже начинали готовиться к Рождеству, и обычно неторопливый проект стал совсем неторопливым проектом, работать не хотел никто. Я нашёл одну тётеньку, наш аналог главбуха, если коротко, и рассказал ей всё по пунктам. Где чего как работает, где можно накосячить, а также к чему всё это может привести.

Тётенька моргнула и сказала, что больше она приложение без валидации принимать не будет. Вообще. Потому что это деньги, за которые она отвечает.

Таким образом я расписал 36 кейсов, из которых 34 признали критическими багами системы. И снова, как в одной из историй выше, репутация компании возросла.

И это снова к тому, что, занимаясь не только тем, чем должен, ты можешь увеличить и репутацию компании, и свою собственную.

Тут возникает логичный вопрос — а стоит ли вообще лезть в дела заказчика? Ведь он просто даёт мне какую-то задачу, я её делаю, отдаю ему, он оценивает и говорит, ОК или не очень.

Вопрос дискуссионный. Вроде бы ты делаешь свою работу, это уже хорошо. Прилетают задачки, ты их разбираешь, растёшь потихоньку. И ты вполне себе хороший технический специалист.

Но если просто хорошо делать свою работу и при этом не уметь доносить до заказчика важные вещи и аргументированную информацию, это не даст вам дорасти до QA-эксперта. Это важная штука, и о ней — отдельно в конце поста. А пока давайте про инструменты.

Как решить процессную задачу

Если честно, этот пример я подглядел у Константина Шереметьева. Хороший дядька, тренер, занимается психологией и прочими полезными для нашей работы вещами. Он разработал алгоритм, который лично для меня работает от и до.

Была у меня ситуация, когда я был джуном и не знал — кого слушать, почему всё так работает, чего делать-то? К кому бежать?

Я обычно пишу на бумаге «Было» и «Стало». Почему именно в прошедшем времени — это полезный психологический трюк, когда про проблему говоришь в прошедшем времени, то считаешь, что уже её решил. В итоге просто вспоминаешь шаги, которые для этого предпринимал.

Итак, написали «Было» и «Стало», оставили между ними место, начинает думать, что делать. В этой схеме я обычно думаю снизу вверх. Вот давайте на примере с двумя заказчиками.

Что я хотел? Наладить коммуникацию между заказчиками.

Как я могу это сделать? Создать чат на троих

Как заставить их разговаривать? Начать назначать задачи себе самому. Так им некуда деваться — или говорят и обсуждают эти задачи, или я сам делаю то, что решил

В общем, нарисовал такую схему, посидел около часа, запустил — всё сработало. Попробуйте, вдруг вам тоже пригодится при решении ваших задач.

Как находить продуктовые проблемы

Тут сложнее. Обычно я задаю себе примерно такие вопросы:

• Для чего это приложение?

• Кто им будет пользоваться?

• Какие ожидания у заказчика?

• Какие ожидания у пользователя?

• Что может пойти не так? (мой любимый) Что можно сделать тут такого, что логика нарушится? Вот как в истории с валидацией.

Разберём этот список на примере приложения Спортмастера.

Для чего это приложение?

Для предоставления и продажи товаров спортивного направления.

Кто им будет пользоваться?
Люди, ведущие активный образ жизни или предпочитающий спортивный стиль. Тут мы  с вами уже потихоньку начинаем понимать публику.

Какие ожидания у заказчика?
Раз это магазин, заказчику хочется высокую посещаемость и высокую конверсию этих посещений в покупки. Ну правда, мы же с вами работаем за деньги. И только потом, если денег достаточно, начинаем работать для души. Так что заказчик тут ждёт того, что он сможет заработать. 

Какие ожидания у пользователя?
Почему пользователь должен захотеть пользоваться именно этим приложением, а не каким-то другим? Тут надо понимать, что мне как обычному пользователю важны два фактора — прозрачность и надёжность.

Прозрачность — это чтобы всё было понятно, интуитивно и удобно. Чтобы я мог открыть приложение и быстро понять, как найти нужный товар, как положить его в корзину, как купить. А потом расплатиться и получить сам товар.

Надёжность — я должен знать, что ничего не отвалится, что мои введённые данные никуда не утекут, включая реквизиты карт.

Что может пойти не так?
Да многое. Допустим, вы набрали товаров и пошли их оформлять. А тут раз и половина товаров просто исчезла из корзины без всяких уведомлений. Или на складе их нету, о чём тоже не было никакой нотификашки, мол, простите, попозже привезём. 

Или вообще — сделали вы заказ, деньги сняли, а заказ не прошёл. Звоните в саппорт, а саппорт не видит такого заказу. Ну вот нету его. 

И подобные кейсы очень помогают понять, в какую сторону надо направить свои мысли. Тут же не только техническая часть — мы снова задаёмся вопросами, для чего это приложением, что можно улучшить, причём что для пользователя, что для заказчика. Как сделать это удобнее и финансово выгоднее.

В чём польза такого подхода

Когда вы рассматриваете задачу с разных сторон, вы находите точки, которые можно улучшить. Или непонятные точки — их можно обсудить с заказчиком. Ведь если мне как тестировщику что-то непонятно, скорее всего, пользователь там вообще не разберётся.

Если мы с вами что-то придумываем полезное и доносим до заказчика, это делает нас не просто QA-специалистами, а QA-экспертами.

Кто такой QA-эксперт

Человек, который предлагает улучшения приложения в целом, не только какой-то технической части, но и пользовательской — юзабилити, дополнительной защиты данных, и прочее.

Поэтому QA-эксперт должен всегда работать в команде с аналитиком и разработчиком. Найдя какой-то своё решение, всегда можно сходить к этим ребятам и спросить, как это реализовать. И когда у вас на руках оказывается готовое решение, с ним можно идти к заказчику.

Лично для меня в QA работа с технической частью не являлась самой сложной, ведь всегда можно что-то нагуглить или там сходить к более опытными коллегами. А вот в работе с заказчиками сложность есть. Если прийти к заказчику и что-то долго ему рассказывать, скорее всего, через пару минут он перестанет вас слушать. 

Поэтому я и назвал пост «Как выживать среди заказчиков» — потому что это самое сложное, донести до заказчиков полезность ваших предложений, объяснить их ценность, и доказать, почему к вам стоит прислушиваться. 

Это реально выживание — если есть какая-то проблема, которая вообще всем мешает, но заказчик её в упор не замечает, а только говорит, что всё нормально, все всегда так работали и вы так работайте.

Или вот у вас появилось уникальное предложение, вы придумали, как повысить конверсию. Заявляете эту инициативу, команда согласна всё реализовать (причём недорого), а заказчик получит прибыль или иные плюшки. Тогда надо идти к заказчику и всё это ему презентовать. а он возьмёт и скажет — чего пристал, отстань.

И чего делать?

Мой алгоритм

Я пришёл к такому способу решения подобных проблем.

Сядьте, возьмите листок бумаги и:

1. Сформулируйте проблему тезисно — что можно улучшить, поменять, починить?

2. Обязательно напишите, какие риски это несёт — что будет, если не исправить проблему. Можно немного напугать заказчика, иногда это полезно.

3. Опишите, какая ценность будет получена в ходе исправлений. Что это вам даст? Даст снижение рисков и повышение прибыли, например.

4. Когда заказчик уже достаточно заинтересован, опишите ваши варианты решения проблемы.

5. Посмотрите снова на всё глазами заказчика — почему ему стоит согласиться и платить за это?

6. Поправьте аргументы при необходимости, добавьте фактов, посоветуйтесь с более опытными коллегами.

Первые пять пунктов — это уже очень позитивный момент, с ними можно смело идти к команде и попробовать что-то запилить. Думаю, никто не откажется помочь, особенно, если у вас именно команда, а не просто группа людей, которые что-то вместе делают.

Вот вам пример.

Во время работы в Warner Music Group я заметил, что нельзя посмотреть итоговый расчёт, пока приложение не сохранит данные в БД. Вот как это выглядит в рамках моего алгоритма.

1. Проблема — нельзя увидеть итоговые суммы, пока не нажмёшь Save.

2. Риски — если пользователь системы опечатался и создал некорректный документ, то этот документ отправится заказчику (покупателю). Его отправят обратно на переделку. В итоге теряем время, деньги в кассу не поступают, а для бизнеса это критично.

3. Ценность — если мы сделаем расчёт сразу на фронте, то пользователь сразу заметит, где именно он опечатался. Допустим, он продаёт товара на $10 000, а налогов ему насчитали $150 000. Видимо, что-то не так, и стоит сразу пересмотреть цифры.

4. Что предлагается делать — просто делать это на фронте.

5. Глазами заказчика — всё не сильно долго и дорого, займёт потолком один рабочий день, но получится круто.

6. Аргументы — сотрудники не переделывают работу, могут оформить больше счетов, а значит, принести больше денег. И покупатели довольны, становятся лояльнее.

Ещё раз отмечу, что тут критично взаимодействовать с командой, приходить, говорить, предлагать. Это пригодится не только им, но и заказчику. А с вашей стороны внесение такого предложения будет выглядеть профессионально, заказчики такое ценят и чаще продлевают контракты. Так что не стесняйтесь выходить за рамки требований и мыслить шире, совместно, в рамках команды. 

Стремиться тут стоит к тому, чтобы получилось, как мне однажды сказали коллеги: «Тестировщик — этот тот человек, который склеивает все отделы вместе, и при этом всех достаёт».

Пару слов о ценности

Когда я только пришёл в SM Lab, я увидел тут формулировку «Мы создаём ценность». Думаю, это очень грамотный подход к работе. Потому в одной компании, где я работал, подход был вида «Мы эксперты в своей области». Ну ОК, заказчик подумает, эксперты это здорово, а мне-то с этого что? Мне приложение нужно, а не ваши эксперты.

Или вот лозунг «Мы создаём лучший продукт». А мне как заказчику, например, нужен не лучший, а тот, который можно уже запустить, чтобы он денег приносить стал, хоть MVP.

Или «Мы — команда профессионалов». Рад за вас. а где ваш проект приносящий деньги?

В общем, важно понимать, что ценность — это то, что нужно заказчику. И ему нужно предлагать что-то ещё. Например, он просит у вас просто MVP магазина. Предложите ему что-то улучшить, что-то, что повысит конверсию. То есть не просто магазин для заказа товаров, а магазин, где можно нормально зарегистрироваться, получать баллы, развивать программу лояльности, получать персональные скидки и прочее. Так заказчик поймёт, что вы предлагаете ценность. И решит, что вы — молодцы, потому что не просто пришли заработать на этом заказчике, но и помогаете заработать ему.

Да, можно делать идеальный продукт, с лучшими разработчиками, протестировать его лучшими тестировщиками, написать автотесты на каждый чих, развернуть его на самых высокопроизводительных серверах. Но если продукт никому не нужен, вся эта работа бессмысленна. 

Я начал с того, что учился «выживать». А потом понял, что любую проблему можно решить, если правильно её преподнести, сформулировав её ценность.

Обсудить в форуме