Две цели при разработке программного продукта

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

Разработать правильный продукт

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

• Вы планируете выйти на существующий рынок, на котором еще есть незанятые ниши?
• Это потенциальный рынок, которые еще требуется создать?
• Если мы реализуем задумку, то сможем ли эффективно донести до клиентов выгоду от ее использования?

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

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

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

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

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

Итого пять простых правил для выбора правильного продукта:

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

 Разрабатывайте продукт правильно

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

Правильные подходы к разработке программного кода обеспечат создание продукта, который не теряет данные, не имеет логических ошибок, утечек памяти и не крешется. Необходимо использовать практики на вроде «безопасного программирования», проверяя корректность значений переменных перед их использованием и анализируя коды возврата функций. Устаревший подход «мусор на вход, мусор на выход», нужно заменять на «мусор на вход, диагностика на выход». Эти дополнительные проверки немного замедляют скорость разработки и перформанс продукта, но в результате окупаются с лихвой.

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

Любая команда разработки софта должна использовать coding style. Каждый программист имеет тенденцию к изобретению своего собственного, совершенного, стиля кодирования. Если попросить 10 программистов описать стандарт кодирования, то вы получите 10 разных стандартов, а если попытаетесь выбрать лучший из них, то можете разжечь религиозную войну. Поэтому coding style должен быть выбран в ультимативной форме менеджером или тимлидом.

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

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

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

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

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

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

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

Все новости сайта в телеграм канале: @CTO_in_Action