Вместо эпиграфа.
«- Ты что – глухонемой?
-Да»
к/ф «Бриллиантовая рука»
Попал я как-то в ДТП – один хороший человек так спешил домой к теще на блины, что не заметил перед собой мою машину. Приехал на станцию, там сделали «дефектовку», определили, что делать и срок ремонта – 3 недели. Конечно, хотелось быстрее, но мне объяснили, что СТО загружена, плюс пару деталей надо ждать, плюс технологический процесс: рихтовка, грунтовка, сушка, покраска, опять сушка. «Совсем как у нас в проектах, — подумал я, — проектирование, реализация, тестирование, исправление багов, приемочное тестирование заказчиком, опять исправление багов».
Спустя три недели, истосковавшись по своей «ласточке», в томительном ожидании приезжаю на СТО. И… И, как вы догадались, машина готова не была. Проект «Прокачусь с ветерком» стремительно закончился факапом. После долгих разбирательств выяснилось, что на СТО был переучет деталей, моих не было, их снова заказали. Но через неделю все будет готово: «Мамой клянус, дарагой», — убеждал меня сто-шник. К моему прискорбию, мама оказалась не в курсе клятвенных заверений сына. Не знаю, как там маме икалось и каково было состояние ее здоровья после еще трех недель обещаний, но спустя 7 недель машину я таки забрал. В процессе были мои звонки, переадресация то на одного, то на другого менеджера. Мои планы были уже сорваны, ряд поездок пришлось переносить на неопределенный срок. «Но мы вам брызговики поставили бесплатно», — глупо улыбался сто-шник, передавая мне ключи.
Все же, факт возврата машинки радовал несказанно, и в прекрасном настроении в тот же день я поехал к заказчику. Заказчик, весьма приятный в общении дяденька, увидев меня, почему-то изменился в лице: «Какого хрена вы ничего не делаете? Когда будут результаты? Мы работаем уже второй месяц, сдвигов по проекту нет! Менеджеры ваши непонятно куда пропали. Они на работу ходят или нет?». Машинка внезапно перестала радовать. «Как это нихрена не делаем?», — лихорадило в мозгу. «Вчера ж было совещание, смотрели систему, все ж по плану».
— Дорогой заказчик, у нас все хорошо, бОльшая часть функцонала уже готова, сайт размещен на тестовом сервере, можно смотреть в любое время. Да, у нас были вопросы по ряду функций, но с вашими сотрудниками мы их разобрали.
— Дорогой Максим, — снисходительно сказал заказчик, — это хорошо, что с моими сотрудниками вы все решили. Но Я об этом ничего не знаю. Я плачу за разработку! Мне мои сотрудники, в частности, наш финансовый директор, говорят, что есть проблемы. Вот представь: отдал ты машину в ремонт…
И дальше пошел пересказ моей истории: об обещанных сроках, о том, что их срывают, что нет никакой информации. «Поздравляю, Шарик, ты – балбес», — мысль эта забилась в стенках черепной коробки. «Теперь, Макс, сто-шником будешь ты. Добро пожаловать в ролевые игры».
Ту встречу мы все же закончили на мажорной ноте: я показал систему, заказчик вызывал своего аналитика, мы обсудили спорные вопросы и расстались с улыбками.
Собравшись в офисе командой, мы начали разбирать проблему. Первой выяснилась интересная деталь: общаясь с разными сотрудниками заказчика в разных информационных плоскостях, мы сами дали заказчику ложное представление о реальном состоянии проекта. Вопросы технической организации работ мы решали с системщиками и решались они сложно. Требования обсуждались с бизнес-пользователями, задачи обучения обсуждали с отделом, который находился в другом офисе. Не было единой политики обмена информацией. «Но у нас же есть Jira», — оправдывались ребята. «Там все статусы, все задачи». Но вопрос о том, знает ли заказчик о Jira и о том, что в ней есть, повис в воздухе. Заказчик был в информационном поле, а мы – в информационном окопе.
Вторым аспектом были помехи в коммуникациях. Проще говоря, мы выбрали не те средства связи и не тот способ предоставления информации. И самое главное – отправив информацию, мы не убедились, что она не только принята, но правильно понята: с нашей-то стороны пули вылетели. Позднее, описание проблемы мы нашли в полезной для ознакомления книге PMBOK (Руководство к своду знаний об управлении проектами).
В терминологии РМВОК кодирование – это изложение мыслей или идей на языке, понятном для других, а декодирование – преобразование получателем сообщения в понятные ему мысли или идеи. Своеобразная игра в «крокодила».
Третий аспект – количество каналов коммуникаций. Здесь нам снова помог РМВОК. Он (или, как ни странно – «оно», руководство) дает простую формулу расчета: количество каналов коммуникаций равно n(n-1)/2, где n – количество заинтересованных сторон в проекте. Здесь позволю себе привести цитату: «ключевым элементом планирования фактических коммуникаций проекта является определение и ограничение того, кто и с кем будет общаться, а также того, кто и какую информацию будет получать». Только на стороне заказчика в проект было вовлечено 8 человек, а это 28 каналов! Более того, не все участники получали адекватную, понятную им информацию. Можно представить, что мог подумать финдиректор, когда видел нашу переписку с админами, в которой были описания системных ошибок и прочие китайские иероглифы…
В результате мы пришли к нескольким простейшим инструментам (привет, Кэп!), позволявшим держать заказчика в нашем информационном поле:
Вместе с тем, главным достоинством протоколов является решение проблемы «парадокса снежного кома».
Все мы прекрасно знаем, что маленькая «снежка», пущенная с горы вниз превращается в большой снежный ком у подножья. В корпоративной среде существует обратный эффект: незначительный вопрос становится большой проблемой, поднимаясь от уровня исполнителей до уровня руководителей. И чем больше компания и выше иерархия, тем больший объем кома имеем на выходе у заказчика. А там, где у заказчика выход, у нас что? Правильно – вход ;). Этот ком забивает наш вход, заставляя нас судорожно через него пробиваться, чтобы иметь возможность вернуться к проекту и устранить причины образования кома.
Дополним картинку количеством каналов коммуникаций в проекте (а это еще и возможность облепить наш ком дополнительными деталями) и получим. Как больно получим, зависит от весовой категории и степени раздражения заказчика. Протоколы позволяют удержать все стороны на одном информационном уровне, тем самым уменьшив объем кома, а в идеальном случае и вовсе его не создать.
Вместо эпилога.
«Информация, в отличие от ресурсов, задумана, чтобы ею делились».
Роберт Кийосаки
«Чем меньше мы знаем, тем больше подозреваем».
Генри Уилер Шоу
Как бы намекает;)
«- Ты что – глухонемой?
-Да»
к/ф «Бриллиантовая рука»
Попал я как-то в ДТП – один хороший человек так спешил домой к теще на блины, что не заметил перед собой мою машину. Приехал на станцию, там сделали «дефектовку», определили, что делать и срок ремонта – 3 недели. Конечно, хотелось быстрее, но мне объяснили, что СТО загружена, плюс пару деталей надо ждать, плюс технологический процесс: рихтовка, грунтовка, сушка, покраска, опять сушка. «Совсем как у нас в проектах, — подумал я, — проектирование, реализация, тестирование, исправление багов, приемочное тестирование заказчиком, опять исправление багов».
Спустя три недели, истосковавшись по своей «ласточке», в томительном ожидании приезжаю на СТО. И… И, как вы догадались, машина готова не была. Проект «Прокачусь с ветерком» стремительно закончился факапом. После долгих разбирательств выяснилось, что на СТО был переучет деталей, моих не было, их снова заказали. Но через неделю все будет готово: «Мамой клянус, дарагой», — убеждал меня сто-шник. К моему прискорбию, мама оказалась не в курсе клятвенных заверений сына. Не знаю, как там маме икалось и каково было состояние ее здоровья после еще трех недель обещаний, но спустя 7 недель машину я таки забрал. В процессе были мои звонки, переадресация то на одного, то на другого менеджера. Мои планы были уже сорваны, ряд поездок пришлось переносить на неопределенный срок. «Но мы вам брызговики поставили бесплатно», — глупо улыбался сто-шник, передавая мне ключи.
Все же, факт возврата машинки радовал несказанно, и в прекрасном настроении в тот же день я поехал к заказчику. Заказчик, весьма приятный в общении дяденька, увидев меня, почему-то изменился в лице: «Какого хрена вы ничего не делаете? Когда будут результаты? Мы работаем уже второй месяц, сдвигов по проекту нет! Менеджеры ваши непонятно куда пропали. Они на работу ходят или нет?». Машинка внезапно перестала радовать. «Как это нихрена не делаем?», — лихорадило в мозгу. «Вчера ж было совещание, смотрели систему, все ж по плану».
— Дорогой заказчик, у нас все хорошо, бОльшая часть функцонала уже готова, сайт размещен на тестовом сервере, можно смотреть в любое время. Да, у нас были вопросы по ряду функций, но с вашими сотрудниками мы их разобрали.
— Дорогой Максим, — снисходительно сказал заказчик, — это хорошо, что с моими сотрудниками вы все решили. Но Я об этом ничего не знаю. Я плачу за разработку! Мне мои сотрудники, в частности, наш финансовый директор, говорят, что есть проблемы. Вот представь: отдал ты машину в ремонт…
И дальше пошел пересказ моей истории: об обещанных сроках, о том, что их срывают, что нет никакой информации. «Поздравляю, Шарик, ты – балбес», — мысль эта забилась в стенках черепной коробки. «Теперь, Макс, сто-шником будешь ты. Добро пожаловать в ролевые игры».
Ту встречу мы все же закончили на мажорной ноте: я показал систему, заказчик вызывал своего аналитика, мы обсудили спорные вопросы и расстались с улыбками.
Собравшись в офисе командой, мы начали разбирать проблему. Первой выяснилась интересная деталь: общаясь с разными сотрудниками заказчика в разных информационных плоскостях, мы сами дали заказчику ложное представление о реальном состоянии проекта. Вопросы технической организации работ мы решали с системщиками и решались они сложно. Требования обсуждались с бизнес-пользователями, задачи обучения обсуждали с отделом, который находился в другом офисе. Не было единой политики обмена информацией. «Но у нас же есть Jira», — оправдывались ребята. «Там все статусы, все задачи». Но вопрос о том, знает ли заказчик о Jira и о том, что в ней есть, повис в воздухе. Заказчик был в информационном поле, а мы – в информационном окопе.
Вторым аспектом были помехи в коммуникациях. Проще говоря, мы выбрали не те средства связи и не тот способ предоставления информации. И самое главное – отправив информацию, мы не убедились, что она не только принята, но правильно понята: с нашей-то стороны пули вылетели. Позднее, описание проблемы мы нашли в полезной для ознакомления книге PMBOK (Руководство к своду знаний об управлении проектами).
В терминологии РМВОК кодирование – это изложение мыслей или идей на языке, понятном для других, а декодирование – преобразование получателем сообщения в понятные ему мысли или идеи. Своеобразная игра в «крокодила».
Третий аспект – количество каналов коммуникаций. Здесь нам снова помог РМВОК. Он (или, как ни странно – «оно», руководство) дает простую формулу расчета: количество каналов коммуникаций равно n(n-1)/2, где n – количество заинтересованных сторон в проекте. Здесь позволю себе привести цитату: «ключевым элементом планирования фактических коммуникаций проекта является определение и ограничение того, кто и с кем будет общаться, а также того, кто и какую информацию будет получать». Только на стороне заказчика в проект было вовлечено 8 человек, а это 28 каналов! Более того, не все участники получали адекватную, понятную им информацию. Можно представить, что мог подумать финдиректор, когда видел нашу переписку с админами, в которой были описания системных ошибок и прочие китайские иероглифы…
В результате мы пришли к нескольким простейшим инструментам (привет, Кэп!), позволявшим держать заказчика в нашем информационном поле:
- план управления коммуникациями. Он ответил на вопросы кто, когда, какую и в каком объеме должен получать информацию о проекте. Здесь же мы планируем периодичность совещаний, отчетов, встреч. Важно донести до заказчика, что план управления коммуникациями – это дорога с двусторонним движением и правила одинаковы для всех;
- записи. Попробуйте вспомнить, когда последний раз члены проектной команды приходили на совещание с блокнотом и ручкой. Вооот. Введя простое правило «Кто пришел без блокнота – тот не крут», мы решили проблему забытых вопросов и забытых ответов. Сюда же отнесем агенду (agenda), без которой совещание назначать не имеет смысла. Но это уже совсем другая история, описанная Патриком Ленсиони в замечательной книге «Смерть от совещаний»;
- средства коммуникаций. Вопрос не в инструментах, а в подходе. Электронная почта уже прочно вошла сознание как наиболее быстрый и удобный способ коммуникации. Нам легче набрать три листа текста, чем снять трубку и позвонить. Все, что можно обсудить голосом, должно решаться в телефонном режиме. Работая в сфере разработки веб-сайтов, мы пользовались правилом «3-х кликов»: любая информация должна быть доступна в эти три клика. Такое же правило мы использовали и для электронной переписки: если обсуждение вопроса требует более трех писем, это уже повод позвонить. Иначе флейм сообщений превысит допустимый уровень вменяемости чуть более, чем полностью;
- информирование о проблемах и решениях. О, это мы любим – написать о неготовности релиза в день сдачи (в лучшем случае, за день или пару часов). И плохо не только, что мы сообщили поздно. Плохо, что и никаких путей решения не предлагаем! Оставляем заказчика один на один с нашим факапом и имитируем бурную деятельность по спасению мира в отдельно взятом за горло проекте.
В решении этого вопроса (точнее, в его визуализации заказчику) нам очень помог хороший дядька Каору Исикава, разработавший в 60-х годах диаграмму имени себя самого; - протоколы совещаний (recap, meeting minutes). Звучит очень бюрократически, однако, они являются незаменим инструментом. Протоколы позволяют зафиксировать договоренности и не забыть о данных обещаниях. Мы не стали выдумывать велосипед. Один клик – и десяток простых шаблонов доступны для скачивания.
Вместе с тем, главным достоинством протоколов является решение проблемы «парадокса снежного кома».
Все мы прекрасно знаем, что маленькая «снежка», пущенная с горы вниз превращается в большой снежный ком у подножья. В корпоративной среде существует обратный эффект: незначительный вопрос становится большой проблемой, поднимаясь от уровня исполнителей до уровня руководителей. И чем больше компания и выше иерархия, тем больший объем кома имеем на выходе у заказчика. А там, где у заказчика выход, у нас что? Правильно – вход ;). Этот ком забивает наш вход, заставляя нас судорожно через него пробиваться, чтобы иметь возможность вернуться к проекту и устранить причины образования кома.
Дополним картинку количеством каналов коммуникаций в проекте (а это еще и возможность облепить наш ком дополнительными деталями) и получим. Как больно получим, зависит от весовой категории и степени раздражения заказчика. Протоколы позволяют удержать все стороны на одном информационном уровне, тем самым уменьшив объем кома, а в идеальном случае и вовсе его не создать.
Вместо эпилога.
«Информация, в отличие от ресурсов, задумана, чтобы ею делились».
Роберт Кийосаки
«Чем меньше мы знаем, тем больше подозреваем».
Генри Уилер Шоу
Как бы намекает;)