Текст книги "Молекулярное управление: периодическая система проектных элементов. Свод инструментов проектного управления для создания гибридного подхода на предприятиях"

РТ – Реестрий (реестр рисков)

Фаза реакции: фаза планирования

Область реакции: административная функция

Валентность (уровень вовлеченности): основные стейкхолдеры

Периодичность: раз в полгода

Реестр рисков – документ, в котором представлен риск, его оценка по вероятности и ущербу, мероприятия реактивного и проактивного характера.

Вы можете выбрать одну или несколько из существующих стратегий:

1. Избегание (Avoidance): полное устранение риска путем изменения плана проекта или бизнес-процесса. Например, отказ от выполнения определенных задач, изменение маршрута поставки, использование альтернативных технологий. Когда использовать: когда риск имеет высокую вероятность и серьезные последствия, и его можно избежать без значительных потерь для проекта.

2. Передача (Transfer): перекладывание ответственности за риск на третью сторону. Например, страхование, аутсорсинг, заключение контрактов с поставщиками, которые берут на себя риски. Когда использовать: когда организация хочет минимизировать финансовые последствия риска, но не может полностью его избежать.

3. Смягчение (Mitigation): снижение вероятности или последствий риска до приемлемого уровня. Например, внедрение дополнительных проверок качества, резервирование ресурсов, обучение сотрудников. Когда использовать: когда риск не может быть полностью устранен, но его влияние можно уменьшить до приемлемого уровня.

4. Принятие (Acceptance): признание риска и планирование действий в случае его наступления. Например, создание резервного плана, выделение резервных средств, мониторинг риска. Когда использовать: когда риск имеет низкую вероятность или незначительные последствия, или когда стоимость других стратегий превышает потенциальный ущерб.

Пример шаблона реестра рисков

Скачать реестр рисков

ЛВ – Левий (силовое поле Левина)

Фаза реакции: фаза планирования

Область реакции: административная функция

Валентность (уровень вовлеченности): малая группа

Периодичность: раз в три месяца

Силовое поле, или анализ поля сил, – это метод выявления и оценки факторов или групп лиц, влияющих на изменения внутри процесса.

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

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

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

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

Алгоритм работы со структурой:

Шаг 1: Идентификация текущей ситуации и целей.

1. Описание текущей ситуации: определите, в каком состоянии находится проект или процесс в данный момент. Это может включать описание текущих проблем, недостатков или областей, требующих улучшения.

2. Определение целей: четко сформулируйте, чего вы хотите достичь. Это может быть повышение эффективности, снижение затрат, улучшение качества и т. д.

Шаг 2: Определение движущих сил.

1. Сбор данных: соберите информацию о факторах, которые поддерживают изменения. Это могут быть внутренние и внешние факторы, такие как:

Инициатива и поддержка руководства.

Требования рынка и конкуренции.

Технологические инновации.

Потребности клиентов.

2. Анализ данных: оцените, как каждый из этих факторов способствует достижению целей. Определите их влияние и значимость.

Шаг 3: Определение сдерживающих сил.

1. Сбор данных: соберите информацию о факторах, которые препятствуют изменениям. Это могут быть:

Сопротивление сотрудников.

Недостаток ресурсов (финансовых, материальных, человеческих).

Культурные барьеры.

Недостаток информации или навыков.

2. Анализ данных: оцените, как каждый из этих факторов препятствует достижению целей. Определите их влияние и значимость.

Шаг 4: Анализ сил и выявление возможностей и угроз.

1. Сравнение сил: создайте визуальное представление (например, диаграмму), где будут показаны движущие и сдерживающие силы. Это поможет увидеть баланс между ними.

2. Выявление возможностей: определите, какие движущие силы можно усилить для достижения целей.

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

Шаг 5: Разработка стратегии.

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

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

Пример применения анализа поля сил

Ситуация: компания хочет внедрить новую CRM-систему для улучшения управления клиентскими данными.

Цель: повысить эффективность работы с клиентами и улучшить качество обслуживания.

Движущие силы:

• Поддержка руководства.

• Потребность в улучшении клиентского сервиса.

• Технологические возможности новой системы.

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

Сдерживающие силы:

• Сопротивление сотрудников, привыкших к старой системе.

• Недостаток навыков для работы с новой системой.

• Временные затраты на обучение.

• Возможные технические проблемы при внедрении.

Анализ:

Движущие силы сильны, но сдерживающие силы также значительны.

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

Угрозы: потеря времени и возможные ошибки при переходе.

Стратегия:

Усиление движущих сил: проведение тренингов, привлечение экспертов для поддержки внедрения.

Ослабление сдерживающих сил: постепенное внедрение системы, предоставление технической поддержки.

Варианты схем Силового поля:

Вариант заполнения структуры силового поля

Вариант визуализации силового поля

Вариант силового поля в формате интеллект-карты

МО – Мониторий (система мониторинга)

Фаза реакции: фаза реализации

Область реакции: продукт

Валентность (уровень вовлеченности): проектная команда

Периодичность: раз в проект

Для мониторинга внутри проекта я работаю с шаблоном.

Пример шаблона – часть1

Пример шаблона – часть2

Что есть в документе:

1. Номер задачи

2. Наименование задачи

3. Группа задач

4. Цель задачи

5. Продукт входа

6. Продукт выхода

7. Срок выполнения

8. Ответственный

9. Исполнитель

10. Текущий статус

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

Периодически появляются еще дополнительные колонки – в зависимости от проекта, требований заказчика и команды.

Такая форма позволяет сортировать задачи по разным критериям. Встречи я готовлю, исходя из документа – где есть вопросы по статусу, особые комментарии и т. д.

Скачать шаблон для мониторинга проекта

ПЛ – Планий (система планирования)

Фаза реакции: фаза планирования

Область реакции: административная функция

Валентность (уровень вовлеченности): проектная группа

Периодичность: раз в год

Интересно, что планирование – один из самых важных этапов жизненного цикла проекта, однако именно этим этапом руководители и команды жертвуют в пользу времени.

Почему так важно планировать работы по проекту до этапа реализации:

Очевидно, что планирование делает процесс реализации более понятным и предсказуемым.

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

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

Чем чревато отсутствие планирования:

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

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

Без планирования вы не сможете управлять. Ибо нечем. Снижение авторитета и проявление некомпетентности.

Как приучить себя и команду планировать:

1. Начните это делать. Уточняйте у команды, как улучшить систему планирования.

2. Привяжите план к системе управления проектом. Оценивайте работы по плану, рассчитывайте показатели эффективности, проводите ретроспективы и летучки по плану и т. д.

3. В конце отчетного периода вносите корректировки в план, делайте план-факторный анализ, хвалите и благодарите команду за проделанную работу, устраивайте kick-off сессии.

Каким не должно быть планирование:

Фанатичным. Не надо сутками планировать. Достаточно понять, кто, когда, зачем и какие работы выполняет, и дальше декомпозировать индивидуально.

Пустым. Не надо писать непонятные слова в плане. «Описать бизнес-процесс» или «Повысить эффективность». Эти буквы не несут смысла и призыва к действию. В плане все задачи отвечают SMART, в ИТ еще могут отвечать SMARTINI.

Формальным. Нелепость планирования ради планирования. Уж лучше без него. Если любите пустые собрания, почитайте «100 способов казаться умнее».

Какие инструменты точно должны быть в арсенале:

Программный продукт – удобный, понятный, не раздражающий службу безопасности и не противоречащий существующим ИС (информационным системам) в компании.

Общий календарь, чтобы управлять друг другом.

Стандарт планирования для общего понятийного аппарата.

Из личных наблюдений в рамках проектов: планирование – этап, который формально есть, но по факту превращается либо в подобие процесса, либо в хаотичные исследования и рандомные цифры, либо в бюрократичные избыточные данные.

Какое планирование убивает проект:

1. Фанатичное

a. Такое планирование, в котором прописаны задачи: «Передать ключи охраннику 2 февраля 2046 года». Ни охранника, ни ключей, ни проекта в это время может не быть.

b. Планируйте в рамках видимого горизонта. Сегодня долгосрочным планированием считается 9—12 месяцев, среднесрочным – полгода, краткосрочным – до 3 месяцев.

c. Мир так быстро меняется, что избыточное планирование бесполезно по своей сути.

2. Хаотичное

a. У планирования в проектах есть своя последовательность. В зависимости от жизненного цикла и продукта она может меняться, но в классике:

1. формулируем цель;

2. делаем ИСР;

3. пытаемся спаять КСП;

4. уточняем требования и корректируем первые пункты;

5. распределяем ответственности и роли по RACI;

6. формируем БДР/БДДС;

7. планируем риски;

8. разбираемся со стейкхолдерами;

9. делаем реестр метрик и готовимся мониторить изменения.

b. Хаотичное планирование приводит к хаотичной реализации.

3. В одно лицо

a. Планировать надо всей командой. Один руководитель ограничен своим опытом, да еще и с сильнейшей проф. деформацией.

b. Планирование включает в себя экспертную оценку продолжительности, последовательности работ, объемов и приоритетов. Никогда еще ни один руководитель не был в состоянии сделать это comme il faut (фр. «как подобает»). К тому же, такой план будет отторгаться командой, что и правильно.

4. Жесткое

a. Авторитарное планирование. Мол вот так, и только так. Ну да. Сегодня. В проектах. Ага.

b. Руководители возмущаются: «А как доказать и отстоять?!». Развивая лидерство, ораторское мастерство и делая свою речь убедительной и ясной. Читайте книги. Хотя бы 50 в год.

5. «Правильное»

a. В крупных компаниях есть «как надо и принято». Когда речь о гос. Стандартах – вопросов нет. Но когда речь о гибких подходах – будьте добры, уберите шаблоны. Любой проект – неопределенность в кубе.

Планирование – в команде или в одно лицо?

Вопрос важный. Потому что, с одной стороны, Agile кричит о командном планировании, с другой – линейное управление про централизованное планирование. Я – про уважение команды, но в меру. Ответственность в итоге на руководителе. Поэтому постараемся выдержать золотую середину.

Цикл планирования:

1. Сначала сам – планирование весьма интимная штука. Команда, конечно, молодец, но всех нюансов проекта она не знает и знать не должна. Поэтому на первом этапе верхнеуровневое планирование делает руководитель, определяя три типа сроков:

a. движимое (то, что можно двигать или назначать самостоятельно при наличии должных аргументов);

b. недвижимое (то, что нельзя двигать, аргументы тоже не спасут);

c. купленное (то, за что заплатили и это надо сделать… Но можно чуть сдвинуть, хотя лучше сделать это и забыть вообще).

2. Потом команда – отдаём команде. Пусть делает свой план с учётом точек входа в виде трёх типов сроков.

3. Снова сам – руководитель смотрит и женит два плана, вносит свои корректировки или нет.

4. Обсудить с командой – обсуждаем финал, пытаемся услышать друг друга. Руководитель должен чуть присесть, команда – снять гонор и побыть в шкуре того, кто отвечает.

5. Снова сам – финальная медитация – календарный онанизм. Теперь план работ должен биться с БДДС и планом коммуникаций. Тут команда – не помощник, а мешатель.

На следующую итерацию вернуться к шагу 1.

А как же важные правила «никаких подходов», «в планировании принимают участие все» и «планы не меняются»?

1. После того, как руководитель определит границы плана, в планировании принимают участие все, кто ДОЛЖЕН ПРИНИМАТЬ. Зевак убираем. Мода привлекать смежников туда, где они не нужны, – крайне нелогичная затея. Исключения составляют деструктивные корпоративные культуры, которые про человека – там можно делать что-угодно. Ничего хорошего всё равно не выйдет.

2. Планы не меняются в рамках отчетного периода. У вас какой отчётный период? Месяц? Две недели? День как в XP? Ну вот в этот период и не меняются планы. В остальном же – ПЛАНЫ ДОЛЖНЫ МЕНЯТЬСЯ. У вас же появляются новые условия, меняются ключевые требования, прирастают объемы готового. Исключение составляет линейное управление. Там без толку что-то менять. Дорого, да и пока перестроишь огромную орг. структур проекта – с ума сойти можно. Пусть уже всё идёт как идёт. Дешевле.

А что насчёт документов? Он должен быть. Если у вас нет документа с планом, плана нет. «У нас всё есть в голове! Мы же обсуждаем план каждый день на летучке». Мда. В голове. В чьей? В какой? Документ. Нет документа – нет управления. Я серьёзно.

Документ должен быть для:

• контроля;

• анализа;

• единого инфо-поля;

• управления данными;

• библиотеки корп. практик;

• порядка, блин.

Важные правила:

Планируем справа налево, проверяем слева направо.

Декомпозируем не фанатично – только в рамках управляемой формулы 8/80.

В плане должны быть ответственные. А если ответственность распределила сама команда, проверяем и распределяем в соответствие с реальными компетенциями, а не их солидарности друг к другу.

«Но мы уважаем друг друга в команде, и если кто-то не хочет выполнять какую-то работу, то мы никого не заставляем». Мы тоже. Но только в том случае, если у сотрудника есть моральное и профессиональное право. Никакого равноправия. Один – бОльший профессионал, другой – меньший. Какое тут равноправие. Выбирать может тот, кто делает основную работу и не должен отвлекаться на другое. В остальном – подписан договор, не хочешь выполнять работу, иди в другую команду другой компании.

Управление – это комплекс инструментов, подходов, методов, которые применяет руководитель для организации работы команды для достижения целевых показателей.

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

Пример моего календаря

ПЗ – Презий (правила оформления презентаций)

Фаза реакции: фаза реализации

Область реакции: административная функция

Валентность (уровень вовлеченности): проектная группа

Периодичность: раз в проект

По итогам посещенных мероприятий можно выделить следующие рекомендации по повышению эффективности проведения презентаций:

Использовать на слайдах тезисы, а не большие блоки текста.

Следовать принципу минимализма, избегать большого количества деталей, картинок, схем на одном слайде.

Использовать инфографику для отображения какого-то процесса вместо текстового описания или словесного озвучивания.

Выдерживать презентации в едином фирменном стиле.

Оценивать слайды презентации с точки зрения полезности.

Не использовать изображения таблиц и схем с нечитабельными элементами.

Выдерживать регламент выступления, оставлять время на вопросы участников.

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

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

Коллеги, важно – презентация – лицо вашей компании. Помните об этом.

Содержание:

1. Добавляйте слайд с проблематикой – почему вы вообще говорите о том, о чем говорите сейчас?

2. Выдерживайте структуру, которую заявляете на слайде «О чем поговорим». Проверяйте себя в конце – все ли вы учли.

3. Если у вас доклад на 30 минут, у вас не может быть 73 слайда. Никак. Ориентируйтесь для доклада на 15-20 слайдов.

4. Структура доклада должна быть логичной – о чем будете говорить? Почему? Какую проблему решает то, о чем вы скажете? Что за инструменты? Есть ли сложности с ними и ошибки? Что предлагаете? На что обратить внимание? Чек-лист или общие итоги (кратко резюме на одном слайде – что вы дали участникам? С чем они уходят?

5. Не плодите слайды на пунктах. Если у вас 5 пунктов в каком-то блоке, разместите их буллитами на одном слайде.

Оформление:

1. Шрифт должен быть читабельным. Исключение – одно слово на слайде или вопрос для акцента.

2. Есть фирменный стиль конференции, коллеги, он сделан не просто так. Свою компанию вы пиарите уже своим выступлением.

3. Не надо много текста на слайде! Если вы описываете подход, на слайде достаточно названия подхода и максимум его автора.

4. QR коды лучше делать классическими черными квадратными. Проверяйте сами, читаются ли они.

5. Картинки. Давайте без клипартов в эпоху доступных иллюстраций. Если вы позиционируетесь как высокотехнологичная инновационная современная компания, хотите привлечь сотрудников или партнёров, задайте задачу в отдел дизайна или маркетинга – пусть нашаманят с пяток иллюстраций.

Если используете текст из книги/сайта, схему, иллюстрацию, ОБЯЗАТЕЛЬНО указывайте источник/автора.

ТЗ – Тэзий (техническое задание)

Фаза реакции: фаза планирования

Область реакции: продукт

Валентность (уровень вовлеченности): проектная команда

Периодичность: раз в год

Без технического задания мы в работу не пойдем – это однозначно. С шаблоном «Разработка технического задания» должны быть ознакомлены все.

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

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

Техническое задание – это основа для технического проекта, потому что с техническим проектом работают те, кто будет разрабатывать систему дальше.

Что важно?

Чтобы требования, которые отражались в техническом задании, были понятны. Если вы не разбираетесь в специфике системы, если вам не понятно требование, то оно не понятно. Оно должно быть понятно вам просто как человеку, который не имеет к этому отношения. Чаще устраивайте себе и команде проверки на ясность формулировок и требований: «Я понятно написал?», «Я понятно изложил суть проблемы или суть требования?»

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

Требование должно быть тестируемым.

По ГОСТу есть рекомендации, какие разделы должны быть в техническом задании, например:

Как будет называться система

Краткое наименование

Актуально или нет

Указание нормативно-справочной документации

Назначение и цели создания системы

Характеристика объектов (будем ли мы что-то менять, будет ли меняться что-то в процессе или в существующей системе)

Требования к системе

Технические требования

Состав содержания работ по созданию системы (здесь может отражаться последовательность, например, изменений, которые мы требуем)

Порядок контроля и приемки системы

Требования к составу и содержанию работ по подготовке, например, бизнес-процессов, в которые будет внедряться эта система

Требование к документированию (здесь могут прилагаться в ТЗ шаблоны документов, с которыми необходимо будет работать или которые нужно будет заполнять, отчетные документы)

Список требований к надежности, безопасности, транспортабельности

Требования к видам обеспечения

Источники разработки