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

Главной особенностью российской стартап - экосистемы является высокая роль государственных органов и институтов в вопросах её развития и функционирования. Это вписывается в стратегию развития России до 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) предложили два подхода к жизненному циклу инвестирования. Первый подразумевает деление проекта на стадии, тесно связанные с жизненным циклом проекта:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Существуют другие модели рассмотрения жизненного цикла стартапа на основе этапов финансирования. Так, Пури и Царутский (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). Также данная модель начинает учитывать риски при реализации проекта.