Грязный стартап: как запороть сайт плохим кодом

Мужчина с удивленным видом у ПК

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

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

Вот тут и начинаются проблемы… Управлять развитием ИТ проекта и так не просто, для этого нужен опыт как продуктовой так и коммерческой разработки, чтобы понимать в чем различия и особенности.

Проблемы быстрого запуска и мусорность кода

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

Бизнес требует быстрого запуска для получения первого фидбэка, продакт общается с бизнесом, анализирует рынок и конкурентов, приоретизирует задачи и выставляет разработчикам.

Что остается разработчикам?! Делать что могут, с тем, что есть.

Почему засоряется код

Стартап это всегда про скорость, там нет времени на рефакторинг ( отладку и улучшение кода ), кучу фич, которые нужно реализовать еще вчера и про быстрое тестирование гипотез.

Поэтому возникают проеблемы:

  1. Задачи меняются каждый день. Много фич реализуется / реализуется на половину / становится не нужными, но времени на удаление старого кода и оптимизацию нет
  2. У разработчиков мало опыта. Если у разработчиков не хватает опыта, то они изначально будут писать плохой код. Такой код скапливается из-за скорости развития проекта и превращаться в хлам, который трудно поддерживать и с каждым разом будет все хуже и хуже, пока однажды вам не прийдется переписывать проект ( долго, дорого, больно )
  3. Плохое управление. Разработать корпоративный сайт для компании и реализовать ИТ проект в стартапе — это разные вещи, если вашей команде не хватает компетенций в управлении на каждом этапе, то ваш продукт быстро станет технологическим хламом

Чем это грозит вашему проекту

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

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

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

Как избежать проблем

Нанять опытного Product — менеджера

Опытный управленец сможет эффективно обсуждать задача, цели с бизнес — заказчиком, отстаивать свою позицию и отсеивать не нужные или не приоритетные задачи.

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

Внедрить методолию разработки ( Agile / Scrum )

Методолия позволит систематизировать разработку и внедрение нового функционала, соблюдать сроки внедрения и приоритезировать задачи.

Такие методологии позволяют:

  1. Быстро внедрять и тестировать новый функционал
  2. Не загрязнять проект ( часто бизнес ставит кучу задач, которые не приоритетны и становятся не актуальными через пару дней, но рефакторить и удалять этот не нужный код, конечно, некогда )
  3. Не нарушают фокус разработки ( эта методология также касается и бизнес — заказчика, он понимает что больше не может закидывать задачами и идеями на быстрое внедрение, новые задачи собираются в back log и будут в работе со следующим «спринтом» )
  4. Рефакторить код ( в спринт можно также закладывать рефакторинг кода, таким образом у вас не нарушаются сроки по разработке нового функционала, но и есть время улучшать / исправлять старый код, который в будущем может негативно влиять на внедрение нового )

Решить проблему с текучкой

Команда разработки также важна ( не только в плане оптыта, это мы уже определили ) и в плане самостоятельности, погруженности и заинтересованности в проекте. Без личного интереса, чувства причастности к чему-то и возможости влияния на проект, качество и чистота кода будет страдать, проект будет все сложнее и сложнее поддерживать с приходом новых людей, порог входа будет увеличиваться и все это рано или поздно сделает проект мусоркой, которую исправить только один выход — сжечь разрабатывать заново.

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

Консультация

Оставьте заявку на консультацию

    О проекте

    Расскажите о проекте, чтобы я мог подготовить предварительное предложение

      Написать в телеграм