Она представляет собой последовательный переход от этапа к этапу: Анализ требований — Проектирование — Реализация —Тестирование — Интеграция — Поддержка. Пока не закончится предыдущий этап, не начнется следующий. Можно обратиться к названию и представить, как вода стекает сверху вниз с камушка на камушек. Как вода не может вернуться обратно наверх, так и в разработке вернуться на шаг назад тоже нельзя. Внести изменения можно только после релиза проекта.
Пройдемся по конкретным минусам модели:
Нет никакой гибкости. Модель неудобна тем, что невозможно все продумать до мельчайших подробностей с самого начала. Все проблемы могут «расцвести» только в конце проекта. Тогда придется все начинать заново, а заказчику оплачивать дополнительные часы разработки.
Заказчик участвует в проекте только на уровне согласования, например, дизайна.
Так как проект не тестируется на реальных пользователях, то по окончании разработки продукт может не соответствовать требованиям потребителя.
Вероятно, будут конфликтные ситуации, когда заказчик хочет получить больше за меньшие деньги, а подрядчик хочет сделать меньше, чтобы получить запланированную прибыль.
Плюсы «водопада»:
Заказчик изначально знает, какой бюджет он должен вложить, и ему не приходится быть включенным в каждый этап разработки.
При таком подходе точно есть гарантии, что проект завершится, правда из-за человеческого фактора не всегда в нужный срок.
Есть четкие инструкции и правила по всему процессу.
Так как все правила уже заранее описаны, то в проект может легко вписаться любой новый разработчик или тестировщик.
Водопадная модель основана на предположении, что все требования, задачи и ресурсы можно точно определить и спланировать заранее. Однако, это редко бывает возможным в реальных условиях. Все может прийти к тому, что проект будет задерживаться, перерасходовать бюджет или даже провалится.
Сначала введем в курс дела и расскажем, что такое MVP. Возможно, вы могли слышать термин, если изучали тему стартапов. MVP или Minimum Viable Product — это минимально-жизнеспособный продукт, который позволяет во-первых, проверить работу гипотез на пользователях, а во-вторых, исследовать целевую аудиторию запущенного продукта. MVP пришел из концепций Lean Startup и Customer Development.
Для понимания можно использовать аналогию еды (все ведь такое любят:). Представим бургер, который состоит из двух булочек и котлеты. Съедобно? В целом — да. Но не хватает соусов, листика салата, огурчиков-помидорчиков.
Так и мы, когда создаем MVP, дальше продолжаем с ним работать в формате спринтов и развиваем. Добавляем те самые ингредиенты, которые по итогу дадут вкусный результат.
Если говорить про сайты, то даже имея MVP сайта, уже можно наполнить его контентом и рассказать о продукте, дать форму для контактов и предложить выйти на взаимодействие с менеджерами.
Плюсы подхода:
Слона едим по частям. Весь проект разбиваем на кучу маленьких спринтов и проверяем множество гипотез.
Изменения можно внести на любом этапе и ничего не посыпется.
Продукт может тестироваться на ранних этапах, причем самими же пользователями.
Клиент, который представляет услуги или товары на создаваемом сайте, уже может начать продавать.
Команда меньше устает за счет постоянной демонстрации конечного небольшого понятного результата.
Минусы подхода:
Невозможно точно предсказать, сколько денег в итоге уйдет на проект. Развитие может быть бесконечным, но в рамках оговоренных ежемесячных трат.
Можно увлечься в доработках и не прийти к какой-то конечной точке при разработке, все время откладывая релиз продукта.
Мы придерживаемся мнения, что проще через пару месяцев получить начальную, но рабочую версию продукта, чем через 8 получить классный проект, но который уже никому не нужен. За это время бизнес уже мог закрыться, владелец обанкротиться, ведь сайт не был готов и, соответственно, продажи не шли или шли плохо. Может просто пропала мотивация. Если бы выбрали подход «MVP+развитие», то за этот период можно было протестировать 20 различных гипотез.
Не будем совсем принижать водопадную модель, она подходит в следующих случаях:
Заказчик знает, что он хочет получить в самом конце.
Заказчику известны все сроки и решения, которые будут приняты на каждом этапе.
Команде заранее известно, какими инструментами они будут пользоваться в процессе разработки.
У клиента нет желания постоянно взаимодействовать с командой, согласен только в редких случаях.
Проект долгий, сложный и дорогостоящий.
Гипотезы развития сайтов: зачем и как их тестировать
Развитие сайта чем-то напоминает развитие всего бизнеса. Если вы хотите увеличить оборот, повторные продажи, средний чек — или, наоборот, снизить издержки и себестоимость товара, то вам нужно тестировать гипотезы в бизнесе. Гипотезы помогут и в развитии сайта.
22 НОЯБРЯ 2023
Что мы делаем, когда приходит клиент и говорит «мне нужно, чтобы на моем сайте была оплата картой»?
В статье расписали шаги подключения онлайн-оплаты в интернет-магазине. Собрана информация по подключению онлайн-кассы и возможные модули, которые мы уже когда-то использовали на проектах.
24 ОКТЯБРЯ 2023
К чему стоит быть готовыми, если приносите проект на поддержку/развитие
Прежде чем браться за проект поддержки и развития обратившегося к нам клиента, мы проясняем все технические и управленческие моменты.
18 ОКТЯБРЯ 2023Хотите работать с нами?
Спасибо. Мы получили вашу заявку и ответим в течение пары дней.
Что будет дальше:
Обычно мы отвечаем в течение двух рабочих дней. За это время мы «сделаем домашку», внимательно прочитаем ваше письмо, подготовимся и вернемся с обстоятельным ответом.
Спасибо. Мы получили ваше резюме и ответим в течение пары дней.
Обычно мы отвечаем в течение двух рабочих дней.
Прикрепить резюме
Форма обратной связи
