Частые ошибки при заказе приложения или сайта

Денис Гордиенко, руководитель Bright Mobile, об ошибках заказчиков при запуске своего первого сайта или приложения.

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

В течение года я собирал обратную связь, общался с коллегами и клиентами и свёл ряд пунктов, которые встречаются чаще всего.

Когда заказчик делает уже не первое приложение, он уже говорит с разработчиком на одном языке и понимает, на какие моменты нужно обратить внимание.

Процесс создания можно разбить на этапы. Каждому этапу свойственны свои ошибки.

1. Проектирование

Многие называют этот этап составлением технического задания. Происходит сбор требований и ожиданий заказчика. На выходе получаем примерно такой документ с описанием.

На этапе проектирования самая частая ошибка — желание запустить все и сразу. Описать в проектировании все фишки, весь функционал и начать разработку по нему.

Этот подход ошибочен, потому что в таком случае, продукт создается не в соответствии с потребностью рынка, а из субъективного мнения заказчика.

Я каждый раз рекомендую, разрабатывать приложение версионно. Заложить в первую версию 15 ‑ 20 экранов, выпустить, собрать обратную связь от пользователей. И уже на основе полученной информации, думать о том, что делать во второй версии.

Не все идеи принесут миллионы. Версионная разработка, в случае неудачи, может помочь уберечь ваши деньги: чем раньше будет ясно, что продукт не будет востребован в текущем виде, тем лучше. Это не значит что нужно всё бросить, это значит, что останется больше денег для корректирования проекта под реалии.

2 этап — Прототипы

Прототипы — это схематическое изображение экранов приложения.

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

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

3 этап — Дизайн

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

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

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

4 этап — Верстка

Верстка — это перевод картинок дизайна в программный код экранов или страниц, которые ещё не связаны друг с другом единой логикой работы.

Многие студии этот этап даже не согласовывают. Мы всё же отправляем заказчику материалы, скорее для промежуточной отчётности, что работа идёт. Здесь всё просто — нужно сравнить картинки дизайна со ссылками вёрстки, они должны выглядеть идентично. Ошибки могут быть только из-за внимательности.

5 этап — Серверная часть

В вебе используется CMS. В приложении продумывается архитектура базы данных и сервера.

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

Если все-таки решили проконтролировать этот момент, стоит посмотреть ТЗ для разработчика на соответствие с проектированием. Например, экран авторизации. Если в ТЗ указана авторизация по номеру телефона, то в документации для программиста должна быть описана реализация функции отправки смс на телефон, приёма ответа, отправки повторного кода и т.д.

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

6 этап — Реализация мобильного приложения, сайта.

На выходе после этого этапа имеем готовое мобильное приложение или сайт, которые можно посмотреть на тестовом контенте.

На этапе реализации приложения всегда появляются доработки. Это нормально, в ходе работы над проектом рождаются новые идеи. В лучшем случае проект запускается за 1‑2 месяца при скоростной разработке. В обычном режиме — 3‑4 мес. Всё это время основатель живёт идеей и придумывает что-то новое.

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

7 этап — Создание панели администратора

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

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

Мы чаще всего этот этап делаем после серверной части. С одной стороны клиент уже может заносить тестовые данные, с другой — может через панель администратора проверить работоспособность сервера хоть в каком-то объёме.

8 этап — Тестирование и отладка

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

Со стороны заказчика ошибочным будет принять приложение без предварительной самостоятельной проверки.

Заказчик может посмотреть пару экранов, сказать, что все его устраивает. А через пару месяцев прийти и сказать, что студия что-то не учла, когда разрабатывала приложение.

В таком случае могут возникнуть спорные моменты о том, как оплачивать возникшие доработки.

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

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

Заключение

Заключение будет коротким и достаточно очевидным. Чтобы не наломать дров важно быть внимательным и не лениться проверять каждый этап. Если возникли какие-то сомнения всегда лучше переспросить, чтобы потом не было мучительно больно.

Надеюсь эта заметка позволит недопустить факапа во многих проектах.

0
3 комментария
Егор Рабцевич

Главное это то, что все написанное автором ,нельзя получить в Bright mobile) как говориться на словах он Лев Толстой, а на деле х... простой.

Ответить
Развернуть ветку
Лев Щенин

Отличная статья!

Давно искал разработчиков ЦРМ для моего проекта "Ресторан бесплатной еды".
А тут - готовое "Техническое задание" с маркетплейсом поваров-надомников!
Беру!
Заверните в подарочную упаковку!
(напишу вечером разработчику в личку)

Ответить
Развернуть ветку
Виталий Подольский

Лучше внимательно прочитайте все комментарии:

https://vc.ru/94868?comment=1542820

Ответить
Развернуть ветку
0 комментариев
Раскрывать всегда