Эволюция управления проектами: стартапы против предприятий

Стартапы играют в покер, крупные компании играют в шахматы.

Эта цитата Дона Доджа, защитника разработчиков в Google, заключает в себе разницу между работой менеджера проекта в стартапе и на предприятии.

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

Это не все черное и белое

Одно предостережение, прежде чем мы углубимся в эту тему, заключается в том, что существуют самые разные компании. Можно ли назвать компанию со 100 сотрудниками стартапом? Что, если она вырастет до 200 или 300 сотрудников? Иногда в СМИ Uber все еще называют стартапом, однако сейчас в Uber работает 12 000 сотрудников. Еще одно отличие заключается в том, что стартап, созданный студентами, сильно отличается от стартапа серийных предпринимателей с более чем 20-летним профессиональным опытом, которые, возможно, ранее работали на предприятии и привнесли оттуда лучшие практики в свои стартапы.

Таким образом, есть много случаев, начиная от совместного стартапа с 5 людьми и многонациональной корпорации с офисами по всему миру. Хотя эта статья в основном будет посвящена двум крайностям, отнеситесь ко всему этому с долей скептицизма и критически подумайте, применимы ли выводы к вашей конкретной ситуации.

Стартапы против предприятий

Отбросив эту оговорку, давайте попробуем определить две крайности, чтобы заложить основу для нашего обсуждения. Для целей данной статьи характеристиками стартапа являются:

• Совместно расположенная команда (~ 1-50 сотрудников), где вы, как правило, знаете всех своих коллег по именам.
• Роли определены свободно.
• Соучредители очень активно принимают большинство решений.
• Компания теряет деньги, и взлетно-посадочной полосы осталось немного — выживание — главная проблема.

На другом конце спектра предприятие будет выглядеть так:

• Несколько отделов и локаций.
• Вы хорошо знаете только своих непосредственных коллег и взаимодействуете с горсткой людей из других отделов.
• У каждого есть четкие обязанности и иерархия.
• Компания может быть публичной.
• Прибыльность и краткосрочное выживание, скорее всего, не вызывают беспокойства.

Управление стартап-проектами

Менеджер проекта ≈ Менеджер по продукту

Теоретически у менеджеров проектов обязанности существенно отличаются от обязанностей менеджеров по продуктам. Однако в условиях стартапа эти две роли обычно переплетаются. Если вы руководитель проекта в стартапе, вы, вероятно, возьмете на себя гораздо больше обязанностей, чем то, что вы обычно делаете на предприятии.

Возможности для руководителей проектов в стартапах

Быстрые решения и большое влияние

В управлении стартап-проектами довольно легко принимать важные решения, поскольку не так много зависимостей с точки зрения процессов, других команд, клиентов и т. д. Что-то столь же важное, как наем нового коллеги, изменение домашней страницы, добавление новых функций или продление крайнего срока может быть на расстоянии одной встречи или разговора в Slack. Это расширяет возможности руководителя проекта и создает чувство автономии.

Стартап — хорошее место, чтобы опробовать свои идеи и вырасти профессионально. Вы можете попробовать новый инструмент управления проектами, который, по словам вашего друга, используется в его компании. Как насчет перехода от Scrum к Kanban? Что бы вы ни делали быстрее, отвечает генеральный директор. Что вы думаете о внедрении этого нового чат-бота, который позволяет запрашивать вашу Google Analytics на естественном языке? Для этого вам не нужен разработчик, объясняет ваш технический директор за обедом. На предприятии все это были бы отдельные, большие и длительные инициативы, управляемые выделенным менеджером проекта.

Дела делаются быстро

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

Легко адаптировать или развернуть

Та же скорость доставки и отсутствие зависимостей позволяет стартап-команде быстро менять курс. Известный пример — PayPal. За первые 15 месяцев с момента своего создания в качестве решения для «криптографии для телефонов» Paypal менялась 5 раз. Рынок платежей быстро менялся, и PayPal смогла превзойти eBay, которая разрабатывала собственное платежное решение под названием Billpoint. Гибкость PayPal позволила ему завоевать доверие покупателей и продавцов eBay, что в конечном итоге привело к тому, что eBay приобрела Paypal.

Жидкие процессы

Обычно не так много строгих процессов и процедур для работы людей в стартапе. Многое остается на здравый смысл и внутренние переговоры. Это одна из основных причин, почему упомянутые выше пункты действительно работают, т.е. вы можете быстрее принимать решения и не нуждаетесь в бесчисленных согласованиях. Конечно, это неизбежный компромисс, который вызывает другие проблемы в будущем, как мы увидим позже в этой статье. Тем не менее, для стартапа, который ищет продукт, соответствующий рынку, и пытается превзойти более крупных и финансируемых конкурентов, это разумный компромисс.

Проблемы для менеджеров проектов в стартапах

Обязанности не полностью определены

Плавный процесс позволяет принимать быстрые и интуитивно понятные решения. Это гладкое плавание, когда все идет хорошо, однако обратная сторона приводит к ошибкам и хаотичной среде. В разбивке процесс — это, по сути, контрольный список — какие шаги необходимо предпринять для достижения результата. Процессы обычно возникают в результате какого-то сбоя, когда коллеги начинают обвинять друг друга в том, что о чем-то не позаботились, а компания инициирует создание процесса для упрощения принятия решений в четко определенные шаги, чтобы снизить риск возникновения таких проблем в работе. будущее.

Например, новая версия привела к сбою веб-сайта клиента. Все в компании знали о готовящемся релизе, но никто не сообщил клиенту. Должен ли менеджер проекта или менеджер по работе с ключевыми клиентами связываться с командой разработчиков клиента? Должен ли технический директор быть более активным? После бурного обсуждения участники соглашаются, что в следующий раз определенные сотрудники будут нести ответственность за определенные действия перед выпуском, чтобы этого больше не повторилось.

Этот пример представляет собой микрокосм того, как стартап превращается в корпорацию. По мере того, как сложность стартапа растет день ото дня, такие решения принимаются, и двусмысленность устраняется из повседневных операций. Однако до тех пор, пока это состояние не будет достигнуто, обычно совершается много болезненных ошибок.

Слабая переговорная сила

Как руководитель проекта в стартапе вы, скорее всего, будете участвовать во внешних переговорах. Соучредители могут приглашать вас на более поздние встречи с клиентами, чтобы представить техническую или продуктовую сторону презентации. Во время этой встречи может возникнуть много вопросов и новых требований, и руководитель проекта должен быть уверен, что не согласует результаты слишком рано. Соучредители могут хотеть завоевать потенциального клиента и соглашаться на его условия еще во время встречи, не осознавая в полной мере стоимость новых позиций бэклога. Клиент может использовать тот факт, что у вашего стартапа не так много времени, чтобы заставить вас взять на себя больше, чем вы можете сделать в разумных пределах.

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

Ярлыки создают устаревшие проблемы

В стартапе очень легко находиться в постоянном режиме MVP. Как руководитель проекта, очень заманчиво подтолкнуть команду разработчиков к тому, чтобы она согласилась на более сжатые сроки и сокращала пути для пунктов дорожной карты. С соучредителями, которые постоянно находятся у вас за спиной, это кажется почти необходимым. Однако, как говорится в народной поговорке, с большой силой приходит и большая ответственность. Если вы злоупотребите этой силой, в конце концов ваша команда начнет сталкиваться с устаревшими проблемами. И это не значит, что когда-нибудь в будущем — вы, скорее всего, столкнетесь с ними еще в режиме запуска.

Например, предположим, что ваша компания решает создать страницу со списком продуктов. Он должен иметь несколько фильтров, чтобы сузить результаты. Он также должен иметь параметры сортировки на основе различных атрибутов. Первоначальная оценка слишком велика, и вы пытаетесь сузить список необходимых фильтров и параметров сортировки. В итоге получается, что большую часть оценки составляет вся система — поиск и возврат результатов. Вы спрашиваете, есть ли способ быстрее доставить более простую версию. Один разработчик предлагает использовать стороннее решение с ежемесячной подпиской. Другие разработчики говорят о проблемах с зависимостями и устаревших проблемах. Для вас это звучит идеально, потому что вы получаете свой MVP быстрее, а позже подписку можно отменить, если вы решите отказаться от проекта. Скрам-мастер соглашается использовать стороннее решение только в том случае, если у них есть возможность переписать код, если проект не будет отменен.

Реальность, однако, такова, что это соглашение почти никогда не выполняется, если скрам-мастер фактически не поставит задачу технического долга в более позднем спринте и не защитит ее, когда придет время. Если первоначальный отзыв о странице со списком был положительным, естественной реакцией руководителя проекта будет разработка дополнительных функций, поскольку MVP был всего лишь тестом. Через 6 месяцев вы достигаете точки, когда добавление новых функций становится очень дорогостоящим, но рефакторинг обходится еще дороже, а затем появляются другие приоритеты, которые становятся более важными и затмевают первоначальные намерения.

Ложные срабатывания

Ложным срабатыванием в случае управления ИТ-проектами будет ситуация, когда ваша команда разрабатывает MVP, а вы воспринимаете первоначальный положительный отзыв как доказательство соответствия продукта рынку. Это может произойти еще раньше, когда заинтересованное лицо скажет вам: «Я представил наше решение крупнейшему клиенту в нашей отрасли, и они сказали, что обязательно купят его у нас». Вы разрабатываете его, а потом его у вас фактически не покупают.

Ложные срабатывания — большая проблема, но есть способ их смягчить. Стив Кон, основатель Validately, предлагает вам проверить спрос на ваше решение. Есть три сигнала, которые могут вам помочь:

1. Готовы ли ваши клиенты тратить деньги еще до того, как вы предоставите полное решение? Заключение контракта перед поставкой решения, вероятно, является лучшим подтверждением, которое вы можете получить.
2. Готовы ли ваши клиенты тратить время на разработку решения вместе с вами? Время – деньги, и у всех есть бесконечный список невыполненных задач. Чем активнее клиент взаимодействует с вами в выяснении требований, вовлекая в обсуждение других своих коллег, тщательно тестируя MVP и предоставляя исчерпывающую обратную связь, тем больше вероятность, что вы на правильном пути.
3. Готовы ли ваши клиенты использовать свою репутацию для вашего продвижения? Будь то в социальных сетях, на профессиональном мероприятии или в любой другой форме, когда клиент продвигает вас, он предоставляет вам свою репутацию, которая подтверждает его неподдельный интерес.

Управление заинтересованными сторонами

Наиболее важными заинтересованными сторонами стартапа для менеджера проекта обычно являются соучредители. Как мы видели в части возможностей, соучредители могут обеспечить быстрое принятие решений на основе здравого смысла. Однако проблема в том, что многие соучредители довольно часто полагаются на свои инстинкты при принятии решений. Это особенно верно для соучредителей, которые работали в определенной отрасли как профессионалы в этой области и теперь решили создать ИТ-решение для решения проблемы, с которой они сами столкнулись в своей работе.

Глубокое знание рынка чрезвычайно полезно для любого стартапа, однако при создании дорожной карты нельзя полагаться исключительно на него. Стремление большинства стартапов — создать решение, которое будет масштабироваться на международном уровне. Даже если на одном рынке работает несколько компаний, они не обязательно будут решать свои проблемы одним и тем же путем. Соучредитель может хорошо знать, как работала его предыдущая компания, но это не значит, что он знает, как другие компании, особенно в других странах, решали те же проблемы.

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

Управление проектами на предприятии

Менеджер проекта ≠ Менеджер по продукту

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

Офис управления проектами (PMO)

По мере роста компании растет и портфель проектов. К нам присоединяются новые менеджеры проектов, которые приносят с собой новые инструменты и методологии управления проектами. Сначала все становится немного хаотичным, и возникает потребность в офисе управления проектами (PMO). PMO занимается жизненным циклом управления проектами и может либо распространять, либо внедрять лучшие практики по всей компании.

Как руководитель проекта на предприятии, вам придется взаимодействовать с PMO. Каждый PMO отличается, но вы можете столкнуться с:

• Заполнение различных форм для запуска и закрытия проекта.
• Отправка бюджетов на рассмотрение.
• Предоставление регулярных обновлений прогресса.
• Получение подписей по вехам или различным этапам процесса.

Для менеджера проекта, который уже много занимается планированием и отслеживанием, многие требования PMO могут показаться ненужной волокитой, особенно если они начинают замедлять проект. Хотя эта бюрократия может быть источником разочарования, инициативный менеджер проекта может минимизировать накладные расходы и даже извлечь выгоду для проекта из PMO:

• Привлеките PMO на ранней стадии, чтобы выяснить требования к отчетности. Затем их можно сопоставить с материалами, произведенными во время выполнения проекта, чтобы сэкономить время.
• Будьте чемпионом процесса. Предоставьте PMO обратную связь о том, как можно изменить процессы, чтобы облегчить жизнь руководителям проектов. Одна из основных целей PMO — помочь менеджеру по продукту быть эффективным.
• Используйте PMO для помощи, когда ваш проект сталкивается с проблемами. PMO имеет представление обо всех проектах в масштабах всей компании и имеет опыт решения различных проблем или рисков, возникающих в ходе выполнения проекта. Используйте их знания в своих интересах.

Возможности для руководителей проектов на предприятии

Достоверность

Стабильность и долгосрочное планирование предприятий свидетельствуют о доверии к клиентам и партнерам. Люди, которые хотят взаимодействовать с вашей компанией, ищут хороший послужной список — вы можете выполнять свои обещания и имеете большой опыт в своей области знаний. Это одно из самых больших преимуществ предприятия перед стартапами. Это облегчает поиск новых клиентов и партнеров.

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

Легче собирать требования

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

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

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

Построить или купить

Возможность, которой нет у стартапов, — это рост за счет слияний и поглощений (M&A). В 2018 году по всему миру было заключено рекордное количество сделок M&A. Большая часть этой тенденции — мега-сделки, такие как недавнее приобретение AT&T компании Time Warner за 85 миллиардов долларов. Тем не менее, согласно исследованию Harvard Business Review, часть сделок невелика с точки зрения оценки и приносит более высокую прибыль. Существует множество небольших стартапов с одноточечными решениями, и руководители проектов на предприятиях должны помнить, что иногда имеет смысл выкупить их, а не пытаться скопировать их решение. Менеджер проекта может не принимать решения для такого сценария, но может быть тем, кто предложит этот вариант на столе.

Проблемы для менеджеров проектов на предприятии

Утверждения занимают больше времени

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

Это означает, что руководитель проекта должен планировать гораздо больше заранее и быть более усердным. Тем не менее, всегда есть специальные и неожиданные ситуации, когда вам нужно получить все утверждения как можно быстрее. Хорошие отношения с другими отделами в таких ситуациях будут иметь большое значение. Руководитель проекта, способный помочь нуждающимся, взамен, скорее всего, получит благосклонность коллег.

Недопонимание

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

Вашей команде нужна пара новых значков для новых функций, над которыми они работают. Во время обеда вы неожиданно встречаете руководителя группы дизайнеров и рассказываете ей об иконках. Она говорит, что сейчас они работают над похожими иконками, и скоро они будут готовы. Во время стендапа на следующий день вы передаете информацию команде и просите их связаться с командой дизайнеров, когда им потребуются значки. Эти функции должны появиться через 4 недели, поэтому все предполагают, что иконки будут готовы к этому времени. Разработчики ставят заглушки для иконок и только во время QA кто-то замечает, что забыли их заменить. Они изо всех сил стараются связаться с командой дизайнеров, которая на самом деле отложила создание этих значков из-за других неотложных задач. Никто из вашей команды не связался с ними, и руководитель группы дизайнеров предположил, что вам больше не понадобятся значки. Руководящие принципы бренда не позволяют вам переходить к производству с какими-либо случайными значками, и ваша команда остается сидеть с готовыми функциями, не в состоянии их развернуть.

Работа руководителя проекта на предприятии полна таких моментов, созревших для недопонимания. Здесь можно использовать две стратегии:

• Используйте ретроспективу, чтобы выяснить вместе с командой, может ли новый процесс помочь избежать подобных ошибок в будущем. Возможно, решение в этом сценарии — вести список всех зависимостей от других команд с еженедельным обзором и последующими действиями.
• Излишне общаться. Как правило, хорошей стратегией для менеджера проекта является сообщать больше, чем вы считаете нужным. Выработайте привычку проверять людей, спрашивая краткие новости в те короткие моменты, когда вы ждете лифта или идете к машине. Это хороший способ сделать так, чтобы меньше вещей просочилось сквозь щели.

Двигайтесь медленно и ничего не сломайте

Чем старше кодовая база, тем сложнее становится разрабатывать новые функции. Менеджер проекта может начать замечать, что небольшие стартапы быстрее выходят на рынок с новыми инновациями и превосходят их.

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

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

Заключение

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

Напомним, что в стартапе гибкие процессы, а руководитель проекта может быстро принимать решения и оказывать большое влияние на компанию в целом. Жизненные циклы разработки намного короче, что позволяет руководителю проекта оставаться гибким и иметь возможность адаптироваться к изменяющимся рыночным условиям.

Менеджер проекта в стартапе также сталкивается со значительными трудностями. Не полностью определенные обязанности могут привести ко многим проблемам по мере роста стартапа. Клиенты и соучредители могут подталкивать менеджера проекта к тому, чтобы он взял на себя больше, чем команда может сделать в разумных пределах. После этого в дорожную карту могут быть внесены различные ярлыки, что в будущем приведет к унаследованным проблемам. Соучредители стартапа очень активно определяют дорожную карту. Их убеждения, однако, могут привести к ложным срабатываниям, и руководитель проекта должен уметь оперировать данными и быть гибким, чтобы смягчить эти проблемы.

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

Проблемы управления корпоративными проектами неизбежно связаны с размером компании. Различные утверждения и подписания означают, что руководитель проекта должен очень тщательно планировать и привлекать PMO, чтобы не замедлять выполнение проекта. Вероятность недопонимания возникает по мере того, как вовлекается все больше и больше людей и отделов, и это необходимо смягчить, внедрив правильные процессы. Наконец, жизненные циклы разработки удлиняются, и руководителю проекта приходится конкурировать как со стартапами, так и с другими предприятиями на рынке.

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