Web-студия «Ананас»: что нужно знать перед тем, как принимать готовое приложение у разработчика
Добрый день, уважаемые читатели VC.RU! Совладелец web-студии «Ананас» из Екатеринбурга Евгений Гавриляк продолжает делиться с вами советами о том, на какие моменты нужно обращать внимание при заказе приложения. Ранее речь шла о процессе постановки ТЗ разработчику и зачем нужно устраивать интервью с ним перед началом проекта. Теперь пришло время рассказать об особенностях сдачи- приема проекта.
Итак, разработчик web-приложения сообщает, что проект готов. Пришло время принимать работу. Это последний этап цикла разработки по времени, но не по важности. Здесь невнимательный заказчик может совершить ошибку и в результате получить продукт, работающий плохо (или вообще не работающий). Если он предназначен для использования внутри компании, как, например, CRM-система, то не окупит вложенные инвестиции. Если же не функционирует приложение для стороннего пользователя, оно еще и нанесет урон репутации компании, как только окажется в публичном доступе.
Web или мобильное приложение относится к технически сложным продуктам, поэтому процесс сдачи-приемки обычно занимает от недели до месяца, но может быть и более длительным. Если завод покупает оборудование для новой производственной линии, он не просто оплачивает его, получает и подписывает акт. Перед этим обязательно идет этап пуско-наладочных работ, которые выполняются при участии фирмы – производителя оборудования. Даже если оно выполнено по индивидуальным чертежам заказчика. Примерно то же происходит и с приложением.
По завершении проекта разработчик обязательно проводит внутреннюю проверку работоспособности приложения, затем выкладывает его на тестовый сервер и предоставляет заказчику доступ. Задача последнего – выделить время на внимательное ознакомление с приложением и проверку его соответствия техническому заданию. Это нужно сделать даже если в процессе разработки подрядчик сдавал промежуточные отчеты и демонстрировал ранние версии программы.
Проверяются и изучаются обычно следующие параметры:
· Визуальный стиль и все элементы UI/UX– интерфейса.
· Функционал, причем проверка идет отдельно для каждого пользовательского сценария (гость, зарегистрированный пользователь, администратор).
· Если приложение кроссплатформенное (написанное под разные операционные системы), оно должно одинаково стабильно работать на всех платформах по ТЗ. Если оно написано для нескольких браузеров – то на всех браузерах.
· Производительность – согласно заявленной в ТЗ.
Заказчик проверяет все это самостоятельно, однако демонстрацию в онлайн или офлайн-режиме может провести и разработчик. Клиент имеет право попросить об этом, и профессиональная компания ему не откажет. При сдаче сложного продукта (например, CRM) разработчик даже может приехать к заказчику и устроить демонстрацию с обучением для всего персонала.
Здесь следует обратить внимание на важный момент. Если во время демонстрации разработчик не показывает какую-то часть функционала, или запускает кроссплатформенно приложение только на одной платформе уверяя, что «все остальное и так работает» - он не пытается таким образом сэкономить время клиента. В 90% случаев подобное означает, что функционал просто не доделан, а подрядчику нужно любой ценой закрыть акт. Исключение возможно, когда сложный продукт принимает ТОП-менеджер компании, который непосредственно работать с ним не будет. В таком случае его не обязательно погружать во все тонкости. При этом разработчик должен быть готов продемонстрировать по первому требованию любой опущенный в презентации момент.
Если приложение предназначено для клиентов заказчика, особенно b2c, последний может задействовать тестовые группы из конечных пользователей. У некоторых наших клиентов широко применяется подобная практика. Участники тестовых групп (они подбираются по разным социальным характеристикам – полу, возрасту, роду занятий и т.п.) получают доступ к приложению, взаимодействуют с ним, оценивают его работу. Случается, что мы делаем несколько вариантов, к примеру, первых двух-трех страниц приложения, и тестовые группы выбирают наилучший с точки зрения функций и дизайна. Так сразу становится видно, какие есть шероховатости, что можно поправить: например, мы не посчитали значимым для пользователя какой-то элемент интерфейса и не стали его прорабатывать, а в ходе тестирования выясняется, что как раз это было необходимо сделать.
А если будут баги?
Когда мы покупаем какую-то вещь в магазине, то естественно ждем, что она будет функционировать без малейших нареканий. Те же ожидания могут быть и у заказчика web-приложения, особенно если он впервые становится клиентом разработчика. Однако нужно иметь в виду, что даже после всех тестирований и сдачи проекта баги могут возникать – это нормально. Главное, чтобы они не были слишком серьезными.
Это как при выпуске на рынок компьютерной игры – вроде все было проверено несколько раз, тестировщики проделали большую работу, игра отлично идет на «железе» разработчика. А спустя некоторое время покупатели начинают жаловаться на баги, приходится делать так называемый «Патч первого дня». Это больше характерно для программ, которые пишутся под разные платформы. Так, разработчик игры не может учесть вообще все конфигурации ПК, на которых пользователь запускает игру – отсюда и баги.
Время простых программ прошло – приложения становятся все более многозадачными, это сотни различных процессов и все особенности их взаимодействия, работы на том или ином браузере, смартфоне, компьютере и даже мониторе (!) трудно предсказать заранее. Для этого у разработчика приложений всегда предусмотрен гарантийный период. В рамах гарантии он осуществляет любые необходимые доработки бесплатно.
Выводы:
1. Прием приложения у разработчика – это задача не на один день. Процесс может занять несколько недель.
2. Главное – тщательное тестирование и обучение работе с приложением до подписания акта. Если продукт для массового пользователя, не лишним будет организовать тестирование с помощью представителей всех сегментов целевой аудитории приложения.
3. При демонстрации приложения разработчик должен быть способен ответить на любой уточняющий вопрос и показать/объяснить работу любой функции или опции, на которую укажет клиент. Если разработчик избегает этого – акт подписывать нельзя.
4. Некоторые баги возможны даже после приемки и запуска приложения в работу. Возможно, что-то было упущено обеими сторонами договора при тестировании, либо разработчик не учел какой-то незначительный (на его взгляд) момент. Этот вопрос решается наличием гарантии у профессионального разработчика.