Процессные игры. Игра в хаос

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

В чем заключается игра в хаос? Это когда вы не понимаете что происходит и с какой стороны ждать подвоха.
Пример 1:

  • Постановка задач. Собирается совещание по решению проблемы А. Все согласны, что надо что-то делать. Бурные дискуссии могут даже породить план действий. Ок. Но теперь самый главный человек на совещании говорит — «ну вот и ладненько, что делать понятно, всем спасибо за участие, приступаем»… И все расходятся. Через некоторое время оказывается, что ничего не сделано. Опять собирается совещание, начинаются разборки, и каждый говорит, что он думал, что кто-то другой сделает такой-то пункт плана. Тут все относительно просто решается — помимо того, что было изначально понятно ЧТО делать, надо было еще и обсудить КТО делает каждый пункт плана. А если завернуть ситуацию посложнее?
  • Посложнее так получается. Вышеописанная ситуация, еще через некоторое время собирается совещание, и оказывается, что проблема А все равно не решена. Главный человек на совещании начинает шипеть и покрываться пятнами. Как так? Уже определили ЧТО делаем и КТО делает, а результата нет. После дискуссий оказывается, что почти каждый пункт плана в отдельности готов. НО! Не было обсуждено кто, кому и когда передает результаты своего пункта плана, т.е. интеграция решения проблемы А не произошла. А также хорошо бы договариваться в каком виде передавать результаты работы. Согласитесь, что, например, акаунт менеджер с трудом поймет ворох технической информации от разработчика.

Пример 2:

  • Изменения. В самом тяжелом случае какие-либо процедуры обработки запросов на изменения отсутствуют. Но, буду надеяться, что не так все и плохо, и процедуры-таки есть, даже описано кто имеет право подавать запросы, а кто их обрабатывать. В чем может состоять хаос?
  • Пользователь заказчика тестирует очередную версию продукта, и после демо пишет одному из разработчиков, что проделана фантастическая работа, но надо бы поменять зеленый цвет на черный. Через некоторое время черный цвет появляется на очередном демо, где присутствует важный представитель заказчика. Люди, знающие о процедуре обработки изменений в шоке, представитель хмурит брови, все имеют бледный вид, никто не может понять откуда взялось черное. Что тут не так? Как минимум такие замечания: а — процедуру обработки изменений нужно доносить всем участникам проекта, и на стороне исполнителя, и на стороне заказчика; б — процедура должна всесторонне оценивать влияние изменения на всю цепочку его воплощения (требования, разработка, тестирование, документация пользователя, и т.п.), и в результате попасть в список задач всех действующих лиц
  • А вот еще про изменения. Продукт немного не успевает к важной для заказчика дате, например коференции. Заказчик говорит — «а давайте временно отменим половину процедур тестирования, будет быстрее». «Хорошо», говорите вы, и честно предупреждаете, что «возможны проблемы с качеством». Хорошо, да не очень. Потому, что отмена тестирования это тоже изменение, только теперь уже рабочих процессов. Какое может быть влияние в данном случае: а — переделки из-за невыявленных вовремя дефектов; б — репутационные потери; в — заказчик не захочет оплачивать ресурс, который должен был делать отмененную часть тестирования; г — в особо тяжелом случае еще и потребует с вас неустойку за плохое качество.

Зачем я пишу эти примеры? А чтобы вызвать осознание, что хаос это не самая лучшая форма работы, ни для компаний, ни для конкретного человека.

Tags: , ,

Comments are closed.