В Qualitica мы занимаемся экспертной разработкой веб-сайтов для повышения эффективности бизнеса, от этапа брифинга до момента совершенствования существующей функциональности. И на основе некоторых случаев мы подготовили текст о том, как именно учитывать возможные риски еще до момента реализации проекта, чтобы избежать ошибок.
Не та аудитория
Это, пожалуй, самая распространенная ошибка — часто при разработке стартапа или пет-проекта гипотеза о том, что она получится прибыльной, становится ошибочной.
Так, один наш знакомый мобильный разработчик решил сделать приложение для ледовых катков. В его городе было достаточно спортивных объектов, но забронировать их было сложно: приходилось каждый раз звонить в рабочее время катка и бронировать лед устно.
Приложение было готово уже через месяц, но при попытке его реализации разработчик столкнулся с жестокой реальностью — обслуживающий персонал катков часто состоял из одного администратора, который даже не располагал смартфоном. А все бронирование велось на листочке бумаги. Переучиваться и переоснащать, внедрять CRM владельцы не очень хотели, и в результате владелец приложения по-прежнему записывает посетителей по старинке, через звонки.
Выводы: прежде чем стартовать проект, нужно четко представлять аудиторию и ее особенности. Для этого нужны не только брифы, но и изучение возможностей клиента — нет смысла рекомендовать автоматизацию, если клиент не располагает желанием обучения и повышения квалификации сотрудников.
Все сразу
У ряда историй бывает несчастливый конец по другой причине — очень часто требования, предъявляемые клиентом, избыточны.
Например, доводится встречать сразу большой пул задач, который необходимо реализовать в сжатые сроки. И, на первый взгляд, в голову приходит фраза «Нет нереализуемых задач, есть слабые бюджеты». Однако в текущих реалиях, скорее всего, тендер будет выигран не с той оценкой, которая учтет все риски.
Выводы: прежде чем просчитывать требования, необходимо оценить их релевантность и рассмотреть альтернативу — например, предложить частичный запуск по этапам, другой способ реализации или сроки по возможности.
Несбыточные сроки
Идеальный подрядчик требует мало, делает все быстро, вежлив, рассудителен, обладает всеми возможными скиллами и...не существует. Если убрать знаменитую диаграмму про сроки, качество и деньги, то в сухом остатке будет тот факт, что делать быстро и дешево без потери качества — невозможно.
Чаще всего клиенты ставят сроки, исходя из бизнес-задач: это может быть дата важной презентации, выставки или срок защиты внутренних KPI. Отсюда вытекают следующие моменты: во-первых, важно понимать, зачем и когда нужен этот проект. Во-вторых, важно своевременно донести клиенту мысль о том, что любая не озвученная в первоначальной смете доработка пропорционально увеличит сроки проекта.
Экспертиза и реалии
На этапе пресейла очень важно подключать конкретных исполнителей — то есть, тех людей, которые будут затем реализовывать задачи. Так, иначе впоследствии может оказаться, что отрисованный для тендера дизайн Главной страницы не может быть реализован на стеке клиента, или оценка в принципе не совпадает с ожиданиями.
Так, например, особо важно привлекать технических специалистов на оценку сложных проектов. Устаревшее окружение проекта потребует не только другого уровня знаний, но и дополнительного времени на разбор задач, а также на его обновление, что должно быть заложено в оценку. Особенно аккуратным стоит быть в моменте интеграций или изменения верстки. Но и простое обновление Битрикс может также привести к поломке стороннего модуля или требованиям смены окружения. В идеале, хорошо иметь тестовый доступ для анализа среды.
Избежать второй ситуации поможет детализированная смета. Она должна содержать не только этапы и стоимость разработки каждого из них, но и список задач внутри, каждую из которых следует дополнительно обсудить с командой, а затем — с клиентом.
Без ТЗ результат…
О расхождении понимания можно также написать отдельный свод правил. Самое главное из них — нельзя не только приступать к работам без четкого ТЗ, но и давать точную оценку. Если есть не сформированные до конца требования — то оценка может быть только приблизительной и об этом крайне важно поставить в известность клиента.
Пример — при оценке сайта клиент не предоставлял доступов в личный кабинет пользователей, сформулировав требования к нему без указания интеграций. По факту оказалось, что в Личном кабинете есть интеграция не с самой распространенной CRM без технической документации. Как итог: проект был реализован, но потрачено больше усилий и времени, чем планировалось.
Отсутствие лица, принимающего решение
Чтобы мнение по поводу работы и приемки проекта было единогласным, желательно, чтобы основное решение и правки в идеале исходили от одного лица со стороны клиента. Речь не идет о мелких недочетах, но если в ходе смены руководителя проекта со стороны клиента глобально изменится и концепция, изначально принятая на этапе пресейла, последствия могут быть печальными.
Также плохо, когда даже мелкие правки приходят от различных лиц: в практике есть случаи, когда одна кнопка меняла цвет несколько раз 😥.
Чтобы минимизировать такие истории, следует на этапе тендера определить список таких лиц, а затем, в идеале, зафиксировать порядок приемки и выдачи правок конкретным списком лиц в договоре.
Затягивание согласований
Бюджет согласован, тайминг отрисован, исполнители на низком старте, и, казалось бы, что может пойти не так — однако, может. Иногда это случается по причине, указанной выше, а иногда — наоборот, когда лицо, принимающее решение, есть, но оно то в отпуске, то в командировке, а в оставшееся время загрузка не позволяет погрузиться полностью в проект. И вот уже написанное ТЗ лежит на подписи вторую неделю, а затем дизайн-макеты переживают шестую итерацию, а вот и весь проект плавно переползает с запуском на два месяца позже.
Избежать таких моментов полностью нельзя — как и принимать решения за клиента. Но можно прописать сдвиг сроков пропорционально срокам согласования в договоре, количество итераций правок, проговорить это с клиентом, а затем напомнить ему в ходе движения проекта, если ситуация того требует.
Мы хотим только что-нибудь одно
Бывает так, что у команды клиента есть часть своей разработки — или дизайн-команда. А уже реализацию остальной части проекта коллеги возлагают на вас. Казалось бы, это облегчает процесс — не нужно будет тратить время на согласования, будет готовый дизан в работу. Но вот приходит дизайн — и вы понимаете, что некоторые моменты не учтены, а кое-что, наоборот, появилось с момента последнего обсуждения. Кроме того, на макете есть элементы, которые нужно приобрести, например, изображения с водяными знаками из фотобанка.
Лучше всего подключаться ко всем процессам создания проекта сразу — вне зависимости от того, какую именно часть вы будете вести. Это позволит быть вовлеченным на всех стадиях проекта и внести коррективы сразу по необходимости.
Если же планируется взаимодействие с другой командой, кроме этапа знакомства, нужно будет четко прописать еще на этапе оценки следующие моменты:
- Кто устраняет ошибки после приемки проекта.
- Кто и как производит приемку.
- Какие критерии приемки.
- Кто производит ревью кода.
- Кто отвечает за серверную часть и в каком объеме.
- Какие стандарты поддерживает команда.
- С чьей стороны производится тестирование, в каком объеме.
- Если включены третьи лица, то кто они и каковы их роли на проекте.
- Где описаны требования к работам.
- Когда и как возможно совместное планирование, кто модерирует встречи.
- Когда производится релиз и какой длительности спринты приняты.
После фиксации этих требований сразу будет ясно, насколько тимлид команды будет загружен и сколько времени заложить на взаимодействие с командой.
Хочется дешевле
Есть и другая ситуация — клиент очень хочет сделать много работ, но денег у него столько, что в бюджет он не помещается. В таком случае, важно предложить рассрочку или поэтапную разработку — скажем, сначала запускаем только Каталог и Личный кабинет, а уже потом — блоги, новости и начинаем вести социальные сети.
Если же клиент хочет сэкономить на критически важных вещах — например, на разработке бэкенда по подключению оплат, то весьма вероятно, у него нет понимания, что именно может стоить столько. Нужно внимательно детализировать смету, четко описав все этапы и состав работ: например, зачем именно нужно столько часов тестировщика, какие именно работы он будет выполнять, сколько страниц будет создано в рамках создания дизайна, и сколько итераций правок заложено.
Важно понимать, что все ошибки, допущенные в начале проекта, никуда не денутся по его развитию — они будут только порождать новые. Поэтому основной этап разработки и старта проекта начинается еще до его работ, на этапе оценки. Внимательно относясь к истории по детализации и проработке, вы получите не только запущенный проект, но и уважение клиента.
Заключение
Разработка — сложный процесс, на этапах которого часто встречаются подводные камни. Особенно важно, еще до старта работ, правильно выстроить процессы и коммуникацию с заказчиком.
Мы делаем решения, которые позволяют нашим клиентам зарабатывать больше с меньшими усилиями, а для того, чтобы понять, как лучше сделать ваш проект, вы всегда можете обратиться к нам за бесплатной консультацией 🤝