Мыслетрекер

Я часто слышу слова «процесс», «строить процесс», «улучшать процесс» и т.д.

А что это такое? Зачем это нужно? Как это делать?

Давайте разбирать поэтапно.

Что такое процесс?

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

• Форматы и шаблоны (документов, ошибок, задач и т.д.)
• Роли и ответственности (кто что делает)
• Последовательности и сроки
• Условия (это делается ЕСЛИ ***, а это — ПОСЛЕ ***)

Простой пример — планирование тестирования обновления: 

Тест-менеджер (РОЛЬ) создаёт таблицу (ФОРМАТ) в течение 1 дня (СРОКИ) после появления информации о релизе (УСЛОВИЕ). Если (УСЛОВИЕ) сроки разработки меняются, тест-менеджер (РОЛЬ) обновляет таблицу (ФОРМАТ) и отправляет письмо в заданном шаблоне (ФОРМАТ) руководителю проекта (РОЛЬ). В течение 1 дня (СРОКИ) РМ (РОЛЬ) отвечает по принятому решению.

Примерно в таком формате у каждого из нас есть в голове карта процессов в нашей компании. Какие-то вещи более формализованы (к примеру, точно известны роли и шаблоны), какие-то менее (к примеру, сроки могут быть не учтены, точные условия не обговорены, а обновлять тест-план может не только ТМ, но и любой участник команды). Вне зависимости от носителя информации по процессу (голова, вики, подписанный регламент), процесс есть всегда.

НО:

• Не всегда он одинаково понимается всеми участниками процесса.
• Не всегда он достаточно понятен кому-либо, и многие действия делаются больше по наитию, чем по процессу.

Зачем нужны процессы?

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

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

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

Но как? Как внедрять и проектировать процессы?

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

1. Анализ процесса

Чтобы понять, что улучшать, надо знать, что есть сейчас. Какого-то универсального процесса на всё тестирование сразу придумать невозможно, но можно смотреть по проблемным зонам и прорабатывать их. Какие у вас были проблемы? Давайте их анализировать, используя метод «Пяти «почему?»".

Мы не протестировали задачу, вошедшую в релиз. Почему? Потому что забыли про неё! Мы забыли про важную задачу. Почему? Потому что она нигде не была выписана. Почему она нигде не была выписана? Потому что у нас нет специализированного инструмента для мониторинга задач, и потому что РМ не всегда сообщает нам о поступлении новых задач.

Можно продолжать копать дальше, почему РМ не сообщает нам информацию, и почему нет инструмента, но на этом уровне уже можно работать с проблемой и искать её решение. НЕ ОДНОКРАТОЕ! Не про текущий пропуск — а на будущее.

2. Проектирование процесса

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

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

Правила хорошего брейншторминга — свобода в выражении идей и не меньше 30-40 разных решений. Те, которые сначала кажутся глупыми, могут сработать!

После этого мы уже продумываем процесс точнее. К примеру, мы решили, что во внедрении полноценного таск-трекинга нас никто не поддержит, и пока что мы будем просто выписывать все задачи релиза в табличку. РМа уговорили всё сообщать, формат и сроки обсудили, поддержкой команды заручились, процесс задокументировали, до всех его важность донесли.

Ура, работаем, всё классно!

3. Контроль процесса

РМ забыл написать письмо. Тестировщик забыл отметить статус тестирования. Тест-менеджер забыл сообщить об изменениях срока. И т.д. и т.п. — первое время проблемы будут ЧАСТО. Варианты решений:

• Забить! Видимо, процесс неподходящий и для нас слишком сложный
• Воспитывать дисциплину в себе и в команде, не допускать «разбитых окон»!

Первое время вы должны быть смотрителем процесса и хранителем дисциплины. Иначе — никак!

4. Контроль результата

Вот мы что-то внедрили, а как успехи? Мы правда стали реже что-то пропускать? Насколько много усилий у нас это отнимает? Не попадайтесь в ловушку «мне не хочется менять то, что я с таким трудом делал». Софт получается с первой попытки хорошим? Нет. Вот и процессы тоже не сразу идеальны.

К примеру, в какой-то момент мы опять столкнулись с проблемой пропуска. Почему? Повторяем шаги 1-3: где проблема? Допустим, оказалось, что есть задача, которую разработчик сделал не сообщив РМу, или РМ забыл нам что-то написать. После долгого брейнштормы мы решили внедрить новый этап в наш процесс: согласование плана. Мы отправляем его всей команде, и разработчики, аналитики, РМ смотрят, не была ли пропущена какая-либо из важных задач тестируемого релиза. Что дальше? Опять проверяем, тестируем, смотрим! Что работает, что нет, что можно улучшит.

Страхи

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

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

Что бы вы не внедрили, вы никогда не достигнете идеала. Поэтому, не бойтесь, этот фейл запрограммирован изначально. Но если вы и стремиться не будете, то полный ай-яй-яй гарантирован. В общем, лучше Лебедева уже не сказать: «Как мотивировать себя? Никак, оставайся в Ж!»…