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

·        Взаимодействие людей и их способности важнее применяемых процессов и инструментов;

·        Продукт важнее документации;

·        Тесное взаимодействие с заказчиком важнее согласований условий контрактов;

·        Готовность и способность к изменениям важнее первоначального плана;

Основные принципы «Манифеста гибкой методологии разработки программного обеспечения»:

·        Простота как искусство не делать лишних работ;

·        Тенденция к само организованным командам;

·        Постоянная готовность искать и осуществлять изменения;

·        Фокус на улучшении технического мастерства и удобства дизайна;

·        Участники проекта должны поддерживать постоянный темп работ;

·        Лучшим измерителем прогресса является работающее ПО;

·        Рекомендуемый метод обмена информацией - личные разговоры;

·        Проектом занимаются мотивированные личности;

·        Постоянный контакт заказчика и исполнителя;

·        Еженедельная, ежемесячная поставка рабочего ПО;

·        Способность принимать изменения даже в конце сроков проекта;

·        Удовлетворение клиента путем предоставления ценного ПО.

Гибкие методологии в управлении информационными проектами подразумевают:

.        Вовлечение конечных пользователей продукта имеет определяющее значение;

.        Принятие решений должно основывать на высокой эффективности команды;

.        Основа работы - это этапность и цикличность;

.        Концентрация на промежуточных результатах с обязательным представлением продукта;

.        Используется модель эффективности Паретто 80/20;

.        Применение коллективного подхода при реализации плана;

.        Переход к следующему этапу производится только после завершения предыдущего.

Как видно из принципов Agile-методологии, её использование рационально в интеллектуальных сферах бизнеса, таких как маркетинг, IT и им подобным. Данный тип методологий стал активно внедряться в организациях в последнее десятилетие ввиду малой эффективности классических подходов управления проектами. Этому поспособствовало следующие тенденции рынка (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. взаимосвязь между количеством проектов, выполняемых одновременно и потерями времени из-за переключения между проектами.

На основании данной статистики можно сформировать требование для применимых методологий управления проектами, о том, что модель должна максимально исключать многозадачность, неясность задач и расфокусировку между ними.

Итак, стартапы, включая занятые в сфере IT, имеют значительные сходства с проектами по параметрам временности, ограниченности бюджета и нацеленности на получении уникального результата. Отсюда следует, что проектная методология применима для IT-стартапов, но необходимо учитывать особенности IT-стартапов при внедрении. Главным отличиями являются:

·        высокая неопределенность внешней среды;

·        важность внимания к своим клиентам;

·        сильная связь жизненного цикла продукта с жизненным циклом стартапа.

Для того, чтобы эти особенности были учтены, в данной ВКР сформирован список требований для методологий:

·        итеративно-инкрементальная модель;

·        простота внедрения и использования;

·        модель должна регламентировать не только процесс разработки продукта, но и процесс управления стартапом.

Глава 2. Применение проектной методологии в стартапе «Wawe»

Рассмотренные в таблице 3 актуальные методологии управления IT-проектами и ПП имеют различные сферы применения. У каждой из них есть свои особенности и инструменты, которые должны применяться в соответствующих IT-проектах или IT-стартапах.

Для выбора конкретной методологии при внедрении в IT-стартап «Wawe» необходимо сравнить их по следующему перечню факторов, сформированных при теоретическом анализе как значимые для стартапа:

.        Оптимальный размер команды и наличие определенных ролей;

.        Степень неопределенности разрабатываемого ПП и внешней среды в целом;

.        Степень фокуса методологии на разработку продукта и на непосредственное управление проектом/стартапом;

.        Тип модели жизненного цикла;

.        Предполагаемая теснота связи с будущими пользователями ПП;

.        Гибкость самой модели к изменениям;

.        Степень вовлеченности участников в проект/стартап.

Данный перечень оцениваемых признаков проектных методологий основывается на ключевых факторах успеха IT-стартапа, и его особенностей перед обычной разработкой программного продукта, которые были выявлены в теоретической части. Также он отражает особенности экосистемы IT-стартапов в России. Таким образом, исследовав применимость проектной методологии в управлении стартапом и доказав адекватность такого внедрения, перейдем к непосредственному применению и оценке результатов.

В рамках практической части анализируется эффективность применения методологии управления проектами в IT-стартап Wawe. Данное исследование было разделено на три этапа. Первый этап - сбор информации о применяемых подходах в управлении стартапом Wawe в совокупности с анализом текущей внешней среды. Для достижения этих задач использованы эмпирические способы сбора информации: наблюдение и глубинное интервью. Начиная с октября 2016 года и по декабрь 2016 года автором данной работы осуществлялись посещения офиса стартапа «Wawe» в бизнес-центре Arma, с целью сбора необходимой информации о:

·        Применяемых инструментах и методах;

·        Особенностях реагирования на изменения внешней среды;

·        Отношении к жизненному циклу стартапа и продукта;

·        Методах управления командой стартапа.

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