Цікаво про управлінський консалтинг

ООО "Хеликс" использует 12 принципов гибкой разработки. Эти принципы дополняют друг друга, соблюдаются последовательно и параллельно. Их применение позволяет достигать синергетического эффекта от работы участников проекта и достигать целей на основе баланса устойчивости и развития, с учетом рисков. И обязательно помним: "СКАЖИ МНЕ — И Я ЗАБУДУ, ПОКАЖИ МНЕ — И Я ЗАПОМНЮ, ДАЙ МНЕ СДЕЛАТЬ — И Я ПОЙМУ". Конфуций.

Я привожу каждый принцип гибкой разработки в формулировке Agile. Поэтому не удивляйтесь, когда читаете "программное обеспечение", "архитектура". 

1.   Наш наивысший приоритет - это удовлетворение Заказчика при помощи частых и непрерывных поставок ценного для него программного обеспечения.

Комментарий.

Фактически требования стандарта направлены на обеспечение постоянного удовлетворения Клиентов компании в соответствии с их требованиями. Это то, вокруг чего строится вся работа над системой менеджмента качества. Одними из инструментов, которые можно применять – результаты обратной связи с Клиентами, построение карты эмпатии Клиентов и … список можно продолжить. Это внешний Клиент. Но у таких проектов есть еще в внутренний Клиент - Клиент консультанта. Это менеджмент компании и персонал. Они также должны быть удовлетворены работой с консультантом. Есть еще одна составляющая удовлетворенности от проекта. И возможно она самая важная, приоритетная. Это удовлетворение персонала самим собой и друг другом, гордость за достигнутые результаты и открывшиеся возможности. У каждого свое. Но это также часть результатов проекта.

2.   Мы принимаем изменения в требованиях даже на поздних этапах реализации проекта. Agile-процессы позволяют использовать изменения для повышения конкурентоспособности продукта.

Комментарий.

Когда начинается проект, то есть свои ожидания и видение его реализации. Есть риски и предполагаемые возможности. Практика показывает, что входе проекта у Клиента могут меняться приоритеты или ожидания несмотря на то, что есть перечень требований стандарта, которые должны быть выполнены. Это ситуация интересна тем, что сам стандарт содержит требования по управлению изменениями. И в ходе проекта сразу отрабатываются методики управления изменениями, которые потом становятся методиками управления изменениями в компании. В ходе проекта по системам менеджмента, изменения связаны с поиском наиболее результативных и эффективных методов выполнения работ (процессов) с учетом подходов "5M", "5S", вовлеченности персонала, статистических методов. Этот перечень можно продолжить.

3.   Мы стремимся поставлять полностью рабочее программное обеспечение каждые несколько недель, в крайнем случае — каждые несколько месяцев. Чем чаще, тем лучше.

Комментарий.

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

4.   Наиболее эффективный и действенный способ передачи информации — это встреча членов команды разработки ПО.

Комментарий.

Групповая работа является обязательным элементом проекта по системам менеджмента. Важно определить и соблюдать правила такой работы. Хорошей практикой в начале проекта является проведение тренинга по формированию, развитию компетенций сотрудников для работы в группах. Члены команды должны понимать через какие этапы проходит команда. Я сейчас о групповой динамике. Через проведение групповой работы Клиент получает еще один результат – сформирована управленческая команда. Как правило Клиент не знает о возможности получения такого результата. Но этот результат не менее весомый, чем свод установленных правил, KPI, распределенных ответственностей и полномочий и т.д..

"Управленческая команда отличается от любой другой (исполнительской, творческой), прежде всего тем, что она занимается выработкой перспективных решений (VISION, планирование, возможные действия на рынке, изменения в организационной структуре, назначения ключевых лиц и т. п.). Текущими вопросами управленческой команде заниматься не следует - не по чину, так сказать. Эти заботы могут быть предметом заботы на любых совещаниях, планерках, в ином составе и режиме, хотя и члены управленческой команды могут на них присутствовать довольно активно". Методы развития организации. А.И. Пригожин.

5.   Представители бизнеса и команда разработки должны работать над проектом вместе.

Комментарий.

В проектах по системам менеджмент вместе работают топ-менеджмент и рабочая группа. Есть примеры, когда в ходе проекта привлекаются внешние заинтересованные стороны. Совместная работа крайне необходима для снижения уровня риска, связанного с ожиданиями участников проекта. Они разные. И это связано в первую очередь с информацией, которой оперируют каждый из участников проектов.

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

Комментарий.

Для выполнения проекта, как правило, создается рабочая группа. Выбор кандидатов важен. Например, ряд критериев выбора: хорошие знания предметной области; коммуникабельность и умение выслушивать собеседника при проведении интервью; объективность и реалистичность; умение аналитически и гибко мыслить; тактичность, лояльность; умение отделять существенное от несущественного. Рекомендуется при формировании группы учитывать роли, которые играют сотрудники внутри компании. Хотя необходимо признать, что в начале проекта не всегда удается сразу определить эти роли. "Роль есть функция от качеств работника, преломленные через восприятие их средой. Иначе говоря, это фактический вклад носителя роли в положение дел в подразделении, в команде, в компании, влияние на них согласно его индивидуальности и помимо должностных обязанностей". А.И. Пригожин. Роли могут быть – организатор, инноватор, аналитик, исполнитель, приемник, стратег, советник. Можно найти примеры других классификаций ролей. Важно помнить об этом и использовать в ходе проекта.

Для самой рабочей группы определяются ее права, полномочия, обязанности и критерии оценки работы. Не лишним является разработка программы мотивации, и не только с элементами финансовой мотивации. При этом к ключевым мотивационным факторам относятся – уважение, доверие и вера как к рабочей группе со стороны сотрудников, так и внутри самой группы.

ВНИМАНИЕ. Ценность проекта, именно ценность, а не стоимость, для компании является эффективной вдохновляющей целью, мотивирующей всю команду. Когда у нее есть эта цель, она искренне верит в нее и готова решать, как ее достичь (и имеет возможность рисковать), команда усердно работает, используя имеющиеся инструменты, чтобы устранить любые препятствия на пути к этой цели.

"Цена – это то, что Вы платите, ценность – то, что получаете". Уоррен Баффит.

7.   Рабочее программное обеспечение — это главная мера прогресса проекта.

Комментарий.

Ключевым фактором успеха проекта и критически важным результатом для дальнейшего поддержания, осознанного применения и развития систем менеджмента, является наличие у Клиента обученного и мотивированного персонала, который знает, понимает и ОБЕСПЕЧИВАЕТ выполнение требований. Главная мера прогресса проекта – система менеджмента в головах сотрудников компании Клиента и то, что они говорят, думают и делают. Достичь такого результата необходимо, потому что именно это приводит к улучшению финансовых результатов компании.

8.   Гибкие процессы способствуют непрерывному развитию. Спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп работы в течение неопределенного срока.

Комментарий.

Длительность проектов по системам менеджмента качества разная. Прохождение проекта идет по кривой эмоциональной активности от позитива до негатива и снова позитив. Темп работы во многом зависит именно от того, в каком состоянии находится рабочая группа. Факторов много, которые определяют это состояние. К ним можно отнести: выполнение взятых на себя обязательств, открытость, готовность к перераспределению работ, наличие навыков бесконфликтного решения проблем, выполнение работ сверхурочно. Перечень можно продолжить. Но здесь в проекте появляется еще одна роль консультанта, точнее компетенции, которыми он должен обладать. Консультант должен уметь работать с инструментами фасилитации, а порой выступать внутренним коучем. Но это отдельная тема для статьи.

9.   Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.

Комментарий.

Проект ради проекта никому не нужен. Это потерянные ресурсы, демотивированный персонал, рост репутационных рисков. Генри Форд говорил: "Предлагайте людям то, что им действительно нужно, а не то что они просят". То, что должен получить Клиент указанно в Техническом задании и закреплено условиями договора.

В ходе проекта принимаются много решений. Но могут случаться и ошибки, сбои, недоработки. В случае выявления таковых проводится обязательный анализ и принимаются решения. При этом решения могут включать необходимость пересмотра предыдущих достигнутых результатов. Но это необходимо. Цена ошибки при ее движении по проекту возрастает в геометрической прогрессии и ее исправление стоит значительно больше, в том числе потеря такого ресурса как время. Потеря ресурсов снижет гибкость проекта, способность быстро реагировать на возникающие возможности и риски.

Во время работы над проектом уделяется внимание не только разработке проектных решений, но исправлению ошибок, тем самым создавая надежную основу для поддержания системы менеджмента в будущем.

10. Простота — это искусство не делать лишней работы.

Комментарий.

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

Первая часть в наших проектах начинается еще на этапе подготовки и обсуждения Технического задания. Для каждого этапа определяются результаты работы, критерии оценки и, внимание, как эти результаты планируется использовать на последующих этапах выполнения проекта. Техническое задание может быть откорректировано по результатам организационной диагностики, которая обеспечивает выявление корневых проблем в компании. Наши проекты - это не только проекты по применению стандартов на системы менеджмента, но и проекты развития, трансформации с включением многих доступных инструментов по управлению.

Вторая часть обеспечивается через внутреннее обсуждения, пилотные проекты, валидацию разработанных решений и обязательную обратную связь с сотрудниками компании. Здесь параллельно используются принципы №2, №4, №5.

11. Лучшая архитектура, требования и дизайн создаются в самоорганизующихся командах.

Комментарий.

Фактически реализация всех предыдущих десяти принципов обеспечивает создание максимально комфортных условий для работы команды по проекту – эмоциональных, психологических, физических и у кого-то и духовных, что в свою очередь позволяет находить отличные решения, выдавать необычные результаты, соблюдая баланс между результативностью и эффективностью системы менеджмента, обеспечивая внутреннюю устойчивость компании и динамику движения. "Скорость важнее качества. Ускорение важнее скорости. Способность к изменениям направления важнее скорости и ускорения" О стратегии, маркетинге и консалтинге. И.Г. Альтшулер.

12. Команда постоянно ищет способы стать более эффективной путем настройки и коррекции своих действий.

Комментарий.

Настройка и коррекция осуществляются через проведение рабочих встреч. Для таких встреч определяются правила. Например, каждый сотрудник отвечает на три вопроса: что я сделал с момента последнего совещания? Что буду делать вплоть до следующего совещания? Какие препятствия есть на моем пути?

Хорошая работа команды определяется тем, что все участники в любой момент знают, как продвигается работа над проектом.

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