«Проект готов на 90%» — как гибнут стартапы

Время прочтения: 6 мин
Сложность: норм Просмотров:
Денис Сапожников 09.10.2019

В среднем, раз в 3-4 недели ко мне обращаются с фразой «Проект готов на 90%, нужно доделать».

Проекты разные, люди разные, бюджеты разные, проблема одна — нужно «чуть-чуть доделать и скорее запустить».

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

Успешно стартуют из таких обращений не более 5%, оставшиеся — никогда не будут доделаны.

Чтобы ты не тратил время, деньги и нервы впустую, давай разберемся…

Что обычно скрывается под фразой «Проект готов на 90%»?

  1. Исчезнувший разработчик.
    В лучшем случае, разработчик просто признал свою некомпетентность или же ушел на работу в другой проект.
    В худшем — отсутствие договора и разработчик пропадает со всеми наработками за последние пару месяцев.
    Не важно, один это человек или речь идет о 30 исполнителях на аутсорсинге — с «проект готового на 90%» все бегут, как крысы с корабля.
  2. Отсутствие технической документации
    Написанное кое-как устаревшее техническое задание, пачка черновиков о доработках и более ничего нет — тоже характерный признак таких проектов.Нормального ТЗ — нет, иерархической стуктуры работ — нет, бэклога разработки — нет, обоснования выбора того или иного стека технологий — нет, документации к коду — нет.О том, что такое реверс инжиниринг и почему он стоит в разы дороже заказчик почему-то не догадывается.
    Как следствие, из-за затрат на реверс — зачастую, экономически выгоднее и быстрее переписать проект с нуля, нежели доделывать.
  3. Некорректно оцененный объем работ
    Очень много проектов загибается из-за первично некорректно оцененного объема работ.
    Если 20-30% от бюджета на разработку не ушло на подготовку к проекту в самом начале этой затеи — это твой случай.Тот факт, что бывший разработчик утверждает, что там работы на чуть-чуть — значит абсолютно обратную ситуацию.
    Если он некорректно оценил свои силы (а зачастую это именно так, иначе зачем менять подрядчика?), то работы там в разы, десятки раз, больше.
    Если с frontend’ом заказчик еще может кое-как принять и оценить объем реализованного, то с архитектурой баз данных, backend’ом — дело обстоит куда иначе. А уж тем более оценить «качество» написанного кода заказчик самостоятельно не может.
  4. Некорректно выбранный стэк технологий
    Ситуация, как по учебнику, бюджета на разработку 5 копеек (до 25000-30000$), а инициатор проекта ведется на «Путь истинного Джедая» выбирая хардкорные laravel, Vue, Go, Java, Swift и прочие языки взрослой разработки для создания какого-нибудь грандиозного проекта федерального масштаба.
    Чем нищеброднее проект, тем проще должен быть технологический стэк и проще происходить миграция от одной команды разработчиков к другой.Сайт Obama Foundation, Mercedes-Benz, Vogue, Sony и тысячи других более технологичных — собраны на халявной CMS WordPress.
    На кой черт массово используют тяжеловесные инструменты разработки, когда их функционал не нужен?
    Не понимаю. Видимо — тренд.
  5. Полная вакханалия в коде
    Здоровый разработчик компенсирует недостатки проект-менеджера, равно как и сильный проект-менеджер может работать со слабой командой.
    Но если твоей проект завис на «последней миле», то это не ошибка какой-то одной составляющей, это ошибка всей системы.К чему я это? Да к тому, что стоит технически подкованному программисту провести анализ пары пунктов из ТЗ и сходу понимаешь, что весь фундамент проекта, бэк и бд — создавалась мудаками. Очень редко, когда в «проекте готовом на 90%» хороший структурированный и документированный код.
  6. Отсутствие бюджета
    Были бы толковые управленцы- не было бы ситуации. У проблем с разработкой есть десятки признаков, до того, как разработка проекта прекратится.
    Раз есть проблемы — нет толковых управленцев. Нет толковых управленцев — нет управления рисками, бюджетами, временем и качеством разработки.
  7. Отсутствие времени
    На стадии «проект готов на 90%» любой проект может находиться сколь угодно долго.
    Но входит он в эту стадию всегда одинаково — сперва падает эффективность работы разработчиков, потом проект-менеджер начинает ускорять разработчика и проявлять излишнюю личную вовлеченность в техническую часть, потом разработчик отваливается.
    Все эти стадии, равно как и поиск замены разработичку, занимают массу времени.
    Как следствие, расчетный дедлайн упущен и проект горит.
  8. Слабый проект-менеджер со стороны заказчика
    Бестолковый разработчик всегда стоит дороже толкового.
    Ни один здоровый проект-менеджер недоспустит ситуации ухода из проекта ключевого разработчика, он будет увеличивать ЗП, добавлять «печеньки», заботиться о кошке разработчика и любых его прихотях и настроении. Здоровый проект-менеджер знает, что затраты на смену разработчика обойдутся гораздо дороже, чем удержание текущего.
    Как следствие, если в вашем проекте «отвалилась» проектная команда, значит что-то тут не так.
  9. Моральная усталость от проекта и всеобщий нервяк
    Пояснений не требует.

 

Что делать, чтобы такого не произошло с твоим проектом?

  1. Менеджмент и документация
    Необходимо потратить колоссальное количество средств и времени на организационные моменты и создание регламентов (требований) к программному коду и его документации.
  2. Адекватное техническое задание
    Необходимо  наложить 20-30% бюджета от разработки на техническое задание и подбор технических решений. Привлечь к этой деятельности более дорогих и толковых консультантов.
  3. Юридическая защита
    Разработать договор с разработчиком и иными стейкхолдерами еще до начала проекта, «на берегу».
  4. Объективная оценка финансовых возможностей
    Блог или интернет магазин — способы разработать 1-2 толковых специалиста.
    У более серьезных проектов (SAAS-сервисы, маркетплейсы, образовательные платформы, AR/VR, AI и пр) минимальная команда 4 человека (тимлид, 2 программиста и проект-менеджер). Не способны содержать команду из 4 человек на протяжении года — не нужно лезть в серьезную разработку.
  5. Сильный управленец
    Обучиться проектному управлению в IT или найти того, кто уже имеет опыт в этой деятельности и нанять его.
  6. Резервный бюджет
    Заложить больший резервный бюджет, чем это минимально необходимо.
    В зависимости от масштабов проекта, резерв должен составлять минимум от 20 до 60% от всего бюджета на разработку.

 

 

Что делать, если это уже произошло с твоим проектом?

  1. Успокоиться
    От твоих переживаний и нервов ничего не изменится. Здоровье и жизнь дороже практически любого проекта.
    Если физически и морально вымотан — отдохни. Серьезно, сейчас самое классное время, чтобы восстановить силы.
    Программный код — не фургон овощей, он не испортится за пару месяцев.
    Разработка проекта — самая простая часть в IT-проектах, если ты вымотался на этом этапе, не нужно пытаться добить проект.
    Самое «веселье» начнется на этапе ввода в эксплуатацию и продвижении, в этот момент времени нужно иметь достаточное количество личной энергии.
  2. Пересмотреть свою систему координат и разрушить все «воздушные замки»
    «Сейчас найду разработчика, еще месяцок и в продакш», «15% от общего бюджета — не беда, осталось выполнить то всего 10% работ», «разработчиков на Vue/Go/Laravel/Flutter/ЛюбойДругой много, найдется тот кто сходу сможет доделать проект».Можешь на меня обижаться, но ситуация, когда «проект готов на 90%» — очень тяжкое положение, задница в простонародье.
    Чем раньше это осознается, тем лучше и легче дальше пойдет доработка проекта или ну или его сворачивание.
  3. Объективно оценить ситуацию
    а) Сколько осталось финансов на разработку
    б) Сколько стоит оценить текущее техническое состояние проекта
    в) Сколько стоит доработка проекта до работоспособного состояния
    г) Что ограничивает время на разработку, сколько есть времени, как увеличить его
  4. Принять решение о том, что нужно делать
  5. Реализовать задуманное

 

Успехов тебе и твоим проектам.

 

P.s. Если проектное управление в IT — совсем новая для тебя тема, почитай статьи из моей первой книги «Учебник веб-клиента» (2016), а именно:
а) Этапы становления проекта
б) Выбор системы управления сайтом (CMS)
в) Толковые разработчики — мудаки
г) Ложь, наглая ложь, веб-аналитика
д) Философия и ошибки разработки минимально жизнеспособного продукта MVP

 

P.s.(2) В РФ очень слабая проектная практика и мало информации на эту тему. Если статья и проект «Дед Денис» был полезен тебе — поддержи проект рублем, ведь он позволит сохранить гораздо больше. Спасибо.

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

А пока этого не произошло, я буду писать этот блог и стараться давать Вам самую суть разработки, продвижения и управления в IT‑проектах.


P.s. нравится проект?
Ну так помоги развить его - репосты, донат и интересная работа приветствуются

Рекомендую посмотреть

Случайный вопрос

Сколько стоит разработать мобильное приложение на iOS?

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

Показать больше ответов

Привет, дружок‑пирожок