Почему терпят фиаско даже самые многообещающие бизнес проекты

1 660

 

Что происходит с большинством Startapов? Инвестиционные компании вкладывают в перспективные проекты, идеи которых воодушевляют, а создатели вдохновляют своим энтузиазмом. Но сколько этих проектов выживает и превращается в прибыльный бизнес?

Каким образом большинство перспективных программных продуктов пылятся «на полке» разработчиков?

Свое видение некоторых аспектов этой проблемы предлагает  Александр Пряхин, преподаватель GeekBrains, декан факультета веб-разработки GeekUniversity

 

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

  • Новая технология – мы используем ее!
  • Дело простое – делаем сервер для сбора информации, пишем аналитический скрипт, отправляем заказчику
  • Мы быстро разберемся в новой технологии, сделаем прототипирование

Вы узнали свой подход? Не удивлюсь, если так.

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

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

В чем связь нашей темы и принципа разумной достаточности?

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

«Создание идеального кода и идеального ПО невозможно. В любой программе будут оставаться ненулевые вероятности сбоев и ошибок»

Вы согласны со мной? Сможете привести хотя бы один пример абсолютно безопасного и безотказного дата-центра или любой другой мощной системы?

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

 

Пункт 1. Классная технология! Будем ее использовать!

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

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

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

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

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

Для того, чтобы использование нового решения в проектах было осознанным и имело смысл, давайте сначала ответим на несколько вопросов:

  1. Что даст нам внедрение этой технологии? (Какую цель преследуем этим шагом?)
  2. Можем ли мы решить эту задачу теми средствами, которые уже имеем? (Аудит имеющихся ресурсов)
  3. С какими проблемами сталкиваются другие пользователи этой технологии? (Мониторинг блогов, форумов, обзоров..)
  4. Какие аналоги данного решения существуют? Их преимущества и недостатки? (Сравнительные тесты)
  5. Каков план внедрения этой технологии в проект? Этапы? Сроки? (Если этого не сделать, сроки и стоимость могут увеличиваться бесконечно)
  6. Кто будет поддерживать и развивать проект после запуска? (Часто на этом этапе проекты перестают обновляться и теряют актуальность)

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

 

Пункт 2. Командные ресурсы

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

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

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

Если IT не является самостоятельным подразделением, то параллельно с созданием нового продукта не стоит забывать про своих клиентов и пользователей, которые требуют текущих решений. По разную сторону баррикад оказываются департаменты продаж и те, кто готовит продукт к продаже. Что делать, если любое решение требуется уже вчера? Попробуйте использовать практику MVC – Minimal Viable Product. Это промежуточное решение. Вы предлагаете клиенту продукт с ограниченным набором функций, но хорошо протестированное, без проблем в использовании. Таким образом, вы получаете время на доработку своего продукта, а пользователь знакомится с интерфейсов и основными возможностями.

 

Пункт 3. Пример

Приведу пример из моей практики. То, что студенты планировали подготовить и то, что получилось в результате.

Исходные требования:

  1. Срок проекта – месяц
  2. Тема проекта – свободная
  3. У проекта должно быть четкое техническое описание (в рамках обучения)
  4. Результат проекта – Minimal Viable Product. Т.е. продукт, готовый к использованию.
ИдеиКонечный вариант
Конструктор сайтов для различных услугВеб-сервис «Список покупок»
Приложение для ИП (набор простых инструментов, по сути — простая CRM)

 

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

Почему же конечный результат оказался столь скромным? Попробуем разобраться.

  1. Идеи первоначально были интересные, но достаточно объемные. Любой опытный разработчик знает, что месяц для разработки даже простой CRM срок недостаточный. Даже при наличии команды. Хотя, вывести продукт в виде MVP было возможно, если бы не следующий пункт.
  2. Несработанная команда. Участники еще недостаточно знают как о собственных возможностях, так и о ресурсах других членов команды. Это существенно увеличивает срок выполнения проекта.
  3. Недостаточная организация работы. Первое время команда вела ежедневную отчетность в мессенджере. Однако интерес к выполнению проекта снизился и достижение результата в срок оказалось под угрозой.

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

 

Подводя итоги.

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

  1. Надейтесь на лучшее, но готовьтесь к худшему.
  2. Держите в фокусе заказчика и его потребность в продукте.
  3. Риски невозможно избежать. Их можно предусмотреть.
  4. Максимально подробно составьте план реализации выбранного решения.

Еще подробнее на эту тему в этом видео:

admin
Author: admin

1 Комментарий
  1. admin говорит

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

Оставьте ответ

Войти: 

Ваш электронный адрес не будет опубликован.

preloader