Размещено на http://www.allbest.ru/

Оглавление

Введение

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

1.1 Взаимосвязь стартапа и проекта

1.2 Подходы к жизненному циклу IT-стартапа

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

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

1.5 Особенности внедрения гибких методологий в IT-стартапы

Глава 2. Применение проектной методологии в стартапе «Wawe»

2.1 Описание стартапа «Wawe»

2.2 Анализ опыта разработки первого продукта стартапа «Wawe»

2.3 Выбор проектной методологии для стартапа «Wawe»

2.4 Результаты применения проектной методологии для стартапа «Wawe»

Заключение

Список литературы

Приложение



Введение

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

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

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

О проблемах управления стартапами свидетельствуют оценки экспертов «Российской венчурной компании», Фонда Бортника и других. Например, Бортник И.М. пишет: «За тринадцать лет работы в Фонде содействия развитию малых форм предприятий в научно-технической сфере я сделал вывод, что именно ошибки руководителя компании в управлении ею являются наиболее серьезной причиной медленного ее роста или даже прекращения существования…» [8].

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

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

Объектом исследования является методология управления стартапами на основе методологии управления проектами в сфере информационных технологий.

Предметом исследования выступает методология управления IT-стартапа «Wawe».

Целью исследования является определение подходящей методологии проектного управления для команды IT-стартапом «Wawe» с последующей оценкой эффективности её внедрения.

В соответствии с целью данной работы был определен ряд задач:

1. Проанализировать теоретические материалы по теме управления информационными проектами, рассмотрев основные международные и локальные стандарты по управлению проектами в IT;

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

3. Оценить особенности, сильные и слабые стороны применяемых проектных моделей управления стартапами в IT;

4. Выявить особенности управления стартапом «Wawe»;

5. Выбрать, модифицировать и внедрить наиболее релевантную модель управления стартапом «Wawe»;

6. Оценить результаты внедрения методологии управления стартапом на базе методологии управления IT-проектами;

Методология работы

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

Далее будет представлено глубинное интервью с основателем и креативным директором компании «Wawe», также было проведено наблюдение за рабочим процессом данного стартапа в период с октября 2016 года по декабрь 2016 года с целью выявления актуальных проблем и особенностей для компании «Wawe». На основании результатов анализа среды стартапов в IT, собранных данных по компании «Wawe», и благодаря полученным теоретическим выводам будет предложена, внедрена и оценена наиболее подходящая модель управления стартапом «Wawe». В рамках этой модели будет использован метод онлайн-опроса фокус-группы, по анализам результатов которого можно будет оценивать эффективность примененной методологии с точки зрения создания ценности.



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

1.1 Взаимосвязь стартапа и проекта

Впервые термин «Start-up» был упомянут в августе 1976 года в журнале Forbes. Стартап был охарактеризован как коммерческая компания с недолгой историей операционной деятельности. Но особую массовость данный термин получил уже в 1990-е и 2000-е годы, в период бума развития интернет-технологий (Blanc, 2012).

Терминологическое определение, наиболее широко используемое сегодня, дал американский предприниматель Стивен Бланк. Он охарактеризовал стартап как «временную структуру, существующую для поиска воспроизводимой и масштабируемой бизнес-модели» (Blanc, 2012). Идеолог бережливого производства и автор книги «Бережливый стартап» Эрик Рис добавляет к данному определению то, что организация должна также существовать в условиях высокой неопределенности и создавать новый продукт для того, чтобы называться стартапом (Рис, 2014). Блэнк и Дорф (2015) соглашаются с определением Риса, они объясняют наличие неопределенности тем, что как потенциальный рынок нового продукта, так и сам продукт являются неизвестными. Для проекта неопределённость среды значительно меньше, хотя Шенхар и Двир (2007) считают, что этот фактор обычный для проектного менеджмента. Они доказывают это на примерах крупных и инновационных проектах, включая сферу информационных технологий, внутри компаний, который имеют высокий уровень сложности. Таким образом, и по данному критерию IT- стартап имеет сходства с проектом. Пол Грэм - венчурный капиталист и Питер Тиль - инвестор Facebook, добавляют признак высокого темпа роста стартапа (4-7% по ключевому показателю в неделю) (Miller, 2014).

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

Исследование Robehmed Natalie, опубликованное в 2013 году в журнале Forbes, показало, как сами участники стартапов дают определение данного термина. Результаты выявили, что участники данных компаний считают, что определяющим фактором в определении стартапа является наличие общих ценностей всех сотрудников и осознание значимости вклада каждого из участников. Ими утверждается, что поддержание этой культуры позволяет рассматривать данную компанию как стартап вне зависимости от степени контроля учредителей над организацией и размера самой компании (Robehmed, 2013).

Тем не менее, определения стартапа Бланка и Риса являются одними из самых распространенны, поэтому в ВКР будут использованы именно они. В этом случае у термина стартап появляются признаки, которые коррелируют с определением проекта по стандартам PMBOK («Проект - это временное предприятие, предназначенное для создания уникальных продуктов, услуг или результатов») и PRINCE2 («Проект -- это комплекс взаимосвязанных мероприятий, направленный на создание уникального продукта или услуги в условиях временных и ресурсных ограничений»). Как видно из определений у стартапа и проекта есть сходства по принципам:

· Временность;

· Уникальный результат

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

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



Таблица 1. Сравнение стартапа и организаций малого бизнеса

	Стартап	Малый бизнес
Инновации	Инновации в центре внимания. Для стартапа важно наличие либо создание уникальной категории товаров, либо разработка новой бизнес-модели, либо создание новой технологии.	Не претендует на уникальность
Масштаб	Стартап ставит цель масштабировать бизнес как можно больше. Ставятся глобальные цели завоевания рынка.	Развитие в рамках видения руководства.
Темп роста	Постоянная нацеленность на рост	Прибыль - цель
Прибыль	Прибыль ставится на один из последних планов, так как цель в создании продукта	Получение прибыли как можно быстрее
Финансирование	Венчурное финансирование, т.к. необходимы крупные вложения для масштабирования бизнеса	Кредитование, личные сбережения
Технологии	Постоянное внедрение новых технологий	Консерватизм во внедрении
Жизненный цикл	92% стартапов уходят с рынка в течение первых трех лет	Около 30% уходят с рынка в течение трех лет
Команда и руководство	Команда, как определяющий успех фактор, расширяется с перспективой на развитие, т.к. участники должны органично вписываться в видение стартапа. Большее количество влиятельных стейкхолдеров	Найм сотрудников исходя из текущих потребностей
Образ работы	Ненормированный график работ	Нормированный график работ
Стратегия выхода	Классическим вариантом является проведение IPO или сделки по продаже	Продажа и передача

В следующих пунктах данной работы будут показаны отличительные особенности стартапа от проекта, однако общих черт гораздо больше между ними чем между IT-стартапом и классической организацией, занятой в сфере информационных технологий. Согласно статье основателя The Startup Couch Шумахера-Ходжа (2015) существуют ряд отличий стартапа от операционного бизнеса, которые диктуют особенности применяемой проектной методологии.

Как видно из сравнительных характеристик, данных Шумахером-Ходжем (2015) стартап отличается от классического формата малого бизнеса. Отличительные особенности диктуют необходимость модифицированного подхода к управлению стартапом.

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

Команда стартап-проекта после создания продукта продолжает деятельность, направленную на:

· поиск финансирования;

· поиск путей выхода продукта на рынок;

· масштабирование бизнеса.

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

Яркими примерами таких экосистем являются Кремниевая долина (Стэндфордский университет), где расположено уже 49 из 100 крупнейших бизнес-акселераторов и венчурных фондов, которые поддерживают стартапы на начальных этапах развития или MIT (Массачусетский технологический университет), создавший высокотехнологическому предпринимательству всю необходимую инфраструктуру, в результате чего совокупный валовый продукт организаций, созданных преподавателями, выпускниками и студентами за последние 50 лет находится на уровне крупных мировых экономик (Мошкин, 2014). Компании, образованные только при MIT создают около 1,1 млн. рабочих мест.

Главной особенностью российской стартап - экосистемы является высокая роль государственных органов и институтов в вопросах её развития и функционирования. Это вписывается в стратегию развития России до 2020 года, где важная роль отведена подготовке кадров для деятельности в инновационных сферах.

Основными государственными институтами поддержки стартапов являются ФРИИ (Фонд развития интернет-инициатив), инновационный центр Сколково и агентство стратегических инициатив. Также существует Российская венчурная компания, в чье ведение отведено формирование венчурных фондов и управление собственным фондом посевных инвестиций. Существует ряд крупных бизнес-инкубаторов при ведущих ВУЗах России: НИУ ВШЭ, ФУ при Правительстве РФ, МГУ. Создаются инновационные центры и технопарки - такие как Сколково и Иннополис.

Основной массив стартапов заняты в сфере информационных технологий. Спрос на IT-продукты со стороны потребителей и организаций сохраняет высокий уровень и имеет тенденцию к дальнейшему увеличению после спада в результате кризиса 2013-2016гг. Эта тенденция подтверждает диаграммой 1 и диаграммой 2, представленными в приложении. Как следствие рынок IT представляет из себя один из наиболее благоприятных сегментов для развития. Согласно исследованию IDC Russia, в 2017 году повысится темп рост рынка информационных технологий России на 7,2% в рублевом выражении, что сделает его привлекательным для инвестирования. Инвесторы продолжают вкладывать капитал в перспективные направления данного рынка. Это послужило тому, что сфера IT превратилась в зону высокого внимания, что привело к наращиванию её темпов развития.

По данным отчета Ernst&Young за 2014 год можно заключить что в фокусе внимания российских фондов находятся стартапы именно из области IT (Ильин, Балашов, Давыдов, Иванов, Скаженюк, Жетельный, Дан Штибель, Георгиева, Газизов, 2014). Такая ситуация продиктована большой интернет-аудиторией, интересом инвесторов к быстрому возврату вложенных средств и менее затратной инфраструктурой поддержки проектов.

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

1.2 Подходы к жизненному циклу IT-стартапа

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

Классическое представление жизненного цикла сформулировано и представлено в своде знаний PMBOK, и имеет следующий вид:

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

Согласно PMBOK жизненный цикл проекта всегда независим от жизненного цикла продукта (PMI, 2014). Однако для стартапов, особенно в сфере IT, эти жизненные циклы тесно сопряжены. Это объясняется тем, что интенсивная часть стартап-проекта заключена в разработке продукта, после которой деятельность компании имеет тенденцию перейти к операционному виду деятельности. Таким образом для стартапа целесообразно рассматривать жизненный цикл как систему из жизненного цикла продукта, жизненного цикла проекта и жизненного цикла финансирования.

Важно понимать на каком этапе жизненного цикла находится стартап, так как с течение времени целесообразно будет перестраивать модель управления (Бланк, 2010). Этапы жизненного цикла стартапа могут быть основаны на этапах финансирования. Гомперс и Лернер (200;4) предложили два подхода к жизненному циклу инвестирования. Первый подразумевает деление проекта на стадии, тесно связанные с жизненным циклом проекта:

1. Стартап, то есть начало;

2. Развитие продукта;

3. Бета-тестирование;

4. Налаживание поставок;

5. Точка прибыльности;

6. «Клинические испытания» или перезапуск.

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

Вестерфилд и Джаффе (2010) предлагают следующую модель жизненного цикла для стартапа, взятую из статьи Бруно и Тибже (2010), в соответствие с которой этапы стартапа связаны в основном с финансированием. Она тесно коррелирует с моделью жизненного цикла Гомперса и Лернера (2004). В ней используются следующие уровни:

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

2. Инвестиции старта - финансирование на разработку продукта и маркетинг;

3. Первый раунд инвестирования - это финансирование, направленное на запуск производства и продаж;

4. Второй раунд инвестирования - поддержка продаж, особенно в случае если продукт стартапа не приносит прибыли;

5. Третий раунд инвестирования - финансирование на расширение деятельности по достижении точки прибыльности;

6. Четвертый раунд инвестирования - финансирование с публичного размещения акций.

Существуют другие модели рассмотрения жизненного цикла стартапа на основе этапов финансирования. Так, Пури и Царутский (2008) в своей статье предлагают модель, внедренную в VentureXpert. В ней предусмотрено пять этапов, однако она почти в точности похожа на выше упомянутую модель Бруно и Тибже. У неё нет принципиальных преимуществ перед моделями Гомперса и Лернера (2004).

Все рассмотренные модели сходятся в ключевом для данной работы принципе. Успешным окончанием стартапа может являться:

· Поглощение стартапа крупной компанией;

· IPO;

· Трансформация в устойчивый бизнес после агрессивного расширения.

Сам стартап-проект должен иметь свой жизненный цикл, внутри которого существует жизненный цикл разрабатываемого ПП. Особенности жизненного цикла продукта в IT-стартапе продиктованы особенностями информационных технологий. У программного продукта для управления жизненным циклом используется модель SDLC (Software Development Life Cycle). SDLC - это система из 6 этапов разработки IT продукта проектной командой целом (Marakas, O'Brien, 2010). На сегодняшний день существует несколько актуальных методологий управления жизненным циклом IT проекта. Но все они состоят из подробного плана, описывающего, как развить, сохранить, заменить, изменить или усложнить программное обеспечение. Жизненный цикл определяет методологию для повышения качества программного обеспечения (Далее - ПО) и улучшения процесса разработок в целом (Marakas, O'Brien, 2010).

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

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

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

Этап 4. Разработка - внедрение - развертывание: Это ключевая фаза, в которой пишется код программного продукта. Она возможна уже после формирования дизайна. Эта фаза традиционно занимает большую часть времени разработки ПП. Для проекта на этой стадии уже возможна установка в «боевом» режиме у заказчика, а для стартапа запуск бета-тестирования, то есть тестирования в котором задействованы потенциальные пользователи.

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

Этап 6. Поддержка системы: Также является традиционной фазой, в которой команда IT-стартапа следит за функционирование системы, выпускает модификации, если необходимо, расширяет функционал, чтобы продукт соответствовал требования внешней среды целом (Marakas, O'Brien, 2010).

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

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

Для начала обратимся к каскадной модели, впервые упомянутой Ройсом У. в 1970 году (Ройс, Винсонт, 1970). В рамках данной модели следующие этапы разработки не могут выполняться без завершения предыдущих.

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

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

· Отсутствие обратной связи между этапами;

· Потеряла актуальность ввиду изменения условий разработки ПП.

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

Следующей моделью разработки ПП является V-модель. Она была разработана независимо в США и Германии в конце 1980-х годов. Данная модель является уже более современной, и существуют организации, применяющие именно этот подход к фазам жизненного цикла.

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

· прояснения требований;

· выбора одного из ряда возможных концептуальных решений;

· анализа осуществимости проекта (Highsmith, 2002).

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

· модель учитывает запросы пользователе ПП;

· V-модель возможно адаптировать под любой проект, т.к. она не зависит от типа организации или проекта;

· высокая детализация работ.

Недостатки данной модели с точки зрения адекватного применения её в IT-стартапах в том, что:

· Модель больше фокусируется на разработке продукта, а не на всей организации проекта;

· В модели нет возможности осуществления изменения на разных этапах жизненного цикла;

· В модель не включены мероприятия по анализу рисков;

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

Следующий тип модели жизненного цикла программного продукта - это спиральная модель, сформулированная Барри Боэмом в 1986 году. В данной модели проявлены свойства итеративности, как у V-модели, так и этапности каскадной модели (Highsmith, 2002). Также данная модель начинает учитывать риски при реализации проекта.

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

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

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

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

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

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

Рисунок 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 основных принципов. Основные идеи:

· Взаимодействие людей и их способности важнее применяемых процессов и инструментов;

· Продукт важнее документации;

· Тесное взаимодействие с заказчиком важнее согласований условий контрактов;

· Готовность и способность к изменениям важнее первоначального плана;

Основные принципы «Манифеста гибкой методологии разработки программного обеспечения»:

· Простота как искусство не делать лишних работ;

· Тенденция к само организованным командам;

· Постоянная готовность искать и осуществлять изменения;

· Фокус на улучшении технического мастерства и удобства дизайна;

· Участники проекта должны поддерживать постоянный темп работ;

· Лучшим измерителем прогресса является работающее ПО;

· Рекомендуемый метод обмена информацией - личные разговоры;

· Проектом занимаются мотивированные личности;

· Постоянный контакт заказчика и исполнителя;

· Еженедельная, ежемесячная поставка рабочего ПО;

· Способность принимать изменения даже в конце сроков проекта;

· Удовлетворение клиента путем предоставления ценного ПО.

Гибкие методологии в управлении информационными проектами подразумевают:

1. Вовлечение конечных пользователей продукта имеет определяющее значение;

2. Принятие решений должно основывать на высокой эффективности команды;

3. Основа работы - это этапность и цикличность;

4. Концентрация на промежуточных результатах с обязательным представлением продукта;

5. Используется модель эффективности Паретто 80/20;

6. Применение коллективного подхода при реализации плана;

7. Переход к следующему этапу производится только после завершения предыдущего.

Как видно из принципов Agile-методологии, её использование рационально в интеллектуальных сферах бизнеса, таких как маркетинг, IT и им подобным. Данный тип методологий стал активно внедряться в организациях в последнее десятилетие ввиду малой эффективности классических подходов управления проектами. Этому поспособствовало следующие тенденции рынка (Conforto, Amaral, da Silva, Di Felippo, Kamikawachi, 2016):

1. Высокая интенсивность конкуренции. Эффективность традиционных методов, таких как PMBOK, сформулированного институтом PMI, в которых формула успешности базируется на проектном треугольнике (быстро, недорого, качественно) значительно снизилась в отраслях, характеризующихся высоким уровнем конкуренции (Рис, 2014) Потребитель продукта проекта сегодня, характеризуется желанием получить наиболее эффективное, качественное и простое решение в кратчайшие сроки и дешевле, чем предложения конкурентов. И более того, в течение проекта его спрос может меняться, и команда проекта должна уметь быстро перестраивать как требования к продукту, так и структуру работ для достижения поставленных задач. Это вытекает в следующую тенденцию рынка:

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

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

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

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

Также согласно исследованию Дагаева А.А. и Лутфулина М.А. (2015) вновь возникшие компании наиболее эффективно применяют упрощенные методологии управления проектами, так как в отличие от проектов в организациях, где может существовать проектный офис, поддерживающий деятельность проектной команды, и существует сравнительно больший опыт работы в условиях внедренных комплексных методологий, у участников стартапа традиционно меньше трудовой опыт в области проектного управления (Рэмптон, 2015). Следовательно, при выборе внедряемой методологии проектного управления в IT-стартап будет также учтена сложность рассматриваемых методологий, особенно в случаях нахождения компании на первых этапах жизненного цикла.

1.5 Особенности внедрения гибких методологий в IT-стартапы

Команда проекта традиционно проходит через фазы развития команды, сформированные Брюсом Тукманов в 1965 году:

1. Forming - этап на котором участники стартапа впервые собрались вместе. Они слабо доверяют друг другу, пытаются оценить свою роль в команде.

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

3. Norming - на этой стадии борьба за власть утихает, и члены команды лучше узнают друг друга. Растет уровень доверия в команде. На обсуждениях всё чаще достигаются консенсусы.

4. Performing - команда становится самоуправляемой и переводит фокус с внутренних проблем на решение задач проекта.

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

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

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

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

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

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

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

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

Количество проектов, выполняемых одновременно	Время, потраченное на проект	Потери времени из-за приключения между проектами
1	100%	0%
2	40%	20%
3	20%	40%
4	10%	60%
5	5%	75%

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

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

· высокая неопределенность внешней среды;

· важность внимания к своим клиентам;

· сильная связь жизненного цикла продукта с жизненным циклом стартапа.

Для того, чтобы эти особенности были учтены, в данной ВКР сформирован список требований для методологий:

· итеративно-инкрементальная модель;

· простота внедрения и использования;

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



Глава 2. Применение проектной методологии в стартапе «Wawe»

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

Для выбора конкретной методологии при внедрении в IT-стартап «Wawe» необходимо сравнить их по следующему перечню факторов, сформированных при теоретическом анализе как значимые для стартапа:

1. Оптимальный размер команды и наличие определенных ролей;

2. Степень неопределенности разрабатываемого ПП и внешней среды в целом;

3. Степень фокуса методологии на разработку продукта и на непосредственное управление проектом/стартапом;

4. Тип модели жизненного цикла;

5. Предполагаемая теснота связи с будущими пользователями ПП;

6. Гибкость самой модели к изменениям;

7. Степень вовлеченности участников в проект/стартап.

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

В рамках практической части анализируется эффективность применения методологии управления проектами в IT-стартап Wawe. Данное исследование было разделено на три этапа. Первый этап - сбор информации о применяемых подходах в управлении стартапом Wawe в совокупности с анализом текущей внешней среды. Для достижения этих задач использованы эмпирические способы сбора информации: наблюдение и глубинное интервью. Начиная с октября 2016 года и по декабрь 2016 года автором данной работы осуществлялись посещения офиса стартапа «Wawe» в бизнес-центре Arma, с целью сбора необходимой информации о:

· Применяемых инструментах и методах;

· Особенностях реагирования на изменения внешней среды;

· Отношении к жизненному циклу стартапа и продукта;

· Методах управления командой стартапа.

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

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

На заключительном этапе выполнялся анализ полученных результатов с целью оценки успешности выбора и внедрения модели управления проектами в управление IT-стартапом Wawe.

2.1 Описание стартапа «Wawe»

Стартап Wawe был основан в 2015 году двумя студентами - Кочергиным Дмитрием (МГУ) и Манняновым Кириллом (НИУ ВШЭ). С момента создания и до сегодняшнего дня Кочергин Дмитрий является CEO стартапа, а Маннянов Кирилл сооснователем и креативным директором.