В сообществах проектных менеджеров есть миф о существовании критического мышления как метанавыка. Типа если ты можешь критически мыслить, то можешь это делать в любой области от воспитания своих детей до принятия принципиальных решений по устройству программно-аппаратного комплекса. Это хрень полная, осознанно, адекватно и разумно мыслить можно в каких-то узких областях, где у тебя есть достаточно экспертизы. Отсюда есть важный вывод:
Ситуация, в которой какой-нибудь авторитет с важным видом изрекает: "One size does not fit all", подразумевая, что надо адаптировать метод управления проектом к конкретной управленческой ситуации, и все вокруг важно кивают что типа да, мы все так делаем, вызывает у меня скепсис. Для того, чтобы приспособить метод планирования, надо понимать то, как мы концептуализируем нашу совместную работу и организацию труда. Умеет это кто-то делать? Нет, почти никто, все такие дискуссии обычно скатываются в то, какие шаблончики взять и какое ПО у какого вендора купить. Решение принципиальных вопросов планирования подменяется вторичным вопросом выбора инструментов.
Я ищу решение этой проблемы.
Как создать модель рабочей практики в формате научной статьи?
Я вел своих детей в детский сад и школу, и младшая спросила меня — а почему когда мы идем, то фонари двигаются на нас, а Луна улетает от нас, двигается туда же, куда и мы? Я немного подумал, и понял, почему так кажется. Дело в том, что люди воспринимают скорость как изменение угла и размера, а тут ни угол ни размер не меняется, и значит, далекие объекты кажутся нам неподвижными, или, если мы идем или едем, "двигаются" вместе с нами. В тот момент я понял, что машинально сделал то же самое, что делаю по работе — я смоделировал рабочую практику, в данном случае практику измерения расстояний. Я взял набор базовых фактов, про то, что фонари двигаются на нас и увеличиваются, а Луна двигается с нами и не меняет размер. Я взял концептуальную схему из трех понятий — угловая скорость, угловой размер, скорость наблюдателя, которая объясняет базовые факты и может достоверно их предсказать (когда мы пошли задом, Луна стала на нас надвигаться, а фонари поползли назад и уменьшились).
Шаги создания метамодели практики:
Проблема 1. "3 километра терминов и определений". Решение — структурирование области обсуждения (domain partitioning and contexts definition). В хранилище проекта должна появиться папка "Область обсуждения".
Проблема 2. "А что такое вещь?". Работы как вещи, процессы и проекты как типы работ. Решение — определение состояний вещей, выделение стадии использования. Необходимо пересмотреть описания процессов и планы проектов.
Проблема 3. "Как объединить каталоги?". Решение — PBS, WBS, SBS и другие разбиения. Универсальных решений нет, но подход единый.
Проблема 4. Измерение неизмеримого. "Что измеряет панель Google Analytics?".
Решение — концептуализация предметной области как заказчика так и разработчика плюс операционализация концептов.
Создание и применение (мета)модели практики для выявления и прохождения развилок проекта (project and design trade-offs). Научные статьи как метод рефлексии над ходом проекта и принятыми решениями.
-
Александр Чудов Но даже такие дискуссии все-таки лучше полного отсутствия обсуждений метода- · 18 ч.
-
Александр ТурхановАлександр Чудов других и не бывает, так что да. Концептуально очень мало кто готов обсуждать и потом ещё следовать.
