Применимость проектной методологии в IT-стартапах
Проведение исследования основных международных и локальных стандартов по управлению проектами в информационных технологиях. Характеристика сравнения стартапа и организаций малого бизнеса. Главные особенности внедрения гибких методологий в IT-стартапы.
Рубрика | Менеджмент и трудовые отношения |
Вид | дипломная работа |
Язык | русский |
Дата добавления | 22.08.2017 |
Размер файла | 522,1 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Также в команде есть команда бэкенд и фронтенд разработки. Она насчитывает 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 в компаниях:
1. Низкий уровень осведомленности об Agile (23,5%);
2. Консерватизм к подходу к работе (17,6%);
3. Непонимание руководством ценностей гибких методологий (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);
2. Быстрота отклика (x2);
3. Плавность использования (x3);
4. Дизайн (x4);
5. Соответствие ожиданиям из аннотации приложения (x5).
6. Вероятность пользования при текущем виде (x6).
Ниже приведены результаты анкетирования.
Таблица 5. Результаты опроса фокус-группы по ключевым показателям продукта.
Android |
iOS |
||||||||||||||
N/A |
1 |
2 |
3 |
4 |
5 |
Ср. |
N/A |
1 |
2 |
3 |
4 |
5 |
Ср. |
||
(x1) |
9 |
7 |
7 |
2 |
2 |
2,3 |
2 |
2 |
5 |
6 |
3 |
2 |
2,6 |
||
(x2) |
2 |
5 |
7 |
8 |
5 |
3,3 |
1 |
2 |
6 |
6 |
5 |
3,6 |
|||
(x3) |
6 |
5 |
4 |
6 |
6 |
3,0 |
1 |
1 |
2 |
7 |
9 |
4,1 |
|||
(x4) |
1 |
1 |
2 |
6 |
7 |
10 |
3,7 |
1 |
2 |
3 |
4 |
10 |
4 |
||
(x5) |
1 |
5 |
8 |
7 |
4 |
2 |
2,5 |
1 |
3 |
5 |
6 |
4 |
1 |
2,6 |
|
(x6) |
4 |
6 |
8 |
6 |
2 |
1 |
2,0 |
2 |
4 |
4 |
7 |
2 |
1 |
2,3 |
Как видно из полученной таблицы, команда стартапа «Wawe» выпустила неудовлетворительный продукт по ключевой характеристике о потенциале использования приложения. В среднем по этому показателю были получены 2,0 по платформе Android и 2,3 по платформе iOS. При этом по показателям, связанным с удобством приложения (x1), (x2), (x3), (x4) получены сравнительно высокие оценки по обеим платформам.
Для данной работы эти показатели важны с точки зрения потенциальной адекватности применения именно гибкой методологии, которая предполагает тесное взаимодействие с пользователем. В условиях меняющейся внешней среды и функционального наполнения текущих приложений необходимо вносить изменения в программный продукт для удовлетворения ожиданий потребителя.
2.3 Выбор проектной методологии для стартапа «Wawe»
Несмотря на то, что для стартапа «Wawe» будет выбрана одна из методологий управления проектами, для каждого стартапа выбор будет свой, в зависимости от особенностей внутренней и внешней среды. Но на примере стартапа «Wawe» возможно разобраться в том, какие факторы внутренней и внешней среды будут определяющими для применения той или иной методологии.
Для компании «Wawe», по результатам проведенного глубинного интервью, анализа внутренних механизмов рабочего процесса, особенностей управления и внешней среды, а также по результатам теоретического обзора ключевых условий применения различных проектных методологий в стартапе был сформирован следующий ряд условий, влияющих на выбор проектной методологии:
1. Существование команды Wawe в рамках одного коллектива более 1 года;
2. Высокая мотивация сотрудников;
3. 9 участников стартапа (из них 3 - команда управления стартапом, а 6 - команда разработчиков)
4. IT-стартап, занятый в сфере разработки ПО для сегмента B2C;
5. Низкая вычислительная сложность разрабатываемого ПО;
6. Высокая неопределенность внешней среды;
7. Нечетко определены требования к ПП;
8. Стартап функционирует в условиях ограниченности бюджета;
9. Интерфейс пользователя важнее функциональности разрабатываемого ПП;
10. В рамках проекта разрабатывается два продукта (iOS и Android);
11. Простота использования проектной методологии;
Для выбора методологии воспользуемся сформированной таблицей сравнения (приложение 3) по результатам анализа каждой из методологий.
Так как неопределенность внешней среды является ключевым фактором для стартапа, то мы исключим из выбора RUP, RAD, MSF и Cleanroom Softaware Development, которые предполагают конкретные требования к продукту и, соответственно, не подходят как для стартапа «Wawe», так и для подавляющего большинства IT-стартапов. По этой же причине не подойдет PMBOK, PRINCE2 и APM BoK.
Сравнив положительные и отрицательные стороны выбранных методологий, было получено, что для стартапа «Wawe» в силу выше перечисленных ограничений и возможностей, подходят две гибкие методологии: Scrum и Kanban. Это продиктовано тем, что эти методологии обладают сравнительно простотой внедрения, применения и понимания со стороны команды стартапа. Также они подошли по важному критерию размера команды и ролевого распределения (6 +/- 3 человека) и фокусом на качество. Сравнительным плюсом данных методологий также в том, что они могут использоваться не только в рамках разработки отдельного продукта, но и в рамках управления стартапом в целом.
Scrum более директивная проектная методология по сравнению с Kanaban. Так, например, в итерацию Scrum (бэклог) нельзя добавлять новые задачи. Но при этом она содержит больше инструментов и конкретных практик. Поэтому исходя из особенностей разрабатываемого продукта (простота и важность удовлетворения пользователей) и особенностей стартапа, как находящегося на начальном этапе жизненного цикла, но уже с сформировавшейся командой, характеризующейся высокой мотивацией была выбрана гибридная гибкая методология управления проектом на основе Scrum и Kanban.
Предложенная стартапу «Wawe» методология подразумевала, что команды разработчиков будут сгруппированы по направлениям разработки, т.е. на Android и iOS. Далее вводится роль Product Owner - владельца продукта, которую выполняет креативный директор, он же выполнял функцию контроля исполнения правил (Scrum Master). Для того чтобы видение креативного директора совпадало с ЦА, проводится опрос фокус-группы в конце каждого спринта. Весь проект был разделен на месячные итерации, как для направления iOS, так и для Android. Эти итерации будут называться спринтами согласно терминологии Scrum. Для формирования планируемого функционального наполнения разрабатываемых продуктов будет вестись журнал пожеланий проекта, в который будут занесены планируемые задачи, а также по результатам обратной связи фокус-группы будет наполняться новыми задачами. В данном журнале задачи будут приоритезированны по значимости совместным обсуждение владельца продукта и команды разработчиков. А также им будут присвоены веса для более равномерного наполнения спринтов. Далее из этого журнала будут выбираться задачи к следующему спринту и расставляться по значимости сверху вниз в столбец «To do» в программе Trello, которая заменит доску с соответствующими столбцами. При этом в отличие от традиционно подхода Scrum, чтобы учесть фактор неопределенности в течение спринта владельцу продукта можно будет добавлять задачи в «To do». Также будет вестись учет качества производтельности команд с помощью Burndown chart, как это делается в классическом Scrum. Также из Scrum были взяты 15-минутные встречи команды перед началом рабочего дня, а также анализ проделанной работы в конце спринта. Для оценки эффективности в конце каждой итерации анализировался burndown chart, график на котором по оси y откладывались все рабочие часы на итерацию, а по оси x рабочие дни. И в конце каждого дня на графике отмечается сколько остается чистых часов работы до готового MVP.
В целом полученная гибридная методология отличается от Scrum сравнительной простотой, а от Kanaban излишней для данной методологии формализованностью рабочего процесса. Гипотетически такая облегченная методология должна эффективно функционировать в команде стартапа.
2.4 Результаты применения проектной методологии для стартапа «Wawe»
С января 2017 года новый продукт компании «Wawe» - «Wave x». Данное приложение по сложности разработок соответствовало первому приложению «Wawe». ЦА у нового приложения сохранилась. Но «Wave x» в отличие от первого продукта разрабатывался с использованием предложенной гибкой методологии управления проектом на основе Scrum и Kanban. Она отличается от способа управления стартапом Wawe более тесным контактом с пользователями и предсказуемой организацией процесса разработки продукта даже в условиях меняющихся требований.
Так первый график Burndown после первого спринта для направления Android выявил низкую производительность команды разработчиков стартапа:
График 1. Burndown chart для первого спринта.
Благодаря этому была выявлена проблема оценки сложности планируемых работ для направления iOS. Если раньше в команде считалось, что набор задач (x) на первый день должна выполняться 8 часов, то в действительности он требовал больше времени разработки ввиду сложности или неопытности разработчиков. Учесть подобную ошибку при инициации внедрения проектной методологии почти невозможно, соответственно для будущих стартапов можно посоветовать только экспериментировать, так как оценка трудозатрат на планируемые задачи зависит как от профессионализма команды и её сплоченности, так и от самой задачи.
В итоге после доработок по результатам второго месяца автором данной ВКР была разработана следующая схема управления стартапом на основе гибких методологий управления проектами:
На данной блок-схеме ромбами отмечались субъекты управления, прямоугольниками - артефакты стартапа (регламенты управления, продукт), овалами - процессы стартапа. Пунктирные стрелки показывают передачу информации, а сплошные - переход к этапам.
Данная модель подразумевает учет внутренних и внешних факторов, влияющих на эффективность управления. После каждой итерации получается минимальный жизнеспособный продукт. После данного этапа производится два параллельных процесса, один из которых направлен на оценку данного продукта со стороны ЦА, а другая на оценку эффективности произведённой итерации. По результатам этих процессов вносятся необходимые изменения в пул функциональных требований к разрабатываемому продукту, а также вносятся изменения в регламент производимых разработок.
Гибридная модель несколько отличается от традиционного Scrum, что еще подтверждает то, что проектная методология IT-стартапа должна не просто применять лучшие практики и желаемую методологию, а опираться на внутренние и внешние условия компании.
Также согласно манифесту Agile и исследованию Дагаева А.А. и Лутфулина М. А. (2015), выполняется важный принцип простоты методологии для субъекта малого бизнеса.
В случае «Wawe» в результате подобных анализов была улучшена система оценки планируемых этапов разработки программного продукта:
· Менялась оценка сложности различных задач для обеспечения более точного планирования сроков и качества итерации;
· Выявлялись проблемы продукта и пожелания потенциальных пользователей к качеству;
Новому продукту компании «Wawe» понадобилось 4 месяца, чтобы запуститься. Первый месяц был наименее эффективен после внедрения. Это связано во много с тем, что команде стартапа пришлось перестраивать подход к управлению и разработки. Также возникали сложности с определение весов задач, для равномерного наполнения спринтов-итераций. Но к началу февраля 2017 года был получен минимальный жизнеспособный продукт (MVP). Он не отражал потенциал планируемого приложения, но обладал дизайном и некоторыми функциями. По окончании первого спринта был проведен опрос фокус-группы, который выявил отправные данные для направлений работы. Ниже приведено сравнение опросов фокус-группы после первого спринта и после финальной версии приложения «Wave x». Конечно данная статистика не может оценить будущий успех стартапа в целом, так как перед компанией встала новая задача выхода на рынок и расширения количества пользователей. Но зато она показывает, что одно из требований, которое сформировано у Риса Э. и Бланка С. к успешному стартапу выполнено - это удовлетворенность потенциальных пользователей и создание ценности для них.
В опросе фокус-группы ЦА после первой итерации не учитывались ответы по вопросу (x5), так как в аннотации к приложению для первого MVP нет необходимости. Ведь продукт не обладает еще планируемым функционалом.
Таблица 6. Результаты опроса фокус-группы по ключевым показателям продукта (03.02.17).
Android |
iOS |
||||||||||||||
N/A |
1 |
2 |
3 |
4 |
5 |
Ср. |
N/A |
1 |
2 |
3 |
4 |
5 |
Ср. |
||
(x1) |
5 |
7 |
5 |
4 |
3 |
3 |
2,1 |
4 |
5 |
4 |
4 |
2 |
1 |
1,9 |
|
(x2) |
4 |
9 |
7 |
4 |
2 |
1 |
1,8 |
4 |
4 |
6 |
3 |
2 |
1 |
1,9 |
|
(x3) |
4 |
12 |
7 |
2 |
1 |
1 |
1,5 |
4 |
1 |
4 |
4 |
5 |
2 |
2,55 |
|
(x4) |
6 |
4 |
5 |
4 |
4 |
4 |
2,3 |
5 |
2 |
4 |
4 |
3 |
2 |
2,2 |
|
(x5) |
|||||||||||||||
(x6) |
4 |
16 |
6 |
1 |
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 |
4 |
7 |
3,7 |
|||
(x6) |
2 |
4 |
5 |
4 |
7 |
5 |
2,9 |
1 |
3 |
2 |
3 |
6 |
5 |
3,25 |
Как видно из представленных таблиц, общая удовлетворенность по обеим платформам выросла с 1,1 и 1,15 после первого релиза до 2,9 и 3,25 после финального. При этом по платформе iOS выше показатель вероятности использования приложения, во много это объясняется тем, что для iOS работы в целом проходили немного легче, так как приложение надо было оптимизировать только под 2 разрешения, тогда как у смартфонов под платформой Android вариантов значительно выше. Также, что особенно важно для данного стартапа, улучшилась общая удовлетворенность продуктом по сравнению с первым опытом разработки приложения Wawe: с 2,0 и 2,3 до 2,9 и 3,25 для платформ Android и iOS соответственно.
Общая эффективность проводимых работ была значительно лучше. Продолжая наблюдение за рабочим процессом было выявлено значительный прогресс в производительности. Отклонения от планируемых работ по графикам burndown снизились в среднем на 10-15%. Разработчики после освоения данной методологии знали, что необходимо делать и в какой последовательности. После постоянных внесений корректировок после опросов фокус-группы, команде пришло осознание создания ценности для пользователей.
Внедренная методология подразумевала мероприятия по управлению проектом. Это выражалось в инструментах итеративного подхода к разработке, который учитывал интересы будущих пользователей и давал возможность команде «Wawe» не выпускать сразу продукт, который не отражал желаемых характеристик ЦА, а каждый раз менять какие-либо свойства, благодаря опросам фокус-группы. Также благодаря burndown графиков и плану планируемых задач в итерации появился инструмент управления сроками и стоимостью. В итеративном подходе заключается также управление качеством.
Заключение
Ежегодно количество стартапов увеличивается, особенно эта тенденция затрагивает высокотехнологические направления, такие как информационные технологии. Как следствие увеличивается интенсивность конкуренции, и, результате, мало иметь отличный продукт, необходимо улучшать управление стартапами. Источником методологий для применения является проектная деятельность, так как анализ теоретических источников выявил сходства стартапов с проектами по параметрам временности, ограниченности бюджета и создании уникального продукта. Однако стоит помнить, что у стартапов есть свои особенности, которые необходимо учитывать при внедрении методологий управления. Особенно это касается неопределенности внешней среды и пролонгированием деятельности стартапа в устойчивый бизнес.
Проанализировав литературу по темам: особенности самих стартапов, особенности применения проектного управления в IT-стартапах, а также оценки применимости методологий управления проектами в IT-стартапах в данной выпускной квалификационной работе был предложен подход к применение проектной методологии в IT-стартапе «Wawe».
В рамках написания ВКР был проведен анализ внутренней среды на предмет:
· Особенностей жизненного цикла стартапа;
· Количественного и ролевого состава команды;
· Этап жизненного цикла команды по модели Тукмана;
· Сложность разрабатываемого продукта.
А также осуществлен анализ внешней среды на предмет:
· Неопределенности;
· Влияния стейкхолдеров.
В связи с тем, что рассматриваемый стартап «Wawe» находится на начальном этапе жизненного цикла команды и проекта, количество участников в нем небольшое (менее 10 человек), а сложность разрабатываемого ПО низкая, то автором ВКР было предложена использовать гибридную проектную методологию, основанную на гибких моделях, таких как Kanban и Scrum.
Опыт применения разработанной методологии в компании «Wawe» продемонстрировал, что нужно не в слепую выбирать готовую модель, а внедрять, опираясь на выше указанные особенности внутренней и внешней среды, а также на опыт аналогичных проектов. Так, для стартапа «Wawe» оказалось наиболее целесообразным взять итеративную модель управления продуктом, синтезировав с гибкой методологией управления проектом, внедрив систему опроса фокус-группы ЦА и добавив возможность формировать изменения к продукту даже во время итерации, что отличает предложенную модель от, например, чистой модели Scrum.
В итоге, предложенная гибкая проектная методология для стартапа «Wawe» соответствовала требованиям, подчеркнутым из научных источников, посвященных различным предметным областям, а также выше упомянутым особенностями внутренней и внешней среды конкретно для данного стартапа.
Полученная модель показала свою эффективность по результатам его внедрения:
1. Увеличилась скорость разработки (в среднем на 10-15%);
2. Увеличилась управляемость стартапом и процессом разработки;
3. Увеличилась прозрачность процесса разработки;
4. Появилась возможность оценивать эффективность разработки;
5. Был внедрен инструмент управления рисками;
6. Был внедрен инструмент управления изменениями;
7. Был внедрен инструмент управления сроками;
8. Был внедрен инструмент управления стейкхолдерами;
9. Финальный продукт «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;
4. Ильин В., Балашов В., Давыдов В., Иванов А., Скаженюк Е., Жетельный И., Дан Штибель, Георгиева В., Газизов К. Исследование российского и мирового венчурного рынка за 2007-2013 годы, // Обзоры и исследования российской инновационной экосистемы // Российская Венчурная Компания - 2012г. URL: http://www.rvc.ru/analytics/ (Дата обращения 03.02.2017);
5. Макконнелл Стив. Влияние итеративных подходов на предварительные условия // Совершенный код = Code Complete. -- Русская Редакция, Питер, 2005. -- С. 31. -- 896 с.;
6. Мартин Роберт С., Джеймс В. Ньюкирк, Роберт С. Косс. Быстрая разработка программ. Принципы, примеры, практика = Agile software development. Principles, Patterns, and Practices. -- Вильямс, 2004. -- 752 с.;
7. Мошкин И. В. Исследование процессов современного предпринимательства. -- М.: Директ-Медиа, 2014. -- 342 с.;
8. Орлова Анастасия Андреевна, Иншаков Максим Олегович. Инновационные стартапы в России: проблемы создания и маркетингового продвижения (рус.) // Вестник Волгоградского государственного университета. Серия 3: Экономика. Экология. -- 2014. -- № 1. -- С. 66-75;
9. Паштова Л.Г., Баев Г.О. Актуальные проблемы стартапов (малых производственных предприятий) в экономике России // Финансовая аналитика: проблемы и решения. 2015.
10. Петренко В.А., Демьяненко Н.Г., Крюкова А.А. Методологии управления стартап-проектами // Проблемы экономики и менеджмента. 2017.
11. Basu, A. et al., 2008. The Oxford handbook of entrepreneurship [electronic resource] M. Casson & O. H. Online, eds., Oxford5: Oxford University Press.;
12. Blank, S., 2013. Why the Lean Start-Up Changes Everything. Harvard Business Review, 65(May);
13. Blank, S. & Dorf, B., 2012. The Startup Owner's Manual. The Step-by-Step Guide for Building a Great Company First Edit., K&S Ranch Publishers, Inc.;
14. 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;
16. 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.;
18. James A. Highsmith. Agile Software Development Ecosystems. -- Addison-Wesley Professional, 2002.;
19. Mandela Schumacher-Hodge. You Think You're a Startup, But You're Really a Small Business (and that's 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
20. 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;
22. 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.;
25. Paul Miller. Zero to One summary: Peter Thiel's advice on startups, - December 2014, - M. Casson & O. H. Online, eds., Oxford5: Oxford University Press.;
26. Ross, S., Westerfield, R. & Jaffe, J., 2010. Corporate Finance 9th ed., McGraw-Hill/Irwin.;
27. Royce, Winston, Managing the Development of Large Software Systems, - 1970;
28. 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.
Сравнение гибких методологий
SCRUM |
XP |
TDD |
||
Степень неопределенности продукта |
Высокая неопределённость продукта |
Средняя неопределенность продукта |
Средняя неопределенность продукта |
|
Оптимальное количество участников |
7 (+/-2) |
Любое |
Любое |
|
Важность мотивации команды |
Да |
Нет |
Нет |
|
Чувствительность к высокому профессионализму команды разработчиков |
Нет |
Да |
Да |
|
Предполагаемая высокая частота контакта с пользователем (чаще 2 раза в неделю) |
Нет |
Да |
Да |
|
Фокус на качество выше фокуса на сроки |
Да |
Нет |
Нет |
|
Фокус на ограниченность бюджета |
Нет |
Нет |
Нет |
|
Низкая вычислительная сложность разрабатываемого ПО |
Да |
Да |
Нет |
|
Простота применения |
Да |
Да |
Нет |
|
Предполагаемая возможность быстрого изменения методологии |
Нет |
Да |
Нет |
AgileUP |
OpenUP |
DSDM |
||
Степень неопределенности продукта |
Высокая неопределённость продукта |
Высокая неопределённость продукта |
Высокая неопределенность продукта |
|
Оптимальное количество участников |
6(+/-3) |
5 |
7 |
|
Важность мотивации команды |
Да |
Да |
Да |
|
Чувствительность к высокому профессионализму команды разработчиков |
Нет |
Нет |
Да |
|
Предполагаемая высокая частота контакта с пользователем (чаще 2 раза в неделю) |
Да |
Да |
Да |
|
Фокус на качество выше фокуса на сроки |
Да |
Нет |
Нет |
|
Фокус на ограниченность бюджета |
Нет |
Нет |
Да |
|
Низкая вычислительная сложность разрабатываемого ПО |
Да |
Нет |
Да |
|
Простота применения |
Да |
Нет |
Нет |
|
Предполагаемая возможность быстрого изменения методологии |
Нет |
Да |
ASD |
Kanban |
FDD |
||
Степень неопределенности продукта |
Средняя неопределённость продукта |
Средняя неопределённость продукта |
Средняя неопределенность продукта |
|
Оптимальное количество участников |
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 Точно предложу
Размещено на Allbest.ru
Подобные документы
Теоретические аспекты международных и национальных стандартов в области управления проектами. Описание международных и национальных стандартов управления проектами. Практическое использование стандартов на примере организации ОАО "Молоко" г. Калининград.
курсовая работа [248,2 K], добавлен 26.12.2016Общая характеристика стандартов, разработанных Институтом управления проектами США. Задачи, классификация и основные сферы деятельности стандартов PMI. Четыре области профессии: проект, программа, портфель и организационный подход к управлению проектами.
реферат [33,5 K], добавлен 13.04.2015Сущность и функции корпоративной системы управления проектами (КСУП), ее элементы и предъявляемые к ней требования. Базовые методологии и процессы управления проектами. Характеристика основных ролей в контексте КСУП, этапы ее разработки и внедрения.
контрольная работа [33,7 K], добавлен 13.06.2013Специфика управления проектами на предприятиях малого бизнеса. Концепция "точно в срок" как основа проектного производства. Отличительные особенности приоритетных направлений деятельности. Определение проблемных и сильных областей на уровне проекта.
дипломная работа [2,0 M], добавлен 20.08.2017Понятие и значение малого бизнеса. Особенности менеджмента организаций малого бизнеса и описание ролей руководителя. Общая характеристика управленческих функций и стилей руководства. Анализ требований и критериев оценки эффективности руководителя.
курсовая работа [293,1 K], добавлен 14.03.2012Понятие управления проектами как важной части функционирования любого предприятия. Внедрение информационных систем. Стандарты по управлению проектами. Интеграция проекта и управление его содержанием. Особенности управления временем и стоимостью.
практическая работа [341,1 K], добавлен 07.04.2015Уровень внедрения международных стандартов на российских предприятиях на примере на ОАО "Газпром". Виды международных стандартов. Международный стандарт "серия ISO-9000" как пакет документов по обеспечению качества. Серия национальных стандартов.
контрольная работа [38,9 K], добавлен 06.10.2011Эволюция подходов к управлению программными проектами, современные тенденции и перспективы, критерии успешности. Оценка успешности проекта разработки программного обеспечения. Особенности организации проектной команды. Жизненный цикл проекта, фазы.
курсовая работа [2,8 M], добавлен 10.01.2015Анализ существующих информационных технологий в области управления проектами. Разработка методики внедрения в работу образовательного учреждения программного комплекса управления проектами Microsoft Project и оценка эффективности его использования.
курсовая работа [151,2 K], добавлен 14.01.2014Использование методологии управления проектами в качестве механизма реализации инновационных инвестиций. Синергия проектного, программно-целевого и портфельного управления. Модель информационно-аналитической системы управления лечебным учреждением.
курсовая работа [1,0 M], добавлен 07.07.2015