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

Это большая область, мы из нее возьмем только небольшие части.

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

Мы с вами будем рассматривать следующие темы.

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

Рассмотрим жизненные циклы. По сути дела, изобретение так называемого жизненного цикла — это наш способ снизить риски и научиться управлять ими.

Характеристики проекта между собой тесно взаимосвязаны.

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

В результате проекта всегда должны быть созданы уникальные продукты.

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

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

А вот как раз создание уникального продукта или услуги накладывает определенные ограничения. Это не значит продукт или услуга прекратит свое существование, прекращает свое существование только вид деятельности под названием проект.

И третья характеристика проекта связана с последовательностью разработки. Что под этим подразумевается в виду? Здесь речь идет о том, что мы не можем создать, как акт создания Господа Бога некоторого объекта по мановению руки. То есть все, что создается в один большой и неделимый на части шаг, соответственно, не является областью управления проектами. Последовательная разработка подразумевает, что вначале у нас нет вообще ничего, то есть у нас нет продукта, который мы хотим создать, или, возможно, какая-то версия, которая сильно отличает этот продукт, и нам необходимо шаг за шагом осуществить создание целевого продукта или услуги.

Следующая часть истории связана с необходимостью управлять проектом в реальном мире. Чаще всего руководители проектов говорят о так называемом треугольнике ограничений, тесно связанным с хорошо известным изречением: быстро, дешево или качественно — выберите что-то одно.

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

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

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

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

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

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

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

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

Содержание проекта (он же Scope проекта). В рамках управления проектом мы имеем дело с двумя основными структурами.

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

Задача управления проектами осуществить планирование результатов и определить, какие материалы нам потребуются. Одна из проблемных частей, связанных с информационными системами, связана с тем, что, по сути дела, входом к проекту по созданию информационной системы является информация. То есть информация и решения, которые приняты на разных уровнях, связанных с бизнес-системой.

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

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

Кроме результатов, существуют еще определенные работы, которые должны быть сделаны.

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

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

Традиционное управление разработкой ПО было построено по схеме, аналогичной другим технологическим проектам.

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

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

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

Что, по сути дела, нужно бизнесу? Для того, чтобы спланировать свои ресурсы, бизнесу нужно планировать затраты, да? то есть, грубо говоря, он не может постоянно производить инвестиции в проект, не получая конкретного результата. И соответственно, вместо того, чтобы планировать Scope информационной системы, было произведено изменение. Начали фиксировать время и соответствующие ресурсы, которые мы выделяем (алоцируем), и строить процесс таким образом, чтобы достичь за это время максимального результата.

При этом тот результат Scope, о котором идет речь, с точки зрения проектирования самой информационной системы — является непринципиально важным. О чем идет речь?

Scope, то есть информационная система, которую мы строим, не равно результату для бизнеса, который мы создаем.

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

По сути дела, мы с вами подходим к двум парадигмам работы над системой.

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

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

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

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

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

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

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

По сути дела, проект или процесс — это всего-навсего две различных точки зрения на одно и то же явление.

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

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

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

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

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

Давайте более подробно разберемся, в чем состоит проблема.

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

Однако в данной ситуации у нас появляется с вами некоторое недопонимание или что называется misuse терминов. Если у нас с вами есть некоторый объект, в рамках которого мы обладаем достаточно большим комплексом знаний, умений, навыков, по сути дела, осуществляем контроль над этим объектом, говорить о том, что мы используем некоторые внутренние цели, не совсем корректно.

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

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

Нет, у нас с вами это не внутренняя цель, это objective или задача. То есть некоторые манипуляции или модификации, которые мы собираемся сделать, которые, как мы думаем, приведут к тому, чтобы достичь цели. Цель находится вне системы, и мы не контролируем ее.

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

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

Цели — это то, что находится вне зоны нашего непосредственного влияния и и которые в идеале требуют от нас некоторого напряжения для достижения.

Для чего нам необходимо такое деление?

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

Можем ли мы спрашивать с руководителя проекта или сотрудника о достижении цели? Безусловно спрашивать можем - это цель, к ней надо стремиться, но гарантии достижения цели нам уже никто дать не может.

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

Вот эта картинка имеет название Denials Map, о неопределенности, то есть от тех неизвестных, которые у нас могут быть.

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

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

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

Каким образом программа, которую мы создаем, поможет достичь соответствующей цели.

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

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

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

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

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

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

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

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

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

Вы - начинающий системный аналитик в компании "Хорошее ПО"

Руководитель проекта Быков Александр Максимович передал вам письмо от потенциального заказчика.

Запрос заказчика

Ваша задача

С учетом прочитанного материала на основе письма заказчика сформулируйте в виде небольшого письма для руководителя проекта ваши предположения о:

1. Целях этого проекта
   
2. Задачах проекта
   
3. Возможных вариантах объекта поставки
   
4. Дополнительных вопросах которые необходимо задать на первой встрече заказчику
   

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

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

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

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

При работе с рисками были замечены следующие интересные эффекты.

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

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

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

• На первоначальном этапе, когда у нас осуществляется инициация проекта, говорить о рисках проекта некорректно. То есть то, что мы делаем — мы управляем целью, то есть постановка целей и задач для проекта и есть работа с потенциальными рисками. В зависимости от целей, задач, которые мы возьмем на себя, и будут проявляться наши риски.
  
  
• На этапе формулировки требований и целей у нас с вами появляется такая дисциплина, как работа с допущениями. То есть когда мы некоторую неопределенность, то есть то, что мы не знаем, что мы не знаем, мы закрываем с помощью некоторых предположений. К примеру часто при оценке программных проектах делается предположение, что нам потребуется разработать, к примеру, пять отчетов, десять отчетов, пятнадцать отчетов. Мы не знаем, какие отчеты конкретно потребуются, но мы можем на уровне управления бюджетом, предположить, что нам потребуется такое-то количество объектов.
  
  
• Если мы с вами не заложили, соответствующие неопределенности, не проработали их на этих этапах, то область происхождения соответствующих рисковых событий попадает в саму дисциплину управления рисками. То есть мы садимся и думаем, что может пойти не так, и планируем нашу реакцию на возникновение этих событий.
  
  
• Если мы какие-то риски не отработали, не обеспечили достаточный уровень их исключения или смягчения, у нас с вами появляется область, которая называется управление проблемами, и зачастую по проекту Issues, с которыми мы вынуждены работать — это то, над чем мы не поработали на соответствующих предыдущих этапах. Либо на уровне формулировки требований, либо на уровне работы с допущениями, либо не методировали возникновение соответствующих возможных рисковых событий.
  
  

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

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

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

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

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

• Вначале существует так называемая среда разработки. То есть разработчики сами создают определенный код, его тестируют и работают с той программой, которая у них получилась, чтобы попытаться понять, а действительно ли это то, что нужно заказчику.
  
  
• Следующий кусочек — это когда мы начинаем осуществлять внедрение этого программного обеспечения для бизнеса и, соответственно, кто-то называет это implementation, кто-то называет его еще как-то, слава Богу, что на русском языке есть замечательное слово — внедрение.
  
  
• К примеру, в гибких методологиях часто используется понятие Agile scrum цикла для того, чтобы осуществлять разработку, а для того, чтобы осуществлять последний шаг и обеспечивать доступность этого решения для бизнеса, внедрение называют DevOps, или работа, необходимая для того, чтобы приложение начало работать.
  

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

О чем идет речь? Чтобы достичь большой цели, нам нужно декомпозировать ее на некоторые части и достигать ее поэтапно.

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

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

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

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

Первая контрольная точка — это так называемый Concept Of Operations. То есть когда у нас с вами готово понимание и видение того, как эта информационная система будет использована в бизнесе для того, чтобы достичь необходимого результата.

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

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

Life Cycle Architecture — это тот момент, в который включены архитектурные, то есть ключевые решения в отношении структуры, системы, взаимосвязей и функций, которые выполняют отдельные элементы, были приняты.

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

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

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

В чем состоит суть? Современная модель жизненного цикла и соответствующих вех жизненного цикла не подразумевают последовательную работу над артефактами.

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

Когда мы говорим о том, что для того, чтобы реализовать информационную систему, вначале нам нужно достичь Concept Of Operations жизнь вехи жизненного цикла, это обозначает, что мы должны сделать все необходимое для этого бизнес- моделирования, проработать все необходимые требования, осуществить проектирование с точки зрения архитектуры и, скорее всего, реализовать некоторое количество исходного кода.

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

Итак, по сути дела, современные основные вехи проекта по созданию информационной системы состоят из следующих этапов.

Инициация — то есть это начало.

Вторая часть — проектирование, проектирование технических решений, которые необходимы для реализации.

В рамках инициации мы принимаем решение с точки зрения контекста той среды, в которой мы разрабатываем систему.

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

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

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

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

Для того, чтобы углубить ваши знания по тому, каким образом строятся информационные системы, из чего состоит разработка программного обеспечения, вы можете почитать в книге Салливана «Время-деньги. Создание команды разработчиков программы обеспечения», Уокера Ройса «Управление проектами по созданию программного обеспечения».

Интересна ситуация с pmbok®. Дело в том что первые и вторые версии содержали так называемые body of knowledge, так называемые универсальные знания по управлению проектами. Однако, начиная с третьей версии, появилась чрезмерная детализация содержания этих проектов: к примеру, пятая версия содержала девять процессных областей, сорок четыре процесса и, естественно, выполнение всех этих рекомендаций и учет всех этих аспектов в рамках управления конкретным проектом технически нецелесообразный и неразумный. Соответственно, для того, чтобы познакомиться с основами управления проектами, вторая версия является замечательной, особенно, если вы читаете на английском, а вот с третьей по шестую версии вам попадется очень много таких понятий и определений, которые вам не пригодятся, если вы не занимаетесь постройкой многоэтажного строительного дома.

И последняя рекомендованная статья для углубления знаний — это «Модели жизненного цикла программного обеспечения» позволят вам лучше познакомиться с историей того, как развивались разные модели разработки программного обеспечения, и это может быть вам полезно, если вы будете строить какие-то сложные гибридные информационные системы.