вторник, 28 мая 2013 г.

Подождите … Осталось 3 ч. 59 мин…


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

Для нас этот вопрос особенно важен, потому что мы ориентированы на кастомизированные проекты. Причем мы не просто берем конструктор, собираем, меняем настройки – вуаля, новый проект. Наши проекты новые без дураков, у каждого куча собственных фишек и индивидуальных особенностей. Соответственно, обновляются они тоже по одному, и не регулярно, а по мере пользовательской необходимости, так что, например, для OS Android нас Google Play как механизм обновления не устроит.

Проще говоря, обновления чего-нибудь для кого-нибудь – это то, чем мы занимаемся постоянно, проектов-то много. Придем с утра в офис и давай обновлять…

Не подумайте, что мы жалуемся. Вовсе нет! Курс на кастомизацию мы взяли сознательно и точно знали, на что идем. А проблему обновлений мы решили. Как? Секрет, но вам скажем.

Давным-давно, во времена Palm OS, мы решали ее очень просто. Удаленного обновления тогда не существовало, и все делалось одним-единственным способом – через программу HotSync.

Когда мы выпустили версию 3.0, мы в числе прочего поменяли и способ обновления. Сделали  в программе «Наполеон – Администратор» закладку «Обновления». Сейчас мы таким способом только лицензии подгружаем (о чем, кстати, в прошлый раз писали), а тогда эта закладочка много для чего использовалась.


Так вот. Формировали пакет со всеми данными, которые в программе поменялись, передавали, а на месте они аккуратно раскладывались. Не подменой программы, а именно обновлением самого кода программы. Сам файл весил немного, килобайт сто. Тогда еще 3G практически не было и вообще не так-то просто было что-то передать, так что маленький размер был существенным плюсом.

Мы очень собой гордились – филигранное же дело! Но потом от этого варианта пришлось отказаться, потому что Windows Mobile начал стремительно устаревать, меняться, производители его все время дорабатывали, о чем не всегда сообщали. Это создавало кучу неудобств и пользователям, и нам, всячески нарушало стройность и красоту нашей системы.

Пришлось меняться. В середине 2011 года, с выходом версии нашей программы для OS Android, мы снова взяли другой подход к обновлению. Он оказался удачным, и мы до сих пор так делаем.

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

Кстати, мы никогда не делали и не сделаем принудительного обновления. Вас когда-нибудь раздражал девайс, который в середине вашего рабочего процесса вдруг начинает перезагружаться и тупить? Спорю, что да. Поэтому мы против того, чтобы мешать пользователю, когда он работает. Будет свободен – нажмет кнопку и запустит процесс.

Выглядит так: идем в раздел меню «О программе»…
…и нажимаем кнопку «Проверить обновления».
Если обновления есть, программа ими займется, а по окончании процесса отчитается.
Если обновлений нет, она вам об этом скажет.

Плюсы этого подхода:

- не надо иметь в виду какие-то отдельные устройства с их особенностями, загрузить файл сможет любой «Андроид»;
- файл обычно в пределах полумегабайта, в самых исключительных случаях (при очень больших обновлениях) – до мегабайта. Редко, но бывает. Но редко. Словом, при современном уровне связи вполне симпатичный размер файла;
- он отлично дополняет наш сервис баг-репорта (о котором мы писали тут). Случается ошибка (ой, не говорите про мифические программы, с которыми ошибок не случается никогда), программа отправляет нам сообщение, мы его получаем, чиним, что надо, отправляем им – и все это без участия ИТ-представителей и вообще без лишних переписок и растолковываний.

Да, не самый утонченный вариант и не самый изящный. Но утонченный у нас уже был. А сейчас мы пришли к выводу, что обновления – это не та задача, где стоит гоняться за красивыми решениями.

Гоняться надо за надежностью.

среда, 22 мая 2013 г.

Лицензирование без бюрократии


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

Все, кто занимаются разработкой и продажей мобильных приложений, вопросы лицензирования для себя как-то решили. Кто опытом поделится в комментариях, скажем спасибо. А пока расскажем про себя. Про «Гильдию разработчиков» то есть и про программный комплекс для автоматизации мобильной торговли АСМТ «Наполеон».

Когда-то давно, когда мы еще делали приложения для Palm, а потом для Windows Mobile,  мы делали регистрацию каждого мобильного устройства с помощью кода. Самый простой и очевидный способ регистрации. На аппарате пользователя генерится код запроса – мы на него даем код ответа – программа залицензирована, можно работать.

Плюсы такого способа:
- дешево;
- оперативно – нам звонят, мы диктуем пользователю код, он его набирает – вуаля, все готово;
- просто – не надо дергать админов и вообще не надо быть продвинутым пользователем. Каждый работник может это сам.

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

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

В 2010 году мы провели реорганизацию нашего программного комплекса и крупное его обновление. В том числе в комплекс вошло приложение под названием «Администратор». В нем-то мы и сделали окошечки и кнопочки, нужные для лицензирования. Теперь лицензии – это отдельный файл, который формируется для сервера каждого конкретного заказчика и подгружается к серверу в программе «Наполеон – Администратор».

Лицензии загружаются здесь:

…и назначаются пользователям здесь:

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

Админ может сделать это сам или может попросить нас о помощи – мы подключимся к серверу удаленно и загрузим лицензии.

С известной долей гордости хочется подчеркнуть, что мы это сделали в 2010 году! Некоторые к подобным системам лицензирования приходят только сейчас и считают их новаторскими. А мы уже! И скоро еще что-нибудь придумаем.

Плюсы тут такие:
- весь процесс происходит без участия конечных пользователей. Кучно, быстро, просто. И легко контролировать распределение лицензий.
- при смене аппаратов не надо возиться с переделкой лицензий – они теперь к аппаратам никак не привязаны, только к логину пользователя.
- высокий уровень защиты – у каждой компании свой уникальный сервер, для него формируется уникальный файл лицензий. Подделать сложно.
- надежность. Мы не бьем себя в грудь, что косяки лицензирования невозможны, но за три года их у нас ни разу не случилось.

Вот. Удобно, здорово, красиво, легко.

Что непонятно - спрашивайте, что не нравится - критикуйте.






понедельник, 20 мая 2013 г.

Путь мобилизации компании "Р" (кейс)

Производственно-сбытовая компания "Р" является лидером отрасли в своём регионе, в структуре компании несколько обособленных филиалов, есть единая управляющая компания, есть производственные площадки и отдел розничных продаж, представленный четырьмя командами торговых представителей, находящихся в разных субъектах РФ.
 Мысли об автоматизации мобильных сотрудников периодически возникали у руководства, но на тот момент, не имея опыта в подобных вопросах, было сложно сформулировать все требования к проекту мобильной торговли.

В результате было принято решение о пилотном проекте. Продукт – один из лидеров рынка на момент 2007 года в РФ, внедрять должен был один из лучших партнёров разработчика, по мнению участников проекта успех был гарантирован. В качестве пилотной площадки был выбран удалённый филиал в Барнауле. В непродолжительный срок была проведена работа по настройке обмена системы мобильной торговли с 1С заказчика, обучены пользователи. Предполагалось, что после получения обратной связи от торговых представителей будет проведена финальная настройка (а возможности настройки были серьёзные) системы, и удачный опыт будет масштабирован на всю компанию. По опыту, такая стратегия часто работает.

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

Получив опыт и "набив шишки", руководство компании решило обратить внимание на продукт мобильной торговли, который можно самостоятельно дорабатывать. Это был 2009 год, в то время ярко выделялось решение от компании 1С, а именно 1С-расширение для КПК. В отличии от других решений, оно позволяло серьёзно менять не только внешний вид, но и функциональность приложения. Учитывая, что штат IT-отдела составлял несколько десятков специалистов – доработка приложения в знакомой среде 1С не составляла проблемы. На данном этапе был приобретён пакет лицензий на одну команду и началась работа по модификации приложения, суть – выполнение желаний коммерческого отдела.

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

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

В результате выбор был остановлен на мобильной торговле Наполеон (в том числе и по причине гораздо меньшего бюджета проекта относительно других конкурсантов), пилотный проект предполагал создание приложения под все текущие требования заказчика без потери качества самого приложения. Срок реализации данного проекта (вернее, приложений, там был и van-selling) составил неприлично долгие для нас 4 месяца. Функционал приложения увеличился в несколько раз относительно базовой версии, было реализовано множество новых функций, было несколько приближений и корректировок реализации. В результате весной 2012 года первые пользователи начали работу в системе Наполеон.

На данный момент идёт третья волна доработок под новые, уникальные запросы пользователей, ни одна просьба не была отклонена и не была названа невыполнимой, бюджет всех доработок (а они действительно большие) не превысил годовую минимальную зарплату начинающего программиста.
На данный момент были реализованы следующие основные функции:
- повторено уникальное ценообразование;
- учёт товара в разных единицах измерения и веса;
- работа с заказами и возвратами, оформленными без участия торгового представителя (возможна корректировка + точный off take);
- оформление возвратов товара на основе накладных отгрузок с указанием причин и качественного состояния продукции;
- редактирование веса при продаже товара;
- сценарий работы с редактором в РМР;
- анкетирование клиентов с редактором анкет;
- заказ отчётов в 1С;
Мы даже возродили текстовый редактор печатных форм образца 2006 года для принтеров Epson LX 300, которые остались с прошлых проектов.

За весь 2012 год были автоматизированы все филиалы и практически все мобильные сотрудники компании. На текущий момент система полностью устраивает пользователей и IT-специалистов компании.


Какие выводы можно сделать из данной ситуации:
1. Перед стартом проекта необходимо чёткое понимание того, что хочется получить в итоге.
2. Далеко не всегда лидер рынка способен оправдать все ожидания клиента.
3. Самостоятельная разработка не всегда может привести к ожидаемому результату, в случае с применением конфигурируемых решений сюда добавляется ещё и ограничение самой платформы разработки (производительность / стабильность).
4. На примере крупной компании с частыми запросами на изменение функционала экономически нецелесообразно держать специалиста в штате, лучше отдавать эту задачу на аутсорсинг или разработчику (при его желании, естественно). Иными словами, серьёзного специалиста способного "тянуть" этот проект прокормить будет дороже, в случае с ротацией кадров есть риск как минимум провала по срокам.
5. Бюджет проекта не всегда пропорционален его качеству.
6. Техническое задание и оговоренные детали "на берегу" с пост-оплатной системой расчётов повышают шансы на удачную реализацию проекта.


Готов обсудить задачу или пояснить выводы.

среда, 8 мая 2013 г.

Решаем кейсы

Здравствуйте дорогие читатели, в начале года я анонсировал рубрику, связанную с решением практических ситуаций в сфере рынка мобильной торговли, рубрику назвал "кейс", по аналогии с Case method (метод изучения конкретных ситуаций и поисков их решения). Данные публикации не несут в себе цели опорочить какого-либо разработчика мобильной торговли или запятнать чьё то имя, рассказываю как есть то, с чем может столкнуться каждая компания выбирающая или уже использующая мобильную торговлю. 

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