СОДЕРЖАНИЕ
Глава 1. Применимость проектной методологии в IT-стартапах
1.1 Взаимосвязь стартапа и проекта
.2 Подходы к жизненному циклу IT-стартапа
.3 Подходы к определению ролей в IT-стартапе
.4 Методологии управления IT проектами
.5 Особенности внедрения гибких методологий в IT-стартапы
Глава 2. Применение проектной методологии в стартапе «Wawe»
.2 Анализ опыта разработки первого продукта стартапа «Wawe»
.3 Выбор проектной методологии для стартапа «Wawe»
.4 Результаты применения проектной методологии для стартапа «Wawe»
Глава 1. Применимость проектной методологии в IT-стартапах
1.1 Взаимосвязь стартапа и проекта
1.2 Подходы к жизненному циклу IT-стартапа
1.3 Подходы к определению ролей в IT-стартапе
1.4 Методологии управления IT проектами
1.5 Особенности внедрения гибких методологий в IT-стартапы
Глава 2. Применение проектной методологии в стартапе «Wawe»
2.2 Анализ опыта разработки первого продукта стартапа «Wawe»
2.3 Выбор проектной методологии для стартапа «Wawe»
2.4 Результаты применения проектной методологии для стартапа «Wawe»
Так как неопределенность внешней среды является ключевым фактором для стартапа, то мы исключим из выбора 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 излишней для данной методологии формализованностью рабочего процесса. Гипотетически такая облегченная методология должна эффективно функционировать в команде стартапа.
С января 2017 года новый продукт компании «Wawe» - «Wave x». Данное приложение по сложности разработок соответствовало первому приложению «Wawe». ЦА у нового приложения сохранилась. Но «Wave x» в отличие от первого продукта разрабатывался с использованием предложенной гибкой методологии управления проектом на основе Scrum и Kanban. Она отличается от способа управления стартапом Wawe более тесным контактом с пользователями и предсказуемой организацией процесса разработки продукта даже в условиях меняющихся требований.
Так первый график Burndown после первого спринта для направления Android выявил низкую производительность команды
разработчиков стартапа:
График
1. Burndown chart для первого спринта.
Благодаря этому была выявлена проблема оценки сложности планируемых работ для направления iOS. Если раньше в команде считалось, что набор задач (x) на первый день должна выполняться 8 часов, то в действительности он требовал больше времени разработки ввиду сложности или неопытности разработчиков. Учесть подобную ошибку при инициации внедрения проектной методологии почти невозможно, соответственно для будущих стартапов можно посоветовать только экспериментировать, так как оценка трудозатрат на планируемые задачи зависит как от профессионализма команды и её сплоченности, так и от самой задачи.
В итоге после доработок по результатам второго месяца автором данной ВКР была разработана следующая схема управления стартапом на основе гибких методологий управления проектами:
На данной блок-схеме ромбами отмечались субъекты управления, прямоугольниками - артефакты стартапа (регламенты управления, продукт), овалами - процессы стартапа. Пунктирные стрелки показывают передачу информации, а сплошные - переход к этапам.
Данная модель подразумевает учет внутренних и внешних факторов, влияющих на эффективность управления. После каждой итерации получается минимальный жизнеспособный продукт. После данного этапа производится два параллельных процесса, один из которых направлен на оценку данного продукта со стороны ЦА, а другая на оценку эффективности произведённой итерации. По результатам этих процессов вносятся необходимые изменения в пул функциональных требований к разрабатываемому продукту, а также вносятся изменения в регламент производимых разработок.
Гибридная модель несколько отличается от традиционного Scrum, что еще подтверждает то, что проектная методология IT-стартапа должна не просто применять лучшие практики и желаемую методологию, а опираться на внутренние и внешние условия компании.
Также согласно манифесту Agile и исследованию Дагаева А.А. и Лутфулина М. А. (2015), выполняется важный принцип простоты методологии для субъекта малого бизнеса.
В случае «Wawe» в результате подобных анализов была улучшена система оценки планируемых этапов разработки программного продукта:
· Менялась оценка сложности различных задач для обеспечения более точного планирования сроков и качества итерации;
· Выявлялись проблемы продукта и пожелания потенциальных пользователей к качеству;
Новому продукту компании «Wawe» понадобилось 4 месяца, чтобы запуститься. Первый месяц был наименее эффективен после внедрения. Это связано во много с тем, что команде стартапа пришлось перестраивать подход к управлению и разработки. Также возникали сложности с определение весов задач, для равномерного наполнения спринтов-итераций. Но к началу февраля 2017 года был получен минимальный жизнеспособный продукт (MVP). Он не отражал потенциал планируемого приложения, но обладал дизайном и некоторыми функциями. По окончании первого спринта был проведен опрос фокус-группы, который выявил отправные данные для направлений работы. Ниже приведено сравнение опросов фокус-группы после первого спринта и после финальной версии приложения «Wave x». Конечно данная статистика не может оценить будущий успех стартапа в целом, так как перед компанией встала новая задача выхода на рынок и расширения количества пользователей. Но зато она показывает, что одно из требований, которое сформировано у Риса Э. и Бланка С. к успешному стартапу выполнено - это удовлетворенность потенциальных пользователей и создание ценности для них.
В опросе фокус-группы ЦА после первой итерации не учитывались ответы по
вопросу (x5), так как в аннотации к приложению
для первого MVP нет необходимости. Ведь продукт не
обладает еще планируемым функционалом.
Таблица 6. Результаты опроса фокус-группы по ключевым показателям продукта (03.02.17).
|
|
Android |
iOS |
|||||||||||||
|
|
N/A |
1 |
2 |
3 |
4 |
5 |
Ср. |
N/A |
1 |
2 |
3 |
4 |
5 |
Ср. |
|
|
(x1) |
5 |
7 |
5 |
4 |
3 |
3 |
2,1 |
4 |
5 |
4 |
4 |
2 |
1 |
1,9 |
|
|
(x2) |
4 |
9 |
7 |
4 |
2 |
1 |
1,8 |
4 |
4 |
6 |
3 |
2 |
1 |
1,9 |
|
|
(x3) |
4 |
12 |
7 |
2 |
1 |
1 |
1,5 |
4 |
1 |
4 |
4 |
5 |
2 |
2,55 |
|
|
(x4) |
6 |
4 |
5 |
4 |
4 |
4 |
2,3 |
5 |
2 |
4 |
4 |
3 |
2 |
2,2 |
|
|
(x5) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
(x6) |
4 |
16 |
6 |
1 |
0 |
0 |
1,1 |
4 |
11 |
4 |
0 |
1 |
0 |
1,15 |
|
Таблица 7. Результаты опроса фокус-группы по ключевым показателям продукта (05.05.17).
|
|
Android |
iOS |
|||||||||||||
|
|
N/A |
1 |
2 |
3 |
4 |
5 |
Ср. |
N/A |
1 |
2 |
3 |
4 |
5 |
Ср. |
|
|
(x1) |
1 |
1 |
2 |
3 |
6 |
14 |
4,0 |
2 |
2 |
2 |
3 |
5 |
6 |
3,25 |
|
|
(x2) |
|
2 |
5 |
7 |
8 |
5 |
3,3 |
|
1 |
1 |
2 |
7 |
9 |
4,1 |
|
|
(x3) |
1 |
3 |
4 |
5 |
6 |
8 |
3,3 |
|
2 |
0 |
2 |
8 |
8 |
4 |
|
|
(x4) |
|
1 |
2 |
6 |
7 |
11 |
3,9 |
|
0 |
3 |
3 |
3 |
11 |
4,1 |
|
|
(x5) |
|
2 |
4 |
6 |
6 |
9 |
3,6 |
|
1 |
2 |
6 |
7 |
3,7 |
|
|
|
(x6) |
2 |
4 |
5 |
4 |
7 |
5 |
2,9 |
1 |
3 |
2 |
3 |
6 |
5 |
3,25 |
|
Как видно из представленных таблиц, общая удовлетворенность по обеим платформам выросла с 1,1 и 1,15 после первого релиза до 2,9 и 3,25 после финального. При этом по платформе iOS выше показатель вероятности использования приложения, во много это объясняется тем, что для iOS работы в целом проходили немного легче, так как приложение надо было оптимизировать только под 2 разрешения, тогда как у смартфонов под платформой Android вариантов значительно выше. Также, что особенно важно для данного стартапа, улучшилась общая удовлетворенность продуктом по сравнению с первым опытом разработки приложения Wawe: с 2,0 и 2,3 до 2,9 и 3,25 для платформ Android и iOS соответственно.
Общая эффективность проводимых работ была значительно лучше. Продолжая наблюдение за рабочим процессом было выявлено значительный прогресс в производительности. Отклонения от планируемых работ по графикам burndown снизились в среднем на 10-15%. Разработчики после освоения данной методологии знали, что необходимо делать и в какой последовательности. После постоянных внесений корректировок после опросов фокус-группы, команде пришло осознание создания ценности для пользователей.
Внедренная методология подразумевала мероприятия по управлению проектом. Это выражалось в инструментах итеративного подхода к разработке, который учитывал интересы будущих пользователей и давал возможность команде «Wawe» не выпускать сразу продукт, который не отражал желаемых характеристик ЦА, а каждый раз менять какие-либо свойства, благодаря опросам фокус-группы. Также благодаря burndown графиков и плану планируемых задач в итерации появился инструмент управления сроками и стоимостью. В итеративном подходе заключается также управление качеством.
Ежегодно количество стартапов увеличивается, особенно эта тенденция затрагивает высокотехнологические направления, такие как информационные технологии. Как следствие увеличивается интенсивность конкуренции, и, результате, мало иметь отличный продукт, необходимо улучшать управление стартапами. Источником методологий для применения является проектная деятельность, так как анализ теоретических источников выявил сходства стартапов с проектами по параметрам временности, ограниченности бюджета и создании уникального продукта. Однако стоит помнить, что у стартапов есть свои особенности, которые необходимо учитывать при внедрении методологий управления. Особенно это касается неопределенности внешней среды и пролонгированием деятельности стартапа в устойчивый бизнес.