Победи_Аристотеля

Не так сложны первые 90% проекта, как вторые 90%! Но я дописал очередную статью/очерк, выкладываю в режиме RFC

Осторожно, 2 а.л. текста:
45 страниц
12051 слов
92230 знаков
80569 количество знаков (без пробелов)

Алексей Пименов: "Нет самоцели сделать канбан-трансформацию".

Алексей Пименов

Основатель и Аккредитованный Канбан тренер, консультант 
Аккредитованный тренер Kanban University, первый российский специалист уровня Accredited Kanban Consultant, преподаватель международного консорциума ICAgile. Тренер и консультант по темам Kanban Method и Business Agility. Спикер на тематических конференциях, автор статей, научный редактор книг, создатель и активный участник тематических сообществ.

0:41 Эволюционные изменения и адаптация в канбан-методе
2:00 Канбан-метод - это инструмент управления работами. Проактивное и реактивное развитие организации.
3:57 Теория канбан-метода
4:35 На что оглядывались при разработке канбан-метода?
7:39 Литература для изучения
11:20 Так ли уж ИТ-проекты отличаются от промышленного производства и как это влияет на применение канбан-метода?
13:02 Канбан-метод - это "градусник" для измерения температуры процессов
15:47 Как описывать деятельность на разных уровнях организации?
16:25 Фрактальный подход к описанию клиентских сервисов
19:05 Неудачный пример для применения канбан-метода
20:23 Контекст применения канбан-метода
22:31 Какие решения помогает принимать канбан-метод?
23:23 Загрузка производственной системы и как обеспечить продвижение работы?
25:30 Про современных менеджеров
25:50 Как продвигать канбан-метод?
27:31 Канбан-метод в условиях жестких дедлайнов
31:30 Про консультантов и их ответственность
35:05 Как выбирать консультантов?
39:56 От чего зависит цена специалиста на рынке?
45:50 Должен ли заказчик понимать тонкие различия между предлагаемыми методами и инструментами?
48:10 Про чуйку в консалтинге и выход из контракта

https://youtu.be/Hwe9d5noqt8

Павел Капусткин: "Хороший продуктовый менеджмент должен существенно увеличивать пользу от Agile"

0:20 Что такое продуктовый менеджмент
2:20 В чем заключается роль продуктового менеджера
6:20 Agile и продуктовый менеджмент
9:20 Архитектура продуктовых команд и производственные систем
12:50 Проблема "сшивки" предметных областей
17:20 Никакой магии и волшебных таблеток не бывает
17:38 Какие подходы к решению проблемы организации продуктовой разработки есть
27:47 Управление рисками в продуктовой разработке
33:45 Подводим итоги обсуждения
34:30 "Вишенка на торте" и нужна ли математика продуктовым менеджерам
36:25 Что такое эффективный продуктовый менеджер в российских условиях
37:30 Нужны ли процессы разработки?
39:00 Где и чему учиться

https://youtu.be/z6xGa3m7LJI

Нигде по тексту документа MIL-STD-881 не говорится о том, что ИСР является декомпозицией работ проекта. В разделе 3 "Определения" указано "Иерархическая структура работ (ИСР). Выраженное в терминах конечных результатов иерархическое дерево с единственной головной вершиной, которое состоит из составных частей изделия (системы), услуг и данных, которые являются результатом инженерных работ по разработке и построению изделия (системы), и которое полностью определяет проект либо программу. ИСР отображает и определяет результаты, которые необходимо получить в рамках проекта либо программы и определяет входимость составных частей работ проекта либо программы. Другими словами, если мы берем классический проект по выполнению опытно-конструкторских работ, то ИСР в исходном понимании практически идентична схеме деления, см. ГОСТ Р 2.711-2019. А где же задавалась декомпозиция работ проекта?

Разукрупнение (декомпозиция) работ проекта описана в вышедшем 1 августа 1977 года руководстве MIL-HDBK-245 Department of Defense Handbook: Preparation of Statement of Work (SOW) (Руководство по подготовке описания содержания проекта). В нем говорится "The SOW should specify in clear, understandable terms the work to be done in developing or producing the goods to be delivered or services to be performed by a contractor." "Описание содержания проекта должно четко и однозначно описывать необходимые к выполнению в рамках проекта работы по разработке или производству поставляемой продукции либо по оказанию услуг". Если совсем просто, то ГОСТовским техническим заданиям и частным техническим заданиям соответствуют описание содержания проекта с требованиями к выполнению работ и specifications с требованиями к изделию (системе) и его составным частям. И точно также, как хорошее техническое задание задает структуру календарно-сетевого графика выполнения опытно-конструкторских работ, описание содержания задает структуру декомпозиции инженерного проекта.

Разница между этими документами не принципиальна, комплект из описания содержания и product specification в США почти полностью соответствует комплекту из головного технического задания на ОКР и частных технических заданий на составные части ОКР в России. Что тот что другой комплект документации задает декомпозицию работ проекта. Так зачем же тогда нужна ИСР и почему почти все разработчики инструментов проектного управления от MS Project и до ClickUp с JIRA не понимают принципов ее использования? Почему методический поворот оказался таким сложным для понимания и как так получилось, что суть ИСР в корне исказилась наивной интерпретацией термина?

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

Такое устройство системы управления проектом позволяет распределить принятие ключевого решения. Аналогично, в разработке ПО решение о релизе за последние 20 лет "расползлось" от единоличного решения технического директора или директора по разработке (Ашманов, 2008) до множества коммитов каждого отдельного разработчика в Git.
Итак, между крушением "Титаника" и выходом статьи 'The Project Manager' в 1959 г. одновременно с прагматическим и семиотическим поворотом [ссылка на мою статью] происходит смена парадигмы проектного менеджмента, возникают методы проектирования, которые забирают часть ответственности за принятие ключевого решения в инженерном проекте с главного разработчика и проектного менеджера. Эффекты этого изменения превосходят всяческие ожидания - сменяется подход к управлению проектными рисками, возникает понятие осознанного принятия рисков, manageble risks. Если в эпоху Великих географических открытий отправка корабля в далёкое путешествие была ставкой на удачу, gamble risk, и даже капитан "Титаника" воспринимал ситуацию столкновения корабля с айсбергом как что-то несущественное (Schröder-Hinrichs et al., 2012), какую-то небольшую ставку, которую стоит принять, чтобы поставить рекорд по скорости пересечения Атлантики, то катастрофа "Челленджера" рассматривалась уже исключительно через призму контрфактуальности, причинно-следственных связей (сноска подробнее про контрфактуальность и причинно-следственные связи см. (Клейнберг С., 2017; de Mesquita and Fowler, 2021)) и рассуждений в стиле "этого можно было бы избежать, если бы ..." (R. P. Feynman, 1986; “Rogers Commission Report”, 1986). Методы проектирования снизили величину риска, "размазав" принятие ключевого решения, и повысив повторяемость и воспроизводимость ситуаций принятия решения. Риски из статических стали динамическими, ими стало можно управлять, что, конечно, очень понравилось представителям страховых компаний и банков (Cooper et al., 2005; Gehner, 2008).

Ключевым моментом методического поворота стало 1 ноября 1968 года, день, в который Министерство обороны США выпустило первую версию стандарта по иерархическим структурам работ MIL-STD-881 Work Breakdown Structures for Defense Materiel Items (Иерархические структуры работ для изделий военного применения). Он был обязателен для применения во всех стратегических программах и в проектах с бюджетом больше 10 млн. долларов США. Разработчиком стандарта был штаб командования систем военно-воздушных сил авиабазы Эндрюз, Вашингтон, округ Колумбия, дирекция стоимостного анализа, отдел стоимостной информации и управленческих систем. Если открыть этот стандарт, то можно легко убедиться, что ни о каком разукрупнении работ в этом стандарте речи не идет. "Иерархические структуры работ (ИСР) обеспечивают согласованный и явно описанный подход, который способствует:
а. Более эффективной управленческой и технической основе планирования и корректному назначению ответственных за управленческие и технические решения государственных структур, вовлеченных в реализацию проектов, и подрядчиков
б. Более согласованному контролю и менее противоречивой отчетности о ходе работ в проектах и текущем статусе, а также о занятости ресурсов, стоимостных оценках, текущих расходах и закупочных процессах
в. Учету экономических и других эффектов на всем жизненном цикле изделия, включая стадии разработки, производства, ввода в эксплуатацию, применения по назначению и выводу из эксплуатации при принятии технических и управленческих решений."

Эти принципы были заимствованы из британской юридической практики: обстоятельства дела, место и времени событий должны были быть зафиксированы письменно, быть достоверными и проходить перекрестную проверку. И результаты этой проверки должны были предъявляться заказчику в понятной ему форме. А поскольку содержание эскизного, технического и рабочих проектов было сложным для понимания непосвященными, в проектных планах появились контрольные точки - ключевые события, в которых предъявлялись имеющие смысл для заказчика результаты, документы и расчеты. Например, смета и график выполнения работ с точностью до 10%, выбранные основные субподрядчики и поставщики, изготовленный опытный образец, заключение страховой компании о готовности подписать договор страхования. Таким образом, работы проекта и проектная документация представлялась в двух структурах - в инженерной структуре этапов проектирования, изготовления и сдачи-приемки, и в управленческой структуре - контрольных точках и папках со сборниками доказательной базы (кейсами контрольных точек). Инженеры подтверждали техническую и экономическую обоснованность проектных решений, а менеджеры подтверждали их финансовую, коммерческую и юридическую обоснованность. В результате таких проверок все могли доверять проектной и конструкторской документации и подтверждающим ее документам и свидетельствам. И предпринимающая проект организация стала передавать заказчику не только итоговый комплект конструкторской и проектной документации вместе с изготовленным изделием, построенным зданием или сооружением, но и всю эту доказательную базу. В проектном менеджменте появилось понятие deliverable, которое на русский язык неудачно перевели как "предмет поставки". Скорее, это подтверждение факта работ, выполненных в соответствии с согласованным методом проектирования и порядком ведения дел, артефакт, рабочий продукт метода. И именно понятие deliverable как некоторого подтверждения того, что работа выполнялась и важные решения принимались в соответствии с каким-то методом, перевернуло в первой половине 20 века весь проектный менеджмент. Вместо персональной ответственности главного конструктора, проектировщика, разработчика, появилась совместная агентность проектного менеджера и метода управления проектом, в полном соответствии с акторно-сетевой теорией Бруно Латура (Латур, 2020, 2017; Напреенко, 2015). Метод управления проектом и его корректная реализация стал значить не меньше, чем личность, опыт и экспертность проектного менеджера (“Beyond Agility | PMI,” 2021; “Pulse of the Profession 2016,” 2016; Reinertsen, 1997, 2009). Появились бизнес-процессы, на которые можно было свалить вину за ошибки и провалы. В 1992 Эдвард Деминг зафиксировал этот методический переход известной фразой: "Blame the process, not the people."

Таблица 1. Пример "пирамиды" доказательной документации. На 3 страницы документации, которая предоставляется по договору на опытно-конструкторские работы (разработку комплекса систем) предоставлено 1940 страниц подтверждающей документации и 85 фотографий собранного опытного образца и его составных частей. Весь этот комплект формирует доказательный кейс, дело проекта разработки, который предоставляется на защиту контрольной точки "Изготовление опытного образца ПАК и корректировка РКД по результатам сборки". Согласно Руководству к своду знаний по управлению проектами нельзя просто показать изготовленный опытный образец и приложить акт его сборки, отчетный документ по договору сопровождается большим объемом подтверждающей документации.

Методический поворот и его влияние на процесс принятия ключевого решения

Еще "Титаник" строился чисто по комплекту конструкторской документации (Halpern et al., 2016). В 1920-х страховые компании и разработчики еще не осознавали, насколько важен процесс получения чертежей, спецификаций, итоговых расчетов и результатов испытаний, то есть, метод проектирования. До появления методов сами конструкторские документы за подписью главного проектировщика являлись полной доказательной базой решения о начале строительства корабля, моста или здания, вне зависимости от того, каким способом были получены эти документы. За их точность, полноту и достаточность нес ответственность главный конструктор (“British Wreck Commissioner’s Inquiry Report on the Loss of the ‘Titanic,’” 1912), вставить ссылку на Рида. В случае гибели судна, разрушения моста или здания отвечал главный конструктор единолично. Методы проектирования создавали цепочки ответственности, где главный конструктор принимал конечное решение, однако он опирался на уже принятые его подчиненными базовые решения. Главный конструктор отвечал за всю конструкцию целиком, а, скажем, за прочность корпуса отвечал совместно с ним другой, за ходовую часть третий, а за компоновку и удобство третий. Под каждый итоговый документ, который шел в комплект конструкторской или проектной документации, подкладывались обоснования, создавались цепочки доказательств обоснованности принятых инженерных решений.

Сторонние специалисты, те, которые не участвовали в проектировании, независимо проверяли эти цепочки доказательств в особые моменты проекта, которые стали называться "этапами проектирования". В советской и далее российской инженерной традиции эти этапы называются "эскизное проектирование", "техническое проектирование", "рабочее проектирование"; в американской выделяются похожие concept design phase, technical design phase, detailed design phase. Границы между этапами это и есть точки контроля этих самых цепочек доказательств обоснованности принятых инженерных решений. Проработанность решений на этапе эскизного проектирования должна быть достаточной, чтобы без особых рисков начать принимать решения по техническому проекту, а к рабочему проектированию мы можем переходить тогда, когда все ключевые решения по классам и составу оборудования, компоновке и взаимодействию уже проработаны в достаточной степени, чтобы понять, у кого заказывать изготовление и что можно сделать на собственном производстве. Опытный инженерный менеджер или разработчик никогда не обольщается плановыми сроками и графиками и не верит плану выполнения работ, который говорит, что проект находится на этапе рабочего проектирования, если видит, что многие принципиальные решения по факту еще не приняты, а команда не договорилась о составе изделия, протоколах информационного обмена и о техническом сопряжении составных частей. Метод проектирования должен был порождать доказательную документацию, которая бы соответствовала действительности, обман и подлоги жестко наказывались. Чтобы методу можно было верить, надо было в первую очередь верить проектной и конструкторской документации.

Причем с появлением в контуре проекта банков, страховых компаний и структур корпоративного управления неправильным может стать не только неработоспособное техническое решение, но и любые действия, пройденные развилки или сделанные выборы, которые не отвечают внутренним нормам и правилам корпорации, регуляторным нормам, законодательству или требованиям технических регламентов. Проектный менеджер уже не мог оставаться только хорошим инженером и проектировщиком, при принятии решений он должен был учитывать появлявшееся в 1950-х корпоративное управление. Например, после крушения "Титаника" появились конвенции SOLAS (Safety of Life at Sea) и COLREG (Collision of Ships Regulation), изменились условия страхования судов (Allianz and Cardiff University, 2012; “British Wreck Commissioner’s Inquiry Report on the Loss of the ‘Titanic’ ” 1912; Halpern et al., 2016; Schröder-Hinrichs et al., 2012). Пространство выборов в проектах увеличивало свою размерность, и один человек уже не мог полноценно нести всю полноту ответственности за ключевое решение. Появилась потребность распределить эту ответственность на нескольких человек. Они готовили варианты решений, обосновывали каждый вариант, правильно подбирали формулировки и оформляли решение. А лицо, принимающее решение, выбирало один из вариантов и ставило под ним утверждающую подпись. В случае чего отвечали все.

Подготовка сложных решений потребовала от людей изобретения методов проектирования и разработки (Cross, 1993a, 1993b), которые во многом сняли тяжесть принятия ключевого решения. Как сказано по этому поводу в (Мартин, 2011), "Доверяйте своим методам. Если вы попали в трудную ситуацию, доверяйте своим методам. Они для того и нужны, чтобы помочь вам выбраться из тяжелой ситуации. В такое время следует особенно тщательно следить за соблюдением правил, а не ставить их под вопрос или отказываться от них. Вместо того чтобы в панике искать хоть что-нибудь, что поможет вам ускорить работу, вы должны сознательно и целенаправленно соблюдать требования выбранных методов. ... Чтобы выйти из тяжелой ситуации, необходимо довериться тому, в эффективности чего вы уже уверены – вашим методам." Методы управления разработкой, иными словами, методы управления процессом принятия ключевых решений, стали крайней важны, иногда достигая уровня почти религиозного, как это вышло с "6 сигма", "Скрам" и "классическим проектным менеджментом".

К каким практическим изменениям привел этот методический поворот в проектировании?

Ключевое решение в инженерном проекте

Иерархическая структура работ (ИСР) как инструмент управления появилась в 1940-50 гг., до этого нужды в ней не было. Мегапроекты, конечно, были и раньше - строительство гигантских флотов, сети железных дорог, сооружение комплекса заводов для производства серийных автомобилей, строительство "Титаника", но они все исполнялись методами, зародившимися в середине 19 века. Чертежей, ведомостей и спецификаций с графиками выполнения работ вполне хватало для управления этими огромными проектами. Что же такого произошло в мире, что потребовало в 1940-50-х изменения подходов к управлению?

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

Я сам столкнулся с такой ситуацией на первом проекте, где я был в роли проектного менеджера. Мы сидели на совещании, где обсуждалась закупка дорогого производственного оборудования. Сроки поджимали и решение о закупке надо было принимать не позднее четверга, чтобы в пятницу разместить заказ, спустя 12 недель получить оборудование на таможне, еще тремя неделями позднее начать шеф-монтаж и запустить новый технологический процесс через четыре месяца. Без работающего оборудования и нового техпроцесса мы не могли закрыть текущий этап и получить деньги на следующий. Что характерно, в комнате для совещаний были одни инженеры. Руководство не захотело обсуждать одно из ключевых решений, тем более, что проект производственной линии не был до конца проработан и выбор оборудования был далеко не так однозначен, как нам того хотелось бы. "Инженерный вопрос - значит решать инженерам. - ехидно прокомментировал ситуацию главный технолог. - Это тебе не цвета в бренд-стиле выбирать". Я каждый раз вспоминаю это совещание перед самым ответственным моментом в проекте - когда надо от документов и расчетов переходить к почти необратимым действиям. Заказать оборудование на 700 тысяч Евро, нанять человека на ключевую позицию, отдать приказ о начале работ или подписать обязывающий ко многому договор. Проектировать и планировать - это одно, воплощать что-то в жизнь - совсем другое. Особенно если неправильное решение или некорректная реализация может привести к неприятным вопросам во время аудита, выплате больших сумм или судебным разбирательствам.

On being the Pareto-best

Alexander Mikhalev, in the middle of December 2021, sent me a link to the beautiful article written by Swentworth, J., 2019. Being the (Pareto) Best in the World — LessWrong.

Why did it hook my attention? The idea behind the article is pretty simple — all good places with clear, marketable positions are taken. As Igor Mann recommended, you must beat the competition being Mister First. But you’re not the first reader of such books, so you’re late, and there is already the first wherever you go. You’ll always fail the comparison with the best on the market.

How will you break from this choice space where the favors aren’t yours? You go for the Pareto-best market positioning. For example, I am not the best project manager, but I have systems engineering and business architecture expertise. So, when you’re looking for all three boxes to be checked, I’m the best fit here.

And that’s what this article is about — it is on being the Pareto-best on the market. And there is a world of opportunities out there for it.

But here is the kicker — shouldn’t we reconsider the hiring process following this idea? If you have some vacancies open and a candidate’s pipeline, shouldn’t you choose the Pareto-best employee mix instead of hiring the best fit for positions opened?

"Назначать задачи и контролировать их исполнение - это не задача РП", - Антон Полисский.

Топикстартер - статья "Как понятие проекта раздулось до полной потери смысла и что с этим делать?"

1:11 Тема обсуждения 
2:10 Источники практик проектного менеджмента 
3:47 Мобилизационный аспект проектов 
4:37 Особенности внутренней проектной организации 
7:00 Проекты, которые не проекты 
9:23 Почему деление на "это проекты, а это не проекты" непродуктивно? 
12:24 Польза практик и инструментов проектного менеджмента 
13:56 Про критерии приемки и deliverables (непереводимый термин) 
15:52 Использование активов организации 
17:10 Назначать задачи и контролировать их исполнение - это не задача проектного менеджера! 
18:44  Про регулярный проектный менеджмент 
20:45 Что такое активы организации? 
24:27 Проблема слабой матричной организационной структуры 
27:09 Разбираемся с понятием deliverable на примере 
30:34 Разделение ответственности между проектным и линейным менеджером 
32:38 Завершение

https://youtu.be/rcRVTjSg_WM

Системная архитектура программно-насыщенных комплексов - за пределами нотаций, инструментов и техник

0:17 Тема обсуждения и проблематика
3:00 Что происходит с системной архитектурой?
6:13 Чем системная архитектура отличается от модели предметной области?
8:17 Где проходит граница между системными описаниями и описаниями контекста?
11:06 Важна ли согласованность системных описаний?
16:39 Классы и экземпляры в системных описаниях
19:01 Как быть с имплицитными описаниями?
19:56 Как учитывать паттерны и культуру обращения с классами систем?
25:16 Можно ли потерять системную архитектуру?
29:11 Инженерная археология и brownfield systems architecture
32:48 Как системный архитектор взаимодействует с командой?

https://youtu.be/2AARoFUy7vU

[[Транзакционная задача]] или когда инженерные технологии бессильны

[[Транзакция]], от лат. transactio — соглашение, договор. Минимальная группа последовательных операций, которая имеет смысл и может быть совершена только полностью. Транзакция может быть выполнена либо целиком и успешно, либо не выполнена вообще, и тогда она не должна произвести никакого эффекта.

Наступает Новый год и родители дружно скидываются на подарки для своего класса. В родительских чатах идут постоянные напоминания о том, что кто-то не сдал или еще даже не выразил своего желания сдавать. Наконец, все согласились по деньгам, перевели организатору, поездка в “Ленту” под акцию забита в календарь. Пока не выясняется, что одна мама решила не сдавать. Точнее как решила не сдавать. Она согласилась на словах и много раз написала “ок” в ответ на напоминания, но денег не перевела.
У организаторов получается развилка — добавить своих денег и купить на всех. Но это плохой прецедент. Можно перейти на темную сторону и купить подарки для всех, кто скинулся, а ребенку этой мамы не купить. Тут два вопроса — ребенок ни в чем не виноват раз; и второй — а как учительница ему объяснит, что вот подарки есть у всех кроме тебя? Тоже плохой вариант. Можно откатить транзакцию, вернуть всем деньги и объяснить в родительском чате, что ничего на этот год не будет потому что вот есть один отколовшийся от коллектива человек со своей несогласованной позицией, который блокирует имплементацию принятого решения. Пока у нас все идет по третьему варианту, но мне как исследователю проектной деятельности интересно построить концептуализацию сложившейся ситуации.

Ссылка на статью.

Александр Турханов - Основные ошибки внедрения проектного менеджмента в ИТ (вебинар)

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

Из этих теоретических посылок есть множество практических следствий, которые мы и будем разбирать на вебинаре и учить на тренинге "Управление работами в ИТ-проектах".

https://www.youtube.com/watch?v=vqU75G2_WDY

Системной архитектор как ключевой коммуникатор в техническом проекте

Почему бизнес-аналитик или проектный менеджер вряд ли вырастет в системного архитектора, что такое “серый ящик”, чем solution architect отличается от systems architect и от чего зависит количество итераций в проекте.
“Из моей практики видно, что если результатом коммуникации должны быть взятые на себя обязательства, планы или решения. В противном случае это не коммуникация, это что-то другое, это какое-то бесполезное времяпровождение, которое проект дальше по жизненному циклу не продвигает. Такое общение не ведет к успеху проекта”.
Лучков Александр, практик-исследователь применимости системного подхода в области проектирования технических систем. Действующий участник российского отделения INCOSE.