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

метки: Методология, Проект, Управление, Проектный, Стартап, Диплом, Социальный, Программа

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

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

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

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

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

актуальность исследования

Объектом исследования, Предметом исследования, Целью исследования

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

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

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

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

Государственное управление в сфере образования

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

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

IT-стартапах

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

Наиболее используемое сегодня терминологическое определение было дано американским предпринимателем Стивеном Бланком. Он охарактеризовал стартап как «временную структуру, существующую для поиска воспроизводимой и масштабируемой бизнес-модели» (Blanc, 2012).

Идеолог бережливого производства и автор книги «Бережливый стартап» Эрик Рис добавляет к данному определению то, что организация должна также существовать в условиях высокой неопределенности и создавать новый продукт для того, чтобы называться стартапом (Рис, 2014).

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

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

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

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

Как видно из определений у стартапа и проекта есть сходства по принципам:

• Временность;
• Уникальный результат

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

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

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

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

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

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

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

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

• поиск финансирования;
• поиск путей выхода продукта на рынок;
• масштабирование бизнеса.

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

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

Компании, образованные только при MIT создают около 1,1 млн. рабочих мест.

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

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

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

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

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

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

IT-стартапа

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

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

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

Согласно PMBOK жизненный цикл проекта всегда независим от жизненного цикла продукта (PMI, 2014).

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

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

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

• Стартап, то есть начало;
• Развитие продукта;
• Бета-тестирование;
• Налаживание поставок;
• Точка прибыльности;
• «Клинические испытания» или перезапуск.

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

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

В ней используются следующие уровни:

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

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

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

• Поглощение стартапа крупной компанией;
• IPO;
• Трансформация в устойчивый бизнес после агрессивного расширения.

Сам стартап-проект должен иметь свой жизненный цикл, внутри которого существует жизненный цикл разрабатываемого ПП. Характеристики жизненного цикла продукта в ИТ-стартапе продиктованы спецификой информационных технологий. У программного продукта для управления жизненным циклом используется модель SDLC (Software Development Life Cycle).

SDLC — это система из 6 этапов разработки IT продукта проектной командой целом (Marakas, O’Brien, 2010).

Сегодня существует несколько актуальных методологий управления жизненным циклом ИТ-проекта. Но все они состоят из подробного плана, в котором описывается, как разрабатывать, поддерживать, заменять, модифицировать или усложнять программное обеспечение. Жизненный цикл определяет методологию для повышения качества программного обеспечения (Далее — ПО) и улучшения процесса разработок в целом (Marakas, O’Brien, 2010).

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

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

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

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

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

Этап 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).

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

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 стартапа опирается на требования внешней и внутренней среды и компетенции каждого из участника команды стартапа при функциональном распределении обязанностей и зон ответственности.

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

• Взаимодействие людей и их способности важнее применяемых процессов и инструментов;
• Продукт важнее документации;
• Тесное взаимодействие с заказчиком важнее согласований условий контрактов;
• Готовность и способность к изменениям важнее первоначального плана;

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

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

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

• Вовлечение конечных пользователей продукта имеет определяющее значение;
• Принятие решений должно основывать на высокой эффективности команды;
• Основа работы — это этапность и цикличность;
• Концентрация на промежуточных результатах с обязательным представлением продукта;
• Используется модель эффективности Паретто 80/20;
• Применение коллективного подхода при реализации плана;
• Переход к следующему этапу производится только после завершения предыдущего.

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

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

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

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

При этом, стоит отметить, что гибкая методология разнится для 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-стартапы, а также позволяющие наиболее безболезненно пройти этап шторминга.

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

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

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

Джеральд Вайнберг (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» необходимо сравнить их по следующему перечню факторов, сформированных при теоретическом анализе как значимые для стартапа:

• Оптимальный размер команды и наличие определенных ролей;
• Степень неопределенности разрабатываемого ПП и внешней среды в целом;
• Степень фокуса методологии на разработку продукта и на непосредственное управление проектом/стартапом;
• Тип модели жизненного цикла;
• Предполагаемая теснота связи с будущими пользователями ПП;
• Гибкость самой модели к изменениям;
• Степень вовлеченности участников в проект/стартап.

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

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

• Применяемых инструментах и методах;
• Особенностях реагирования на изменения внешней среды;
• Отношении к жизненному циклу стартапа и продукта;
• Методах управления командой стартапа.

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

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

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

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

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

С момента создания и до сегодняшнего дня Кочергин Дмитрий является CEO стартапа, а Маннянов Кирилл сооснователем и креативным директором.

Также в команде есть команда бэкенд и фронтенд разработки. Она насчитывает 6 человек: 2 сотрудника занимаются бэкенд программированием и по 2 разработчика заняты в iOS и Android направлениях соответственно. Тесно с командой управления стартапа сотрудничает основной инвестор проекта, выделивший на посевной раунд 3 млн. рублей за 5-20% доли в компании. стандарт проект стартап бизнес

Соответственно, организационную структуру стартапа Wawe можно представить следующим образом:

Рисунок Организационная структура компании Wawe.

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

Наблюдение за тем, как разрабатывался первый программный продукт Wawe в совокупности с глубинным интервью с представителем команды управления данным стартапом — креативным директором (Маннянов Кирилл) позволило выявить особенности подхода к управлению внутри данной компании, на основании которых был сделан вывод о наиболее целесообразной проектной методологии для применения.

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

Начало разработки данного продукта пришлось на осень 2015-ого года, но в результате весь процесс занял более года. Столь длительный срок для приложения с не самой сложной архитектурой и интерфейсом оказался критическим. Если первоначально данное приложение планировалось в условиях, когда не было «stories» у Instagram (публикуемые фотографии, которые исчезают по истечении суток) — прямого конкурента «моментальных» фотографий у Wawe (Через режим «моментальной» фотографию можно опубликовать только новый кадр), то за несколько месяцев до запуска стартапу пришлось столкнуться с данной трудностью. Руководством было принято решение продолжать разработку и выводить продукт на рынок. Данное решение полностью противоречит принципам гибкой методологии управления проектам, согласно которому вся команда стартапа должна быть не только готова отвечать на возникшие изменения внешней среды, но и сами искать потенциальные угрозы и реагировать на них.

По результатам проводимых наблюдений за рабочим процессом «Wawe» и по результатам глубинного интервью с креативным директором стартапа было выявлено, что данная компания использует ситуационный подход к управлению проектом. Такой вывод был сделан по отсутствию долгосрочного планирования, и неполностью ясными взаимоотношениями между командой управления, офисом разработчиков и программным продуктом. Например, дизайнер в лице креативного директора предоставляет ТЗ для разработчиков, те в свою очередь только уточняют вопросы и приступают к разработке. Более того, техническое задание (далее — ТЗ), по словам самого Маннянова К. Б., было сделано из совместных представлений соучредителей об идеальном продукте. В интервью креативному директору был задан вопрос: «Что для Вашего стартапа в центре важнее всего: продукт, рынок или люди?», на что Маннянов Кирилл ответил, что продукт. Это показывает, то что в понимании стартапа у креативного директора есть расхождения с Рисом и Бланком, которые заявляют о важности создания ценности для пользователей.

При этом в интервью Маннянов К. Б. сообщает, что в стартапе используется agile-методология. Данный ответ респондента показывает, что сложность применения методологии agile в некоторых случаях лежит в недопонимании принципов и сути. Это подтверждает результат исследования компании Wrike в 2016, в котором по результатам опроса 803 маркетологов, было выделено три главных сдерживающих фактора внедрения agile в компаниях:

• Низкий уровень осведомленности об Agile (23,5%);
• Консерватизм к подходу к работе (17,6%);
• Непонимание руководством ценностей гибких методологий (11,6%).

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

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

С точки зрения жизненного цикла стартапа — Wawe на момент начала этапа наблюдения находилась на этапе «start-up» по модели Вестерфилда и Джаффе (2010), так как первое инвестирование для запуска проекта уже было получено, и было получено инвестиционное вложение в размере 200000$ на разработку продукта.

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

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

На основании целевой аудитории (далее ЦА) стартапа «Wawe» была сформирована фокус-группа из 47 добровольцев, которым было предложено оценить вышедшее приложение Wawe.

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

Ключевые вопросы по выявлению отношения ЦА к разрабатываемому продукту были разработаны с опорой на American Customer Satisfaction Index (ACSI), который используется для оценки удовлетворенности потребителей в экономике США и особенностей самого стартапа и разрабатываемого продукта.

Рисунок Возрастная структура фокус-группы.

Рисунок Структура фокус-группы по времени, использования смартфона.

Важным критерием по структуризации фокус-группы — это соотношение пользователей iOS и Android — платформ. На российском рынке около 70% смартфонов работает на платформе Android и 25% — на iOS.

Рисунок Структура фокус-группы по платформам смартфона.

Полученная статистика по фокус — группе показала, что у 27 респондентов Android-смартфоны, а у 20 — iOS. Данное смещение центральной тенденции объясняется тем, что все представители фокус-группы относятся к московскому региону, где доля смартфонов от Apple выше в связи с большей экономической развитостью.

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

Приложение Wawe было предложено оценить по 5 показателям, считающиеся ключевыми для удовлетворенности пользования:

1. Понятность интерфейса (x1);

• Быстрота отклика (x2);
• Плавность использования (x3);
• Дизайн (x4);
• Соответствие ожиданиям из аннотации приложения (x5).

• Вероятность пользования при текущем виде (x6).

Ниже приведены результаты анкетирования.

Таблица 5. Результаты опроса фокус-группы по ключевым показателям продукта.

	Android							iOS
	N/A	1	2	3	4	5	Ср.	N/A	1	2	3	4	5	Ср.
(x1)		9	7	7	2	2	2,3	2	2	5	6	3	2	2,6
(x2)		2	5	7	8	5	3,3		1	2	6	6	5	3,6
(x3)		6	5	4	6	6	3,0		1	1	2	7	9	4,1
(x4)	1	1	2	6	7	10	3,7		1	2	3	4	10	4
(x5)	1	5	8	7	4	2	2,5	1	3	5	6	4	1	2,6
(x6)	4	6	8	6	2	1	2,0	2	4	4	7	2	1	2,3

Как видно из полученной таблицы, команда стартапа «Wawe» выпустила неудовлетворительный продукт по ключевой характеристике о потенциале использования приложения. В среднем по этому показателю были получены 2,0 по платформе Android и 2,3 по платформе iOS. При этом по показателям, связанным с удобством приложения (x1), (x2), (x3), (x4) получены сравнительно высокие оценки по обеим платформам.

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

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

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

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

• Существование команды Wawe в рамках одного коллектива более 1 года;
• Высокая мотивация сотрудников;
• 9 участников стартапа (из них 3 — команда управления стартапом, а 6 — команда разработчиков)

4. IT-стартап, занятый в сфере разработки ПО для сегмента B2C;

• Низкая вычислительная сложность разрабатываемого ПО;
• Высокая неопределенность внешней среды;
• Нечетко определены требования к ПП;
• Стартап функционирует в условиях ограниченности бюджета;
• Интерфейс пользователя важнее функциональности разрабатываемого ПП;
• В рамках проекта разрабатывается два продукта (iOS и Android);
• Простота использования проектной методологии;
• Для выбора методологии воспользуемся сформированной таблицей сравнения (приложение 3) по результатам анализа каждой из методологий.

Так как неопределенность внешней среды является ключевым фактором для стартапа, то мы исключим из выбора RUP, RAD, MSF и Cleanroom Softaware Development, которые предполагают конкретные требования к продукту и, соответственно, не подходят как для стартапа «Wawe», так и для подавляющего большинства IT-стартапов. По этой же причине не подойдет PMBOK, PRINCE2 и APM BoK.

Сравнив положительные и отрицательные стороны выбранных методологий, было получено, что для стартапа «Wawe» в силу выше перечисленных ограничений и возможностей, подходят две гибкие методологии: Scrum и Kanban. Это продиктовано тем, что эти методологии обладают сравнительно простотой внедрения, применения и понимания со стороны команды стартапа. Также они подошли по важному критерию размера команды и ролевого распределения (6 +/- 3 человека) и фокусом на качество. Сравнительным плюсом данных методологий также в том, что они могут использоваться не только в рамках разработки отдельного продукта, но и в рамках управления стартапом в целом.

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

Предложенная стартапу «Wawe» методология подразумевала, что команды разработчиков будут сгруппированы по направлениям разработки, т.е. на Android и iOS. Далее вводится роль Product Owner — владельца продукта, которую выполняет креативный директор, он же выполнял функцию контроля исполнения правил (Scrum Master).

Для того чтобы видение креативного директора совпадало с ЦА, проводится опрос фокус-группы в конце каждого спринта. Весь проект был разделен на месячные итерации, как для направления iOS, так и для Android. Эти итерации будут называться спринтами согласно терминологии Scrum. Для формирования планируемого функционального наполнения разрабатываемых продуктов будет вестись журнал пожеланий проекта, в который будут занесены планируемые задачи, а также по результатам обратной связи фокус-группы будет наполняться новыми задачами. В данном журнале задачи будут приоритезированны по значимости совместным обсуждение владельца продукта и команды разработчиков. А также им будут присвоены веса для более равномерного наполнения спринтов. Далее из этого журнала будут выбираться задачи к следующему спринту и расставляться по значимости сверху вниз в столбец «To do» в программе Trello, которая заменит доску с соответствующими столбцами. При этом в отличие от традиционно подхода Scrum, чтобы учесть фактор неопределенности в течение спринта владельцу продукта можно будет добавлять задачи в «To do». Также будет вестись учет качества производтельности команд с помощью Burndown chart, как это делается в классическом Scrum. Также из Scrum были взяты 15-минутные встречи команды перед началом рабочего дня, а также анализ проделанной работы в конце спринта. Для оценки эффективности в конце каждой итерации анализировался burndown chart, график на котором по оси y откладывались все рабочие часы на итерацию, а по оси x рабочие дни. И в конце каждого дня на графике отмечается сколько остается чистых часов работы до готового MVP.

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

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

С января 2017 года новый продукт компании «Wawe» — «Wave x». Данное приложение по сложности разработок соответствовало первому приложению «Wawe». ЦА у нового приложения сохранилась. Но «Wave x» в отличие от первого продукта разрабатывался с использованием предложенной гибкой методологии управления проектом на основе Scrum и Kanban. Она отличается от способа управления стартапом Wawe более тесным контактом с пользователями и предсказуемой организацией процесса разработки продукта даже в условиях меняющихся требований.

Так первый график Burndown после первого спринта для направления Android выявил низкую производительность команды разработчиков стартапа:

График 1. Burndown chart для первого спринта.

Благодаря этому была выявлена проблема оценки сложности планируемых работ для направления iOS. Если раньше в команде считалось, что набор задач (x) на первый день должна выполняться 8 часов, то в действительности он требовал больше времени разработки ввиду сложности или неопытности разработчиков. Учесть подобную ошибку при инициации внедрения проектной методологии почти невозможно, соответственно для будущих стартапов можно посоветовать только экспериментировать, так как оценка трудозатрат на планируемые задачи зависит как от профессионализма команды и её сплоченности, так и от самой задачи.

В итоге после доработок по результатам второго месяца автором данной ВКР была разработана следующая схема управления стартапом на основе гибких методологий управления проектами:

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

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

Гибридная модель несколько отличается от традиционного Scrum, что еще подтверждает то, что проектная методология IT-стартапа должна не просто применять лучшие практики и желаемую методологию, а опираться на внутренние и внешние условия компании.

Также согласно манифесту Agile и исследованию Дагаева А.А. и Лутфулина М. А. (2015), выполняется важный принцип простоты методологии для субъекта малого бизнеса.

В случае «Wawe» в результате подобных анализов была улучшена система оценки планируемых этапов разработки программного продукта:

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

— Новому продукту компании «Wawe» понадобилось 4 месяца, чтобы запуститься. Первый месяц был наименее эффективен после внедрения. Это связано во много с тем, что команде стартапа пришлось перестраивать подход к управлению и разработки. Также возникали сложности с определение весов задач, для равномерного наполнения спринтов-итераций. Но к началу февраля 2017 года был получен минимальный жизнеспособный продукт (MVP).

Он не отражал потенциал планируемого приложения, но обладал дизайном и некоторыми функциями. По окончании первого спринта был проведен опрос фокус-группы, который выявил отправные данные для направлений работы. Ниже приведено сравнение опросов фокус-группы после первого спринта и после финальной версии приложения «Wave x». Конечно данная статистика не может оценить будущий успех стартапа в целом, так как перед компанией встала новая задача выхода на рынок и расширения количества пользователей. Но зато она показывает, что одно из требований, которое сформировано у Риса Э. и Бланка С. к успешному стартапу выполнено — это удовлетворенность потенциальных пользователей и создание ценности для них.

В опросе фокус-группы ЦА после первой итерации не учитывались ответы по вопросу (x5), так как в аннотации к приложению для первого MVP нет необходимости. Ведь продукт не обладает еще планируемым функционалом.

Таблица 6. Результаты опроса фокус-группы по ключевым показателям продукта (03.02.17).

	Android							iOS
	N/A	1	2	3	4	5	Ср.	N/A	1	2	3	4	5	Ср.
(x1)	5	7	5	4	3	3	2,1	4	5	4	4	2	1	1,9
(x2)	4	9	7	4	2	1	1,8	4	4	6	3	2	1	1,9
(x3)	4	12	7	2	1	1	1,5	4	1	4	4	5	2	2,55
(x4)	6	4	5	4	4	4	2,3	5	2	4	4	3	2	2,2
(x5)
(x6)	4	16	6	1			1,1	4	11	4		1		1,15

Таблица 7. Результаты опроса фокус-группы по ключевым показателям продукта (05.05.17).

	Android							iOS
	N/A	1	2	3	4	5	Ср.	N/A	1	2	3	4	5	Ср.
(x1)	1	1	2	3	6	14	4,0	2	2	2	3	5	6	3,25
(x2)		2	5	7	8	5	3,3		1	1	2	7	9	4,1
(x3)	1	3	4	5	6	8	3,3		2		2	8	8	4
(x4)		1	2	6	7	11	3,9			3	3	3	11	4,1
(x5)		2	4	6	6	9	3,6		1	2	6	7	3,7
(x6)	2	4	5	4	7	5	2,9	1	3	2	3	6	5	3,25

Как видно из представленных таблиц, общая удовлетворенность по обеим платформам выросла с 1,1 и 1,15 после первого релиза до 2,9 и 3,25 после финального. При этом по платформе iOS выше показатель вероятности использования приложения, во много это объясняется тем, что для iOS работы в целом проходили немного легче, так как приложение надо было оптимизировать только под 2 разрешения, тогда как у смартфонов под платформой Android вариантов значительно выше. Также, что особенно важно для данного стартапа, улучшилась общая удовлетворенность продуктом по сравнению с первым опытом разработки приложения Wawe: с 2,0 и 2,3 до 2,9 и 3,25 для платформ Android и iOS соответственно.

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

Внедренная методология подразумевала мероприятия по управлению проектом. Это выражалось в инструментах итеративного подхода к разработке, который учитывал интересы будущих пользователей и давал возможность команде «Wawe» не выпускать сразу продукт, который не отражал желаемых характеристик ЦА, а каждый раз менять какие-либо свойства, благодаря опросам фокус-группы. Также благодаря burndown графиков и плану планируемых задач в итерации появился инструмент управления сроками и стоимостью. В итеративном подходе заключается также управление качеством.

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

Проанализировав литературу по темам: особенности самих стартапов, особенности применения проектного управления в IT-стартапах, а также оценки применимости методологий управления проектами в IT-стартапах в данной выпускной квалификационной работе был предложен подход к применение проектной методологии в IT-стартапе «Wawe».

В рамках написания ВКР был проведен анализ внутренней среды на предмет:

• Особенностей жизненного цикла стартапа;
• Количественного и ролевого состава команды;
• Этап жизненного цикла команды по модели Тукмана;
• Сложность разрабатываемого продукта.

А также осуществлен анализ внешней среды на предмет:

• Неопределенности;
• Влияния стейкхолдеров.

В связи с тем, что рассматриваемый стартап «Wawe» находится на начальном этапе жизненного цикла команды и проекта, количество участников в нем небольшое (менее 10 человек), а сложность разрабатываемого ПО низкая, то автором ВКР было предложена использовать гибридную проектную методологию, основанную на гибких моделях, таких как Kanban и Scrum.

Опыт применения разработанной методологии в компании «Wawe» продемонстрировал, что нужно не в слепую выбирать готовую модель, а внедрять, опираясь на выше указанные особенности внутренней и внешней среды, а также на опыт аналогичных проектов. Так, для стартапа «Wawe» оказалось наиболее целесообразным взять итеративную модель управления продуктом, синтезировав с гибкой методологией управления проектом, внедрив систему опроса фокус-группы ЦА и добавив возможность формировать изменения к продукту даже во время итерации, что отличает предложенную модель от, например, чистой модели Scrum.

В итоге, предложенная гибкая проектная методология для стартапа «Wawe» соответствовала требованиям, подчеркнутым из научных источников, посвященных различным предметным областям, а также выше упомянутым особенностями внутренней и внешней среды конкретно для данного стартапа.

Полученная модель показала свою эффективность по результатам его внедрения:

• Увеличилась скорость разработки (в среднем на 10-15%);
• Увеличилась управляемость стартапом и процессом разработки;
• Увеличилась прозрачность процесса разработки;
• Появилась возможность оценивать эффективность разработки;
• Был внедрен инструмент управления рисками;
• Был внедрен инструмент управления изменениями;
• Был внедрен инструмент управления сроками;
• Был внедрен инструмент управления стейкхолдерами;
• Финальный продукт «Wave x», выпущенный в условиях внедренной методологии обладал высокими баллами удовлетворенности ЦА по сравнению с опытом разработки первого продукта «Wawe»;
• В результате проведённой работы цель данной ВКР выполнена. Для IT-стартапа «Wawe» была определена подходящая методология управления, которая подтвердила свою эффективность.

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

[Электронный ресурс]//URL: https://management.econlib.ru/diplomnaya/upravlenie-sotsialnyimi-proektami-i-programmami-diplom/

1. Association for Project Management, 2012. APM Body of Knowledge 6th ed., Association for Project Management;

2. Project Management Institute, A Guide to the Project Management Body of Knowledge — Fifth Edition, Project Management Institute Inc., 2013;

3. Дагаев А.А., Лутфуллин М.А, Некоторые особенности управления проектами в сфере малого инновационного бизнеса // Российский журнал управления проектами №3(12)2015, — Моcква, 2015;

• Ильин В., Балашов В., Давыдов В., Иванов А., Скаженюк Е., Жетельный И., Дан Штибель, Георгиева В., Газизов К. Исследование российского и мирового венчурного рынка за 2007-2013 годы, // Обзоры и исследования российской инновационной экосистемы // Российская Венчурная Компания — 2012г. URL: #»908596.files/image008.gif»>