Кажется, что принципы гибких подходов давно стали нашей действительностью. Мы признаем их значимость и стремимся сократить потери ресурсов на всех этапах. Однако на практике, даже в такой казалось бы прогрессивной отрасли как ИТ, многое устроено по старинке. Расскажу историю, как я увидела проблему в своей компании, и как мы ее устранили с помощью принципа «Три Амиго».

Привет, уважаемые Хабровчане. Я — Алена Зорина, профдеформированный тестировщик и руководитель отдела обеспечения качества SSP. Предлагаю обсудить инструменты, которые помогают выстроить адекватную коммуникацию в команде, и при чем здесь тестировщики.


Когда в товарищах согласья нет

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

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

В итоге они договаривались, а потом шли и делали разные вещи. Аналитик в недоумении, потому что он же русским языком объяснил! Разработчик разводит руками: вот так же договорились.

К слову, процесс шел, и все было в общем‑то неплохо. Однако, при полном взаимопонимании получилось бы быстрее и приятнее для всех.

Представляете, люди два месяца не видели нестыковку, которую можно заметить уже после 10 минут обсуждения. Взгляд со стороны творит чудеса.

В этом и состоит принцип «Трех Амиго»: втроем договориться проще, быстрее и результат получается лучше.

Оптимальный состав

Нужен третий? Отлично! Давайте посмотрим, какова его роль, и кто им может быть.
Есть такая штука, как разность контекста. Для объективной картины их должно быть несколько, только так получается избежать перекосов. «Три Амиго» работает именно потому, что эти три собеседника разные, с разным бэкграундом, взглядом и зоной ответственности.
Почему же я считаю, что к аналитику и разработчику как можно раньше должен присоединиться именно тестировщик?

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

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

  • Работа тестировщика — проверка на соответствие требованиям. То же единство глоссария, как в ситуации, которую я привела в начале, объект нашего внимания в любом проекте. Отсюда и берется третий и очень нужный контекст;

  • Достаточно спорная причина, но все же. Мое глубокое убеждение, что разработчики и аналитики мыслят в разных плоскостях. Аналитик настроен сделать по максимуму, предугадать все чаяния и надежды заказчика, максимально докрутить и усовершенствовать. Отсюда очень часто бывают лишние требования, фичи и задачи. Даже те, о которых клиент не подозревает и которые ему возможно вообще никогда не понадобятся.

    Разработчик же намерен сделать только то, что действительно необходимо. Не тратить драгоценное время на какие‑то абстракции и изыски. Быстро и четко.
    С такими подходами им бывает очень сложно договориться. И в этом месте тестировщик может стать неким непристрастным судьей. Он по долгу службы и нашим, и вашим. С одной стороны, он член команды и заинтересован в том, чтобы сделать работу максимально быстро. С другой, смотрит на проект с точки зрения требований заказчика. Он не даст навертеть лишнего и убрать нужное. По крайней мере, в моей команде точно.

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

Как мы выстроили этот процесс в SSP?

Сначала я прощупала почву и поняла, что коллеги в принципе не против видеть меня в качестве третьего.

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

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

Какая польза? Мы меньше времени тратим на обсуждение и быстрее находим решение, которое всех устраивает. Отличный результат для такого маленького изменения в процессе.
Может показаться, что я вся такая молодец, умею общаться с людьми, и поэтому у меня круто получается быть третьей. А вот и нет. Практика показывает, что схема работает даже когда от моего отдела приходит другой человек. Главное, чтобы не боялся говорить и отстаивать свое мнение. Иначе отдуваться придется всем.

Неожиданно про кадры

Следуя логике того, что тестировщики должны уметь коммуницировать с коллегами, я иначе посмотрела еще на один процесс: работу с персоналом.

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

Поэтому я решила работать над soft skills тестировщиков сразу с нескольких сторон. Во-первых, я замечаю ребят, которые хотят развивать навык коммуникации, и отправляю их на встречи на троих. Равномерно прокачиваю скиллы в отделе.

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

Ну и, в-третьих, собственным примером показываю как надо. Показываю, что так вообще можно: подойти к коллеге на корпоративе и обсудить какие-то моменты. Или высказать свое видение на митинге.

Итак, друзья, вывод из моих слов каждый сделает сам в меру своего опыта. Но я все-таки хочу подытожить. Мало начитаться умных статей о том, как теперь принято работать в прогрессивных компаниях. Нужно начинать с себя. Пробовать самому. И при любом удобном случае прокачивать soft skills.

Комментарии (3)


  1. Dezrhog
    00.00.0000 00:00

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

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

    Речь не обязательно о конкретно троице разраб-тестировщик-аналитик. Как я уже писал выше: если команде для решения проблемы достаточно меня и одного другого члена команды, тогда все остальные люди на встрече - лишние. Кто бы что не говорил, но когда кого-то зовут на встречу просто из соображения "вдруг будет другое мнение", то этот человек скорее всего будет в пол уха слушать, а на деле заниматься более важными для себя задачами.

    Не дам пример правильного решения, потому что правильного не знаю, но приведённое в статье "решение" никак не решает настоящую проблему.


  1. Korinsky
    00.00.0000 00:00

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

    Но с точки зрения качества разработки проблему "синхронизации картинки" внутри команды лучше решать через этап согласования документа (ТЗ, бизнес-постановка, техническое решение - у всех по разному).

    Мы работаем в Редмайн, у каждой крупной фичи есть задача "Проектирование". Когда аналитик заканчивает создание ТЗ, переводит задачу в статус "Согласование". Тестировщик проверяет документ на соответствие базовым требованиям (полнота, непротиворечивость, однозначность, тестируемость и прочее). При необходимости общается с разработкой, архитектором и может вернуть аналитику на доработку. Перед сменой статуса Проектирования с "Согласование" на "Решено" тестировщик должен выставить в задаче "ожидаемое время выполнения" и перечислить основные запланированные проверки.

    Если аналитик и тестировщик хорошо сделают свою работу по созданию/приёмке ТЗ - шансы что у команды "картинки разойдутся" - минимальны.


  1. cool102ru
    00.00.0000 00:00

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