Процесс разработки программного продукта сопряжен с кучей подводных камней и возникающих проблем.
Будет хорошо, если вы узнаете о них до начала проекта. В этом случае они не будут для вас неприятным сюрпризом, и вы будете готовы к их решению.
У нас есть отдельная статья про карту рисков сайта (сайт упал, пароли украли и т.д.). Данная статья отличается тем, что мы здесь сосредоточимся именно на процессе разработки и полученном результате - программном продукте.
Для заказчика созданный сайт, в большинстве случаев - это айсберг. Он видит только внешнюю оболочку и не представляет, что там внутри. Многие заказчики не знают даже на какой технологии сделан их сайт. В этой статье мы попробуем вскрыть эти возможные подводные камни.
Мы рассмотрим каждый риск, а также дадим советы, как можно его минимизировать в плане критичности и вероятности.
Это серьезная проблема для кастом проектов, где используется не готовое решение, а создается что-то свое.
Программисты сделали сайт, все хорошо работает. Вы начинаете работать, а через некоторое время сайт начинает сильно тормозить, пользователи жалуются, вываливаются ошибки. Что случилось?
Проблема в том, что программисты делали свой код на небольших тестовых данных. Если в таблице 100-1000 строк, то даже если вы напишете суперкривой запрос SQL, он все равно будет работать быстро. Но как только в таблице станет достаточно много данных (100 000+), то запросы начинают уходить в таймаут, т.к. сервер подвисает.
Эту проблему сложно выявить на начальных стадиях.
Что предлагаю делать:
Не нужно думать, что если сайт работал год назад, то он и сейчас должен так же работать. Сайту требуется обслуживание, сопровождение. Если этого не делать, база разрастается, запросы замедляются, проблемы наслаиваются и получается тяжелый эффект.
Гораздо правильнее решать такие проблемы по диагностике, т.е. ежемесячно проводить анализ базы данных, выискивать проблемные запросы и оптимизировать.
В Falcon Space мы собрали все инструменты диагностики базы в одном месте. Эти инструменты позволяют находить проблемные места в проекте:
Главный посыл - эта проблема в любом случае появится при росте проекта, нужно быть готовым решать ее:
Никто об этом не думает на начальной стадии проекта, верно?
А ведь именно эта часть жизненного цикла будет самой большой. Продукт будет расти, меняться, дорабатываться.
Если стоимость изменений в будущем очень высока, то такие изменения будут делаться неохотно, с оговоркой "Бюджет не резиновый", "А может не нужно?".
В идеале нужно сделать так, что любое мелкое внедрение можно было бы сделать прямо здесь и сейчас, и стоило бы это только как чисто временные затраты на саму полезную работу по изменению.
Мы создали свою учетную систему на своей же платформе. Изменения в нее вносятся по ходу использования. Зачастую новая таблица добавляется в интерфейс прямо по ходу использования (придумали, что нужен такой-то отчет - сразу выводим и используем в течение часа).
Если же цикл изменения большой, есть dev, prod и test stage, инженеры по тестированию, devops и прочее - любое изменение может занимать рабочий день. Т.е. полезная правка программиста заняла допустим час, но затраты будут часов на 8-10, т.к. требуются разные специалисты для доставки всего этого добра на сервер.
При простом цикле правок возникает другая проблема - внесение ошибок. Тут 3 момента: во-первых, при сложном цикле этот риск никуда не девается, более того, сам сложный процесс может породить новые ошибки. Во-вторых, быстрые правки позволяют также и быстро править ошибки. Обнаружили внесенную ошибку - сразу надо исправлять. Данный подход должен рука об руку идти с плотной диагностикой. Мониторьте ошибки и оперативно на них реагируйте. В-третьих, никто не мешает вам тренироваться на кошках - сделайте копию страницы, таблицы и работайте с ней. Добейтесь нужного поведения и перенесите на основную таблицу.
Как вы поняли, мы за простой цикл внесения изменений. Это уменьшает стоимость владения, упрощает поддержку и уменьшает количество людей на проекте. Для стартапа это означает более долгий срок жизни и меньше риска дефицита бюджета на проекте.
Технологии навряд ли как-то вытащат наверх ваш проект, но могут значительно подпортить карму проекту.
Например, захотели вы сделать IOS приложение для учета финансов (все же пользователи Iphone более платежеспособные, верно?). Долго делали, внедрили, исправили все баги, получили хороший фидбек. А потом платформу IOS просто закрыли для определенных стран (нет, такого не бывает).
Учитывайте риски определенных технологий и вендоров.
Если ваши данные хранятся у кого-то в облаке - эти данные могут исчезнуть в любой момент. Пример - Google Drive и связанные инструменты.
Вы используете тильду? В целом это хорошо, но имейте копию страницы для того, чтобы быстренько ее можно было к себе перенести на свой хостинг с Wordpress.
Прогресс нас тянет использовать различные Dadata, Google сервисы, яндекс сервисы и т.д., но он также повышает наши риски.
Сделайте так, чтобы ключевая технология была надежной и под вашим контролем (желательно на вашем сервере).
А для второстепенных технологий можно использовать внешние сервисы, но с оговоркой, что в будущем им возможно придется искать замену. Пример - недавно мы внедрили в платформу компонент Яндекс Карты как альтернативу существующему компоненту Google Карты.
Иногда предлагают делать проекты, где данные собираются по парсингу.
На мой взгляд, это очень ненадежно, неудобно, неправильно и некрасиво. Что-то поменялось на внешних сайтах - у вас упало. Внедрили новую защиту от парсинга - у вас упало. Скрыли часть полей от вывода - у вас нет этих данных теперь.
Изначально делайте ставку на стабильные простые правильные технологии. Не нужно пытаться делать ставку на технологичность (особенно, если вы от этого далеки). Не нужны вам блокчейны, искусственный интеллект и прочие сложные штуки.
Вспомните про простые понятные проекты, которые выстрелили - Excel, 1C, Telegram - в них нет какого-то новомодного тренда. Они просто хорошо выполняют свою основную задачу.
Это больше растет от качества кода программы и хрупкой архитектуры. Если ваша система очень критично относится к малейшей ошибки в настройках или коде- это плохо.
К примеру, возникли в какой-то процедуре ошибки - и весь сайт просто падает и не запускается. Так быть не должно. Если где-то ошибка - нужно дать сообщение об ошибки, но хоть как-то загрузить базовое содержимое. Также неприятно, когда код критично реагирует на разный ввод. При одних данных он работает хорошо, при других - все падает.
Система должна быть построена таким образом, чтобы:
Если вы программист, то у меня для вас только один совет - почаще проверяйте на NULL.
Вы можете сделать хорошее полезное приложение. Но его могут взломать. Необходимо на уровне кода внедрять проверки доступа и защиту от основных типов атак (XSS, SQL injection, DOS и др.)
Чтобы защититься от возможных проблем используйте такие рекомендации:
Если вы не технарь, то вы можете спросить у программиста "А как мы проверяем доступ для этой функции". Прямо по коду пусть покажет, как проверяет тот или иной доступ или как работает система авторизации на определенное действие.
Представьте, делали-делали сложный каталог. А потом пришел SEOшник и сказал - а почему страницы каталога не статичные? Как их будет считывать поисковик?
Т.е. в проекте могут быть такие критичные моменты, которые нужно учесть сразу в самом начале. Желательно показывать свой проект специалистам различного толка и выявлять подобные критичные элементы.
Это могут быть особенности API, подпадание под требования внешнего регулятора (государство, поисковик и т.д.), локализация на разные языки.
Про сроки сказано уже очень много. Есть хорошая книга Цель Голдратта. Читайте, перенимайте опыт заводов по работе с узкими звеньями.
Почему срываются сроки проектов:
Как можно улучшить ситуацию со сроками:
Этот пункт идет рука об руку с предыдущим и последующим.
Большой объем, новые хотелки по ходу проекта, желание сделать все максимально кастомно под себя, большая команда, требующая взаимодействия - все это приводит к удорожанию проекта.
Большая проблема возникает, когда у проекта первой версии нет каких-то явных границ. В итоге проект превращается в постоянное накачивание новыми фичами, интеграциями и улучшениями без реального внедрения.
Переводите свой проект на диету - меньше новых хотелок, более конкретные цели (аналог - килограммы на весах), более простые решения в проекте (полезная еда).
Это бич кастом разработки. Чем сложнее проект, чем более он кастомный, чем больше в нем разных интеграций, тем больше ошибок будет в итоге.
И зачастую это не вина программистов. Ошибки - это часть разработки. Другой вопрос - тестеры должны находить большую часть этих ошибок, а не конечные пользователи.
Хотите уменьшить количество ошибок? Уменьшите объем проекта, принимайте решения с учетом сложности и кастомизации, не используйте в проекте ненадежные решения и хрупкие технологии.
Здесь мы дадим общие рекомендации по снижению рисков разработки.
Разработчики могут заложить логические бомбы в код. Могут сделать специальные лазейки. Поддерживайте хорошие партнерские отношения.
Если разработчик неадекватный, плохо делает - по хорошему расстаньтесь с ним, даже если он совсем редиска.
Любой обиженный технический специалист - повышение риска для проекта.
Хорошо бы иметь человека, который может вас вести по техническим дебрям, которому вы будете доверять, и который никак не имеет своего интереса в проекте.
Но не нужно брать в ряды таких советников диванных теоретиков, которые все знают обо всем, но ничего сами руками не делали. Обычно это некие консультанты, которые умеют красиво говорить о рисках, о том, как должно быть, но чуть ковырни - и нет за этим никаких глубинных знаний. Такие люди скорее будут вредны проекту, нежели оберегут его от серьезной угрозы.
Также у советника не должно быть интереса в проекте - иначе он приведет в проект своего подрядчика, свои продукты и т.д.
Сделали продукт - сразу наполняйте базу и активно внедряйте процессы. Так вы избежите риска, что система просто не будет внедрена вообще.
Т.е. пока все свежо, пока проект актуален, пока все помнят слабые места проекта - активно надо его внедрять и выявлять проблемные зоны.
Помните о возможных проблемах роста базы данных и сразу наполняйте ее данными для полноценного использования, чтобы выявить проблемы роста на самой ранней стадии использования.
Чем меньше первая версия, тем качественнее она будет сделана, тем меньше проблемных мест в ней, тем лучше вы ее протестируете.
Частая болезнь - пухлый объем первой версии. Малыш, еще не ходит, а его откармливают, откармливают. В итоге он встать на ноги (запуститься в эксплуатацию) уже просто не может.
Лучше добейтесь реального использования на более узком функционале, и затем расширяйте его по мере получения РЕАЛЬНОЙ обратной связи от пользователей.
50% создаваемой вами системы вообще никому не нужна. Но какая именно - это ясно будет только после запуска проекта в реальную эксплуатацию.
Нужно следить за кодом. Нужно контролировать рабочие характеристики проекта.
Если мы не смотрим за кодом, то есть риск плохих решений от отдельных разработчиков. Он может принять хорошие, а может плохие решения.
И выявляется без просмотра кода только тогда, когда стоимость изменений уже сильно выросла. Чем раньше обнаружена неточность, тем дешевле ее поправить.
Отслеживайте ключевые параметры кода - скорость загрузки страниц и выполнения операций, количество исключений, нагрузка на процессор и т.д. В итоге можно на ранней стадии выявить проблему и порешать ее в спокойной атмосфере, а не когда все падает, тормозит, слышатся безумные вопли "Ниче не грузится!!!".
Отдельную статью мы посвятили теме Как защитить сайт?
Если у проекта нет документации - вы в плену у разработчиков.
Без документации вы не сможете нормально сменить подрядчика по разработке. А также не будет точного понимания как эта программа работает.
Какая нужна документация:
Максимально точно пропишите бизнес-логику в отдельном документе, это позволит всех новичков в проекте проще знакомить с деталями, а не отправлять к старейшине на проекте за сакральными знаниями.
Проводите различные аудиты, которые улучшают качество вашего продукта. Это могуть быть SEO параметры, быстродействие, нагрузочное тестирование, тесты юзабилити и другое.
Это не разовая, а регулярная работа - находите проблемы и ставьте задачи на улучшение продукта.
Только так можно добиться хорошего качества продукта. Качество - это не про единичный результат, это про процесс.
Мы постарались изложить свой анализ рисков разработки - какие подводные камни вы можете встретить при разработке программ или сайтов.
Есть и более специфичные риски, касающиеся отдельных технологий или платформ. Здесь мы прошлись по верхам, но даже такое введение уже дает достаточно много материала для планирования работ по улучшению качества продукта и выявлению рисков в разрабатываемом продукте.
Источник: https://falconspace.ru/blog/analiz-riskov-razrabotki-veb-proektov-i-programm