Гибкое управление сложными проектами

Немного о себе

Я достаточно давно работаю в IT-отрасли – преимущественно, именно в IT-проектах. В моей практике есть направления, связанные с информационной безопасностью, есть чисто IT как таковое, и есть небольшой опыт строительных проектов (на уровне понимания, как это происходит). При этом я также участвовал в достаточно сложных и интересных проектах – например, в разработке проектаЭлектронного Правительства для Санкт-Петербурга. Я думаю, что многие из вас пользуются его многофункциональным центром. Так вот, та информационная система, которая была создана в МФЦ для юридических лиц, – это как раз один из проектов, который я возглавлял.

Гибкое управление сложным проектом. Что это?

Что такое сложный проект для вас? Понятно, что критерии могут быть разные – по объему денег, по количеству участников, по рабочим местам. Но как вы представляете себе сложный проект?

• Постоянные изменения в ТЗ.
• Заказчик не знает, чего хочет. Добавлю к этому – исполнитель не знает, что спрашивать.
• Огромное количество неопределенностей. Я вообще считаю, что управление проектами – это управление вероятностями
• Пользователи не хотят ничего менять. Они всегда не хотят – более того, человек всегда не хочет того, чего он не знает.

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

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

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

А что такое проект? Только не надо мне зачитывать выдержки из PMBoK. Запуск системы? Космический корабль тоже можно запустить, но это ведь не проект?

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

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

Проект как решение проблемы

Допустим, есть некая ось времени и есть некая компания. Состояние этой компании на сегодняшний момент находится в точке Т1 данного графика. Это состояние может описываться любыми параметрами: размером маржи, прибыли, оборотными средствами, количеством рабочих мест и т.д., то есть, некими абстрактными проблемами. Фактически, в точке T1 мы просто фиксируем набор текущих проблем в компании.

Дальше происходит следующее – если мы вообще ничего не делаем, то проходит какое-то время, и наступает некое другое состояние, которое отражается в точке Т2. Что будет с компанией? Можно предположить, что будет через три месяца, если у вас около дома поставят пивной ларек? Тут все зависит от того, как мы запроектируем – либо это будут бутылки, бычки и алкоголики, либо директор ларька будет давать деньги на озеленение, и это будет хорошо ухоженная площадка. Здесь то же самое: проект может сложиться по-разному, но мы точно можем сказать, что если мы ничего не станем делать, будет плохо. Такое естественное ухудшение ситуации приводит к разрыву между текущим и будущим состоянием и представляет собой проблему, которой желательно избежать.

Соответственно, бизнес воспринимает проект именно как средство устранения тех или иных проблем и как попытку ухода от естественного проблемного будущего к желаемому.

Надо отметить, что реализация проекта не всегда достигает 100% – очень многое обычно так и остается недоделанным. Но, несмотря на это, в практике выполнения IT-проектов у нас, как правило, всегда указано, что «информационная система внедрена». Это то же самое, как нас в школе на лабораторных работах учили: цель лабораторной работы – померить напряжение, соответственно результат – напряжение померено, 5 Вт. Всегда 100% результат. И здесь по аналогии: надо внедрить информационную систему – информационная система внедрена, результат 100%. Работает она при этом или не работает, приносит она компании пользу или нет – неизвестно.

Два взгляда на проект

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

• Во-первых, бизнес, который тратит деньги, всегда хочет очень четко понимать, на что они тратятся. Поэтому с точки зрения бизнеса проект обязательно должен реализовывать изменения (естественно, в лучшую сторону, уходя от проблем).
• А если посмотреть с другой стороны – что такое проект для внедренца? Читаем 79 статью гражданского кодекса, там написано, что договор подряда – это жесткая спецификация. Какие такие изменения? У нас в договоре фикспрайс – никаких изменений, что пользователь сказал, именно это и должно быть сделано – и не более того. Соответственно, любое изменение воспринимается как расстрел, потому что процедура управления изменениями в наших компаниях поставлена не очень хорошо.

Теперь о том, какие цели преследуются сторонами?

• С точки зрения заказчика, цель проекта – достичь запланированных в проектном или в экономическом основании результатов.
• А с точки зрения подрядной деятельности цель – получить деньги в соответствии с согласованной ценой.

Что является ключевым документом проекта?

• Проектно-экономическое обоснование для бизнеса.
• И договор подряда со спецификацией – для внедренца.

И, наконец, какие риски они несут в проекте?

• Риски, которые несет бизнес, это – получить меньше, чем потрачено, потерять положение на рынке, конкурентоспособность и пр.
• А с точки зрения внедренца – это не получить деньги или выплатить штраф (если уже окончательно догонят и нагнут).

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

Инструменты гибкого управления сложным проектом

Исходя из того, что с этим конфликтом интересов надо в проекте как-то работать, я расскажу о четырех основных инструментах гибкого управления сложным проектом:

• Первое – это гибкая организационная структура проекта. Что такое организационная структура и как она строится – надеюсь, вы услышите что-то новое.
• Второе – это документирование – то, что мы не любим делать. IT-шники вообще документировать ничего не любят: они умные, они считают, что документирование занимает много времени, а это время, которое можно потратить на разработку.
• Третье – это гибкое планирование работы. Тоже интересный момент. Ни один проект для бизнеса не обходится без изменений. Внутри всегда происходит много инцидентов, поэтому гибкость работы играет очень важную, существенную роль – и, конечно, стандартными механизмами это сделать достаточно тяжело, особенно если у вас проект большой.
• Ну и последнее, о чем хотелось бы рассказать, – это гибкая идеология.
  Кто-нибудь сталкивался с Российской инструментальной моделью – называется РИМ-III? Чувствую, даже не слышали.
  А PMBoK знаете? А Prince2? А P2M? А FW немецкую?
  Кстати, все знают, что PMBoK не является технологией? Это – ящик с инструментами, на первом листе которого написано – «Риски, связанные с применением тех или иных инструментов PMBoK несет руководитель проекта». А вот, например, PRINCE2 – это уже процессная технология в чистом виде.
  Так вот – Prince2, P2M, FW – это все самые основные технологии, которые применяются в мире, но, тем не менее, немного по-разному воспринимают проектную деятельность.
  А я вам сегодня немного расскажу про РИМ-III – это «Российская инструментальная модель». Интересная штучка.

Гибкая организационная структура

«У нас в России все только людьми можно сделать и всякое дело надобно держать, не отпуская ни на минуту: как только отпустишь его в той мысли, что все идет само собой, так дело разоряется, люди распускаются и расходятся» – писал в 1927 году обер-прокурор Синода К.П.Победоносцев.

Согласитесь, что с тех пор ничего не изменилось. Управление проектами – это управление людьми. 80% времени руководитель проекта тратит на коммуникации. И от того, какая это будет коммуникация (внутри команды, с заказчиком, либо с исполнителем), будет зависеть успешность вашего проекта.

Давайте попытаемся разобраться, кто является основой проектной команды:

• У нас есть бизнес, который хочет получить какую-то выгоду, перейти из одного состояния в другое. Для этого он делает какой-то набор мероприятий, в том числе – внедрение информационных систем, организационные перепланирования, перепрофилирование процессов, реинжиниринг и пр. Бизнес заинтересован в выгодах.
• Есть пользователи. В чем заключается их роль? Пользователи ставят основные требования. И когда вы делаете (или пишете вместе с заказчиком) техническое задание, вы разговариваете с пользователями, потому что именно на них возложена задача перевести бизнес из одного состояния в другое. И, поскольку пользователи формируют технические требования к проекту, то, соответственно, они же должны и являться приемщиками – никто кроме них функциональность решения (в том числе юзабилити интерфейса) не проверит.
• Также есть третья составляющая – так называемый поставщик  – тот, кто предоставляет решение. Для меня как для заказчика поставщиком является IT-подразделение, которое у меня находится. Понятно, что у IT-подразделения кроме этого есть еще и внешний поставщик, который будет привозить, устанавливать, модифицировать и запускать ту или иную «коробку».

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

Кстати, технология организации проектной команды подробно описана в PRINCE2 – кому будет интересно, потом можете взять стандарт и почитать.

Как это происходит в жизни? Дальше будет немного картинок из реальной практики. Буду их объяснять. Здесь на слайде, собственно, изображена организационная структура проекта:

• Первый уровень – тактический – это уровень бизнеса. Есть еще «нулевой уровень» – стратегический, но это, как правило, уже группа процессов, связанная с компаниями, у которых есть проектный офис, и группа процессов, связанная с проектным офисом – мы это сейчас не рассматриваем.
  Итак, первый уровень – тактический. Это – куратор проекта, тот человек, который стартует проект, акцептует деньги и т.д.
• Второй уровень – это уровень управляющего комитета проекта. Это те люди, которые принимают решения об изменениях проекта, либо о приемке тех или иных результатов (этапов проекта) и перевода их на следующий этап, либо об изменениях, связанных с проектом (изменениях по времени, по деньгам).
• И третий уровень – операционный. Фактически, это уровень рабочих групп. Их может быть достаточно много. Туда же входят всякие администраторы проектов, группы качества и т.д.

Обратите внимание, что на оперативном уровне мы можем выделить три роли:

• У нас есть старший пользователь (он входит в УКП) – тот, кто представляет всех пользователей и отвечает за выделение рабочего времени ключевых специалистов для составления технических заданий (эти же ключевые специалисты потом участвуют при приемке, тестировании, опытно-промышленной эксплуатации).
• Есть блок, связанный с бизнесом, который представляет единое ответственное лицо – знаете такой термин? Это, фактически, представитель куратора, которому делегируется непосредственное участие в управляющем комитете от куратора (у нас его еще называют «Смотрящий»).
• Ну и, наконец, «Старший поставщик» - это руководитель IT-подразделения. Именно он несет ответственность за выбор решения, его закупку, инсталляцию, модификацию и пр.

Вот как это выглядит в настоящем проекте. На слайде – картинка с реальной презентации kick-off одного из проектов, которые у меня были. Кто не знает, kick-off – это сбор всей команды, на котором всем объясняется их роль и зона ответственности в проекте.

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

И здесь тоже обозначены те самые три роли, которые мы выделяли – соответственно, организационная структура в данном случае сбалансирована.

Что интересного здесь нужно сказать?

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

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

Что позволяет грамотное распределение организационной структуры?

• Конечно, оно позволяет оптимально составить проектную группу – утвердить оптимально необходимое минимальное количество людей, которые будут общаться, коммуницировать, принимать единые для всех решения. Мы же понимаем, что если два человека могут договориться, то семь человек – уже с трудом (особенно в рамках организации), а если их двенадцать, то их вообще надо еще постараться собрать в одно время и в одном месте.
• Минимизировать состав управляющего комитета,
• Распределить ответственность в проекте – ни один проект не обходится без матрицы ответственности.
• А также необходимо построить сквозной контроль, а когда у нас есть четко выделенные люди с четкой ответственностью, тогда и контроль строится достаточно просто.

Гибкое документирование

Теперь немного о документах.

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

У нас нет такой культуры соблюдения порядка, как в Германии, у нас нет такой проектной культуры, как в США, у нас тем более нет такой восточной культуры, как в Японии. Поэтому мы, снижая свои трудозатраты (а иногда и просто потому, что нам лениво), ничего не документируем, пока нас не заставят – нам самим это не нужно.

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

• У нас обязательно должна быть группа документов, в которых определяется, каким образом выполняется проект (она на данном рисунке нарисована сверху). В структуре, где я работаю, в качестве этих документов выступают:
  • политика управления проектами,
  • основополагающий стандарт по управлению проектами,
  • стандарт управления ИТ-проектами,
  • и прочие стандарты управления проектами – инвестиционными, строительными – их там целый набор. Все они друг от друга чем-то отличаются: набором необходимых документов, требований и т.д.
  • Есть еще связанные документы – всякие матрицы, правила, которые помогают в работе (например, методики расчета проектных премий).

Это – стандарты компании. Руководитель проекта обязан использовать их в своей работе, потому что они регламентируют тот состав документов, который будет заполняться на самом проекте.

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

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

Если смотреть уже на состав тех документов, которые должны использоваться внутри проекта, то у нас для этого есть ГОСТ.

Вы наверняка уже сталкивались с тем, что кроме PMBoK у нас есть его упрощенная модификация, которая в российской версии выглядит как ГОСТ 21.500. Там все примерно то же самое, что и в PMBoK, только половина вырезана, чтобы немного облегчить понимание.

Что представляет собой ГОСТ 21.500? Там описаны группы стандартных процессов по проекту (инициация, планирование, исполнение, контроль, завершение) и целый набор обязательных документов по этим процессам.

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

Соответственно, количество вот этих документов начинает расти.

По ГОСТ их 43, не считая итераций, которые могут быть запущены внутри проекта. Кто-нибудь столько документов когда-нибудь видел в одном проекте? А я с этим работаю.

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

А для чего вообще нужны документы?

• Понятно, что документы нужны для того, чтобы что-то в них фиксировать (чтобы не забывать)
• Также документы нужны для контроля.
• Но самое главное – документы нужны для того, чтобы минимизировать риски на проекте. Если мы не делаем документы, мы рисками не занимаемся. Например, если два аксакала встретились, поговорили и не написали протокол – значит, они время потратили зря, потому что потом никто никому ничего не докажет.

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

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

• Обязательный или рекомендательный,
• Создается или актуализируется
• Указано, где брать шаблоны этих документов
• И стоят плюсики о том, где используется документ - в простом, среднем или сложном проекте.

Итого в зависимости от сложности проекта получается 39, 63 или 67 обязательных документов, которые должны быть заполнены. Вот какая гора. И это все нужно каким-то образом делать.

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

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

Гибкое планирование

Как вы видите, еще Петр I говорил о важности и целесообразности качественной работы в проектах.

Для того чтобы контролировать проект, необходимо использовать несколько правил. Я выделил три основных:

• Для контроля реализации проекта руководству необходимо фокусироваться на главных результатах, а значит, нужно построить контрольные точки верхнего уровня. Это те контрольные точки, которые интересны бизнесу, для понимания, когда что происходит, чтобы проконтролировать.
• Второе – надо управлять будущим, а не смотреть на уже случившийся факт. Для этого мы должны пытаться заранее планировать контрольные точки второго уровня, а значит, в перспективе на два-три-четыре месяца задавать исполнителям вопрос, насколько вероятно исполнение той или иной контрольной точки вовремя. Тем самым мы существенно повышаем вероятность выполнения проекта.
• И третье – контрольные точки для исполнителей проекта должны быть мотиватором.
  Мы же все знаем синдром студента – сколько нам ни пиши в диаграмме Ганта дату, когда должно быть начато выполнение задачи, мы же все равно будем ее делать в последний момент. Я от планирования работ по этапам отказался и не очень сильно жалею. Понятно, что исполнители делают для меня в Project все свои СДР-ки, но я (да и вообще весь крупный бизнес) все свои проекты контролирую именно с помощью контрольных точек. Это просто, удобно и всегда показывает «хвост». Зато все мотивированы.
  Это выглядит так – у тебя персонально в статус-листе переписаны все контрольные точки от начала до конца проекта, и ты по ним должен каждую неделю отчитываться по вероятности их наступления. И когда у тебя зеленая, зеленая, зеленая, а потом, бах – красная, то тебе начинают задавать много вопросов – как же ты так работал, что у тебя так все неожиданно покраснело. Хороший инструмент.

Какие есть плюсы управления проектом по контрольным точкам:

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

Контрольные точки делятся на несколько уровней – эти уровни показаны на слайде.

В этой таблице показан типовой набор контрольных точек для моих ИТ-проектов – всего здесь 105 релевантных точек. Для каждой контрольной точки указаны параметры:

• Уровень – первый, второй, третий (уровень бизнеса, уровень руководителя проекта и уровень рабочих групп).
• Дано описание контрольной точки – что должно произойти (документы или какие-то события).
• И показана ответственность за выполнение данной контрольной точки по ролям (матрица ответственности проектных ролей).

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

Соответственно, каким образом выстраиваются эти контрольные точки?

• На верхнем уровне у нас определены контрольные точки для управляющих комитетов, которые переводят этапы проекта из одного состояния в другое. Эти переходы управляются инструментами PMBOK.
• Далее идет уровень руководителей проектов и рабочих групп – и здесь мы уже руководствуемся процессной технологией PRINCE2. В результате получается не плоская структура контрольных точек, а вертикальная: мы задействуем не только контрольные точки верхнего уровня (которые изображены на этом рисунке красным цветом), мы опираемся также и на контрольные точки второго уровня (они обозначены синим), и на контрольные точки третьего уровня (сиреневым). Соответственно, если у меня где-то стоит контрольная точка верхнего уровня, то у нее есть, как минимум, две-три контрольные точки нижних уровней, которые распределены по сотрудникам. И для того, чтобы моя контрольная точка состоялась, те три должны выполниться.
• А на уровне пакета работ на разработке, там, где нужно непосредственное участие пользователя и идет быстрый обмен информацией, – там у нас используется методика Agile.

Управление проектом – штука вероятностная. Мы не знаем, какой инцидент произойдет завтра. Инциденты начинают множиться. У нас есть инцидент, и есть его причина.

• Японцы в своем P2M говорят о том, что надо устранять причину – выявили, подумали, как этого больше не допустить, идем дальше. Следующий инцидент – опять подумали, как не допустить, и т.д.
• Американская модель: инцидент – решаем, инцидент – решаем. Главный акцент на быстрое устранение выявленных инцидентов.
• А российская модель: инцидент – ну и ладно. А дальше инциденты начинают множиться, связываться, и получается лавинообразный эффект, который приводит к катастрофе. Соответственно, главная задача управления проектом в России – это не допустить пожара и просчитать вероятность того или иного инцидента. Каким образом это можно сделать? Надо назначить контрольную точку, которая у тебя будет через три месяца, и каждый день спрашивать – ты помнишь, что у тебя там? Успеваешь? И если человек честно говорит тебе, что не успевает – значит, ему нужна помощь, и нужно постараться успеть вовремя спасти ситуацию.

Гибкая идеология – Российская инструментальная модель

Немного расскажу про РИМ-III.

Некоторое время назад (в 2000-х годах) Александр Прохоров выпустил книгу «Русская модель управления». Выводы, сделанные в книге, легли в основу идеологии РИМ-III.

Вообще, если вы просто в интернете наберете «РИМ-III», то попадете на страничку Павла Алферова (РАО ЕЭС), который года два назад начал формировать идеологию, которая называется «Российская инструментальная модель». Павел в то время работал в спорткомитете Сочи 2014 - был руководителем проектного офиса. Понятно, что уровень этого проекта и подчиненных внутри него просто космический, грандиозный. Количество контрольных точек, которые он использовал в своих проектах, у него было намного больше, чем 700. 700 точек в Excel не управляется – это невозможно, уже необходим специальный инструмент. У меня 105-110 – это предел для Excel, предел мозга и глаз. А у Павла было примерно в 5-6 раз больше, чем даже 700 точек. Поэтому он искал инструменты, которые реально работают на проектах, такие, которые позволяли бы построить контроль и снизить риски в этих условиях информационной перегрузки.

****************

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2015 CONNECTION 15-17 октября 2015 года.

Приглашаем вас на новую конференцию INFOSTART EVENT 2019 INCEPTION.