Почему проваливаются самые амбициозные проекты

Александр Пряхин
Александр Пряхин

Преподаватель GeekBrains и декан факультета веб-разработки GeekUniversity

Расскажите друзьям
Вероника Елкина

Почему амбициозные проекты с крутыми идеями «не взлетают»? Их цели восхищают, а лидеры вдохновляют инвесторов. Но проходит время, и они закрываются. Почему разработчики оставляют умирать множество своих сайд-проектов «в столе», так и не дав им увидеть свет? Своим мнением в этой статье делится Александр Пряхин, преподаватель GeekBrains, декан факультета веб-разработки GeekUniversity.

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

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

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

В информационной безопасности известен так называемый «принцип разумной достаточности». Гласит он следующее:

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

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

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

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

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

Выбор технологий

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

Ситуация с любой новой технологией имеет много общего с экспериментальными лекарствами. В определенной критической ситуации их применение вполне объяснимо: других вариантов зачастую не остается. Но если у вас есть выбор между существующей технологией и чем-то новомодным, но находящемся «на слуху», что выберете вы?

picФото: Unsplash

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

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

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

«Так что же, откатываемся до Assembler?».  Нет. Ни в коем случае. Новые системы/языки/решения нужно внедрять, но относиться к этому следует с осторожностью. Выбирая решение для внедрения, честно ответьте себе на следующие вопросы:

  1. Чем, кроме крутизны, обусловлен выбор технологии? Самый первый вопрос. Чему, кроме вашего профессионального эго, будет полезно нововведение?
  2. Можно ли решить ту же самую задачу теми средствами, что у меня есть? Может быть, вы просто пытаетесь изобрести велосипед?
  3. Какие проблемы встречает сообщество рассматриваемого решения при внедрении? Почитайте на форумах и тематических ресурсах обзоры и отзывы. Может быть, решение еще «сырое»?
  4. Что показывают бенчмарки (сравнительные тесты) по данному решению в сравнении с его аналогами? Какой именно выигрыш в производительности или решениях даст вам выбранная технология?
  5. Есть ли у вас пошаговый план с жесткими сроками по внедрению данного решения в проект? Всегда отвечайте на вопрос «Как?». Нельзя отвечать «Здесь мы анализируем логи». Нужно отвечать «Здесь мы при помощи решения N анализируем логи, применяя алгоритм M, который консолидирует результаты на сервере K».
  6. Кто будет отвечать за поддержку и развитие данного продукта после запуска? Самый простой пример: запустили корпоративную Wiki, а дальше что? Кто будет вести и актуализировать записи в ней? Всем, как правило, лень.

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

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

Оценка сил команды

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

В идеальном варианте, когда у команды или компании есть ресурсы, нужно нанимать менеджера проектов, а еще лучше — владельца продукта (product owner). Этот человек должен будет заниматься планированием рабочего времени команды разработки совместно с тимлидом.

picФото: Unsplash

Согласно сложившимся практикам, на риски отводится до 30% рабочего времени команды, т.е. та оценка, которая дается разработчиками, может быть смело увеличена на эти самые тридцать процентов.

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

Отдельная история — это решение, с которым команда не работала. Внедряете новый для большинства фреймворк? Умножайте сроки в три раза. Я не шучу. Если вы хотите получить на выходе что-то отличное от велосипеда с квадратными колесами, нужно будет учитывать, что люди будут учиться работать с новым решением, узнавать его, нарабатывать опыт. А это процесс далеко не быстрый.

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

Наиболее реальной и удобной является практика подготовки MVC — Minimal Viable Product. Это компромиссное решение, которое заключается в поставке конечному пользователю продукта с небольшим количеством функций, но без багов и проблем в использовании.

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

Реальный пример

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

  • На проект давался месяц.
  • Проект имел свободную тему.
  • Проект должен был иметь четкое (разумеется, на уровне обучения) техническое описание.
  • По результатам должен получиться MVP, что немаловажно. Т.е. хоть маленький, но продукт.

Идеи

Конечный вариант

Конструктор сайтов для различных услуг

Веб-сервис «Список покупок»

Приложение для ИП (набор простых инструментов, по сути — простая CRM)

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

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

Давайте разберемся.

  1. Идеи действительно очень большие. Любой программист скажет, что месяц на ту же CRM — это не так уж и много, даже если есть команда. Впрочем, проект в виде MVP реализуем, если бы не другой фактор.
  2. Команда еще не «слеталась» — люди не знают своего реального ресурса, не говоря уже о ресурсах своих коллег в проекте. Это сильно тормозит разработку. «Сработанная» команда должна пройти явно не один месяц совместной разработки.
  3. Команда ввела практику ежедневной отчетности — этакий Daily standup в Telegram. Но со временем перестала ее соблюдать. А это означает, что реальный статус проекта стал размываться.

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

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

Вместо заключения

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

  1. Будьте скептиком в отношении выбираемого решения.
  2. Помните про конечного пользователя и его заинтересованность в продукте.
  3. «Если какая-нибудь неприятность может произойти — она обязательно произойдёт» (с) Закон Мерфи. Риски есть всегда. В первую очередь их нужно не избегать, а предусматривать.
  4. Всегда честно отвечайте на вопрос «Как?» в отношении выбранного решения.

Материалы по теме:


Дизайнер Facebook рассказал о принципах разработки продукта в WhatsApp

Золотая лихорадка на рынке мобильных приложений закончилась. Или нет?

15 понятных советов по развитию вашего стартапа

«Эффект планирования» в бизнесе: почему маленькие цели дают большие результаты


Актуальные материалы — в Telegram-канале @Rusbase

Нашли опечатку? Выделите текст и нажмите Ctrl + Enter


Комментарии

Зарегистрируйтесь, чтобы оставлять комментарии и получить доступ к Pipeline — социальной сети, соединяющей стартапы и инвесторов.
EMERGE
31 мая 2019
Ещё события


Telegram канал @rusbase



Реклама помогает Rusbase


Разместить рекламу