Новые модели продуктового проектирования: матричный метод

1. Предпосылки статьи, или Дурная бесконечность

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

Чтобы понять, о чём пойдёт речь дальше, приведу определение важного термина.

Из определения видно, что положительный результат возникает не от нового информационного объекта (регламента, программы или технологии) самого по себе, но только в результате взаимодействия нового объекта с существующим хозяйственным механизмом. Образно говоря, новый «движок» должен не только иметь выдающиеся ТТХ, но ещё и влезать в капот вашей машины – иначе вы никуда не поедете.

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

Блок 1: Показатели разработки ИС (АСУ)

• отсутствует текущая система натуральных показателей деятельности ХМ компании (что измеряем, что имеем);
• отсутствуют формулы пересчёта натуральных показателей в денежные (доход) по каждому показателю/группе схожих показателей (как считаем);
• отсутствуют значения планового прироста показателей с обоснованием достижимости этого прироста по каждому показателю в результате внедрения цифрового вундерваффе (где количественный эффект? за счёт чего?);
• декларируемый рост доходности не имеет расчёта (по тем же формулам!) на основании прироста натуральных показателей (цифры «от балды»).

Блок 2: Подмена объективного подхода субъективными ожиданиями

Сначала пишутся стратегические цели компании, перечисляются указы Президента РФ по цифровизации, постановления Правительства в развитие указов, идут массовые ссылки на корпоративные документы и прочая. Потом, когда доходит до детализации в структурных подразделениях, все эти общие документы подменяются «хотелками» с мест (длиииииинным нумерованным списком!) без обоснования достижимости стратегических целей при реализации этих «хотелок». Почему выбраны эти предложения, а не другие, какая между ними связь – непонятно. «Это сейчас модно – и всё» ©. Очевидно, что при таком подходе успех случаен, а вот растрата инвестиций на ложные цели – неминуема.

Что мы видим в итоге? Существующий хозяйственный механизм игнорируется напрочь. Его анализ заменяется подтасовками. Это очень серьёзная, давняя и плохо понимаемая проблема.

Объективный критерий успеха продукта (автомобиля или рыночного САПР) очень прост – это объём продаж. Хорошо продаётся – разработчикам всё простят, плохо продаётся – «кому здесь нужно ваше жалкое блеяние?» ©

А вот для оценки успеха средств производства (например программы АСУ для нужд компании) должна быть разработана система показателей, понятная капиталисту:

Показатели → Цифровая трансформация → Показатели+ (как аналог Д → Т → Д+).

Но поскольку никто не будет вводить новые показатели для какой-то одной программы² (оценивать их значимость, взаимосвязь, собирать статистику применения и прочая), то базироваться надо на существующих экономических показателях ХМ компании.

² Формирование системы показателей хозяйственной деятельности компании является отдельной большой темой. По сути, руководство осуществляет управление компанией, сверяясь с текущими значениями системы показателей и сравнивая их с нормативными.
Так врач судит о наличии воспалительного процесса в организме, сверяясь с показателем температуры тела больного. Поэтому показатели, которые ни о чём ему не говорят, врачу не нужны. С другой стороны, наихудший случай, когда все показатели в норме, а пациент умирает. Управление предприятием (или правильнее всё-таки говорить – хозяйственным механизмом) имеет очень много схожего с медициной. О некоторых проблемах выбора показателей можно прочесть здесь: Новогодний винегрет.

Важным моментом здесь является то, что с системой показателей ХМ компании связаны KPI руководства. Улучшение показателей, от которых зависит их премия, всеми понимается очень хорошо.

Соответственно, если меняется система показателей – должны пересматриваться и требования к системам управления… Это что касается ошибок 1-го блока.

По 2-му блоку суть проблемы точно определена Дэвидом Марка (см. цитату в начале статьи). Сегодняшняя система ГОСТ 34 на разработку ИС, на мой взгляд, морально устарела³. Во-первых, она очевидно рассчитана на полный цикл разработки софта, но в случае популярных сегодня интеграционных проектов, по моему мнению, нужна другая схема. Во-вторых, отсутствуют эффективные методики разработки ключевых документов на ранних стадиях, в первую очередь – функциональных требований (ФТ) со стороны заказчика.

³ Злые языки даже поговаривают, что основные положения были скопированы с американского ИТ-стандарта 70-х годов.

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

Разумным действием для руководства компании в решении задачи «как не растранжирить деньги на ИТ» является проведение внутрикорпоративного конкурса на функциональные требования к ИТ-проекту, когда групп разработки ФТ как минимум две⁴. Тогда по итогам можно премировать победителя и сформировать сводные ФТ, которые наверняка будут лучше тех, что по отдельности.

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

Но данный организационный приём не снимает проблему снижения субъективности и повышения внутренней связности предложенных требований. «Как научить людей сразу думать правильно?» © Для решения этих задач предлагается использовать «матричный метод», описанный ниже.

2. Описание метода

2.1. «Полезная» цель

На данном этапе достаточно кратко ответить на два вопроса:

Вопрос 1. Что является целью: предмет потребления или средство производства?

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

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

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

Вопрос 2. Является ли разрабатываемый объект продуктом?

Здесь имеется в виду: собираетесь ли вы в дальнейшем разрабатываемый объект продавать на рынке? Это сразу определяет: периметр проекта/возможных стейкхолдеров, необходимость в маркетологических исследованиях (даже если это средство производства), внутреннюю архитектуру объекта и т. п.

P.S. Сейчас пошла мода при выбивании бюджета на разработку корпоративной ИС заявлять, что «вот мы сейчас сделаем для себя, а на втором этапе будем продавать её на рынке и окупим все затраты, так дайте ж денег нам скорее!» Если руководство не хочет верить честным задорным лицам, то полезно поинтересоваться: какие меры по обеспечению успеха будущего ИТ-продукта будут заложены уже на первом этапе, насколько профессионально проведен анализ возможных рынков сбыта и условий продаж? В противном случае велик риск, что для рынка корпоративную программу придётся переписать почти полностью.

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

2.2. Определение ключевых факторов влияния

Хозяйственный механизм (ХМ) может быть представлен в виде группы независимых переменных, которые оказывают постоянное существенное влияние на это взаимодействие. Эта группа переменных называется Ключевые факторы влияния (КВФ). Другими словами, КВФ отражают важные особенности среды, в которой предстоит «работать» новому объекту.

Наилучший учёт КВФ означает максимальную приспособленность объекта к работе в этих условиях. Таким образом, с КВФ не борются, к ним адаптируются⁵. Задача анализа КВФ – повысить адаптивность разрабатываемого объекта к существующему ХМ⁶.

⁵ Пример: На улице -15°С мороза. Вы же не боретесь с морозом, вы к нему адаптируетесь – надеваете шубу. Шуба – это наилучший способ адаптации из возможных, кто в шубе – тот лучше себя чувствует.
Следовательно, чем выше адаптивность фирмы к КВФ, тем лучше она себя чувствует на рынке (секрет конкурентоспособности).

⁶ Это принципиально отличается от «западного» подхода, где в качестве ключевых факторов предлагается выбирать свои «хотелки» – ключевые факторы успеха (КФУ), для реализации которых может просто не оказаться возможных решений.

Принцип адаптации не отрицает инноваций в ХМ, поскольку инновация может дать наибольшую адаптивность субъективно построенного производственного процесса к объективно сложившимся условиям внешней среды⁷ (а может и не дать, тогда эта инновация – бесполезна).

⁷ См. определение хозяйственного механизма выше.

2.3. Формулировка новой парадигмы

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

На этапах выбора КВФ и формулировки парадигмы важную роль в команде играют участники, обладающие талантом исследователя. На эту тему более развёрнуто здесь: Наблюдение за наблюдающим: о методе isicad-а.

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

2.4. Ключевые идеи и «матричная» модель объекта

Рис. 1. Старт «матричной» модели

Однако КИ должны пройти проверки на адекватность, целостность и непротиворечивость. Для этого строится матрица КИ – см. рис. 1.

Совокупность К_ii (элементов на главной диагонали) – это сами идеи, это их описание с указанием на то, с какими факторами влияния они связаны/на какие факторы влияния они воздействуют.

Совокупность К_ij (элементов не на главной диагонали) – это описание влияния одних идей на другие, причём влияние КИ1 → КИ2 (элемент К₁₂) и влияние КИ2 → КИ1 (элемент К₂₁) – это разные влияния и они должны быть описаны отдельно.

Проверки:

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

Примечание 1: чем на большее число факторов влияет КИ, тем лучше – значит выбрана более «весомая» идея. Таким образом, в рамках проектной команды возможен «конкурс идей», которые оцениваются на право быть включёнными в список КИ. Правильность подбора КИ зависит от профессионализма команды.

Примечание 2: следует внимательно относиться к недиагональным «нулевым» элементам матрицы («нет связи»). Возможно, связь всё-таки есть, но не была выявлена.

2.5. Построение матричной иерархии

При этом анализ недиагональных элементов матрицы играет важную роль:

• связи между элементами КИ формируются только на своём уровне, «гибельной» для больших проектов путаницы межуровневых связей не возникает;
• выявление взаимовлияний КИ из матрицы i-го уровня нередко приводит к лучшему пониманию задач и более быстрому нахождению КИ уровня i+1.

Проверки КИ на адекватность, целостность, непротиворечивость и инвариантность должны выполняться всегда, для каждой матрицы каждого уровня⁸.

⁸ Требование к инвариантности ключевых идей матрицы и проверки взаимовлияния КИ друг на друга (недиагональные элементы матрицы) не противоречат друг другу: когда изначально независимые идеи объединяются в систему (матрицу), то они начинают друг на друга влиять. Пример: в собранном автомобиле вибрация двигателя передаётся на его кузов.

2.6. «Разделяемые» элементы

Для назначения ответственности за исполнение матричных КИ назначается «хозяин матрицы», его синонимом является «руководитель проекта» в большом проекте (программе проектов), где таких РП может быть много. Хозяин матрицы несёт ответственность за своевременное выполнение своего «разделяемого КИ» и обеспечение его результатами смежников.

Матричная парадигма считается исполненной, если все матричные КИ выполнены. Контроль исполнения КИ со стороны директора проекта (по всему разрабатываемому объекту) ведётся по чек-листам.

2.7. О статической и динамической проверках матричной модели

А «динамика» построенной модели объекта, своего рода конструктивные испытания, проверяется через построение «процессной модели» объекта разработки, когда каждой операции процесса должна соответствовать некая функция (КИ) в матрице.

Если такой КИ не находится, то это повод для пересмотра отдельных подструктур матрицы: правильно ли был определён состав КИ?

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

2.8. Ещё раз о показателях

В завершение необходимо сказать о связи системы показателей ХМ и «матричной» модели. В перечень КВФ должен явно попасть хотя бы один фактор, стоящий за каким-либо вычисляемым показателем системы показателей ХМ компании. Иначе вы получите «сферического коня в вакууме» – информационная система сама по себе, действующий ХМ – сам по себе. Но означает ли это обязательный провал ИС? Нет, «только ситхи всё возводят в абсолют» ©. При проектировании иерархии «матриц» возможно появление КИ, которые окажут существенное влияние на контролируемые системой показателей факторы ХМ. Но, как вы понимаете, если фактор не указан явно, то появление «удачного» КИ – воля случая.

3. Заключительное слово

Анализ самого метода позволяет дать ответ на многие интересные вопросы, например: почему одни проекты получаются, а другие нет? Почему мы видим на рынке такие разные предложения продуктов? Потому что команды разные, люди все уникальные, а значит в голову приходят разные КИ, даже если декомпозируются схожие парадигмы. Где-то эти КИ более адаптивны к реальности, где-то менее, отсюда и результат. Но метод настойчиво объясняет важность умения привлечь в команду профессионалов и работать «по схеме» и бесполезность надежды на успех дилетантов. Весёлые хипстеры, уверенно «нагибающие» транснациональные корпорации, рождаются только на съёмочных площадках Голливуда…

Публикация метода, надеюсь, также подводит черту под подзатянувшейся дискуссией на isicad о том, что можно жить по принципу «воровать чужие идеи и делать на этом успешную карьеру». Чтобы ворованная идея для вас стала эдаким «бустером», нужно украсть всю иерархию КИ с подробным описанием, при этом КВФ должны быть определены верно, а это значит, что ХМ должен совпадать как по структуре, так и по фазе, что всё вместе выглядит очень маловероятно... Ну украдёте вы резинку от трусов, а вам надо шапки шить. И что с этим будете делать?… 

...Метод новый, продолжает развиваться на конкретных проектах. Кому интересна тема, пишите с рабочего адреса вот сюда: 352217@rambler.ru. Представьтесь, назовите должность и организацию, я отвечу.

Всем добра