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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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