Классические ошибки управления проектами при запуске стартапов

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

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

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

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

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

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

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

Руководители по продуктам в цифровом стартапе (product manager in digital startup) - это по характеру своей деятельности те же Руководители временных мероприятий, которые взращивают продукт с “0” и далее передают его в процессный менеджмент к профессионалам в масштабирование бизнес модели. В связи с жесткой ограниченностью ресурсов стартапов, от таких людей часто требуются дополнительные навыки, помимо управленческих, на месте которых в будущем могут вырастать целые отделы: программирование, маркетинг, продажи, финансы, реклама, дизайн, статистика, управление персоналом и др. В отличие от модного в наше время гибкого (agile) мышления, что часто противопоставляется классическому проектному, у таких людей должно превалировать мышление предпринимателя. Продуктологи, как их именуют на рынке, требования к минимальному профессиональному инструментарию формировали из жесткой ресурсной ограниченности стартапа. Руководители же проектов опирались при взращивании своего тяжеловесного инструментария в отраслях на развитую профессиональную поддержку процессного менеджмента (см. историю создания PMI).

Тяжеловесный инструментарий project management зачастую бесполезен без дополнительной ресурсной или процессной поддержки, что почти всегда ограничено в среде стартапов
Тяжеловесный инструментарий project management зачастую бесполезен без дополнительной ресурсной или процессной поддержки, что почти всегда ограничено в среде стартапов

Существуют разные мнения о том, где проводить черту между специализациями на управлении проектом (Project manager), продуктом (Product manager), бэклогом (Product owner) в цифровых стартапах. В условиях диктатуры работодателя (заказчика), черта будет проведена там, где ему удобно или где получится сторговаться. А станет ли ему выгоднее от этого в итоге – зависит от понимания последствий бездумного микса ролей:

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

 Ниже собраны типовые ошибки с описанием последствий, которые встречаются, если для сотрудника образа мышления project manager поставить задачу в части создания / корректировки нового продукта (бизнеса в миниатюре), что больше подходит для product manager.

Погоня за лидерами рынка взамен выверенного расписания проекта

Головокружительные успехи роста стартапов таких как Groupon, Instagram, Slack и других устанавливают высокую планку по разворачиванию успешной бизнес модели в кратчайшие сроки:

В погоне за образом инноватора, менеджеры часто декларируют соответствующие обещания перед акционерами, спуская их на команду, не учитывая, что:

●      одинаковых стартапов не бывает и при построении вех проекта необходимо делать соответствующие поправки;

●      без адекватной обратной реакции исполнителя задача не может считаться принятой (качественно поставленной);

●      неисполнимая задача подрывает дух команды и является основой для манипуляций в обе стороны - как от начальника к подчиненному, так и обратно.

Ориентиром в верхнеуровневом планировании может служить концепт трёх горизонтов роста, который был представлен в 1999 Baghai, Coley and White  году в книге “The Alchemy of Growth”. Так для первого горизонта (улучшения текущего бизнеса) можно отнести проекты длительностью 6-12 мес., для второго (новые технологии без смены направления бизнеса) 1-3 лет, и далее идет третий экстремальный горизонт инноваций (новые технологии в новом направлении бизнеса), где время реализации может существенно затянуться.

Ошибки в управлении ресурсами: недооценка важности мотивации и переоценка универсальности опыта

Учебники по профессиям начинаются со вступления в окружающую среду функционирования специалиста. Если, заходя на новый startup продукт (проект), не прощупать плотность профессиональной поддержки коллег в создании миниатюрного бизнеса, то, вполне вероятно её нехватку придётся компенсировать своими силами. При этом базовый опыт вызовет ускорение в одних вопросах и замедление вплоть до остановки в других: абстрактность, присущая, дизайнеру обратно пропорциональна «приземлённости» инженера, и открытость к миру новатора обратно пропорциональна интровертности программиста. Важно, заходя на проект по созданию нового startup, понимать, чьи навыки у руководителя прокачены внутри больше: инженера, предпринимателя, вольного художника или кого другого. Это позволит избежать неожиданного “крена” деятельности проекта в пользу развитых навыков управленца, которые могут не быть выигрышными в конкретной ситуации. Видению ключевых аспектов создаваемого бизнеса в рамках одной картины способствует построение “полотна бизнес модели” (The business model canvas). Данный инструмент визуализации применяется и для других целей: классический (Growth hacking canvas), инновационный (Corporate innovation canvas), встречаются даже те, которые помогают увидеть аспекты построения доверия в команде (Trust discovery canvas).

При работе над нетиповыми проектами выгодно вовлечь максимальное количество членов команды проекта даже в определение клиентских болей:

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

  • команда впоследствии получает больше удовлетворение от успеха – чувствуется польза от работы для конкретных потребителей, с которыми в ходе исследования команда знакомится лично;

  • и самое главное, после успешного спринта, где проверяется клиентская проблематика и выверяется ваше предложение, создаётся гораздо меньше лишних, не приносящих пользы характеристик продукта.

Недельными дизайн спринтами для выявления быстрых решений для клиентов пользуются такие большие компания как Яндекс, Google не просто так – там как нигде умеют считать деньги: «Семь раз отмерь, один – отрежь».

Время работы команды - это часто основная статья расходов инвестора при создании нового стартапа. Именно поэтому экономия этого ресурса крайне важна, кроме того в то время как новый бизнес только учится быть полезным, клиент сильнее привыкает к альтернативному удовлетворению потребности. Так гибкие (agile) элементы проектного управления в новых digital решениях становятся оптимальным спутником инноватора. Пользовательские истории (могут быть сложены в user story mapping), реализуемые за короткие спринты (sprints) позволяют не только избежать продолжительной фазы написания требований для программистов, но и заострить их работу на том, что для клиента действительно важно. К примеру, к формулированию задачи по созданию  функции фильтрации документов в каталоге можно подойти двояко:

●      определить все возможные атрибуты фильтрации, порядок выдачи результата и сформулировать требования к пользовательскому интерфейсу;

●      сформулировать основанное на исследовании клиентских потребностей предположение: “Для ускорения порядка доступа к нужным документам при обслуживании клиента, я как пользователь системы, хотел бы получить результат автоматической фильтрации в каталоге по группе, к которой клиент относится”.

С точки зрения менеджмента оба подхода жизнеспособны, но в рамках второго подхода в формулировке задачи присутствует именно “гипотеза о полезности”, которая в ходе эксплуатации может быть опровергнута числовыми замерами вовлеченности. Реализация функции по первой модели подхода может спровоцировать создание множества неиспользуемых характеристик продукта, но быть более выверенной для создания архитектуры ИТ решения. Хотя для стартапов важнее вопрос не “что делать?”, а “зачем делать?”, ведь это высоко рискованное мероприятие и правильная архитектура в ненужном для клиента продукте не решит задач по возврату вложений.

Грёзы о будущем вместо управления содержанием

Понимание разницы смысла английских слов из понятий продуктолога outputs / outcomes / impact применительно к постановке задач позволит избежать подмены реальной причины деятельности менеджмента декларируемой. Перевод содержимого слов можно свести к следующему смыслу: результат достижения цели / прямое воздействие / косвенное влияние. Бывает, что продукты создаются для некоего косвенного влияния, которое они возможно окажут. Менеджмент при этом забывает применить классику целеполагания (типа SMART), чтобы это влияние обеспечить. Ну, или на ранней стадии понять несостоятельность идеи.

К примеру, так может прозвучать фраза топ менеджера, за которой кроется столб обоснования трат ресурсов: «Мы создаём продукт, который окажет влияние на всю индустрию». При этом не все понимают, что для того, чтобы этого достичь, должна быть поставлена и контролируемо достигнута более конкретная цель, например: «За 2 года достичь уровня продаж не менее 20% от локального рынка по результатам замеров на конец года». Достижение такой цели может оказать воздействие, к примеру, на закупочную политику крупных игроков локального рынка, что уже дальше возможно окажет влияние на индустрию в целом.

Gold plating, что в переводе означает “украшательство” - болезнь, известная в среде управления проектами. Она проявляет себя коварно, каждый раз требует от подверженного ей менеджера всё больше и больше проявленного творчества за счёт, как правило, чужих ресурсов. Дизайнеры, столкнувшись с ней со стороны заказчика, называют её “вкусовщиной”.

Hook framework (Крючок), предложенный инвестором Ниром Эялем, призывает привычку и зависимость от украшательства переложить на клиента, что позволит сделать его зависимым от продукта. Ведь украшательство - это инвестиция (времени, денег), которая затягивает и заставляет окружение человека признавать великолепие расточительства: так люди украшают свои аккаунты в социальных сетях новыми фотографиями призывая друзей к лайкам, бесконечно автоматизируют процессы и хвастаются о своих достижениях, получают многочисленные сертификаты и стимулируются на достижение новых под восторг (поглаживания) профессионального сообщества и т.п.

Неуместное применение клиентских фокус групп или индивидуальный опрос близкого окружения для выверки бизнес модели (содержания проекта) вместо глубокого интервью проблематики приводит к созданию продуктов, которые должны быть успешными (как заверяли опрашиваемые), но отчего-то не стали (подробнее, но аккуратнее с интервью проблематики можно познакомиться в книге Роба Фитцпатрика «Спроси маму: Как общаться с клиентами и подтвердить правоту своей бизнес-идеи, если все кругом врут?»). Бывает, что менеджеры рисуют перспективные, весьма интересные для клиентов решения, отказ от которых во время интервью травматичен для опрашиваемого, в том числе от того, что не хочется прерывать рассказчика о том как “корабли бороздят просторы вселенной”. Так же не стоит забывать о стадном чувстве, которое может захватить людей в комнате, ведь бывает, что люди отвечают не от того, что они так думают, а от того, что своим ответом они хотят выделиться или наоборот слиться с манящим большинством.

Качество проекта (продукта) определяет клиент, голосуя в итоге рублём

Каждый проект уникален - нет одинаковых стартапов. В попытке воспроизведения чужого успешного опыта, зачастую упускаются неочевидные на первый взгляд аспекты, к примеру «критерии качества», при которых стартап можно признать успешным. Если не задаваться вопросом их фиксации в самом начале, нет смысла прорабатывать путь клиента (Customer Journey Map, CJM) – не зафиксировано состояние, определяющее развитие. Так появляются сайты без системы метрик, перегруженные информацией лендинги, отсутствие продуманных мероприятий по удержанию пользователя и т.п.  И ведь не смотря на то, что продуктом клиент не будет удовлетворён, проект по его созданию может при этом быть успешным.

Продуктолог в своём арсенале имеет множество шаблонных инструментов по построению критериев качества, которые опираются на психологические стадии принятия решения клиентом о пользовании продуктом. В качестве показателей, за которыми могут следить управленцы для оценки востребованности продуктов, можно выделить многочисленные названия метрик (CAC, M-% CAC, Time to payback CAC, CPC, CPV, CPA, CPO, CPM, CPL, CTR), фреймворки (AARRR, AIDAOR) и др.

Фанатичная вера в гениальность идеи как способ управления рисками

Человеку свойственно пытаться обезопасить психику от крушения мечты – он будет страховаться и «прокладывать» продукт гарантиями. Часто приходится наблюдать как в погоне за чьей-то эмоциональной безопасностью проект по выводу или созданию нового продукта делается тяжелым и излишне затянутым. То есть предпринимается попытка избежать риск того, что продукт клиенту не понравится за счет утяжеления его всевозможными потребительски важными характеристиками. Кривая Фогга (B. J. Fogg) объясняет, что идеальное удобство и одновременная мотивация – слишком высокая цель для стартапа, достигая которую можно потратить много ресурсов: высокомотивированный клиент при правильно выстроенном триггере может сделать покупку и на неудобном сайте.

Как раз вопросы недостоверной мотивации могут закрыть эксперименты по выводу минимально работоспособных продуктов (Minimum Viable Product) на суд клиенту. Среди наиболее известных типов MVP можно выделить: консьерж (решение проблем клиента вручную), волшебник страны Оз (эмуляция продукта или сервиса) или предпродажи (тестовые продажи). При создании же типовых продуктов, в отношении которых клиент уже успел сформировать ожидания, помогает избавиться от лишних функций модель Кано (Kano model), которая делит атрибуты продукта на обязательные (как руль у автомобиля - без него клиент продукт не воспринимает), одномерные (как расход топлива у автомобиля: чем меньше - тем лучше), привлекательные (как максимальная скорость у спорткара), неважные (как крышка бензобака: слева или справа).

Эрик Рис в книге  “Бизнес с нуля. Метод Lean startup” приводит фразу, о том, что «с успехом сложно спорить»: часто отказ от валидации пользовательских гипотез, что является неотъемлемой частью экспериментальной среды startup проектов, оправдывается успешностью основателей или основного бизнеса, под крылом которого разрабатывается новое направление. Однако дизайн мышление применяется не только для минимизации трат при взращивании интерфейсного удобства, но и для того, чтобы вовремя отказаться от неперспективных проектов, пока неэффективные вложения ресурсов не затянули команду проекта в цикл смерти продукта (Product death circle). Вкратце цикл смерти продукта характеризуется его улучшениями, которые продиктованы больше возможностью их сделать, нежели подтвержденной потребностью пользователей. Психологически это похоже на фигуру штопора у самолёта: вложений всё больше и больше (менеджер старается применить всё, о чём знает, даже если это не помогает, искренне веря в успех), агония управленца нарастает - он наращивает усилия и отказаться от потраченных ресурсов всё сложнее и сложнее.

Прекрасный корабль вложенных усилий среди клиентской пустыни - то состояние, которое признавать не захотят увлеченные создатели бизнеса
Прекрасный корабль вложенных усилий среди клиентской пустыни - то состояние, которое признавать не захотят увлеченные создатели бизнеса

Часто стартапы возникают вблизи зоны деятельности материнской структуры. Именно излишняя уверенность в области возникновения нового бизнеса (понимание отраслевой специфики) приводит к недооценки риска несостоятельности бизнес модели. К примеру, маркетплейс – это уже не просто торговля, это место встречи одной аудитории с другой и узкое и самое тяжелое место роста необходимо определять заранее: кого сложнее привлечь - покупателей или продавцов? Помочь в такой задаче может знание четырёх шагов к озарению (Four Steps to the Marketplace Epiphany): оценка спроса независимо от предложения, посвящение усилий самой сложной части (спросу или предложению), создание системы сервиса, увеличение инвестирования в инфраструктуру для роста доходности. Последствия такой ошибки - маркетплейсы, умирающие из-за своей невостребованности или неизвестности, ну или, маркетплейсы, перегруженные функциональностью, которая не важна клиенту.

Одной из форм менеджерской агонии по спасению невостребованной клиентом идеи стартапа - это попытка совместить в одном умирающем продукте множественные бизнес модели, не делая полноценного pivot (смены бизнес модели): продукт массового потребления, решения для удовлетворения конкретной целевой аудитории, инфраструктурные решения.  Каждая из таких моделей вносит особые требования к стандартизации бизнес процессов и имеет отдельный драйвер роста: к примеру, для продукта массового потребления (к примеру, модель телефона) драйвер заключается в цене, которая должна перекрыть выгоду клиента от альтернатив; продажи, упаковка, поддержка должны быть максимально стандартизированы и идеально выстроены. А вот инфраструктурные решения имеют иные аспекты (например, облачные сервисы): драйвер заключён в количестве пользователей, а вот продажи, поддержка, ценовая политика могут быть менее стандартизированы. Непонимание этого приводит к неправильному планированию реагирования на риски низкой потребительской активности.

Бывает, что идея цифрового стартапа основателям видится настолько гениальной, что восторг от этого застилает глаза так же на конкурентное окружение. К примеру, конкурентом для семейного ресторана могут быть не только те заведения питания, что в непосредственной близости находится, но и домашняя кухня потребителей. Опираясь при проработке мероприятий по продвижению продукта не на собственное осознание уникальности предложения, а на проверенную потребность клиента, возможно качественно проработать план и ожидаемый результат. Однако игнорирование такого подхода приводит к отсутствию спроектированного продукта под конечного пользователя – часто из поля зрения пропадают косвенные конкуренты, проблема клиента уходит на второй план: первый занимает восторг менеджера от грандиозности идеи, которую ему посчастливилось реализовывать. Особенно такая ошибка часто встречается в проектном менеджменте, где уровень мастерства сопоставляется с размером бюджета проекта или его уникальностью - видение косвенных конкурентов затмевают показатели тщеславия (подробнее о них в книге Э.Риса “Бизнес с нуля. Метод Lean startup). Итогом закрытых глаз менеджмента на альтернативу клиентского выбора, как правило, является недостижение целевых показателей захвата рынка.

Эпилог

Product management для Project manager может быть хорошим лекарством от украшательства, веры в показатели тщеславия и многие другие признаки профессиональной деформации, которые проявляются с годами наработанного опыта. Здесь ограничителем от черствости в профессиональном подходе является необходимость настолько аккуратной работы, которая не приведет к утяжелению и смерти еще неокрепшего бизнеса. Именно в startup проектах под мышлением предпринимателя раскрывается с лучшей своей стороны agile инструментарий. Здесь на гибкость подхода накладывается не догма, что “так клиенту удобнее”, а понимание, что без этого бизнес просто не выживает.

Источник: https://habr.com/ru/post/583818/


Интересные статьи

Интересные статьи

Аннотация Численность и размеры центров обработки данных (ЦОД) растут, а их сети расширяются с  учетом увеличивающихся объемов трафика. Профиль трафика в э...
За 15 лет работы мы встречались с различными трекерами: от экзотических FogBugz и Mantiss до современных, которые активно использовали до 2019 года - TFS, Jira, Redmine, ...
Любое ПО содержит уязвимости, причем они появляются на разных этапах его жизненного цикла. Полностью избавиться от уязвимостей в коде достаточно сложно, но можно, как минимум, сократить и...
Привет, Хабр! Я не разработчик, а менеджер. Меня некоторое время учили управлять людьми, а потом я погрузилась в мрачный мир разработки, где всё идёт не так, как говорят в университете. Сейчас я ...
Но если для интернет-магазина, разработанного 3–4 года назад «современные» ошибки вполне простительны потому что перед разработчиками «в те далекие времена» не стояло таких задач, то в магазинах, сдел...