У меня есть очень умный брат
Когда я рассказывал ему про системный подход, он сказал: “Так это ведь все просто здравый смысл”. Я пытался объяснить, почему нет, но не смог. Шесть месяцев спустя я понял почему. Потому что это и в самом деле здравый смысл, но он потерян в бесконечных диаграммах, сложных текстах и абстракциях. Здесь я раскрываю свой взгляд на системное лидерство.
Есть два вида объяснений системного подхода - байки и международные стандарты.
Проблема с моим текущим объяснением системного подхода в лидерстве в том, что для человека, работающего в типичной российской компании, он выглядит так:
Кролики и арифметика - это методы управления людьми с помощью регламентов и штрафов.
Высшая математика и тригонометрия - это системный подход.
Перейти от первого ко второму получается лишь у самых упорных.
Второй вид объяснений - это Сенге с “Пятой дисциплиной” и Годраттом. Это объяснение системного подхода байками. Считается, что если будешь десять лет рассказывать про котов Шредингера, то уверенно отличишь бозон от фермиона. Не знаю как вас, но меня ни одна байка ничему серьезному не научила.
В этом тексте я объясняю, как компании пришли к использованию системного лидерства, шаг за шагом. Это объяснение с позиций здравого смысла.
Где та разница, которая даст разницу?
Достижения любого проекта ограничены только мозгами вашей команды:
Если вы можете сделать ракету, вы умник
Обезьянка должна делать, рациональный тип организовывать:
Обезьянка не понимает производственные планы и графики и письма с описанием проблем
Разница между обычным человеком и талантом
в списках дел:
У исполнителей негодный список дел
У исполнителей хороший, правильный список дел
Что должно быть в твоем списке дел, чтобы быть талантливым?
Список задач вашей команды - это все, на что вы можете повлиять. Это разница между успехом и провалом.
Или даже
Системный подход - это схема мышления и чек-листы, которые помогают составить правильные списки задач в вашем проекте.
Общие правила системного мышления
Описание одного из 41 ходов системного мышления
Вы системно планируете свой проект и добиваетесь успеха
Структура объяснения
Часть 1. Управление проектами за 4,000 лет до н.э. (лучшие практики строительства Зенит Арены)
Часть 2. От чего в проектах завелись системные инженеры? (или почему Королев работал хуже Роберта Симэнса)
Часть 3. Системный подход 2.0 (спустя 70 лет после Эйнштейна остальные люди поняли, что время - это четвертое измерение, у людей есть свобода воли, а инженеры догадались, как использовать всю эту философию в строительстве мостов)
Часть 4. За пределами системной инженерии (конец эпохи пожизненного найма, переход к мотивации 2.0, “поколению Y+” и спиральной динамике организаций, а также ответ на вопрос “Как сейчас проектируются и строятся команды?” (подсказка - в Экселе)
Часть 1. Управление проектами за 4,000 лет до н.э.
В проектах есть заинтересованные стороны. На профессиональном жаргоне проектных управляющих "стейкхолдеры", так короче. Стейкхолдеры говорят, что и как надо сделать в проекте, дают на него деньги и могут остановить работы. У стейкхолдеров есть интересы, которые они оценивают. Например, стейкхолдер “Исполнитель” имеет интерес "Деньги", а оценкой интереса будет "Оплата договора справедливая" или "Платят слишком мало". В основе целей проекта всегда лежат интересы и оценки.
Возьмем простой проект ремонта квартиры:
На диаграмме выглядит так:
Совет - откройте эту диаграмму на отдельном экране или хотя бы в отдельном окне, вам придется часто на нее смотреть.
Ставим цель
Неопытные руководители проектов (РП) часто допускают ошибку. Они записывают цель под диктовку: "Заказчик хочет жить в красивой и удобной квартире". Это правильно по содержанию, но не дает понимания причин. Этими словами вы признаете, что решение принято и договариваться не о чем. При таком подходе вы не получите хороший результат. Чтобы сделать заказ хорошо, нужно понять, какие есть варианты решения и выбрать наилучший. Для этого надо спросить заказчика почему он поставил себе такую цель. Он скажет, что некуда повесить рубашки, на кухне неудобно готовить, а балкон завален барахлом. И чуть позже добавит, что обои истерлись, а шкаф в детской покосился. Вы понимаете, что его интерес - это удобство, а оценка интереса - квартира неудобная и некрасивая.
Теперь у вас есть модель целеполагания из стейкхолдера, интереса, оценки этого интереса и цели этого стейкхолдера. Когда вы принимаете решения по выбору плитки, мебели, модели крана, у вас есть четкий ориентир. Можно детально расспросить его, что такое удобно, что такое красиво и заказчик будет доволен результатом ремонта.
Запомните: цель - это стены и крыша дома, а интересы и оценка - его фундамент. Хотите крепкий дом - ищите надежный фундамент.
У нас есть цель, идем дальше.
Определяем результат
Для достижения цели нам надо что-то сделать. И тогда мы получим результат, который приведет нас к цели. Например, я хочу разговаривать с людьми и писать в ФБ - это цель. Мне надо выбрать и купить телефон и сим-карту с тарифом на 1 Гб - это действия. Подключенный телефон - это результат.
На жаргоне проектных управляющих действия - это пакет работ. Когда РП планирует проект, он оценивает пакеты работ. Он говорит "Ремонт этой квартиры займет 3 месяца и будет стоить 800 тысяч". Это его оценка пакета работ, не путайте с оценкой интереса стейкхолдером.
На английском языке пакет работ будет work package.
Итогом каждого пакета работ является результат или продукт. Поэтому РП говорит - вы заплатите 800 тысяч и будете ждать 3 месяца, и получите отремонтированную квартиру.
Запомните: результат проекта реализует цель и отвечает на интерес стейкхолдера. Стейкхолдеру не интересны работы проекта, ему важен результат. Не важно как, важно что. А руководителю проекта важно как, потому что он отвечает за действия. Он должен сделать продукт, который ответит на интерес стейкхолдера. Это и есть главная проблема проектного управления и системной инженерии. Я называю ее “Водоразделом Заказчик-Исполнитель”. “Что” - это ведущий вопрос. “Как” - подчиненный. Проблема в том, что в проекте надо преобразовать “Что” в “Как”, и сделать это без потерь. Это просто решается при покупке телефона, преобразование “Что” в “Как” несложное. Но и здесь бывают ошибки. Но у телефона всего один стейкхолдер - это сам покупатель, он же пользователь. А теперь представьте приобретение аэропорта. Сколько у него стейкхолдеров? Сколько целей? Сколько всего надо сделать, чтобы его построить?
Чем больше система, тем больше водораздел Заказчик-Исполнитель.
Что:
Продукт проекта
Как:
Структурная декомпозиция работ (СДР)
Дальше я объясняю механизм появления проблемы. А потом перейду к тому, какие три вещи делают, чтобы ее решить.
Вам надо перейти через водораздел "Что" - "Как".
Из Максима Дорофеева
Другими словами, надо спланировать проект.
Как планируют проекты
Шаг 1. Определить различие (AS IS-TO BE gap analysis)
Шаг 2. Составить описание проекта (project scope definition)
Шаг 3. Определить технологию выполнения работ
Шаг 4. Оценить объем работ и составить календарный график
Шаг 5. Оценить бюджет
Шаг 6. Согласовать план с Заказчиком
Шаг 1. Определить различие
Вам нужно сесть со стейкхолдером и описать его текущую ситуацию и конечный результат. Разница между ними называется "Различие" (gap или AS IS-TO BE gap). В нашем примере Различие = отремонтированная квартира - квартира до ремонта. В диаграмме квартира до ремонта и после ремонта называются "Рабочим продуктом". Рабочий продукт или артефакт - это результат труда человека. Есть природные объекты и есть артефакты. Песок - это природный объект, а цемент и построенный дом - это артефакты или рабочие продукты. Вся документация по проекту тоже является рабочим продуктом.
Рабочие продукты проекта ремонта:
- отремонтированная квартира
- дизайн-проект
- смета ремонта
- СДР (я объясню позже)
Шаг 2. Составить описание проекта
Когда вы понимаете, в чем разница между тем, что есть и тем, что вы хотите, вы можете сделать описание проекта (scope definition). Описание проекта всегда составляется на конечный результат.
Но мы помним про нашу проблему - водораздел. Поэтому нам надо вначале ответить на вопрос "Что", описать саму новую квартиру. Мы можем описать ее в разговоре, записать в тетрадку, а можем создать рабочий продукт "Дизайн-проект". Заказчик одобрит его нам перед началом проекта.
Шаг 3. Определить технологию выполнения работ
В этот момент начинаются первые проблемы. Разберем, кто такой "Исполнитель". Для проекта ремонта это строительная бригада. Она состоит из людей, которые делают работу, и бригадира. Бригадир организует работы и надзирает за их исполнением.
Но даже 6,000 лет назад люди пользовались инструментами и методами работ. Пирамиды строили с помощью веревочных блоков, колесных опор и коллективной тяги, а сейчас есть много разных инструментов:
Если у людей нет инструментов или они не умеют ими пользоваться, то работы не будут выполнены.
“Шварценеггер купил однажды бензопилу,а через неделю приходит с
ней обратно в магазин и говорит: - Вот тут на ней написано,что
можно срубить 300 деревьев. А я срубил только сто - и она
сломалась. Продавец ему говорит: - А вы правильный бензин
заливали? Шварценеггер: - А разве сюда еще надо бензин заливать?”
Технологии - это продолжение команды, ее физическая часть.
Нет технологий - нет команды, нет работ.
Пример из жизни
Однажды я делал ремонт. Сделал его быстрее за месяц и дешевле на 150 тысяч, чем сравнимые ремонты знакомых. Никто не верил. А причина успеха была очень простой - и бригадир и главный рабочий учились в строительных техникумах и знали технологии строительства. Спасибо, Захир!
Другими словами, они не просто умели замешивать раствор или резать плитку, они знали теорию технологии. Теоретические основы технологии называются дисциплиной.
Пример из жизни
Разговариваю с инвестиционным аналитиком. Обсуждаем проект, я начинаю говорить о дисконтированных денежных потоках и активах. Он мне тут же отвечает: “Сразу видно, что ты только книжки читал, в жизни всех этих дисконтированных потоков нет, они только в учебниках”. Я тут же перехожу в предметную область и повторяю мысль, используя другую терминологию. Мы быстро завершаем расчет модели.
Вывод - дисциплина позволяет переносить опыт между ситуациями, для этого используются абстрактные понятия. Дисциплина позволяет быстро переходить от одной технологии к другой, т.к. вы работаете с теми же абстракциями (терминами предметной области).
Технологии выражаются через рабочие продукты.
Пример из жизни
Строительный подрядчик №1 строит дома из готовых блоков
Строительный подрядчик №2 строит каркасные дома
Сами дома и документация на них у этих подрядчиков сильно отличаются. Но мы уже говорили, что документация и дом - это примеры рабочих продуктов. Разные технологии - разные артефакты.
Вопрос - могут ли рабочие первого подрядчика построить дома по технологии второго?
Ответ - квалифицированные рабочие смогут, неквалифицированные не смогут. Квалификация - это владение предметной областью, дисциплиной.
Команда состоит из людей и технологий.
Технологии поддерживаются дисциплиной.
Дисциплина в голове у команды.
Абстракции нашей жизни и рабочие продукты:
Право проезда на общественном транспорте - Проездной “Тройка” (технология турникетов и считывателей), билет на автобус (технология офсетной печати и контролеров), “до перекрестка за десятку докинешь?” (технология устных соглашений)
Документ, удостоверяющий личность - Паспорт РФ, загранпаспорт, “За 500 договоримся?”
Этот текст объясняет понятия дисциплины системного подхода.
Шаг 4. Оценить объем работ и составить календарный график
Команда знает технологию, которую будет использовать в проекте. Они берут описание результата проекта, и оценивают объем и график работ.
Или, переходя на язык выбранной технологии:
Абстракции из дисциплины управления проектами (1) - Рабочие продукты выбранной технологии (2)
Описание новой квартиры (1) - дизайн-проект + уточнения в разговоре с заказчиком (2)
Объем и график работ (1) - смета ремонта, структурная декомпозиция работ (СДР), календарный план-график (2)
“Бригада смотрит на дизайн-проект, уточняет вопросы с заказчиком, и готовит план-график, смету ремонта и структурную декомпозицию работ” (описание конкретной технологии) = “Команда знает технологию, которую будет использовать в проекте. Они берут описание результата проекта, и оценивают объем и график работ.” (дисциплинарное описание, применимо ко множеству технологий)
Дисциплина одна - технологий множество.
Помните СДР детского центра?
Конкретная команда строителей подготовила календарный план работ
План работ показывает развертку технологии во времени.
Если бы центр строили эти ребята:
сроки были бы другими.
Разные технологии - разные планы работ.
Разные дисциплины в основе технологий.
Шаг 5. Оценить бюджет
Аналогично шагу 4.
Шаг 6. Согласовать план с Заказчиком
Берем рабочие продукты процесса планирования - смета, СДР, план-график, и идем к заказчику. Он достает рабочий продукт дизайн-проект и мы начинаем сверяться. Заказчик смотрит в дизайн-проект и спрашивает “А где у вас люстра?”, исполнитель показывает на работы по подвесу люстры, их длительность и стоимость. И так по каждому пункту. Если заказчика устраивает объем и график работ и стоимость, он начинает платить за работы и проект начинается. В диаграмме это показано событием “Заказчик начал платить за работу”.
Сила здравого смысла: запуск проекта - это когда заказчик начал платить исполнителям. Половина сертифицированных руководителей проектов не понимают этого простого факта. Вы уже умнее их.
После начала оплат бригада начинает выполнять работы, используя технологию ремонта. Бригадир следит и управляет ходом работ, используя утвержденный план-график и бюджет. По завершении работ заказчик принимает результат, сверяя его с дизайн-проектом.
Этот подход такой простой, что им пользуются уже 6,000 лет. Египетские пирамиды у нас уже были, а из последних проектов можно вспомнить “Зенит Арену”:
С небольшими добавлениями эта методика используется во всех остальных госпроектах РФ. Рассказывает Андрей Кувшинов, начальник центра управления проектами Высшей школы управления, ставивший проектное управление в правительстве Белгородской области:
Но у этого подхода есть проблема.
Часть 2. От чего в проектах завелись системные инженеры?
Проблема и решение. Возникали ситуации, когда деньги кончались до завершения работ. Смета была неверной. Заказчики захотели иметь механизмы контроля проекта и предсказания его исхода. Родилось первое поколение проектного управления, в нем появились контрольные точки и сетевой график. В основе этих технологий управления лежали дисциплины теории расписаний и расчет критического пути.
Следствие. Для контроля проекта у заказчика должна была появиться нужная экспертиза. Так на проектах появились два руководителя - один со стороны заказчика, другой со стороны исполнителя. Теперь интересы заказчика в проекте представлял РП и он надзирал за работами проекта. Он разбирался в технологии, потому что сам был инженером. Почти все руководители проектов в 1910-1970 вышли из инженерной профессии. Эта сложная схема управления привела еще к одному важному следствию. До этого проектами управляли инженеры, которые проектировали систему и затем ее же делали. Ответственность вся была исключительно на них. Но невозможно было создавать сложную управленческую документацию и отчетность и одновременно строить. В проектах появились главные инженеры. Они отвечали за проектирование системы. Они понимали, как она работает до последнего винтика. Руководители проекта понимали на один уровень вниз, на уровне основных технических решений, обоснований выбора конструкций и оценок по пакетам работ. РП со стороны заказчика отвечал за то, что с выбранным техническим решением заказчик достигал поставленной цели.
Модульная сборка. В время промышленной революции была изобретена модульная сборка. Она резко сократила время и стоимость производства систем. Модуль - это часть системы, выполняющая фиксированную функцию. У модуля есть стандартный интерфейс, которым модуль подсоединяется к системе. Модули (и их интерфейсы) это:
Блоки Лего (посадочные места), мышка (разъем USB и драйвер), чашка (ручка и дно), винты, болты (резьба).
Проектное управление по версии раннего Керцнера
Эта организация работ с небольшими вариациями сохранялась до 1960-х годов, пока НАСА не открыло программу “Аполлон”.
Проблема высадки на Луну была в том, что не существовало в мире инженера, который бы смог удержать в голове ракету с возвращаемым лунным модулем. Это было слишком сложно. Был использован системный подход 1.0, с объективно определяемой системой.
Системный подход 1.0 состоял из трех частей:
- Раздельное рассмотрение системы как “черного ящика” и “прозрачного/белого ящика”
- Рассмотрение системы как части другой системы (надсистемы)
- Использование жизненного цикла
- Междисциплинарный подход
Совместное использование всех четырех принципов мышления позволило Колоссу Человеческому сделать гигантский скачок.
“Великие” советские инженеры
Представьте, что надо сделать не ремонт в квартире, а построить завод. И оснастить его оборудованием. Выстроить логистику и сбыт.
Человек, который будет уметь все это делать, будет стоить как чугунный мост. А посередине проекта, когда от него будет зависеть вообще все, как два чугунных моста. Вам некуда будет деваться. И если он больше не сможет работать над проектом, то то вы окажетесь с грудой дорогого ненужного железа. Представьте, что стало бы с советской космической программой, если бы Королева случайно стукнули чуть сильнее во время допроса?
Помните, я писал “почему Королев работал хуже Роберта Симэнса”? “Кто такой Симэнс?” - спросите вы. “Именно”, - отвечу я вам.
Кто главный конструктор айфона? Кто спроектировал ваш автомобиль или ноутбук? Это сделала команда системных инженеров. Без геройства, без надрыва, с 8 до 17 с перерывом на обед. В срок, в бюджет, с нужным уровнем качества. Это технология, а не искусство. В этом величие Симэнса, он часть Колосса Человеческого. А Королев свои знания не передал.
Системный подход 1.0
Черный ящик - прозрачный ящик
На эту идею инженеров навели взаимозаменяемые детали, модули. Если детали и узлы механизмов можно менять и станок будет работать, это можно делать и с целыми системами. Надо очертить границы подсистемы и определить интерфейсы. Тогда можно выделить работы по проектированию и производству подсистемы от других работ проекта.
Типовые интерфейсы телефона. Мы не знаем, как он устроен внутри, главное, что он поддерживает нужные интерфейсы.
На практике выглядит так:
- Системный инженер, занимающийся производственной линией, договаривается с системным инженером завода, что линия займет 120 метров в длину, 30 в ширину, 5 в высоту. Ей нужно будет 130 кВт мощности, загрузка сырья со склада по траволатору 2 метра со скоростью 1 м/с, выгрузка в стандартных палетах. И в рамках этих договоренностей оба инженера могут решать свои задачи. Для инженера завода производственная линия - черный ящик, он не заходит за интерфейс, ему все равно, что происходит в проекте разработки, производства и монтажа этой линии, если соблюдается контракт на интерфейсе модуля.
- Системный инженер производственной линии собирает ее из единиц оборудования и приспособлений. Он разрабатывает под них интерфейсы и определяет границы каждой подсистемы и модуля. И ему все равно, как работает шнековый механизм выбранного станка, если он отвечает интерфейсам.
При этом подразумевается раздельное рассмотрение системы как функции и как конструкции. Когда систему рассматривают как черный ящик, то не думают, как она устроена. Интересуются только тем, как она себя ведет, ее функцией. Когда определились с функцией, переходят к рассмотрению прозрачного ящика. Это означает, что инженер думает над тем, как может быть устроена система, которая реализует назначенную на нее функцию.
Так в инженерной работе появились компоненты, модули и размещения.
Пример из жизни:
Функциональная (компонентная схема) системы метрополитена
Функциональная схема показывает как работает система. Это рассмотрение со стороны заказчика. Мне, как пользователю, все равно, односводчатые там станции или колонно-стеновые, глубокого они заложения или мелкого, какая модель щита использовалась при прокладке туннеля. Меня интересует, какие функции она выполняет - с какой станции куда она перевезет, где я смогу пересесть на другую линию.
Но все эти подробности становятся очень важны для инженеров и руководителей проектов, потому что им надо построить метрополитен. Им важно как.
Мы говорим и про функцию системы и про ее конструкцию и понимаем, что говорим об одном объекте - метрополитене. Это объективный системный подход.
Разбиение системы на компоненты позволяет заказчику объяснить, что ему надо. Что для него означает функция “перевозка пассажиров”? Сколько пассажиров должен перевозить метрополитен, куда, где возможны пересадки, все это можно понять из функциональной схемы и компонентного разбиения.
Функциональная схема состоит из компонент (функциональных элементов) и портов, через которые компоненты соединяются друг с другом. Например, в метрополитене станции и перегоны - это компоненты, они выполняют назначенные на них функции. На станциях можно зайти и выйти из метрополитена, а по перегонам можно доехать от одной станции к другой. А переходы между станциями - это порты, по ним компоненты соединяются друг с другом. Когда мы рассматриваем функциональную схему системы, нам все равно, как она устроена. Я не знаю, глубокого залегания тоннель между станциями или мелкого, и представления не имею, использован ли в переходе траволатор или надо идти пешком. Меня интересует функциональное описание.
Другой пример порта - транспортный узел между двумя проспектами. Конструктивно он может быть реализован нерегулируемым перекрестком, регулируемым перекрестком, эстакадой, развязкой, все зависит от того, какие системные требования (см. дальше) были поставлены, и какие технологии есть у Исполнителя.
Функциональное описание “как работает система как черный ящик” называется системными требованиями. Например, системными требованиями метрополитена будут:
- Метрополитен должен обеспечивать перевозку между всеми своими станциями
- Метрополитен должен перевозить пассажиров со средней скоростью не ниже 40 км/ч
- Метрополитен должен перевозить пассажиров с 5 утра до 1 часа ночи
- Переход между станциями не должен быть длиннее 500 метров
Инженеры и менеджеры, получив системные требования, смогут разработать техническое решение, которое их реализует. И они скажут, что колея должна быть 1650 мм, тяговый двигатель поезда должен быть асинхронный с мощностью 650 кВт, а переход будет без эскалаторов. Другими словами, на базе системных требований и функционального разбиения они составят модульное описание.
Модульное и функциональное описание позволило преодолеть водораздел Заказчик-Исполнитель. Заказчик работал с функциональным разбиением и системными требованиями, а Исполнитель с модульным описанием. И они убеждались, что говорят об одном объекте.
Системный подход иерархичен, поэтому метрополитен разбивался на линии, и линии тоже разбивались на компоненты и модули, до тех пор, пока с данным конкретным компонентом и модулем не могли работать люди. Проблема со сложностью была решена, и программа Аполлон успешно реализована. Люди научились строить сколь угодно сложные системы, просто рассматривая функции и конструкцию, в которой компоненты были соединены портами, а модули интерфейсами. Связь между Заказчиком и Исполнителем была через требования. Если система отвечала требованиям, значит, она выполняла функции и была успешной. Эта связь между Заказчиком и Исполнителем показывается через V-модель:
Слева функциональное рассмотрение системы (сторона Заказчика, что),
справа модульное (сторона Исполнителя, как).
Связь между ними идет через процесс проверки и утверждения.
Чуть позже появились еще понятие архитектуры и платформы системы.
Понятие платформы системы.
Возьмем кубики Лего https://shop.lego.com/en-US/Themes
В рамках одной темы они полностью совместимы между собой и вы можете собирать из них что угодно, и не беспокоиться, подойдут ли модули один к другому. Это позволяет сосредоточиться на замысле того, что вы строите, и не думать о подгонке строительных блоков. В терминах системной инженерии эта совместимость обеспечивается платформой. Платформа состоит из типовых модулей и типовых интерфейсов между этими модулями. В случае с Лего строительные блоки будут модулями, а посадочные места - интерфейсами.
Для автомобиля платформа и интерфейсы будут уже сложнее, но принцип сохраняется:
Платформа
Интерфейсы
Архитектура - это ключевые технические решения в вашей системе. Например, чтобы выполнить требование “Метрополитен должен перевозить пассажиров со средней скоростью не ниже 40 км/ч” было выбрано техническое решение сделать железнодорожную линию подземной, чтобы не пересекаться с наземными транспортными потоками.
Жизненный цикл 1.0
Аэропорт Шарль де Голя не работает из-за сбоя Windows 3.1, а 70-летний инженер программы Вояджер-1 учит молодежь Фортрану. Это результаты плохой работы с жизненным циклом продукта. Тот самый здравый смысл. Понятно, что аэропорт переживет Windows 3.1, а Фортран устареет раньше, чем Вояджер долетит до межзвездной среды (вам она знакома по фильму Interstellar).
Модели жизненных циклов
Жизненный цикл - это механизм мышления, который позволяет подумать о том, что произойдет с системой во время ее проектирования, производства, использования и обслуживания, а также как ее будут заменять на другую, более современную. Жизненный цикл состоит из стадий. Стадия показывает значительное изменение системы или ее окружения. Например, разработка технического проекта, строительство, эксплуатация - это все различные стадии системы.
Пример: в системе метрополитена предусмотрены технические депо для обслуживания и ремонта поездов. Если бы инженеры не подумали о стадии обслуживания, то поезда бы ломались и оставались внутри тоннелей. Подумайте, а как будет выводиться из эксплуатации метрополитен? Что с ним произойдет?
Междисциплинарный подход
Каждая система и подсистема разрабатывалась командой специалистов разных областей.
Междисциплинарный подход
Если вы знаете про “межфункциональные группы” или “кросс-функциональное взаимодействие”, то вы встречались с этой вещью на практике. Идея в том, что разные специалисты видят проблему с разных сторон. Такой комплексный подход помогает быстрее находить технические решения и допускать меньше ошибок проектирования.
Междисциплинарный подход больше всего помогает при совмещении функции и конструкции подсистемы. Помните, что вначале мы рассматривали систему как черный ящик, и думали, что она будет делать? А потом придумывали, как она может быть устроена внутри? Команда специалистов из смежных областей видит больше возможностей решить эту задачу, чем однородная группа экспертов.
Порядок бьет класс. Классный порядок бьет все.
На рисунке “Междисциплинарный подход” впервые появляется системное лидерство. Видите пункт “Набор, организация, направление людей”? Это первая версия управления жизненным циклом человеческого капитала.
Корпорация 90-х годов.
Управление проектами по версии Милошевича и позднего Керцнера.
Этот подход продержался до начала 2000-х, а в госпроектах развитых стран используется и сейчас. На этой схеме видны классические “ракетные шахты” (silos) отдельных функций. Это разделение труда позволило создать эффективные структуры и накопить лучшие практики по каждой из областей. Это была эпоха расцвета офисов управления проектами (РМО), гонки за качество и прекрасное время для разработчиков стандартов. Время Матрицы.
Лучшее время человечества по версии агента Смита
Но в бюрократические структуры АНСИ, ИСО и АйИИИ проникли программные инженеры и ученые. И создали свои стандарты.
Это было начало конца системной инженерии 1.0.
Время объективно определяемых систем закончилось с приходом инноваций. Тысячелетия ничего принципиально нового не появлялось. Поезд - это большая телега, автомобиль - это быстрая телега, которая не устает и ей не нужны рельсы, телеграф - это письма по проводам, а сотовый телефон - это гибрид рации и телефона. Это все были усовершенствования.
Но пришел век персональных компьютеров с операционными системами и пользовательскими приложениями. Посмотрите на свой телефон. Какой аналог из 17 века у него есть? Никакого, это целый мир новых возможностей в вашем кармане. Настоящая инновация, как электричество. Если вы захотите разработать телефон, то как договориться с исполнителем? На что разработать системные требования? Такого объекта не существует, это же инновация, помните. И инженерам пришлось искать решения, как управлять проектами по созданию вещей, которых раньше не было.
Но пришел век персональных компьютеров с операционными системами и пользовательскими приложениями. Посмотрите на свой телефон. Какой аналог из 17 века у него есть? Никакого, это целый мир новых возможностей в вашем кармане. Настоящая инновация, как электричество. Если вы захотите разработать телефон, то как договориться с исполнителем? На что разработать системные требования? Такого объекта не существует, это же инновация, помните. И инженерам пришлось искать решения, как управлять проектами по созданию вещей, которых раньше не было.
Решение нашлось у философов и онтологов. В системный подход пришли функциональные объекты, стейкхолдеры как роли, субъективно определяемые системы и 4Д-онтологии. И вот что получилось.
Часть 3. Системный подход 2.0
- Время как четвертое измерение и почему танец - это тоже ракета
- Как инженеры стали делать работу маркетологов и изменили маркетинг навсегда
- Параллельная инженерия, спиральный жизненный цикл и секретное знание PMBOK Guide
Повторяем пройденный материал:
Когда говорят, что системный подход борется со сложностью, говорят о разбиении продукта и работ, мы говорили о них в проекте ремонты квартиры.
Единственный способ понять сложную вещь - сделать разбиение продукта и работ.
Разбиение должно иметь смысл, т.е., Заказчик понимает, что ему делают, а Исполнитель понимает, какие работы по каким технологиям нужны. (1)
Разбиение должно быть адекватным, т.е., их можно собрать обратно в целостную картинку. (2)
В первом поколении управления проектами делали разбиение продукта проекта (product breakdown structure) и разбиение работ (work breakdown structure).
Кому интересно: термины work breakdown structure и work package пришли от юристов. Когда начинался процесс, они делили (breakdown) документацию по коробкам. Коробка называлась work package, и отдавалась участнику.
Пакет работ
Проверка соответствия работ продукту проводилась отдельно в голове Заказчика и Исполнителя. Если каждый доволен, то все в порядке. Хорошо работает, если оба человека понимают чего хотят и разбираются в предметной области и технологии производства.
Системный подход 1.0 в добавление к этому дополнительно разбивает систему еще на две части - компонентное (функциональное) и модульное (конструктивное). Теперь заказчик вначале пишет, как он хочет, чтобы система работала. Он пишет системные требования, и на этой стадии ему все равно, с помощью каких технологий будет построена система. Ему важно то, что она делает. Когда мы покупаем телефон нам важно, чтобы он хорошо звонил и делал приличные фотографии. Все эти мегапиксели и 5G не имеют смысла, если телефон не выполняет основную функцию. А исполнитель на основании этих требований составляет вначале принципиальную схему, которая показывает, как эти функции работают вместе:
Функциональная схема телефона. Так он в принципе работает. Компоненты (блоки) и порты (стрелочки).
Если клиента все устраивает, то инженеры придумывают, как он будет будет устроен, из каких модулей его сделать:
Модульная схема. Не очень похоже на функциональную, согласны? Сложно понять, как работает, если ты не инженер. Модули (коробочки) и интерфейсы (стрелочки).
Модульное представление позволяет разделить работы между рабочими группами проекта. Одни делают модуль приемо-передатчика, другие RISC-процессор. А потом все собирается через интерфейсы, о которых договорились заранее, на самом старте. И все работает.
Модульное представление позволяет из одного большого проекта, который не помещается в голове одного человека, сделать 17 маленьких, каждый из которых можно понять.
Связь между модульным и компонентным представлением происходит через системные требования. Системные требования можно:
а) Проверить (верифицировать). Убедиться, что модульное представление полностью реализует все функции, прописанные в компонентном. Система сделана правильно
б) Принять (валидировать). Убедиться, что система позволяет заказчику достичь поставленной цели, ответить на его интерес. Сделана правильная система.
История из жизни:
Иногда надо объяснить людям, что такое требования, качество, валидация и верификация. Цитировать ИСО или какой другой стандарт бесполезно, они написаны так, чтобы никто ничего не понял. Никогда, а то работу отнимут. Я обычно рассказываю эту историю.
Я работал в автомобилестроении, ездил по делам в Тольятти, к поставщикам автокомпонентов. Часто общался с директорами и владельцами. Происхождение 90% из них в Тольятти понятное - цеховики и бандиты, с соответствующими нравами и вкусами. Один из них рассказал, как он Гелендеваген Брабус покупал. Долго сидел в мастерской, разговаривал со специалистами, ездил на тест-драйвы, подбирал комплектацию по десятку каталогов, пока не получил машину своей мечты. Проехался по Боторпу, по автобанам, все его устроило, привез домой. И тут обнаружился один неприятный момент - на тот момент, в начале 2000-х, в Тольятти не было заправок с подходящим для этой машины топливом. Так и пришлось ему еще и заправку строить. Потом туда и другие авто уважаемых людей стали ездить заправляться, и он сделал на этом небольшой бизнес.
Когда заказчик подбирал комплектацию автомобиля, он разрабатывал системные требования. Затем ему по этим системным требованиям произвели автомобиль и он произвел проверку - поездил на ней и попробовал все функции. Все работает, система проверку прошла. А потом привез ее домой и выяснил, что цель не выполнена, интерес остался неудовлетворенным.
Успешная верификация не равна успешной валидации
В этом и есть главное отличие системного подхода 2.0. Заказчикам надоела ситуация, когда все сделали по требованиям, но ездить на этом невозможно. Они стали:
- Определять системы субъективно, для этого ввели стейкхолдеров как позиции в деятельности
- Перешли от водопадной модели жизненного цикла с последовательной проверкой и приемкой к спиральной модели. Это тот самый Эджайл
- Заставили разрабатывать архитектуру системы до начала модульного синтеза
Время как четвертое измерение и почему танец - это тоже ракета
Отвлекитесь на секунду и подумайте, а как наличие времени позволяет сделать еще одно разбиение? Упростить задачу мы можем только разбивая ее на меньшие куски, как тут поможет время?
История (нереальная): представьте, что друг взял у вас машину. Представьте, что у вас есть специальный сканер, в который вы эту машину засунули перед тем как отдать ее другу. И этот сканер запомнил расположение всех атомов в вашей машине. Друг уехал покататься и через пару дней вернул вам две машины
Какая из них ваша?
Вы скрещиваете пальцы и засовываете целую машину в сканер. Ее отпечаток полностью совпадает с начальным образом. Значит, это ваш автомобиль?
Тут друг достает видеозапись, в которой есть каждая секунда после того, как он взял у вас автомобиль. И на ней вы видите, что это именно ваша машина разбита в лепешку. Итак, вопрос, какой автомобиль ваш? Конечно тот, который вдребезги разбит. Непрерывность существования - это главный признак объекта.
Космонавт в 35 и пятилетний ребенок - это один объект.
Он существует непрерывно в пространстве-времени.
Мы все привыкли говорить, что время - это четвертое измерение.
Но если вдуматься в эту фразу, она приводит к очень странным выводам.
Возьмем, например, бутерброд.
Мы можем разрезать бутерброд вдоль, поперек, по диагонали. Это будут пространственные части бутерброда. Но если мы говорим, что бутерброд существует во времени, то будут еще и временные части бутерброда! Они называются темпоральными частями. И темпоральные части бутерброда подчиняются той же логике, что и пространственные.
Темпоральные части автомобилей
Темпоральные части человека
Системы существуют в пространстве-времени.
Еще говорят, что системы занимают 4Д-экстент.
Подробнее про 4Д-экстенсионализм и объектную онтологию можно почитать только на английском, но одну мысль стоит запомнить.
Если человек - это такой временной червяк, и инструменты с технологиями, которые он использует - это тоже временные червяки, то получается очень интересная вещь.
Мы можем рассматривать человека с инструментами (а это команда, мы помним) в 4Д пространстве. И его работа - это тоже будет такой временной червяк, состоящий из двух червяков - самого человека и инструментов. Поэтому любая задача, которую вы делаете - это временной червяк.
Ваш список задач - это куча временных червяков:
Когда вы выполняете задачи из списка, физически вы становитесь 4Д-экстентом системы “человек+технология (инструменты)”. Каждая задача - это червяк, состоящий из пересечений 4Д-экстента человека и его инструментов. Странная, но очень полезная мысль.
Углубленное объяснение:
Почему танец - это такая же система, как ракета, а фигуры танца - такие же подсистемы, как двигатель и корпус?
Проект, бизнес-процесс и любая деятельность вообще - это такой же 4Д-экстент, как и автомобиль, и его можно рассматривать как систему.
Он состоит из модулей, у него есть функции, к нему можно предъявлять требования.
Так появились обеспечивающие системы.
Бизнес-процесс автомобильной перевозки пассажиров. 4Д-экстент. Модуль с интерфейсом пользователя “салон автомобиля, руль, педали, кресла, двери”. Интерфейс для надсистемы - габариты автомобиля, фары, тормозные и ходовые огни, колеса. Сервис модуля - доставка пассажиров и грузов с определенной скоростью и уровнем комфорта. К модулю предъявляются требования по безопасности, стоимости и удобству использования. Модуль реализует бизнес-функцию (деятельность) “Перевозка пассажиров и транспортировка грузов”. У модуля есть стейкхолдеры “Пользователь” и “Владелец”.
Для любителей поразмышлять - рассказ, по которому был снят фильмы “Прибытие”. О природе языка, времени и принципе Ферма.
Деятельность (бизнес-функция) - это компонент. Деятельность устроена функционально, например, если мы говорим о финансовом менеджменте, то без разницы в чем мы работаем - в SAP FICO или 1С: Предприятие. И там и там мы можем наладить финансовый учет, планирование и контроль, пользуясь одной дисциплиной финансового менеджмента.
Функциональное устройство деятельности легко показать. Я ни разу не видел, чтобы в штатном расписании стояли “Финансист SAP” или “Бухгалтер 1С”. Ну, или “Проектный менеджер Oracle BPMS 12c”. Подразумевается, что если владеешь деятельностью, то конкретную технологию всегда изучишь. Исполнители должны быть компетентны.
Чтобы не путать деятельность как компонент с “компонентами системы”, ее называют специальным термином - практикой. Практика основывается на дисциплине, это означает, что прежде чем планировать бюджет, надо почитать учебник “Финансы предприятия”. Поэтому, если вам надо освоить новую деятельность, почитайте вначале учебник, а не бросайтесь сразу делать работу.
Практика реализуется технологией. Например, финансовый менеджмент может быть реализован технологией МСФО, GAAP, РСБУ, а может и бюджетированием с нулевой базой.
Вспомним, что технологии развертываются во времени, то есть инструменты применяют в какой-то последовательности, и получится, что работы - это модули деятельности, модули практики. Или рабочие продукты практики, ведь процессы делают люди, они не природного происхождения. Практика строительства загородного дома может быть реализована различным набором модулей деятельности (рабочих продуктов).
Рабочие продукты или модули практики
Есть три вида модулей, из которых состоит деятельность (практика) - это процедура (процесс), проект и дело.
Различие между процедурами, проектами и делами/поручениями:
Процедура - сервис определен, контракт на интерфейсах гарантирован, архитектура фиксирована. При совершенствовании процедуры меняется ее конструкция, но принципиальных изменений быть не может, т.к. контракт на интерфейсе фиксирован.
Например, оформление загранпаспорта. Контракт на интерфейсе фиксирован - вы должны принести строго определенный комплект документов и оплаченную квитанцию, и вам строго в пределах установленного срока выдают готовый паспорт или мотивированный отказ.
Стойка в МакДональдс - граница модуля “Процесс обслуживания клиентов”. На этой границе есть интерфейсы сервиса - вывески с блюдами и напитками, речевые акты коммуникации сотрудников с клиентами, оплата заказов, передача заказов. У сервиса есть контракт - стандарт клиентского обслуживания + прейскурант.
Проект - сервис обещан, контракт на интерфейсах обещан, постоянно уточняется, архитектура определена на старте, может меняться.
Например, строительство дома. Чтобы начать проект, вам нужен определенный комплект документации, но можно и неполный. Нужна определенная сумма, но она может плавать в обе стороны. Дом обещают сдать к определенному сроку, но и он тоже смещается. Общий план стройки (архитектура) есть, но как конкретно будут выполняться работы (детальная конструкция модулей) решается по месту, а не заранее.
Провал проекта - это неспособность обеспечить контракт на интерфейсе.
Провал проекта - это неспособность обеспечить контракт на интерфейсе.
Дело/поручение - интерфейсы на старте не определены, меняются в ходе выполнения. Сервисы представлены закрытым набором - дело может быть успешно закрыто, неуспешно закрыто, досрочно прекращено, повторно открыто.
Например, судебное расследование. Когда оно начинается, никто не может сказать, сколько времени оно займет, что будет в результате, с какими процессами и проектами оно будет взаимодействовать и как.
Подробнее про адаптивное управление поручениями здесь. Как запустить трекер у себя в компании здесь и здесь.
4Д-экстенсионализм позволяет единообразно, в терминах компонент, модулей, требований и архитектуры рассуждать обо всей деятельности:
Платформы
Платформа - это набор модулей с взаимодополняющими сервисами и совместимыми интерфейсами.
Пример:
Платформа торговой сети
Посмотрим, например, на такую системную иерархию. Системные иерархии называются холархиями, от слова холон, целый с греческого. Системный подход - целостный подход, отсюда и холархии. Водопроводная система является частью магазина. Магазин входит в торговую сеть и канал цепочки поставок. Распределительный центр входит в канал цепочки поставок и торговую сеть. Каждая из этих систем находится на своем системном уровне и у нее есть своя платформа
Платформа состоит из блоков Лего.
Из каких блоков собирается водопроводная система?
Водопроводная арматура (по ГОСТ Р 54808–2011, ГОСТ Р 53672-2009 и т.д.)
Сантехническое оборудование (ГОСТ 15167-93 и т.д.)
Совместимый по резьбе, давлению, нагрузкам и прочим характеристикам набор модулей называется платформой. Например, в проекте постройки магазина будет раздел технического проекта со списком рекомендуемой сантехнической арматуры и оборудования. Это платформа.
Аналогично магазин собирается из:
Типовых бетонных блоков и свай
Торгового оборудования
Матричного ассортимента
Платформа ограничивает выбранный системный уровень снизу. При проектировании и производстве системы мы не уходим ниже платформы. Не строим магазин из атомов.
Холархия ограничивает системный уровень сверху. Водопроводное оборудование - это не часть торговой сети, хотя формально это так. Но сказать “Оборудование входит в Галактику Млечный Путь” значит не сказать ничего содержательного. Выбор правильного системного уровня определяет полезность собранных к системе требований, я объясню это чуть дальше.
Платформа - это типовые строительные блоки системы. На уровне платформы вы останавливаете свое проектирование, и не идете ниже. Существование платформы - необходимое условие возможности создать систему. Пока не было микросхем, не было компьютеров.
Эмерджентность, редукционизм и системные уровни
Разобранный автомобиль
Когда использовать системный подход? Что такое система? Критерий прост - у системы есть эмерджентность. Поясню, что это такое.
Допустим, у нас есть две автомобильные покрышки. У них есть свойства - жесткость, упругость. Положим одну покрышку на другую. Появятся ли у этой стопки новые свойства? Нет, ее свойства сводимы к свойствам отдельных покрышек. Это не система.
Теперь возьмем покрышку и диск и соберем колесо. Появится ли новые свойства у сборки? Да, оно сможет ехать на скорости 220 км/ч, этого не может ни сам обод ни сама покрышка в отдельности. Свойства собранного колеса не сводятся к свойствам его модулей. Появление новых свойств, которые не выводимы их элементов и называется эмерджентностью. Системный подход применяется только к тем сборкам, у которых эмерджентность есть.
Эмерджентность определяет системные уровни, на каждом системном уровне появляются новые системные эффекты. Поищите примеры в жизни, они обязательно найдутся.
Обеспечивающие системы и жизненный цикл 2.0
4Д-экстенсионализм привел к очень интересному практическому следствию - системные принципы стало возможным применять к предприятиям. И вот что получилось.
Начнем с жизненного цикла бабочки:
Что заставляет ее переходить из одной стадии в другую? Внутренние процессы. Живые существа, в том числе и люди, двигают себя по жизненному циклу сами. Запомните это, мы вернемся к этой важнейшей идее, когда будем говорить про жизненный цикл участника команды.
Если привезти на стройку бетонные блоки, то сложатся они в здание завода сами? Нет, для строительства нужна квалифицированная команда, у которой есть технологии строительства и которая производит работы. Это тоже система, она называется обеспечивающей системой. А наша основная система, которую мы производим, называется целевой системой. Обеспечивающая система протаскивает целевую систему по стадиям жизненного цикла.
Например, есть дом, это целевая система. У него есть жизненный цикл, состоящий из стадий. На каждой стадии есть своя обеспечивающая система, которая переводит дом на следующую стадию. Например, если проектировщики не посчитают конструкцию, то строители не смогут купить нужные материалы и не могут ничего построить.
Целевая и обеспечивающие системы всегда рассматриваются совместно. Продукт и проект идут рука об руку. Системный подход дружит менеджеров с инженерами.
От процессов к практикам
В жизненном цикле 1.0 стадии определялись ведущей практикой. Была классическая водопадная модель. От замысла, через проектирование, в производство. Она, как и было сказано, не устраивала заказчика, ездить на этом Брабусе было нельзя, хотя документация была в полном порядке. Произошел переход к спиральным моделям жизненного цикла. В проектах появились итерации, каждая из которых использовала все практики (т.е., дисциплины и технологии).
Процессы - это практики. Применение технологий с использованием дисциплины. Конкретно под каждую ситуацию.
Практика реализована через задачи (модули).
Вернемся к системной схеме проекта:
Альфы (“рыбки”) на рисунке - это функциональные объекты, компоненты.
Они выражены модулями, рабочими продуктами или артефактами.
Допустим, определение системы (system definition, в оригинале SEMAT ‘Requirements’, “Требования”) выражается спецификацией системных требований.
Работы выражаются планом проекта, а технология конкретным оборудованием, программами, рабочими инструкциями.
Одна альфа обычно выражается 5-6 артефактами. Так, определение системы будет состоять из модульной архитектуры (схема конструкции сводов метрополитена), компонентной архитектуры (транспортная схема метрополитена), спецификации системных требований на тоннели, на пути и на поезда, спецификацией нефункциональных требований - по безопасности, устойчивости, восстановлению и т.д.
Мы разобрали области инженерного решения и предпринятия (endeavor, проект).
Остался клиент и с ним начинается самое веселье.
Стейкхолдеры как роли в деятельности. Второе крупнейшее заблуждение PMI (PMBOK Guide) и IIBA (BABOK).
Я разбирал отличие BABOK от системной инженерии в этом посте (текст для специалистов). Здесь я объясню ключевое отличие стейкхолдеров в BABOK/PMBOK и системном подходе.
РМВОК определяет стейкхолдеров просто:
“Заинтересованные стороны проекта – это лица или организации (например, заказчики, спонсоры)...”. Организации сами по себе не говорят, это делают их руководители, поэтому проще “стейкхолдеры - это конкретные люди”. Руководитель проекта должен найти всех конкретных людей, которые могут повлиять на проект.
Мы помним, что руководители проектов ориентированы на то, как сделать. Системным языком - они работают с модульными представлениями. Забота РП - обеспечить логистику. В одной точке должны сойтись 4М:
- Manpower. Люди, которые будут делать работу.
- Machines. Оборудование, на котором они это будут делать.
- Materials. Материалы для работы.
- Methods. Технологии, по которым эти материалы будут обрабатываться на оборудовании людьми, которые будут делать работу.
Проектная методология очень глубоко копает в эти 4М и выдает крайне детальные чек-листы для управления логистикой людей, технологий, материалов и методов. Примеры таких чек-листов для управления кризисными проектами. Примеры чек-листов для организации общения на проектах.
Для руководителя проекта проектная организация - это труба, через которую должен “протечь” необходимый объем работ. Объем проходящей через проект работы называется проходом (throughput).
Желтые столбики - это проход, производительность команды проекта. Ключевое понятие теории ограничений.
Поскольку 4Д-экстенты работ (темпоральные червяки) не видны невооруженным глазом, руководители проектов используют канбан, диаграммы Гантта и прочие методы визуализации модулей.
Канбан делает модули работ (задачи) видимыми:
Канбан - это модульное рассмотрение альфы “Работа”. У каждой задачи есть требования - это правила работы в проекте и требования к качеству выполнения конкретной задачи (QA). У каждой задачи есть сервис с контрактом - Definition of Done и оценка длительности. Задачи относятся к обеспечивающей системе и производят целевую. Задачи как модули работ могут быть сделаны в виде процессов, например, тестирование UX, а могут быть кейсами, когда непонятно, чем чем эта задача закончится.
Руководители проектов любят модули.
Проблема предварительного планирования (upfront planning) и стейкхолдеры-персонажи
Особенность предварительного планирования проекта в том, что люди на проект выделяются после составления плана. За хороших менеджеров и исполнителей всегда идет борьба.
Исполнителей дают только после утверждения базового плана, см. также порядок действий на проекте от Риты Малкахи
Это означает, что вначале им надо ввести каких-то абстрактных исполнителей, которые будут делать работу. А затем распланировать проект, исходя из способностей этих абстрактных исполнителей. Абстрактные исполнители = компоненты, функции. Затем на эти компоненты будут назначены конкретные люди = модули, конструкция.
Предварительное планирование основано на практиках. Пакет работ - это архитектура проекта. Модульная реализация появляется в ходе исполнения проекта, после назначения конкретных исполнителей.
Д. Милошевич показывает это так. Читается как “Руководитель проекта разбивает работы до тех пор, пока не появляется ответственный за практику внутри отдела. Результатом выполнения практики будет сервис/рабочий продукт”.
Там же. Модель жизненного цикла. Видим практики (деятельности), в которые вовлечен руководитель проекта - календарное и ресурсное планирование, контроль исполнения, управление рисками.
А вот как описывает это Р2М. Тут как функциональное (практики, используемые в организации), так и конструктивное рассмотрение (процедуры проекта).
Далее, во время исполнения практики РМВОК “Управление сроками”, СДР преобразуется в модульное описание (расписание операций/задач):
Системные уровни хорошо видны в проектах PRINCE2. Модуль верхнего уровня - проект, из проектов составляется программа. Проекты - это платформа программы. Проекты состоят из пакетов работ. Пакеты работ - платформа проекта. Пакеты работ собираются из контрольных точек и планов команды. На каждом следующем системном уровне происходит приемка, см. видео Софонова.
Модульная архитектура проекта из пакетов работ.
На всех этих примерах видна связь между структурой целевой и обеспечивающей системы. СДР идет от структуры продукта, см., например, стандарт министерства обороны MIL-STD-881C.
Связь конструкции продукта и организации работ на проекте:
Итак, руководители проектов заточены на логистическую работу с модулями, а для работы с компонентами у них есть специально обученные люди.
Бизнес-аналитики любят компоненты.
Практика бизнес-анализа. Выражена 50 технологиями.
Для анализа людей аналитик использует Stakeholders List, Map or Personas. Это инструменты функционального рассмотрения исполнителей. Цитата из ВАВОК 3.0:
“10.43 Stakeholder List, Map, or Personas
10.43.1 Purpose
Stakeholder lists, maps, and personas assist the business analyst in analyzing
stakeholders and their characteristics. This analysis is important in ensuring that
the business analyst identifies all possible sources of requirements and that the
stakeholder is fully understood so decisions made regarding stakeholder
engagement, collaboration, and communication are the best choices for the
stakeholder and for the success of the initiative.
10.43.2 Description
Stakeholder analysis involves identifying the stakeholders that may be affected by
a proposed initiative or that share a common business need. Stakeholder analysis
notes, considers, and analyzes the various characteristics of the identified
stakeholders.
Common types of stakeholder characteristics that are worth identifying and
analyzing include:
• level of authority within the domain of change and within the organization,
• attitudes toward or interest in the change being undertaken,
• attitudes toward the business analysis work and role, and
• level of decision-making authority.
For details on the work involved in conducting a thorough stakeholder analysis,
see Plan Stakeholder Engagement (p. 31).
When analyzing stakeholders, business analysts utilize one or more techniques to
draw out a list of stakeholders and analyze them. Stakeholder lists, maps, and
personas are three tools that can be utilized when conducting this work.”
По простому, аналитики либо ищут конкретных исполнителей (модули), просто делают это лучше руководителей проектов, либо, если нужно составить предварительный план (upfront plan), то составляют компонент (функцию), используя инструмент “Персонаж” (Personas). На русском не нашел, вот на английском, включите в Chrome перевод, можно понять, о чем идет речь.
Персонажи - наиболее распространенное представление стейкхолдеров в современном бизнес-анализе и проектном управлении. И с ними есть огромная проблема.
Выборочный перевод книги компании Интерком Jobs-to-be-Done с дополнениями и примечаниями
Сконцентрируйтесь на работе
Персонажи всегда будут использоваться. Если вы хотите создать
рекламу, которая привлекает 21-летних мужчин или 35-летних специалистов,
Персонажи помогут создать реалистичные представления вашей целевой аудитории.
Но если вы хотите создать отличный программный продукт, решения, построенные вокруг персональных характеристик не приведут вас никуда. Потому что продукты не создаются под людей, они создаются под проблемы.
Мы узнали, что результат, который человек хочет, гораздо важнее, чем
сам человек. Если вы знаете, что за компьютером сидит 37-летний это вряд ли что-то изменит в разработке вашего продукта.
Ориентируясь на работу и контекст клиентов, вы можете разрабатывать рыночные продукты, хорошо адаптированные к тому, что уже делают клиенты. Это то, чего сложные описания шести разных людей просто не могут достичь.
Персонажи - это инструмент для совместного использования общего видения целевого пользователя на проекте. Когда все знают, на каких конечных пользователей нацелен продукт, мы избавляемся от ненужных дебатов.
Персонаж показывает то, что вам нужно знать о типичном конечном пользователе, чтобы принимать обоснованные проектные решения. Есть несколько рекомендаций
о том, как лучше всего создавать, представлять и использовать их. Вот два важных из них:
Никакой ерунды. Каждое предложение в описании персон должно иметь последствия для дизайна. Например, если вы говорите, что пользователю 72 и он часто пишет смски, значит надо разрабатывать приложение под пользователей со слабым зрением, слабыми навыками работы с компьютерами и подумать над отсылкой смсок.
Создавать их вместе. Заинтересованные стороны проекта должны участвовать в
Исследованиях и анализе во время создания персонажей. Персонажи - это
результат куска работы. Как говорит Джаред Спаул, они похожи на праздник
открытки; они свидетельствуют о том, что путешествие было, но вы не можете купить
открытку и думать, что вы были в отпуске.
Персонажи хорошо работают, когда пользовательскую базу можно разбить на разные типы пользователей с разными потребностями.
Но когда вы создаете продукт, это не всегда так.
Когда персонажи ничего не дают
Некоторые продукты лучше определяются выполняемой ими работой, чем клиентами, которым они служат. Для некоторых продуктов клиенты не имеют между собой ничего общего. Они из разных стран, с разным опытом, с любой зарплатой и каким угодно опытом работы с компьютером. Единственное, что у них есть общего - это работа, которую они должны выполнить. В этих случаях надо очень близко ознакомиться с самой работой, зачем она нужна и кого бы вы наняли, чтобы ее сделать.
Клей Кристенсен, профессор Гарвардской бизнес-школы, описывает это
как маркетинг на основе работы. А вот выступление Виталия Король на эту тему. Кристенсен предлагает пример сети быстрого питания которая хочет продавать больше молочных коктейлей. Их первоначальный подход заключается в изучении клиентов на основе демографического анализа и психографических переменных. Это не привело к увеличению продаж. Анализ не дал содержательных результатов потребностей клиентов.
Тогда Клей предложил сосредоточиться на работе, на которую клиенты нанимают молочные коктейли. Это, конечно, звучит странно (никто не думает о «найме молочного коктейля»), но смена перспективы вызывает новые мысли.
Оказывается, более 40% молочных коктейлей были наняты ранним утром чтобы поддержать силы в течение длительного времени. Так что молочные коктейли конкурировали с рогаликами, бананами и энергетическими батончиками, а не с остальным меню завтрака. У молочных коктейлей были преимущества перед энергетическими батончиками и бананами - они не крошатся и их легче потребить в машине.
Они были лучше рогаликов - те были слишком сухие и усиливают жажду. И они побеждали кофе - сытнее и не заставляют вас искать туалет посреди сорокаминутной поездки. Как только сеть осознала это, они были они внесли изменения, которые сделали молочные коктейли лучшим инструментом для работы - удобной, легко употребляемой закуской, которая побеждала голод до обеда.
Сфокусируйтесь на работе
Вот некоторые работы, которые существуют вокруг нас в течение длительного времени:
- Доставить пакет из точки A в точку Б с гарантией и в срок.
- Держать всех в курсе проекта, над которым они работают.
- Сделать мне очную встречу с коллегой из другого города.
Работа может предложить долгосрочный взгляд. Юлий Цезарь часто должен был выполнять первую работу, и он нанял мужчин и лошадей, чтобы решить эту задачу. Сегодня у нас есть FedEx. Работа не изменилась.
Используя эту перспективу, вы можете выявить реальных конкурентов вашего продукта. Электронная почта является крупнейшим конкурентом MS Project PWA. Люди нанимают email несколько раз в день, чтобы держать коллег в курсе проекта.
Полеты эконом или бизнес классом являются подходящими кандидатами для третьей работы, хотя они просят очень разные зарплаты. Видеоконференции не такие способные, но готовы работать за гораздо меньшие деньги. У меня есть выбор кого нанять.
Мои замечания
То, что есть вакансия, на системной схеме проекта называется “Возможностью”. Стейкхолдеры обеспечивают возможности.
Поймите, кто ваши реальные конкуренты
Когда люди думают о своих конкурентах, они склонны смотреть на то, что поближе к их дому. Если я заведу магазина, который будет продавать нарезанную пиццу, а вы рядом открыли МакДональдс, мы ведь конкуренты, не так ли? Но реальная конкуренция обычно где-то на соседнем поле.
JTBD дает вам гораздо лучшую перспективу того, кто ваш настоящий конкурент. JTBD дает контекст ситуации потребления, который побуждает людей использовать продукты. Чтобы использовать приведенный выше пример, если я знаю, что мои клиенты выбирают пицца, потому что у них есть только пять минут, чтобы поесть пока они идут на встречу. Теперь я знаю, что мой конкурент - это не Макдональдс.
Я конкурирую со Сникерсом и хот-догами за углом.
Когда вы ослеплены поиском конкурентов, которые делают точно то же самое, что и вы, угроза разрушения бизнеса приходит из неожиданных мест. Газетная индустрия думала, что они в бизнесе продажи новостей, напечатанных на бумаге. Если бы они поняли, что их бизнес это развлечение людей или поддержание их в курсе, то заметили бы новых конкурентов, таких как мобильные игры, Twitter или Facebook.
Поэтому, когда вы думаете о конкурентах, лучше всего игнорировать категории продуктов и подумать о том, кто еще делает эту работу.
Иногда ваши клиенты действительно хотят использовать вашу фичу или продукт, но они также хотят чего-то еще, что просто несовместимо с ними. Люди реально хотят быть стройными и здоровыми, но они также очень хотят газировку и фаст-фуд.
McDonalds и Weight Watchers продают дико разные продукты, но они конкурируют за одних и тех же клиентов. Это то, что мы называем косвенной конкуренцией. Обратите внимание, что это отличается от конкуренции по результатам. Видеоконференции и полеты бизнес-классом конкурируют за результаты, поскольку они оба наняты на ту же работу - деловые встречи.
В косвенной конкуренции существуют две разные задачи, которые клиент хочет выполнить, но сами работы конкурируют друг с другом. Программы постоянно сталкиваются с такими типами конфликтов:
- «Я хочу разрешить платежи в своем продукте, но хочу свести к минимуму количество сторонних интеграций, на которые мы полагаемся»
- «Я хочу добавить этот инструмент аналитики, но я также хочу оптимизировать время ответа”
- «Я хочу знать, как моя команда проводит время, но и показать, что мы доверяем друг-другу”
Это может противоречить логике, но люди прекрасно справляются с поддержанием множества противоречивых мнений и желаний. Мы хотим быть красивыми, богатыми и есть что угодно.
Мои замечания. Продукт - это ваша целевая система. В своих проектах ищите того стейкхолдера, работу которого нанимается делать ваш продукт. Это будет верхний системный уровень. Он еще называется “системным окружением”. Помним, что любая работа - это 4Д экстент и к ней может использоваться системный подход.
Потребности стейкхолдера еще называются “требованиями стейкхолдера” либо “бизнес требованиями”. Вы разбираетесь с потребностями, и формируете системные требования, которые им соответствуют. А на базе системных требований формируете архитектуру:
Процесс итеративный, происходит много раз за проект.
Стейкхолдер определяется работой, которую он хочет сделать. Другими словами, своей целью.
Руководство по определению целевой системы. Что должно быть в содержании вашего проекта помимо самого продукта?
Почему клиенты переключаются на другой продукт?
Люди не то, чтобы ненавидят прогресс, они просто предпочитают инерцию. Это останавливает их от покупки вашего продукта, даже если эта покупка выглядит логичной.
Дело не в том, что им нравится управлять проектами по электронной почте, отслеживать расходы в файлах с названием «Расходы-март-2017-v3-финальная (2).xlsx», или вести протоколы собраний в Visual Studio. Для них просто не важен этот переход.
Понимаете, переход на другой продукт - это большое дело. Клиенты не покупают продукт, они переходят на него от чего-то другого. Большинство компаний пытаются переключить с помощью лучшего дизайна, лучшей производительности или большему количеству функций. (Т.е., речь идет о системных требованиях, примечание мое).
Это влияет только на качество вашей продукции, на одну часть головоломки.
Группа ReWired определила четыре силы в этой игре. Двое из них работают на вас и две против вас:
Вы можете посмотреть на эту диаграмму с точки зрения приобретения клиента - как мы можем заставить больше людей перейти на наш продукт? Или вы можете посмотреть на это с точки зрения удержания - как мы можем убедиться, что никто не переключается на другое?
Реклама позволяет вам манипулировать этими четырьмя силами. В частности, вы можете:
1. Увеличьте отталкивание: покажите, насколько плох их существующий продукт
2. Увеличьте привлекательность своего продукта: продвигайте идею того, насколько хорошо ваш продукт решает проблему
3. Снизить страх и неопределенность изменений: убедить потребителей, что переключение происходит быстро и просто.
4. Уменьшить их привязанность к статус-кво: устранить иррациональную привязанность потребителей к текущей ситуации.
Вы можете вспомнить рекламную кампанию Apple «Я Mac». В ней были показаны проблемы Windows (1), продемонстрировано, как крут Mac (2), показано, как легко было переключиться (3), те, кто не будет переключаться были представлены лопухами, уменьшая их привязанность (4) к старым привычкам.
Короче говоря, они создали беспокойство, которое можно было преодолеть только покупкой.
Где заканчивается одна работа и начинается другая (границы использующей системы, определение стейкхолдеров)
Компании-разработчики программного обеспечения всегда сталкиваются с вопросом о том, следует ли добавлять еще одну фичу. Ответ, к которому они обычно приходят - да! Когда ты умеешь создавать программы, вы хотите решить все проблемы в мире.
В Intercom мы научились ценить точку, в которой останавливаются работы нашего продукта. Если будете слишком тщательно следовать JTBD, то ваш продукт будет поддерживать клиента весь день. Нет, у китайцев это получилось, спору нет, но стоит ли пытаться повторить это? Вы можете начать разработку трекера, добавить выставление счетов, а затем начислять зарплату, и вот у вас есть идеальное решение для очень небольшого круга пользователей. Вы должны знать, где остановится ваш продукт.
Самое главное, что делает менеджер по продуктам, - это решает, где останавливается ваш продукт и за работу принимается кто-то другой.
Если ваш продукт делает слишком мало, то это не стоит затрат на установку, не говоря уже о цене покупки. Аналогично, если продукт делает слишком много, он столкнется с некоторыми другими ранее существующими программами или пользователями рабочего процесса, которые уже довольны текущей ситуацией.
Проблема Маши у медведей - вам нужно найти продукт, который будет ровно того размера, который нужен.
Понимание рабочего процесса вашего продукта
В качестве примера возьмем тайм-трекер. Минимальный набор функциональности для отслеживание отработанных часов - это просто сумма чисел по списку. Если это все, что может предложить программный продукт, он бесполезен. Excel или
Google Sheets уже выполняет эту работу. Именно в этот момент мы понимаем, что простота переоценена. Даже самый лучший дизайн интерфейса не может помочь продукту, который не стоит своих денег.
По максимуму такой продукт может включать управление проектами, бюджеты, подрядчиков, выставление счетов, отслеживание инвойсов и мониторинг сотрудников.
Такие приложения наступают на ноги уже существующих продуктов: Xero, Wrike, Basecamp, Teamwork.
Продукты существуют для решения проблем, возникающих в рабочем процессе. У них есть начальная и конечная точка внутри этого процесса. Чтобы понять, где должны быть эти точки, вы должны понимать весь рабочий процесс. Давайте разложим процесс “Команда заказывает обед каждый день”.
Если вы создаете приложение, помогающее командам заказывать обед каждый день, рабочий процесс может выглядеть так:
1. Кто-то проголодался.
2. Он общается с остальной частью команды.
3. Обсуждение о том, следует ли идти в ресторан или заказывать доставку.
4. Вторая дискуссия о том, где заказать.
5. Обсуждения меню разных ресторанов.
6. Принимается решение, быстро.
7. Один человек назначается для сбора заказов от каждого.
8. Затем этот человек заказывает.
9. Этот человек сообщает всем время доставки и стоимость.
10. Проходит время.
11.Привозят еду, и ее едят.
12. Заказчик проверяет, все ли заплатили правильно и кто все еще должен деньги.
13. Решаются вопросы оплаты или урегулирование откладывается до завтра.
14. Некоторые расскажут о еде в Twitter или Facebook. Некоторые будут публиковать
Фотографии на Instagram. Другие расскажут на Yelp.
15. Каждый возвращается к работе.
Когда вы понимаете полный рабочий процесс, вы можете сосредоточиться на самых небольших, но трудозатратных моментах, которые решает ваш продукт. Либо, как вариант, вы можете сделать процесс более интересным и захватывающим. Спросите себя - мой продукт - витамин или аспирин?
Когда остановиться?
Ваш бюджет, будь то время или деньги, должен ограничивать, но не определять содержание проекта. При большом бюджете следует определить, насколько хорошо решена проблема, но никогда не “сколько/как много проблем решено”. Попытка решить весь рабочий процесс от начала до конца для всех типов пользователей практически обречена на неудачу.
Ваш продукт должен остановиться когда следующий шаг:
- Имеет четко определенных лидеров рынка, которые держат его (например, Apple, Netflix, Expedia), и вы не собираетесь конкурировать с ними
- Выполняется множеством разных способов множеством различных типов пользователей (например, попытка считать зарплаты в приложении для отслеживания времени будет проблемной)
- Включает в себя отличных от первых шагов пользователей (например, менеджеры, бухгалтеры и т. д.)
- Это область, в которой вы не можете сделать ничего полезного.
Что стоит вынести из этого блока?
Система определяется субъективно, по ее функции в стадии использования.
Функция системы определяется стейкхолдером.
Пример из жизни: один знакомый построил танкер для перевозки химических веществ
Вспоминаем модели жизненного цикла:
Пять стадий (темпоральных частей) системы судна. Нас интересует только стадия использования - ship operation. Проект мы начинаем для того, чтобы перевозить химические вещества.
Хотя в этом проекте зарабатывают многие другие люди - ремонтные бригады зарабатывают в стадии обслуживания; проектировщики зарабатывают в стадии постройки и т.п., систему мы называем по стадии использования.
Мало какая часть РМВОК навредила управлению проектами так, как Глава 2 “Жизненный цикл проекта и организация”
Никакого жизненного цикла проекта нет. Есть модель жизненного цикла системы и есть воплощение жизненного цикла системы со стадией использования. Стадия использования - это темпоральная часть 4Д-экстента системы.
Стейкхолдеры, интересы, частные методы описаний, частные описания
ИСО42010, архитектурные описания.
Как разрабатывается архитектура, пример:
1. Начните с задания высокого уровня
2. Разбейте его на меньшие задачи
3. Наблюдайте за тем, как люди решают проблему сейчас (работа, которую они в настоящее время делают)
4. Придумайте job story, чтобы исследовать причины, беспокойство и мотивы того, что они делают сейчас.
5. Создайте решение, которое решит эту job story.
Например, рассмотрим, как команда может спроектировать представление профиля для продукта, который помогает продавцам автомобилей обеспечивать кредиты для клиентов.
Проектируем профиль клиента
В начале процесса проектирования команда обсуждала, как должен выглядеть профиль клиента, и какие там должны быть функции.
В какой-то момент Сара, член команды, встала и нарисовала на доске простую основу. Она указала на область в нем и сказала: «Это профиль продавца ".
Команду пришлось убеждать. Они спрашивали “Почему” по каждой части профиля. И даже после всех этих вопросов команда смогла ни согласиться ни отказаться от идеи.
Тогда возник вопрос:
«Почему продукт должен иметь профиль? Почему это должно быть в в том или ином месте? Какую информацию он должен отображать? Какие ситуации он решает? Какую работу выполняет этот профиль?"
Чтобы решить эту проблему, функция была переделана через Job Stories.
Начните с задания высокого уровня
Задача высокого уровня продукта - помочь продавцу автомобилей обеспечить кредит для перспективных клиентов. В настоящее время должны заполнить много сложных документов.
Разбейте его на меньшие задачи
Чтобы правильно заполнить заявку на получение кредита, продавец и клиент должны ввести много информации об автомобиле и условиях кредитования. Поскольку это важная информация, клиент должен чувствовать, что передавая информацию продавцу, он ничем не рискует. (это “Интерес стейкхолдера”, Stakeholder Concern, “Безопасность личной информации”).
Наблюдайте за тем, как люди решают проблему сейчас (то есть какую работу они делают сейчас). Это поиск viewpoint, частного метода описания. Наиболее часто используемый viewpoint - шаблон. “Сделай как в этом документе, сделай по шаблону”.
При заполнении этого типа информации покупатель анализирует (обычно визуально) продавца и автосалон и решает, можно ли им доверять. Обычно они заполняют свою конфиденциальную финансовую информацию в тесном физическом контакте, на листе бумаги, с продавцом. Это помогает им быть уверенным, что информация заполнена правильно и не будет передана третьим лицам.
Придумайте job story, чтобы исследовать причины, беспокойство и мотивы того, что они делают сейчас (создается частное описание, которое отвечает на интерес стейкхолдера, это требование стейкхолдера)
1. Когда продавцы автомобилей и их клиенты взаимодействуют друг с другом через
продукт…
2. ... клиенты хотят чувствовать, что они могут доверять организации, процессу и продавцу.
3. Продавцы хотят быть уверенными в том, что в ходе процесса их клиенты чувствуют себя комфортно ...
4. ... поэтому клиенты будут чувствовать себя в безопасности, вводя свою финансовую информацию для обработки.
Создайте решение, которое решит эту job story
Чтобы решить эту задачу, команда решила, как должен выглядеть профиль. Если в нем будет слишком мало информации, он будет бесполезен, слишком много информации может иметь негативные последствия. Поэтому команда решила:
1. Когда клиент использует продукт, профиль профиля продавца будет всегда виден (чтобы уменьшить беспокойство клиентов о том, что продавец не рядом).
2. Профиль будет иметь изображение продавца, должность, количество проданных автомобилей и стаж в компании (чтобы уменьшить беспокойство клиентов о том, можно ли доверять продавцу).
3. Профиль позволит легко найти продавца и связаться с ним, например, по телефону, электронной почте или с помощью кнопки «Задайте [продавцу] вопрос» (чтобы уменьшить беспокойство клиентов по поводу неправильного заполнения формы).
Пример такого решения:
Другими словами, мы нашли стейкхолдера, поняли возможность (какую работу он делает, какие силы его направляют на переключение и от переключения), поняли его интересы (безопасность и корректность предоставления данных), нашли частный метод описания, отвечающий этим интересам, выявили требования стейкхолдера и разработали архитектуру решения.
Такое представление позволяет сделать еще один метод разбиения системы - разделение интересов (separation of concerns). В этом примере мы рассматривали только один интерес и разбирались с ним. В другой раз мы можем рассмотреть интерес “Финансы” и будем оценивать бюджет и трудозатраты проекта. В третий раз это может быть интерес “Сроки”, где мы будем обсуждать расписание выпусков продукта. По одному интересу за раз.
Помните, я обещал рассказать про три метода борьбы с водоразделом “Заказчик-Исполнитель”? Подвожу итоги.
Системный подход борется со сложностью тремя способами:
- Отдельно рассматривает функции системы и ее конструкцию, плюс размещения
- Использует жизненный цикл, где разбивает систему по четко разделимым состояниям
- Использует разделение интересов с помощью частных описаний
Это и есть системный подход 2.0. Субъективно определяемые системы, стейкхолдеры как роли и жизненный цикл, состоящий из практик, а не процессов.
Помните, в начале текста я писал, что разница между успехом и неудачей - в вашем списке дел? На тренинге вы начнете искать ответы в правильном направлении.
Заказать подходящий тренинг можно по телефону +7(925)673-44-84 или e-mail: alex.turkhanov@gmail.com Александр Турханов.
Комментариев нет:
Отправить комментарий