СОДЕРЖАНИЕ
Глава 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»
Проанализировав литературу по темам: особенности самих стартапов, особенности применения проектного управления в 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: #"908596.files/image008.gif">
Темы
роста рынка ИТ в России 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, который похожи с концептом нашего продукта - удаляющихся записей с течением времени.