четверг, 15 ноября 2012 г.

Баг репорт

Баги делают все разработчики, если кто-то скажет что это не так, то есть 2 варианта: либо его приложением не пользуются, либо не говорят об ошибках. Согласен, их количество зависит от многих факторов, но никто не поручится за полное их отсутствие, вообще никто в здравом уме.

Как мы работали с багами:
Когда то давно, когда клиентов было не так много и они были не так удалены, то любой (да, именно любой) пользователь, будь то оператор или торговый представитель могли позвонить в офис или на сотовый ответственному за проект и пожаловаться на нестабильность в работе программы. Отчёт был примерно следующим: "я делаю заказ и программа вылетает" или "у меня база неправильная".
Со временем, такой формат технической поддержки и фиксации ошибок не мог остаться неизменным ввиду растущего числа пользователей и мы решили помочь пользователям, ну и конечно же себе – мы сделали файл лога ошибки, возможность экспорта базы, на которой она повторяется. Таким образом, во время сбоя программы пользователь видел такое окно:

Необходимо было подключить коммуникатор или планшет к ПК, скопировать файл с карты памяти и передать разработчику с возможными дополнительными комментариями.
И знаете, это на порядок улучшило время реакции на исправление ошибок, нам не надо было разворачивать клиентскую систему и повторять последовательность действий приводящую к ошибке, вся основная информация уже содержалась в этом файле, иными словами мы сразу знали что и где сломалось.
Но вот беда, ошибки чаще происходят в полях, в руках у простых пользователей, которые коммуникатор к компьютеру никогда не подключали, а это значит, что им сложно объяснить, как найти и переслать файл ошибки (в тот момент это была самая долгая и сложная процедура).
С ноября 2012 года все проекты АСМТ Наполеон собираются с новой системой отчёта об ошибках, вот пример сбоя программы:

В данном случае пользователю не обязательно доставать из КПК файл, его можно сразу отправить разработчику, возможно вместе с базой, на которой воспроизводится ошибка.
Не надо участия IT специалистов компании или партнёра, не надо никому ничего рассказывать, надо нажать верхнюю или среднюю кнопку и возможно написать несколько слов, мы же (разработчики) знаем в течении минуты у кого, на какой версии произошла ошибка.
Представьте, пользователь обнаруживший в первой половине дня ошибку до вечера не приезжая в офис сможет обновить уже исправленную программу, без напряга других сотрудников компании, круто же!

четверг, 8 ноября 2012 г.

Матрицы (универсальный фильтр).

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

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

Простой и как оказалось, универсальный фильтр товарной номенклатуры пришелся по душе пользователям и в подавляющем большинстве случаев используется не совсем по назначению.
Итак, как ещё можно использовать этот инструмент:
  1. Фокусный товар (возможно даже под формат торговой точки) – набор товаров, обязательных к продаже. Можно создавать эти списки по месяцам, по форматам ТТ и т.д. Описание отдельной реализации побуждения заказать фокусный товар будет чуть позже.
  2. Отделение брака или некондиционного товара.
  3. Создание списка акционных товаров. В данном случае название матрицы это название акции, внутри – список товаров, который дополнительно можно красить цветом (возьми пять товаров из списка и получи один красный из этого же списка).
  4. Список бонусных товаров.
Возможно, не всё указал, поправьте если так.
Не берусь говорить, что эти варианты отлично выполняют поставленную задачу, основной минус в данном случае – пользователь должен САМ открыть этот список, однако, перечисленные задачи подразумевают, что пользователю это НАДО. Главное в том, что программа позволяет покрыть дополнительный функционал самостоятельно, без привлечения разработчика.
В этом месяце я приведу примеры специальной реализации описанных выше задач, когда программа начинает активно предлагать пользователю совершать ряд своевременных действий. 

вторник, 6 ноября 2012 г.

Стоимость проекта мобильной торговли.

Стоимость реализации проекта мобильной торговли это, пожалуй, самая неопределённая величина до момента запуска проекта. Причём происходить это может по разным причинам, виной тому могут быть прососы исполнителя или растущие аппетиты заказчика, например. Однако, если второй момент сложно просчитать, то первый – вполне можно. Ниже привожу возможные статьи затрат на запуск проекта мобильной торговли (если заказчик с исполнителем обсудят все необходимые из этого списка – велика вероятность того, что стоимость проекта будет определена верно):

1.     Стоимость мобильных устройств (скорее всего это коммуникаторы или планшеты) стоимость умножаем на количество мобильных сотрудников.
2.     Стоимость физического сервера системы (если необходим).
3.     Стоимость серверной OS и СУБД (MS SQL, например) – если необходимо.
4.     Стоимость мобильной части системы на всех необходимых пользователей (возможны скидки от объёма).
5.     Стоимость серверной части системы мобильной торговли (ПО) – если требуется.
6.     Стоимость АРМ Руководителя (необходимое количество).
7.     Стоимость SIM карт для мобильных устройств и стоимость тарифа.
8.     Стоимость выделенного IP-адреса (абонентская плата), если не входит в тарифный план.
9.     Стоимость дополнительной учётной записи пользователя КИС (например 1С) - некоторые системы могут их использовать.
10. Стоимость внедрения системы:
a. Стоимость предпроектного обследования и написания ТЗ (если необходимо и услуга платная).
b. Стоимость создания или доработки модуля обмена с КИС (актуально для всех КИС с нетиповой конфигурацией), может выполняться силами собственных специалистов.
c. Стоимость установки, настройки, обучения.
11. Время необходимое для внедрения системы, количество визитов специалистов исполнителя, время бездействия отдела.
12. Стоимость технической поддержки (возможно заключение договоров на тех. поддержку при старте проекта) и условия её получения в необходимом для вас объёме.

Итак, если для вас важно понимать стоимость запуска проекта – согласуйте с исполнителем все эти 12 пунктов, это должно отразить конечную стоимость проекта.
Замечу, выше приведены пункты отражающую стоимость запуска проекта мобильной торговли. Стоимость владения системой – немаловажный момент, о нём речь пойдёт в следующий раз.