Очень часто я сталкиваюсь с ситуацией, когда бизнес игнорирует стратегию и глубокий системный анализ при разработке нового продукта. Как правило, первого своего ИТ проекта. Причин здесь очень много, и одна из самых главных, это недостаток опыта и знаний. И вот об этом я хочу сегодня и поразмышлять, почему это происходит и можно ли что-то изменить.
В своей предыдущей статье "Как я замучился с пресейлами и решил создать SaaS сервис себе в помощь", я рассказал, как и почему я создал продукт Presale.Ninja для помощи в пресейлах. Так что если вам нужно создавать сметы для клиентов, то это будет вам очень полезно. Но еще более полезным будет понимание того факта, что создание своего ИТ продукта - это очень сложный процесс, где само программирование занимает небольшой процент от всей работы, которая должна быть проделана. А вот что действительно может занять много времени, так это стратегическое планирование всего продукта, от этапа голой идеи, до быстрого роста, где потребуется оперативная масштабируемость.
Говорить буду только о том виде бизнеса и планирования продуктов, которые являются не гипотезами или MVP, а уже спланированной бизнес идеей, которая должна быть реализована, и использоваться для долгосрочного развития бизнеса.
Итак, какие частые причины того, что бизнес игнорирует системный анализ, архитектуру и стратегию, кроме очевидных, как отсутствие опыта и знаний.
1. Инвестиции в продукт, которые вкладывают другие люди или компании
Как бы странно и парадоксально это не звучало, но тут на пути лежит большое количество разнообразных граблей. Когда руководители начинают планировать бюджеты и приступают к работе над продуктом за чужой счет, то их это очень сильно расслабляет. Потому что все риски несут не они, а инвестор. И за каждую ошибку при создании продукта заплатит кто-то другой. А рассказать о том, что кто-то там плохой и работает неэффективно, что ситуация на рынке не очень сейчас, и еще десятки разных отговорок, приведет к экстра вложениям или убыткам не самих менеджеров, а именно инвесторов. А вот при собственном инвестировании проекта, ситуация может быть другой. Так как ничто так не прочищает , как потеря личных денег.
Второй момент с инвестициями заключается в том, что инвесторы могут начать активно вмешиваться в процесс создания продукта. Руководствуются они, как правило, желанием быстро вернуть затраченные вложения и быстрое получение прибыли. Особенно когда инвестор не один, то договориться между собой они не в состоянии, и своими бесконечными вмешательствами во все процессы, могут сами погубить хорошую идею и привести к неудаче.
Поэтому тут присущи такие частые проблемы, как безответственность и жажда быстрой наживы, которые с большой долей вероятности ни к чему хорошему не приведут. Конечно же, это не про всех, и есть много приятных исключений. Но, к сожалению, именно исключений.
2. Ожидание и реальность - это параллельные вселенные
Это один из самых важных пунктов, который очень часто приводит к проблемам и неудачам. На эту тематику существует тысячи мемов. Но если с такими вещами, как внешний вид, умение петь и танцевать, и т.д., все очевидно и понятно, то вот в такой тематике, как создание ИТ продуктов, нет. Одна лишь вера в успех, и нежелание глубоко погружаться в проблематику вопроса, очень быстро вернет менеджеров в суровую реальность. Все это еще может отягощаться и личными качествами, как упрямство, излишняя самоуверенность, завышенное ЧСВ.
Вот представьте, к примеру, любого своего родственника или знакомого, которому дали миллион долларов инвестиций для создания нового ИТ продукта. Это каким-либо образом сделает из человека профессионального стартапера, руководителя, специалиста в разных сферах, или может у него появятся новые таланты и способности? Ответ очевиден.
Полученные на проект инвестиции совсем не означают, что продукт будет создан, а главное, что он будет востребован. И вера в то, что у нас уже есть деньги, и дело только за малым, это не более, чем фантазии, так как в реальности будет много сложнейших этапов. Ожидание того, что нужно нанять программистов и успех уже близок, это еще одно необоснованное ожидание, которое не имеет ничего общего с реальностью.
По сути, ожидание успеха связанно с отсутствием знаний, опыта и набором личных качеств менеджера.
3. Попытка снять с себя ответственность
Тоже немаловажный пункт, который погубил не один проект. Не стоит путать этот пункт с делегированием полномочий. Это разные вещи. Очень часто менеджер считает, что у него есть дела по важнее, чем нырнуть в омут с головой абсолютно во все процессы разработки ИТ продукта. Я видел много раз, как бизнесмены погрязают в операционной работе, в бесконечных презентациях своих идей (смотреть пункт два) и искренне верят, что проектом должен заниматься кто-то другой. Например, продакт менеджеры, программисты, маркетологи и т.д. В общем все те, кого наняли.
Но вот проблема в том, что бизнес не до конца осознает тот факт, что все эти люди, это наемный персонал, который вообще не интересует бизнес. Сотрудники работают за зарплату, и если все завалится, то они уйдут работать в другую компанию. А значит, что именно на бизнесмене лежит весь груз ответственности за все состояние дел на проекте. Иначе все превратится в бесконечную текучку кадров, что погубит проект в разы быстрее.
Проблемы бизнеса - это только проблемы бизнеса, именно он несет все риски, и рассчитывает на прибыль. И не стоит ожидать того, что можно сбросить всю ответственность на людей на зарплате, а самому не нести риски, а только получать прибыль. Это так не работает.
4. Желание сэкономить на старте проекта
Это тоже очень распространенный подход среди бизнеса. Тут очень хорошую аналогию можно привести на примере строительства частного дома. Есть задача - построить частный дом на земельном участке. И есть два подхода: правильный и авантюристский. При правильном подходе, заказчик будет изучать матчасть, спецификации, стандарты, и полностью попытается наработать свою базу знаний для достижения своей цели. Этот подход потребует много времени и вложений, но в итоге приведет к долгосрочному и устойчивому результату. На участке будут произведены геодезические работы. После чего заказчик обратиться к архитектору, для создания грамотно рассчитанного и спроектированного проекта будущего здания. После создания архитектурного проекта уже полностью будет понятна смета на строительство и сроки создания нового дома. Проект будет учитывать особенности местности и глубины залегания грунтовых вод. Фундамент, что является главнейшей составляющей здания, будет рассчитан правильно и эффективно. После этого будет нанята команда профессиональных строителей, с прорабом во главе. Заказчика будет интересовать в первую очередь репутация этих людей, и их предыдущие работы. Он даже съездит с ними, на их предыдущие проекты, и ему все покажут и расскажут. А заказчик, уже обладая базовой матчастью, будет понимать, что ему не сказки рассказывают, а дают свою экспертизу. В итоге, все будет построено, как и было запланировано. Это займет больше вложений, и времени, но даст именно тот результат, который и ожидался изначально.
При втором же варианте, авантюрном, заказчик посмотрит пару роликов на ютубе, как кто-то сам себе построил дом, быстро и почти бесплатно. Послушает знакомых, родственников и еще кого-нибудь, но только не профессиональных экспертов. Будет искренне верить, что все эти архитекторы, прорабы и профессиональные строительные бригады просто хотят развести клиента на деньги, хотя в строительстве все просто. Как я указывал в пункте 2, вижу цель, не вижу препятствий, будет преобладать в этом плане. В результате, геодезические работы проведены не будут, ведь можно же круто сэкономить. Архитектор вообще не нужен, можно накидать свой крутой "дизайн" будущего дома. Профессиональная бригада не нужна, это лишние траты. Ведь любой сельский мужик умеет строить без проблем. Поэтому можно нанять рабочих на вокзале. Прораб не нужен, это лишний человек, который на всех кричит. В качестве прораба можно назначить одного из строителей, ему и платить больше и не нужно, пусть он и кричит на остальных. Фундамент нужно делать попроще и подешевле. А то фундамент, это очень дорого, а вон у всех же стоят дома на их фундаментах и ничего страшного. Стены подешевле из газобетона можно сделать. И так далее. Ну а в качестве проекта будет выступать 3D рисунок заказчика из какой-то дизайнерской программы.
В результате, уже на самых первых шагах начнут вылазить огромные проблемы, которые потребуют переделок. Все строительство превратиться не в понятный и прозрачный процесс, а в бесконечную возню, и попытки решить предыдущие проблемы, при этом порождая ряд новых проблем. И что самое плохое в этом всем, так это полное непонимания того, что происходит, и чем все это закончиться. В итоге, дом будет намного дороже, чем при первом варианте, а сроки его производства могут затянуться вообще на неопределенный период. А в финале и вовсе может потребоваться полный снос такого строения.
Как видим, попытка игнорирования стратегии и ставка не на профессионализм, а на свои внутренние убеждения, однозначно приводят к провалу. Но это в строительстве, а что же с созданием ИТ продукта? Да все точно так же. Нежелание тратить время на изучение базовой матчасти своего бизнеса, нежелание нанимать с первого же шага экспертов, у которых большой опыт в создании продуктов, игнорирование солюшен архитекторов и системных аналитиков, плюс идея о том, что просто нужно нанять программистов, а одного из них сделать лидом, с вероятность 99.99% приведет к точно таким же последствиям, как и в строительстве.
Отсюда мораль, что на старте проекта нужно заложить прочный фундамент, опираясь на спланированную архитектуру, полностью обладая стратегическим планом, который и позволит в запланированные сроки создать именно тот продукт, который и задумывался бизнесом. И конечно же на самом старте проекта потребуется вложить максимум инвестиций, для устойчивости и предсказуемости всего процесса. Что в конечном итоге будет в среднесрочной и долгосрочной перспективе снижать накладные расходы.
5. Искренняя вера в технологии
Частый случай, практически у всех. За последние десять лет технологии превратились из инноваций в маркетинг. Крупные технологические компании раздувают хайп вокруг каких-то фреймворков, облачных сервисов, и других технологий, которые в реальности не дают бизнесу ничего. Вот от слова совсем.Это вообще на сегодня присуще всей ИТ индустрии, да и не только ей. Инженерный подход как-то тихонечко умер, и его заменила идея о том, что успех продукта только в том, что нужно выбрать "правильную" технологию. Например, берем такой-то фреймворк, делаем проект на микросервисах, все под управлением Кубернетес, а инфраструктура на Амазон. Или ИИ поможет нам написать весь код. Вот это и есть, у подавляющего большинства, весь "системный анализ и архитектурный проект" всего бизнеса.
В какой-то момент производственного процесса происходит одна и та же печальная трансформация. За всей этой возней с технологиями, погружением в глубокий процесс разработки и рефакторинга, с бесконечной настройкой разнообразных конфигов, начинает теряться основная суть и цель бизнеса. Все усилия и ресурсы начинают перенаправляться с самого бизнеса, на бесконечный производственный процесс. И в какой-то момент происходит очень страшная ситуация, что сам бизнес превращается к дополнению к ИТ. А должно быть все наоборот. В итоге бизнес вынужден все больше ресурсов тратить на новых разработчиков, на бесконечное переписывание кода, и еще больше платить за распухшую серверную инфраструктуру.
И все дело еще в том, что с этим пунктом накладываются и те пункты, о которых я писал выше. Происходит череда ошибок, которые ведут к экспоненциальному росту затрат и потери времени. Технологии должны выбирать не программисты или менеджеры, а солюшен или системные архитекторы с огромным опытом создания продуктов, исходя из бизнес задач заказчика. При этом это должны быть уже зрелые люди, с большим инженерным опытом, для которых технологии не более, чем инструмент, а не фетиш. А для этого, жизненно необходим и системный анализ, и хотя бы базовый архитектурный проект, а так же полное стратегическое видение на несколько лет вперед. Без этого любые самые современные технологии станут не помощником в создании продукта, а надгробием. Только надпись на этом надгробии будет у каждой компании своя.
6. Непонимание процессов и их важности
Вы никогда не задумывались, почему до времен скрама было больше успешных компаний? И они были все разные, со своими индивидуальными подходами в ведении бизнеса. А ответ очень простой. Раньше во главу угла ставили не какую-то "волшебную" методологию, а профессиональных специалистов, которые и разрабатывали свои производственные процессы, в зависимости от нужд конкретного бизнеса. Другими словами, именно люди приносили ценный вклад в сложный анализ и построение процессов, а не какая-то хайповая идея, с которой все носятся. Есть вещи которые можно унифицировать и упростить, а есть те, где нужно приложить особые интеллектуальные усилия и создать что-то свое.
И вот создание процессов при производстве ИТ продукта, и при его масштабировании - это один из наиважнейших моментов, который игнорируют многие. Например, только и слышишь от каждой компании, у нас скрам, а у нас канбан. А чуть всмотришься, а там полный хаос с вывеской аджайл над всем этим бардаком. Вот давайте рассмотрим один кейс. Например, компания решила создать интернет магазин. Наняла четырех программистов и дала им техническое задание: "Сделайте так, чтобы было все зашибись". Менеджеры "внедрили" скрам подход с двух недельными спринтами. Внимание вопрос. Кто наполнит эти спринты и чем? А когда начнут в спешке все переделывать, что и так из головы выдумали, то на что опираться? Как зафиксировать где проект сейчас, а где должен быть через месяц? Как вообще понять прогресс и куда все идут? Это не скрам - это СРАМ!
В условиях полной бизнес неопределенности скрам вообще не работает. Поэтому так важно и разработать свои бизнес процессы, а для этого должны быть системные аналитики. Нужен полный анализ бизнес требований, нужно создать архитектуру будущего продукта, выбрать подходящие технологии с полным пониманием почему именно они. Необходимо составить дорожную карту. А так как нельзя просто идти по шагам, по причине того что ресурсы всегда ограничены, нужно расставить приоритеты, что необходимо создать в первую очередь, а что оставить на пост релиз. И только тогда, когда у вас на руках есть вся документация, дорожная карта и приоритеты, можно использовать скрам, для гибкости процесса разработки. Но только в рамках обозначенных в дорожной карте. Если решено в первые три месяца заняться ядром системы, то только в этих задачах и должен работать скрам. А не так, что стопорим сейчас работу над АПИ системы, и переключаемся на СЕО, так как у наших маркетологов появились гениальные мысли.
Или еще, как пример, менеджер нанял одного программиста, который делает сайт на Вордпресс, второго программиста на Пайтоне, который тоже сайт делает, и еще одного, который делает сайт на Ноде. А потом такой менеджер говорит, что у них команда и они работают по скраму. И что у них даже техлид есть, который на ноде разработку ведет. А по факту есть три фрилансера, вместо единой команды, вместо скрама вагон хотелок, а не задач, а также зоопарк технологий, который до конца никто так и не довел. В итоге компания осталась с тремя недоделанными сайтами, которые создавались оставленными без присмотра людьми, которые просто что-то пилили, не совсем понимая, что от них хотят. И таких случаев очень много.
Как результат непонимания важности процессов, что это не просто какая-то готовая методология, а реальный аналитический труд, который нужно проделать, и что этим тоже профессионалы должны заниматься, происходят довольно неприятные вещи, а именно, потеря контроля и управляемости над проектом. Выйти из этой фазы без убытков нереально. А вот попасть туда очень даже легко.
7. Неумение работать с людьми
К большому сожалению, фраза "Я начальник, ты дурак", актуальна не только на пост советском пространстве, но так же и во всем мире. Руководители, которые смогли привлечь инвестиции, считают, что они уже находятся на недосягаемом для простых смертных уровне. А все потому, что любым мерилом чего-либо уже давно считаются деньги. Но вот только проблема заключается тут в том, что любые бездумно вложенные инвестиции очень быстро умножаются но ноль. А чтобы инвестиции стали работать и приносить прибыль, как раз и нужно нанимать профессионалов. А с этим таки опять беда. Отсутствие стратегического подхода будет толкать менеджеров на стандартные шаги, такие, как найм родственников или знакомых на руководящие позиции. И именно после этого и начнется раскручиваться спираль последующих проблем. Ведь для менеджеров успех по сути уже состоялся, осталась такая мелкая деталь, как создать продукт. А для этого можно нанять рекрутера подешевле. И он, а чаще она, будет искать идеального кандидата с неадекватными требованиями, типа "Должен знать и уметь абсолютно все". Первого найденного специалиста назначат эталоном. Именно он и будет собеседовать всех последующих кандидатов. По каким критериям был нанят этот "эталон", неизвестно вообще никому, даже самому нанимателю. Вот тут и возникает любопытная ситуация, кого же такой специалист будет одобрять. Но я уверен на 100%, что читатель и сам знает ответ на этот вопрос. Все эти безумные тестовые задания и лайв кодинг на позицию архитектора или техлида, говорят сами за себя ярче тысячи слов. В итоге не могут найти того, кто в одном лице создаст весь продукт за пару недель, и нанимают того, кого получится. В результате бизнес хочет всех уволить, так как программисты не оправдали его ожиданий (смотри пункт 2). А для этого нужно нанять новых программистов, которых будут собеседовать старые, которых хотят уволить. В общем, процесс создания продукта уходит на какой-то дальний план, а компания погружается в операционный ад.
А по сути все очень просто. Если нет опыта и знаний, то нужно нанять консультантов, которые эксперты в создании продуктов. Которые могут показать свои решения, построить процессы и найти верный путь вперед. А если уже так сложилось, что проект потерял контроль, то нужно опять таки нанять экспертов, которые проведут полный аудит всех процессов на проекте, проведут аудит решений и профессионализма персонала. Но бизнес, почему-то, выбирает самый сложный путь - текучку кадров, снятие ответственности с себя и перекладывание на других. И когда приходит понимание того, что вот-вот все развалится, то как правило, уже поздно, и время безвозвратно упущено.
Менеджеры всегда должны прислушиваться к специалистам и экспертам. Нельзя делать себе одно доверенное лицо и слушать только его. Чем больше мнений и взглядов на ситуацию, тем легче будет разобраться в путях решения проблем. Попытка игнорирования экспертизы, опыта и знаний других людей, не может быть заменена никакими идеями/догадками/предположениями менеджеров. Очень часто руководители требуют наличие софт скилов от своих подчиненных, но при этом сами ими не обладают. И это неумение работать с людьми обязательно будет приводить к конфликтам, текучке кадров и потери контроля над проектом.
Я уверен, что есть много еще разных причин, о которых я не упомянул. Поэтому делитесь ими в комментариях, будет интересно о них узнать.
Какой вывод тут можно сделать? Первый - без стратегического планирования не получится построить успешный, гибкий и масштабируемый продукт, который не будет тянуть экстра затрат и времени из бизнеса. А второй - ничего, к моему сожалению, так и не изменится. Поскольку за последние 20 лет понятие стратегии практически покинуло бизнес умы. Преобладает слепая вера в технологии, наличие инвестиций и желание быстрой наживы.
Автор: Kirill_Dan
