Как работать с качеством в командах, где нет тестировщиков?
Привет! Меня зовут Сергей, я в тестировании уже 11 лет и сейчас развиваю качество в компании QIWI. В этом посте я хочу рассказать вам, как сейчас выглядят наши продуктовые команды, куда подевалась роль тестировщика и поделиться некоторыми выводами.
Проблематика прошлого
Когда‑то у QIWI была довольно популярная структура. У нас были отделы разработки, аналитики, тестирования и прочее. Ребята из этих отделов объединялись в проектные команды и занимались проектом.
При этом одной из целей нашей компании — »Поставлять всё возрастающее количество качественных инкрементов, способствующих развитию приоритетных продуктов, не забывая при этом о людях в командах».
И в рамках этой цели у нас в фокусе всегда было две вещи:
Целеполагание. Это некоторые цели, которые мы хотим достигать и трансляция этих целей сотрудникам.
Самостоятельность команд, или по‑другому автономность. Важная штука, ведь мы хотим непрерывные поставки и никто не должен никого сбивать или заставлять ждать. Команда должна уметь отгружать готовый полезный код в любой момент. Никаких барьеров быть не должно.
Но целеполагание и автономность на самом деле являются разнонаправленными векторами. И, если развернуть их в декартову плоскость, получается следующая картинка
Низкая автономность и низкое целеполагание — это уровень «просто заткнись и делай». Никаких трансляций целей, чистая работа.
При высоком целеполагании и низкой автономности руководители уже начинают транслировать в команды наши цели и проблемы, при это указывая, как именно мы будем их решать.
При высокой автономности и высоком целеполагании руководитель фокусирует команду на задачах и проблемах, а команда уже сама решает, что и как будет делать, чтобы достичь результата.
Если автономность будет высокой, но целеполагание низким — это ситуация, когда каждый делает, что хочет.
К тому моменту мы поняли важную для себя мысль »Диалог и совместное движение очень важны для того, чтобы изменения происходили».
При этом мы очень хотели быть в третьем состоянии, но, к сожалению, мы постоянно двигались между вторым и четвёртым. Почему? С диалогами у нас все было хорошо. В крупных компаниях никогда не было проблем со встречами: ‑)
А вот с совместным движением у нас получалась следующая картина. У нас есть отделы, например, отдел тестирования, функция которого — поставлять своих специалистов в проектные команды. Ребята как будто на работу уходят в проектную команду, живут там по своим спринтам, общаются с коллегами по проекту, а иногда возвращаются «домой» в родной цех и обсуждают, что да как было сделано и как можно что‑то улучшить. Знакомая картина?
Получается, у этого сотрудника, с одной стороны, есть цели проектной команды, с другой стороны, у него как у сотрудника отдела тестирования есть цели отдела. У него могут быть свои личные цели. У каких‑то смежных отделов свои цели и прочее. В итоге рождается вот такое разнонаправленное множество векторов, и совместного движения не получалось. Это как на кораблях, которые идут на веслах. Если все одинаково гребут — корабль летит на полном ходу, но если каждый гребет, как хочет — корабль крутится на месте.
Получается, наша проблема как раз и состояла в том, что при текущей структуре с отделами, поставляющих специалистов в проектные команды, мы теряли по целеполаганию. С другой стороны, мы видели, что формирование таких проектных команд давало нам рост автономности, и не хотелось это терять.
Поэтому нашим решением было внедрить культуру продуктовой разработки. Мы трансформировали проектные команды в продуктовые (Product Team) с общим целеполаганием и крутой автономностью, сфокусированных при этом на высоком перфоминге.
Тут у нас вставал вопрос »Что делать с отделами в новых реалиях? Например, с отделом тестирования? ».
Продуктовая команда по scrum
Мы сделали самое простое решение. Просто закрыли отдел тестирования, а ребят оставили в продуктовых командах
