Я часто слышу слова «процесс», «строить процесс», «улучшать процесс» и т.д.
А что это такое? Зачем это нужно? Как это делать?
Давайте разбирать поэтапно.
Что такое процесс?
Процесс — это согласованная последовательность действий, направленных на достижение какого-либо результата. Процесс включает в себя:
- Форматы и шаблоны (документов, ошибок, задач и т.д.)
- Роли и ответственности (кто что делает)
- Последовательности и сроки
- Условия (это делается ЕСЛИ ***, а это — ПОСЛЕ ***)
Простой пример — планирование тестирования обновления:
Тест-менеджер (РОЛЬ) создаёт таблицу (ФОРМАТ) в течение 1 дня (СРОКИ) после появления информации о релизе (УСЛОВИЕ). Если (УСЛОВИЕ) сроки разработки меняются, тест-менеджер (РОЛЬ) обновляет таблицу (ФОРМАТ) и отправляет письмо в заданном шаблоне (ФОРМАТ) руководителю проекта (РОЛЬ). В течение 1 дня (СРОКИ) РМ (РОЛЬ) отвечает по принятому решению.
Примерно в таком формате у каждого из нас есть в голове карта процессов в нашей компании. Какие-то вещи более формализованы (к примеру, точно известны роли и шаблоны), какие-то менее (к примеру, сроки могут быть не учтены, точные условия не обговорены, а обновлять тест-план может не только ТМ, но и любой участник команды). Вне зависимости от носителя информации по процессу (голова, вики, подписанный регламент), процесс есть всегда.
НО:
- Не всегда он одинаково понимается всеми участниками процесса.
- Не всегда он достаточно понятен кому-либо, и многие действия делаются больше по наитию, чем по процессу.
Зачем нужны процессы?
Анализируя свою работу, мы (если мы объективны к себе) регулярно замечаем какие-либо проблемы (например, мы забыли протестировать какую-то важную для релиза штуку). И, конечно, хотим их исправить (протестировать её экстренно сейчас и не допустить подобных пропусков в будущем). Как это можно сделать?
- Смотреть по обстоятельствам. Есть проблема — найдём решение, «не ошибаются только те, кто ничего не делает»
- Пожурить виновных. Почему вы это не проверили? Как вы могли! Ай-яй-яй, больше не пропускайте такое!
- Спроектировать процесс, решающий подобную проблему на будущее.
И, действительно, мы почти всегда можем сократить наступление на грабли до 1 раза: наступили — решили как больше не наступать — внедрили соответствующий процесс. Собственно, для этого они и нужны
Но как? Как внедрять и проектировать процессы?
Если кто-то когда-то скажет, что внедрять процессы просто — ударьте его в левый глаз. Процессы это вам не оперативное решение проблем «ой опять облажались, давайте поругаемся на виновных и всё быстренько решим». Процессы — это архитектура, искусство, анализ, логика и творчество в одном флаконе.
1. Анализ процесса
Чтобы понять, что улучшать, надо знать, что есть сейчас. Какого-то универсального процесса на всё тестирование сразу придумать невозможно, но можно смотреть по проблемным зонам и прорабатывать их. Какие у вас были проблемы? Давайте их анализировать, используя метод «Пяти «почему?»".
Мы не протестировали задачу, вошедшую в релиз. Почему? Потому что забыли про неё! Мы забыли про важную задачу. Почему? Потому что она нигде не была выписана. Почему она нигде не была выписана? Потому что у нас нет специализированного инструмента для мониторинга задач, и потому что РМ не всегда сообщает нам о поступлении новых задач.
Можно продолжать копать дальше, почему РМ не сообщает нам информацию, и почему нет инструмента, но на этом уровне уже можно работать с проблемой и искать её решение. НЕ ОДНОКРАТОЕ! Не про текущий пропуск — а на будущее.
2. Проектирование процесса
Мы хотим, чтобы вышеописанная проблема с пропуском важной фичи больше не пропускалась. Как это можно сделать? Первый шаг, как всегда при решении проблем, брейншорминг. Давайте соберём команду и придумаем все возможные идеи:
- внедрить нормальный таск-трекинг,
- выписывать задачи в таблицу,
- накормить РМа шоколадками и выпросить своевременно писать письма,
- поругаться на РМа высокоуровневому начальству чтоб его заставили нам всё сообщать
- и т.д.
Правила хорошего брейншторминга — свобода в выражении идей и не меньше 30-40 разных решений. Те, которые сначала кажутся глупыми, могут сработать!
После этого мы уже продумываем процесс точнее. К примеру, мы решили, что во внедрении полноценного таск-трекинга нас никто не поддержит, и пока что мы будем просто выписывать все задачи релиза в табличку. РМа уговорили всё сообщать, формат и сроки обсудили, поддержкой команды заручились, процесс задокументировали, до всех его важность донесли.
Ура, работаем, всё классно!
3. Контроль процесса
РМ забыл написать письмо. Тестировщик забыл отметить статус тестирования. Тест-менеджер забыл сообщить об изменениях срока. И т.д. и т.п. — первое время проблемы будут ЧАСТО. Варианты решений:
- Забить! Видимо, процесс неподходящий и для нас слишком сложный
- Воспитывать дисциплину в себе и в команде, не допускать «разбитых окон»!
Первое время вы должны быть смотрителем процесса и хранителем дисциплины. Иначе — никак!
4. Контроль результата
Вот мы что-то внедрили, а как успехи? Мы правда стали реже что-то пропускать? Насколько много усилий у нас это отнимает? Не попадайтесь в ловушку «мне не хочется менять то, что я с таким трудом делал». Софт получается с первой попытки хорошим? Нет. Вот и процессы тоже не сразу идеальны.
К примеру, в какой-то момент мы опять столкнулись с проблемой пропуска. Почему? Повторяем шаги 1-3: где проблема? Допустим, оказалось, что есть задача, которую разработчик сделал не сообщив РМу, или РМ забыл нам что-то написать. После долгого брейнштормы мы решили внедрить новый этап в наш процесс: согласование плана. Мы отправляем его всей команде, и разработчики, аналитики, РМ смотрят, не была ли пропущена какая-либо из важных задач тестируемого релиза. Что дальше? Опять проверяем, тестируем, смотрим! Что работает, что нет, что можно улучшит.
Страхи
Все мы чего-то боимся, и при внедрении процессов тоже. Что процесс будет слишком сложным, что разведём бюрократию, что не получится поддерживать, что не хватит дисциплины, что не придумаем чего-то достаточно хорошего, что невозможно будет всё сразу и быстро улучшить и т.д.
Вы можете продолжать бояться, сталкиваться с одними и теми же проблемами, искать им виноватых. А можете внедрить problem management: возникла любая малейшая проблема — ищем источник — находим решение в процессе, чтобы она больше не возникала — внедряем — мониторим, правда ли это помогло — корректируем.
Что бы вы не внедрили, вы никогда не достигнете идеала. Поэтому, не бойтесь, этот фейл запрограммирован изначально. Но если вы и стремиться не будете, то полный ай-яй-яй гарантирован. В общем, лучше Лебедева уже не сказать: «Как мотивировать себя? Никак, оставайся в Ж!»…
Pingback: 戦国ixa銅éŠ
Pingback: ラグナãƒã‚¯ã‚ªãƒ³ãƒ©ã‚¤ãƒ³ RMT
Pingback: TERA RMT
Pingback: çœŸãƒ»ä¸‰åœ‹ç„¡åŒ RMT
Pingback: Diablo 3 育æˆä»£è¡Œ
Pingback: WOT 育æˆä»£è¡Œ
Pingback: FF14 育æˆä»£è¡Œ