Зачем это все?
Я помню, как мне в руки попал первый iPhone. Единственное, что я сразу понял - это как с него звонить и писать СМС. Все остальное было загадкой - приложения, карты, видеозвонки, календарь, синхронизация с компьютером. Я даже не мог послушать с него музыку, потому что в iPhone нет папок и файлов, и я не знал, а как еще можно скопировать музыку с компа на телефон. Это была такая необычная вещь, что про нее пришлось много что учить и узнавать нового.
А ведь кто-то эту необычную штуку придумал и сделал. "Как они такое выдумали и сделали?" - крутился в моей голове вопрос.
Годы спустя я внимательно наблюдал за тем, как растут дети. Видел, как рождается в их головах знание о мире. Когда они были маленькими, то почти ничего не знали о вещах вокруг, об их функциях и назначении. Когда они впервые столкнулись с самолетом или телефоном, их надо было учить зачем эту штука нужна и как она работает. И я стал понимать, как рождается индивидуальное знание о вещах.
Все эти годы как руководитель проектов я внимательно наблюдал за тем, как команда проектирует, строит и продает продукты. На старте проекта, до начала исследований и разработок, в головах команды нет четкого концепта продукта, нет понимания того, в чем его польза, как его проектировать, производить и продавать. И они должны много что сделать, чтобы понять, какая новая вещь появится в мире, наделить ее смыслом для себя и положить этот смысл в головы покупателей. Нелегкая задача для любой штуки, которую нельзя съесть прямо на кассе. И я стал понимать, как рождается коллективное знание о вещах.
Последние несколько лет как системный инженер и методист я внимательно изучал процессы проектирования, изготовления, маркетинга и продаж. Я видел, какие проблемы возникают при попытках обсудить, согласовать и записать планы сложных проектов, системную архитектуру или создать набор согласованных между собой документов из разных областей - от маркетинга до закупок и НИОКР. И я стал понимать, как обеспечивается функциональное взаимодействие между разными командами, как проходит трансдисциплинарный анализ и синтез проектных решений в больших распределенных командах без единого руководства.
Я объединил эти три знания и понял, как инженеры думают о продуктах.
В наш мир приходит все больше необычных вещей, а использование многих существующих постоянно переосмысливается. Вещи становятся все более сложными, и даже для того, чтобы перевести ERP, CRM или WMS/TMS из опытной эксплуатации в серийную, надо как следует постараться и подумать. Полностью полагаться на то, что за заказчика все сделает разработчик продукта уже нельзя. Любой менеджер сейчас должен уметь думать о продукте и ставить задачу на его доработку, даже если это не входит в описание должностных обязанностей. Мышление руководителей должно приблизиться к мышлению инженеров и программистов. И тогда для них наступит освобождение от парадигмы "я придумываю, как зарабатывать деньги, дело разработчиков - исполнять замысел". Бизнес-замысел должен подстраиваться под технические возможности, но при этом не должна наступать диктатура исполнителя.
С другой стороны, и у самих проектировщиков и программистов наступили времена, когда нельзя просто взять и реализовать полученное на старте техническое задание. Во время разработки проектных решений надо закладывать возможность их последующего изменения, надо понимать, у кого что спросить и что необходимо уточнить перед тем, как начать работу, чтобы не сделать ненужную доработку или функцию. И мышление современного программиста или проектировщика должно стать ближе к мышлению руководителей, в их голове должно появиться четкое денежное и социальное измерение работы. И тогда для многих из них, которые застряли в парадигме "я реализую ровно то, что написано в постановке задачи и не понимаю, чем заказчик недоволен" наступит долгожданное освобождение от диктатуры заказчика.
И для тех и для других решение лежит в одной плоскости - надо уметь четко структурировать объекты в реальном мире, подбирать под них работоспособные концепции, строить на базе этих концепций понятийный аппарат, строить на базе понятийного аппарата логику достижения цели и получения нужного результата, подбирать метод организации работ под конкретные условия, в которых работает команда, вовремя вовлекать нужных людей и давать им ровно ту информацию, которая нужна для принятия нужных решений. Словом, все то, что обычно называют "здравый смысл" и "умение включать голову", но я разобрал эти общие рекомендации на сотню конкретных отрабатываемых навыков, которые совместно составляют более-менее современный корпус системноинженерных знаний.
В этом производственном романе и серии сопутствующих упражнений я детально объясняю как работает дисциплинированная инженерная и управленческая мысль в проектах по созданию продуктов и что надо сделать на каждом шаге, чтобы не только не бояться пришествия нового iPhone, но и уметь доработать его под свои нужды.
В своей работе я использую идеи из следующих источников:
Системное мышление 2019. А. Левенчук,
Системный инженер: Как начать карьеру в новом технологическом укладе. В. Мизгулин,
Курс по онтологике. П.Медведева,
Блог http://anticomplexity.org/ Е. Чурилов
Блог http://howtoknowhow.ru/ М. Ковина-Горелик
Стандарт Semantics of Business Vocabulary and Rules, OMG
Chris Argyris Organizational Traps: Leadership, Culture, Organizational Design
Роман состоит из двух частей - первая часть вводит основные понятия, вторая часть показывает использование введенного понятийного аппарата для реверс-инжиниринга кофемашины. Предлагаемый подход основан на системном подходе Школы системного менеджмента с дальнейшим развитием теории стейкхолдеров идеями Криса Аргириса.
Краткий обзор основных идей
Принципы директивного управления
(Auftragstaktik; тактика поручений; то, что применительно к разработке ПО 200 лет спустя прозвали Agile)
При реализации любого плана есть три барьера:
Пробел между уровнем необходимых и фактических знаний (1)
несогласованность планов и действий (2)
различие между ожидаемым и подтвержденным результатом действий (3).
Эти барьеры неустранимы.
Stephen Bungay, Art of Action.
Медленный хаос не равен порядку. Agile требует от команды предельной дисциплины в мышлении и согласованности в действиях.
Gregor Hohpe, Technical director in Google Cloud’s Office of the CTO
Ситуационная осведомленность команды - ключ к успешному созданию и реализации стратегии.
Основной принцип, который стоит за методом PowerMaps.
Умение быстро и четко различать абстракции и реальность
При зрелом размышлении все спокойно отличают, идет речь о реальных штуках или о понятиях. Вопрос в том, что это различение должно идти на автомате. Дети в первом классе могут складывать и вычитать, но обычно делают это медленно, у них уходит на это много сил. Инженеры и руководители даже довольно сложные расчеты прикидывают в уме на раз-два и не напрягаются. Надо добиваться именно такого автоматизма.
Есть реальный мир и абстракция от него. Чем лучше наши понятия, тем качественнее наше мышление о мире и тем более верные решения мы принимаем. В реальном мире есть объекты со свойствами, в мире абстракций есть понятия с характеристиками:
- каждый объект имеет одно или несколько свойств
- каждое свойство подобного вида абстрагируется в одну характеристику
- каждая характеристика является частью одного или нескольких понятий
- каждое понятие образуется уникальным набором характеристик
- каждый объект абстрагируется в одно или несколько понятий.
Пример:
- кофемашина, которая стоит у нас в офисе, может быть капсульной, с черным корпусом, в не профессиональном исполнении;
- когда мы думаем о такой кофемашине, то у нас в голове возникает понятие "кофемашина", пункт в мысленном инвентаре вещей, о которых мы думаем. У этого понятия есть характеристики "капсульная", "черная", "бытовая", эти характеристики образовались от свойств реального объекта, который стоит на кухне в офисе;
- когда мы думаем о кофемашинах, то капсульной может быть не только та кофемашина, которая стоит на кухне, но куча других кофемашин;
- при этом знания в нашей голове собраны вокруг какого-то набора характеристик. Мы знаем, что капсульная черная кофемашина в бытовом исполнении подойдет для офиса, а профессиональный трехрожковый аппарат для приготовления эспрессо нет;
- про конкретную кофемашину мы можем думать еще и про как пункт статьи затрат, электропотребителя, источник шума в офисе, элемент интерьера, пункт в списке ежедневной уборки офиса. Другими словами, один объект представляется множеством понятий.
Понятия могут быть единичными или общими. Единичное понятие относится к уникальному объекту, тому самому, про который собеседники точно знают, что он один. Общее понятие относится к классу объектов. Чтобы различать уникальность объектов, инженеры используют так называемый URI, унифицированный идентификатор ресурса. Вы все знаете про разновидность URI - URL, адрес сайта и ISBN - идентификатор книги.
Любой объект мы можем рассмотреть как простой, неделимый на другие объекты, и как сложный, состоящий из других объектов. Мы часто проделываем эту мыслительную операцию, даже не задумываясь над этим. Типичный пример - покупка и эксплуатация автомобиля. Когда мы покупаем автомобиль, мы оперируем им как неделимым объектом с какими-то свойствами (двигатель, салон, класс, цвет, надежность, удобство) и сравниваем в голове единичные понятия о конкретных автомобилях, которые мы видели в автосалонах, по характеристикам.
Как остановиться в этом бесконечном углублении рассмотрения? Окончательную точку в этом вопросе ставит системный архитектор, он принимает решение что включать в рассмотрение, а где остановиться. Как он это делает?
Чтобы ограничить количество рассматриваемых объектов и структурировать область рассмотрения, инженеры используют два приема - помещают объект в контекст и рассматривают его на жизненном цикле.
В системном подходе реальный мир делят на четыре объекта: бизнес-контекст (1), который включает в себя операционный контекст (2), целевую систему (3), помещенную в операционный контекст, и системный контекст (4), который описывает, из каких объектов состоит целевая система. При этом мы осознанно используем мыслительный прием, который мы обычно используем бессознательно - мы думаем о сложных объектах как о пространственно-временных структурах, наше мышление оперирует 4Д, пространством и временем. Поясню, как это обычно происходит.
Допустим, собрались вы вечером с друзьями поиграть в "Монополию". Конкретная партия игры определенно является объектом реального мира, т.к. ее можно увидеть и понять. Этот объект является сложным/составным, т.к. для игры нужны люди, карта, кубики, фишки, деньги и сборник правил. Составной объект "Игра в Монополию" структурно состоит из других объектов - кубиков, игроков, фишек, денег. Вы начинаете игру, бросаете кубики, двигаете фишки, зарабатываете и теряете деньги, покупаете предприятия и торгуете друг с другом. Все это происходит в какую-то единицу времени, в игровой ход. Получается, игровой ход мы тоже можем увидеть, выделить как отдельный объект, обсудить правильность и допустимость действий. В шахматах так постоянно и делают, в них выделяют и обсуждают отдельные ходы. И в футболе - матч состоит из передач, ударов, штрафных, а не только из игроков, ворот, мяча, поля и судьи. Другими словами, мы можем рассматривать состав объектов не только в виде пространственной структуры, но и в виде временной, темпоральной структуры. Например, один и тот же состав "Сапсана", который курсирует между Москвой и Питером, будет состоять из двух объектов - поезда 752А и поезда 761А. И мы различаем между собой два этих объекта "поезд Москва-Питер 752А" и "поезд Питер-Москва 761А", хотя и тот и другой определенно являются временной частью одного и того же состава бортовой номер, допустим 7628. Объект "состав 7628" состоит из временных частей, объектов "поезд 752А" и "поезд 761А".
Такое временное разделение позволяет системному архитектору обсуждать деятельность предприятия в бизнес-контексте. Потому что для того, чтобы структурировать бизнес-контекст и операционный контекст, мало уметь различать между собой физические объекты, надо уметь видеть динамику ситуации. Это нужно для того, чтобы учитывать использование станка с ЧПУ или испытательной лаборатории в разных проектах, потому что в каждом из этих проектов и станок и лаборатория будут учтены как отдельные объекты со своей ролью и назначением, а системный архитектор должен уметь правильно организовать распределение ресурса лаборатории или станка между разными проектами и процессами, должен уметь собрать и свести данные из разных учетных систем в системе управления жизненным циклом изделия. Другими словами, если инженер-испытатель приходит к нему с запросом "мне нужен стенд 13 через неделю на 24 часа", то система управления жизненным циклом, которую построил системный архитектор, должна свести между собой данные из четырех 1С-ок и 12 таблиц Excel, чтобы понять, есть ли такое окно. Чтобы построить такую систему, ему надо думать об объектах как о пространственно-временных структурах, думать в 4Д.
Такое мышление контринтуитивно, обычно когда я начинаю рассматривать работу строительного крана, процесс проектирования или работу с CRM в том же ключе, что и конструкцию дома, модульную архитектуру прибора или структуру баз данных, люди вокруг очень возмущаются. Они считают такое рассмотрение (состав не может состоять из двух поездов, это нонсенс!) недопустимым, пока не увидят, что использование логики пространственно-временных структур сильно упрощает модели целевой системы и ее контекстов. И тогда все аргументы исчезают.
Рассмотрение объектов в 4Д позволяет в разы сократить количество объектов в области рассмотрения для сложных проектов, упростить модели и принятие проектных решений.
Когда мы организуем систему понятий, мы объединяем концепты в какие-то группы. Для этого мы берем характеристики и объединяем их в типы, а типы строим в иерархию подтипов и надтипов. Получившаяся система понятий описывается концептуальной схемой. Таким образом, физический мир у нас организуется в пространственно-временную структуру из целевой системы, операционного контекста и бизнес-контекста, в 4Д-экстент, а понятия организуются в систему понятий, которая описывается концептуальной схемой, и делится на предметные области. Первая структура наводит порядок в реальном мире, вторая структура наводит порядок в мире абстракций. Обе эти структуры связаны между собой какой-то логикой, хотя и не повторяют друг-друга в точности, потому что структуры реального мира происходят от технологических и организационных ограничений, от того, что мы можем сделать с объектами, а структуры абстрактного мира происходят от мыслительных ограничений, от удобства коллективного мышления и коммуникаций. Связь между этими двумя структурами называется законом Конвея, который вкратце можно сформулировать так: "Структура общения команды определяет структуру системы". Практическое применение закона Конвея в том, что модель общения определяет "нарезку" и распределение технологий работы с объектами реального мира. Чтобы изменить технологию проектирования и построения целевой системы, зачастую надо изменить систему понятий и общение в команде.
Какая-то целостная система типизированных понятий называется онтологией. Онтология - это обобщение в типы/классы; она реализуется через группу типов, классов, категорий или иных конструктов, более или менее избавленных от объектной конкретики, и в это её ценность. Единичные понятия группируются в онтики, в мыслительные инвентари.
Итого: онтика - список конструктов с координатами в операционных пространствах, "концептуализированных объектов". Их координатные определения (4Д, например) мы можем скармливать конкретным моторным программам. Онтология - список конструктов с обобщёнными местами, она нужна для построения переносимости параметрических структур между группами операций (откорректированное мной определение онтологии, которое дал Егор Чурилов).
Метод состоит из онтологии (общих, переносимых между ситуациями знаний по тому, как построить коллективное мышление) и технологии (общих, переносимых между ситуациями знаний по тому, как преобразовать одни объекты в другие), методика состоит из онтики (практически применимых знаний по тому, как построить коллективное мышление) и техники (практически применимых знаний по тому, как преобразовать одни объекты в другие). Метод можно перенести между ситуациями широкого класса, в контексте всей реальной деятельности предприятия на длительных временных промежутках, на различном рыночном, процессном и ИТ-ландшафте. Методика применима для узкого класса заданных ситуаций, скажем, для заданного набора клиентов, поставщиков, рыночных условий и устоявшегося процессного и ИТ-ландшафта.
Метод и методика находятся в голове команды и рабочих продуктах (шаблонах документов, базах данных, настройках приложений, архивах и т.п.)
Мы не рассматриваем всю Вселенную объектов и все понятия, которые соответствуют этим объектам. Для каждого проекта выделяется область обсуждения, которая определяет, какие объекты относятся к проекту, а какие нет.
ГОСТ Р ИСО 15531-1-2008
3.6.50 область обсуждения (universe of discourse, domain): Совокупность физических или абстрактных объектов, относящихся к области реального мира, которые выбраны в соответствии с интересом, который они представляют для системы, подлежащей моделированию, и ее окружением.
Область обсуждения определяет, где мы останавливаем дальнейшее разбиение составных, сложных объектов на составляющие их объекты. Как только нас перестало волновать, как мы получаем тот или иной объект, мы проводим границу области обсуждения. Например, если мы покупаем автомобиль в салоне с гарантией производителя для того, чтобы ездить по городу, нас не интересует марка аккумулятора, тип приводного ремня и износ дисков сцепления. Если что случится, мы просто отвозим автомобиль по гарантии и нам все исправляют. Но если нам надо выехать в безлюдную местность, то мы будем тщательно изучать все нюансы эксплуатации и ремонта автомобиля в полевых условиях, озаботимся многими мелочами, которые становятся важны в тайге, где нет инфраструктуры для эксплуатации автомобиля. Аналогично, производители одежды или еды, которые озабочены этичностью поставщиков, начинают отслеживать цепочку происхождения сырья и материалов, и расширяют область рассмотрения.
В области обсуждения помимо физических объектов: целевой системы, операционного контекста и бизнес-контекста, есть и абстрактные объекты, которые существуют в области обсуждения логически. Например, я знаю, что если вырыть котлован, купить машину цемента, пригнать бригаду рабочих, замесить раствор и залить котлован раствором цемента, то у меня будет фундамент под дом. Никакого фундамента еще нет, есть только деньги и замысел. Но в области обсуждения проекта по строительству дома все эти объекты - участок, котлован, бригада, раствор, фундамент уже существуют в логическом смысле. Концептуальная схема проекта строительства дома (онтология строительства, накопленные знания) говорит мне, что такое возможно. И я могу обсуждать такие абстрактные, еще не существующие объекты с другими людьми и мне никто не будет крутить пальцем у виска потому что они разделяют со мной концептуальную схему. Как говорят системные инженеры, в таком случае команда разделяет метод.
Глава 1, в которой все знакомятся и понимают, что будет трудно.
Лидия вышла из такси перед зданием 30 подразделения AnyCorp. Донна уже ждала ее, они радостно обнялись и Донна повела ее в кафе за углом. Там они сели и за чашкой латте ударились в воспоминания. Прошло уже 8 лет, как они встречались в последний раз, а мрачноватую Лидию жизнерадостная подруга всегда привлекала.
"Как карьера? Уже директор по персоналу?" - спросила ее Донна. Про повышение ей рассказала Ольга, их общая знакомая, которая всегда знала все про всех.
"Была полгода, теперь у нас в подразделении нет директора по персоналу, есть только HR бизнес-партнеры. Переходим к бирюзовой организации", - Донна, казалось, немного погрустнела. Но она всегда была амбициозной, а стать из понятного директора по персоналу непонятным HR бизнес-партнером могло выглядеть не очень.
"Ну что, расскажи мне про этот проект", - Лидия пересела немного в тень, потому что от латте и жаркого солнца она начала потеть.
"Э, нет, не на улице, у нас очень строгая служба безопасности. Вначале иди, оформи допуск, возьми SecurePad".
"Что взять?"
"Защищенный планшет, на нем будет вся информация по проекту и данные по подразделению. Даже по подразделениям, они пока разъединены, производство сидит в 16 корпусе, их надо перевозить и объединять. Пойдем, если ты так рвешься в бой".
Они прошли шлюзовый вход, в котором Лидия немного запуталась с этими блокировками входов и разговорами через интерком, поднялись на лифте на 13 этаж, проехав полуосвещенный 9, на который Донна кивнула, мол, твой, и вышли в длинный узкий коридор. Охранник, сидевший на этаже, сказал Лидии следовать за ним, а Донна осталась ждать на диванчике рядом с аквариумом, в котором плавала черепаха и несколько тропических рыбок.
Охранник провел Лидию в кабинет, где ее ждал офицер внутренней безопасности. Он выдал ей бэйдж и толстенький планшет с абсолютно черным экраном. На планшете была надпись SecurePad.
"Как будете расписываться?" - спросил офицер, и Лидия выбрала подпись с помощью телефона.
"Короткий инструктаж. Планшетом можно пользоваться только на территории корпорации, в пределах корпоративного WiFi. И дома, координаты прописаны в планшете. В пути разрешается только в корпоративном автомобиле, там стоит маячок, радиус действия 10 метров. Планшет блокируется вне этих зон. Если планшет покидает защищенную зону больше чем на 24 часа, все данные на нем стираются. У планшета поляризованный экран, видеть изображение можно только поставив экран прямо. Планшет распознает ваше лицо, как только в него посмотрит другой, он заблокируется. На ваш телефон сейчас будет установлена программа поиска планшета и удаленного уничтожения информации на нем".
"А если воры его выключат, то как я его сотру?"
"Там спутниковая связь, если планшет не видит спутник 4 часа, то стирает информацию".
"Отвечая только да и нет, скажите, вам все понятно про правила пользования защищенным планшетом?"
"Да, все понятно".
"Выходите к сопровождающему".
Лидия вышла в коридор с планшетом в руках. Он был какой-то немного неудобный, в сумочку залез с трудом.
"Ну что, идем к тебе?" - И Донна нажала девятку.
Они вышли в слабо освещенный коридор, Лидия бикнула пропуском и они зашли внутрь. Половина этажа была пустая, свет был выключен, но дальний конец был освещен, там ходили люди и были слышны разговоры. Донна провела Лидию к дальний конец, и когда их увидели, разговоры моментально стихли.
"Это ваш босс, ребята", - представила Донна Лидию.
"Меня зовут Лидия, я закончила Гарвард, получила степень по социологии, в AnyCorp работаю 8 лет, и у вас я буду старшим директором по объединенным операциям DevProd. Можете считать меня старшим исполнительным директором для подразделения".
"Планшет", - прошептала ей Донна.
Лидия достала планшет и он включился. На нем появилось лицо Донны: "Привет. Познакомься со своей командой". И пошли фотографии с краткой справкой по каждому члену команды, Лидии только оставалось запоминать лицо, жать руку и кликать "Следующий". Через 5 минут все закончилось, хотя оставалось еще много народу.
"Сейчас только руководители, всех все равно не запомнишь", - объяснила Донна.
Лида только помахала всем рукой: "До завтра, ребята, я всем назначу встречи и мы поговорим".
Потом они сели в пустой переговорке и Донна рассказала ей что да как.
Ребята, которых встретила Лидия, были тем самым стартапом 9-bis, который нашумел на выставке по беспилотному транспорту в Мюнхене в Феврале. В марте AnyCorp их купила и посадила делать серийный продукт "Универсальный автопилот", который они хотели продавать как опцию автомобильным компаниям. Условно, как АБС - ставишь и получаешь автопилот высокого уровня. Но ребята отставали от графика уже на два месяца и отставание увеличивалось. Они никак не могли справиться с производственными процессами, производственники не принимали их дизайн по самым разным причинам. В результате руководство решило, что к проектировщикам надо добавить производственный отдел, который занимался запуском спецавтомобилей, и поставить "родительский надзор" в виде опытного руководителя.
"Я тебя проталкивала всеми силами", - Донна вся раскраснелась.
"Спасибо", - Лидия была возбуждена, но все равно никак не могла понять, зачем Лидии была нужна именно она.
"А все-таки, почему я?" - попробовала она почву.
"Честно говоря, я не очень верю во все эти организации будущего", - внезапно открыто сказала Донна.
"И ты хочешь от меня что?" - Лидия знала, что никто ничего просто так не делает и лучше бы понимать мотивы других.
"Мне кажется, им порядка не хватает, а по поводу остального ты сама решай".
Лидия внимательно посмотрела на Донну и тут у нее позвонил телефон. Она взглянула на номер и прямо ринулась к другой переговорке, показав Донне, что это очень-очень срочно. Она нашла пустую переговорку, закрыла дверь, повернулась спиной к ней, чтобы никто не видел ее лица и начала разговаривать. Донна прошла мимо, посмотрела, ничего не увидела, и пошла к кофе-машине. Навстречу ей выскочил интерн, молодой индус, его только что взяли, и побежал к переговорке. Он постучался и зашел.
"Извините, я забыл свой телефон, возьму и побегу".
Но Лидия была взбешена и секунд 30 выговаривала про правила приличия и объясняла, что если дверь закрыта, то заходить нельзя и вообще надо уважать право начальника на приватный разговор.
"Так вы наш новый босс?"
"Я же приходила, знакомилась 15 минут назад".
"У нас было совещание, я писал протокол в переговорке, не видел вашего представления, мне очень-очень жаль", - интерн весь в поту выбежал из переговорки, держа в руке забытый телефон.
Донна увидела, как Лидия посмотрела на нее и улыбнулась. Она зашла в переговорку и спросила: "Вербовала?"
"Ага, классика жанра. Он толковый?"
"Тут вообще глупых нет, мы же тщательно отбираем".
Лидия посмотрела в планшет. Викрам Найду, ассистент системного инженера, помощник команды. Неплохая кандидатура, только надо проверить, годится ли он в качестве информатора. Лидия умела уговаривать людей.
"Ну что, сама дорогу найдешь?"
Лидия только кивнула головой и пошла домой, изучать документацию по проекту. Ей предстояла большая работа. Ближе к двум часам, исписав почти полную тетрадку конспектами, она выключила SecurePad и и пошла чистить зубы перед сном. Тут ей на телефон пришло сообщение "Вам перечислен аванс за июнь. Сумма 52,000. AnyCorp." "Корпоративный центр в Бангалоре, значит", - вычислила Лидия, и зашла в интернет-банк. Открыла шаблон "Благотворительный фонд Звезды" и перечислила ему 26,000. Взяла стакан на кухне, налила воду, открыла новую упаковку пегинтерферон бета-1а, выпила таблетку и запила ее водой.
На работу Лидия приходила всегда к 7 утра, пока пробок на улицах не было, а офис был пустой и можно было спокойно поработать. В 7:30 пришел Викрам, Лидия настроила оповещение в пропускной системе на его имя, поэтому она вышла из кабинета и сделала вид, что куда-то спешит. Они чуть не столкнулись, и Викрам чуть в стенку не вжался, но Лидия его успокоила: "Ничего-ничего, все нормально. Не ожидала, что кто-то придет в такую рань, поэтому уткнулась в телефон на ходу. Викрам, ведь верно?" Интерн кивнул и хотел было пройти дальше, но Лидия взяла его под руку и спросила: "Кофе будете? Директорский, из хороших капсул?" Они сидели и пили утренний кофе, а Лидия понемногу расспрашивала Викрама про проект и инженерную культуру 9-bis. Ответы Викрама были вполне здравые и даже умные, и Лидия решила, что он ей подойдет. Она откинулась в своем Herman Miller и спросила: "Викрам, а вы готовы стать из ассистента команды заместителем руководителя проекта? Зарплата в 2,5 раза выше, компетенций на первый взгляд достаточно. Если сейчас пройдете небольшой тест, то я прямо сейчас попрошу HR начать перевод". "А какой тест?" - Викрам вроде бы даже и не волновался. "Знаете, я обычно даю очень простую задачу, которую может сделать любой. Но люди с талантом делают ее гораздо быстрее и творчески. Метод Джоэля Спольски. Но пусть это будет не просто какой-то абстрактный тест, давайте сделаем его немного практичным. Нам надо будет перевести отдел по производственной подготовке из 16 корпуса к нам в DevProd. Составьте чек-лист такого переезда за 15 минут", -и она пододвинула к нему бумагу и ручку. "Зачем это?" - удивился Викрам. "А вы в уме будете задачу делать?" "Нет, на компьютере, так гораздо быстрее". "Я из старой школы, вначале надо почиркать на бумажке, и только потом могу перенести мысли в компьютер". Викрам уже достал из папочки под мышкой ноутбук, примостился на кофейной стойке и бодро стучал по клавишам. Через 8 минут он повернул Лидии ноутбук, там был документ.
Чек-лист офисного переезда
Шаг 1. Как только было принято решение переезжать.
• Присвоить отделам цветовые коды с помощью стикеров.
• Разметить план помещения цветовыми кодами.
• Приклеить стикеры с табельным номером и именем работника на его мебель и оборудование.
• Четко обозначьте места общего пользования на новом плане помещения и дайте им названия.
• Привлеките к переезду системных администраторов и обсудите, что им надо, чтобы его обеспечить.
• Оформите все необходимые официальные документы, разрешения и лицензии.
• Зарезервируйте парковочные места и лифты на день переезда.
• Разместите заказы на новую мебель и канцтовары.
• Организуйте клининг в вашем старом и новом помещении.
• Установите коды и замки в новом помещении.
• Вышлите подробный план помещения перевозчику, при необходимости организуйте встречу на месте.
• Создайте подробный план действий для работников в день переезда.
• Составьте список контактов для срочного решения проблем для всех, кто участвует в переезде, включая техническое обслуживание лифтов и оператора здания.
• Установите дату празднования переезда.
• Организуйте хранение на стороннем складе, при необходимости.
Задействуйте работников
• Организуйте собрание для обсуждения переезда.
• Назначьте ответственного от каждого отдела за упаковкой вещей.
• Обсудите порядок и правила упаковки и размещение на новом месте.
• Дайте указания по проезду, парковке, движению общественного транспорта и т.п.
• Дайте каждому работнику раздатку, где будет указан номер их рабочего места, цветовой код, приведена информация о здании и офисе, может быть указания по ресторанам, кафе и магазинам в округе.
• Объясните стандартные способ маркировки ноутбуков, системных блоков, мониторов, клавиатур и т.п.
• Проверьте, что все забрали домой личные вещи, сменную обувь, зонты.
• Обсудите, кто останется в старом офисе пока оттуда все не вывезут, а кто приедет в новый офис, чтобы помочь с переездом.
• Проверьте, что каждый отдел надежно упаковал документацию, закрыл коробки и файловые кабинеты.
• Проверьте, что на месте есть мусорные мешки, упаковочная лента, скотч, ножницы, коробки.
На вашем новом месте
• Разметьте офис цветовыми кодами, чтобы четко понимать на месте границы отделов.
• Укажите размещения рабочих мест по номерам столов.
• Проверьте, что ключи, карточки доступа и информация по безопасности есть в наличии.
• Отошлите оповещение о смене адреса:
○ Клиентам и партнерам
○ Профессиональным организациям
○ Поставщикам канцтоваров
○ Банкам
○ Поставщикам еды и воды
○ Компаниям, которые обслуживают офисное оборудование
○ Страховым
○ Бухгалтерии
○ Провайдеру Интернета
○ Другим поставщикам услуг
Шаг 3. В день переезда
• Держите распечатку с номерами для срочного решения проблем при себе.
• Проверьте отсутствующих и назначьте им замену.
• Выдайте перевозчику и системным администраторам контрольные списки того, что они должны сделать.
• Посчитайте выделенное количество персонала перевозчика и запишите время начала работ.
• При загрузке в грузовики проверяйте по списку что куда грузится.
• Закупите перекус и напитки для тех, кто участвует в переезде.
• В жаркое время года включите кондиционер.
• Раздайте новые ключи, карточки и пропуска.
• Перевозите телефоны, технику и компьютеры в первую очередь.
• Обшейте косяки и лифты защитными щитами, чтобы не повредить их при переезде.
• После загрузки последнего грузовика, но до его отправки пройдитесь по помещению и проверьте, не забыли ли чего.
• Расклейте распечатки планировки помещения в нескольких местах нового офиса.
• Проверьте, что координаторы переезда на местах и проверяют, что цветовые коды коробок, мебели, техники и разметка помещения совпадают.
• Проверить, что все стол поставлены верно, счет коробок по столам совпадает, цветовые коды совпадают.
• Проверьте, что подключения телефонов и компьютеров к сетям идут по плану и работники смогут приступить к делам в указанную дату.
На следующий день после переезда
• Разложите на рабочих местах распечатки с именем, должностью, рекомендациям по тому, где обедать и как добираться.
• Проверьте здание и помещение, проверьте исправность оборудования.
• Проверьте, достаточно ли четко размечены области и понятна ли разметка работникам.
• Установите все компьютеры и оборудование.
• Установите телефоны и проложите кабельные и WiFi сети.
• Создайте новый список телефонных номеров.
Через несколько дней после переезда
• Разошлите новый список телефонных номеров и расположения отделов.
• Проведите тщательную инспекцию помещений.
• При необходимости сообщите о повреждениях компании-перевозчику.
• Проверьте, что страховка помещений была перенесена.
• Проверьте, что старый договор аренды прекратил действие.
• Подтвердите получение депозитов от старого помещения.
• Соберите все ключи, карточки и пропуска от старого здания и верните их.
• Проверьте все накладные, счета и платежи за новое помещение.
• Поставьте новую мебель на баланс.
• Создайте итоговую версию списка рассылки и разошлите оповещения о переезде.
• Организуйте празднование переезда.
Лидия не подала виду, но была очень довольна результатом. Она давала это задание кандидатам раз 200, и ей было с чем сравнивать. Главная идея была в том, что спорить по поводу качества исполнения этой задачи кандидатам было очень сложно, потому что ошибки были очевидные - забывали про ИТ, про повреждения мебели и лифтов, про еду, депозиты и прочие мелочи. Но те, кто справлялся, обычно неплохо показывали себя в работе, потому что быстро думали и могли очень четко представить себе картинку в проекте и организовать людей. Она, конечно, еще погоняла Викрама по пунктам, проверить, насколько он уверен в результате, но он очень четко понимал зачем он поставил тот или иной пункт и аргументировано доказывал Лидии свою точку зрения. Было уже почти восемь, и скоро могли подойти люди. Лидия не хотела, чтобы их оживленную беседу увидели, и сказала Викраму: "Подавайте заявление на перевод, я подпишу его сегодня". Викрам, окрыленный ушел на свое место, в логово интернов.
Первым делом ему надо было завершить расшифровку вчерашнего собрания. Первые 40 минут он сделал еще вечером, после работы, оставалось еще 5. Сама запись была длиной 58 минут, потому что Викрам забыл выключить ее, когда уходил, и на нее попал разговор Лидии. Перед ним стояла теперь дилемма - послушать, о чем она говорила, или нет. Он недолго колебался, но решил все-таки послушать. Лидия говорила с кем-то близким, похоже, что с дочерью, у которой были проблемы со здоровьем. Викрам решил не дослушивать до конца, и обрезал запись до 45 минут. Разослал расшифровку всем участникам, и как раз вовремя, пришел поезд на 8:24, и в логово разом завалились все интерны. Начался рабочий вторник.
Всю неделю Лидия проводила очные встречи со всеми членами команды, а в пятницу в неосвещенную часть офиса приехали грузчики с горой коробок, пришли админы с компьютерами и оборудованием, администраторы офиса бегали и вешали таблички. К ним переезжало производство. А в обед Викраму пришло письмо от HR с просьбой подойти и подписать новый договор. На радостях он объявил, что угощает всех интернов в их любимом баре после 8.
Интернов было много, они сдвинули три стола, и разговор свернул в привычную для последних дней сторону. Все обсуждали Лидию, сможет ли она изменить проект. Так как она за неделю провела 40 совещаний, то мнение о ней уже сформировалось, да и сама Лидия слишком часто говорила про себя, что она здесь adult supervision, родительский надзор. Очередная жесткая рука, корпоративный босс, ничего человеческого. "Ну, дочка у нее есть, и они вроде в нормальных отношениях", - проболтался Викрам. Он уже успел выпить пару бокалов и расслабился. Рядом сидела интерн из HR, Викрам не помнил точно ее имени, вроде бы Ребекка, она тут же залезла в телефон и стала что-то искать, только и мелькали экраны соцсетей и поисковиков. Через несколько минут Ребекка сказала: "Да нет у нее никакой дочери, или она такая секретная, что даже в интранете про нее ни слова". Викрам уже жалел о длинном языке, поэтому ничего Ребекке не ответил. Но потом, уже перед тем, как зайти в бар и расплатиться по счету и уйти домой, на улице он разболтался со своим бывшим однокурсником. "Понимаешь, ей ведь нужен успех, а значит, у нее есть сильный мотив слушать нормальные советы. Потому что это слишком сложный проект, чтобы управлять им с помощью обычных интриг и корпоративных механизмов контроля. У нее не получится игнорировать системную инженерию, и тут мы на коне. Но вот ее недоверчивость играет здесь против нее. Но что-то человеческое в ней есть, не все потеряно".
Глава 2, в которой компания начинает зарабатывать, все при этом разругались, а Донна пытается втихую кинуть всю команду.
Лидия сидела и ждала очной встречи со своим руководителем, старшим вице-президентом Виком Донаги. Вик как обычно опаздывал, от выделенного ей времени оставалось 7 минут. "Привет, Лидия, рассказывай", - как всегда без особых вежливостей бросил он. "Проект по разработке универсального автопилота для нескольких автомобильных платформ, у которых есть подходящий набор опций. Модуль планируем производить с China Robust Circuits и поставлять автопроизводителям. На заводах поставят станцию, где рабочие CRC будут устанавливать модуль автопилота в автомобиль. Послепродажное обслуживание и гарантии производителя тоже на них. Есть рабочий прототип, который сделал стартап, мы купили этих ребят. Последние 2 месяца они не могут договориться с CRC по конфигурации, производственному процессу и себестоимости установленного в автомобиль модуля". "Почему?" "Постоянный пинг-понг. Посылают очередной вариант конструкции, китайцы выставляют ценник и такт тайм операции, он нас не устраивает, и мы начинаем разбираться, делаем новый вариант, и все идет заново". "Производственников привлекли?" "На той неделе в пятницу группа Ковальски переехала к нам в офис и с сегодняшнего дня стартуем DevProd, будем решать совместно". "Проект, который отстает по срокам, обязательно превышает бюджет, - сказал Вик и выразительно посмотрел на Лидию. - Останови кровотечение".
Лидия вышла от Вика и позвонила Викраму: "Расчищай свое расписание на три дня, привози пять смен одежды и организуй доставку еды в офис, мы будем писать план". Лидия встряхнулась, она любила такие напряженные периоды работы с четким результатом в конце.
Прошло 5 месяцев. Викрам проехался на колесе по пустынным улицам задолго до восхода низкого осеннего солнца, и зашел в офис даже раньше обычного, на часах было в 6:31, здание только-только открылось. Лифты и холлы еще домывали и в офисе пахло чистящим средством. Он прошел в офис и телефон подцепил корпоративный Wi-Fi, тут же начала приходить сообщения в Slack. 16 непрочитанных сообщений, первое в 2:34. Викрам даже читать их не стал, захлопнул ноутбук и пошел в лаунж пить кофе и завтракать. Почистил фильтр кофе-машины, засыпал свежесмолотый из мельницы, залил воду и поставил его вариться. В холодильнике лежали чьи-то вчерашние суши, он выложил их на тарелку и медленно съел. К семи стал подтягиваться народ. "О, ты что, не уходил?" "А ты что, опять в машине уснул, выглядишь фигово". "Кофе свежий?" "Да, но легче тебе не станет". "Дай мне предлог еще 10 минут почту не открывать, я прошу тебя". "Вот тебе полтора литра предлогов, не замучайся только в туалет бегать". Наконец он закончил утренние ритуалы, и приступил к разбору переписки, чтобы окончательно проснуться и отвлечься от легкого запаха перегара, который шел от каждого второго - офис работал в режиме 12 на 6 и многие стали расслабляться после работы в барах. Начал он с простого, руководитель отдела разработки бортового ПО не оплатил работу очередного консультанта и тот писал очередное гневное письмо с требованиями заплатить за работу. Викрам в очередной раз вспомнил первый принцип консультанта, которому его научил еще его научный руководитель: "Если консультации или покупка не забюджетированы, то денег на них не найдется, несмотря на уверения любых людей". В который раз этот принцип доказал свою правильность, Викрам уже не мог посчитать, до такой степени это было правдой.
Вот это уже интереснее - очередное сообщение в переписке "DevProd:103 - цифровой двойник или цифровой макет?" На этот раз инженер по валидации цитировал три контрактных требования с их подробным анализом, где со ссылкой на стандарты довольно убедительно показывал, что если они сделают обычную цифровую тень автомобиля с их модулем и реализуют механизм выборочной передачи данных из PLM раз в месяц, то требования будут высланы. Поскольку DevProd уже три месяца препирался с заказчиком, автомобильным концерном, и с центром сертификации насчет условий омологации и сертификации типа, а бюджета и главное квалифицированных людей сильно не хватало на задачи, то сообщение было сильно в тему и он его перенаправил письмом личному помощнику Фрэнка, руководителя проекта, с пометкой "отработайте с юристами и проектным офисом по-полной, там есть зацепки".
"Запрет на передачу курительных пропусков посетителей сотрудникам". Безопасники опять кого-то поймали? Лучше бы уже выдавали пропуска хотя бы за пару дней, а не неделю. Тут всплыло напоминание: "Трекинг проектных закупок в Primavera". Это опять старая проблема, как отслеживать комплексные поставки в проектном офисе. Чего-то там не хватало в функционале, ведомости материалов и оборудования, что ли не могли ввести, в результате отслеживались только лоты, а то ли пришло или нет, приходилось разбираться вручную. Первую очередь завода строили вовсю, поставок было много, проектный офис и логисты сидели допоздна и постоянно вешали систему своими запросами. Ладно, еще 15 минут до этого, успею почитать переписку и повестку.
После встречи он засел с планировщиками и уточнял планы на ближайшие две недели, потом сел закрывать табели рабочего времени. У технологов опять были сверхурочки, они шли с перерасходом бюджета 18%. Викрам решил все-таки разобраться, в чем дело, и залез в отчетность по проделанной работе. На первый взгляд ничего подозрительного не было, скорость работы упала по сравнению с летом, но люди в самом деле устали и работали медленно. С другой стороны, обычно к середине проекта скорость должна расти, потому что все притерлись, процессы выстроились. Он решил посмотреть коммиты в хранилище. И вот тут был сюрприз, потому что на выходных технологи выпускали столько же документов, как в остальные пять дней, а то и больше. Он вызвал к себе руководителя технологов и выторговал ограничение по сверхурочным, так, чтобы к концу года превышение было не больше 7%. А уж кому давать сверхурочные и как решать проблему с мотивацией - это не его, Викрама, дело. Он посмотрел в окно, Солнце уже садилось, а он даже не пообедал.
В столовой выбор блюд еще был, видимо, эта пятница у всех выдалась напряженной, поэтому вид подноса его радовал. Да еще и любимый столик не был занят, и Викрам сел прямо у панорамного окна и молча ел, смотрел на парк и пытался отключиться от навязчивых мыслей и постоянно звонящего телефона. "12,000 замечаний к рабочей документации завода - что будем делать?" "Омологация и сертификация - проблемы с типом А21". Тут всплыло напоминание о совещании "3D и BIM модели из чертежей". Он начал вспоминать о чем оно. Ах, да, точно. Генподрядчик строительства завода не мог сам создавать 3D модели, которые требовались по корпоративным стандартам заказчика, автомобильного концерна, для одобрения производства. При этом на стороне AnyCorp никто не понимал, что делать с этими 3D моделями. Строителям они были не нужны, потому что они строили по печатным версиям чертежей, эксплуатации тоже было не нужно, хотя реестр оборудования и поверочных сертификатов их вроде в последний раз заинтересовал, производство готово было попробовать имитационное моделирование техпроцесса, но этих данных в модели не было. В общем, надо заложить в бюджет работы по оцифровке чертежей, найти подрядчика. Но в ходе совещания выяснилось, что все не так просто, потому что непонятно, как отлеживать версионность моделей, получается, что надо вносить доработки в рабочие процессы отдела контроля инженерной документации, чтобы как минимум во время аудита все это не вылезло. Руководителя отдела на совещании не было, по телефону он ответил, что посмотрит, но никаких обязательств, люди перегружены, а сверхурочно они работать не будут, семья для некоторых важнее работы.
19:00, вечерний стенд-ап. Основная тема - логистика второго инкремента проекта. Ключевая проблема - опять много поставщиков везут много грузов по узкому месту, где не хватает грузовиков, складов, места. На связь выходит логист с распредцентра, жалуется по Скайпу, что грузовики приходят полупустые, а стоимость логистики слишком высокая. Короткое бурное обсуждение и все понимают, что из-за несогласованности действий разные логисты в разных подразделениях законтрактовали разных перевозчиков, те, в свою очередь, стали перехватывать друг у друга фуры и дронов, в результате транспорт загружен на 40% в объемах и на 97% в ресурсах. Выход предложили быстро - вводить логистические данные в PLM при проектировании. Вопрос как всегда кто будет делать. Проектировщики послали всех сразу, показав, что у них загрузка 97%, и очереди разработки уже 3-4 месяца, каждый лишний процент загрузки означает, что все будут ждать проектных решений еще дольше, поднимите руку, кто за. Служба справочных данных повторила аргументацию проектировщиков и потребовала расширения штата в очередной раз. Предложили стороннего оператора, некую Nawinia, они вроде специалисты в проектной логистике. Но денег на них в бюджете не заложили, поэтому чем все это закончится Викрам знал, и портить карму дальше ему не хотелось. Все впали в ступор и опять всплыл вопрос с 12 тысячами замечаний - что с ними делать? "И ведь на исполнительной будет не 12, а 120,000", - пророчествовал руководитель проекта Фрэнк. Он был настоящий козел. Так и разошлись, ничего не решив.
Викрам подводил итоги дня и рассылал отчетность. Технический долг продолжал расти, требования закрывались медленнее, чем надо, график и бюджет срывались, но пока не критично. План сдерживающих мероприятий и управления рисками неудержимо рос. И тут пришло приглашение от Лидии: "Празднование вехи С. Выход в операционную прибыль. Присутствие обязательно для всех". 15 этаж, воскресенье в 14:00, такси и перелет оплачивается, засчитывается как рабочее время. Викрам автоматом прикинул стоимость мероприятия и погрустнел. Лучше бы наняли пару человек в службу справочных данных. Решения Лидии его очень часто разочаровывали, 9-bis и AnyCorp сильно расходились в стратегиях. Он вызвал диспетчер отработанного времени - 21:00, 14 часов 27 минут отработанного времени, сверхурочные 108 часов за последний месяц, это значит почти тройной оклад, очень даже неплохо. Пора ехать домой, чтобы хотя бы выспаться. Странно, раньше его намного меньше волновали деньги, это, видимо, влияние постоянных разговоров о деньгах и кэше на собраниях с Лидией. А на собрания инженеров, где говорили о продукте, а не о деньгах, сроках и обязательствах, он уже почти не бывал. Он оглядел рабочее место перед уходом, проходя чек-лист ухода с работы, который всплыл после того, как он вышел из системы. Последний пункт чек-листа был "Честно ответьте себе, заплатили ли бы вы себе зарплату за сегодняшний день на месте работодателя?" Викрам даже головой покачал. Со стены кубикла на него смотрела вся команда 9-bis на февральской выставке. Тогда казалось, что покупка их стартапа крупной корпорацией- это что-то очень хорошее и многообещающее. Но это оказалось не так. И дело было даже не в 70-часовой рабочей неделе, или в 90-часовой, в его случае, работать он привык. Но то, к чему они приближались, не походило на успешный проект. Не по меркам 9-bis.
Когда Викрам пришел на встречу в конференц-зал на 15 этаже, там уже сидел незнакомый парень в футболке Space Invaders и с огромными часами Fossil. Кто-то совсем незнакомый, наверное, новенький из офиса Лидии, она любит помощников-азиатов из-за их сумасшедших рабочих часов, за которые еще и платить не надо. Викрам поздоровался с ним и сел разбирать сообщения. Зашел Фрэнк: "А чего совещание на воскресенье поставили?" - "Так свободного времени не было ни на какой другой день, я так думаю. Что там насчет проектной премии?". "Так мы три недели назад должны были веху С пройти, какая теперь премия?" "Подожди, должна же все равно быть?" "15%, что ли будет, не больше. Я думаю, с нашим объемом сверхурочных мы вряд ли HR прожмем хоть на какую-нибудь премию, у нас перерасход по статье персонала". "А что с отчетностью по проекту?" "Вик Донаги доволен и это все, что тебя должно волновать, приятель". "Еще бы он не был доволен, даже премию платить не надо". "Ты вроде тоже все бюджет зажимал?" "Да у меня борьба то за людей то за бюджет. Колеблюсь вместе с линией партии". Начали приходить люди и Викрам стал разговаривать с подходившими, уточнять, ободрять и знакомить людей друг с другом, чтобы бесконечные переписки закончились уже очным решением проблем.
Тут все замолчали, потому что пришел Вик. Сосед нагнулся к Викраму: "Смотри внимательно, мы видим вице-президента в первый и последний раз". Выступление было классическим - очень зажигательным и артистичным, но после него ничего не стало понятнее кроме того, что топы выпишут себе премию и сделают презентацию на совете директоров. Из зала было пара острых вопросов, например: "Вы говорили, что в компании идет программа по управлению знаниями и талантами. Как мне получить продвижение?" Донаги ответил: "Есть только один способ получить продвижение - вовремя узнать о позиции и вовремя поговорить с нужными людьми. И это все зависит только от вашего нетворкинга". Голос из зала начал было полемику в стиле "а зачем тогда вообще нужна программа, если все остается по-старому, но его быстро заткнул то ли начальник то ли коллеги". Донаги ушел, и на сцену вышла Лидия. Она начала:
"Мы начали антикризисный проект в подразделении DevProd пять месяцев назад. Это были сложные и трудные пять месяцев, и у нас была сложная цель - выйти на окупаемость. Руководство, как вы видели, оценило наши усилия". "Премии будут?" - выкрикнул кто-то из зала. "Все в соответствии с исполнением ваших КПЭ". "То есть, не будет премии", - подытожили сзади. "Но не только руководство признало наш результат, его заметил и наш производитель, знакомьтесь с мистером Ли. Вы знаете, как эта история выглядела со стороны AnyCorp и вашего отдела, а мистер Ли расскажет нам, как все это выглядело со стороны производителя". И на сцену поднялся тот самый китаец или кореец в футболке Space Invaders и часами Fossil. Он рассказал про подготовку опытной производственной линии, которая начала работать 1,5 месяца назад на заводе заказчика, который собирал sport station wagon. За это время они практически отладили монтаж модуля на эту модель и разработали технологию, которая позволит работать в такте 240 автомобилей в смену, это текущая производительность этого завода по данной модели. Дефектов уже почти не осталось, сертификацию они вот-вот пройдут, всем спасибо, это замечательный проект, а теперь еще и прибыльный. "Да откуда прибыльный, откуда мы это знаем, с нашим-то учетом?" - кто-то явно был разражен донельзя. Викрам привстал с кресла и обернулся. Это был ведущий инженер по силовой установке. Лидия вовремя прервала волны негодования, свернула беседу, и начался фуршет. Команда быстро разбилась по отделам и своим тусовкам, никаких ранее обычных групповых обсуждений в этот раз не получилось. Только Викрам успел съесть пару клубных сэндвичей и тарталеток и выпить бокал безалкогольного мохито, как его отловила Лидия. "Спускайся вниз, там будет автобус Мерседес, номер 747, как самолет. Садись в него, едем ко мне в загородный дом".
За окном мелькал город, потом они въехали в лес и остановились у ворот закрытого поселка, прямо у самой реки. Солнце уже садилось и лес быстро темнел. Команда почти не говорила, все сидели, уткнувшись в свои телефоны, кто-то дремал. Водитель провел их мимо коттеджей в западный угол поселка и показал на апартаменты Лидии на втором этаже. Деревянная лестница слегка скрипела под ногам, когда они поднимались, но сами домики выглядели очень даже ничего. И от офиса всего 25 минут, если без пробок, неплохо босс устроился. В комнате уже сидела вся команда управления проектом, и даже китайский поставщик приехал.
"Парни, давайте выложим рыбу на стол, - начала Лидия. - Чем вы так недовольны кроме рабочего графика, но я не думаю, что проблема в нем?" Все молчали, никто не хотел начинать, а Лидия держала паузу, она была опытным переговорщиком и знала, что молчание - золото. Не выдержал главный технолог: "Проблема в том, что проект проваливается, а мы тут перед начальством видимость успеха создаем". Лидия молча смотрела на команду и до нее доходило, что технолог и впрямь выразил общее мнение. Только Фрэнк был не согласен, по его позе это было абсолютно ясно. Фрэнк отслужил 15 лет по контракту и субординация была в его крови. Но на одной лояльности этот проект не вытянуть. "Я что-то не поняла, - уточнила она, - вы что, считаете, что Вик слукавил и на самом деле хочет закрыть проект?" "Причем здесь Вик?" - удивился технолог, и это опять было общее мнение. Лидия не понимала, она четко связывала успех с тем, как проект воспринимал ее босс. От чего еще он мог зависеть? Но переломить мнение команды за один раз нельзя, и это направление дискуссии опасно. "Мы обязательно сегодня обсудим ваше понимание что такое успех, но давайте вспомним, с чего все начиналось". Технолог не унимался: "Начиналось все с того, что вы с Викрамом провели антикризисный аудит проекта и сказали, что рамки проекта слишком широкие, что мы сейчас решаем слишком большие проблемы. И все текущие проблемы, из серьезных, есть следствие того урезания содержания проекта. Давайте я повторю просто пункты вчерашнего протокола собрания по прогрессу проекта. У нас объем проектирования на следующую модель ничуть не меньше, чем на первый образец; у нас огромный технический долг; мы вообще не понимаем состояние реализации спецификации требований, я уж не говорю про качество самих требований", - и он замолчал, потому что подключились другие. Галдеж продолжался еще пару минут, пока Лидия не прервала жалобы. "Когда я вначале дала две недели на определение содержания антикризисного этапа и поставила эти задачи менеджерам, чем это все закончилось? Менеджеры отдали все на откуп инженерам, устранились от принятия решения. Да, я приняла решение потому что его не принимали те люди, которые должны это сделать". "Лидия, при всем к вам уважении, когда вы принимали эти решения, вы работали с вашими гипотезами и предположениями как с фактами, вот в чем проблема". "Проблема в том, что руководители не приняли решений, которые должны были принять. Проект требовал жесткого руководства". "Жесткое руководство - слишком общие слова. Как бы вы поступили на месте менеджеров?" "При чем здесь как бы я поступила? Я и так была на их месте и как я поступила вам всем известно". "Давайте я уточню свой вопрос, раз уж мы выкладываем рыбу на стол. Критические решения, которые надо было принять на тот момент, были техническими. Вы их не приняли, вы просто выбрали в тот вариант дизайна, который вам больше понравился". "Не понравился, а был больше обоснован". "Если бы он был на самом деле лучше обоснован, мы бы договорились сами. Просто Егор звучит убедительнее, чем Юси, вот и все. Он, блин, русский, который работал в Британии 9 лет. Конечно он будет убедительнее финна, если не разбираться в сути вопроса, а смотреть на внешние проявления. И такое повторялось несколько раз, в разных комбинациях". К критике подключился руководитель разработки: "А переход на Agile-trains, где все решали производственники? Я на прошлой неделе поднимал протокол со своим особым мнением, которое я озвучил на совещании по запуску этого перехода, и 9 из 10 моих возражений оправдались". "Вот тут я уверена на все сто и то, что какие-то опасения оказались правдой ничего не меняет. Вы своими темпами еще год бы проектировали, я уж не говорю о том, что через 5 месяцев получить прибыль от работающего производства. Кому какое дело до долгосрочной правоты, если вас закроют из-за отсутствия результата прежде чем вы получите результат, который можно показать руководству? No money, no honey, вы думаете я зря вам эти браслеты раздала на стартовом совещании? Прибыль и денежный поток прежде всего". "Да что вы так уперлись с этой прибылью? Мы выкатываем плохой продукт!" "Это бизнес, парни, а не парк развлечений для инженеров. Честно говоря, это я тут вас выслушиваю с вашими представлениями о качестве инженерной работы, профессиональной гордости и прочей ерундой. В головном офисе это готовы терпеть, если есть прибыль, но такие разговоры не прокатят, если вы развлекаетесь за бюджет работодателя". В доме повисла тишина, постепенно все даже жевать и пить перестали. Лидия внимательно смотрела на свою команду. Кажется, она донесла свою точку зрения. Но руководитель разработки не сдавался.
"Эта прибыль есть только в моменте, пока покупатели не поймут, что мы не можем быстро выпускать модификации, устранять дефекты, улучшать надежность". "Кто вам мешает, теперь, когда проект приносит прибыль, у вас есть время на это, устраняйте". "Да с этой архитектурой продукта, к которой мы пришли с постоянными заплатками и временными решениями мы только заплатки можем ставить, а про развитие продукта даже говорить не стоит, там все работает ровно в той конфигурации, в которой мы проверили. Я же говорил про технический долг. Мы ведь отстаиваем хорошую архитектуру и правильные наборы требований не из-за эстетического удовлетворения". "Ой, да правда что ли? - Лидия просто взбесилась. - Да когда я пришла на проект, вы все сидели и только и делали, что в диаграммы смотрели да обсуждали их на собраниях. Работа стояла". "Мы с таким подходом за год сделали работающий прототип, который лучше всех на рынке на две головы, это что-то да значит в вашем мире, Лидия? Или это случайность и нам повезло?" "Это подход, который работал, когда вы делали концепт. В производство такими темпами не запускают". "То есть, вы считаете, что планирование и размышления над планами, диаграммами и схемами - это только для стадии разработки концепции?" "Типа того, да. Дальше, когда в проекте начинают работать сотни людей, планы становятся неактуальными и все эти построения просто бесполезны. Надо просто делать и корректироваться по ходу". Опять длительная пауза, во время которой руководитель разработки что-то искал на своем компьютере. Наконец он выдал: "Вот отчет по зрелости процесса разработки от нашего аудитора. Одни и те же консультанты проверяют нас третий год подряд, так что есть, что сравнивать. В Феврале у нас был CMMI уровень 4, сейчас мы скатились на второй. И знаете, что сказал главный консультант не под протокол? Что мы потеряли всяческую организацию за удивительно короткий срок". "А что-нибудь, кроме обычного консалтерского бла-бла-бла в отчете есть?" - наконец встал на защиту Лидии Фрэнк. "Конечно есть. К примеру он пишет, что задокументированный процесс внесения изменений в конструкторскую документацию не соответствует описанному процессу и настроенным рабочим процессам PDM". "Консалтерское бла-бла-бла, как и было сказано", - ухмыльнулся Фрэнк. "Ну, давайте переведу на понятный язык, - вмешался Викрам. - Вот поднимем график проведения собраний с прошлой недели и протоколы". Он открыл свой календарь, весь раскрашенный в разные цвета, с множеством накладывающихся друг на друга блоков, и открыл блок Нейрокода, но уже в строгой синей гамме. "Смотрим. Вот совещания на этой неделе. Складская логистика, потом цепочка поставок, продажники и маркетинг, интеграторы, программисты, железячники и группа запуска. Видите?" "На что мы смотрим?" - спросила Лидия? "На пункты повесток и задачи из протоколов". "Ну, что мы должны в этом увидеть? Пункты задач, мы все про них знаем", - Фрэнк тоже начал злиться. "Они не связаны между собой. Все проводят совещания только по своим пунктам в рамках своих зон ответственности". "Ну правильно, своих дел хватает, чтобы еще чужими заниматься". "Да, но в моделях процессов у нас есть стрелочки между этими функциональными блоками. То есть пункты повесток этих собраний должны быть связаны, а в протоколах должны быть задачи не только своему подразделению, но и смежникам. Про это мы и говорим - когда мы сидели и планировали совместную работу на диаграммах, мы очень много взаимодействовали между функциями, ставили друг-другу задачи, процесс у нас был сквозной, а не ограничен рамками отдела, как сейчас". "Давайте по-простому, Лидия. - встал главный программист. - Сейчас бардак с организацией и мы отдельно договариваемся по тому как сделать работу и отдельно по тому как отчитаться. И отчетность перестала адекватно отражать то, что происходит в проекте. Работаем мы не по методу, как привыкли, а как придется, в результате не можем улучшать работу, не можем нормально планировать и давать обязательства". "И что? Почему меня как руководителя должно это волновать пока вы даете нужный результат?" "Да где мы даем нужный результат?!" - завелся было технолог, но Викрам остановил его.
"Давайте я объясню все без технического жаргона. Без всех этих валидаций, технического долга и прочих вещей, которые могут запутать понимание. Представьте, что вы управляете туристическим агентством и вам надо организовать поездку для группы по какому-то довольно сложному маршруту, с перелетами, автобусными поездками, размещением и питанием. Есть два способа управлять принятием решений. Вы можете принимать во внимание мнение только одного человека, например, спонсора этой поездки или неформального лидера группы, либо вы можете балансировать интересы так, чтобы не было особо недовольных. И вот, вы везете людей по маршруту и вас подводит перевозчик, дает автобус меньшей вместимости, так что люди влезут, а багаж пока останется в отеле, и его надо будет перевезти позже. Ничего особо критического, если часть вещей вы довезете завтра, а оставшиеся в течение пары дней. Вот непривезенный багаж и есть метафора технического долга. Мы пообещали привезти все, но привезли только самое важное. У нас в проекте сейчас все больше непривезенного багажа, а кое-где и пассажиры в пути остались, и мы даже не знаем, не потерялся ли кто сейчас, потому что группа большая, путь длинный, а отчетность не отражает того, что в нашей поездке происходит". "Метафора страдает. - ответила Лидия. - В поездке у нас есть манифест и мы точно знаем количество пассажиров, маршрут, условия обслуживания. С качеством и тем, как его мерить, все понятно. А тут мы сами себе хозяева, так что вариантов привезти всех в пункт назначения куча и все они будут успешными". "Ну, не совсем так. У нас есть спецификация продукта, она является частью контракта поставки заказчику и мы должны ее выполнить. И вот метод управления поставкой продукта и метод управления проектом как раз позволяют предсказать, хватит ли тех ресурсов, которые у нас есть и которые мы можем достать, для реализации спецификации продукта и выполнения планов проекта. Возвращаясь к нашей метафоре - вот смотрим мы на остатки туристических сборов, на текущие расходы и плановые расходы, на расценки перевозчиков, на ставки аренды и зарплату сотрудников, и понимаем, в плюсе мы с поездки или в минусе. Но если всего этого нет и вы просто везете туристов, не глядя на цены, маршруты и затраты, то да, в середине поездки у вас лидер группы может быть очень довольным, потому что все очень круто, вы останавливаетесь в хороших отелях, обедаете в хороших ресторанах, но вот скоро вы обнаружите, что деньги кончились и ваша группа осталась в горах без денег, медпомощи и обратных билетов. И наш проект скорее попадает в эту категорию". "А почему я слышу про спецификацию продукта только сейчас?" - Лидия на самом деле ничего про нее не помнила. "Ну, обычно ее реализацией занимаются инженеры и менеджеров сама по себе она не очень-то и волнует, им важнее исполнение планов проекта и выполнение контрактных обязательств, а это довольно далекие от спецификации материи". "Ладно, со спецификацией мы разберемся на следующей неделе. Теперь объясните мне как вы предлагаете исправить ситуацию и что такое успех проекта в вашем понимании?" "Вначале я объясню, что такое схема, когда мы говорим про восприятие успешности проекта. Вот представьте, что вы едете на машине по трассе из столицы в регион. Выехали вы с полным баком и проехали 300 км, индикатор показывает, что осталось еще 50% бака. Вам надо принять решение заправляться. Чем дальше в регион вы выезжаете, тем дешевле топливо, поэтому чем позже вы заправитесь, тем больше сэкономите. Когда вы заедете на заправку?" "Ну, условно, через 280 км". "Видите, это сработала ваша схема. Вы использовали ее для предсказания того, что будет в будущем и можете принимать решение прямо сейчас, а исполнять это решение потом. Да, это очевидно, я знаю, поэтому немного усложню задачу. Теперь вы знаете, что чем дальше вы отъезжаете от столицы, тем больше вероятность того, что топливо будет плохое, разбавленное и вам его недольют. Это повлияет на работу вашей схемы и вы заправитесь раньше. Так вот - и в том и в том случае вы свою заправку посчитаете удачной, нормальной, хотя в одном случае вы заправились раньше и дороже, а во втором случае позже и дешевле. Реальность не изменилась, это все те же заправки, те же риски. Меняется только ваше восприятие реальности, ваша схема предсказания. Для того, чтобы сделать сложную штуку типа нашего автопилота, нам надо много разных людей, у каждого из которых своя схема предсказания, которая работает в рамках его специальности, его дисциплины и технологии. Викрам вон системный инженер, я разработчик ПО, там вон сидят ребята, которые отлично разбираются в обработке видео с камер и его сжатии на лету. У всех свои схемы, и все по-своему предсказывают будущее. Так вот, успех - это когда никто не видит очевидного провала. Никто, а не только человек, который выписывает чеки". "И что, вы предлагаете мне увязывать видение успеха проекта всех 200 человек, которые в нем участвуют? Это невозможно!" "Ну, и да и нет. Фактически, есть три группы проектных и процессных ролей. Есть инженеры, которые видят успех в реализации продуктовой спецификации. Есть менеджеры, которые видят успех в выполнении всех контрактных работ в рамках имеющихся ресурсных и временных ограничений. И есть продажники с производственниками, которым важно, чтобы были выполнены планы продаж и клиент был удовлетворен при использовании продукта. У каждой группы есть свой метод, свой набор схем, с помощью которых они предсказывают будущее, оценивают успешность проекта. Есть метод управления поставкой продукта, есть метод управления проектом. Успех - это когда метод отражает схемы всех трех групп и мы следуем методу". "Ох, парни. Еще раз - что вы практически предлагаете сделать? Вернуться к методической работе, которая у вас была?"
"Да, но с одной существенной доработкой - нам нужно дополнить метод вашей схемой и схемой Вика Донаги, иначе успеха нам не видать". "То есть, мне надо вытащить схемы из головы Донаги?" "Точно". "И бунт на корабле прекратится?" Лидия внимательно оглядывала команду, нет ли несогласных с решением. "Но вы, парни, забыли еще про одну проектную роль - это изготовитель. Позвольте представить вам Стэна Ли, нашего КАМа на заводе-изготовителе". И к ним вышел тот самый азиат в Space Invaders и с Fossil на руке. Завязалось бурное обсуждение планов, обстановка была разрежена. Лидия накинула плед на плечи, вышла на улицу, зажгла сигарету, затянулась и посмотрела на звезды. Как обычно, не смогла найти Полярную звезду и вздохнув, достала телефон и набрала Вика Донаги. Трубку он не взял, и она оставила ему сообщение: "Вик, привет. Я свою часть сделки выполнила в срок. Хочу уточнить, поставил ли ты вопрос с моим повышением на совет директоров как мы договаривались. Секретарь СД ничего мне не отвечает. Жду ответа". Потом позвонила Донне, тоже автоответчик: "Донна, ты гений мотивации. Команда купила все без остатка и попросила добавки. Организуй мне 360 как можно скорее, момент подходящий и результате мне нужны для совета директоров, скоро будет слушание". Последняя затяжка, черт, где же эта Полярная звезда?
Сцена 3. “Что такое правда и удивление”.
В понедельник Лидия впервые за последние пару месяцев выспалась. Вик пригласил ее к 10:00 и в офис она вошла в 9:50. На телефоне было 12 не отвеченных вызовов, но ничего важного, хотя кто-то настойчивый с неизвестного номера набирал 5 раз. Но Лидия не хотела пока сбивать себе настрой перед важной встречей. "У себя, ждет," - знаками показал ей личный помощник Вика, и она открыла дверь. И тут у нее появилось очень нехорошее предчувствие. Кроме Донаги в его огромном кабинете сидела еще Донна, с ней было понятно, такие разговоры без HR не происходят, а вот кто был высокий мужчина австралийской внешности в темно-синей поло и светлых штанах? На безопасника не похож, но и на внутреннее расследование тоже. Странный тип, совсем не в стиле AnyCorp. Начал диалог Вик: "Это Рональд, наш независимый внешний аудитор по технологическим проектам. Мы с ним работаем уже 12 лет". "Можно просто Рон", - протянул тот руку. Пожатие было твердое, уверенное, легкая улыбка очень уверенного в себе профессионала, который пришел с плохими новостями. На поло крокодил Lacoste атаковал таксу Harmont & Blain, такса огрызалась. Человек с юмором, а новости явно плохие. Лидия села в кресло и оглядела присутствующих, ей пришлось глубоко выдохнуть, чтобы не перейти в агрессивную защиту. Сейчас надо быть крайне осторожной. Она расслабила тело и искреннее улыбнулась. А, вспомнила, Рон же бывал несколько раз в ее офисе и ей даже говорили, что он какой-то там контрактор, это было полтора месяца назад, значит, она уже давно находится у него в разработке. Хорошо, держим это в уме. Вик кашлянул: "Лидия, ты не можешь уйти с проекта". Здесь надо удивленно вздернуть брови, пусть будет спектакль по-полной: "То есть, повышения пока не будет? Почему?" Вик был финансист, эмоциональный интеллект не был его сильной стороной, и по его лицу явно можно было прочитать искренний ответ: "Повышения не будет никогда". Но вслух он ответил: "Рон сейчас объяснит почему". Лидия обернулась к Рону: "Рон, объясни, как так получилось, что руководитель проекта DevProd не знает, что на его проекте идет аудит?" "Все объясняется просто. NDA, соглашения о неразглашении. Ключевые сотрудники подписали секретное соглашение и участвовали в аудите на условиях этого соглашения". "А встречались вы в секретных бункерах нашего инфобеза?" "По большей части в окрестных кафешках, в бункерах только записывали важные показания для возможной комиссии". Донаги хмыкнул: "Это стандартная практика, Лидия, ты знаешь об этом. Мы даже офисные разговоры не прослушивали, хотя у Донны есть на руках все основания, чтобы затребовать эти записи и приобщить их к делу". Лидия помнила, что записи хранятся 3 года и Вику некуда спешить. Но если Донна на их стороне, то дело совсем худо. "Давайте послушаем вас, Рон", - Лидия повернулась к нему с улыбкой. Рон вывел на настенную панель график с освоенным объемом проекта. "Это график освоенного объема и он не отражает реальности. Если судить по графику, то отставание по срокам 7%, а перерасход по бюджету 12%. В реальности все как минимум в 3 раза хуже". "Этот график формируется автоматически системой, Рон, вы в курсе? Так что не обвиняйте меня в ошибках проектного офиса, пожалуйста". "Нет-нет, конечно, Лидия. Я знаю об ошибках проектных офисов и манипуляциям с отчетностью почти все, и излагаю только неоспоримые факты. Так вот, как считается освоенный объем на проекте DevProd? При авторизации нового пакета работ, при его открытии, на освоенный объем списывается 50%. То есть, когда вы начинаете работу, по отчетности получается, что вы уже половину работы сделали. Нормально ли это? Да, это нормально. В проекте 340 пакетов работ, поэтому ошибка отчетности при таком подходе (1/340*2)*100%=0.15%. - Он записал эти расчеты на флип-чарте, остановился и осмотрел всех, затем продолжил. - Но только при условии, что авторизованный пакет работ закрывается, а не висит незавершенным. Другими словами, если вы используете такую методику учета, то надо отслеживать динамику незавершенной работы". И он вывел на экран следующий график с надписью Design-in-Progress. У Лидии замерло сердце потому что она поняла, что именно этот график исчез из отчетности 2 месяца назад, и она этого не заметила, потому что появилось много других отчетов о запуске производства, а истинное значение этого графика о незавершенной работе она до этого момента не понимала. Рон продолжал: "Видите этот пик 6 недель назад? Резкий рост количества авторизованных пакетов работ. Я наложил его на график освоенного объема и выделил только промежуток 2 месяцев, обратите внимание на этот отчет (он обвел его красным маркером). Создается четкая и убедительная картинка того, что команда поднажала и стала наверстывать опоздание. Но на деле, посмотрите на показатели скорости работ (он обвел другой график зеленым) - они снижаются 4 месяца подряд во всех командах. Исключение составляет команда системных инженеров, руководитель этой группы Викрам, фамилию я не могу произнести, извините". "Майтхилишаран. Викрам Майтхилишаран". - Лидия помнила всех лидов. "Неважно. Я привел этот случай с отчетностью как наиболее явный и понятный, хотя есть еще 3 аналогичных несоответствия и с десяток поменьше. Полный отчет о состоянии проекта в этой папке", - Рон открыл сумку, достал оттуда нетолстую, но достаточно увесистую папку и передал ее Лидии. "Вик попросил не убирать из отчета ничего, здесь полная версия. Записи интервью и расшифровки я передал вам на SecurePad, тоже можете ознакомиться". Заговорила Донна: "Для протокола. Лидия не отстраняется от управления проектом. На время разбирательства отчетность проектному комитету будет проходить не 1 раз в месяц по упрощенной процедуре, а каждую неделю по полной. Документы об изменениях в управлении проектом направлены на SecurePad Лидии". "Собрание прошу считать оконченным", - Вик встал из кресла и показал всем на выход. Лидия держалась прямо и свободно, дышала диафрагмой и контролировала походку. Рон смотрел ей вслед с сожалением.
20 минут спустя она сидела в греческой забегаловке недалеко от офиса и ковыряла вилкой остывавшую питу. Отчет Рона она уже прочла и ситуация на проекте была ясна. Наконец в кафе зашла Донна, она была на взводе: "Какого черта, Лидия, ты почему трубку не берешь?" "Не знала, что это ты, извини". "Не буду же я тебе со своего личного телефона звонить, чтобы предупредить о дисциплинарном слушании". "Да, ты права. Но давай подумаем, что делать". "Тебе надо вытащить этот проект, тогда дело можно будет закрыть". "Этот проект безнадежен". "Я знаю, но его надо вытащить, давай подумаем как". Но Лидия не хотела думать, она хотела пройтись по осеннему городу и подумать. И она не знала, можно ли верить Донне. Она точно не могла верить Вику и Фрэнку, Фрэнк, похоже, ее и подставил, хотя вряд ли по своей инициативе, вопрос, кто его попросил - Вик или Донна. Но, похоже, она могла верить Викраму, Викраму Майтхилишаран, руководителю группы системной инженерии, который ее предупреждал о критическом состоянии проекта и который предлагал ей выход. А других вариантов у нее пока не было, за неделю надо было показать прогресс, иначе следующей ее позицией будет дирекция по развитию во главе департамента из пяти человек, и максимум, что она будет делать - это презентация раз в месяц. И денег у нее будет намного меньше, в тот самый момент, когда они ей так нужны.
Она достала планшет, нашла сообщение Викрама с предложениями по реорганизации управления проектом и начала читать. Презентация была очень запутанной и сложной, единственное, что она поняла, так это то, что вместо функционального деления по отделам Викрам предлагал вернуться к сквозным процессам, которые были в их стартапе изначально. А дальше это все как-то связывалось с моделью жизненного цикла, ролевой моделью проекта, отчетностью. В общем, это было непонятно, такое в нашем цирке не сделать и никому не продать. "OK, Google, позвонить Викраму", - она отвернулась от проезжей части, чтобы ее было лучше слышно, и стала ждать, когда ей ответит слегка хриплый голос с сильным акцентом. Через 10 минут они сидели в комнате для совещаний бизнес-центра и обсуждали презентацию. "Я готова менять управление проектом, но чтобы это сделать, мне нужно перевыпустить устав. А, значит, его должен подписать Вик Донаги. И он не подпишет ничего того, что не понимает. Поэтому, если мы хотим изменить подход к тому, как мы управляем, надо рассказать, чем твоя схема управления лучше текущей". "Лучше тем, что текущая схема не работает". "Ты не понял. Вик консервативен. Текущее управление дает результат - мы запустили производство и начали продажи. На все предложения он просто скажет, что надо лучше стараться и больше работать, а не пытаться найти волшебное средство". "Это не волшебное средство, мы так работали и было намного лучше". "Во-первых, вас было всего 37 человек, а нас сейчас 280 только в команде плюс производство плюс поставщики и подрядные организации. И это тоже проблема, потому что сквозные процессы надо продать не только Вику, но и, к примеру, Стэну Ли". Викрам задумался и начал пояснять свою презентацию. Через пять минут Лидия его остановила: "Ты только больше меня запутываешь. Давай начнем с базовых понятий, например, ты вводишь какие-то функциональные процессы и сквозные процессы, в чем между ними разница? И когда будешь объяснять, представь, что у тебя на плече сидит маленький человечек, который слушает все, что ты говоришь и задает один вопрос - ну и что? Договорились?" - Лидия одобряюще улыбнулась и Викрам начал. "Начать надо будет не с определения что такое процесс, а с более базовой вещи, с объекта. Есть ли у вас зеркало в косметичке?". Лидия открыла сумку и протянула ему пудреницу. Викрам открыл ее, повернул зеркало к Лидии и задал вопрос: "Что вы видите?" "Себя, свое лицо". "А если точнее?" "Ну, точнее зеркальное отражение своего лица". Тогда Викрам взял в руки пульт освещения и начал убавлять яркость потолочных светильников. "Что происходит?" "Ну, отражение меняется, изображение становится темным". Викрам добавил освещение и переключил свет с холодного оттенка на теплый. "Ну, опять отражение изменилось". Лидии стало надоедать: "К чему ты клонишь?" "Почему твое отражение меняется?" - задал Викрам очередной вопрос. "Потому что ты меняешь характеристики освещения и конечно меняется отражение в зеркале". "А можете объяснить подробнее, что происходит? По шагам?" "Из лампы вылетает луч света, он падает мне на лицо, отражается от лица, попадает на отражающую поверхность зеркала, отражается от нее и попадает мне в глаз, где я его и вижу. Когда ты меняешь характеристики луча света, который вылетает из лампы - делаешь его сильнее или слабее, меняешь оттенок от холодного до теплого, то меняется и то, что я вижу. Так понятно?" "Да, спасибо большое, так понятно. Другими словами, есть ряд связанных между собой фактов - то, что я меняю свет лампы и то, что вы видите в отражении зеркала, и эти факты связаны между собой потому что так ведет себя луч света?" "Дурацкое какое-то объяснение, но да. Ты крутишь регулятор лампы, меняется отражение в зеркале. Как это нас пододвигает к обсуждению модели управления?" "А если бы мы спросили пятилетнего ребенка про то, почему когда крутишь регулятор лампы, меняется его отражение в зеркале, что бы он ответил?" "Ну не знаю, можно попробовать и спросить". "Но смог бы он объяснить это так, как объясняете это вы?" "Ну, наверное, нет, по крайней мере если не задавать вопрос Гуглу". "Смотрите, Лидия, здесь есть важнейший момент. Объект - это такая штука, которая связывает разные факты причинно-следственной связью. Я меняю свет лампы и вы фиксируете этот факт, и вы видите как меняется ваше отражение в зеркале и фиксируете этот факт. И в вашей голове строится логика - ага, эти факты между собой связаны с помощью луча света". "И что? Это и без луча света интуитивно понятно любому ребенку". "Да, но объект 'луч света' позволяет вам не просто строить причинно-следственные связи, он помогает вам предсказывать факты, которые вы еще не наблюдали. Допустим, представьте, что я возьму вот эту маленькую ложечку и буду закрывать ей светильник, что вы увидите? Вы увидите, что отражение понемногу темнеет по мере того, как я приближаю ложечку к источнику света. Ребенок, который не знает про основы оптики, скажет, что ничего не будет, потому что у него в голове нет хорошего, качественного объекта, который связывает эти факты между собой". "Ну хорошо. У тебя какое-то свое представление о том, что такое объекты, но допустим это так. Теперь вспомни про маленького человечка на твоем плече, который спрашивает тебя 'ну и что из этого следует?'" "Из этого следует одна важнейшая штука - от набора объектов в голове Вика зависит то, какие логические взаимосвязи он видит в мире. А так как успех - это когда ожидания совпадают с фактами реальности, то если мы будем знать, какие объекты, понятия есть в голове Вика, то сможем предсказать, какой набор фактов будет для него убедительным доказательством того, что мы даем дельные предложения". "Другими словами, ты хочешь сказать, что в целом любой объект как-то обобщает набор фактов в логический вывод. Если мы знаем, какие объекты, типа лучей света, есть в голове Вика, то мы понимаем его логику, и сможем представить твой набор предложений так, что Вику будет понятно?" "Точно!" "Тогда возникает два вопроса. Первый - как получить этот список объектов. Второй - не все так просто, нельзя свести определение успеха проекта к одному объекту". "Ну да, предлагаю вернуться к начальной схеме, которая описывает весь метод управления проектом".
Я помню, как мне в руки попал первый iPhone. Единственное, что я сразу понял - это как с него звонить и писать СМС. Все остальное было загадкой - приложения, карты, видеозвонки, календарь, синхронизация с компьютером. Я даже не мог послушать с него музыку, потому что в iPhone нет папок и файлов, и я не знал, а как еще можно скопировать музыку с компа на телефон. Это была такая необычная вещь, что про нее пришлось много что учить и узнавать нового.
А ведь кто-то эту необычную штуку придумал и сделал. "Как они такое выдумали и сделали?" - крутился в моей голове вопрос.
Годы спустя я внимательно наблюдал за тем, как растут дети. Видел, как рождается в их головах знание о мире. Когда они были маленькими, то почти ничего не знали о вещах вокруг, об их функциях и назначении. Когда они впервые столкнулись с самолетом или телефоном, их надо было учить зачем эту штука нужна и как она работает. И я стал понимать, как рождается индивидуальное знание о вещах.
Все эти годы как руководитель проектов я внимательно наблюдал за тем, как команда проектирует, строит и продает продукты. На старте проекта, до начала исследований и разработок, в головах команды нет четкого концепта продукта, нет понимания того, в чем его польза, как его проектировать, производить и продавать. И они должны много что сделать, чтобы понять, какая новая вещь появится в мире, наделить ее смыслом для себя и положить этот смысл в головы покупателей. Нелегкая задача для любой штуки, которую нельзя съесть прямо на кассе. И я стал понимать, как рождается коллективное знание о вещах.
Последние несколько лет как системный инженер и методист я внимательно изучал процессы проектирования, изготовления, маркетинга и продаж. Я видел, какие проблемы возникают при попытках обсудить, согласовать и записать планы сложных проектов, системную архитектуру или создать набор согласованных между собой документов из разных областей - от маркетинга до закупок и НИОКР. И я стал понимать, как обеспечивается функциональное взаимодействие между разными командами, как проходит трансдисциплинарный анализ и синтез проектных решений в больших распределенных командах без единого руководства.
Я объединил эти три знания и понял, как инженеры думают о продуктах.
В наш мир приходит все больше необычных вещей, а использование многих существующих постоянно переосмысливается. Вещи становятся все более сложными, и даже для того, чтобы перевести ERP, CRM или WMS/TMS из опытной эксплуатации в серийную, надо как следует постараться и подумать. Полностью полагаться на то, что за заказчика все сделает разработчик продукта уже нельзя. Любой менеджер сейчас должен уметь думать о продукте и ставить задачу на его доработку, даже если это не входит в описание должностных обязанностей. Мышление руководителей должно приблизиться к мышлению инженеров и программистов. И тогда для них наступит освобождение от парадигмы "я придумываю, как зарабатывать деньги, дело разработчиков - исполнять замысел". Бизнес-замысел должен подстраиваться под технические возможности, но при этом не должна наступать диктатура исполнителя.
С другой стороны, и у самих проектировщиков и программистов наступили времена, когда нельзя просто взять и реализовать полученное на старте техническое задание. Во время разработки проектных решений надо закладывать возможность их последующего изменения, надо понимать, у кого что спросить и что необходимо уточнить перед тем, как начать работу, чтобы не сделать ненужную доработку или функцию. И мышление современного программиста или проектировщика должно стать ближе к мышлению руководителей, в их голове должно появиться четкое денежное и социальное измерение работы. И тогда для многих из них, которые застряли в парадигме "я реализую ровно то, что написано в постановке задачи и не понимаю, чем заказчик недоволен" наступит долгожданное освобождение от диктатуры заказчика.
И для тех и для других решение лежит в одной плоскости - надо уметь четко структурировать объекты в реальном мире, подбирать под них работоспособные концепции, строить на базе этих концепций понятийный аппарат, строить на базе понятийного аппарата логику достижения цели и получения нужного результата, подбирать метод организации работ под конкретные условия, в которых работает команда, вовремя вовлекать нужных людей и давать им ровно ту информацию, которая нужна для принятия нужных решений. Словом, все то, что обычно называют "здравый смысл" и "умение включать голову", но я разобрал эти общие рекомендации на сотню конкретных отрабатываемых навыков, которые совместно составляют более-менее современный корпус системноинженерных знаний.
В этом производственном романе и серии сопутствующих упражнений я детально объясняю как работает дисциплинированная инженерная и управленческая мысль в проектах по созданию продуктов и что надо сделать на каждом шаге, чтобы не только не бояться пришествия нового iPhone, но и уметь доработать его под свои нужды.
В своей работе я использую идеи из следующих источников:
Системное мышление 2019. А. Левенчук,
Системный инженер: Как начать карьеру в новом технологическом укладе. В. Мизгулин,
Курс по онтологике. П.Медведева,
Блог http://anticomplexity.org/ Е. Чурилов
Блог http://howtoknowhow.ru/ М. Ковина-Горелик
Стандарт Semantics of Business Vocabulary and Rules, OMG
Chris Argyris Organizational Traps: Leadership, Culture, Organizational Design
Роман состоит из двух частей - первая часть вводит основные понятия, вторая часть показывает использование введенного понятийного аппарата для реверс-инжиниринга кофемашины. Предлагаемый подход основан на системном подходе Школы системного менеджмента с дальнейшим развитием теории стейкхолдеров идеями Криса Аргириса.
Краткий обзор основных идей
Принципы директивного управления
(Auftragstaktik; тактика поручений; то, что применительно к разработке ПО 200 лет спустя прозвали Agile)
При реализации любого плана есть три барьера:
Пробел между уровнем необходимых и фактических знаний (1)
несогласованность планов и действий (2)
различие между ожидаемым и подтвержденным результатом действий (3).
Эти барьеры неустранимы.
Stephen Bungay, Art of Action.
Медленный хаос не равен порядку. Agile требует от команды предельной дисциплины в мышлении и согласованности в действиях.
Gregor Hohpe, Technical director in Google Cloud’s Office of the CTO
Ситуационная осведомленность команды - ключ к успешному созданию и реализации стратегии.
Основной принцип, который стоит за методом PowerMaps.
Умение быстро и четко различать абстракции и реальность
При зрелом размышлении все спокойно отличают, идет речь о реальных штуках или о понятиях. Вопрос в том, что это различение должно идти на автомате. Дети в первом классе могут складывать и вычитать, но обычно делают это медленно, у них уходит на это много сил. Инженеры и руководители даже довольно сложные расчеты прикидывают в уме на раз-два и не напрягаются. Надо добиваться именно такого автоматизма.
- каждый объект имеет одно или несколько свойств
- каждое свойство подобного вида абстрагируется в одну характеристику
- каждая характеристика является частью одного или нескольких понятий
- каждое понятие образуется уникальным набором характеристик
- каждый объект абстрагируется в одно или несколько понятий.
Пример:
- кофемашина, которая стоит у нас в офисе, может быть капсульной, с черным корпусом, в не профессиональном исполнении;
- когда мы думаем о такой кофемашине, то у нас в голове возникает понятие "кофемашина", пункт в мысленном инвентаре вещей, о которых мы думаем. У этого понятия есть характеристики "капсульная", "черная", "бытовая", эти характеристики образовались от свойств реального объекта, который стоит на кухне в офисе;
- когда мы думаем о кофемашинах, то капсульной может быть не только та кофемашина, которая стоит на кухне, но куча других кофемашин;
- при этом знания в нашей голове собраны вокруг какого-то набора характеристик. Мы знаем, что капсульная черная кофемашина в бытовом исполнении подойдет для офиса, а профессиональный трехрожковый аппарат для приготовления эспрессо нет;
- про конкретную кофемашину мы можем думать еще и про как пункт статьи затрат, электропотребителя, источник шума в офисе, элемент интерьера, пункт в списке ежедневной уборки офиса. Другими словами, один объект представляется множеством понятий.
Понятия могут быть единичными или общими. Единичное понятие относится к уникальному объекту, тому самому, про который собеседники точно знают, что он один. Общее понятие относится к классу объектов. Чтобы различать уникальность объектов, инженеры используют так называемый URI, унифицированный идентификатор ресурса. Вы все знаете про разновидность URI - URL, адрес сайта и ISBN - идентификатор книги.
Эти характеристики отражают свойства разных автомобилей-как-конкретных-объектов. После того, как мы выбрали автомобиль и стали на нем ездить, мы начинаем думать о нем как о сложном объекте, который состоит из двигателя, колес, подвески, фильтров кондиционера - мы разбиваем объект автомобиль на части, и у каждой части появляются свои свойства. Мы думаем о таких свойствах шин как радиус и ширина, тип зимняя/летняя, типоразмерах аккумулятора, степени очистки фильтров и т.п. А если мы привлечем к обслуживанию специалистов, то они могут начать рассуждать о типах и марках электролита в аккумуляторе, особенностях решетки и параметрах пускового тока, профиле зарядки и надежности аккумуляторных ячеек. И тогда они опускаются еще уровнем ниже, начинают обсуждать объекты, из которых состоит аккумулятор - корпус, гель, ячейки, клеммы. Им не хватит информации, и они обратятся к специалистам на заводе-изготовителей, и тот им начнет рассказывать про то, как очищается свинец для пластин аккумулятора, и они уйдут еще ниже, начнут рассуждать про кристаллические структуры, из которых состоит пластина, у вас появится еще один объект, у которого будут свои свойства. Даже такой простой объект как карандаш, может породить огромное количество рассмотрений, см. рассказ "Я, карандаш".
Как остановиться в этом бесконечном углублении рассмотрения? Окончательную точку в этом вопросе ставит системный архитектор, он принимает решение что включать в рассмотрение, а где остановиться. Как он это делает?
Чтобы ограничить количество рассматриваемых объектов и структурировать область рассмотрения, инженеры используют два приема - помещают объект в контекст и рассматривают его на жизненном цикле.
В системном подходе реальный мир делят на четыре объекта: бизнес-контекст (1), который включает в себя операционный контекст (2), целевую систему (3), помещенную в операционный контекст, и системный контекст (4), который описывает, из каких объектов состоит целевая система. При этом мы осознанно используем мыслительный прием, который мы обычно используем бессознательно - мы думаем о сложных объектах как о пространственно-временных структурах, наше мышление оперирует 4Д, пространством и временем. Поясню, как это обычно происходит.
Допустим, собрались вы вечером с друзьями поиграть в "Монополию". Конкретная партия игры определенно является объектом реального мира, т.к. ее можно увидеть и понять. Этот объект является сложным/составным, т.к. для игры нужны люди, карта, кубики, фишки, деньги и сборник правил. Составной объект "Игра в Монополию" структурно состоит из других объектов - кубиков, игроков, фишек, денег. Вы начинаете игру, бросаете кубики, двигаете фишки, зарабатываете и теряете деньги, покупаете предприятия и торгуете друг с другом. Все это происходит в какую-то единицу времени, в игровой ход. Получается, игровой ход мы тоже можем увидеть, выделить как отдельный объект, обсудить правильность и допустимость действий. В шахматах так постоянно и делают, в них выделяют и обсуждают отдельные ходы. И в футболе - матч состоит из передач, ударов, штрафных, а не только из игроков, ворот, мяча, поля и судьи. Другими словами, мы можем рассматривать состав объектов не только в виде пространственной структуры, но и в виде временной, темпоральной структуры. Например, один и тот же состав "Сапсана", который курсирует между Москвой и Питером, будет состоять из двух объектов - поезда 752А и поезда 761А. И мы различаем между собой два этих объекта "поезд Москва-Питер 752А" и "поезд Питер-Москва 761А", хотя и тот и другой определенно являются временной частью одного и того же состава бортовой номер, допустим 7628. Объект "состав 7628" состоит из временных частей, объектов "поезд 752А" и "поезд 761А".
Такое временное разделение позволяет системному архитектору обсуждать деятельность предприятия в бизнес-контексте. Потому что для того, чтобы структурировать бизнес-контекст и операционный контекст, мало уметь различать между собой физические объекты, надо уметь видеть динамику ситуации. Это нужно для того, чтобы учитывать использование станка с ЧПУ или испытательной лаборатории в разных проектах, потому что в каждом из этих проектов и станок и лаборатория будут учтены как отдельные объекты со своей ролью и назначением, а системный архитектор должен уметь правильно организовать распределение ресурса лаборатории или станка между разными проектами и процессами, должен уметь собрать и свести данные из разных учетных систем в системе управления жизненным циклом изделия. Другими словами, если инженер-испытатель приходит к нему с запросом "мне нужен стенд 13 через неделю на 24 часа", то система управления жизненным циклом, которую построил системный архитектор, должна свести между собой данные из четырех 1С-ок и 12 таблиц Excel, чтобы понять, есть ли такое окно. Чтобы построить такую систему, ему надо думать об объектах как о пространственно-временных структурах, думать в 4Д.
Такое мышление контринтуитивно, обычно когда я начинаю рассматривать работу строительного крана, процесс проектирования или работу с CRM в том же ключе, что и конструкцию дома, модульную архитектуру прибора или структуру баз данных, люди вокруг очень возмущаются. Они считают такое рассмотрение (состав не может состоять из двух поездов, это нонсенс!) недопустимым, пока не увидят, что использование логики пространственно-временных структур сильно упрощает модели целевой системы и ее контекстов. И тогда все аргументы исчезают.
Рассмотрение объектов в 4Д позволяет в разы сократить количество объектов в области рассмотрения для сложных проектов, упростить модели и принятие проектных решений.
Когда мы организуем систему понятий, мы объединяем концепты в какие-то группы. Для этого мы берем характеристики и объединяем их в типы, а типы строим в иерархию подтипов и надтипов. Получившаяся система понятий описывается концептуальной схемой. Таким образом, физический мир у нас организуется в пространственно-временную структуру из целевой системы, операционного контекста и бизнес-контекста, в 4Д-экстент, а понятия организуются в систему понятий, которая описывается концептуальной схемой, и делится на предметные области. Первая структура наводит порядок в реальном мире, вторая структура наводит порядок в мире абстракций. Обе эти структуры связаны между собой какой-то логикой, хотя и не повторяют друг-друга в точности, потому что структуры реального мира происходят от технологических и организационных ограничений, от того, что мы можем сделать с объектами, а структуры абстрактного мира происходят от мыслительных ограничений, от удобства коллективного мышления и коммуникаций. Связь между этими двумя структурами называется законом Конвея, который вкратце можно сформулировать так: "Структура общения команды определяет структуру системы". Практическое применение закона Конвея в том, что модель общения определяет "нарезку" и распределение технологий работы с объектами реального мира. Чтобы изменить технологию проектирования и построения целевой системы, зачастую надо изменить систему понятий и общение в команде.
Какая-то целостная система типизированных понятий называется онтологией. Онтология - это обобщение в типы/классы; она реализуется через группу типов, классов, категорий или иных конструктов, более или менее избавленных от объектной конкретики, и в это её ценность. Единичные понятия группируются в онтики, в мыслительные инвентари.
Итого: онтика - список конструктов с координатами в операционных пространствах, "концептуализированных объектов". Их координатные определения (4Д, например) мы можем скармливать конкретным моторным программам. Онтология - список конструктов с обобщёнными местами, она нужна для построения переносимости параметрических структур между группами операций (откорректированное мной определение онтологии, которое дал Егор Чурилов).
Метод состоит из онтологии (общих, переносимых между ситуациями знаний по тому, как построить коллективное мышление) и технологии (общих, переносимых между ситуациями знаний по тому, как преобразовать одни объекты в другие), методика состоит из онтики (практически применимых знаний по тому, как построить коллективное мышление) и техники (практически применимых знаний по тому, как преобразовать одни объекты в другие). Метод можно перенести между ситуациями широкого класса, в контексте всей реальной деятельности предприятия на длительных временных промежутках, на различном рыночном, процессном и ИТ-ландшафте. Методика применима для узкого класса заданных ситуаций, скажем, для заданного набора клиентов, поставщиков, рыночных условий и устоявшегося процессного и ИТ-ландшафта.
Метод и методика находятся в голове команды и рабочих продуктах (шаблонах документов, базах данных, настройках приложений, архивах и т.п.)
Умение ограничивать и структурировать область рассмотрения проекта
Мы не рассматриваем всю Вселенную объектов и все понятия, которые соответствуют этим объектам. Для каждого проекта выделяется область обсуждения, которая определяет, какие объекты относятся к проекту, а какие нет.
ГОСТ Р ИСО 15531-1-2008
3.6.50 область обсуждения (universe of discourse, domain): Совокупность физических или абстрактных объектов, относящихся к области реального мира, которые выбраны в соответствии с интересом, который они представляют для системы, подлежащей моделированию, и ее окружением.
Область обсуждения определяет, где мы останавливаем дальнейшее разбиение составных, сложных объектов на составляющие их объекты. Как только нас перестало волновать, как мы получаем тот или иной объект, мы проводим границу области обсуждения. Например, если мы покупаем автомобиль в салоне с гарантией производителя для того, чтобы ездить по городу, нас не интересует марка аккумулятора, тип приводного ремня и износ дисков сцепления. Если что случится, мы просто отвозим автомобиль по гарантии и нам все исправляют. Но если нам надо выехать в безлюдную местность, то мы будем тщательно изучать все нюансы эксплуатации и ремонта автомобиля в полевых условиях, озаботимся многими мелочами, которые становятся важны в тайге, где нет инфраструктуры для эксплуатации автомобиля. Аналогично, производители одежды или еды, которые озабочены этичностью поставщиков, начинают отслеживать цепочку происхождения сырья и материалов, и расширяют область рассмотрения.
В области обсуждения помимо физических объектов: целевой системы, операционного контекста и бизнес-контекста, есть и абстрактные объекты, которые существуют в области обсуждения логически. Например, я знаю, что если вырыть котлован, купить машину цемента, пригнать бригаду рабочих, замесить раствор и залить котлован раствором цемента, то у меня будет фундамент под дом. Никакого фундамента еще нет, есть только деньги и замысел. Но в области обсуждения проекта по строительству дома все эти объекты - участок, котлован, бригада, раствор, фундамент уже существуют в логическом смысле. Концептуальная схема проекта строительства дома (онтология строительства, накопленные знания) говорит мне, что такое возможно. И я могу обсуждать такие абстрактные, еще не существующие объекты с другими людьми и мне никто не будет крутить пальцем у виска потому что они разделяют со мной концептуальную схему. Как говорят системные инженеры, в таком случае команда разделяет метод.
В системном подходе мы начинаем с изучения бизнес-контекста, который уже физически существует. Проводим бизнес-анализ, определяем источник проблем, способ устранения этой проблемы и целевое организационно-техническое решение, которое в результате внедрения устранит проблему. Таким образом мы определяем целевое состояние по результатам нашего проекта. Теперь нам надо определить средства достижения этого результата. Для выполнения проекта мы привлекаем специалистов в разных предметных областях, причем каждая предметная область по своему концептуализирует объекты в области рассмотрения, в каждой из них есть свои технологии преобразования имеющихся объектов в какие-то другие объекты, причем мы считаем, что эти преобразования приближают нас к целевому состоянию. Мы так считаем потому что у нас есть знания, которые описываются онтологией, которая является частью метода, с помощью которого работает наша команда. В больших проектах мы сталкиваемся с ситуацией, когда концептуальные схемы разных предметных областей несовместимы между собой, а то и противоречат друг другу. Мы не можем создать непротиворечивую онтологию проекта. Тогда нам нужны особые инструменты, чтобы объединить концептуальные схемы предметных областей общей системной логикой. Таким трансдисциплинарным рассмотрением и объединением как раз и занимается системная инженерия.
Объединение различных предметных областей достигается в основном тремя способами:
1. За счет архитектурных моделей, когда системный архитектор объединяет точки зрения разных предметных областей в своей голове и принимает решения по тому, как должен быть организован проект или целевая система
2. За счет моделей системной динамики, когда понятия предметных областей вначале операционализируются через операнды (operands, proxy variables), затем создаются массивы этих операндов, а работа целевой системы в операционном и бизнес контексте моделируется через функции, преобразующие входные массивы операндов в выходные массивы операндов.
3. За счет трансграничных объектов либо трансдоменных объектов (boundary objects), которые находятся на границе предметных областей и совместно создаются специалистами этих разных областей, деятельностно объединяя их позиции. Типичным примером трансдоменного объекта может служить календарный график сооружения, который объединяет точки зрения проектировщиков, строителей, закупщиков оборудования и материалов, монтажников, пуско-наладчиков, продажников, специалистов по безопасности, защите труда, сертификации и т.д. Несмотря на совершенно разные и часто несовместимые концептуальные схемы, которые используют эти группы специалистов, календарный график сооружения помогает им договориться по совместным действиям даже тогда, когда они не понимают чужой позиции.
Итого
Метод - разделяемый командой проекта набор не взаимоисключающих теорий (концептуализаций), который позволяет производить и собирать факты при выполнении работ проекта и выстраивать из них связанное повествование, которое не противоречит концептуализации. Сила метода определяется объемом и охватом корпуса фактов и связанностью логических цепочек повествования, а также его предсказательной силой, то есть вероятностью того, что собранные в будущем факты подтвердят рассказанную ранее историю.
Если очень просто, то метод говорит нам, какая цепочка логически существующих объектов в области обсуждения приведет нас к целевому состоянию по оптимальному пути. Оптимальный путь определяется по трем группам критериев - оптимальный выбор одной альтернативы из имеющихся, соответствие ресурсным ограничениям команды, приемлемость альтернативы и ее обоснования для стейкхолдеров.
Метод рассматривает материальный мир, мир объектов и предметов, и комплекс моделей, которые представляют, концептуализируют этот материальный мир, позволяют построить историю развития проекта в будущем. Эта история позволяет команде понять, что сделать прямо сейчас, чтобы приблизить хороший конец истории или избежать плохого.
Если мы рассматриваем объекты материального мира, объекты наших исследований и инженерных усилий, с точки зрения системного подхода, то называем их системами. На любую самую простую систему можно посмотреть с самых разных позиций. Например, на кофемашину можно посмотреть глазами электрика, механика, баристы, специалиста по пользовательским интерфейсам, маркетолога, производственного технолога. При этом объект кофемашина будет представлен предметами этих специальностей - электрическими цепями, механизмами, технологиями приготовления кофейных напитков, клиентским опытом, рыночным позиционированием модели, технологией сборки. За одним объектом стоит много предметов, одной модели кофемашины соответствует множество схематизаций предметных областей, чтобы спроектировать и изготовить кофемашину, нужен комплекс разных моделей, от конструкторской и программной документации до маркетингового плана и бюджета проекта. За каждым предметом стоит своя предметная область с набором концептов, понятий. Системный подход объединяет концептуальные схемы разных предметных областей в онтологии проекта и объединяет несовместимые онтологии с помощью архитектурных моделей, трансграничных объектов и моделей системной динамики. Такой подход позволяет расширить пространство выборов (trade-off space) при принятии проектных и организационных решений на системный, междисциплинарный и трансдисциплинарный уровень.
Смысл (в прагматическом понимании). Высказывание или действие осмысленно, если оно подчиняется некоторому правилу, логике, теории, концептуальной схеме.
Смысл (в системной инженерии). Высказывание или действие осмысленно, если оно подчиняется модели жизненного цикла целевой системы. Проектное решение осмысленно, если оно соответствует системной архитектуре. Управленческое решение осмысленно, если оно подчинено корпоративной архитектуре.
Факт - высказывание об опыте в категориях теоретической (концептуальной) схемы.
Взгляд на ситуацию с позиций разных теорий даст разный набор фактов. Полезная теория из этого набора фактов порождает новое, нетривиальное знание о ситуации. Бесполезная теория породит тривиальное знание либо вообще приведет к коллапсу объяснительной модели.
Этимология - в конце 15 века от factum, ранее facere, "делать". Начальный смысл - "действие", позже "преступление". Смысл, который часто приписывается этому слову сейчас, "правда, реальность" появился в конце 16 века. Важно понимать, что факты изготавливаются, факт есть социальный конструкт, а не что-то "объективно существующее". Например, "в нашей галактике от 100 до 400 млрд. звезд" или "вакцина спасает от гриппа" подразумевают, что вы разделяете теорию о том, что звезды и галактики существуют, точно также, как существуют вирусы и иммунитет. Эти высказывания будут фактами только для тех, кто разделяет эти теории, и вызовут споры с людьми, которые считают небо твердым, а болезни наказанием за грехи. Разные схемы концептуализации мира приводят к разным фактам.
"Факт = «Фиксированный кем-то АКТ».
Нет позиции, нет средств — нет факта.
Другая позиция, другие средства — другой факт.
Никаких «освобождений» нет".
Модели метода: от выбора схем концептуализаций зависит то, какие факты команда соберет в проекте. Например, если управленческого учета на проекте не будет, то фактов учета и витрин с управленческой отчетностью тоже не будет. Факты и наборы фактов объясняются с помощью предметных моделей (с помощью инженерных дисциплин, маркетинга, фин.учета). Данные испытаний объясняются инженерными дисциплинами, данные продаж маркетингом, сводные и объясненные данные объединяются в события - испытания завершены успешно, позиционирование выбрано корректно, бизнес-модель успешна. Модели предметных областей объединяются системными моделями.
События как-то характеризуют изменение состояния объекта, позволяют контролировать ход проекта по созданию целевой системы.
Модели бывают трех видов - текстовые, для людей (business, Ib, Iib, IIIb - технические задания, презентации, финансовые отчеты), диаграммы (diagrams, Id, Iid, IIId - BPMN, ArchiMate, UML) и формальные логические модели, пригодные для реализации в ИТ-системах (generalization, Ig, Iig, IIIg - организационные нормы, выражения в формальной логике предикатов и пр.).
Почему системный подход к созданию метода лучше любого дисциплинарного?
Есть два объяснения.
Классическое объяснение Томаса Куна относится к 1960-м:
«Все эти пять характеристик: точность предсказаний, их непротиворечивость, область применимости, отсутствие избыточности в понятийном аппарате и полезная интерпретация фактов - стандартные критерии оценки адекватности теории».
Томас Кун, Объективность, ценностные суждения и выбор теории, в Хрестоматии: Современная философия науки, М., «Логос», 1996 г., с. 62-63. (уточненный перевод)
Исходя из этой позиции системный подход позволяет:
- получить более точные предсказания, применяя дисциплины предметных областей только там, где они дают хороший результат
- обеспечить меньше противоречий, вовремя выявляя их и разрешая различными способами
- сократить понятийный аппарат, с помощью правильного структурирования области рассмотрения
- корректно собирать и интерпретировать факты за счет междисциплинарного и трансдисциплинарного анализа.
Более современное объяснение, исходя из современных теорий доверия, см. обзорную статью "Доверие и его воплощения на цифровых рынках" Роман Химич, Егор Чурилов v2-20191206, можно сформулировать так. Далее идут цитаты из статьи с моими комментариями:
"Доверие – это предположение агента-доверителя о том, что некоторый доверяемый агент будет действовать определённым известным и/или согласованным образом, воплощённое в планировании деятельности первого с опорой на данное предположение.
Доверие, как понятие, необходимо нам, чтобы говорить о планировании и неопределённости в ситуациях зависимой деятельности. Это позволяет осознанно вводить в практику планирования шаги, связанные с управлением этой неопределённостью, а также обусловленными ею рисками и возможностями".
Метод нам нужен, чтобы экономически обосновано доверять остальным членам команды, которые разделяют с нами метод.
"Архитектура доверия – это представление о параметрах планирования созависимой деятельности для группы устоявшихся в некотором сообществе практик. Например, такие разные социумы, как тюремное сообщество и штат корпорации имеют различные цели, различные группы практик по их достижению, различные подходы к их планированию. Весьма различаются значения параметров этого планирования, обеспечивающих устойчивость достижения целей: представления о распределении власти, отношения к авторитетам, правовые гарантии, процедуры апелляции и пр.
Схема, дающая представление о ключевых параметрах доверительных отношений, и называется архитектурой доверия. Она эксплицирует базовые механизмы и отношения, которыми обеспечивается/поддерживается аспект доверия в рамках конкретного экземпляра или класса агентских отношений. Таковыми механизмами и отношениями являются отношения власти (правоустановление, правоприменение, разрешение споров), отношения в части гарантирования покрытия рисков, отношения в части фиксации состояний/отношений, нормы права (публичного, непубличного, любого фактически действующего и учитываемого сторонами), механизмы исполнения решений, механизмы предоставления доступа к ресурсам, доверительные услуги и т.п.
Выделяя такие представления как самостоятельные концептуальные объекты, мы можем характеризовать деятельность рассматриваемого социума с точки зрения его подхода к планирования групповой деятельности".
Метод определяет архитектуру доверия в команде и между командой и стейкхолдерами.
"Уровень доверия – количественная, не всегда численная, оценка агентом-доверителем устойчивости некоторой собственной деятельности в условиях зависимости достижения её целей от деятельности агента-доверяемого, относительно содержания которой у агента-доверителя существует опорное предположение.
Предположение является опорным в том смысле, что агент-доверитель при планировании своей деятельности опирается на его содержательные части.
Вопрос о метриках доверия возникает в силу необходимости оценивать меру устойчивости планируемой деятельности и обусловленную этим неопределённость. Метрики призваны дать возможность метрически (численно) оценивать сценарии зависимой, отвечая на такого рода вопросы:
«Насколько выполнимы в части совокупных затрат ресурсов шаги нашего плана, когда наши действия в нём, а также общий или промежуточные результаты зависимы от действий второй стороны?»
«Сколько энергии мы, в целом, должны потратить на управление рисками в процессе реализации данного плана?»
«Насколько выгодным является выбор в пользу некоторого вида зависимого взаимодействия с данным контрагентом при наличии альтернативных сценариев?»
Доказательная сила
Авторы исходят из предположения, что в процессе выбора между несколькими инструментами поддержки доверия агенты, в первую очередь, исходят из всегда возможной и значимой для них возможности наступления ситуации оспаривания действий/бездействия участников соглашения. Иными словами, именно корректное (комфортное, незатратное, предсказуемое в части процедур) разрешение ситуаций нарушения оказанного доверия есть тот момент, ради которого агенты готовы инвестировать в такого рода инструменты.
Выбор тех или иных инструментов напрямую обусловлен ответами на вопрос как быстро такая ситуация разрешается? С какими издержками? Можно ли ожидать возмещения ущерба или только части издержек? Насколько велики санкции?
Из этого ракурса инструменты доверия рассматриваются как инструмент уменьшения издержек. Если в рамках системы доверия С1 доказательство своей правоты посредством артефакта А1 требует X денег, а с помощью А2 достаточно обойтись Y, где X> Y, тогда всё сразу ясно и понятно. То же самое и в случае принципиально отличной системы доверия С2. «Доказательная сила» здесь может быть определена, как отношение количества устраняемой неопределённости и рисков к совокупной стоимости их устранения:
Метод устанавливает экономически выгодный для участников проекта уровень доверия, а рабочие продукты метода обладают приемлемой доказательной силой.
Часть 1, в которой Лидия знакомиться с понятиями системного подхода.
Глава 1, в которой все знакомятся и понимают, что будет трудно.
Лидия вышла из такси перед зданием 30 подразделения AnyCorp. Донна уже ждала ее, они радостно обнялись и Донна повела ее в кафе за углом. Там они сели и за чашкой латте ударились в воспоминания. Прошло уже 8 лет, как они встречались в последний раз, а мрачноватую Лидию жизнерадостная подруга всегда привлекала.
"Как карьера? Уже директор по персоналу?" - спросила ее Донна. Про повышение ей рассказала Ольга, их общая знакомая, которая всегда знала все про всех.
"Была полгода, теперь у нас в подразделении нет директора по персоналу, есть только HR бизнес-партнеры. Переходим к бирюзовой организации", - Донна, казалось, немного погрустнела. Но она всегда была амбициозной, а стать из понятного директора по персоналу непонятным HR бизнес-партнером могло выглядеть не очень.
"Ну что, расскажи мне про этот проект", - Лидия пересела немного в тень, потому что от латте и жаркого солнца она начала потеть.
"Э, нет, не на улице, у нас очень строгая служба безопасности. Вначале иди, оформи допуск, возьми SecurePad".
"Что взять?"
"Защищенный планшет, на нем будет вся информация по проекту и данные по подразделению. Даже по подразделениям, они пока разъединены, производство сидит в 16 корпусе, их надо перевозить и объединять. Пойдем, если ты так рвешься в бой".
Они прошли шлюзовый вход, в котором Лидия немного запуталась с этими блокировками входов и разговорами через интерком, поднялись на лифте на 13 этаж, проехав полуосвещенный 9, на который Донна кивнула, мол, твой, и вышли в длинный узкий коридор. Охранник, сидевший на этаже, сказал Лидии следовать за ним, а Донна осталась ждать на диванчике рядом с аквариумом, в котором плавала черепаха и несколько тропических рыбок.
Охранник провел Лидию в кабинет, где ее ждал офицер внутренней безопасности. Он выдал ей бэйдж и толстенький планшет с абсолютно черным экраном. На планшете была надпись SecurePad.
"Как будете расписываться?" - спросил офицер, и Лидия выбрала подпись с помощью телефона.
"Короткий инструктаж. Планшетом можно пользоваться только на территории корпорации, в пределах корпоративного WiFi. И дома, координаты прописаны в планшете. В пути разрешается только в корпоративном автомобиле, там стоит маячок, радиус действия 10 метров. Планшет блокируется вне этих зон. Если планшет покидает защищенную зону больше чем на 24 часа, все данные на нем стираются. У планшета поляризованный экран, видеть изображение можно только поставив экран прямо. Планшет распознает ваше лицо, как только в него посмотрит другой, он заблокируется. На ваш телефон сейчас будет установлена программа поиска планшета и удаленного уничтожения информации на нем".
"А если воры его выключат, то как я его сотру?"
"Там спутниковая связь, если планшет не видит спутник 4 часа, то стирает информацию".
"Отвечая только да и нет, скажите, вам все понятно про правила пользования защищенным планшетом?"
"Да, все понятно".
"Выходите к сопровождающему".
Лидия вышла в коридор с планшетом в руках. Он был какой-то немного неудобный, в сумочку залез с трудом.
"Ну что, идем к тебе?" - И Донна нажала девятку.
Они вышли в слабо освещенный коридор, Лидия бикнула пропуском и они зашли внутрь. Половина этажа была пустая, свет был выключен, но дальний конец был освещен, там ходили люди и были слышны разговоры. Донна провела Лидию к дальний конец, и когда их увидели, разговоры моментально стихли.
"Это ваш босс, ребята", - представила Донна Лидию.
"Меня зовут Лидия, я закончила Гарвард, получила степень по социологии, в AnyCorp работаю 8 лет, и у вас я буду старшим директором по объединенным операциям DevProd. Можете считать меня старшим исполнительным директором для подразделения".
"Планшет", - прошептала ей Донна.
Лидия достала планшет и он включился. На нем появилось лицо Донны: "Привет. Познакомься со своей командой". И пошли фотографии с краткой справкой по каждому члену команды, Лидии только оставалось запоминать лицо, жать руку и кликать "Следующий". Через 5 минут все закончилось, хотя оставалось еще много народу.
"Сейчас только руководители, всех все равно не запомнишь", - объяснила Донна.
Лида только помахала всем рукой: "До завтра, ребята, я всем назначу встречи и мы поговорим".
Потом они сели в пустой переговорке и Донна рассказала ей что да как.
Ребята, которых встретила Лидия, были тем самым стартапом 9-bis, который нашумел на выставке по беспилотному транспорту в Мюнхене в Феврале. В марте AnyCorp их купила и посадила делать серийный продукт "Универсальный автопилот", который они хотели продавать как опцию автомобильным компаниям. Условно, как АБС - ставишь и получаешь автопилот высокого уровня. Но ребята отставали от графика уже на два месяца и отставание увеличивалось. Они никак не могли справиться с производственными процессами, производственники не принимали их дизайн по самым разным причинам. В результате руководство решило, что к проектировщикам надо добавить производственный отдел, который занимался запуском спецавтомобилей, и поставить "родительский надзор" в виде опытного руководителя.
"Я тебя проталкивала всеми силами", - Донна вся раскраснелась.
"Спасибо", - Лидия была возбуждена, но все равно никак не могла понять, зачем Лидии была нужна именно она.
"А все-таки, почему я?" - попробовала она почву.
"Честно говоря, я не очень верю во все эти организации будущего", - внезапно открыто сказала Донна.
"И ты хочешь от меня что?" - Лидия знала, что никто ничего просто так не делает и лучше бы понимать мотивы других.
"Мне кажется, им порядка не хватает, а по поводу остального ты сама решай".
Лидия внимательно посмотрела на Донну и тут у нее позвонил телефон. Она взглянула на номер и прямо ринулась к другой переговорке, показав Донне, что это очень-очень срочно. Она нашла пустую переговорку, закрыла дверь, повернулась спиной к ней, чтобы никто не видел ее лица и начала разговаривать. Донна прошла мимо, посмотрела, ничего не увидела, и пошла к кофе-машине. Навстречу ей выскочил интерн, молодой индус, его только что взяли, и побежал к переговорке. Он постучался и зашел.
"Извините, я забыл свой телефон, возьму и побегу".
Но Лидия была взбешена и секунд 30 выговаривала про правила приличия и объясняла, что если дверь закрыта, то заходить нельзя и вообще надо уважать право начальника на приватный разговор.
"Так вы наш новый босс?"
"Я же приходила, знакомилась 15 минут назад".
"У нас было совещание, я писал протокол в переговорке, не видел вашего представления, мне очень-очень жаль", - интерн весь в поту выбежал из переговорки, держа в руке забытый телефон.
Донна увидела, как Лидия посмотрела на нее и улыбнулась. Она зашла в переговорку и спросила: "Вербовала?"
"Ага, классика жанра. Он толковый?"
"Тут вообще глупых нет, мы же тщательно отбираем".
Лидия посмотрела в планшет. Викрам Найду, ассистент системного инженера, помощник команды. Неплохая кандидатура, только надо проверить, годится ли он в качестве информатора. Лидия умела уговаривать людей.
"Ну что, сама дорогу найдешь?"
Лидия только кивнула головой и пошла домой, изучать документацию по проекту. Ей предстояла большая работа. Ближе к двум часам, исписав почти полную тетрадку конспектами, она выключила SecurePad и и пошла чистить зубы перед сном. Тут ей на телефон пришло сообщение "Вам перечислен аванс за июнь. Сумма 52,000. AnyCorp." "Корпоративный центр в Бангалоре, значит", - вычислила Лидия, и зашла в интернет-банк. Открыла шаблон "Благотворительный фонд Звезды" и перечислила ему 26,000. Взяла стакан на кухне, налила воду, открыла новую упаковку пегинтерферон бета-1а, выпила таблетку и запила ее водой.
На работу Лидия приходила всегда к 7 утра, пока пробок на улицах не было, а офис был пустой и можно было спокойно поработать. В 7:30 пришел Викрам, Лидия настроила оповещение в пропускной системе на его имя, поэтому она вышла из кабинета и сделала вид, что куда-то спешит. Они чуть не столкнулись, и Викрам чуть в стенку не вжался, но Лидия его успокоила: "Ничего-ничего, все нормально. Не ожидала, что кто-то придет в такую рань, поэтому уткнулась в телефон на ходу. Викрам, ведь верно?" Интерн кивнул и хотел было пройти дальше, но Лидия взяла его под руку и спросила: "Кофе будете? Директорский, из хороших капсул?" Они сидели и пили утренний кофе, а Лидия понемногу расспрашивала Викрама про проект и инженерную культуру 9-bis. Ответы Викрама были вполне здравые и даже умные, и Лидия решила, что он ей подойдет. Она откинулась в своем Herman Miller и спросила: "Викрам, а вы готовы стать из ассистента команды заместителем руководителя проекта? Зарплата в 2,5 раза выше, компетенций на первый взгляд достаточно. Если сейчас пройдете небольшой тест, то я прямо сейчас попрошу HR начать перевод". "А какой тест?" - Викрам вроде бы даже и не волновался. "Знаете, я обычно даю очень простую задачу, которую может сделать любой. Но люди с талантом делают ее гораздо быстрее и творчески. Метод Джоэля Спольски. Но пусть это будет не просто какой-то абстрактный тест, давайте сделаем его немного практичным. Нам надо будет перевести отдел по производственной подготовке из 16 корпуса к нам в DevProd. Составьте чек-лист такого переезда за 15 минут", -и она пододвинула к нему бумагу и ручку. "Зачем это?" - удивился Викрам. "А вы в уме будете задачу делать?" "Нет, на компьютере, так гораздо быстрее". "Я из старой школы, вначале надо почиркать на бумажке, и только потом могу перенести мысли в компьютер". Викрам уже достал из папочки под мышкой ноутбук, примостился на кофейной стойке и бодро стучал по клавишам. Через 8 минут он повернул Лидии ноутбук, там был документ.
Чек-лист офисного переезда
Шаг 1. Как только было принято решение переезжать.
• Предупредите текущего владельца помещения и подайте формальное предупреждение
• Получите подробный план нового помещения
• Замерьте новое помещение
• Оповестите всех, кто будет переезжать, о дате переезда
• Найдите и зарезервируйте компанию, которая будет обеспечивать переезд
• Составьте общий список людей, которых надо будет оповестить о смене адреса
• Проверьте, что списки персонала актуальные
• Проверьте, что список контрагентов и поставщиков актуальный
• Проведите инвентаризацию мебели и решите, что будет перевозиться, а что остается
• Решите, какую мебель и как закупить для нового места
Шаг 2. Перед переездом.• Получите подробный план нового помещения
• Замерьте новое помещение
• Оповестите всех, кто будет переезжать, о дате переезда
• Найдите и зарезервируйте компанию, которая будет обеспечивать переезд
• Составьте общий список людей, которых надо будет оповестить о смене адреса
• Проверьте, что списки персонала актуальные
• Проверьте, что список контрагентов и поставщиков актуальный
• Проведите инвентаризацию мебели и решите, что будет перевозиться, а что остается
• Решите, какую мебель и как закупить для нового места
• Присвоить отделам цветовые коды с помощью стикеров.
• Разметить план помещения цветовыми кодами.
• Приклеить стикеры с табельным номером и именем работника на его мебель и оборудование.
• Четко обозначьте места общего пользования на новом плане помещения и дайте им названия.
• Привлеките к переезду системных администраторов и обсудите, что им надо, чтобы его обеспечить.
• Оформите все необходимые официальные документы, разрешения и лицензии.
• Зарезервируйте парковочные места и лифты на день переезда.
• Разместите заказы на новую мебель и канцтовары.
• Организуйте клининг в вашем старом и новом помещении.
• Установите коды и замки в новом помещении.
• Вышлите подробный план помещения перевозчику, при необходимости организуйте встречу на месте.
• Создайте подробный план действий для работников в день переезда.
• Составьте список контактов для срочного решения проблем для всех, кто участвует в переезде, включая техническое обслуживание лифтов и оператора здания.
• Установите дату празднования переезда.
• Организуйте хранение на стороннем складе, при необходимости.
Задействуйте работников
• Организуйте собрание для обсуждения переезда.
• Назначьте ответственного от каждого отдела за упаковкой вещей.
• Обсудите порядок и правила упаковки и размещение на новом месте.
• Дайте указания по проезду, парковке, движению общественного транспорта и т.п.
• Дайте каждому работнику раздатку, где будет указан номер их рабочего места, цветовой код, приведена информация о здании и офисе, может быть указания по ресторанам, кафе и магазинам в округе.
• Объясните стандартные способ маркировки ноутбуков, системных блоков, мониторов, клавиатур и т.п.
• Проверьте, что все забрали домой личные вещи, сменную обувь, зонты.
• Обсудите, кто останется в старом офисе пока оттуда все не вывезут, а кто приедет в новый офис, чтобы помочь с переездом.
• Проверьте, что каждый отдел надежно упаковал документацию, закрыл коробки и файловые кабинеты.
• Проверьте, что на месте есть мусорные мешки, упаковочная лента, скотч, ножницы, коробки.
На вашем новом месте
• Разметьте офис цветовыми кодами, чтобы четко понимать на месте границы отделов.
• Укажите размещения рабочих мест по номерам столов.
• Проверьте, что ключи, карточки доступа и информация по безопасности есть в наличии.
• Отошлите оповещение о смене адреса:
○ Клиентам и партнерам
○ Профессиональным организациям
○ Поставщикам канцтоваров
○ Банкам
○ Поставщикам еды и воды
○ Компаниям, которые обслуживают офисное оборудование
○ Страховым
○ Бухгалтерии
○ Провайдеру Интернета
○ Другим поставщикам услуг
Шаг 3. В день переезда
• Держите распечатку с номерами для срочного решения проблем при себе.
• Проверьте отсутствующих и назначьте им замену.
• Выдайте перевозчику и системным администраторам контрольные списки того, что они должны сделать.
• Посчитайте выделенное количество персонала перевозчика и запишите время начала работ.
• При загрузке в грузовики проверяйте по списку что куда грузится.
• Закупите перекус и напитки для тех, кто участвует в переезде.
• В жаркое время года включите кондиционер.
• Раздайте новые ключи, карточки и пропуска.
• Перевозите телефоны, технику и компьютеры в первую очередь.
• Обшейте косяки и лифты защитными щитами, чтобы не повредить их при переезде.
• После загрузки последнего грузовика, но до его отправки пройдитесь по помещению и проверьте, не забыли ли чего.
• Расклейте распечатки планировки помещения в нескольких местах нового офиса.
• Проверьте, что координаторы переезда на местах и проверяют, что цветовые коды коробок, мебели, техники и разметка помещения совпадают.
• Проверить, что все стол поставлены верно, счет коробок по столам совпадает, цветовые коды совпадают.
• Проверьте, что подключения телефонов и компьютеров к сетям идут по плану и работники смогут приступить к делам в указанную дату.
На следующий день после переезда
• Разложите на рабочих местах распечатки с именем, должностью, рекомендациям по тому, где обедать и как добираться.
• Проверьте здание и помещение, проверьте исправность оборудования.
• Проверьте, достаточно ли четко размечены области и понятна ли разметка работникам.
• Установите все компьютеры и оборудование.
• Установите телефоны и проложите кабельные и WiFi сети.
• Создайте новый список телефонных номеров.
Через несколько дней после переезда
• Разошлите новый список телефонных номеров и расположения отделов.
• Проведите тщательную инспекцию помещений.
• При необходимости сообщите о повреждениях компании-перевозчику.
• Проверьте, что страховка помещений была перенесена.
• Проверьте, что старый договор аренды прекратил действие.
• Подтвердите получение депозитов от старого помещения.
• Соберите все ключи, карточки и пропуска от старого здания и верните их.
• Проверьте все накладные, счета и платежи за новое помещение.
• Поставьте новую мебель на баланс.
• Создайте итоговую версию списка рассылки и разошлите оповещения о переезде.
• Организуйте празднование переезда.
Лидия не подала виду, но была очень довольна результатом. Она давала это задание кандидатам раз 200, и ей было с чем сравнивать. Главная идея была в том, что спорить по поводу качества исполнения этой задачи кандидатам было очень сложно, потому что ошибки были очевидные - забывали про ИТ, про повреждения мебели и лифтов, про еду, депозиты и прочие мелочи. Но те, кто справлялся, обычно неплохо показывали себя в работе, потому что быстро думали и могли очень четко представить себе картинку в проекте и организовать людей. Она, конечно, еще погоняла Викрама по пунктам, проверить, насколько он уверен в результате, но он очень четко понимал зачем он поставил тот или иной пункт и аргументировано доказывал Лидии свою точку зрения. Было уже почти восемь, и скоро могли подойти люди. Лидия не хотела, чтобы их оживленную беседу увидели, и сказала Викраму: "Подавайте заявление на перевод, я подпишу его сегодня". Викрам, окрыленный ушел на свое место, в логово интернов.
Первым делом ему надо было завершить расшифровку вчерашнего собрания. Первые 40 минут он сделал еще вечером, после работы, оставалось еще 5. Сама запись была длиной 58 минут, потому что Викрам забыл выключить ее, когда уходил, и на нее попал разговор Лидии. Перед ним стояла теперь дилемма - послушать, о чем она говорила, или нет. Он недолго колебался, но решил все-таки послушать. Лидия говорила с кем-то близким, похоже, что с дочерью, у которой были проблемы со здоровьем. Викрам решил не дослушивать до конца, и обрезал запись до 45 минут. Разослал расшифровку всем участникам, и как раз вовремя, пришел поезд на 8:24, и в логово разом завалились все интерны. Начался рабочий вторник.
Всю неделю Лидия проводила очные встречи со всеми членами команды, а в пятницу в неосвещенную часть офиса приехали грузчики с горой коробок, пришли админы с компьютерами и оборудованием, администраторы офиса бегали и вешали таблички. К ним переезжало производство. А в обед Викраму пришло письмо от HR с просьбой подойти и подписать новый договор. На радостях он объявил, что угощает всех интернов в их любимом баре после 8.
Интернов было много, они сдвинули три стола, и разговор свернул в привычную для последних дней сторону. Все обсуждали Лидию, сможет ли она изменить проект. Так как она за неделю провела 40 совещаний, то мнение о ней уже сформировалось, да и сама Лидия слишком часто говорила про себя, что она здесь adult supervision, родительский надзор. Очередная жесткая рука, корпоративный босс, ничего человеческого. "Ну, дочка у нее есть, и они вроде в нормальных отношениях", - проболтался Викрам. Он уже успел выпить пару бокалов и расслабился. Рядом сидела интерн из HR, Викрам не помнил точно ее имени, вроде бы Ребекка, она тут же залезла в телефон и стала что-то искать, только и мелькали экраны соцсетей и поисковиков. Через несколько минут Ребекка сказала: "Да нет у нее никакой дочери, или она такая секретная, что даже в интранете про нее ни слова". Викрам уже жалел о длинном языке, поэтому ничего Ребекке не ответил. Но потом, уже перед тем, как зайти в бар и расплатиться по счету и уйти домой, на улице он разболтался со своим бывшим однокурсником. "Понимаешь, ей ведь нужен успех, а значит, у нее есть сильный мотив слушать нормальные советы. Потому что это слишком сложный проект, чтобы управлять им с помощью обычных интриг и корпоративных механизмов контроля. У нее не получится игнорировать системную инженерию, и тут мы на коне. Но вот ее недоверчивость играет здесь против нее. Но что-то человеческое в ней есть, не все потеряно".
Глава 2, в которой компания начинает зарабатывать, все при этом разругались, а Донна пытается втихую кинуть всю команду.
Лидия сидела и ждала очной встречи со своим руководителем, старшим вице-президентом Виком Донаги. Вик как обычно опаздывал, от выделенного ей времени оставалось 7 минут. "Привет, Лидия, рассказывай", - как всегда без особых вежливостей бросил он. "Проект по разработке универсального автопилота для нескольких автомобильных платформ, у которых есть подходящий набор опций. Модуль планируем производить с China Robust Circuits и поставлять автопроизводителям. На заводах поставят станцию, где рабочие CRC будут устанавливать модуль автопилота в автомобиль. Послепродажное обслуживание и гарантии производителя тоже на них. Есть рабочий прототип, который сделал стартап, мы купили этих ребят. Последние 2 месяца они не могут договориться с CRC по конфигурации, производственному процессу и себестоимости установленного в автомобиль модуля". "Почему?" "Постоянный пинг-понг. Посылают очередной вариант конструкции, китайцы выставляют ценник и такт тайм операции, он нас не устраивает, и мы начинаем разбираться, делаем новый вариант, и все идет заново". "Производственников привлекли?" "На той неделе в пятницу группа Ковальски переехала к нам в офис и с сегодняшнего дня стартуем DevProd, будем решать совместно". "Проект, который отстает по срокам, обязательно превышает бюджет, - сказал Вик и выразительно посмотрел на Лидию. - Останови кровотечение".
Лидия вышла от Вика и позвонила Викраму: "Расчищай свое расписание на три дня, привози пять смен одежды и организуй доставку еды в офис, мы будем писать план". Лидия встряхнулась, она любила такие напряженные периоды работы с четким результатом в конце.
Прошло 5 месяцев. Викрам проехался на колесе по пустынным улицам задолго до восхода низкого осеннего солнца, и зашел в офис даже раньше обычного, на часах было в 6:31, здание только-только открылось. Лифты и холлы еще домывали и в офисе пахло чистящим средством. Он прошел в офис и телефон подцепил корпоративный Wi-Fi, тут же начала приходить сообщения в Slack. 16 непрочитанных сообщений, первое в 2:34. Викрам даже читать их не стал, захлопнул ноутбук и пошел в лаунж пить кофе и завтракать. Почистил фильтр кофе-машины, засыпал свежесмолотый из мельницы, залил воду и поставил его вариться. В холодильнике лежали чьи-то вчерашние суши, он выложил их на тарелку и медленно съел. К семи стал подтягиваться народ. "О, ты что, не уходил?" "А ты что, опять в машине уснул, выглядишь фигово". "Кофе свежий?" "Да, но легче тебе не станет". "Дай мне предлог еще 10 минут почту не открывать, я прошу тебя". "Вот тебе полтора литра предлогов, не замучайся только в туалет бегать". Наконец он закончил утренние ритуалы, и приступил к разбору переписки, чтобы окончательно проснуться и отвлечься от легкого запаха перегара, который шел от каждого второго - офис работал в режиме 12 на 6 и многие стали расслабляться после работы в барах. Начал он с простого, руководитель отдела разработки бортового ПО не оплатил работу очередного консультанта и тот писал очередное гневное письмо с требованиями заплатить за работу. Викрам в очередной раз вспомнил первый принцип консультанта, которому его научил еще его научный руководитель: "Если консультации или покупка не забюджетированы, то денег на них не найдется, несмотря на уверения любых людей". В который раз этот принцип доказал свою правильность, Викрам уже не мог посчитать, до такой степени это было правдой.
Вот это уже интереснее - очередное сообщение в переписке "DevProd:103 - цифровой двойник или цифровой макет?" На этот раз инженер по валидации цитировал три контрактных требования с их подробным анализом, где со ссылкой на стандарты довольно убедительно показывал, что если они сделают обычную цифровую тень автомобиля с их модулем и реализуют механизм выборочной передачи данных из PLM раз в месяц, то требования будут высланы. Поскольку DevProd уже три месяца препирался с заказчиком, автомобильным концерном, и с центром сертификации насчет условий омологации и сертификации типа, а бюджета и главное квалифицированных людей сильно не хватало на задачи, то сообщение было сильно в тему и он его перенаправил письмом личному помощнику Фрэнка, руководителя проекта, с пометкой "отработайте с юристами и проектным офисом по-полной, там есть зацепки".
"Запрет на передачу курительных пропусков посетителей сотрудникам". Безопасники опять кого-то поймали? Лучше бы уже выдавали пропуска хотя бы за пару дней, а не неделю. Тут всплыло напоминание: "Трекинг проектных закупок в Primavera". Это опять старая проблема, как отслеживать комплексные поставки в проектном офисе. Чего-то там не хватало в функционале, ведомости материалов и оборудования, что ли не могли ввести, в результате отслеживались только лоты, а то ли пришло или нет, приходилось разбираться вручную. Первую очередь завода строили вовсю, поставок было много, проектный офис и логисты сидели допоздна и постоянно вешали систему своими запросами. Ладно, еще 15 минут до этого, успею почитать переписку и повестку.
После встречи он засел с планировщиками и уточнял планы на ближайшие две недели, потом сел закрывать табели рабочего времени. У технологов опять были сверхурочки, они шли с перерасходом бюджета 18%. Викрам решил все-таки разобраться, в чем дело, и залез в отчетность по проделанной работе. На первый взгляд ничего подозрительного не было, скорость работы упала по сравнению с летом, но люди в самом деле устали и работали медленно. С другой стороны, обычно к середине проекта скорость должна расти, потому что все притерлись, процессы выстроились. Он решил посмотреть коммиты в хранилище. И вот тут был сюрприз, потому что на выходных технологи выпускали столько же документов, как в остальные пять дней, а то и больше. Он вызвал к себе руководителя технологов и выторговал ограничение по сверхурочным, так, чтобы к концу года превышение было не больше 7%. А уж кому давать сверхурочные и как решать проблему с мотивацией - это не его, Викрама, дело. Он посмотрел в окно, Солнце уже садилось, а он даже не пообедал.
В столовой выбор блюд еще был, видимо, эта пятница у всех выдалась напряженной, поэтому вид подноса его радовал. Да еще и любимый столик не был занят, и Викрам сел прямо у панорамного окна и молча ел, смотрел на парк и пытался отключиться от навязчивых мыслей и постоянно звонящего телефона. "12,000 замечаний к рабочей документации завода - что будем делать?" "Омологация и сертификация - проблемы с типом А21". Тут всплыло напоминание о совещании "3D и BIM модели из чертежей". Он начал вспоминать о чем оно. Ах, да, точно. Генподрядчик строительства завода не мог сам создавать 3D модели, которые требовались по корпоративным стандартам заказчика, автомобильного концерна, для одобрения производства. При этом на стороне AnyCorp никто не понимал, что делать с этими 3D моделями. Строителям они были не нужны, потому что они строили по печатным версиям чертежей, эксплуатации тоже было не нужно, хотя реестр оборудования и поверочных сертификатов их вроде в последний раз заинтересовал, производство готово было попробовать имитационное моделирование техпроцесса, но этих данных в модели не было. В общем, надо заложить в бюджет работы по оцифровке чертежей, найти подрядчика. Но в ходе совещания выяснилось, что все не так просто, потому что непонятно, как отлеживать версионность моделей, получается, что надо вносить доработки в рабочие процессы отдела контроля инженерной документации, чтобы как минимум во время аудита все это не вылезло. Руководителя отдела на совещании не было, по телефону он ответил, что посмотрит, но никаких обязательств, люди перегружены, а сверхурочно они работать не будут, семья для некоторых важнее работы.
19:00, вечерний стенд-ап. Основная тема - логистика второго инкремента проекта. Ключевая проблема - опять много поставщиков везут много грузов по узкому месту, где не хватает грузовиков, складов, места. На связь выходит логист с распредцентра, жалуется по Скайпу, что грузовики приходят полупустые, а стоимость логистики слишком высокая. Короткое бурное обсуждение и все понимают, что из-за несогласованности действий разные логисты в разных подразделениях законтрактовали разных перевозчиков, те, в свою очередь, стали перехватывать друг у друга фуры и дронов, в результате транспорт загружен на 40% в объемах и на 97% в ресурсах. Выход предложили быстро - вводить логистические данные в PLM при проектировании. Вопрос как всегда кто будет делать. Проектировщики послали всех сразу, показав, что у них загрузка 97%, и очереди разработки уже 3-4 месяца, каждый лишний процент загрузки означает, что все будут ждать проектных решений еще дольше, поднимите руку, кто за. Служба справочных данных повторила аргументацию проектировщиков и потребовала расширения штата в очередной раз. Предложили стороннего оператора, некую Nawinia, они вроде специалисты в проектной логистике. Но денег на них в бюджете не заложили, поэтому чем все это закончится Викрам знал, и портить карму дальше ему не хотелось. Все впали в ступор и опять всплыл вопрос с 12 тысячами замечаний - что с ними делать? "И ведь на исполнительной будет не 12, а 120,000", - пророчествовал руководитель проекта Фрэнк. Он был настоящий козел. Так и разошлись, ничего не решив.
Викрам подводил итоги дня и рассылал отчетность. Технический долг продолжал расти, требования закрывались медленнее, чем надо, график и бюджет срывались, но пока не критично. План сдерживающих мероприятий и управления рисками неудержимо рос. И тут пришло приглашение от Лидии: "Празднование вехи С. Выход в операционную прибыль. Присутствие обязательно для всех". 15 этаж, воскресенье в 14:00, такси и перелет оплачивается, засчитывается как рабочее время. Викрам автоматом прикинул стоимость мероприятия и погрустнел. Лучше бы наняли пару человек в службу справочных данных. Решения Лидии его очень часто разочаровывали, 9-bis и AnyCorp сильно расходились в стратегиях. Он вызвал диспетчер отработанного времени - 21:00, 14 часов 27 минут отработанного времени, сверхурочные 108 часов за последний месяц, это значит почти тройной оклад, очень даже неплохо. Пора ехать домой, чтобы хотя бы выспаться. Странно, раньше его намного меньше волновали деньги, это, видимо, влияние постоянных разговоров о деньгах и кэше на собраниях с Лидией. А на собрания инженеров, где говорили о продукте, а не о деньгах, сроках и обязательствах, он уже почти не бывал. Он оглядел рабочее место перед уходом, проходя чек-лист ухода с работы, который всплыл после того, как он вышел из системы. Последний пункт чек-листа был "Честно ответьте себе, заплатили ли бы вы себе зарплату за сегодняшний день на месте работодателя?" Викрам даже головой покачал. Со стены кубикла на него смотрела вся команда 9-bis на февральской выставке. Тогда казалось, что покупка их стартапа крупной корпорацией- это что-то очень хорошее и многообещающее. Но это оказалось не так. И дело было даже не в 70-часовой рабочей неделе, или в 90-часовой, в его случае, работать он привык. Но то, к чему они приближались, не походило на успешный проект. Не по меркам 9-bis.
Когда Викрам пришел на встречу в конференц-зал на 15 этаже, там уже сидел незнакомый парень в футболке Space Invaders и с огромными часами Fossil. Кто-то совсем незнакомый, наверное, новенький из офиса Лидии, она любит помощников-азиатов из-за их сумасшедших рабочих часов, за которые еще и платить не надо. Викрам поздоровался с ним и сел разбирать сообщения. Зашел Фрэнк: "А чего совещание на воскресенье поставили?" - "Так свободного времени не было ни на какой другой день, я так думаю. Что там насчет проектной премии?". "Так мы три недели назад должны были веху С пройти, какая теперь премия?" "Подожди, должна же все равно быть?" "15%, что ли будет, не больше. Я думаю, с нашим объемом сверхурочных мы вряд ли HR прожмем хоть на какую-нибудь премию, у нас перерасход по статье персонала". "А что с отчетностью по проекту?" "Вик Донаги доволен и это все, что тебя должно волновать, приятель". "Еще бы он не был доволен, даже премию платить не надо". "Ты вроде тоже все бюджет зажимал?" "Да у меня борьба то за людей то за бюджет. Колеблюсь вместе с линией партии". Начали приходить люди и Викрам стал разговаривать с подходившими, уточнять, ободрять и знакомить людей друг с другом, чтобы бесконечные переписки закончились уже очным решением проблем.
Тут все замолчали, потому что пришел Вик. Сосед нагнулся к Викраму: "Смотри внимательно, мы видим вице-президента в первый и последний раз". Выступление было классическим - очень зажигательным и артистичным, но после него ничего не стало понятнее кроме того, что топы выпишут себе премию и сделают презентацию на совете директоров. Из зала было пара острых вопросов, например: "Вы говорили, что в компании идет программа по управлению знаниями и талантами. Как мне получить продвижение?" Донаги ответил: "Есть только один способ получить продвижение - вовремя узнать о позиции и вовремя поговорить с нужными людьми. И это все зависит только от вашего нетворкинга". Голос из зала начал было полемику в стиле "а зачем тогда вообще нужна программа, если все остается по-старому, но его быстро заткнул то ли начальник то ли коллеги". Донаги ушел, и на сцену вышла Лидия. Она начала:
"Мы начали антикризисный проект в подразделении DevProd пять месяцев назад. Это были сложные и трудные пять месяцев, и у нас была сложная цель - выйти на окупаемость. Руководство, как вы видели, оценило наши усилия". "Премии будут?" - выкрикнул кто-то из зала. "Все в соответствии с исполнением ваших КПЭ". "То есть, не будет премии", - подытожили сзади. "Но не только руководство признало наш результат, его заметил и наш производитель, знакомьтесь с мистером Ли. Вы знаете, как эта история выглядела со стороны AnyCorp и вашего отдела, а мистер Ли расскажет нам, как все это выглядело со стороны производителя". И на сцену поднялся тот самый китаец или кореец в футболке Space Invaders и часами Fossil. Он рассказал про подготовку опытной производственной линии, которая начала работать 1,5 месяца назад на заводе заказчика, который собирал sport station wagon. За это время они практически отладили монтаж модуля на эту модель и разработали технологию, которая позволит работать в такте 240 автомобилей в смену, это текущая производительность этого завода по данной модели. Дефектов уже почти не осталось, сертификацию они вот-вот пройдут, всем спасибо, это замечательный проект, а теперь еще и прибыльный. "Да откуда прибыльный, откуда мы это знаем, с нашим-то учетом?" - кто-то явно был разражен донельзя. Викрам привстал с кресла и обернулся. Это был ведущий инженер по силовой установке. Лидия вовремя прервала волны негодования, свернула беседу, и начался фуршет. Команда быстро разбилась по отделам и своим тусовкам, никаких ранее обычных групповых обсуждений в этот раз не получилось. Только Викрам успел съесть пару клубных сэндвичей и тарталеток и выпить бокал безалкогольного мохито, как его отловила Лидия. "Спускайся вниз, там будет автобус Мерседес, номер 747, как самолет. Садись в него, едем ко мне в загородный дом".
За окном мелькал город, потом они въехали в лес и остановились у ворот закрытого поселка, прямо у самой реки. Солнце уже садилось и лес быстро темнел. Команда почти не говорила, все сидели, уткнувшись в свои телефоны, кто-то дремал. Водитель провел их мимо коттеджей в западный угол поселка и показал на апартаменты Лидии на втором этаже. Деревянная лестница слегка скрипела под ногам, когда они поднимались, но сами домики выглядели очень даже ничего. И от офиса всего 25 минут, если без пробок, неплохо босс устроился. В комнате уже сидела вся команда управления проектом, и даже китайский поставщик приехал.
"Парни, давайте выложим рыбу на стол, - начала Лидия. - Чем вы так недовольны кроме рабочего графика, но я не думаю, что проблема в нем?" Все молчали, никто не хотел начинать, а Лидия держала паузу, она была опытным переговорщиком и знала, что молчание - золото. Не выдержал главный технолог: "Проблема в том, что проект проваливается, а мы тут перед начальством видимость успеха создаем". Лидия молча смотрела на команду и до нее доходило, что технолог и впрямь выразил общее мнение. Только Фрэнк был не согласен, по его позе это было абсолютно ясно. Фрэнк отслужил 15 лет по контракту и субординация была в его крови. Но на одной лояльности этот проект не вытянуть. "Я что-то не поняла, - уточнила она, - вы что, считаете, что Вик слукавил и на самом деле хочет закрыть проект?" "Причем здесь Вик?" - удивился технолог, и это опять было общее мнение. Лидия не понимала, она четко связывала успех с тем, как проект воспринимал ее босс. От чего еще он мог зависеть? Но переломить мнение команды за один раз нельзя, и это направление дискуссии опасно. "Мы обязательно сегодня обсудим ваше понимание что такое успех, но давайте вспомним, с чего все начиналось". Технолог не унимался: "Начиналось все с того, что вы с Викрамом провели антикризисный аудит проекта и сказали, что рамки проекта слишком широкие, что мы сейчас решаем слишком большие проблемы. И все текущие проблемы, из серьезных, есть следствие того урезания содержания проекта. Давайте я повторю просто пункты вчерашнего протокола собрания по прогрессу проекта. У нас объем проектирования на следующую модель ничуть не меньше, чем на первый образец; у нас огромный технический долг; мы вообще не понимаем состояние реализации спецификации требований, я уж не говорю про качество самих требований", - и он замолчал, потому что подключились другие. Галдеж продолжался еще пару минут, пока Лидия не прервала жалобы. "Когда я вначале дала две недели на определение содержания антикризисного этапа и поставила эти задачи менеджерам, чем это все закончилось? Менеджеры отдали все на откуп инженерам, устранились от принятия решения. Да, я приняла решение потому что его не принимали те люди, которые должны это сделать". "Лидия, при всем к вам уважении, когда вы принимали эти решения, вы работали с вашими гипотезами и предположениями как с фактами, вот в чем проблема". "Проблема в том, что руководители не приняли решений, которые должны были принять. Проект требовал жесткого руководства". "Жесткое руководство - слишком общие слова. Как бы вы поступили на месте менеджеров?" "При чем здесь как бы я поступила? Я и так была на их месте и как я поступила вам всем известно". "Давайте я уточню свой вопрос, раз уж мы выкладываем рыбу на стол. Критические решения, которые надо было принять на тот момент, были техническими. Вы их не приняли, вы просто выбрали в тот вариант дизайна, который вам больше понравился". "Не понравился, а был больше обоснован". "Если бы он был на самом деле лучше обоснован, мы бы договорились сами. Просто Егор звучит убедительнее, чем Юси, вот и все. Он, блин, русский, который работал в Британии 9 лет. Конечно он будет убедительнее финна, если не разбираться в сути вопроса, а смотреть на внешние проявления. И такое повторялось несколько раз, в разных комбинациях". К критике подключился руководитель разработки: "А переход на Agile-trains, где все решали производственники? Я на прошлой неделе поднимал протокол со своим особым мнением, которое я озвучил на совещании по запуску этого перехода, и 9 из 10 моих возражений оправдались". "Вот тут я уверена на все сто и то, что какие-то опасения оказались правдой ничего не меняет. Вы своими темпами еще год бы проектировали, я уж не говорю о том, что через 5 месяцев получить прибыль от работающего производства. Кому какое дело до долгосрочной правоты, если вас закроют из-за отсутствия результата прежде чем вы получите результат, который можно показать руководству? No money, no honey, вы думаете я зря вам эти браслеты раздала на стартовом совещании? Прибыль и денежный поток прежде всего". "Да что вы так уперлись с этой прибылью? Мы выкатываем плохой продукт!" "Это бизнес, парни, а не парк развлечений для инженеров. Честно говоря, это я тут вас выслушиваю с вашими представлениями о качестве инженерной работы, профессиональной гордости и прочей ерундой. В головном офисе это готовы терпеть, если есть прибыль, но такие разговоры не прокатят, если вы развлекаетесь за бюджет работодателя". В доме повисла тишина, постепенно все даже жевать и пить перестали. Лидия внимательно смотрела на свою команду. Кажется, она донесла свою точку зрения. Но руководитель разработки не сдавался.
"Эта прибыль есть только в моменте, пока покупатели не поймут, что мы не можем быстро выпускать модификации, устранять дефекты, улучшать надежность". "Кто вам мешает, теперь, когда проект приносит прибыль, у вас есть время на это, устраняйте". "Да с этой архитектурой продукта, к которой мы пришли с постоянными заплатками и временными решениями мы только заплатки можем ставить, а про развитие продукта даже говорить не стоит, там все работает ровно в той конфигурации, в которой мы проверили. Я же говорил про технический долг. Мы ведь отстаиваем хорошую архитектуру и правильные наборы требований не из-за эстетического удовлетворения". "Ой, да правда что ли? - Лидия просто взбесилась. - Да когда я пришла на проект, вы все сидели и только и делали, что в диаграммы смотрели да обсуждали их на собраниях. Работа стояла". "Мы с таким подходом за год сделали работающий прототип, который лучше всех на рынке на две головы, это что-то да значит в вашем мире, Лидия? Или это случайность и нам повезло?" "Это подход, который работал, когда вы делали концепт. В производство такими темпами не запускают". "То есть, вы считаете, что планирование и размышления над планами, диаграммами и схемами - это только для стадии разработки концепции?" "Типа того, да. Дальше, когда в проекте начинают работать сотни людей, планы становятся неактуальными и все эти построения просто бесполезны. Надо просто делать и корректироваться по ходу". Опять длительная пауза, во время которой руководитель разработки что-то искал на своем компьютере. Наконец он выдал: "Вот отчет по зрелости процесса разработки от нашего аудитора. Одни и те же консультанты проверяют нас третий год подряд, так что есть, что сравнивать. В Феврале у нас был CMMI уровень 4, сейчас мы скатились на второй. И знаете, что сказал главный консультант не под протокол? Что мы потеряли всяческую организацию за удивительно короткий срок". "А что-нибудь, кроме обычного консалтерского бла-бла-бла в отчете есть?" - наконец встал на защиту Лидии Фрэнк. "Конечно есть. К примеру он пишет, что задокументированный процесс внесения изменений в конструкторскую документацию не соответствует описанному процессу и настроенным рабочим процессам PDM". "Консалтерское бла-бла-бла, как и было сказано", - ухмыльнулся Фрэнк. "Ну, давайте переведу на понятный язык, - вмешался Викрам. - Вот поднимем график проведения собраний с прошлой недели и протоколы". Он открыл свой календарь, весь раскрашенный в разные цвета, с множеством накладывающихся друг на друга блоков, и открыл блок Нейрокода, но уже в строгой синей гамме. "Смотрим. Вот совещания на этой неделе. Складская логистика, потом цепочка поставок, продажники и маркетинг, интеграторы, программисты, железячники и группа запуска. Видите?" "На что мы смотрим?" - спросила Лидия? "На пункты повесток и задачи из протоколов". "Ну, что мы должны в этом увидеть? Пункты задач, мы все про них знаем", - Фрэнк тоже начал злиться. "Они не связаны между собой. Все проводят совещания только по своим пунктам в рамках своих зон ответственности". "Ну правильно, своих дел хватает, чтобы еще чужими заниматься". "Да, но в моделях процессов у нас есть стрелочки между этими функциональными блоками. То есть пункты повесток этих собраний должны быть связаны, а в протоколах должны быть задачи не только своему подразделению, но и смежникам. Про это мы и говорим - когда мы сидели и планировали совместную работу на диаграммах, мы очень много взаимодействовали между функциями, ставили друг-другу задачи, процесс у нас был сквозной, а не ограничен рамками отдела, как сейчас". "Давайте по-простому, Лидия. - встал главный программист. - Сейчас бардак с организацией и мы отдельно договариваемся по тому как сделать работу и отдельно по тому как отчитаться. И отчетность перестала адекватно отражать то, что происходит в проекте. Работаем мы не по методу, как привыкли, а как придется, в результате не можем улучшать работу, не можем нормально планировать и давать обязательства". "И что? Почему меня как руководителя должно это волновать пока вы даете нужный результат?" "Да где мы даем нужный результат?!" - завелся было технолог, но Викрам остановил его.
"Давайте я объясню все без технического жаргона. Без всех этих валидаций, технического долга и прочих вещей, которые могут запутать понимание. Представьте, что вы управляете туристическим агентством и вам надо организовать поездку для группы по какому-то довольно сложному маршруту, с перелетами, автобусными поездками, размещением и питанием. Есть два способа управлять принятием решений. Вы можете принимать во внимание мнение только одного человека, например, спонсора этой поездки или неформального лидера группы, либо вы можете балансировать интересы так, чтобы не было особо недовольных. И вот, вы везете людей по маршруту и вас подводит перевозчик, дает автобус меньшей вместимости, так что люди влезут, а багаж пока останется в отеле, и его надо будет перевезти позже. Ничего особо критического, если часть вещей вы довезете завтра, а оставшиеся в течение пары дней. Вот непривезенный багаж и есть метафора технического долга. Мы пообещали привезти все, но привезли только самое важное. У нас в проекте сейчас все больше непривезенного багажа, а кое-где и пассажиры в пути остались, и мы даже не знаем, не потерялся ли кто сейчас, потому что группа большая, путь длинный, а отчетность не отражает того, что в нашей поездке происходит". "Метафора страдает. - ответила Лидия. - В поездке у нас есть манифест и мы точно знаем количество пассажиров, маршрут, условия обслуживания. С качеством и тем, как его мерить, все понятно. А тут мы сами себе хозяева, так что вариантов привезти всех в пункт назначения куча и все они будут успешными". "Ну, не совсем так. У нас есть спецификация продукта, она является частью контракта поставки заказчику и мы должны ее выполнить. И вот метод управления поставкой продукта и метод управления проектом как раз позволяют предсказать, хватит ли тех ресурсов, которые у нас есть и которые мы можем достать, для реализации спецификации продукта и выполнения планов проекта. Возвращаясь к нашей метафоре - вот смотрим мы на остатки туристических сборов, на текущие расходы и плановые расходы, на расценки перевозчиков, на ставки аренды и зарплату сотрудников, и понимаем, в плюсе мы с поездки или в минусе. Но если всего этого нет и вы просто везете туристов, не глядя на цены, маршруты и затраты, то да, в середине поездки у вас лидер группы может быть очень довольным, потому что все очень круто, вы останавливаетесь в хороших отелях, обедаете в хороших ресторанах, но вот скоро вы обнаружите, что деньги кончились и ваша группа осталась в горах без денег, медпомощи и обратных билетов. И наш проект скорее попадает в эту категорию". "А почему я слышу про спецификацию продукта только сейчас?" - Лидия на самом деле ничего про нее не помнила. "Ну, обычно ее реализацией занимаются инженеры и менеджеров сама по себе она не очень-то и волнует, им важнее исполнение планов проекта и выполнение контрактных обязательств, а это довольно далекие от спецификации материи". "Ладно, со спецификацией мы разберемся на следующей неделе. Теперь объясните мне как вы предлагаете исправить ситуацию и что такое успех проекта в вашем понимании?" "Вначале я объясню, что такое схема, когда мы говорим про восприятие успешности проекта. Вот представьте, что вы едете на машине по трассе из столицы в регион. Выехали вы с полным баком и проехали 300 км, индикатор показывает, что осталось еще 50% бака. Вам надо принять решение заправляться. Чем дальше в регион вы выезжаете, тем дешевле топливо, поэтому чем позже вы заправитесь, тем больше сэкономите. Когда вы заедете на заправку?" "Ну, условно, через 280 км". "Видите, это сработала ваша схема. Вы использовали ее для предсказания того, что будет в будущем и можете принимать решение прямо сейчас, а исполнять это решение потом. Да, это очевидно, я знаю, поэтому немного усложню задачу. Теперь вы знаете, что чем дальше вы отъезжаете от столицы, тем больше вероятность того, что топливо будет плохое, разбавленное и вам его недольют. Это повлияет на работу вашей схемы и вы заправитесь раньше. Так вот - и в том и в том случае вы свою заправку посчитаете удачной, нормальной, хотя в одном случае вы заправились раньше и дороже, а во втором случае позже и дешевле. Реальность не изменилась, это все те же заправки, те же риски. Меняется только ваше восприятие реальности, ваша схема предсказания. Для того, чтобы сделать сложную штуку типа нашего автопилота, нам надо много разных людей, у каждого из которых своя схема предсказания, которая работает в рамках его специальности, его дисциплины и технологии. Викрам вон системный инженер, я разработчик ПО, там вон сидят ребята, которые отлично разбираются в обработке видео с камер и его сжатии на лету. У всех свои схемы, и все по-своему предсказывают будущее. Так вот, успех - это когда никто не видит очевидного провала. Никто, а не только человек, который выписывает чеки". "И что, вы предлагаете мне увязывать видение успеха проекта всех 200 человек, которые в нем участвуют? Это невозможно!" "Ну, и да и нет. Фактически, есть три группы проектных и процессных ролей. Есть инженеры, которые видят успех в реализации продуктовой спецификации. Есть менеджеры, которые видят успех в выполнении всех контрактных работ в рамках имеющихся ресурсных и временных ограничений. И есть продажники с производственниками, которым важно, чтобы были выполнены планы продаж и клиент был удовлетворен при использовании продукта. У каждой группы есть свой метод, свой набор схем, с помощью которых они предсказывают будущее, оценивают успешность проекта. Есть метод управления поставкой продукта, есть метод управления проектом. Успех - это когда метод отражает схемы всех трех групп и мы следуем методу". "Ох, парни. Еще раз - что вы практически предлагаете сделать? Вернуться к методической работе, которая у вас была?"
 |
| Метод управления поставкой продукта |
 |
| Метод управления проектом |
 |
| Связь методов |
Сцена 3. “Что такое правда и удивление”.
В понедельник Лидия впервые за последние пару месяцев выспалась. Вик пригласил ее к 10:00 и в офис она вошла в 9:50. На телефоне было 12 не отвеченных вызовов, но ничего важного, хотя кто-то настойчивый с неизвестного номера набирал 5 раз. Но Лидия не хотела пока сбивать себе настрой перед важной встречей. "У себя, ждет," - знаками показал ей личный помощник Вика, и она открыла дверь. И тут у нее появилось очень нехорошее предчувствие. Кроме Донаги в его огромном кабинете сидела еще Донна, с ней было понятно, такие разговоры без HR не происходят, а вот кто был высокий мужчина австралийской внешности в темно-синей поло и светлых штанах? На безопасника не похож, но и на внутреннее расследование тоже. Странный тип, совсем не в стиле AnyCorp. Начал диалог Вик: "Это Рональд, наш независимый внешний аудитор по технологическим проектам. Мы с ним работаем уже 12 лет". "Можно просто Рон", - протянул тот руку. Пожатие было твердое, уверенное, легкая улыбка очень уверенного в себе профессионала, который пришел с плохими новостями. На поло крокодил Lacoste атаковал таксу Harmont & Blain, такса огрызалась. Человек с юмором, а новости явно плохие. Лидия села в кресло и оглядела присутствующих, ей пришлось глубоко выдохнуть, чтобы не перейти в агрессивную защиту. Сейчас надо быть крайне осторожной. Она расслабила тело и искреннее улыбнулась. А, вспомнила, Рон же бывал несколько раз в ее офисе и ей даже говорили, что он какой-то там контрактор, это было полтора месяца назад, значит, она уже давно находится у него в разработке. Хорошо, держим это в уме. Вик кашлянул: "Лидия, ты не можешь уйти с проекта". Здесь надо удивленно вздернуть брови, пусть будет спектакль по-полной: "То есть, повышения пока не будет? Почему?" Вик был финансист, эмоциональный интеллект не был его сильной стороной, и по его лицу явно можно было прочитать искренний ответ: "Повышения не будет никогда". Но вслух он ответил: "Рон сейчас объяснит почему". Лидия обернулась к Рону: "Рон, объясни, как так получилось, что руководитель проекта DevProd не знает, что на его проекте идет аудит?" "Все объясняется просто. NDA, соглашения о неразглашении. Ключевые сотрудники подписали секретное соглашение и участвовали в аудите на условиях этого соглашения". "А встречались вы в секретных бункерах нашего инфобеза?" "По большей части в окрестных кафешках, в бункерах только записывали важные показания для возможной комиссии". Донаги хмыкнул: "Это стандартная практика, Лидия, ты знаешь об этом. Мы даже офисные разговоры не прослушивали, хотя у Донны есть на руках все основания, чтобы затребовать эти записи и приобщить их к делу". Лидия помнила, что записи хранятся 3 года и Вику некуда спешить. Но если Донна на их стороне, то дело совсем худо. "Давайте послушаем вас, Рон", - Лидия повернулась к нему с улыбкой. Рон вывел на настенную панель график с освоенным объемом проекта. "Это график освоенного объема и он не отражает реальности. Если судить по графику, то отставание по срокам 7%, а перерасход по бюджету 12%. В реальности все как минимум в 3 раза хуже". "Этот график формируется автоматически системой, Рон, вы в курсе? Так что не обвиняйте меня в ошибках проектного офиса, пожалуйста". "Нет-нет, конечно, Лидия. Я знаю об ошибках проектных офисов и манипуляциям с отчетностью почти все, и излагаю только неоспоримые факты. Так вот, как считается освоенный объем на проекте DevProd? При авторизации нового пакета работ, при его открытии, на освоенный объем списывается 50%. То есть, когда вы начинаете работу, по отчетности получается, что вы уже половину работы сделали. Нормально ли это? Да, это нормально. В проекте 340 пакетов работ, поэтому ошибка отчетности при таком подходе (1/340*2)*100%=0.15%. - Он записал эти расчеты на флип-чарте, остановился и осмотрел всех, затем продолжил. - Но только при условии, что авторизованный пакет работ закрывается, а не висит незавершенным. Другими словами, если вы используете такую методику учета, то надо отслеживать динамику незавершенной работы". И он вывел на экран следующий график с надписью Design-in-Progress. У Лидии замерло сердце потому что она поняла, что именно этот график исчез из отчетности 2 месяца назад, и она этого не заметила, потому что появилось много других отчетов о запуске производства, а истинное значение этого графика о незавершенной работе она до этого момента не понимала. Рон продолжал: "Видите этот пик 6 недель назад? Резкий рост количества авторизованных пакетов работ. Я наложил его на график освоенного объема и выделил только промежуток 2 месяцев, обратите внимание на этот отчет (он обвел его красным маркером). Создается четкая и убедительная картинка того, что команда поднажала и стала наверстывать опоздание. Но на деле, посмотрите на показатели скорости работ (он обвел другой график зеленым) - они снижаются 4 месяца подряд во всех командах. Исключение составляет команда системных инженеров, руководитель этой группы Викрам, фамилию я не могу произнести, извините". "Майтхилишаран. Викрам Майтхилишаран". - Лидия помнила всех лидов. "Неважно. Я привел этот случай с отчетностью как наиболее явный и понятный, хотя есть еще 3 аналогичных несоответствия и с десяток поменьше. Полный отчет о состоянии проекта в этой папке", - Рон открыл сумку, достал оттуда нетолстую, но достаточно увесистую папку и передал ее Лидии. "Вик попросил не убирать из отчета ничего, здесь полная версия. Записи интервью и расшифровки я передал вам на SecurePad, тоже можете ознакомиться". Заговорила Донна: "Для протокола. Лидия не отстраняется от управления проектом. На время разбирательства отчетность проектному комитету будет проходить не 1 раз в месяц по упрощенной процедуре, а каждую неделю по полной. Документы об изменениях в управлении проектом направлены на SecurePad Лидии". "Собрание прошу считать оконченным", - Вик встал из кресла и показал всем на выход. Лидия держалась прямо и свободно, дышала диафрагмой и контролировала походку. Рон смотрел ей вслед с сожалением.
20 минут спустя она сидела в греческой забегаловке недалеко от офиса и ковыряла вилкой остывавшую питу. Отчет Рона она уже прочла и ситуация на проекте была ясна. Наконец в кафе зашла Донна, она была на взводе: "Какого черта, Лидия, ты почему трубку не берешь?" "Не знала, что это ты, извини". "Не буду же я тебе со своего личного телефона звонить, чтобы предупредить о дисциплинарном слушании". "Да, ты права. Но давай подумаем, что делать". "Тебе надо вытащить этот проект, тогда дело можно будет закрыть". "Этот проект безнадежен". "Я знаю, но его надо вытащить, давай подумаем как". Но Лидия не хотела думать, она хотела пройтись по осеннему городу и подумать. И она не знала, можно ли верить Донне. Она точно не могла верить Вику и Фрэнку, Фрэнк, похоже, ее и подставил, хотя вряд ли по своей инициативе, вопрос, кто его попросил - Вик или Донна. Но, похоже, она могла верить Викраму, Викраму Майтхилишаран, руководителю группы системной инженерии, который ее предупреждал о критическом состоянии проекта и который предлагал ей выход. А других вариантов у нее пока не было, за неделю надо было показать прогресс, иначе следующей ее позицией будет дирекция по развитию во главе департамента из пяти человек, и максимум, что она будет делать - это презентация раз в месяц. И денег у нее будет намного меньше, в тот самый момент, когда они ей так нужны.
Она достала планшет, нашла сообщение Викрама с предложениями по реорганизации управления проектом и начала читать. Презентация была очень запутанной и сложной, единственное, что она поняла, так это то, что вместо функционального деления по отделам Викрам предлагал вернуться к сквозным процессам, которые были в их стартапе изначально. А дальше это все как-то связывалось с моделью жизненного цикла, ролевой моделью проекта, отчетностью. В общем, это было непонятно, такое в нашем цирке не сделать и никому не продать. "OK, Google, позвонить Викраму", - она отвернулась от проезжей части, чтобы ее было лучше слышно, и стала ждать, когда ей ответит слегка хриплый голос с сильным акцентом. Через 10 минут они сидели в комнате для совещаний бизнес-центра и обсуждали презентацию. "Я готова менять управление проектом, но чтобы это сделать, мне нужно перевыпустить устав. А, значит, его должен подписать Вик Донаги. И он не подпишет ничего того, что не понимает. Поэтому, если мы хотим изменить подход к тому, как мы управляем, надо рассказать, чем твоя схема управления лучше текущей". "Лучше тем, что текущая схема не работает". "Ты не понял. Вик консервативен. Текущее управление дает результат - мы запустили производство и начали продажи. На все предложения он просто скажет, что надо лучше стараться и больше работать, а не пытаться найти волшебное средство". "Это не волшебное средство, мы так работали и было намного лучше". "Во-первых, вас было всего 37 человек, а нас сейчас 280 только в команде плюс производство плюс поставщики и подрядные организации. И это тоже проблема, потому что сквозные процессы надо продать не только Вику, но и, к примеру, Стэну Ли". Викрам задумался и начал пояснять свою презентацию. Через пять минут Лидия его остановила: "Ты только больше меня запутываешь. Давай начнем с базовых понятий, например, ты вводишь какие-то функциональные процессы и сквозные процессы, в чем между ними разница? И когда будешь объяснять, представь, что у тебя на плече сидит маленький человечек, который слушает все, что ты говоришь и задает один вопрос - ну и что? Договорились?" - Лидия одобряюще улыбнулась и Викрам начал. "Начать надо будет не с определения что такое процесс, а с более базовой вещи, с объекта. Есть ли у вас зеркало в косметичке?". Лидия открыла сумку и протянула ему пудреницу. Викрам открыл ее, повернул зеркало к Лидии и задал вопрос: "Что вы видите?" "Себя, свое лицо". "А если точнее?" "Ну, точнее зеркальное отражение своего лица". Тогда Викрам взял в руки пульт освещения и начал убавлять яркость потолочных светильников. "Что происходит?" "Ну, отражение меняется, изображение становится темным". Викрам добавил освещение и переключил свет с холодного оттенка на теплый. "Ну, опять отражение изменилось". Лидии стало надоедать: "К чему ты клонишь?" "Почему твое отражение меняется?" - задал Викрам очередной вопрос. "Потому что ты меняешь характеристики освещения и конечно меняется отражение в зеркале". "А можете объяснить подробнее, что происходит? По шагам?" "Из лампы вылетает луч света, он падает мне на лицо, отражается от лица, попадает на отражающую поверхность зеркала, отражается от нее и попадает мне в глаз, где я его и вижу. Когда ты меняешь характеристики луча света, который вылетает из лампы - делаешь его сильнее или слабее, меняешь оттенок от холодного до теплого, то меняется и то, что я вижу. Так понятно?" "Да, спасибо большое, так понятно. Другими словами, есть ряд связанных между собой фактов - то, что я меняю свет лампы и то, что вы видите в отражении зеркала, и эти факты связаны между собой потому что так ведет себя луч света?" "Дурацкое какое-то объяснение, но да. Ты крутишь регулятор лампы, меняется отражение в зеркале. Как это нас пододвигает к обсуждению модели управления?" "А если бы мы спросили пятилетнего ребенка про то, почему когда крутишь регулятор лампы, меняется его отражение в зеркале, что бы он ответил?" "Ну не знаю, можно попробовать и спросить". "Но смог бы он объяснить это так, как объясняете это вы?" "Ну, наверное, нет, по крайней мере если не задавать вопрос Гуглу". "Смотрите, Лидия, здесь есть важнейший момент. Объект - это такая штука, которая связывает разные факты причинно-следственной связью. Я меняю свет лампы и вы фиксируете этот факт, и вы видите как меняется ваше отражение в зеркале и фиксируете этот факт. И в вашей голове строится логика - ага, эти факты между собой связаны с помощью луча света". "И что? Это и без луча света интуитивно понятно любому ребенку". "Да, но объект 'луч света' позволяет вам не просто строить причинно-следственные связи, он помогает вам предсказывать факты, которые вы еще не наблюдали. Допустим, представьте, что я возьму вот эту маленькую ложечку и буду закрывать ей светильник, что вы увидите? Вы увидите, что отражение понемногу темнеет по мере того, как я приближаю ложечку к источнику света. Ребенок, который не знает про основы оптики, скажет, что ничего не будет, потому что у него в голове нет хорошего, качественного объекта, который связывает эти факты между собой". "Ну хорошо. У тебя какое-то свое представление о том, что такое объекты, но допустим это так. Теперь вспомни про маленького человечка на твоем плече, который спрашивает тебя 'ну и что из этого следует?'" "Из этого следует одна важнейшая штука - от набора объектов в голове Вика зависит то, какие логические взаимосвязи он видит в мире. А так как успех - это когда ожидания совпадают с фактами реальности, то если мы будем знать, какие объекты, понятия есть в голове Вика, то сможем предсказать, какой набор фактов будет для него убедительным доказательством того, что мы даем дельные предложения". "Другими словами, ты хочешь сказать, что в целом любой объект как-то обобщает набор фактов в логический вывод. Если мы знаем, какие объекты, типа лучей света, есть в голове Вика, то мы понимаем его логику, и сможем представить твой набор предложений так, что Вику будет понятно?" "Точно!" "Тогда возникает два вопроса. Первый - как получить этот список объектов. Второй - не все так просто, нельзя свести определение успеха проекта к одному объекту". "Ну да, предлагаю вернуться к начальной схеме, которая описывает весь метод управления проектом".
"Вот у нас есть продукт, который мы создаем, система. Процесс ее создания, использования и вывода из эксплуатации разбит на стадии жизненного цикла. И весь метод управления состоит из 4 частей - надо заключать договора закупки и поставки, надо обеспечивать проект организационно, надо управлять стадиями жизненного цикла и надо создавать саму систему. Поэтому правильнее говорить не то, что у нас есть пользователь системы и команда проекта, фактически, у нас есть группа стейкхолдеров со стороны клиента и три группы внутренних стейкхолдеров. Есть инженеры, которые видят успех в реализации продуктовой спецификации. Есть менеджеры, которые видят успех в выполнении всех контрактных работ в рамках имеющихся ресурсных и временных ограничений. И есть продажники с производственниками, которым важно, чтобы были выполнены планы продаж и клиент был удовлетворен при использовании продукта. Такое разбиение мы сейчас уже имеем по факту на проекте и оно правильное. Давайте вернемся немного в прошлое, помните фразу на совещании на вашей даче? Успех - это когда никто не видит очевидного провала? У каждой группы стейкхолдеров есть свой метод, свой набор схем, с помощью которых они предсказывают будущее, оценивают успешность проекта. Есть метод управления поставкой продукта, есть метод управления проектом." "Подожди, подожди, Викрам. Мы говорили про объекты, а сейчас ты опять стал говорить про схемы, я совсем запуталась". "Схема - это набор объектов, которые как-то связаны между собой. Вы раньше сказали, что нельзя свести определение успеха проекта к одному объекту, но его можно свести к схеме". "Подожди, а как схемы связаны с этой твоей картинкой?" "Каждая группа процессов описывается каким-то непротиворечивым набором схем, то есть набором объектов и логичных связей между ними. Допустим, заключение договоров явно использует объекты из договорного права, из переговорных практик, и все эти объекты между собой связаны, продажники и закупщики хорошо друг-друга понимают". "Так, а еще примеры?" "Ну, скажем, управление проектами. Там есть понятия PMBOK и они тоже между собой связаны. Например, понятно, как иерархическая структура работ становится календарно-сетевым графиком. Или технические процессы, мне ясно, как системные требования связаны с архитектурой системы". "Так, хорошо. Внутри каждой группы процессов у нас одна схема, по которой стейкхолдеры предсказывают что должно случиться, и если они видят, что случается то, что они ожидают, им это нравится и они считают проект успешным". "Да, все верно. Можем двигаться дальше?" "Подожди, Викрам. А почему людям нравится быть правыми, угадывать, может, ты и это знаешь?" "Если очень просто, то внутри мозга есть машинка для предсказаний, которая работает на основе схем, которые мы только что обсудили. На вход этой машинки поступают факты, машинка предсказывает, что должно произойти дальше, делает ставку (hold a stake, откуда и происходит термин "стейкхолдер") на какой-то вариант событий в будущем. И дальше эта машинка переходит в режим наблюдения, ищет подтверждающие этот вариант факты. Если предсказание сбылось, машинка вырабатывает дофамин, который говорит нам, что мы молодцы, правильно угадали. Как-то так". "Ага, понятно. Теперь объясни мне одну вещь. Ты говоришь, что проект сейчас организован правильно. Есть закупщики, продажники, инженеры, руководители, у них есть схемы в голове, они предсказывают, что-то делают и так далее. Так что же ты предлагаешь менять?" "Я задам встречный вопрос. Если мы угадываем, то нам становится хорошо. А вот если не угадываем, то чувствуем себя плохо, считаем, что мир неправильный. Ну, по крайней мере, это всегда первая мысль, которая приходит в голову, что-то здесь не так. Другими словами, схема не всегда предсказывает успех, скорее надо говорить, что схема описывает правду, как ее видит конкретный стейкхолдер. Любой человек, когда видит какой-то факт, пытается описать его своей схемой, помните, мы смеялись над Стэном Ли, когда ходили в столовку, а он везде видел очереди задач, запасы материалов и потери? На самом деле, мы все так делаем, просто он хорошо осознает свой способ мышления, а большинство людей даже не осознают, какими схемами они пользуются в данный момент". "Ну а какими схемами пользуюсь я, Викрам?" "В основном социальными, вы хорошо понимаете людей и их отношения. Я понимаю математику и физику, я инженер. А Вик Донаги разруливает сложные социальные взаимодействия, контрактные вопросы и обязательства. По большому счету, если мы говорим про схемы, то они распадаются на эти три большие группы - объективные схемы, которые описывают реальный мир, субъективные схемы, которые описывают внутренний мир, и социальные схемы". "Стоп-стоп-стоп. Я теряю мысль. Я тебя спросила, на что будем менять текущую правильно организованную модель управления и почему?" "Понял вопрос. Поясню, что хочу сказать. Вот есть разные группы стейкхолдеров, у каждого своя схема предсказаний, на основании которой они действуют. Но чтобы проект был успешным, нам надо, чтобы они все были счастливы. Чтобы все предсказания сбылись. Нам нужна суперсхема, которая сведет все локальные предсказания по областям проекта в единое целое. Тот метод, который я предлагаю, это делает, но я еще не приступил к объяснению того, как он работает". "Мда, это будет длинный вечер". "Ничего, вы привыкли. И я привык. Так что продолжим. У нас есть три группы схем - объективные схемы, субъективные схемы и социальные схемы. Условно говоря, Шерлок Холмс, Харуки Мураками и Фрэнк Андервуд. Ну или научный метод, самопознание и политология с социологией и правосудием, как вам понятнее. Соответственно, вы можете наблюдать три группы фактов - объективные факты, которые могут видеть разные люди, субъективные факты, которые видит только сам человек, личность, и социальные факты, договоренности и исполнение договоренностей, социальных контрактов и обязательств. У этих фактов есть последствия - физические, субъективные и социальные. Например, объективный факт: я бросил этот стакан. Объективное последствие: стакан упадет на пол. Субъективный факт: я считаю, что увольнение несправедливо. Субъективное последствие: я обижен. Социальный факт: мой трудовой договор предусматривает работу с 9 до 19, я работаю с 7:30 до 21:00. Социальное последствие: у меня возникает право на оплату сверхурочных. И есть три вида моделей - те, которые моделируют реальный мир, те, которые моделируют субъективный мир, и те, которые моделируют социальный мир. Эти модели можно зафиксировать в схемах. Фиолетовые блоки относятся к моделям субъективным, желтые и коричневые к социальным, а голубые и зеленые к объективным. А получившаяся мультимодель как раз реализует суперсхему, которая позволяет предсказать какой вариант мира будет считаться участниками успешным".
"Слишком сложно, Викрам, слишком абстрактно. Давай конкретное применение этой мультимодели или суперсхемы, ты же еще называешь ее по-разному". "Хорошо, давайте конкретно. Возьмем последнее запрошенное инженерное изменение по изменению корпуса нашей коробочки. Меняется корпус, значит, надо проверить, можно ли его смонтировать на все целевые модели автомобилей и не сломается ли она (зеленые элементы модели). Надо понять, может ли поставщик перестроить производство, сколько времени это займет и сколько будет стоить (коричневые элементы модели). Закупщики должны сказать, когда они внесут эту позицию в закупочную спецификацию, а логисты скажут, когда они это привезут. Технологи должны изменить процесс сборки и монтажа, внести изменения в производственную документацию, а группа производственного контроля отследить реализацию инженерного изменения (желтые элементы модели). Все эти отдельные планы со сроками, ответственными и прочими моментами должны попасть руководителю проекта и он должен принять решение, имеет ли смысл проводить это изменение. Даже в таком простом случае есть множество прогнозов и ожиданий и если это изменение пойдет вразрез в ожиданиями и планами проектировщиков, закупщиков, продажников или руководителей, то успешным оно не будет. И чтобы принять решение о том, реализовывать это изменение или остаться на стадии внесения запроса на изменение, лучше бы иметь схему, которая учитывает все эти частные планы. А если подняться с уровня отдельного изменения до уровня всего проекта в целом, то такая схема и будет такой вот супер-схемой". "Ну ладно, хорошо. А почему ты говоришь про мультимодель?" "Схемы же в голове, а когда мы переносим содержимое головы на бумагу или в компьютер, то у нас схема преобразуется в модель". "Окей. И что дает перенос схемы в модель?" "Во-первых, можно обсудить свои мысли с другими людьми, да хоть и с самим собой из другой ролевой позиции, во-вторых, можно проверить логику рассуждений, если модели достаточно строгие, а в-третьих, мы можем сопоставить разные схемы и понять, не противоречат ли друг-другу разные планы". "Хорошо, но все эти планы, схемы, они же про только объективный мир, про железки. А ты говорил еще про социальный мир и внутренний мир личности?" "Ну как. Обязательства же тоже можно выразить в модели, тот же контракт поставки, например, или стратегию реализации проекта. А внутренний мир - это целеполагание, вот они, фиолетовые квадратики и стрелочки между ними. Возвращаясь к примеру с инженерным изменением, мы можем записать проектные ограничения в виде модели целеполагания и проверять, не нарушают ли предлагаемые изменения этих ограничений". "Давай приземлим это на конкретную ситуацию. Вот наш проект, вот пусть даже ты смоделировал все мои схемы о том, как я считаю должно быть. Но ведь я была неприятно удивлена, когда узнала, что отчеты по освоенному объему не отражают реальности". "Удивление - это реакция на несбывшееся предсказание. Мы испытываем удивление, когда наблюдаемые факты не соответствуют схеме. Надо ловить этот момент, он означает, что надо менять схему, потому что она неверна". "Давай закруглимся на сегодня, подведи итоги". "Люди фиксируют факты, факты они объединяют в логические цепочки с помощью объектов. Объекты и связи между ними формируют схему в голове человека. Схема предсказывает вариант возможного мира. Человек запоминает этот предсказанный вариант возможного мира и когда наблюдает факты, сравнивает их с тем, что он запомнил. Если факт укладывается в предсказанный вариант, то человек получает дофаминовое подкрепление и убеждается в том, что его схема верна. Это и есть успех действия. Человек воспринимает предсказания схемы как правду и чаще всего не готов ставить факты и логику, которая связывает их, под сомнение. Если наблюдаемый факт не укладывается в предсказание, то человек удивляется, в этот момент он может изменить схему, то есть либо поменять объект либо поменять связи между объектами. Факты могут быть объективными, социальными либо субъективными, соответственно, схемы тоже могут предсказывать либо возможный вариант реального мира либо возможный вариант поведения человека либо социальные последствия. Если выразить схему на бумаге или на компьютере, то получится модель. Модели можно обсуждать с другими и проверять на ошибки и согласованность между разными моделями. Так организуется междисциплинарная работа. Это я и предлагаю сделать". "Я посплю, подумаю над всем, о чем мы сегодня говорили, и мы продолжим обсуждение твоих предложений, Викрам. До встречи". "До встречи, Лидия".
Глава 4. В которой Лидия разбирается, что такое метод, онтология и пространство выборов, а также в том, как моделирование позволяет достичь успеха проекта.
Лидия зашла в кабинет системных инженеров, в первый раз за все время. На стене висел плакат с какой-то теткой и ее цитатой: “До Второй мировой войны жизнь была проще. После неё у нас появились системы”, подписано "Грейс Хоппер". Викрам сидел в наушниках за своими четырьмя мониторами, с бешенной скоростью набирал что-то на двух клавиатурах, и работал с трекболом. Остальные смотрели на быстро меняющуюся модель их устройства на своих экранах и о чем-то переговаривались между собой. Викрам доделал свои дела, снял наушники и улыбнулся ей. "Привет, Лидия. Ну как, продолжим обсуждение?" "Не знаю, меня что-то не особо зацепила пока идея. Не понимаю, как это поможет. И вообще не понимаю, что такое объект". "Ну вот посмотрите. - Викрам встал и прошел к флип-чарту. - Почему летом на улице теплее, а зимой холоднее? Какая причина?" "Орбита Земли эллиптическая и зимой просто мы улетаем дальше от Солнца, поэтому тепла меньше и наступают холода". "Но как тогда вы объясните два факта - на экваторе, где-нибудь в Сингапуре, температура круглый год 30 градусов, а летом открытые плечи загорают сильнее, чем шея?" Лидия задумалась, эти неоспоримые факты и в самом деле рушили стройную схему ее рассуждений. Но она ничего за пять секунд не придумала и пожала плечами: "Спорить не буду, раскрой секрет". "Никакого секрета нет, все, что я сделал - это фальсифицировал вашу теорию, показал факты, которые она не может объяснить. Если немного разобрать, как вы рассуждали, то скорее всего получится что-то такое. Зимой до Земли долетает меньше тепла от Солнца. Из опыта я знаю, что чем дальше источник тепла, та же батарея или печка, тем меньше она греет. Я знаю, что орбита Земли эллиптическая, значит, в какой-то момент Земля просто улетает от Солнца так далеко, что до нее долетает намного меньше солнечных лучей и тепла, и настает холодное время года. Это абсолютно логичное рассуждение, которое построено на объекте дистанция до источника тепла. И эта модель порождает верное предсказание - чем дальше до источника тепла, тем будет холоднее. Но если посмотреть на орбиту Земли, то мы увидим почти чистый круг, эксцентриситет орбиты Земли составляет сотые доли. Модель хорошая, но она не объясняет факты.
Нужен другой объект, который сможет обобщить, собрать все факты. Подумайте над тем, почему загорают плечи и почему на экваторе температура неизменная? Что обобщает эти факты?" Лидию позабавила эта задачка, хорошо, что все сидели в наушниках и никто не слышал этого разговора экзаменатора и ученицы. "Угол падения лучей", - наконец выдала она ответ. "Да, угол падения лучей хорошо обобщает все известные нам факты. Чем угол падения больше, тем меньше греется предмет от источника тепла даже если расстояние не меняется, потому что тем больше тепла отражается обратно от поверхности".
Поэтому хорошо подобранные объекты позволяют сделать верные предсказания и сформировать метод управления проектом, который приведет нас к успеху. Видите, например, как я повлиял на ваше мышление, просто предъявив вам факты, которые вы не смогли объяснить своей текущей схемой? И в тот момент, когда вы удивились тому, что ваша схема дает неверное предсказание, я смог предложить вам другую схему, которая объясняет эти факты. Такой же трюк надо проделать и с Донаги". "Но это ведь означает, что надо вытащить из его головы схемы его мышления?" "И еще раз да". "Хорошо, я поняла что объект сворачивает множество фактов в какую-то одну схему, модель. Так сказать, знание немногих принципов освобождает от знания множества фактов. Эти факты, получается, можно попросту вывести из принципов, из схем. Но как все это связано с методом? Как это применяется к твоему предложению?" "У меня есть старший брат, от военный летчик-снайпер. Он не особо любит говорить про свою работу, но однажды он долго рассказывал как их готовили летать в сложных метеорологических условиях, ночью, при минимуме погоды, в составе крыла. Не то, чтобы их сразу из училища послали в ночное задание всей эскадрильей, нет. Вначале их учили взлетать и садиться. Потом летать и делать простые маневры. Потом выполнять сложные маневры. Потом взлетать и выполнять простые маневры звеном. Потом они осваивали сложные маневры звеном, прикрытие и трюки. Потом делали простые одиночные ночные вылеты, потом ночные вылеты звеном ну и так далее. На каждом этапе навыки доводились до автоматизма и только потом они переходили к отработке следующей ступени. И если сейчас я попрошу его описать то, как он летает ночью при минимуме погоды, то он будет сыпать специальными терминами, объектами, которые собирательно описывают для него кучу фактов этой крайне сложной деятельности. Но самих терминов будет немного, с десяток. Сложная деятельность описывается небольшим количеством объектов и схем с использованием этих объектов. Там, где новичок просто потеряется в сложности происходящего - в показаниях приборов, командах ведущего, мельтешении теней, быстро несущемся на него пейзаже, огне противника, опытный пилот будет чувствовать себя уверенно потому что то же самое огромное количество фактов будет у него структурированно по небольшому количеству объектов. Условно, любой факт будет идти в какой-то ящичек, сразу понятно, что с ним делать, требует ли он действий и если да, то каких. Другими словами, у опытного пилота есть метод, который резко снижает сложность ситуации и позволяет действовать, а не тупить". Лидия кивала головой. "А что такое сложность?" - спросила она у Викрама и тут он запнулся и задумался. "Хороший вопрос. Сложность разбивается на три составляющие - сложность цели, сложность способности и сложность условий. Совокупная сложность задачи - это соотношение метрик этих отдельных сложностей. Допустим, летать днем проще, чем ночью, в хорошую погоду проще, чем при погодном минимуме. Это сложность условий. Вылетать на боевую миссию сложнее, чем на разведывательную или транспортную. И выполнить маршрут, который требует сложных скоординированных маневров сложнее, чем слетать по простой линии полета пчелы. Чем сложнее ситуация, тем более зрелый должен быть метод, чтобы снизить сложность ситуации. Ну или попросту так - на лайфхаках АЭС не построишь". "Ну окей. Но пока все равно не понятно, как метод позволяет предсказывать будущее". "Ну, простой пример. Я стал водить автомобиль только здесь. Когда я только стал ездить, то глаз с дороги не спускал, даже когда ездил медленно, потому что ситуация была сложной, сложно было доехать куда надо, сложно было управлять автомобилем, сложно было маневрировать в плотном городском потоке. По мере того, как я стал понимать, что множество отдельных действий от осмотра по сторонам в зеркала до поворота руля и выжимания педалей укладываются в объект "поворот налево", я стал думать о дорожной ситуации абстрактно - перестройся, поверни налево, займи правый ряд и съезжай на дублер. Такой переход на абстракции высвободил кучу моих ресурсов, и я смог повысить скорость езды, начал разговаривать во время езды, переключать радио. Другими словами, я стал переключать внимание с дороги на что-то другое и при этом я не врезаюсь. Теперь вопрос почему?" Лидия слушала, пока это было для нее каким-то перечнем банальщины. "Потому что после того, как я освоил метод езды на автомобиле, у меня в голове появилась картинка, модель реальной ситуации, и мне не надо все время смотреть на дорогу, потому что эта модель считается сама по себе и я понимаю, надо мне что-то делать или нет даже не особо глядя на дорогу. Конечно, временами я все-таки смотрю на дорогу, чтоб сверить картинку в уме с реальностью и откорректировать действия, но в целом из района я могу даже с закрытыми глазами выехать". "То есть ты хочешь сказать, что освоенный метод дает тебе новую возможность? Предвидеть будущее? И если я пойму, какое вариант будущего Донаги считает предпочтительным, то метод позволит тебе предсказать, какие действия надо сделать, чтобы в этот вариант будущего прийти?" "Именно так. Хотя с понятием возможности и способности надо еще разбираться, там есть смысловые нюансы. Пока отложим и поразберёмся с методом. Езжу на автомобиле я один, и поэтому метод может быть целиком в моей голове, мне не надо описывать его для других. Но вот наш проект так не сделать, у нас есть множество ролей, которые надо исполнить, чтобы метод был выполнен, и проект удался. И тут в общении начинаются проблемы, потому что в дело вступает семантика". "Что начинается? Викрам, скажи нормально". "Есть смысл, который мы понимаем в нашей голове, а когда мы передаем этот смысл другим, то мы выражаем его через какие-то символы, диаграммы, нотации, слова, языки. Вот такое выражение смысла через язык называется семантикой. И вопрос в том, как при достаточно сжатом, компактном изложении не потерять значимые куски смыслов. Семантика важна в двух аспектах - нам надо доносить то, что мы хотим сказать, до людей, переводить смысл для человека, и нам надо доносить то, что мы хотим сказать, до компьютеров, делать формализацию, чтобы автоматизировать метод". "Другими словами, ты хочешь сказать, что сложные мультидисциплинарные предсказания с помощью методов коллективного мышления делают группы людей с помощью компьютеров, и поэтому метод надо описывать в двух разрезах?" "Скорее в трех - обычно используется представление метода в виде диаграмм, а потом это представление развертывается в структурированный естественный язык, например, в Gellish, для людей, и в формальную постановку для дальнейшей автоматизации. Причем вначале нам надо таким образом описать факты, а потом создать компактный набор понятий, объектов, которые обобщат эти факты в небольшое количество схем предметных областей". "Ну хорошо, вот у тебя будет диаграмма, которая описывает набор фактов. Вот у тебя будет диаграмма, которая обобщает эти факты в какую-то концептуальную схему предметной области. Я одного не понимаю - ты мне с самого начала говорил, что метод объединяет разноплановых специалистов, позволяет делать междисциплинарное предсказание. Как это сюда укладывается?" "Над схематизацией предметных областей строится схематизация системная, которая объединяет разные предметные области, связывает их системными связями". И Викрам взял маркер и стал рисовать пирамиду.
Слово метод пошло от μέθοδος — путь исследования или познания, от μετά- + ὁδός «путь». Метод фактически предсказывает как пройти от текущей ситуации к целевому пространству состояний, к целевой ситуации, которая устраивала бы нас больше, чем та, которая есть сейчас. Но в одиночку туда не пройти, дойти к этой желаемой цели мы можем только вместе. Но раз мы стартуем в одной точке, мы все находимся в одной лодке, и хотим на этой лодке приплыть в одно и то же место, то мы должны разделять метод. Это, как описывал мой брат, принцип "отряд возвращается или погибает целиком". Другими словами, все участники проекта должны этот метод разделять. Сейчас, как вы понимаете, это не так, проект управляется ситуативно, приказами и распоряжениями, нет метода, нет коллективных предсказаний, и как следствие, нет обязательств одних участников перед другими, вся полнота ответственности лежит на вас. Случись что с вами и проект неизбежно закроется". Лидия просто поежилась в этот момент, настолько она ощутила всю хрупкость ситуации. "В любом случае, метод необходимо описывать тремя способами, нельзя ограничиться только версией стандарта предприятия, как это обычно делают в AnyCorp. Необходимо описать метод в диаграммах, на структурированном языке и сделать формальную постановку для автоматизации. При этом надо понимать, что метод должен описывать факты реальной жизни, иначе он будет бесполезным, должен вводить разделяемые командой понятия, иначе мы просто утонем в фактах и не сможем компактно излагать наши мысли и предположения, и должен позволять связать между собой разные предметные области, иначе все наши предсказания будут описывать мир однобоко, с позиции какой-то дисциплины, например, с финансовой точки зрения, логистической или производственной. А однобокость приведет к перекосам и неудовлетворенности всех остальных. Поэтому пирамида делится на три части по вертикали и три части по горизонтали. Снизу вверх будут уровни абстрагирования, а слева направо будут уровни формализации. Вверху абстрактное, справа формальное. Внизу конкретное, слева слабоформализованное. При этом чтобы метод работал, у людей должно быть схожее понимание понятий, объектов, схожее понимание того, как эти объекты объясняют факты деятельности (угол падения солнечных лучей, а не расстояние до Солнца). У них должно быть одинаковое понимание того, как эти понятия связаны друг с другом, как они соотносятся, какова логика рассуждений (солнечный луч поглощается поверхностью, чем меньше угол падения, тем больше солнечный луч поглощается поверхностью). Такое вот понимание, которое обеспечивает возможность людей договариваться по тому, что они будут делать, называется онтологией. Общее понятийное поле и логика работы с понятиями, объектами. Люди с одинаковой онтологией видят одинаковые объекты в мире и думают похоже, поэтому им легко договориться, если их цели совпадают". "А у компьютеров что?", - Лидия, наконец, хоть сколько-то заинтересовалась темой. "У компьютеров это тоже называется онтологией, набор объектов и связей между объектами, с помощью которых компьютеры обмениваются данными. Соответственно, есть онтологии предметных областей и системные онтологии". "Что-то я опять запуталась. Есть метод, если мы соблюдаем метод, то можем предсказать, в какой вариант будущего попадем. Метод основан на объектах, объекты обощают факты деятельности, на основе объектов мы строим модели, которые компактно описывают мир. Знание немногих моделей спасает от знания множества фактов, которые эти модели предсказывают. При чем тут онтологии?" "Онтологии предметных областей и онтология системного подхода позволяет команде понимать, обсуждать и улучшать метод. Онтология гарантирует, что все одинаково понимают происходящее и делают одинаковые выводы. Ну не знаю, приведу пример Нильса Бора, который в 1931 году выступил на Римской конференции с докладом о том, что принцип сохранения энергии не соблюдается. И у него были на это основания, просто в его онтологии не было такого понятия как нейтрино, ему нечем было объяснить исчезновение энергии в определенного вида реакциях. А как в физике появилось такое понятие и было доказано существование такой частицы как нейтрино, то все опять стали думать сходим образом и делать похожие выводы из одинакового наброа фактов. В этом и есть роль онтологии - думать схожим образом при одинаковом наброе фактов. Если опять вернуться к полетам в составе звена или езде на автомобиле по городским дорогам, то раделяемая онтология позволяет нам не сталкиваться, если мы видим одну и ту же ситуацию, если у нас есть одни и те же факты. А для метода управления проектом онтологии позволяют обсуждать предметные области". "Ага, то есть онтология нужна для передачи информации между людьми?" "Не только людьми, а агентами вообще, но да, для этого она и нужна. Только не надо путать передачу информации и передачу данных". "Та-а-а-а-к, а в чем разница?" "Передача информации подразумевает, что агент меняет свое поведение после получения информации, а вот обмен данными есть лишь необходимое условие для передачи информации. Нельзя передать информацию, не передавая данные, но вполне можно передать данные, не передавая информацию. Самый простой способ объяснить это, наверное, трехслойка из теории коммуникативного действия Юргена Хабермаса". Викрам быстро нарисовал на флип-чарте такую диаграмму.
"Допустим, вы ставите мне задачу на совещании. При этом происходит обмен физическими сигналами, звуковыми волнами. Я понимаю слова, которые вы мне говорите, это обмен по форме, понимание значения слов. Слова складываются в предложения и я понимаю вашу мысль, это и есть обмен информацией. Та информация, которые вы мне передаете подразумевает, что я что-то сделаю по-другому. И это можно проверить, записав поручение в протокол собрания. Это поручение является моим руководством к действию, гарантией того, что мы одинаково понимаем кто кому что пообещал. Все вместе - обмен по форме, обмен информацией и руководство к действию в совокупности составляет акт координации". "И ты имеешь в виду, что цепочка может прерываться на каждом этапе?" Викрам кивнул. "Не понимаю, как это связано с онтологией команды и онтологией компьютерной". "Ну как, чтобы понять мысль, мы должны одинаково интерпретировать понятия, которые мы используем. Если я говорю про решение какой-то проблемы и я обещаю эту проблему решить, то мы должны быть уверены, что мы говорим об одной и той же проблеме". Лидия в этом месте скривилась, потому что Викрам надавил на больное место, таких ситуаций в проекте, когда каждый понимал сказанное по-своему, было в последнее время много. "И с компьютерами то же самое, когда мы передаем данные о поставках и себестоимости, надо понимать, что мы ссылаемся на одну и ту же вещь реального мира, которая лежит на складе или едет в контейнере".
"Хорошо, есть команда, у команды есть метод, метод предсказывает будущее. Команда использует при общении один и тот же набор понятий и оперирует одинаковой логикой, поэтому они одинаково понимают кто кому что пообещал в ходе общения. Это все ясно. Но как это позволяет убеждать других в том, что проект успешен, я этого не понимаю," - Лидия откинулась на спинку кресла и внимательно посмотрела на Викрама. "Важна ли логика для системных инженеров? Нет. Потому что системные инженеры работают в ситуациях неопределенности, постоянных изменений и парадоксальных требований. Они постоянно должны решать противоречия. Большинство людей работают в своих функциональных зонах ответственности, они по определению крайне логичны, потому что нельзя сводить баланс или возить грузы, если ты не можешь очень четко логически мыслить. И никакие системные инженеры в такой ситуации не нужны. Системные инженеры нужны в ситуациях, когда логика не работает, когда люди столкнулись с парадоксом, дилеммой, противоречием. В тот момент, когда они застряли. Так что от системного инженера не требуется быть рациональным и логичным. Системный инженер должен быть вразумительным, здравомыслящим. Если бы логика всегда работала, никому и ни при каких условиях не потребовался бы системный подход. Не то, чтобы все идеи, которые я сейчас излагаю, выстраиваются в безупречно логическую цепочку рассуждений. Даже более того, тут полно логических пропусков и скачков. Но этот подход все равно лучше, чем то, что у нас есть сейчас. Мы застряли, Лидия, застряли. Мы идем в никуда, с нашим текущим замечательным, логическим, обоснованным подходом. Поэтому сделать этот шаг разумно, даже если он не полностью обоснован и не до конца логичен". "Ты думаешь, что меня можно сбить с мысли каким-то ответвлением от темы? Пока ты мне не расскажешь до конца всю цепочку рассуждений, пока я не пойму, какие риски несет этот переход, я ничего не смогу сделать. Пока ты не продашь эту идею мне, внимательному и заинтересованному слушателю, а я не продам ее Донаги, ничего не случится". "Чего хочет Донаги? Я почему-то уверен, что он часто говорит, что ему нужно решение минимальной стоимости, выполненное в кратчайшие сроки, выполненное наилучшим образом". "По большому счету да, это выжимка из разговор с ним". "Когда я получаю такой запрос, я всегда уточняю - а чем вы готовы пожертвовать? Ваша беда, Лидия, что вы в ответ на такой запрос всегда отвечаете "Хорошо, сэр, я немедленно это сделаю". Лидия промолчала, но мгновенно посуровела. Викрам безмятежно ждал пока она не почувствует свою злость и не начнет делать "квадратное" дыхание. Когда через безумно долгие 40 секунд он все-таки услышал от нее: "Продолжай", он сам выдохнул с облегчением и начал рисовать.
"Вы ездите на Tesla S. Как вы думаете, как пробег на полном заряде зависит от скорости?" Лидия не знала точно. "Чем с большей скоростью вы будете ехать, тем меньше дистанцию в общей сложности вы проедете, там будет почти линейная зависимость".
"Точнее, конечно, если строить кривую с нуля, то будет бета-распределение".
"Другими словами, вам всегда надо выбирать хотите вы ехать дальше или быстрее. Причем это идеальная кривая, для свежего аккумулятора, у реального автомобиля с пробегом кривая будет проходить ниже этой идеальной кривой". "Ты хочешь сказать, что такие кривые есть для любой ситуации?" "Не то, чтобы ситуации, а скорее для любого решения любой проблемы. Мы должны понимать, что любое организационное или техническое решение является компромиссом между различными параметрами. Если мы улучшаем один параметр, мы с очень высокой вероятностью ухудшаем другой. Вопрос в том, насколько далеко мы готовы пойти в оптимизации этого параметра в связанным с этой оптимизацией ухудшением остальных характеристик". "Как это связано с моим разговором с Донаги?" "Вам надо понять, в каком пространстве выборов мы реально работаем - как технических выборов, так и организационных, проектных выборов. Как изменение одних параметров влияет на изменение других. Надо понять, в каком диапазоне должно работать решение. Надо понимать, что для одного узкого диапазона оптимизировать проще, чем для широкого диапазона. Надо понимать, что такую кривую пространства решений можно построить для лучших в своем классе решений, например, до скорости 40 взять характеристики Nissan Leaf, а на скорости 40-60 взять характеристики Toyota Prius, и тогда эта кривая покажет предельное пространство выборов, за которое вообще никто еще не перешел, и все требования за пределами этого пространства выборов нереалистичны, как нереалистичны текущие характеристики, под которыми мы сейчас подписались в проекте. И выход за пределы этой кривой, составленной из лучших в своем классе решений невозможен ни за какие деньги, и уж тем более не в условиях нехватки ресурсов и времени". "Слушай, давай я на свой язык переведу. Ты хочешь сказать, что каждый раз, когда Донаги требует что-то улучшить, я могу обосновано торговаться с ним, занижая требования в другом месте? И у вас есть такие кривые, таблицы для нашего проекта?" Викрам кивнул. "Так что же вы раньше молчали?"
Глава 4. В которой Лидия разбирается, что такое метод, онтология и пространство выборов, а также в том, как моделирование позволяет достичь успеха проекта.
Лидия зашла в кабинет системных инженеров, в первый раз за все время. На стене висел плакат с какой-то теткой и ее цитатой: “До Второй мировой войны жизнь была проще. После неё у нас появились системы”, подписано "Грейс Хоппер". Викрам сидел в наушниках за своими четырьмя мониторами, с бешенной скоростью набирал что-то на двух клавиатурах, и работал с трекболом. Остальные смотрели на быстро меняющуюся модель их устройства на своих экранах и о чем-то переговаривались между собой. Викрам доделал свои дела, снял наушники и улыбнулся ей. "Привет, Лидия. Ну как, продолжим обсуждение?" "Не знаю, меня что-то не особо зацепила пока идея. Не понимаю, как это поможет. И вообще не понимаю, что такое объект". "Ну вот посмотрите. - Викрам встал и прошел к флип-чарту. - Почему летом на улице теплее, а зимой холоднее? Какая причина?" "Орбита Земли эллиптическая и зимой просто мы улетаем дальше от Солнца, поэтому тепла меньше и наступают холода". "Но как тогда вы объясните два факта - на экваторе, где-нибудь в Сингапуре, температура круглый год 30 градусов, а летом открытые плечи загорают сильнее, чем шея?" Лидия задумалась, эти неоспоримые факты и в самом деле рушили стройную схему ее рассуждений. Но она ничего за пять секунд не придумала и пожала плечами: "Спорить не буду, раскрой секрет". "Никакого секрета нет, все, что я сделал - это фальсифицировал вашу теорию, показал факты, которые она не может объяснить. Если немного разобрать, как вы рассуждали, то скорее всего получится что-то такое. Зимой до Земли долетает меньше тепла от Солнца. Из опыта я знаю, что чем дальше источник тепла, та же батарея или печка, тем меньше она греет. Я знаю, что орбита Земли эллиптическая, значит, в какой-то момент Земля просто улетает от Солнца так далеко, что до нее долетает намного меньше солнечных лучей и тепла, и настает холодное время года. Это абсолютно логичное рассуждение, которое построено на объекте дистанция до источника тепла. И эта модель порождает верное предсказание - чем дальше до источника тепла, тем будет холоднее. Но если посмотреть на орбиту Земли, то мы увидим почти чистый круг, эксцентриситет орбиты Земли составляет сотые доли. Модель хорошая, но она не объясняет факты.
"Хорошо, есть команда, у команды есть метод, метод предсказывает будущее. Команда использует при общении один и тот же набор понятий и оперирует одинаковой логикой, поэтому они одинаково понимают кто кому что пообещал в ходе общения. Это все ясно. Но как это позволяет убеждать других в том, что проект успешен, я этого не понимаю," - Лидия откинулась на спинку кресла и внимательно посмотрела на Викрама. "Важна ли логика для системных инженеров? Нет. Потому что системные инженеры работают в ситуациях неопределенности, постоянных изменений и парадоксальных требований. Они постоянно должны решать противоречия. Большинство людей работают в своих функциональных зонах ответственности, они по определению крайне логичны, потому что нельзя сводить баланс или возить грузы, если ты не можешь очень четко логически мыслить. И никакие системные инженеры в такой ситуации не нужны. Системные инженеры нужны в ситуациях, когда логика не работает, когда люди столкнулись с парадоксом, дилеммой, противоречием. В тот момент, когда они застряли. Так что от системного инженера не требуется быть рациональным и логичным. Системный инженер должен быть вразумительным, здравомыслящим. Если бы логика всегда работала, никому и ни при каких условиях не потребовался бы системный подход. Не то, чтобы все идеи, которые я сейчас излагаю, выстраиваются в безупречно логическую цепочку рассуждений. Даже более того, тут полно логических пропусков и скачков. Но этот подход все равно лучше, чем то, что у нас есть сейчас. Мы застряли, Лидия, застряли. Мы идем в никуда, с нашим текущим замечательным, логическим, обоснованным подходом. Поэтому сделать этот шаг разумно, даже если он не полностью обоснован и не до конца логичен". "Ты думаешь, что меня можно сбить с мысли каким-то ответвлением от темы? Пока ты мне не расскажешь до конца всю цепочку рассуждений, пока я не пойму, какие риски несет этот переход, я ничего не смогу сделать. Пока ты не продашь эту идею мне, внимательному и заинтересованному слушателю, а я не продам ее Донаги, ничего не случится". "Чего хочет Донаги? Я почему-то уверен, что он часто говорит, что ему нужно решение минимальной стоимости, выполненное в кратчайшие сроки, выполненное наилучшим образом". "По большому счету да, это выжимка из разговор с ним". "Когда я получаю такой запрос, я всегда уточняю - а чем вы готовы пожертвовать? Ваша беда, Лидия, что вы в ответ на такой запрос всегда отвечаете "Хорошо, сэр, я немедленно это сделаю". Лидия промолчала, но мгновенно посуровела. Викрам безмятежно ждал пока она не почувствует свою злость и не начнет делать "квадратное" дыхание. Когда через безумно долгие 40 секунд он все-таки услышал от нее: "Продолжай", он сам выдохнул с облегчением и начал рисовать.
"Вы ездите на Tesla S. Как вы думаете, как пробег на полном заряде зависит от скорости?" Лидия не знала точно. "Чем с большей скоростью вы будете ехать, тем меньше дистанцию в общей сложности вы проедете, там будет почти линейная зависимость".
Комментариев нет:
Отправить комментарий