45
10. Бережливая разработка. Основные принципы:
• Исключение потерь. Потерями считается всё, что не добавляет
ценности для потребителя.
• Акцент на обучении. Короткие циклы разработки, раннее
тестирование, частая обратная связь с клиентом.
• Предельно отсроченное принятие решений. Решение должно
приниматься не на основе предположений и прогнозов, а после обнаружения
существенных фактов.
• Предельно быстрая доставка заказчику. Короткие итерации.
• Мотивация команды. Нельзя рассматривать людей исключительно
как ресурс. Людям нужно нечто большее, чем просто список заданий.
• Интегрирование. Передать целостную информацию заказчику.
Стремиться к целостной архитектуре. Рефакторинг.
• Целостное видение. Стандартизация, установление отношений
между разработчиками.
RAD - rapid application development - быстрая разработка приложений -
концепция создания инструментов разработки программных продуктов
уделяющая особое внимание скорости и удобству программирования, созданию
технологического процесса, который позволяет программисту быстро создавать
компьютерные программы.
RAD предполагает, что разработка ПО осуществляется небольшой
группой разработчиков в течение примерно трех-четырех месяцев путем
использования инкрементного прототипирования с применением
инструментальных средств визуального моделирования и разработки.
Технология RAD предусматривает активное вовлечение клиента уже на
ранних этапах - обследование организации, разработка требований к системе.
Последнее из этих свойств подразумевает полное выполнение требований
заказчика как функциональных, так и нефункциональных, с учетом их
возможных изменений при разработке системы, а также получение
высококачественной документации, обеспечивающей простоту эксплуатации и
46
обслуживания системы. Таким образом, общее время от начала разработки до
получения приемлемого продукта с использованием этого метода значительно
уменьшается.
Выводы по разделу два
В данном разделе было рассмотрено:
• Жизненный цикл программного обеспечения информационной
системы, который обычно включает в себя основные, вспомогательные и
организационные процессы.
• Модели жизненного цикла программного обеспечения. Было
выявлено, что к настоящему времени наибольшее распространение получили
каскадная, спиральная и итеративная модели ЖЦ.
• Методы проектирования информационных систем. Такие как RUP,
гибкая разработка, включающая scrum, экстремальное программирование и
бережливую разработку, RAD.
При гибкой разработке наивысшим приоритетом является
удовлетворенность клиентов за счет регулярной и ранней поставки ценного
ПО. В основе методологии Scrum лежит простая идея. Когда бы ни был
запущен проект, ничто не мешает регулярно проверять ход работ и
последовательно выяснять: справляется ли команда с заданием; в правильном
ли направлении она движется; создается ли именно то, что на самом деле хочет
получить заказчик. И так же постоянно поднимать вопросы: есть ли способы
усовершенствовать методы разработки и выполнять работу наиболее
качественно и быстро; существуют ли факторы, препятствующие
поставленным задачам.
RAD позволяет создавать компьютерные программы максимально
быстро при весьма удобном программировании, при этом полностью выполняя
все требования заказчика. Разработка ПО по данной методологии ведется в
течении нескольких месяцев небольшой командой разработчиков. Также как и
при гибкой разработке, быстрая разработка подразумевает вовлечение клиента
на ранней стадии.
47
Для проекта реестр платежей выбрана методология Scrum поскольку в
основе лежит итеративный подход выполнения проекта. В отличие от
линейного (каскадного) подхода, когда проект изначально планируется «от» и
«до», а результат где-то «в конце пути», в пустую тратятся огромные средства и
который зачастую ни к чему не приводит, данный способ позволяет в короткие
сроки с минимальными затратами получить готовый продукт. Конечно, он еще
не обладает всеми требуемыми характеристиками, но его уже можно
использовать.
Важно, как можно раньше получить обратную связь от пользователей,
на основе которой производить циклическое наращивание функциональности и
совершенствование продукта. Именно данный подход позволяет оперативно
реагировать на изменения в требованиях заказчика и быстро адаптироваться к
ним.
Однако при внедрении Scrum возникали некоторые трудности. Во-
первых, предполагаемое активное участие заказчика в проекте, было не таким
активным, как хотелось бы. Не всегда удавалось добиться присутствия
заказчика на собраниях и получения адекватной обратной связи от него. Во-
вторых требующаяся слаженная командная работа, началась только после
небольшой «притирки» участников команды. Какие-то идеи и инструменты
были применены частично, что тоже принесло свои плоды. Выявлена причина
успеха методики, следует смотреть на то как люди на самом деле работают, а не
слушать, что они говорят об этом.
На сегодняшний день Scrum - хорошо проработанная методология. Она
уже прочно закрепилась в управленческом арсенале большинства
технологичных компаний мира. Популярность Scrum растет с каждым днем, в
том числе в нашей стране.
48
Глава 3. Исследование стадий жизненного цикла проекта реестра
платежей для ООО «Adidas groop»
3.1. Характеристика фаз, стадий и этапов проекта реестра платежей для
ООО «Adidas groop»
С целью повышения эффективности планирования и распределения
денежных средств поставщикам было принято решение о начале проекта реестр
платежей.
Описание текущей ситуации («как есть»):
Планирование платежей включает 2 уровня:
• Долгосрочное планирование - платежный календарь, формируется в
ручном режиме в MS EXCEL силами финансового отдела для планирование
платежей на месяц (квартал, год).
• Оперативное планирование - реестр платежей (реестр заявок на
оплату), формируется в КИС ЧТПЗ, но работа ведется в ручном режиме с
использованием «режима комментариев» к заявкам на оплату.
Ручное планирование платежей имеет ряд недостатков:
• Высокая трудоемкость:
1. Сложность долгосрочного планирования - используются оценки, а
не фактические документы;
2. Сложность оперативного планирования - до 1000 писем изменений
относительно первоначального плана платежей;
• Человеческий фактор:
1. Ошибки при планировании;
2. Субъективное принятие решения (в части формирования заявок на
оплату).
Существующая система планирования платежей не позволяет
оперативно планировать платежи, а также применять единую логику
распределения денежных средств между поставщиками и подрядчиками.
49
Описание ситуации «как надо»:
Долгосрочное планирование - необходимо перейти от ручного
планирования к автоматическому формированию будущих платежей,
платежного календаря.
Оперативное планирование - необходимо повысить оперативность
принятия решения путем создания алгоритма распределения денежных средств.
Таким образом, предлагаемая система позволит оптимизировать
планирование платежей:
• повысит оперативность планирования;
• повысит точность планирования.
Внешнее решение по оперативному планированию платежей (реестр
платежей) является независимым от платформы (от КИС ЧТПЗ) и будет
актуальным в случае смены платформы.
Для поддержки - и повышения эффективности исполнения процессов
управления проектами на ПАО «ЧТПЗ» создана Корпоративная система
управления проектами (далее - КСУП). КСУП - это комплекс организационных,
методических, технических, программных и информационных средств.
В ее обязанности входит организация и контроль достижения целей
проектов Группы, при соблюдении ограничений по срокам, бюджету, качеству
и выполнении иных требований, предъявляемых руководством ЧТПЗ к
реализуемым проектам.
Разграничение проектной и процессной (функциональной) деятельности
(как правило, регулярной деятельности, выполняемой в рамках должностных
обязанностей) необходимо для эффективного функционирования Группы в
целом и системы КСУП в частности.
Важным фактором успеха разграничения проектной и процессной
(функциональной) деятельности является четкое определение границ проектной
деятельности.
Для повышения управляемости и прозрачности проект разделяется на
ряд отдельных фаз, совместно составляющих жизненный цикл управления
50
проектом (далее - жизненный цикл проекта).
Определены следующие типовые фазы жизненного цикла проекта:
• Фаза 1. Концепция.
• Фаза 2. Разработка.
• Фаза 3. Реализация.
• Фаза 4. Завершение.
Набор фаз жизненного цикла проекта (все или некоторые из
перечисленных), состав задач и участников отдельных фаз зависит от вида и
класса проекта. Переход проекта на следующую фазу осуществляется на
основании решения Проектного комитета.
Классификация проектов предполагает разделение проектов на виды и
классы, которые вводятся с целью установления единой системы для Г руппы и
дивизионов, а также для повышения эффективности работы с проектами на
всех фазах их жизненного цикла.
4.1 Определение вида и класса проекта
Вид проекта - первичный критерий, отражающий основную сферу
деятельности, в рамках которой осуществляется проект.
Вид проекта определяется на основании его цели/целей и предметной
области, в которой осуществляется проект. При наличии нескольких целей
проекта и предметных областей вид проекта определяется на основании его
главной цели / предметной области.
Вид проекта определяется на фазе «Концепция» Офисом управления
проектами (далее - ОУП) и утверждается Проектным комитетом. При
необходимости вид проекта может быть пересмотрен по решению Проектного
комитета. Решения о смене вида проекта, принимаемые субъектами
корпоративной системы управления проектами уровня Группы, являются
обязательными для исполнения для субъектов дивизионального уровня. В
таблице 6 выделены виды проектов.
51
Таблица 6
Виды проектов
Вид
Описание
Инвестиционный
Проекты, направленные на вложение капитала
(инвестирование) в расширение или совершенствование
основных фондов Группы и/или отдельного дивизиона.
Инновационный
Проекты, включающие объекты творческой деятельности,
изобретения, открытия, которые воздействуют на
производительность и конкурентоспособность Группы,
дивизиона, продукта.
Организационны
й
Проекты, направленные на оптимизацию деятельности
Группы и дивизионов и их функционирования в условиях
рынка (процессов и процедур), в том числе проекты по
изменению структуры управления Группы, массовой
разработке (корректировке) комплектов организационных
документов, регламентирующих деятельность отдельных
должностных лиц и подразделений, внедрению систем
управления, оптимизации бизнес-процессов.
Социальный
Проекты, направленные на создание материально-духовных
ценностей, целью которых является поддержание и
повышение качества жизни работников предприятий
Группы, их семей и общества в целом.
Коммерческий
Проекты, реализуемые в рамках коммерческой
деятельности, целью которых является развитие
предложения клиентам продуктов и/или услуг.
ИТ-проект
Проекты, направленные на разработку, внедрение и/или
улучшение программных продуктов, корпоративной ИТ-
инфраструктуры.
Специальный
Проекты, которые не относятся ни к одному из
определенных выше видов проектов.
Проект по разработке ПО реестр платежей относится к виду ИТ-проекта.
Вторичный (после вида проекта) критерий, отражающий уровень
сложности и важности проекта.
Класс проекта определяется на основании дерева решений для каждого
из видов проектов.
Параметры, используемые для определения класса проекта, включают
параметры, общие для всех видов проектов, и дополнительные
параметры для отдельных видов проектов.
Параметры, общие для всех видов проектов, включают:
• профильность проекта;
• кросс-дивизиональность проекта;
52
• объем инвестиций в рамках проекта / бюджет проекта.
Дополнительные параметры для отдельных видов проектов включают:
• масштаб влияния (для организационных проектов), отражает влияние
результатов проекта на бизнес-процессы и оргструктуру;
• уровень вовлечения (для социальных и коммерческих проектов),
отражает вовлечение внешних сторон - органов власти и субъектов
коммерческой деятельности;
• планируемый объем реализации (выручки) (для коммерческих
проектов).
По решению ОУП Группы для определения класса проекта может быть
использован иной подход.
Класс проекта определяется на фазе «Концепция» ОУП и утверждается
Проектным комитетом. При необходимости класс проекта может быть
пересмотрен по решению Проектного комитета. Решения о смене класса
проекта, принимаемые субъектами КСУП уровня Группы, являются
обязательными для исполнения для субъектов дивизионального уровня.
Класс проекта используется для выбора подхода к управлению проектом
- определения модели управления проектом.
Выделяются пять классов проектов с учетом принятых видов проектов:
Класс А. Непрофильные проекты Группы.
• Класс Б. Профильные сложные проекты и/или кросс-дивизиональные
проекты.
• Класс В. Профильные средние проекты и/или проекты, реализуемые в
рамках одного дивизиона.
• Класс Г. Профильные простые проекты и/или проекты, реализуемые
в рамках одного структурного подразделения.
• Класс Д. Профильные проектные активности, реализуемые вне
методологического контура управления проектами.
Процесс определения класса ИТ-проекта представлен в виде дерева
принятия решений на рисунке .
53
Рисунок 8. Определение класса ИТ-проекта
В соответствии с данным рисунком получаем ИТ-проект класса Г.
В КСУП используется дифференцированный подход к управлению
проектами: с учетом вида проекта определяется его класс, класс проекта
определяет модель управления проектом.
Модель управления проектом задает набор и требования к элементам
управления, которые должны быть использованы при управлении конкретным
проектом. Основные группы элементов, из которых формируется модель
управления проектом, представлены ниже:
• распределение функций по управлению проектом между
различными уровнями управления в Группе;
• объем используемых документов по управлению проектом;
• необходимость привлечения экспертов;
• набор фаз жизненного цикла проекта.
В таблице 7 представлены сводные характеристики модели управления
ИТ-проектом класса Г.
54
Таблица 7
Характеристика ИТ-проекта класса Г
Класс
проекта
Распределение
функций по
управлению
проектом между
уровнями
управления
Группы
Объем
используем
ых
документов
по
управлени
ю проектом
Необходимос
ть
привлечения
экспертов
Набор фаз
жизненного
цикла
проекта
Класс Г
Стратегическое
управление - ПК
дивизиона
Оперативное
управление - РП в
бизнес-единице
Централизованный
мониторинг - ОУП
дивизиона
Администрировани
е - ОУП дивизиона
Минимальны
й
пакет
проектных
документов
Возможно
привлечение
экспертов по
решению
лица/органа,
осуществляющ
его
стратегическое
управление
проектом
Фаза 1.
Концепция
Фаза 2.
Реализация
Фаза 3.
Завершение
Далее опишем управление ИТ-проектом класса Г по трем фазам его
жизненного цикла, а именно «Концепция», «Реализация», «Завершение».
Главное содержание фазы «Концепция»: формулирование идеи проекта,
подтверждение целесообразности проекта и его параметров, определение вида
и класса проекта, формирование рабочей группы проекта.
Ключевыми участниками фазы «Концепция» являются: инициатор,
заказчик, функциональный руководитель, Рабочая группа во главе с
Руководителем рабочей группы, эксперты, ОУП Дивизиона и ОУП Группы,
Проектный комитет.
Основные шаги фазы:
• Формулирование идеи проекта и ее согласование;
• Формирование рабочей группы для подготовки Заявки на открытие
проекта;
• Подготовка Заявки на открытие проекта;
• Получение одобрения на заседании Проектного комитета для начала
работ по следующей фазе (формальное «открытие проекта» и переход на фазу
«Разработка»).