Если у вас стартап или свой сервис ( который вы делаете не спеша ) на широкий рынок, хотите быстро протестировать идею или наконец-то начать собирать обратную связь ( а может и минимальную прибыль ), значит у вас MVP.
Минимально жизнеспособный продукт ( MVP ) — продукт, обладающий минимальными, но достаточными для удовлетворения первых потребителей функциями.
Вот тут и начинаются проблемы… Управлять развитием ИТ проекта и так не просто, для этого нужен опыт как продуктовой так и коммерческой разработки, чтобы понимать в чем различия и особенности.
Проблемы быстрого запуска и мусорность кода
Не будем вдаваться в процессы разработки, описания структуры команды и других аспектов, запомним лишь что есть бизнес ( будет называть так заказчика конечного продукта ), продакт ( продакт — менеджер, занимается управлением развития продукта ) и разработчики.
Бизнес требует быстрого запуска для получения первого фидбэка, продакт общается с бизнесом, анализирует рынок и конкурентов, приоретизирует задачи и выставляет разработчикам.
Что остается разработчикам?! Делать что могут, с тем, что есть.
Почему засоряется код
Стартап это всегда про скорость, там нет времени на рефакторинг ( отладку и улучшение кода ), кучу фич, которые нужно реализовать еще вчера и про быстрое тестирование гипотез.
Поэтому возникают проеблемы:
- Задачи меняются каждый день. Много фич реализуется / реализуется на половину / становится не нужными, но времени на удаление старого кода и оптимизацию нет
- У разработчиков мало опыта. Если у разработчиков не хватает опыта, то они изначально будут писать плохой код. Такой код скапливается из-за скорости развития проекта и превращаться в хлам, который трудно поддерживать и с каждым разом будет все хуже и хуже, пока однажды вам не прийдется переписывать проект ( долго, дорого, больно )
- Плохое управление. Разработать корпоративный сайт для компании и реализовать ИТ проект в стартапе — это разные вещи, если вашей команде не хватает компетенций в управлении на каждом этапе, то ваш продукт быстро станет технологическим хламом
Чем это грозит вашему проекту
Финансовые потери. Бизнес ( или инвестор ) расходует бюджет не эффективно: тратит деньги на бессмысленные или не актуальные задачи ( очень часто задача не правильно ставится и нужно смотреть в целом на проблему, а не делать мертвому припарку ); на тестирование фич, которые вообще не нужны и никогда не будут использоваться; на переполненную команду ( у вас не много задач, у вас не эффективный управленец ).
Временные затраты. Кажется, еще страшнее чем финансовые, так как вы бессмысленно тратите время, не получаете полезного фидбэка и не запускаете свой проект. Постоянно переделывая фичи, внедряя ненужное, пытаясь сделать все и сразу вы засоряете проект и увеличиваете время на его обслуживание и развитие в будущем.
Текучка кадров. Да — да, возможно это не очевидно, но я, как разработчик, который участвовал в нескольких стартапах знаю, что если до бизнеса не донести суть проблемы, четкий план по рефакторингу важных частей проекта и его критическому улучшению, то я скорее выйду из проекта, чем каждый раз буду страдать пытаясь внедрить новые фичи и не сломать весь проект.
Как избежать проблем
Нанять опытного Product — менеджера
Опытный управленец сможет эффективно обсуждать задача, цели с бизнес — заказчиком, отстаивать свою позицию и отсеивать не нужные или не приоритетные задачи.
Главная задача продакт — менеджера это общаться с бизнес — заказчиком, отсеивать ненужные идеи, доносить суть и проблемы, важность своей позиции и развивать проект. Так как зачастую, основная проблема в таких проектах — это бесконечная генерация идей от бизнес — заказчика ( это нормально, бизнес на то и бизнес, что находится в постоянном состоянии генерации идей ), но не всегда эти идеи хорошие или актуальный, нужно уметь отстаивать позицию и доносить суть, цель и почему нужно делать иначе.
Внедрить методолию разработки ( Agile / Scrum )
Методолия позволит систематизировать разработку и внедрение нового функционала, соблюдать сроки внедрения и приоритезировать задачи.
Такие методологии позволяют:
- Быстро внедрять и тестировать новый функционал
- Не загрязнять проект ( часто бизнес ставит кучу задач, которые не приоритетны и становятся не актуальными через пару дней, но рефакторить и удалять этот не нужный код, конечно, некогда )
- Не нарушают фокус разработки ( эта методология также касается и бизнес — заказчика, он понимает что больше не может закидывать задачами и идеями на быстрое внедрение, новые задачи собираются в back log и будут в работе со следующим «спринтом» )
- Рефакторить код ( в спринт можно также закладывать рефакторинг кода, таким образом у вас не нарушаются сроки по разработке нового функционала, но и есть время улучшать / исправлять старый код, который в будущем может негативно влиять на внедрение нового )
Решить проблему с текучкой
Команда разработки также важна ( не только в плане оптыта, это мы уже определили ) и в плане самостоятельности, погруженности и заинтересованности в проекте. Без личного интереса, чувства причастности к чему-то и возможости влияния на проект, качество и чистота кода будет страдать, проект будет все сложнее и сложнее поддерживать с приходом новых людей, порог входа будет увеличиваться и все это рано или поздно сделает проект мусоркой, которую исправить только один выход — сжечь разрабатывать заново.
Поэтому лучше заинтересовать команду ( как финансово, так и перспективами роста ), дать ей возможность влиять на продукт и быть важными для проекта, так будет улучшаться и командная работа, атмосфера в коллективе и процесс разработки самого продукта.
