Системное лидерство - тренинг

Если вы:

• понимаете комиксы с Дилбертом
• считаете, что менеджеры и специалисты не договорятся никогда
• не можете объяснить пятилетнему ребенку, как то, чем вы и ваши коллеги заняты вот прямо сейчас поддерживает стратегию компании
• при просмотре рекламного ролика EDS про кошачьих пастухов не видите очевидных улучшений используемых кэтбоями технологий

То читайте дальше.

Если вы:

• спонсоры и руководители программ проектов или проектные менеджеры
• руководители отделов обучения и развития и менеджеры HR
• менеджеры по управлению организационными изменениями

И вам интересны:

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

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

Вы хотите снизить роль денежной стимуляции при организации работ.

То это тренинг для вас.

В основу тренинга поставлен стандарт по управлению программами проектов Р2М, конкретно те разделы, которые описывают платформу сообщества (Р2М community platform). 

Основная задача этого тренинга - дать теоретические и практические основы для построения профессионального сообщества, работающим над программой проектов развития. 

Для унификации терминологии с курсом системного мышления программа проектов далее будет называться предпринятием, а  платформа сообщества программы «платформой сообщества предпринятия», далее ПЛАС. 

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

Необходимое предварительное требование программы обучения – курс системного мышления Школы системного менеджмента в объеме первых трех дней.

Материал курса намеренно предельно урезан и приближен к практическим навыкам (hard skills).

Место ПЛАС в управлении программой проектов

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

1. Архитектура платформы сообщества предпринятия

a. Место ПЛАС в архитектуре программы

b. Модель мотивации деятельности в программе

c. Функциональная схема ПЛАС

d. Основные модульные решения ПЛАС

e. Основные подальфы команды, их состояния (новый руководитель, новый подчиненный, сформировавшаяся команда с новым руководителем, неорганизованный член команды, неэффективный член команды, эксперт, творческий работник, член команды с проблемами общения, суперзвезда)

f. Основные интерфейсные решения ПЛАС

2. Коммуникационные циклы и модели

a. Циклы информирования (для исполнителя)

b. Циклы влияния (для knowledge worker)

c. Циклы ритуального общения

d. Модель коммуникации DEMO

e. Технологии использования коммуникационных циклов

f. Ситуационное лидерство и паттерны работы с подальфами команды

g. Типовые проблемы и ошибки в коммуникационных циклах (кризисы производительности и доверия), подход к восстановлению разрушенных отношений в команде

3. Дисциплины

a. GTD и Тойота Ката (адаптированный вариант пустого инбокса Максима Дорофеева)

b. Визуальная грамматика

c. Основные ошибки мышления (cognitive bias)

d. Принятие решений по схеме WRAP

e. Эмоциональный интеллект

f. Техника переговоров Джима Кэмпа

g. Управление организационными изменениями по методике changesetter (круг изменений, микс 4 комнат, Коттера и ситуационного лидерства)

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

Предварительная подготовка – Джим Кэмп «Сначала скажите нет», «Ловушки мышления» Чип и Дэн Хиз. Подготовка к деловой игре, анализ и групповая работа над переговорной позицией

Программа обучения

День 1. Коммуникационные циклы и модели. Основные подальфы команды и практики работы с ними. Деловая игра «Переговоры в проекте внедрения CRM» команда филиала-внедренца против команды корпоративного центра. Разбор итогов игры с использованием материалов курса.

Домашнее задание. «Эмоциональный интеллект. Российская практика», «Бла-бла-бла» Дэн Роэм, «Наш айсберг тает» Коттер. Минимум 5 прогонов на симуляторе организационных изменений.

День  2. Разбор результатов симуляции. Changesetter и связь с подальфами команды. Архитектура ПЛАС. Закрывающая сессия.

Домашнее задание. «Все начальники делают это» Тулган, «Как привести дела в порядок» Аллен.

Сессии по разбору ситуаций в проектах участников, планирование индивидуальных траекторий развития с использованием подхода Making the Matrix work by Kevan Hall.

Сравнение бизнес-анализа и системного мышления

http://www.babokonline.org/

Резюме после пролистанных по диагонали 120 страниц.

Бизнес-анализ примерно соответствует инженерии требований. Главными артефактами работы аналитика, работающего на основе BABOK является гармонизированный набор требований и логической архитектуры решения.

Два ключевых отличия аналитика от инженера по требованиям:
1) Не используется прием абстрагирования системы как черного ящика с сервисом и интерфейсом, требованиями называются как требования, так и ограничения и архитектура;
2) Не рассматривается воплощение системы, работа аналитика завершается выпуском т.н. "архитектуры требований", которая состоит из гармонизированного набора требований и логической архитектуры. Модели привязаны (оттрассированы к модулям).

В чем системное мышление и бизнес-анализ схожи?

1. Работают со стейкхолдерами, сгруппированными по интересам. Каждому интересу предъявляют свой частный метод описания и частное описание.
2. Работают с потребностями, потребности фокусируют требования. Используется целеориентированная инженерии требований, есть трассировка от стейкхолдеров и их целей к требованиям и архитектуре. Требования рассматриваются как функциональный объект (альфа), с набором состояний.
3. Используется функциональная декомпозиция, требования трассируются к модулям.
4. Есть понятие платформы системы как набора типовых архитектурных решений

В чем системное мышление и бизнес-анализ различаются?

1. Требования и архитектура (requirements and designs) постоянно путаются и смешиваются. Прямо заявляется "Requirements are focused on the need; designs are focused on the solution. The distinction between requirements and designs is not always clear. The same techniques are used to elicit, model, and analyze both. A requirement leads to a design which in turn may drive the discovery and analysis of more requirements. The shift in focus is often subtle".
2. Состояния альфы "Требования" определяется по усмотрению, нет чек-листа для определения состояния требований.
3. Под верификацией БА подразумевает " Requirements (verified): a set of requirements that have been verified to be of sufficient quality to be used as a reliable body of work for further specification and development...Verify Requirements: ensures that a set of requirements or designs has been developed in enough detail to be usable by a particular stakeholder, is internally consistent, and is of high quality." Т.е., верификация требований в БА - это соответствие требований требованиям к требованиям.
4. Под валидацией БА подразумевает "Validate Requirements: ensures that a set of requirements or designs delivers business value and supports the organization's goals and objectives", т.е., валидация производится против требований к обеспечивающей системе.
5. Методы БА не могут быть рекурсивно использованы на любом уровне холархии системы. Системы задаются объективно. Холархия требований отсутствует.
6. Воплощение системы не рассматривается, жизненный цикл системы с выделенной стадией эксплуатации не используется, хотя стейкхолдеры из стадий использования и обслуживания заявлены.
7. Стейкхолдеры не рассматриваются в ролях, 4Д экстенсионализм к ним не применяется. Роль стейкхолдера фиксирована на исполнителе.
8. В БА платформы системы не содержит типовых интерфейсов и модулей.
9. БА использует пять аспектов рассмотрения системы "The perspectives included in the BABOK® Guide are:• Agile• Business Intelligence• Information Technology• Business Architecture• Business Process Management"
10. Функциональное разбиение используется по большей части при анализе оргпроцессов, не используется при модульном синтезе. Модульный синтез основан на фольклоре (мозговые штурмы, рабочие встречи), нет метода.
11. Логическая и физические архитектуры не связаны "Requirements architecture is the structure of all of the requirements of a change. A requirements architecture fits the individual models and specifications together to ensure that all of the requirements form a single whole that supports the overall business objectives and produces a useful outcome for stakeholders.Business analysts use a requirements architecture to:• understand which models are appropriate for the domain, solution scope, and audience,• organize requirements into structures relevant to different stakeholders,• illustrate how requirements and models interact with and relate to each other, and show how the parts fit together into a meaningful whole,• ensure the requirements work together to achieve the overall objectives, and• make trade-off decisions about requirements while considering the overall objectives. Requirements architecture is not intended to demonstrate traceability, but rather to show how elements work in harmony with one another to support the business requirements, and to structure them in various ways to align the viewpoints of different stakeholders. Traceability is often used as the mechanism to represent and manage these relationships (see Trace Requirements (p. 79)). Traceability proves that every requirement links back to an objective and shows how an objective was met. Traceability does not prove the solution is a cohesive whole that will work."

Постановка практики трекинга

При запуске трекера допускают две основные ошибки:

1)    Не определяют процесс управления задачами и схему поддержки трекера, включая процедуры планирования, изменения и закрытия задач и проектов, шаблоны, индивидуальные планы работ, чек-листы запуска и закрытия проектов, проектных аудитов и связи трекера с Outlook и Exchange;

2)    Не обучают дисциплине управления задачами. Это может быть GTD, 18 минут, одноминутный менеджмент или сборная техника, например, пустой инбокс.

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

Про дисциплину не буду распространяться, книжек и вебинаров на эту тему предостаточно. Стоит только помнить – ограничивайте WIP (work in progress, количество одновременно исполняемых дел) и ставьте очень конкретные задачи.

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

Предельно упрощенные чек-листы Эссенс

Представители заказчика
Определены	1. Роли и ответственность представителей заказчика были определены 2. Есть конкретные люди, которые согласились исполнять эти обязанности 3. У назначенных на проект людей есть все необходимые полномочия для исполнения обязанностей 4. Принципы совместной работы определены
В согласии	1. Представители заказчика ходят на собрания и активно участвуют в решение вопросов по проекту 2. Представители заказчика выполняют все возложенные на них обязанности 3. Представители заказчика своевременно общаются с командой, дают обратную связь и принимают необходимые решения 4. Представители заказчика согласны с выставляемыми приоритетами
Удовлетворены	1. Представители заказчика согласовали минимальные ожидания к продукту проекта 2. Представители заказчика обеспечивают обратную связь по использованию продукта проекта 3. Представители заказчика согласны принять продукт проекта 4. Ожидания представителей заказчика были удовлетворены
Возможности и Бизнес-кейс
Определены	1. Спонсор видит возможность и хочет инвестировать ресурсы в исследование проблемы и поиск решения 2. Проблема, которую решает проект ясна, понятны ее корневые причины 3. Найдено как минимум одно решение проблемы
Польза ясна	1. Польза от успешного решения проблемы установлена и посчитана 2. Влияние реализованного проекта на представителей заказчика и на бизнес компании понятно всем 3. Все представители заказчика согласны с бизнес-кейсом и готовы реализовывать проект
Адресованы	1. Решение выбрано и стоимость его реализации, обслуживания и поддержки на пять лет посчитаны 2. Есть оценки, показывающие, что решение может быть разработано и развернуто в рамках заданных ограничений 3. Риски находятся под контролем 4. Есть пилотный проект либо практическая реализация, показывающая, как выбранное решение решает проблему
Эффект достигнут	1. Есть готовый к использованию продукт 2. Представители заказчика удовлетворены тем, как продукт реализует возможность, описанную бизнес-кейсом 3. Итоговый бизнес-кейс одобрен спонсором
Требования к продукту
Понятны в общем	1. Назначение и состав продукта согласованы всеми представителями заказчика 2. Критерии успешности проекта утверждены спонсором 3. Ключевые предположения и ограничения проекта определены, зарегистрированы и донесены до представителей заказчика на совещании по запуску проекта
Понятны полностью	1. Большая картинка и общая презентация по продукту согласована всеми представителями заказчика и командой 2. Основные сценарии использования продукта конечными пользователями определены 3. Приоритеты требований ясны 4. Требования описывают продукт, который представители заказчика считают приемлемым для дальнейшего использования
Выполнены	1. Польза продукта ясна 2. Достаточное количество требований было реализовано для того, чтобы считать, что качество продукта приемлемо 3. Представители заказчика готовы начать использование продукта 4. Продукт полностью соответствует изначально определенным требованиям
Продукт
Концепт выбран	1. Выбранная концепция снижает ключевые риски технической реализации и исполнения проекта 2. Критерии выбора концепции согласованы 3. Платформы, технологии и партнеры выбраны 4. Решения по покупке, самостоятельной разработке или повторному использованию элементов приняты
Можно использовать	1. Критичные интерфейсы и основные элементы продукта реализованы 2. Продукт можно использовать и его качество отвечает потребностям 3. Конечные пользователи могут использовать продукт 4. Функциональность и технические характеристики продукта протестированы и приняты представителями клиента 5. Уровень дефектности удовлетворителен
Готов	1. Пользовательская документация доступна 2. Представители клиента приняли продукт и хотят запустить его в эксплуатацию 3. Продукт используется в производственном окружении конечными пользователями
Команда
Сформирована	1. Миссия команды и зоны ответственности участников ясны 2. Необходимые компетенции определены 3. У команды есть достаточное количество ресурсов для начала работы 4. Участники команды знают, как выполнять назначенную им работу
Сотрудничает	1. Команда работает согласовано 2. Коммуникации в команде открытые и честные 3. Команда стремится выполнить миссию 4. Участники команды ставят коллективный успех выше собственных интересов
Эффективно работает	1. Команда результативно и эффективно работает 2. Адаптируется к изменяющимся обстоятельствам 3. Производит продукт высокого качества 4. Почти не занимается переделками и постоянно улучшает рабочий процесс
Рабочие практики и Технология
Определены	1. Ключевые практики и инструменты готовы к использованию 2. Различие между текущим и целевым уровнями владения практиками и технологиями понятны 3. Выбранные практики и технологии увязаны и могут быть использованы совместно
Используются	1. Некоторые участники команды используют практики 2. Использование практик и технологий регулярно отслеживается 3. У команды есть доступ к инструментам 4. Обучение использованию проведено, обратная связь по удобству использования собирается и вовремя отрабатывается
Работают хорошо	1. Практики и технологии хорошо подходят для команды 2. Работа выполняется вовремя

Управление целями проекта по контрольным точкам

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

Проект плывет от одной контрольной точки к другой

Контрольные точки проектов выделяются трех уровней.

Уровень 1. Определяется выбранным видом жизненного цикла проекта.

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

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

Первая точка в жизненном цикле проекта – это совещание по запуску проекта (кик-офф). Если вы используете Эссенс, то есть варианты жизненного цикла и, соответственно, контрольных точек первого уровня.

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

Уровень 2 (КТ2.х). Определяется изменением состояний альф и подальф проекта и реализацией важных требований.

Шестифазная модель жизненного цикла проекта по Эссенс. Фазы делятся КТ1.х. Состояния отдельных альф - КТ2.х

Уровень 3 (КТ3.х) определяется личными рабочими планами.

КТ1.х и КТ2.х всегда привязываются к требованиям и в них происходит проверка и приемка. Это значит, что их прохождение контролирует стейкхолдер, чьи требования выполняются.

Управление работами происходит только на уровне КТ3.х либо отдельных задач.

В схеме управления целями проекта из P2M пакет работ (work package) как раз и является КТ2.х при управлении в трекере

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

Схема развертывания трекера

Очки системного мышления и Гарри Поттер

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

Очки системного мышления

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

Вижу одно и то же, задаю одни и те же вопросы, но все для дела

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

Системное мышление состоит из трех блоков:

1. Как думать о людях и их интересах. Как выяснить, что они хотят? Как учесть все их хотелки в мега-модели?
2. Как составить мега-модель? Как надо думать о системе, чтобы она делала все то, что хотят от нее люди?
3. Как проверить, что построенная по мега-модели система соответствует хотелкам людей и вообще успешна?

Итак, (люди) – (модель) – (реальная система, ее проверка с приемкой). Давайте разберемся подробнее с пунктом 1, с людьми.

Мы уже сказали, что в системном мышлении мы смотрим на мир сквозь очки. На самом деле, у системного человека три пары очков – фиолетовые, желтый левый, синий правый и зеленый для третьего глаза (это не устаревшие уже 3Д очки, как вы подумали, а их модификация для 4Д) и сиреневые.

Люди и их интересы - вот что лежит в основе системного подхода

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

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

Стейкхолдер племени сибаи в естественной среде обитания. Наскальный рисунок, начало 21 века

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

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

Тайная жизнь Ольги в Мире Варкрафт

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

Роль стейкхолдера позволяет понять, как он будет себя вести

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

Как же стейкхолдеры понимают, что они хотят о системе и что реализованный проект по созданию системы успешен?

Успешна система или нет определяют стейкхолдеры. И мнения их могут меняться

Стейкхолдеры предъявляют требования и заявляют потребности к системе. В чем отличие требований от потребностей? Давайте разберемся.

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

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

Другими словами, стейкхолдеры предъявляют свои требования к системе как к черному ящику. 

Поэтому требования часто формулируются с использованием схемы «Я, как <роль стейкхолдера> хочу от <системы> <поведение или функциональность>, чтобы была <польза>».

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

Как же так, спросите вы? Очень просто, достаточно посмотреть на ваш телефон. Когда он входит в систему сотовой связи, по нему можно звонить и бродить в Интернете. Но его можно подключить к Apple TV и смотреть фильмы на большом экране. А можно включить систему спутниковой навигации, и тогда он будет показывать дорогу. Функция системы всегда определяется тем, в какую надсистему она входит. Надсистема имеет особое название «использующая система». При этом саму систему называют «целевой системой».

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

В качестве примера инженер объяснил Ольге:

1. Использующая система – сеть сотовой связи. Функция целевой системы – обеспечивать Интернет соединение и связь абонента с другими абонентами. Потребность стейкхолдера абонент «телефон в составе сети сотовой связи должен обеспечивать качественную связь и быстрый коннект». Требование «телефон должен поддерживать LTE соединение».
2. Использующая система – Apple TV. Функция целевой системы – обеспечивать трансляцию видео и аудио потока на телевизор. Потребность стейкхолдера зритель «телефон в составе Apple TV должен обеспечивать показ большинства фильмов HDTV на большом экране». Требование «телефон должен показывать фильмы с разрешением HDTV с FPS 30 и передавать потоки на Apple TV в пределах 2 метров от приемопередатчика».
3. Использующая система – GPS и Яндекс.Навигатор. Функция целевой системы – обеспечивать определение местоположения и показывать дорожную обстановку и оптимальный маршрут движения. Потребность стейкхолдера водитель «телефон в составе системы дорожной навигации должен сокращать время поездки на 30 минут в день». Требование «время работы без зарядки не менее 5 часов, чтобы можно было доехать до любого места в области».

Задачка. Определите интересы стейкхолдеров в каждом случае.

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

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

Дальше целевая система проектируется по этим требованиям. Здесь и создается мега-модель системы.

После этого система производится по мега-модели, и производится ее проверка против требований и приемка.

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

Используя пример Ольги, проверкой будет:

1. Подключение антенны телефона к осциллографу и анализатору сигналов, чтобы проверить, что сигнал с антенны соответствует протоколу LTE.
2. Замер частоты передаваемых кадров и коэффициента затухания на двухметровом видеокабеле HDTV.
3. Измерение времени автономной работы аккумулятора на типовой нагрузке.

А для приемки придется сделать прототип и отдать его на опытную эксплуатацию либо строить полноценный стенд, который сымитирует спутники GPS, базовую станцию LTE или Apple TV.

Тестирование – это наиболее частый случай проверки. 

Опытная эксплуатация – наиболее частый случай приемки.

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

Если проверка показывает, что в жизни система ведет себя не так, как мы описали, хотя все сделано по спецификациям, значит, надо поправить модель. А если система сделана не так, как описано, возможно, надо ее переделать.

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

Одна легенда - сто тысяч карт 

Другими словами, есть метод описания, с использованием которого можно ответить на несколько интересов, сделав соответствующие описания.

Квинтэссенция всего поста

Бейсики лидерства

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

Отсылаю к недавнему посту Архитектурная диаграмма подхода ПрОф2020, говорить мы будем про квадратики "Управление командами" и "Визуальное мышление".

Основой рассуждений будет эта диаграмма:

Для более подробного пояснения надо рисовать еще и V-диаграмму для альфы команды и показать связи там, но сейчас делать этого не буду.

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

Функциональное разбиение системы лидерства:
1) На старте проекта есть команда и роли, которые она должна исполнять. До них надо довести эти роли. Нам нужна практика коммуникации. За это отвечают дисциплины визуального мышления и инфостиля;
2) Нам надо информацию донести в верном эмоциональном ключе и разбить задачи на понятные компоненты. За это отвечают практика Theory of mind based communications (переводы в студию), дисциплины GTD, техника пустого инбокса, эмоциональный интеллект Гоулмана;
3) Нам надо привязать модель бизнес-мотивации к личной мотивации участников команды. Помним Дэна Пинка, мотивацию нельзя создать, ее можно только использовать - ту, которая уже есть. Поэтому нужны переговорные техники, я рекомендую Джима Кэмпа, она одна из самых простых и эффективных. Сюда же идет реципрокность, внутренние валюты команды и прочее DEMO, полагаю;
4) Далее, после того, как мы довели роли до участников команды, договорились, надо контролировать и следить ,чтобы эти роли и договоренности выполнялись. Тут приходит на помощь бихевиоризм и недооцененный у нас Брюс Тулган со своим развитием одноминутного менеджмента, в русском переводе "Все начальники делают это". Практика положительных и отрицательных подкреплений, дисциплина "Одноминутный менеджмент";
5) То же самое нужно на уровне коллектива, за это отвечает практика управления организационными изменениями, дисциплина changesetter, они удачно совместили три модели - Коттера, ситуационное лидерство и 4 комнаты, и создали типовые симуляторы и ситуационные плейбуки на стадии изменений.

Примерно так.