Учебная работа. Применимость проектной методологии в IT-стартапах
Применимость проектной методологии в IT-стартапах
Оглавление
Введение
Глава 1. Применимость проектной методологии в IT-стартапах
1.1 взаимосвязь стартапа и проекта
.2 Подходы к жизненному циклу IT-стартапа
.3 Подходы к определению ролей в IT-стартапе
.4 Методологии управления IT проектами
.5 особенности внедрения гибких методологий в IT-стартапы
Глава 2. Применение проектной методологии в стартапе «Wawe»
2.1 Описание стартапа «Wawe»
.2 анализ опыта разработки первого продукта стартапа «Wawe»
.3 Выбор проектной методологии для стартапа «Wawe»
.4 Результаты применения проектной методологии для стартапа «Wawe»
Заключение
список литературы
Приложение
Введение
В современном мире всё большее обусловлено тем, что повышается изменчивость и сила влияния внешней социально-экономической среды на организации. компании и даже государства вынуждены существовать в условиях высокой конкуренции и для достижения преимуществ они должны внедрять инновации в свою деятельность.
Одним из ключевых элементов такой инновационной деятельности выступает организация стартапов или стартап-проектов. Как следствие, одним из стратегических направлений развития Российской Федерации до 2020 года является подготовка высококвалифицированных специалистов для инновационной деятельности и мотивация к проведению инновационных проектов. И организация стартапов занимает одну из важнейших ролей в рамках этой стратегии.
Стартапы в сфере информационных технологий особенно важны, так как, во-первых, они способны разрабатывать инновационные программные продукты (далее ПП), востребованные на российском рынке, а во-вторых, увеличивать долю экспорта, приходящуюся на IT-сектор, что жизненно важно при переходе к четвертой промышленной революции.
О проблемах управления стартапами свидетельствуют оценки экспертов «российской венчурной компании», Фонда Бортника и других. Например, Бортник И.М. пишет: «За тринадцать лет работы в Фонде содействия развитию малых форм предприятий в научно-технической сфере я сделал вывод, что именно ошибки руководителя компании в управлении ею являются наиболее серьезной причиной медленного ее роста или даже прекращения существования…» [8].
При этом в научной сфере проблематику стартапов рассматривают в основном извне. Чаще всего затрагиваются темы, связанные со способами и проблемами оценки стартапа, с особенностями привлечения венчурного инвестирования. Но мало исследований посвящено внутренним проблемам стартап-проектов, таким как особенности управления ими.
В связи с этим актуальность исследования обуславливается недостаточной освещенностью проблемы управления стартапами с одной стороны и возрастающим вниманием к стартапам в сфере информационных технологий с другой.
Объектом исследования является методология управления стартапами на основе методологии управления проектами в сфере информационных технологий.
Предметом исследования выступает методология управления IT-стартапа «Wawe».
Целью исследования является определение подходящей методологии проектного управления для команды IT-стартапом «Wawe» с последующей оценкой эффективности её внедрения.
В соответствии с целью данной работы был определен ряд задач:
.Проанализировать теоретические материалы по теме управления информационными проектами, рассмотрев основные международные и локальные стандарты по управлению проектами в IT;
.Выявить, какими инструментами и методами управления пользуются команды управления стартапами в сфере информационных технологий;
.Оценить особенности, сильные и слабые стороны применяемых проектных моделей управления стартапами в IT;
.Выявить особенности управления стартапом «Wawe»;
.Выбрать, модифицировать и внедрить наиболее релевантную модель управления стартапом «Wawe»;
.Оценить результаты внедрения методологии управления стартапом на базе методологии управления 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) предложили два подхода к жизненному циклу инвестирования. Первый подразумевает деление проекта на стадии, тесно связанные с жизненным циклом проекта:
.Стартап, то есть начало;
.Развитие продукта;
.Бета-тестирование;
.Налаживание поставок;
.Точка прибыльности;
.«Клинические испытания» или перезапуск.
Другой подход подразумевает деление жизненного цикла стартапа на две большие группы: начальный этап и поздний этап. Этот подход подразумевает получение финансирования стартапом в несколько раундов в зависимости от нахождения на разном этапе жизненного цикла.
Вестерфилд и Джаффе (2010) предлагают следующую модель жизненного цикла для стартапа, взятую из статьи Бруно и Тибже (2010), в соответствие с которой этапы стартапа связаны в основном с финансированием. Она тесно коррелирует с моделью жизненного цикла Гомперса и Лернера (2004). В ней используются следующие уровни:
.Посевные инвестиции, т.е. небольшой объем инвестиций, необходимый для запуска стартап-проекта с целью обоснования жизнеспособности идеи;
.Инвестиции старта — финансирование на разработку продукта и .Первый раунд инвестирования — это финансирование, направленное на запуск производства и продаж;
.Второй раунд инвестирования — поддержка продаж, особенно в случае если продукт стартапа не приносит прибыли;
.Третий раунд инвестирования — финансирование на расширение деятельности по достижении точки прибыльности;
.четвертый раунд инвестирования — финансирование с публичного размещения акций.
существуют другие модели рассмотрения жизненного цикла стартапа на основе этапов финансирования. Так, Пури и Царутский (2008) в своей статье предлагают модель, внедренную в VentureXpert. В ней предусмотрено пять этапов, однако она почти в точности похожа на выше упомянутую модель Бруно и Тибже. У неё нет принципиальных преимуществ перед моделями Гомперса и Лернера (2004).
Все рассмотренные модели сходятся в ключевом для данной работы принципе. Успешным окончанием стартапа может являться:
·Поглощение стартапа крупной компанией;
·IPO;
·Трансформация в устойчивый бизнес после агрессивного расширения.
Сам стартап-проект должен иметь свой жизненный цикл, внутри которого существует жизненный цикл разрабатываемого ПП. Особенности жизненного цикла продукта в IT-стартапе продиктованы особенностями информационных технологий. У программного продукта для управления жизненным циклом используется модель SDLC (Software Development Life Cycle). SDLC — это система из 6 этапов разработки IT продукта проектной командой целом (Marakas, OBrien, 2010). На сегодняшний день существует несколько актуальных методологий управления жизненным циклом IT проекта. Но все они состоят из подробного плана, описывающего, как развить, сохранить, заменить, изменить или усложнить программное обеспечение. жизненный цикл определяет методологию для повышения качества программного обеспечения (Далее — ПО) и улучшения процесса разработок в целом (Marakas, OBrien, 2010).
этап 1. Планирование и анализ системы: анализ требований является наиболее важным и основополагающим этапом в SDLC. Это этап реализуется командой управления проектом на основе данных от клиентов, отдела продаж, исследований рынка и домен-специалистами в этой отрасли. затем полученная информация используется для планирования проекта и проведения технико-экономического обоснования продукта в экономической, эксплуатационной и технической областях. Планирование требований по обеспечению качества и идентификация рисков, связанных с проектом осуществляется также на этапе планирования. Результаты технико-экономического обоснования необходимы для определения технического подхода, которому можно следовать для успешной реализации проекта с минимальными рисками.
Этап 2. Определение требований: после того, как выполнен анализ требований команда проекта переходит к следующему шагу — детальное определение и документирование требований к продукции и их утверждение с заказчиком. Формируется документ, который содержит все требования к продукту, которые должны быть разработаны и выполнены в ходе жизненного цикла проекта.
Этап 3. Дизайн системы: Только когда сформированы требования к продукту, команда проекта переходит к фазе дизайна. На этой фазе планируются какие элементы и компоненты системы будут внедрены в систему, включая различные модули, архитектуру, интерфейсы, типы данных и уровни безопасности. Классически дизайн сначала прототипируется графически на листах бумаги, чтобы определить общий вектор вида и функционирования системы. После этого уже выполняется более детальный анализ разрабатываемой системы, с опорой на все функциональные и технические требования.
Этап 4. Разработка — внедрение — развертывание: Это ключевая фаза, в которой пишется код программного продукта. Она возможна уже после формирования дизайна. Эта фаза традиционно занимает большую часть времени разработки ПП. Для проекта на этой стадии уже возможна установка в «боевом» режиме у заказчика, а для стартапа запуск бета-тестирования, то есть тестирования в котором задействованы потенциальные пользователи.
Этап 5. Опытная эксплуатация и интеграция: Это этапа тестирования, в котором либо специальная группа команды проекта, либо пользователи ПП, либо специальные программы оценивают, как ведет себя система при входе различных данных в нее. Крайне важная стадия для IT-проектов, так и для стартапов, так как она позволяет понять удовлетворенность продуктом пользователя, и в случае необходимости внести изменения в продукт.
Этап 6. Поддержка системы: Также является традиционной фазой, в которой команда IT-стартапа следит за функционирование системы, выпускает модификации, если необходимо, расширяет функционал, чтобы продукт соответствовал требования внешней среды целом (Marakas, OBrien, 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 основных принципов. Основные идеи:
·Взаимодействие людей и их способности важнее применяемых процессов и инструментов;
·Продукт важнее документации;
·Тесное взаимодействие с заказчиком важнее согласований условий контрактов;
·Готовность и способность к изменениям важнее первоначального плана;
Основные принципы «Манифеста гибкой методологии разработки программного обеспечения»:
·Простота как Искусство не делать лишних работ;
·Тенденция к само организованным командам;
·постоянная готовность искать и осуществлять изменения;
·Фокус на улучшении технического мастерства и удобства дизайна;
·Участники проекта должны поддерживать постоянный темп работ;
·Лучшим измерителем прогресса является работающее ПО;
·Рекомендуемый метод обмена информацией — личные разговоры;
·Проектом занимаются мотивированные личности;
·Постоянный контакт заказчика и исполнителя;
·Еженедельная, ежемесячная поставка рабочего ПО;
·Способность принимать изменения даже в конце сроков проекта;
·Удовлетворение клиента путем предоставления ценного ПО.
Гибкие методологии в управлении информационными проектами подразумевают:
.Вовлечение конечных пользователей продукта имеет определяющее .Принятие решений должно основывать на высокой эффективности команды;
.Основа работы — это этапность и цикличность;
.Концентрация на промежуточных результатах с обязательным представлением продукта;
.Используется модель эффективности Паретто 80/20;
.Применение коллективного подхода при реализации плана;
.Переход к следующему этапу производится только после завершения предыдущего.
Как видно из принципов Agile-методологии, её использование рационально в интеллектуальных сферах бизнеса, таких как стал активно внедряться в организациях в последнее десятилетие ввиду малой эффективности классических подходов управления проектами. Этому поспособствовало следующие тенденции рынка (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. взаимосвязь между количеством проектов, выполняемых одновременно и потерями времени из-за переключения между проектами.
Количество проектов, выполняемых одновременноВремя, потраченное на проектПотери времени из-за приключения между проектами1100%0%240%20%320%40%410%60%55%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.
Данная компания является представителем продуктовых IT-стартапов, то есть основной вид её деятельности — это разработка программного продукта, с целью вывода его на Рынок.
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. Результаты опроса фокус-группы по ключевым показателям продукта.
AndroidiOSN/A12345Ср.N/A12345Ср.(x1)977222,32256322,6(x2) 257853,3126653,6(x3) 654663,0112794,1(x4)11267103,71234104(x5)1587422,51356412,6(x6)4686212,02447212,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).
AndroidiOSN/A12345Ср.N/A12345Ср.(x1)5754332,14544211,9(x2)4974211,84463211,9(x3)41272111,54144522,55(x4)6454442,35244322,2(x5)(x6)41661001,141140101,15
Таблица 7. Результаты опроса фокус-группы по ключевым показателям продукта (05.05.17).
AndroidiOSN/A12345Ср.N/A12345Ср.(x1)11236144,02223563,25(x2)257853,3 112794,1(x3)1345683,3 202884(x4)1267113,9 0333114,1(x5)246693,6126473,7(x6)2454752,91323653,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» была определена подходящая методология управления, которая подтвердила свою эффективность.
список литературы
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: #»justify»>.Макконнелл Стив. влияние итеративных подходов на предварительные условия // Совершенный код = Code Complete. — русская Редакция, Питер, 2005. — С. 31. — 896 с.;
.Мартин Роберт С., Джеймс В. Ньюкирк, Роберт С. Косс. быстрая разработка программ. Принципы, примеры, практика = Agile software development. Principles, Patterns, and Practices. — Вильямс, 2004. — 752 с.;
7.Мошкин И. В. исследование процессов современного предпринимательства. — М.: Директ-Медиа, 2014. — 342 с.;
.Орлова Анастасия Андреевна, Иншаков Максим Олегович. инновационные стартапы в России: проблемы создания и маркетингового продвижения (рус.) // Вестник Волгоградского государственного университета. Серия 3: Экономика. Экология. — 2014. — № 1. — С. 66-75;
.Паштова Л.Г., Баев Г.О. актуальные проблемы стартапов (малых производственных предприятий) в экономике россии // Финансовая аналитика: проблемы и решения. 2015.
.Петренко В.А., Демьяненко Н.Г., Крюкова А.А. Методологии управления стартап-проектами // проблемы экономики и менеджмента. 2017.
11.Basu, A. et al., 2008. The Oxford handbook of entrepreneurship [electronic resource] M. Casson & O. H. Online, eds., Oxford5: Oxford University Press.;
.Blank, S., 2013. Why the Lean Start-Up Changes Everything. Harvard Business Review, 65(May);
.Blank, S. & Dorf, B., 2012. The Startup Owners Manual. The Step-by-Step Guide for Building a Great Company First Edit., K&S Ranch Publishers, Inc.;
.Daniel, J. & John, D., 2009. Agile Project Management — Agilism Versus Traditional Approaches. The Journal of Computer Information Systems, 49(2), pp.10-17.;
15.Edivandro Carlos Conforto, Daniel Capaldo Amaral, Sergio Luis da Silva, Ariani Di Felippo Dayse, Simon L. Kamikawachi The agility construct on project management theory // International Journal of Project Managemnet,- 2016;
.Ganesh, N. & Thangasamy, S., 2012. Lessons Learned in Transforming from Traditional to Agile Development. Journal of Computer Science, 8(3), pp.389-392.;
17.Gompers, P. & Lerner, J., 2004. The venture capital cycle 2nd ed., Cambridge, Mass.5: MIT Press.;
.James A. Highsmith. Agile Software Development Ecosystems. — Addison-Wesley Professional, 2002.;
.Mandela Schumacher-Hodge. You Think Youre a Startup, But Youre Really a Small Business (and thats totally cool too) [электронный ресурс] URL: https://medium.com/swlh/you-think-you-re-a-startup-but-you-re-really-a-small-business-and-that-s-totally-cool-too-cd45ff80e6be
.Marakas, James A. O’Brien, George M. (2010). Management information systems (10th ed.). New York: McGraw-Hill/Irwin. pp. 485-489;
21.Moran A., Managing Agile: Strategy, Implementation, Organisation and People, — Springer Verlag, — 2015;
.McHugh, O. & Hogan, M., 2011. Investigating the rationale for adopting an internationally-recognised project management methodology in Ireland: The view of the project manager. International Journal of Project Management, 29(5), pp.637-646.;
23.Nicholls, Gillian; Lewis, Neal; Eschenbach, Ted (2015). "Determining when simplified Agile Project Management is right for small teams". Engineering Management Journal. 27 (1): 5;
24.Paul Graham. Hackers and Painters: Big Ideas from the Computer Age. — O’Reilly, 2004. — 272 p.;
.Paul Miller. Zero to One summary: Peter Thiels advice on startups, — December 2014, — M. Casson & O. H. Online, eds., Oxford5: Oxford University Press.;
.Ross, S., Westerfield, R. & Jaffe, J., 2010. Corporate Finance 9th ed., McGraw-Hill/Irwin.;
.Royce, Winston, Managing the Development of Large Software Systems, — 1970;
.Serrador P., Pinto J.K. Does Agile work? — A quantitative analysis of agile project success // International Journal of Project Management,- 2016;
приложение
Российский рынок IT услуг в сегменте B2B, млрд. руб.
Темы роста рынка ИТ в россии 2014-2017.
Сравнение гибких методологий
SCRUMXPTDDСтепень неопределенности продуктаВысокая неопределённость продуктаСредняя неопределенность продуктаСредняя неопределенность продуктаОптимальное количество участников7 (+/-2)ЛюбоеЛюбоеВажность мотивации командыДаНетНетЧувствительность к высокому профессионализму команды разработчиковНетДаДаПредполагаемая высокая частота контакта с пользователем (чаще 2 раза в неделю)НетДаДаФокус на качество выше фокуса на срокиДаНетНетФокус на ограниченность бюджетаНетНетНетНизкая вычислительная сложность разрабатываемого ПОДаДаНетПростота примененияДаДаНетПредполагаемая возможность быстрого изменения методологииНетДаНет
AgileUPOpenUPDSDMСтепень неопределенности продуктаВысокая неопределённость продуктаВысокая неопределённость продуктаВысокая неопределенность продуктаОптимальное количество участников6(+/-3)57Важность мотивации командыДаДаДаЧувствительность к высокому профессионализму команды разработчиковНетНетДаПредполагаемая высокая частота контакта с пользователем (чаще 2 раза в неделю)ДаДаДаФокус на качество выше фокуса на срокиДаНетНетФокус на ограниченность бюджетаНетНетДаНизкая вычислительная сложность разрабатываемого ПОДаНетДаПростота примененияДаНетНетПредполагаемая возможность быстрого изменения методологииНетДа
ASDKanbanFDDСтепень неопределенности продуктаСредняя неопределённость продуктаСредняя неопределённость продуктаСредняя неопределенность продуктаОптимальное количество участников10Меньше 5Больше 10Важность мотивации командыНетДаНетЧувствительность к высокому профессионализму команды разработчиковДаНетДаПредполагаемая высокая частота контакта с пользователем (чаще 2 раза в неделю)ДаНетДаФокус на качество выше фокуса на срокиНетДаНетФокус на ограниченность бюджетаДаНетНетНизкая вычислительная сложность разрабатываемого ПОНетДаНетПростота примененияНетДаНетПредполагаемая возможность быстрого изменения методологииНетДаДа
Транскрипт интервью с креативным директором «Wawe».
добрый день, Кирилл!
Привет!
Мы договаривались провести интервью по поводу подходов к управлению стартапом Wawe
Да
Давай начнем. Итак, как давно ты находишься в команде управления стартапом?
чуть меньше двух лет. До этого я был соучредителем другого стартапа Lazerto, но дела пошли в гору, и нам пришлось отказаться от проекта. Мы с Дмитрием Кочергиным решили основать стартап Wawe после той неудачи, собрали новую команду и начали работать
Что по твоему мнению не хватило стартапу Lazerto?
У нас много времени ушло на то, чтобы разобраться с распределением обязанностей и организации правильного русла работы. Хочу сказать, что сама идея была отличная, это был 2013-2014гг, люди начали беспокоиться о защите данных после ряда знаменитых случаев вскрытия утечек. Ты, наверное, слышал. Наша команда хотела предложить дружелюбный и защищенный поисковик. Он был более лайтовым, чем Tor, и в этом была его простота и привлекательность
В конечном счете вы закрыли проект после чего?
У нас были арендованы сервера в Нидерландах, нанята большая команда стартапа. В итоге в какой-то момент просто не хватало денег на все. сначала мы сократили команду, но готовый продукт никак не получался, тогда мы отказались от качественных серверов. В итоге все посыпалось. В нас перестали верить участники команды.
Если бы сегодня вы начали проект Lazerto заново, что бы Вы поменяли?
Нуу… Мы бы, наверное, не арендовали сразу дорогие сервера, ведь по сути в них не было необходимости, пока количество пользователей не достигло бы хотя бы числа 10000. Также я бы не стал бы без разбору брать друзей в команду стартапа. Да, с ними комфортно находится и работать, но сложно их обязывать к чему-то, тем более подчиняться тебе.
Что для Вас стартап: продукт, Рынок или люди?
Я отвечу, что продукт. По сути его делаем в условиях рынка и для людей.
Тут как посмотреть. Хорошо. Давайте вернемся к стартапу Wawe. Итак, вы начали новый проект, новая команда, новый продукт. Что изменилось в рабочем процессе и управлении по сравнению с Вашим предыдущим опытом.
Всё изменилось. Мы не раздували большую команду. Она состояла из только нужных людей. У нас на стратегическом уровне было понимание, что нужно сначала сделать продукт, потом его протестировать, внести доработки и запустить полноценную кампанию по продвижению. Поэтому необходимо сначала взять в команду только разработчиков и финансового специалиста.
А что насчет получения инвестирования? Это в планы входило?
Да, разумеется. Но мы относились к этому, как к инструменту, необходимому для реализации намеченных планов.
Кто занимался поиском инвестиций и их привлечением?
В основном этим занимался я и Дима. Мы ходили к разным инвесторам, искали их в Facebook, искали среди знакомых. В итоге мы нашли после двух месяцев поиска человека. Он просил не называть его имя, но он вложил около 200000$ сначала проекта и ещё 100000$ в течение полутора лет.
В какой форме было получено финансирование?
Инвестор получил долю в компании. Я не будем разглашать какую именно, но в пределах 5-20%.
Понял. Как у вас организован рабочий процесс в целом у стартапа? И как он выглядит ежедневно?
Как я уже говорил, мы сделали на стратегическом уровне план развития, который предполагал создание продукта вначале. Мы сформировали команду разработчиков из двух по платформе Android и двух специалистов backend — разработки. Также пришлось нанять студию разработки по направлению iOS, потому что у нас не получилось найти нормальных специалистов за устраивающие нас деньги. Что касается каждого дня, то он выглядит следующим образом. Все приезжают к 10 в наш офис, арендуемый в бц Arma. Разработчики продолжают работу над планируемым продуктом, если это понедельник или четверг, то я контактирую с студией разработки, и они показывают прогресс, а также запрашивают корректировки, если таковые необходимы. Работать заканчиваем часов в 7-9, потому что все вовлечены в процесс и никого не выгонишь из офиса (смеется).
Меня интересует какая документация существует по планированию и регламентированию работ?
У нас есть план-график на месяц, раздробленный по неделям. Есть финансовый план, в котором ведется расчет будущих затрат на заработную плату, аренду офиса и контракт с студией разработки.
Ведется ли какая-нибудь работа по управлению рисками?
Нуу.. Мы знаем, какие риски могут случится, но мы не записывали их.
хорошо. А есть какие-нибудь мероприятия по учету интересов заинтересованных сторон?
Нет.
Стартап — это малый бизнес в условиях высокой неопределенности. Значит, необходимо быть готовым к изменениям, которые продиктованы извне. Например, появился аналогичный сервис или деньги обесценились, в общем много причин. Как вы готовы к изменениям? Как ищите их?
Мы следим за рынком, какие сервисы выходят, как меняются существующие. Так, недавно появились Instagram Stories, который похожи с концептом нашего продукта — удаляющихся записей с течением времени.
Вы решили поменять свое приложение?
Нет. Мы думаем, что это не единственная фича, которая будет интересна пользователям. У нас будут также особенные «лайки», модуль достижений и особенно приятный глазу дизайн.
Вы же слышали про гибкие методологии управления проектами?
Да
Применяете ли Вы Agile в своем стартапе? И если да, то в чем он выражается?
Да, мы применяем agile. У нас нет жесткой иерархии, каждый участник команды может предложить идеи и все открыты для обсуждений. Мы стараемся использовать доску, на которой пишутся карточки с заданиями для работ. Карточку берет сотрудник и приступает к работе.
существуют какие-то правила для использования карточек с заданиями на доске?
правило только в том, что нахождение карточки на доске соответствовало реальному положению задачи. А в остальном всё гибко.
Были случаи серьезного срыва по срокам или стоимости планируемых работ?
Да, было пару случаев. чаще всего это было связано с тем, что мы с разработчиками посчитали задачу простой для нашей команды, но по факту они занимали куда больше времени. По стоимости не было серьезных срывов, так как статьи расхода привязаны к количеству рабочих часов.
сложно управлять стартапом?
Управлять, наверное, несложно, когда ты едешь за рулем машины, у которой ты знаешь все заводские характеристики, текущие характеристики и видишь, и просто интерпретируешь, что происходит на улице, также есть ПДД, которым ты следуешь. А вот когда ты садишься за руль непонятного средства в непонятной стране, где нет правил управлять сложно. Сложно, потому что ты не знаешь ни при каких условиях транспорт сломается, ни куда ты едешь даже. поэтому сложно. Мы читаем книги, общаемся с другими стартаперами, не люблю это слово, но всё же. Набираемся опыта от них, видим истории успеха и в какие стартапы вкладываются инвесторы. Но, когда дело доходит до практики появляются сложности.
Спасибо, Кирилл за интервью!
Пожалуйста, Андрей. Рад помочь!
Опрос для фокус-группы.
Укажите Ваш возраст *
·Меньше 18
·18-19
·20-21
·22-23
·24-25
·Старше 25
Укажите Ваш пол *
·Мужской
·женский
Сколько часов в день Вы проводите с смартфоном? *
·Меньше 1 часа
·1 час
·2 часа
·3 часа
·4 часа
·больше 4 часов
На какой платформе Ваш смартфона *
·Android
·iOS
Оцените понятность интерфейса Wawe?
·1 полностью непонятно
·2
·3
·4
·5 Полностью понятно
Оцените быстроту отклика Wawe?
·1 очень медленно
·2
·3
·4
·5 Очень быстро
Оцените плавность работы Wawe?
·1 Очень резко
·2
·3
·4
·5 Очень плавно
Оцените Wawe?
·1 Совершенно неприятный
·2
·3
·4
·5 Очень приятный
Совпадают ли Ваши ожидания от аннотации к приложению с приложением Wawe
·1 Совершенно не совпадают
·2
·3
·4
·5 совершенно совпадают
Оцените вероятность использования приложения Wawe в её текущем виде?
·1 точно не буду пользоваться
·2
·3
·4
·5 Точно буду пользоваться
Предложите ли Вы своим знакомым или друзьям скачать приложение Wawe?
·1 Точно не предложу
·2
·3
·4
·5 точно предложу