TOC для строительной отрасли.





В предверии мастер классов в Петербурге, хотел бы познакомить с ТОС на примере разбора частных решений для различных участников рынка: проектных мастерских, генерального подрядчика, профессиональных рабочих, поставщика материалов или частной бригады рабочих, выполняющих ремонт в квартире.
ТОС предполагает целостный взгляд на картину с разных сторон, чтобы определить корневую причину большинства нежелательных явлений, с которыми все сталкиваются ежедневно, ежемесячно или даже ежегодно, другими словами регулярно. Даже если событие насупило лишь раз, откуда знать, что это не просто прецедент?
Хэдлайнеры конференции:
- Эли Шрагенхайм с темой обучения ТОС и извлечению максимальной пользы от этого,
- Йен Хептинстал с применением частных решений ТОС в строительных проектах и созданием проектных альянсов.
Мысль ТОС ушла далеко вперёд со времён «Цели». Всем известно про частные решения для производства и проектов, а так же для управления цепями поставок. Вот только современная среда гораздо разнообразней частного взгляда на неё и для эффективного управления необходимо сочетать практики различных подходов. Другими словами, в ТОС тоже про адаптивность, жизнеспособность и все такое.
Мероприятие будет интересно тем, кто занят в строительной тематике, так как Йен будет много говорить про контракты, которые во многом регулируют отношения Заказчик-Исполнитель. Да, да, то о чем договаривались «на словах» не важнее то, что отражено текстом договора. Заказчик не понимает, что передача риска невозможна, Исполнитель не в курсе того, какая работа от него требуется. Из такой бреши в коммуникациях вытекает много денег на лишнюю работу в виде переработок уже выполненного объема и прочих потерь.
Новые контрактные отношения может инициировать как исполнитель, так и заказчик работ.
Чтобы приступить к классическому пути поиска корневой причины, разрешения конфликта и проведения изменений, необходимо найти НЖЯ, которые являются следствиями настоящих проблем, которые требуют первостепенного внимания для их решения.
Чтобы не заниматься долгим поиском, есть более короткий путь — определить целевое состояние строительной отрасли, когда все ХОРОШО. Сравнивая текущую ситуацию с идеальной мы и найдём пресловутые НЖЯ. К тому времени большая часть дерева текущей реальности будет близко к готовности.
Итак, первый шаг заключается в определении идеального состояния отрасли. Тут же есть затык — иметь в виду картину в отдельно взятом городе или стране в целом? Или может мировой рынок сразу?
Как определить эти границы: стоимостью недвижимости, объемами ввода и использования?
Есть много вопросов, так что я ограничился масштабами отдельно взятой городской агломерации. Государственный уровень касается  регулирования и находится за пределами влияния частной инициативы. На уровне городов именно частная инициатива меняет ландшафт взаимодействия людей, создавая новые пространства.
Как выглядит идеальное городское пространство? Стоит ли ориентироваться на примеры модернизации других городов или в российских городах «особые условия» и все предсказуемо плохо?
Что можно сказать о рынке недвижимости в идеальном состоянии?
- владельцы недвижимости становятся богаче со временем за счёт роста стоимости активов,
- спрос на недвижимость растёт,
- на рынке есть покупатели из разных социальных групп и различного достатка,
- экономика города растёт из года в год,
- доля услуг в ВРП растёт,
- у региона широкие и разнообразные деловые и культурные связи по всему миру,
- структура городских пространств способствует/не препятствует для реализации потребностей резидентов (деловые, культурные, социальные, экологические),
- Что еще стоит добавить?
Дерево текущей реальности будет состоять из логических взаимосвязей между причиной и следствием, чтобы определить истоки большинства проблем и недовольств.
Перед тем как приступить к работе, поделюсь своими соображениями наперед, отчасти как напоминание самому себе, что есть склонность к однобокости описания текущей ситуации. Полагаю что одним из ключевых аспектов являются договорные отношения, в которые вступают участники рынка. Сложившиеся уклады того, о чем и как договариваться с заказчиком или исполнителем работ — основа договорных отношений требует кардинального пересмотра в сторону большей гибкости и вариативности условий, о которых договариваются (к примеру договор долевого участия мог бы включать перечень процедур приёмки готовой квартиры).
Такие дела для начала. Stay tuned. . .
P.S. План таков:

  1. Собрать НЖЯ отрасли

  2. Построить дерево текущей реальности

  3. Найти корневые причины

  4. Определить конфликтные состояния (Построить Тучи)

  5. Глянуть что будет дальше


Заговор против Станиславского.

В Ростове на улице Станиславского нашли останки людей, которые жили там тысячу лет назад.
1000 лет — это очень много. В мире не так много городов, которые могут похвастать таким возрастом и далеко не все из них сейчас процветают. Города загибаются, если не усваивают опыт собственных решений и успешные примеры коллег. Вода нагревается медленно, Поэтому забавно читать про "важные" рейтинги городов страны, когда реальная конкуренция гораздо шире границ страны и географических широт.

Но вернемся к улице Станиславского, про города как-нибудь потом.
Улица тянулась от порта к центральному рынку и некоторые здания все еще помнят разные времена от царей до . . . нынешних дней. Уверен, что если бы собирали статистику продаж пирожков и прочего (простигосподи) стритфуда, 80% продавались бы именно на Станиславского. Ныне там очень грустно, ремонт дороги затянулся сначала из-за раскопок, а потом из-за подрядчика, который куда-то удрал.

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

Как бы не так!

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

Что все это значит?

Достал из закромов старый пост ailev про два способа описания описания деятельности в условиях неопределенности. Ссылку дал, но тут приведу текст полностью, чтоб не было отрыва внимания.

"
Два способа описания деятельности в условиях неопределённости


Есть две основных метафоры, которыми пользуются люди для показа всё большего понимания ситуации по ходу деятельности:
-- обучение: чаще всего используется технологическими менеджерами и предпринимателями в знаниевых организациях (разработчики). Фишка тут в том, что вы не знаете, чему учитесь на каждом шаге: делаете вы каждый раз что-то другое, а в итоге бабах: вы чему-то (полученные знания часто tacit knowledge и трудно рефлектируемы) научились, стали лучше понимать ситуацию. Австрийская экономика идёт по этой линии, обоснования hyper-productive organizations (и апологетика agile и lean) проходит по этой линии, классика жанра тут "Пятая дисциплина" Питера Сенге. Начало этой всей социологической-экономической традиции обсуждать знания для продуктивной работы идёт от работы Хайека (1945) "The Use of Knowledge in Society". Скажем, beyond budgeting тоже отсюда: "постепенное прояснение ситуации требует гибкости в планировании и расходовании финансов", а "прояснение ситуации" сводят к "обучению". Чему учимся? А всякому, что нужно, не называя это даже словом "обучение". Но главным образом учимся вокруг целевой системы и её окружения (рынки, использующая система).
-- совершенствование-улучшение: процесс непрерывных улучшений, цикл Дёминга, главным образом не разработка, а производство. Фишка тут другая: вы каждый раз знаете, что усовершенствовали. "Прогресс", безусловно, из этой серии (понятно, в чём он состоялся). Этим занимаются инженерные менеджеры и процессные управляющие/службы качества главным образом. Но иногда так обсуждают и agile (с точки зрения уточнения состава практик). Это всё про обеспечивающую систему.

Для меня лично эта метафора "обучения" очень трудна (как, впрочем, и метафора "машинного обучения" по сравнению с метафорами распознавания образа и анализа сцен). Это типа как в НЛП (которое нейролингвистическое) говорится, что "плохой привычке вы научились. Как вам удалось научиться?", там тоже метафора обучения.

А вот про "непрерывные улучшения" я хорошо понимаю, идея "прогресса" мне ясна.

А как у вас с метафорой learning organization, предпринимательства и стратегирования как learning, интенсивной коммуникации при разработке продукта как learning? Понятно, что все про это читали. Вопрос, использовали ли это мышление в терминах "обучения" на практике, или перед использованием как-то переформулировать приходилось? Про "улучшения" или "совершенствование" ведь никто ничего не переформулирует, прямо так и используют. А про "обучения" я в жизни использований почему-то не встречал, зато в книжках -- всё цветёт и пахнет именно этими словами (а хоть и в книжке про TameFlow, 2015 года выпуска. Там все начальные главы про это).

"

Далее в одном из комментариев было пояснение, в котором "цикл дёминга -- убирать отклонения, вести к гомеостазу, совершенствование в этом. Цикл Бойда -- это цикл понимания-действия. В литературе часто не разбираются и приводят просто через запятую (иногда добавляя к этому цикл непрерывного совершенствования Голдратта)".

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

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

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

Что случилось 100 лет назад?



То, что мы творим с историей — это в интересах прошлого, будущего или настоящего?

100-летие революций заставило взглянуть на то, как мы склонны относиться к домыслам и слухам о старых временах и самое главное то, что мы с этими «данными» делаем.

Я неоднократно видел спор, где люди грызлись кидаясь «фактами» 500, 200, 100 летней давности, будто они сами были свидетелями событий. Даже авторитетные историки частенько додумывают, что и говорить о возможности намеренной фальсификации улик и создания артефактов, ведь победители каждый раз «творили» историю заново.

Можно теперь по-разному смотреть, что же произошло сто лет назад. Помимо хитрых планов, было много случайности, везения, а для кого-то и невезения. Мы внуки и правнуки того времени и как в любой семье, у нас есть свои маленькие секреты друг от друга.
Полной картины нет ни у кого, а сама карта — не территория;)

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

не всё сложно

ailev снова высказался в привычной манере про преподавание, освоение statу of art предметной области. О последних достижениях в отрасли еще нет инструкций, описаний и учебников как к ним прийти. Освоение же новых интструментов и практик тормозиться тем, что инструкции и прочие указания никто не читает. 

Те же мыслительные процессы ТОС имеют ряд инструкций, которые со временем стали четче и понятней, но их все равно не читают. Критерии проверки логических построений (КПЛП) напоминают страшный сон одним своим названием. Барабан-Буфер-Канат, Критическая цепь и прочее все это — рабочие продукты применения логичечких построений из ТОС. Их не так и много:

- Дерево текущей реальности

- Грозовая туча

- Дерево будущей реальности

- Дерево перехода

- План преобразований

- Дерево Стратегии и Тактики

- Дерево премежуточных целей

Но и этого достаточно, чтобы вогнать в скуку любого "энтузиаста" или "реформатора".  


Системная медитация 2.2

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

Что такое системный подход?

Системный подход — это (всего лишь) способ представления окружающего мира, в котором все состоит из систем. Исследование системы всегда стоит начинать с её основной функции в качестве части надсистемы и только потом компоненты, модули и размещения. Для человека, который имеет дело с системным подходом всё вокруг — это системы, но все эти системы не только разные сами по себе, они разные по их роли в инженерном проекте и разные по интересующим стадиям их жизни (говорят о стадиях "жизненного цикла" системы — хотя никакого "цикла" там нет, да и "жизнь железки" тоже ведь не жизнь! Но об этом позже). Для показа этой разницы ISO 15288 вводит следующую классификацию систем, которая неявным образом включает в себя и стадию жизненного цикла рассмотрения системы:

Использующая система — система, которая получает выгоду от использования целевой системы. Например, небоскреб в пригороде Подольска.

Целевая система (systems-of-interest) — та, которая подлежит созданию (или модернизации) командой инженеров и рассматривается на всём протяжении жизненного цикла. Например, кондиционер для изменения температуры воздуха в помещениях небоскреба.

Система в операционном окружении, система в эксплуатационной среде (system in operational environment) — одна из систем, которые окружают целевую систему в момент её эксплуатации. Например, система вентиляции и кондиционирования, в которой помимо нашей целевой системы есть сеть датчиков, патрубков, источники питания и тд.

Обеспечивающая система (enabling systems) — система, которая создаёт и поддерживает систему в ходе её жизненного цикла. Например, инженерная служба в управляющей компании небоскреба.

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

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

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

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

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

Для того чтобы проводить целенаправленные изменения в системе, очень хорошо знать с чем имеешь дело, что к этому делу относиться и что лучше оставить за бортом. Системная медитация и является такой процедурой, когда происходит выявление и прояснение информации о интересующей области. Тому, кто собирается каринальным образом улучшить то, что он делает, необходимо разобраться не только в предметной области (профессия). Наиболее важно разобраться в организационном вопросе — как создается то, что создается. Для проведения системной мдитации подготовьте пару листов А4 и ручку. Сразу предупреждаю, что что-то будет выглядеть коряво и несуразно — так и должно быть, это фишка плана;) Отвечать следует подряд, так быстрее.


СИСТЕМНАЯ МЕДИТАЦИЯ

1. Представьте себе то, что вы создаёте. Даже если вы создаёте "сервис", то вы создаете не столько сам этот сервис, сколько то, что потом этот сервис оказывает.

2. Обзовите то, что вы создаёте, "целевой системой". Обзовите себя и тех, кто трудится над целевой системой вместе с вами (людей, инструменты, помещения) "обеспечивающей системой".

3. Обзовите тех, кто пользуются целевой системой (клиентов, заказчиков, потребителей, покупателей и тд) "использующей системой", нужды (и какие будут тесты приёмки)

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

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

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

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

Думайте в терминах стрелочки-жизненного цикла и отрезков между штришками на этой стрелочке — стадиях.

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

4. Подумайте, где вы обычно начинаете принимать участие в судьбе целевой системы (или система начинает принимать участие в вашей судьбе обеспечивающей системы), и где вы эту систему покидаете. Отметьте это на стрелочке.

5. Нарисуйте рядом похожую стрелочку обеспечивающей системы (для "мы", или для "я" — на ваш вкус) — выполните пункт 4 для неё. Можете поупражняться, нарисовать и для этой системы обеспечивающую ее систему (кто делает вас?). Вполне может быть вариант, в котором вы сами себя делаете — ну что же, и так может быть. Или не так. Подумайте над этим.

6. Теперь можно подумать, как называть вашу целевую типовую систему (ту, первую). Собственно, тут волнует не столько название, сколько определение. Определение делается по следующему образцу:
[название типовой системы] — это [название ее родовой системы] [описание специализации]. Рама — это крепление для стекла. Рама — это набор покрашенных деревяшек. Напишите десяток таких определений, которые могли бы дать разные люди, которым система нужна для разных целей.
7. Помните, что вы себя как "обеспечивающую систему" уже нарисовали стрелочкой. Что делает эта ваша стрелочка со стрелочкой системы? Как называется та типовая работа, которую вы делаете с целевой системой? Какая ваша роль? Запишите это на бумажку: [моя роль] [что делаю] [целевая система]. Пример — "Мама моет раму".

8. Каким методом вы делаете то, что делаете? Осознаёте ли вы, что вы делаете (другая формулировка: смогли ли вы ответить на предыдущий вопрос, назвав при этом несколько альтернативных методов, осознанно вами отброшенных)?

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

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

11. Вернитесь к п. 8 и по возможности определите несколько альтернативных методов, которые можно использовать для выполнения той же самой работы.

12. Посмотрите на каждую стадию жизненного цикла (особенно Целевой Системы) и по возможности трансформируйте каждый метод в процедурный чек-лист (что необходимо сделать для выполнения работы —своеобразная памятка). В конце каждой стадии жизненного цикла определите перечень параметров для проверки (проверочный чек-лист) чтобы минимизировать количество ошибок и переделок в дальнейшем.

Теперь вы знаете, что делаете. Или знаете, что этого не знаете.

Состояние дел в ССРМ.

9 марта в Хельсинки прошла конференция ТОСРА. Основная тема "ТОС in Construction".
Самое близкое к теме было выступление Ian Heptinstall. Сообщение было простое — Критическая Цепь всего лишь необходимое, но не достаточное условие для пруспевания в инвестиционно-строительных проектах. Проект теперь представлялся со стороны заказчика, когда до 90% работ выполняются чужими руками.  Это уже совсем другий тип проекта, хотя основной конфликт остался тем же — ответственные за результаты проекта часто не совпадают с теми, у кого нужный ресурс для их реализации. Почему так просиходит?

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

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



Буфер менеджмент из ТОС можно реализовать только при наличии общего запаса проекта на всех участников. А сложившийся порядок договоренностей не благоволит такой модели, особенно если речь идет о дележке прибылей, которые где-то в будущем, туманном и пока что совсем неопределенном. Добавляет путанницы в понимании среды тот факт, что есть два проекта — один про проект, который делают проектировщики, другой про проект, который делают планировщики. Благо еще строители свой проект пока еще называют просто работами или объемами.

Collaboration needed. Extremly.

В чем ценность программного решения?

Продавцы программных продуктов вплоть до Microsoft делают упор на учетной способности своих продуктов. Они же любят называть программы решениями. «Программное решение проблем клиента»
Если я веду дела в блокноте, привести статистические данные по работе не представляется никакой возможности. Другое дело с электронным помощником, который с точностью до секунды расскажет о том, сколько, где и когда. Это преимуществом становится только тогда, когда эти данные используются другим процессом, а не пылятся в архиве. И если регулярно не проводятся обзоры работы и никто целенаправленно не улучшает делопроизводство, то аналитическая способность программ не такое уж и весомое преимущество для потенциального покупателя. Еще одна беда аналитики в том, когда данные нельзя связать с конкретными действиями или связывают черт те что. Аналитика бесполезна или даже вредна для тех, кто ей никогда не пользовался. Учитывая пассивную роль покупателя на этом рынке, странно что производители программных продуктов продолжают гнуть свою линию.
Продают положительные отзывы тех, кто пользуется купленным решением. Потенциальная выгода определяет масштаб преобразований в текущей работе. Вот Micosoft написал статью с 6 не самыми очевидными причинами почему провалились проекты. Интересно проследить логику исследования:
Причина 1
Статичные методы — по итогам проекта стало ясно, что если бы использовали гибкие методологии, то избежали бы провала?
Причина 2
Недорогие программные решения — используй они дорогие, звезды бы сошлись иначе? Они правда в это верят?
Причина 3
Неэффективное управление виртуальной командой — звучит умно, а информации ноль. Более того, это констатация факта, который похож на следствие, а не причину.
Причина 4
Слабая поддержка руководителя —  была бы сильная, проекты бы взлетели — откуда они это узнали? Все проекты с сильной поддержкой руководства добивались успеха? Really?
Причина 5
Несоответствие целям и стратегиям предприятия — немудрено для компании с несколькими стратегиями. Наконец таки упомянуты конфликты и потери, к которым они приводят.
Причина 6
Сбой в коммуникациях — «К счастью, последние исследования говорят о том, что покупка правильного программного обеспечения для управления проектами может значительно улучшить коммуникацию внутри команд, а также коммуникации с клиентами. Возможность связываться в реальном времени с членами своей команды, расположенных ниже этажом или в другой стране с помощью инструментов, созданных для передачи критически важных сообщений быстро и безопасно – это ключевой фактор для успеха проекта.»
Один или даже несколько сбоев в коммуникациях по мнению Microsoft могут быть причиной провала проекта. Интересно, они искали, что являлось причинами этих сбоев?

Сдается мне, в следующей статье публике представят еще более неочевидные причины почему "действительно" проекты проваливаются.


А ведь мир становится сложнее с каждым днем.

Преподавание это практика философии?

Рванул пукан у Елены Федурко, видать совсем мало клиентов приходит, раз она пошла на то, чтобы открытым текстом писать о том, какая она крутая и умная в этом деле. Если никто про нее не пишет, она сама напомнит о том, какая она крутая.

А я все мусолю мысль про уровни компетенций из OMG Essense, там помимо 5 ступенек мастерства есть три области применения: профессиональная, коммуникативная и управленческая. С первой и последней более менее понятно о чем они, а вот с куммуникациями все куда запутанней. Мутность в том, что при разработке стандарта предполагалось что области применения компетенций покрывают все нужды современной организации, таким образом коммуникативная мышца работает с клиентами, между подразделениями и вообще обеспечивает обмен информации в рассматриваемой системе, а это от появления данных до их применения и получения обратной связи. Когда речь заходит об обучении, именно коммуникации обеспечивают скорость развития компетенций за счет исследовательской составляющей.