Материал: Применимость проектной методологии в IT-стартапах

Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам

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

Достоинства данной модели:

·        Быстрота получения результатов;

·        Повышение уровня конкурентоспособности;

·        Реагирование на изменения.

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

Рисунок 4. Спиральная модель жизненного цикла IT-проекта.

Самой перспективной моделью для применения её в IT-стартапе, является итеративная модель. Она предполагает непрерывные процессы реализация, тестирования и анализа предыдущего опыта (Макконнелл, 2005).

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

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

·        Теснота связей с будущими пользователями, которая позволяет создать продукт реально отвечающим его потребностям;

·        Учет изменения внешней среды;

·        Использование важного ресурса команды стартапа - энтузиазма и высокой мотивации;

·        Снижение рисков неудовлетворительного продукта;

·        Повышение успешности проекта в целом от непрерывного итеративного тестирования и анализа продукта;

·        Издержки распределены по всему проекту, а не концентрируются в конце;

·        Фокус внимания команды именно на те изменения, которые важны будущим пользователям (Макконнелл, 2005).

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

 

1.3 Подходы к определению ролей в IT-стартапе


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

·        Спонсор проекта;

·        Пользователи продукта проекта;

·        Подрядчики;

·        Покупатели;

·        Бизнес-партнеров;

·        Функциональные менеджеры;

·        И другие.

В PRINCE2 выделяются только основные стейкхолдеры, такие как спонсоры, пользователи и подрядчики.

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

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

Бланк и Дорф (2012) выделили в своей работе следующий ряд ролей внутри стартапа:

·        CEO - Chief Executive Officer;

·        CFO - Chief Financial Officer;

·        CTO - Chief Technical Officer;

·        COO - Chief Operating Officer;

·        И другие.

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

В IT-стартапе, где важнейшим фактором является разрабатываемый продукт появляются роли разработчиков frontend и backend, отвечающие за пользовательский интерфейс и серверную часть соответственно; дизайнеры, маркетологи. Но в любом случае не существует унифицированного подхода к ролевому распределению в стартапах, так как CEO стартапа опирается на требования внешней и внутренней среды и компетенции каждого из участника команды стартапа при функциональном распределении обязанностей и зон ответственности.

 

1.4 Методологии управления IT проектами


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

На сегодняшний день существует целый ряд зарекомендовавших себя методологий управления IT-проектами. Для наиболее релевантного внедрения в стартап именно той, которая наиболее полно отвечала бы запросам проектной команды и будущим пользователям продукта необходимо сравнить их между собой. После анализа литературы было выделено 19 наиболее подходящих методологий управления проектами в IT-сфере - 4 традиционных свода знаний и 15 относящихся к гибким методологиям.

Классические методологии проектного управления не имеют жесткой привязки к применяемым областям. Морис, Кроуфорд, Ходгсон, Шепард и Томас (2006) рассматривают три традиционные методологии. Это PMBOK, PRINCE2 и APM Body of Knowledge. В случае данного исследования в их ряд следует добавить и четвертую - P2M, особенно целесообразную в контексте информационных технологий. МкХаг и Хоган (2011) в своих исследованиях показывают, что PMBOK и PRINCE2 самые популярные применяемы методологии в менеджменте. Более того APM BoK поверхностно раскрывает темы проектной деятельности и выполняет скорее только информационную функцию.

Таблица 2. Сравнение традиционных методологий управления проектам.

Название

Подход

Рассмотрение проекта

Предметная область

PMBOK

Процессный

Изолированно

Не привязана к предметной области

PRINCE2

Процессный

В контексте организации

Не привязана к предметной области

P2M

Системный

В контексте организации

Разработка ПО

APM

Процессный

В контексте организации

Не привязана к предметной области


Свод знаний PMBOK и PRINCE2 держат в фокусе процессы проектной деятельности, в то время как P2M больше системная методология. Несмотря на традиционность этих методологий, ряд используемых инструментов и методик, упоминающийся в них используются в деятельности IT-стартапов. Согласно исследованию МкХуга и Хогана (2011) стандарт PMBOK значительно чаще используется в бизнес сфере, чем P2M даже в среде стартапов. Помимо этого, PMBOK рассматривает проект отдельно от организации, что значительно сближает такое рассмотрение проекта со стартапом. При этом в данном стандарте инструменты всегда используются в контексте конкретных процессов управления и на конкретных этапах жизненного цикла, что усложняет попытку опосредованного применения их. Попытку их структурирования предприняли Беснер и Хобс (2012), сформировав список из более 100 инструментов из PMBOK и наиболее популярных инструментов классических методологий и независимых методик. Наиболее популярные из инструментов списка Беснера и Хобса (2012), применяемые стартапами, согласно исследованию Завялова Г. (2015):

·        Анализ затрат-выгод;

·        Планирование по вехам;

·        Контракты;

·        Анализ возможностей и угроз бизнеса;

·        Поэтапный список работ;

·        Контроль ключевых факторов успеха (КФУ);

·        Диаграммы Ганта;

·        NPV, IRR, PBP.

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

Современные гибкие методологии, как показывается в статья Риса (2012), Дэниэла и Джона (2009) и Лаанти (2011) имеют в целом больше преимуществ для IT-проектов. Несмотря на то, что их грамотное внедрение в IT-стартап является сложнее применения уже ставших шаблонными традиционных методологий, потенциальные выгоды являются существенными (Рис, 2012). В рамках данной работы особенный интерес будет проявлен именно к гибким методологиям, так как последние исследования, например, статья Акмаевой, Епифановой, Жукова (2017), демонстрируют высокую популярность гибких методологий в управлении продуктом и проектом. На сегодняшний день существует значительное количество agile-методологий и их модификаций, применяемых в бизнес сфере, в том числе и в IT-стартапах.

Уточним, что Agile - это гибкий итеративный-инкрементальный подход (т.е. делается первая функционирующая версия, после согласования с пользователем делается вторая версия, расширяющая функциональные возможности продукта и так далее до финальной версии, которая также подвержена дальнейшим модификациям) к управлению проектами и продуктами, ориентирующийся на динамическое формирование требований к продукту, их реализацию путем обеспечения тесного взаимодействия команды проекта с будущим потребителем продукта (Moran, 2015).

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

В рамках данной работы, применительно к IT-стартапам не будут подходить методологии разработки и управления проектами, которые предполагают низкую неопределённость планируемого продукта, т.к. по определению стартапа, данного Рисом (2012), высокая степень неопределенности неотъемлемый фактор функционирования стартапа. Однако отдельные используемые инструменты возможно окажутся адекватными для использования.

Ниже представлен перечень наиболее популярных и распространенных гибких методологий управления:

Таблица 3. Сравнение гибких методологий управления проектам.

Название

Применяемая модель жизненного цикла продукта

Степень неопределенности продукта

SCRUM

Итеративная

Высокая неопределённость продукта

Rational Unified Process (RUP)

Итеративная

Низкая неопределенность продукта

Extreme Programming (XP)

Спиральная

Средняя неопределенность продукта

Test-Driven development (TDD)

Спиральная (Основана из XP)

Средняя неопределенность продукта

Agile Unified Process (AgileUP)

Итеративная (Опирается на RUP и TDD)

Средняя неопределённость продукта

OpenUP

Итеративная (Легкий и гибкий вариант RUP)

Высокая неопределённость продукта

Dynamic Systems Development Method (DSDM)

Итеративная

Высокая неопределенность продукта

Adaptive Software Development (ASD)

Итеративная

Средняя неопределённость продукта

Rapid application development (RAD)

Итеративная

Низкая неопределенность продукта

Kanban

Зависит от типа разработки

Средняя неопределённость продукта

Microsoft Software Development (MSF)

Итеративная

Низкая неопределенность продукта

Feature-Driven Development (FDD)

Итеративная

Средняя неопределенность продукта

Бережливая разработка ПО

Итеративная

Средняя неопределенность продукта

Cleanroom Software Engineering

Итеративная

Низкая неопределенность продукта


Необходимо отметить, что Agile является самой популярной методологией по управлению как IT-проектами, так и IT-стартапами по результатам последних исследований (Акмаева, Епифанова, Жуков, 2017). Данная методология получила особенное распространение после опубликованного «Манифеста гибкой методологии разработки программного обеспечения» в 2001 году. По своей сущности он явился альтернативой, считавшейся традиционной каскадной модели разработки. Данный манифест содержит 4 идеи и 12 основных принципов. Основные идеи:

Источник: https://www.bibliofond.ru/view.aspx?id=908596