74
реализовывают замысел проекта. В зависимости от масштабов, типа и сложности
проекта, в нем могут участвовать от одного до десятка предприятий. Каждый
имеет собственную степень и перечень функций, применяемых на определенном
этапе ЖЦ проекта. Все без исключения участники проекта, исходя из
выполняемых функций, объединяются в определенные категории. Основными
участниками проекта считаются [9]:
1. Инициатор - автор идеи проекта.
2. Заказчик - является главным участником проекта, и в будущем
владельцем и/ или пользователем проекта. Заказчиком может быть и физическое,
и юридическое лицо. Стоит отметить, что заказчиком может являться одно или
несколько предприятий, консолидирующих интересы и средства в реализацию
проекта и его результаты.
3. Инвестор – тот, кто предоставляет материальные средства. В иных
случаях ним может являться заказчик. Если инвестор и заказчик не одна и та же
особа, между ними подписывается договор. Инвестор производит контроль над
выполнением условий, а также производит расчет с участниками проекта.
4. Проектировщики - лица или организации, создающие проектно- сметную
документацию.
5. Поставщики - предприятия, отвечающие за материальное и техническое
обеспечение проекта.
6. Подрядчики – лица или организации, привлекаемые в проект для
выполнения определенных работ. Подрядчики могут быть генеральными или
субподрядчиками.
При осуществлении проекта особое место отводится руководителю проекта
(менеджеру). Им может юр. или физ. лицо, обладающее полномочиями по
управлению проектом. Менеджер выполняет планирование, контролирование и
координацию работы других участников проекта [20].
Менеджер также управляет командой проекта - структурой,
организованной на период выполнения проекта. Основной целью команды
является эффективное достижение целей проекта.
К участникам проекта относится более широкая категория лиц, в отличие
от команды проекта.
75
Команда проекта - группа лиц (специалистов), задействованных в
осуществлении проекта. Она создается на период работы над проектом для
реализации основных его целей, и распускается в момент его завершения.
Численный и профессиональный состав команды может изменяться в период
выполнения проекта. В рамках команды определяются роли - абстрактные
группы участников проекта, объединенные общими интересами или задачами.
Основные типы проектов ИТ [9]:
- Проекты для разработки и развития ПО;
- Проекты для внедрения автоматизированных ИС;
- Организационные и инфраструктурные проекты.
Управление проектами в сфере ИТ - вид руководящей деятельности,
основанный на планировании и реализации проекта в сжатые сроки,
определенным бюджетом и качеством выполнения [9].
Эффективные средства и технологии, высококлассные разработчики,
достаточная материально-техническая база - все это необходимо для успешного
создания ИТ-проекта. Во время реализации проекта руководство компании
должно произвести четкие организационные мероприятия по применению ИТ, а
также организовать плодотворную деятельность команды, работающей над
проектом. Выполнение проекта в поставленные временные рамки, при этом, не
выходя за лимиты бюджета, принесет для предприятия уникальный опыт в сфере
организации комплексных проектов и поможет переосмыслить роль ИТ в ведении
бизнеса.
Объединение ролей в проектной команде представлено на рис. 12.
76
Рисунок 12 Объединение ролей в проектной команде
2.2.3 Средства коллективной работы над проектом
автоматизации
Невзирая на достаточно долгую продолжительность успешного
использования во всевозможных проектах, большая часть менеджеров до
сегодняшнего дня скептически относятся к agile методологии и отдают
предпочтение традиционным методам. Такую позицию можно частично
обосновать: все проекты считаются уникальными и требуют различного подхода.
Во всевозможных обстоятельствах наиболее эффективным может
считаться традиционный подход, в некоторых же – гибкий. В типовом проекте с
легко достижимой и ясной целью традиционный подход будет проще и
эффективнее, поскольку изменения в последующем маловероятны. В ситуациях,
когда что-нибудь неизвестно, возникает неопределённость. Традиционный
подход будет не очень эффективным в такой ситуации: возрастают риски,
поскольку стоимость изменения чрезвычайно высока. В обстоятельствах
неопределённости цели, либо пути, либо всего сообща, гибкие методологии
показывают себя лучше, поскольку поддерживают изменения на всех без
исключения стадиях и в самом начале не требуют абсолютного понимания
конечного результата. Команда совместно с заказчиком может достичь
необходимого результата при создании, что существенно понижает риск
получения мало актуального продукта. Авторами статьи также отмечается, что
гибкие методологии кроме решения проблем запрашивают конкретные
требования к командам, менеджерам, предприятию. Agile предусматривает
решение большого количества задач автономными командами, следовательно,
организационная структура и руководитель обязаны это позволять, и
позаботиться о конкретной зрелости такой команды.
Если менеджер, который до этого применял традиционную методологию в
процессе работы, решил использовать гибкий подход в очередном проекте,
возникает ключевой вопрос, каким факторам стоит уделить внимание ему и его
команде. Имеется множество аспектов, которые, бесспорно, нельзя исключить, но
для эффективного использования новой методологии немаловажно понимать, на
которых стоит акцентировать максимальное внимание. При этом в Agile Manifesto
немаловажные принципы напротив описаны излишне абстрактно и
77
непосредственно в работе считаются не применимыми. С целью будущего
использования требуются наиболее конкретные рекомендации.
Введение новой методологии считается сложным процессом, который
зачастую может сопровождаться различными проблемами: сопротивление
сотрудников, неготовность персонала и др. Выше было отмечено, что
идентифицированные КФУ является чертой предприятия, на котором гибкие
методологии внедрены в полном объеме в рабочий процесс и культуру. В
обратном случае, достичь успеха чрезвычайно сложно. По этой причине одна из
основных задач менеджера проекта заключается во внедрении методологи на
предприятии и в команду [20].
В концепции управления проектами существенное место отводится оценке
зрелости предприятия, а также построению корпоративной системы по
управлению проектами. Главная идея состоит в том, что предприятие стремится
постепенно к полноценному введению управления проектами, поскольку
невозможно осуществление многих инструментов, если предприятие ещё не
готово к этому. Аналогичный подход необходимо использовать и к гибким
методологиям. Мгновенно невозможно перестроить команды и сотрудников,
чтобы они отвечали agile подходу. Предприятиям и командам требуется время,
чтобы постепенно понять не только определённые процедуры и процессы,
происходящие в проекте, который использует гибкий подход, но и
фундаментальные принципы. Предприятие может начать применять конкретную
методологию, впрочем, это не будет означать, что она введена: интегрирована в
систему убеждений и ценностей, рабочих практик сотрудников [9].
Затруднительность перехода на новейшую методологию варьируется от
предприятия к предприятию и зависит от большого количества факторов.
Менеджер обязан обратить особенное внимание на обучение команды передовым
методикам, донесение ценности инновационной методологии до команды,
ресурсную поддержку внедрения, апробацию новейшего подхода [9].
Для эффективного введения гибких методологий требуется необходимое
количество работников 2 и 3 категории. Если на предприятии большая часть
негибких работников 1В, то внедрение agile подхода считается рискованным.
Необходимо рассмотреть плановый, или гибридный подход, которым
78
предполагается наиболее формализованное и основательное планирование.
Следует также подметить, что этот подход, наиболее соответствующий
отечественной организационной культуре [20].
Гибкие методологии по управлению проектами, которые базируются на
формировании бизнес - ценности для заказчика при постепенной итеративной
разработке продукта надежно вошли в проекты в области IT. Доказана их
эффективность в условиях неопределённости, которой сопровождается бизнес
сегодняшнего времени.
Выполненное исследование разбито на 4 стадии:
Подготовительная стадия;
Стадия сбора информации;
Стадия анализа приобретенной информации;
Формулировка рекомендаций.
На подготовительной стадии проведен первоначальный анализ проблемной
ситуации: выполнен обзор зарубежных и российских публикаций, относящиеся к
данной теме. Также проведено неструктурированное интервью трех менеджеров
проектов в сфере IT, которые имеют опыт работы с Agile. Итогом данной стадии
явилась формулирование гипотез изыскания и создание вопросника для сбора
информации в дистанционном режиме.
На втором этапе изыскания осуществлялся сбор информации при помощи
дистанционного опроса экспертов из сферы IT посредством интернета. С этой
целью опросник, который был создан на предшествующем этапе, размещался в
группах социальных сетей, на тематических форумах с применением сервиса
Google Docs.
Анализировалась полученная информация при помощи SPSS. Особое
внимание обращалось на анализ корреляций и построение регрессионных
моделей.
На стадии формулирования рекомендаций была осуществлена подготовка
методических рекомендаций для практиков по управлению проектами. Учтены
главные КФУ, которые считаются актуальными для России. Даны конкретные
предложения для разнообразных сфер знаний.
В отечественной практике управления проектами agile методологии по
79
разработке проектов интернет – вещей, до настоящего времени считаются для
большинства менеджеров чем-то непонятным и новым. Одним из прикладных
итогов предоставленной работы считается формулирование обнаружение
факторов, которые наиболее важные для управления проектами по разработке
интернет – вещей. Результаты считаются интересными и менеджерам проектов
отечественных предприятий, которые с agile методологиями уже работают, и тем,
кто только намеревается. В основу модели КФУ положена гипотеза, что
успешность, к примеру, проекта, главным образом, зависит от отдельных
наиболее значительных факторов. Как показывает исследование, в РФ для
эффективной работы с agile для команды считаются важными [20]:
Оперативное принятие решений;
Качественный контроль деятельности команды;
Ориентация на заказчика (потребителя).
Разберем детальнее определенные ситуации, в которых могут
использоваться КФУ, которые идентифицированы в процессе исследования.
Ориентирование на удовлетворение потребителя – один из основных
принципов Agile. эффективное введение методологии считается единственным
вариантом, чтобы данный принцип привить команде.
Внедрение гибких методологий по разработке интернет - вещей в
конкретном предприятии комплексный и сложный процесс. Основное различие
от введения корпоративной системы по управлению проектами состоит в том, что
agile является, прежде всего, системой принципов и ценностей, чем конкретной
методологией. Необходимо понимать, что практики и методики гибких
методологий, к примеру, scrum немаловажны, но более сложным считается ввести
основы agile в корпоративную культуру предприятия. Собственно, тогда такой
подход заработает в полном объеме.
При осуществлении в жизнь таких комплексных и серьёзных изменений
полезным инструментом станет цикл Шухарта (Деминга) PDCA. Идея цикла
содержит в 4 фазы [20]:
Планирование;
Реализация;
Проверка;
80
Корректировка.
Следовательно, переход на гибкие методологи можно представить таким
алгоритмом. Менеджером анализируется текущая ситуация на предприятия,
исследуются процедуры реализации продукта. Потом на основании
приобретенных данных вырабатывается план, какие подходы следует применить
для решения обнаруженных проблем (для каждого предприятия план будет
персональный). Далее выполняется постепенное осуществление разработанного
плана. Очередной этап заключается в проверке, насколько предложения оказались
успешными, насколько отклонение от плана было сильным. По результатам
данного этапа план корректируется [9].
Этот цикл несколько раз повторяется, поскольку внедрение является
достаточно долгим процессом. Это дает возможность выполнять изменения
небольшими шагами, стабильно контролируя итоги и направляя процесс.
Введения часто сопоставляют с японской теорией Shu Ha Ri, которая
пришла из боевых искусств. Ею определяются три этапа мастерства, обучения [9]:
Shu – «Соблюдать». Первый этап, которым предполагается строгое
соблюдение методологии, работе «по книжке»;
Ha – «Прорываться». Второй этап, предполагающий отступление от
традиций и правил, их нарушение. Предполагается понимание методологии, а
также её адаптация для определенной ситуации;
Ri – «Отделяться». Третий и наивысший этап, предполагающий
отделение, отступление от практик и принципов, формирование новых,
собственных.
Предприятие должно пройти все стадии, постепенно совершенствоваться и
познавать agile. Результатом будет считаться выход за границы определенных
методологий Kanban, Scrum и остальных, построение уникальной, собственной
методологии, системы практик и ценностей [20].
На практике такую непростую задачу зачастую решают посторонние agile
консультанты, которые для этого проводят тренинги и организовывают пилотные
проекты и команды. Процесс проходит постепенно, однако, в случае
положительного исхода, с течением времени включается все предприятие.
Единого рецепта по введению гибких методологий по разработке интернет -
81
вещей не существует, поскольку каждое предприятие уникально собственной
корпоративной культурой, масштабность и остальными параметрами, которые
оказывают очень серьёзное влияние на внедрение [20].
Впрочем, имеется ряд инструментов, которые окажут помощь команде и
предприятию в случае перехода на гибкие методологии.
Представителем таких инструментов считается нулевая итерация (iteration
zero). Этот подход состоит в применении первой итерации не с целью разработки,
а с целью предварительной подготовки. В процессе перехода с традиционной
методологии на гибкие методологии по разработке интернет - вещей данная
итерация используется, чтобы перевести привычный план в backlog проект,
являющийся списком необходимых технических свойств и заданий проекта на
текущий момент. По итогам нулевой итерации законченный продукт не
вырабатывается, а создаются достаточные и необходимые и условия для начала
реализации. Этот метод не следует воспринимать в качестве полноценной
проработки и планирования как в традиционной методологии. В этом случае все
приготовления заключаются в минимально необходимых действиях, поскольку
все изменится в процессе осуществления проекта. С течением времени команда
может постепенно уменьшать продолжительность нулевой итерации до того
момента, когда сможет полностью отказаться от неё [20].
Ретроспектива считается одной из основ agile методологий, однако на
стадии внедрения с ней, обычно, появляются проблемы: команда в недостаточной
степени открыта, ей не понятна польза этого процесса. Усложняется это
индивидуальными особенностями некоторых членов – они по характеру могут
быть замкнутыми. В таком случае менеджеру необходимо команду вывести на
разговор. Для этого имеются некоторые техники.
Молчаливой ретроспективой предполагается запись отрицательных
и положительных факторов итерации на «стикерах» любым членом команды.
Потом обсуждают каждую запись. Это дает возможность высказать свое мнение
даже наиболее замкнутым участвующим, привлечь их в обсуждение вопроса.
Смена ролей представляет собой передачу права ведения
ретроспективы кому-либо из участников команды. Этот способ дает участникам
возможность лучше осмыслить процесс, повысить заинтересовать, увеличить
82
стремление к результату, поскольку они также частично несут ответственность за
него.
Результатами исследования подтвердилась связь успешности agile проекта
и использования качественных способов контроля.
В agile методологиях, обычно, оценка и контроль работы команды
осуществляется в процессе ретроспективы. После каждой итерации
осуществляется первоначальная ретроспектива. В это время вся команда
собирается, для разбора результатов итерации, выявления проблем и определения
методов их решения. Впрочем, на практике зачастую получается, что провести
ретроспективу в конце затруднительно: у команды слишком мало времени,
многие проблемы были решены еще в процессе итерации. Поэтому изредка
наиболее подходящим считается подход, применяющийся многими agile
консультантами и практикующими менеджерами – непрерывной (continuous)
ретроспективы. Главная суть данного подхода к ретроспективе заключается в
переносе процесса на каждодневные «stand-up» собрания: визуализации каким-
либо методом проблемы и процессе реализации, и решении их на месте. Имеется
большое количество различных методов визуализации, наиболее
примечательными считаются – Доска идей, Value stream mapping.
VSM (Value stream mapping) – метод, пришедший из lean management.
Метод является некоторой схемой этапов и событий, которые проходит продукт,
прежде чем поступит к потребителю. Этот метод предоставляет возможность
визуализации процесса формирования бизнес - ценности продукта. Данный
подход, как правило, применяют в производстве, впрочем, он считается хорошим
и для создания ПО. Формирование бизнес - ценности считается краеугольным
камнем гибких методологий, поэтому визуализация такого процесса
предоставляет команде превосходное понимание того, что в проекте происходит.
Достаточно «прикрепить» возникнувшую проблему к определенному месту
появления на VSM, для представления о том, какое значение имеет процесс, в
котором появилась проблем, и к каким последствиям это приведет. Располагая
такой информацией в реальном времени, можно решать проблемы на
каждодневных собраниях.
Доска идей – считается аналогом доски задач. Предоставляет возможность
83
визуализации проблем и их решений, а также реализации улучшений и
предложений аналогично задачам. Все компоненты расположены в 3 зонах:
запланировано, в исполнении, выполнено. Этот метод в отличие от VSM, не дает
возможности увидеть взаимосвязи, но обеспечивает отличную визуализацию и
упрощает контроль процесса решения проблем и введения улучшений. На
повседневных собраниях команда, совместно с задачами, обговаривает и статус
компонентов на доске идей, что позволяет помнить об улучшениях и проблемах,
не отодвигать их до завершения итерации, а решать сейчас и здесь.
Если проблема обнаружена, появляется вопрос, каким образом ее решить.
Обычно, проблемы, существующие длительное время, не просто решить быстро.
Не всегда решение находится на поверхности, изредка может затронуть интересы
других команд и лиц. В таких случаях можно воспользоваться другим
инструментом из ТОС – диаграммой разрешения конфликтов – рисунок 13.
ПрорывПервостепенная задача
Необходимое условие Метод обеспечения
Необходимое условие Метод обеспечения
Рисунок 13 Диаграмма разрешений конфликтов
Данный подход предоставляет возможность визуализации существующих
противоречий и обнаружения прорывного решения, которое может находиться на
любой стрелке из представленной схемы.
Деревом будущей реальности команде предоставляется возможность
визуализации последствий принятого решения проблемы: на самом деле ли
приобретается желаемый результат, не повлечет ли это негативные последствия.
Такой анализ дает возможность сделать ретроспективу бесспорно сильным
и полезным инструментом для команды в борьбе за улучшение и саморазвитие