Победи_Аристотеля
202 members
25 photos
1 file
183 links
Полностековое системное мышление (4Д, прагматизм, агентское мышление, байесовское принятие решений) в применении к бизнес-проектам.
https://t.me/turkhale
Download Telegram
to view and join the conversation
Голубой океан вашей карьеры или ваша жизнь как антипроект
Почему единственное правильное время действовать - это прямо сейчас и как в этом помогает знание практик системной архитектуры и сценарного планирования?

У меня есть знакомые, которые летают на маленьких самолетах и планерах. В смысле летают пилотами. Многим кажется, что летать на самолете - это что-то очень сложное, но на деле для получения свидетельства пилота надо 30-40 часов налета и сдача теории в объеме как для водительского удостоверения. Так вот, оказывается, что летать на самолете скучно - заправил полный бак, вырулил на дорожку, взлетел, пролетел по плану полета, снизился, сел. Все предсказуемо, единственная вещь, которая определяет твой полет - это количество топлива. Конечно, если ты не залетишь в облачность или в опасные метеоявления. То ли дело планер, говорят они. Так это же тот же самолет, но без двигателя, отвечаю им я. Да, и это все меняет, все ощущения, механику полета, контроль ситуации. Планер обычно буксируют на высоту самолетом и он планирует с высоты вниз. У него есть ключевая характеристика, которая называется качеством планера. Она показывает, на сколько метров вперед пролетит планер, на каждый метр потерянной высоты. Потерял 1 метр, пролетел 10, значит коэффициент качества десятка. Потерял один метр, пролетел 30, значит коэффициент 30. В результате если самолет поднял тебя на высоту 1 км, то ты пролетишь 30 км? Нет, опытные планеристы летят куда дальше, потому что по пути они ловят восходящие потоки, и кружат в них как орлы, набирая высоту, с которой они потом могут планировать дальше. И ловят от этого кайф, потому что их полет зависит не т уровня топлива, а от того, насколько хорош твой планер и насколько точно ты чуешь, где может быть восходящий поток.

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

Жизнь-как-проект работает по другому. Вы сидите на аэродроме и заправляетесь, пополняете свой карьерный капитал. Чтобы перелететь на другой корпоративный аэродром, вам надо много топлива, ваш карьерный капитал тратится при смене корпорации, при смене позиции, при любом движении. Вы можете долго сидеть на рулежной дорожке и потом вам отменять вылет. И вы сидите и тщательно обдумываете, на каких самолетах летать, через какие аэропорты, заходить ли в грозу или облететь ее вокруг. Вы зависите от диспетчеров и руководства аэропорта целиком и полностью. А они не любят опозданий, перерасходов топлива, простоев на земле, я уж не говорю про то, что качество планера большого самолета чуть лучше чем у камня, ни о какой свободе искать интересные темы обычно и речи быть не может.
http://sdu2020.blogspot.com/2020/05/blog-post.html
Архитектура доверия - альтернатива практикам риск-менеджмента

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

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

30 минутный доклад + ответы на вопросы.
https://youtu.be/gfQElb-gdy8
— с Yehor Churilov и Романом Химичем.
Курс для системных аналитиков и инженеров по требованиям

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

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

Мы представляем новый курс «Системная архитектура и сценарное планирование».

Вы научитесь создавать рабочие продукты в нужной для них форме - от пояснительной записки к техническому проекту по ЕСКД и ГОСТ 34 до сайта в Confluence. И не просто создавать, но и использовать системную архитектуру и дорожные карты в реальных обсуждениях.

Даты проведения: 18 июня - 27 августа
Стоимость: 12 500₽
Формат: онлайн

Запись на курс, а также все подробности по ссылке: https://it-park-events.timepad.ru/event/1324733/
Стадийность-этапность и контрольные точки-инкременты-спринты

Бизнес состоит из двух частей:
- надо сделать работу
- и получить за нее деньги

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

Если финансирование целевое, то эти два цикла синхронизированы и их можно рассматривать как один. Минобороны выделило грант, КБ и завод набрали людей, сделали работу. Перевели денег на разработку технического задания - КБ сделало ТЗ; перевели денег на разработку технического проекта - сделали ТП; перевели денег на разработку РКД - сделали РКД. С точки зрения команды, которая делает работу, этапность отражает то, какие компетенции нужны. Для разработки ТЗ нужны аналитики, для разработки ТП нужны проектировщики, для РКД нужны конструктора и программисты. Если технический проект доделывается до последнего, то проектировщики нужны до последнего, если РКД корректируется пока не наступит срок сдачи по договору, то конструктора нужны до последнего, а то и после сдачи проекта надо будет правки вносить.

Этапность - это про то, как работы выглядят изнутри.

Заказчику или потребителю все равно как у вас там организованы работы. Главное - это результат. Поэтому в коммерческой разработке, где циклы получения денег не синхронизированы с циклом организации работ, используют другое деление. Там есть инкременты и спринты.
Этапы могут перекрываться, да более того, чаще всего на деле и перекрываются, некий водопадный подход в вакууме существует только в головах бизнес-тренеров, никогда не управлявших ни одним проектом. Я писал про эту грустную историю перевранного водопада тут
https://www.facebook.com/alex.turkhanov/posts/10216077269781592

Инкременты и спринты (и, как вариация, управление по контрольным точкам) про другое. Это единицы поставки ценности заказчику. Дал заказчик денег на проект - вот  ему результат, который он считает ценным. Не команда, а тот, кто дал денег. При этом в проекте разработки сама этапность все еще есть, куда она денется.

"Водопад" против Эджайла - ложное разделение. Этапность описывает как оно устроено внутри, с точки зрения необходимых компетенций и работ. Инкременты описывают как оно устроено снаружи, с точки зрения подотчетности расходования денег и других ресурсов.
Поклонники Эджайл напоминают логистов, которые ратуют за курьерскую доставку по любому поводу - мол быстро, гибко, захотел - уволил, захотел - набрал новых. Но вот если надо организовать доставку 1,5 млн. тонн стройматериалов, то курьеры не катят.
Поклонники водопада напоминают логистов, которые говорят, что мол по центам за тонну контейнерные перевозки ваще топчик. На крайняк ж/д или там автопоездом. Но вот если надо доставить маленький пакетик до дверей, то уже никак.

Практики же занимаются мультимодальной логистикой.

Это и есть управление программами проектов - где надо будет "водопад", где надо "Эджайл", здесь кейс-менеджмент, там - процессное управление. Все приспособлено под ситуацию, под навыки конкретных людей в конкретном месте, под конкретные потребности конкретных заказчиков.
Отличная диссертация с обзором современных практик того, как планировать, описывать и управлять составом многовариантных модульных продуктов. https://www.research-collection.ethz.ch/bitstream/handle/20.500.11850/149674/eth-29279-02.pdf
Дырка от бублика как системный интерфейс (PRINCE 4.0*)

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

Чтобы поставить задачу системе, надо выдать ей корректное задание в правильном месте - на интерфейсе, API или в экранной форме, с использованием протоколов обмена информацией, плюс она еще и уровень доступа у вас проверит, а можете ли вы вообще ей задачи ставить. Выполнение задачи забирает ограниченные ресурсы системы, нельзя навалить сто задач и требовать, чтобы все это было сделано сию же минуту. Если системе не выдать абсолютно понятного ей задания, или у нее ресурсов не хватает, она просто ничего не сделает и ей даже стыдно не будет. Человеку же дать задание намного проще - достаточно остановить в коридоре на 15 секунд и что-то быстро надиктовать, зачастую даже проверки прав на доступ не происходит, на чем живут многочисленные продавцы по телефону и мошенники. А дальше человек сам справляется с потоком непонятно каких задач непонятно от кого, как Анна. До какого-то момента справляется, пока ресурсы не кончатся. У кого-то их много, и он тянет долго, у кого-то их меньше, и они выгорают раньше. Если только не перепоручать выполнение другим. Но тут есть ряд проблем.

Проблема Анны в том, что она не может дальше перепоручить ничего из своих дел, потому что все задачи слишком слабо формализованы и только она знает, что, как и когда делать. На передачу дела уйдет уйма времени, больше, чем на то, чтобы сделать самой.

Но необязательно так страдать от чрезмерной нагрузки, достаточно правильно построить орг.дизайн в своих проектах. И один из ключевых шагов в построении правильного орг.дизайна заключается в том, что надо перенести понятие системного интерфейса на взаимодействие людей. Достаточно начать правильно рассуждать о бизнес-процессах, организационных ролях, организационных единицах и организационных интерфейсах. И тогда не будет ситуации, которую описал Виктор Вахштайн, исследователь, который формирует результаты Евробарометра в России. На вопрос «Как вы считаете, люди действительно такие откровенные сволочи, какими кажутся?», подавляющее большинство россиян отвечает «И еще хуже!».

Аннотация

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

Статья описывает часть фреймворка PRINCE 4.0 - Projects in Chaos Environment.

Ключевые слова: ограничения системной инженерии, трансдоменные объекты, организационные интерфейсы, архитектура предприятия
http://sdu2020.blogspot.com/2020/06/prince-40.html
Системное проектирование и анализ альтернатив за три минуты

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

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

Полный текст в блоге
http://sdu2020.blogspot.com/2020/06/blog-post.html

Dislike, unshare, unsubscribe.
Презентация доклада "Интерфейс как дырка от бублика"

Видео доклада

3:00:00 Системная инженерия, ее эффективность и ошибки понимания
3:02:00 Космический телескоп "Хаббл" и междисциплинарная коммуникация в системной инженерии
3:04:20 Проблема, которую раскрывает доклад
3:05:15 Трансдоменные объекты, boundary objects в ИТ, их роль в междисциплинарной коммуникации
3:08:45 Классический системный подход и его ограничения
3:15:20 Как работает системный подход - задача с сепулькаторной колонной
3:19:10 Концепт интерфейса и разные типы интерфейсов
3:23:20 Проблемы понимания концепта интерфейса
3:26:30 Имплементация организационных интерфейсов
3:29:15 Проблема бюрократии при масштабировании
3:31:10 Демонстрация разных имплементаций орг.интерфейсов и проблема имплементаций
3:35:10 Синхронные орг.интерфейсы как трансдоменные объекты и их проектирование
3:38:00 Ответственность ролей на орг.интерфейсах
3:43:10 Инфраструктура, ее свойства и различение между инфраструктурой и ТДО
3:44:40 Интуиции, которые помогают понять концепцию интерфейса
3:50:45 Примеры фреймворков, которые помогают создавать ТДО
Откуда берутся цели проектов?

Почти всю свою карьеру в управлении проектами я интересовался вопросом откуда берутся цели проектов? Почему заказчик или топ-менеджер выбрал именно эту цель? Почему важен именно такой результат и насколько в реальности можно от него отклониться так, чтобы не вызвать недовольства?
Дело в том, что заказчики проекта - это обычно люди из операционной деятельности, связанной с зарабатыванием денег. Там все очень конкретно - если не достиг заданного уровня строго определенного финансового показателя, то бизнес просто схлопнется. Ставки высоки, требования ставятся на пределе, люди ведут себя крайне жестко и последовательно. Мир проектов куда более зыбкий. Ты никогда не можешь достичь планового результата в точности. Всегда есть люфт. Вопрос, уволят тебя за него или нет - очень важный.
И из многолетней практики мне ясно, что никто из заказчиков и не ждет точного достижения поставленных целей. Все ожидают отклонений. И если ты знаешь, как превратить точку цели - бюджет, KPI, доходность и возврат инвестиций в то, что я называю “тессерактом целей”, то управление проектами становится намного проще. Вам надо прийти не в точку в одном мире, а в область в любом из миров.
И достигается это за счет 4 шагов системного подхода - функции, контекста, имплементации и культуры. Разберемся с ними.
КЕЙС
Однажды я сидел на важном совещании. Топ-менеджеры известной розничной торговой сети обсуждали, что делать с бизнес-процессом исполнения заказов магазинов. Текущий процесс не устраивал их по многим параметрам. На смену предлагались два варианта. Первый был описан коротким, очень простым регламентом, его предлагали сами магазины. Второй был куда более сложным, его предлагали логисты и закупщики.
СУТЬ ПРОБЛЕМЫ
Выбор был непростой, потому что сложный регламент позволял исполнять заказы куда быстрее. Но в то же время, с текучкой персонала в 150% в год, время на его освоение работниками, которые уйдут через 8 месяцев, выглядело непозволительной роскошью.

Продолжение смотри в видео длиной 6:20
https://youtu.be/IhNHIZr2K-A
Вебинар про то как руководителю проектов освоить профессию руководителя программ.
Кратко и популярно изложу результаты последних исследований в этой области, проблематику и продемонстрирую технологии "war rooms" для офисов управления программами.

20 августа, четверг, 13:00.
https://turhanov.ru/
Победи_Аристотеля
Вебинар про то как руководителю проектов освоить профессию руководителя программ. Кратко и популярно изложу результаты последних исследований в этой области, проблематику и продемонстрирую технологии "war rooms" для офисов управления программами. 20 августа…
4 шага системного подхода в управлении проектами. Шаг 2 - Контекст.

Какой главный признак хорошего технического задания?

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

- У тебя на проводах под напряжением стоит вилка. Если клемма раскроется, то провод упадет прямо на стальную палубу и закоротит его.
- В смысле? - я стремительно перебирал в голове варианты где и что я не учел.
- Поменяй розетку и вилку местами на кабеле, который соединяет блок питания и компас.
- Но в техническом задании сказано сделать именно так! - ответил ему я.
- Ну и что, головой думать надо, а не только ТЗ читать. И ошибки в ТЗ надо исправлять. - здраво ответил мне ведущий конструктор.

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

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

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

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

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

Но видеть систему и контекст в своих проектах я научился далеко не сразу.

Продолжение и ссылка на ролик в блоге
http://sdu2020.blogspot.com/2020/08/4-2.html
Почему SMART-целеполагание в проектах само по себе не работает и как это исправить?

Топ-менеджмент и собственники обычно ставят очень четкие и понятные цели по стратегическим проектам и оговаривают вполне достижимые критерии их успеха. На основании этих целей определяются задачи и формируется стратегия проекта, которую необходимо реализовать.
Обычно после согласования стратегии сразу начинают разрабатывать план проекта. И я тоже так раньше делал. Но если проект достаточно большой и сложный, то сформировать с ходу корректный и работоспособный план только на основе целей и стратегии проекта — нельзя. В любом случае придётся его корректировать в процессе, с учетом поступающих вводных.

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

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

Продолжение и ссылка на видео в блоге
http://sdu2020.blogspot.com/2020/08/smart.html
Как настроить YouTube для трансляции выступления: инструкция и чек-лист для олдстеров

Чтобы создать трансляцию, надо выполнить следующие шаги:
- Настроить сигналы с аппаратуры передатчика (кадр и звук)
- Получить Ключ трансляции от Приемника
- Настроить Передатчик на Ключ трансляции Приемника
- Проверить прохождение сигнала в тракте передачи
- При необходимости включить Рекордер
- Запустить трансляцию

Ключ трансляции создается каждый раз заново для новых трансляций.

Dislike, unshare, unsubscribe.
Весь мой 16-летний опыт проектной работы подсказывает, что на курсах и в книгах по большей части учат не тому, как реально запускаются проекты в жизни. В жизни важно понимать как работает офисная политика, как вести конструктивный диалог с коллегами, руководителями и поставщиками даже если вы друг-другу не нравитесь, как оформлять договора так, чтобы не нарушить бюджет и не попасть под раздачу контролеров, как использовать юридический способ мышления при написании отчетов, как структурировать задачи, когда у тебя 200 человек и 15 организаций в проекте. И только если удалось запустить работу, можно думать о планировании, организации регулярного исполнения и контроля, закрытии этапов и накоплении знаний и опыта. Другими словами, в проектной работе важно уметь неплохо играть в политику и работать с реальными людьми в кризисных и стрессовых условиях. А инструменты и практики управления важны только в той мере, в которой они работают на эти задачи.
http://sdu2020.blogspot.com/2020/09/blog-post.html
Книжный марафон. Сезон 1.

S01E01 Agendas, alternatives and public policies
S01E02 Снайдер Б. Спасите котика!: И другие секреты сценарного мастерства. – " Манн, Иванов и Фербер", 2014.
S01E03 Argyris C. Flawed advice and the management trap: How managers can know when they're getting good advice and when they're not. – Oxford University Press, 2000.
S01E04 Hubbard D. W. The failure of risk management: Why it's broken and how to fix it.
S01E05 Закон малинового варенья и еще 103 секрета консалтинга
S01E06 Alvesson M., Spicer A. The stupidity paradox: The power and pitfalls of functional stupidity at work. – Profile Books, 2016.
S01E07 Partridge C. Business Objects: Re-engineering for re-use. 1996.
S01E08 Kleinberg S. Why: A guide to finding and using causes. – " O'Reilly Media, Inc.", 2015.
S01E09 Newport C. Digital minimalism: Choosing a focused life in a noisy world. – Penguin, 2019.
S01E10 Ahrens S. How to Take Smart Notes: One Simple Technique to Boost Writing, Learning and Thinking–for Students, Academics and Nonfiction Book Writers. – Sönke Ahrens, 2017.

Подробнее см. в блоге
http://sdu2020.blogspot.com/2020/09/1.html
Про ценообразование услуг и консалтинга

Понятно, что фундаментальные знания здесь см. Марн М., Рёгнер Э., Завада К. Ценовое преимущество: Сколько должен стоить ваш товар?. – Альпина Паблишер, 2015.

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

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

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

Dislike, unshare, unsubscribe.
Нужно ли давать историю мысли либо сразу современный вариант дисциплины (SoTA)?

Для прикладников давать историю становления области знаний действительно смысла нет. Если ты будешь управлять требованиями в Jama, в которой реализован Workflow Use Case 2.0 для DO-278A, то зачем знать про ГОСТ34, как бы хорош он ни был для 1987 года?

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

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

Dislike, unshare, unsubscribe.
Вся эта затея с симулятором проверяет одну гипотезу: можно ли научить трансдициплинам с помощью метода кейсов (ситуационного анализа)?

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

- INSEAD является признанным лидером в написании бизнес-кейсов по международным рынкам. В 2008 году INSEAD победил в семи из девяти категорий ECCH European Case Award.
- Yin R. K. Case study research and applications: Design and methods. – Sage publications, 2017.
- Gerring J. Case study research: Principles and practices. – Cambridge university press, 2006.
- Merriam S. B. Case study research in education: A qualitative approach. – Jossey-Bass, 1988.
- Merriam S. B. Qualitative Research and Case Study Applications in Education. Revised and Expanded from" Case Study Research in Education." – Jossey-Bass Publishers, 350 Sansome St, San Francisco, CA 94104, 1998.
- https://www.thecasecentre.org/main/
- http://www.cambridge.org/us/catalogue/catalogue.asp?isbn=0521676568
- https://web.archive.org/web/20130128062534/http://www.gslis.utexas.edu/~ssoy/usesusers/l391d1b.htm
- https://web.archive.org/web/20140417105359/http://microsoft.changellenge.com/
- https://hbsp.harvard.edu/home/
- https://www.thecasecentre.org/main/
- https://ru.wikipedia.org/wiki/%D0%9C%D0%B5%D1%82%D0%BE%D0%B4_%D0%BA%D0%B5%D0%B9%D1%81%D0%BE%D0%B2
- Структурированные кейсы (highly structured cases)
- короткое и точное изложение ситуации с конкретными цифрами и данными. Для такого типа кейсов существует определённое количество правильных ответов. Они предназначены для оценки знания и/или умения использовать одну формулу, навык, методику в определённой области знаний.
- Неструктурированные кейсы (unstructured cases)
- материал с большим количеством данных и предназначены для оценки стиля и скорости мышления, умения отделить главное от второстепенного и навыков работы в определённой области. Для них существуют несколько правильных вариантов ответов и обычно не исключается возможность нахождения нестандартного решения.
- Первооткрывательские кейсы (ground breaking cases)
- могут быть как очень короткие, так и длинные. Наблюдение за решением такого кейса даёт возможность увидеть, способен ли человек мыслить нестандартно, сколько креативных идей он может выдать за отведённое время. Если проходит групповое решение, то может ли он подхватить чужую мысль, развить её и использовать на практике.
- Исследовательский вопрос
- Актуальные исследовательские проблемы
- Поле типовых задач
- Эталонные управленческие решения

Dislike, unshare, unsubscribe.
- The Antidote
- Цели-то они достигли, на Эверест поднялись, но цели всегда в системе, всегда взаимосвязаны с другими параметрами, ты достигаешь нескольких целей/антицелей. Поэтому, достигнув целей, они достигли и антицелей, и не смогли вернуться живыми.
- [Программа 29](http://archive.boston.com/bostonglobe/ideas/articles/2009/03/15/ready_aim____fail/) (желаемая доля рынка) у Дженерал Моторз как пример феерического провала целеполагания. Цели должны быть конкретными, они не должны быть абстрактными.
- https://www.businessinsider.com/gm-trying-to-increase-us-market-share-2017-5
- Грегори Бейтсон - деревни в Бали, которые нацелены на баланс множества целей.
- История с Ford Pinto - это и есть тот самый случай, о котором говорит герой "Бойцовского клуба" в самолете, см. Ordonez
- Ordóñez L. D. et al. Goals gone wild: The systematic side effects of overprescribing goal setting //Academy of Management Perspectives. – 2009. – Т. 23. – №. 1. – С. 6-16.
- https://d1wqtxts1xzle7.cloudfront.net/32514915/09-083.pdf
- Цели слишком конкретны
- Узкие цели
- Слишком много целей
- Неверно выбранный временной горизонт. Пример нью-йоркских таксистов
- Слишком сложные цели
- Цели, заставляющие чрезмерно рисковать
- Цели, вызывающие неэтичное поведение
- Недовольство и психологические эффекты от недостижения целей
- Цели, обучение и взаимодействие
- Цели замедляют обучение
- Цели создают культуру конкуренции
- Цели могут разрушить мотивацию
- Можем ли мы вообще поставить правильную цель? Проблема калибровки
- For decades, scholars have prescribed goal setting as an all-purpose remedy for employee motivation. Rather than dispensing goal setting as a benign, over-the-counter treatment for students of management, experts need to conceptualize goal setting as a prescription-strength medication that requires careful dosing, consideration of harmful side effects, and close supervision. Given the sway of goal setting on intellectual pursuits in management, we call for a more self-critical and less self-congratulatory approach to the study of goal setting.
- Barsky A. Understanding the ethical cost of organizational goal-setting: A review and theory development //Journal of Business Ethics. – 2008. – Т. 81. – №. 1. – С. 63-81.
- Camerer C. et al. Labor supply of New York City cabdrivers: One day at a time //The Quarterly Journal of Economics. – 1997. – Т. 112. – №. 2. – С. 407-441.
- Deci E. L., Koestner R., Ryan R. M. A meta-analytic review of experiments examining the effects of extrinsic rewards on intrinsic motivation //Psychological bulletin. – 1999. – Т. 125. – №. 6. – С. 627.
- Fleming P., Zyglidopoulos S. C. The escalation of deception in organizations //Journal of Business Ethics. – 2008. – Т. 81. – №. 4. – С. 837-850.
- Gilliland S. W., Landis R. S. Quality and quantity goals in a complex decision task: Strategies and outcomes //Journal of Applied Psychology. – 1992. – Т. 77. – №. 5. – С. 672.
- Jensen M. C. Paying people to lie: The truth about the budgeting process //European Financial Management. – 2003. – Т. 9. – №. 3. – С. 379-406.
- Knight D., Durham C. C., Locke E. A. The relationship of team goals, incentives, and efficacy to strategic risk, tactical implementation, and performance //Academy of Management Journal. – 2001. – Т. 44. – №. 2. – С. 326-338.
- Locke E. A., Latham G. P. Building a practically useful theory of goal setting and task motivation: A 35-year odyssey //American psychologist. – 2002. – Т. 57. – №. 9. – С. 705.
- Locke E. A., Latham G. P. New directions in goal-setting theory //Current directions in psychological science. – 2006. – Т. 15. – №. 5. – С. 265-268.
- Mann L., Samson D., Dow D. A field experiment on the effects of benchmarking and goal setting on company sales performance //Journal of Management. – 1998. – Т. 24. – №. 1. – С. 73-96.
Публикую заметки к книге
http://sdu2020.blogspot.com/2020/10/agendas-alternatives-and-public-policies.html

Dislike, unshare, unsubscribe.