Как с нами работать

Уважаемый (потенциальный?) пользователь системы "Курьерская служба 2008"!

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

Руководитель MeaSoft
Евгений Милевский

О системе

Немного цифр: по состоянию на момент написания статьи (март 2017) наша система существует и развивается 14 лет. Над ней ежедневно трудятся 7 программистов. Ежедневно решается около 30-ти тикетов. Система установлена более чем в 300 компаниях. В географию установок входят Россия, Казахстан, Украина, Белоруссия, Киргизия, Латвия. С помощью системы, ежедневно 4,5 тысячи курьеров доставляют 60 тысяч отправлений от 11 тысяч клиентов. База данных состоит из 207 связанных друг с другом таблиц, в некоторых из которых встречается по 50 млн записей.

Как получить качественную поддержку

Корректно обратиться в поддержку

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

• Обратиться "по адресу" Обратиться в поддержку можно по будням (в соответствии с трудовым календарем Российской Федерации) с 8:00 до 21:00 по московскому времени любым удобным для Вас способом: Почта support@courierexe.ru, Телефон +7 (495) 987-17-12 или skype: courierexe, courierexe1, courierexe2.

• Представиться При обращении любым из способов Вам понадобится представиться: назвать ФИО и компанию, в которой Вы работаете. Возможно, продиктовать телефон и адрес электронной почты для обратной связи. В случае отсутствия данной информации (особенно по почте) специалисты технической поддержки, прежде чем начать решать проблему, сначала будут выяснять эту информацию, на что уходит драгоценное время. Мы не принимаем анонимки ни в каком виде! Особенно частая ошибка - когда пользователи пишут с общей почты организации, вида "info@courier.ru" и в подписи, вместо контакта человека написано что-то вроде "С уважением, команда курьерской службы".

• Предоставить полную информацию Очень важно предоставить исчерпывающую информацию о своем вопросе. Номер заказа, с которым возникла проблема, или название клиента, если проблема с клиентом. Обратите внимание: если проблема касается сразу группы заказов - это хорошо, что Вы например, заметили "Во всех позавчерашних заказах происходит ...", и это даже может нам помочь, но номер конкретного заказа, хотя бы одного из той группы, нужно назвать. Сотрудник службы технической поддержки должен будет посмотреть на этот заказ, и увидеть, что именно Вам не нравится - не надо заставлять его рыться в вашей программе в поисках заказов, подходящих под какие-то условия, в противном случае он найдет первый попавшийся заказ, не увидит в нем проблемы и закроет тикет, и будет абсолютно прав. Если вопрос по отчету - укажите точную последовательность действий для его получения, какие пункты меню выбирали, какие данные вводили, приложите сам отчет. Если загружаете файлы - обязательно приложите исходные файлы и опишите, как загружаете. Обратите внимание на разницу терминологии, например: У нас есть понятие "Заказ" (вкладка заказы). В разных компаниях его называют "Заявка", "Загрузка", "Реестр", "Подключение", "База", "Рассылка" - список можно продолжать бесконечно. Очевидно, что на вопрос "В подключении дата стоит не такая" последует вопрос о том, что же такое, в вашем представлении "подключение", и эту потерю времени можно предотвратить указав понятные нашим сотрудникам термины, а еще лучше - приложить скрин-шот, на котором было бы сразу видно, и какую именно Вы имеете в виду дату.

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

С одной стороны, приведенные здесь рекомендации, казалось бы, очевидны каждому. Однако, факт: до 50% рабочего времени сотрудников поддержки уходит на "вытягивание клешнями" указанных сведений. А самое обидное, когда из-за того, что человек, почему-то, элементарно не сообщил кто он, откуда, номер заказа, на который жалуется - решение его вопроса откладывается на длинную переписку с выяснениями. Хочу так же обратить внимание на то, что подобные задачи, требующие длительной переписки для выяснения, получают низший приоритет, как наименее продуктивные.

Контроль качества

Если Вы не удовлетворены качеством решения Вашего вопроса, есть несколько способов повлиять на ситуацию:

• Проголосовать по телефону После окончания телефонного разговора с нашими специалистами, система предлагает поставить им оценку.
• Проголосовать из письма (разрабатывается) В письме об изменении тикета по Вашему обращению Вам предлагают выбрать оценку.
• Обратиться к директору По почте admin@courierexe.ru или, в экстренных ситуациях, даже телефону: +7 (916) 114-79-92. При обращении нужно представиться, назвать номер тикета и/или максимально точное время телефонного общения с нашими сотрудниками - я лично подниму историю вопроса, записи телефонных разговоров, дам оценку ситуации и обязательно приму меры! Надо понимать, что голословные, не проверяемые, претензии вроде "я звонил когда-то, не помню когда, и мне плохо ответили" я принять не могу.

Почему вы не сообщаете об изменениях?

Текущие изменения функциональности и логики работы

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

Добавление новых функций

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

Как осуществить доработку

Почему мы задаем вопросы

Как я уже писал, в день, в среднем, мы обрабатываем 30 обращений. Из них 2-3 шт звучат примерно как "А добавьте в карточку курьера галку "Выдан фирменный портфель"" (№1) или "А сделайте, чтобы на каждый район на карте можно было назначить отдельного курьера на каждый день недели" (№2). "А добавьте в отчет "количество доставок по клиентам"" поле "Среднее отношение количества выездов курьера к километражу между точками, умноженному на средний счет клиента" (№3). Посчитаем: за 200 (примерно) рабочих дней в году мы бы за год добавили бы минимум 500 таких галок, кнопок и полей, а за 10 лет - 5000. На самом деле - добавили бы гораздо больше, т.к. они тянут друг друга: По №1 я задаю вопрос клиенту: А завтра Вы, наверное, попросите добавить галку "Выдан планшет", а потом "Выдан проездной", плащ-палатка, футболка и солнечные очки. Они говорят "Ну, видимо, да...". Представляете, насколько система была бы не управляема сейчас? На практике, конечно, мы находим решение задач, главное - понимать, что именно он хочет. В первой - клиенту нужно учитывать выдачу сотрудникам и прием неограниченного количества видов инвентаря. И так в модуле складского учета, в номенклатуре, появилась галка "инвентарь", и клиент, помимо того, что просил, получил еще средство контроля за остатками своих фирменных портфелей на складе. По второму пункту - понятно же, что в 95% случаев на одном районе курьер будет работать каждый день недели, а то, что в выходные у них работает другой курьерский состав на тех же районах - это исключение. С гораздо большей вероятностью, вместо разных курьеров по дням недели, нашим клиентам понадобятся разные курьеры в зависимости от массы отправления (пешие/вело/авто курьеры), или срочности. Если бы мы добавляли возможность указания разных курьеров для всех этих вариаций (а сколько их еще можно придумать!), схемами на карте стало бы невозможно пользоваться. Понимая задачу, которую решает клиент, мы делаем возможность копирования схем. И клиент может нарисовать районы, скопировать схему, и 2 схемы назвать "будни" и "выходные", и назначить разных курьеров. А можно - сделать 7 схем по дням недели. А можно - отдельно для пеших, и отдельно - для автокурьеров. По третьему эпизоду совсем все просто: Делается отдельный отчет в "доп. возможности", в котором выводятся те показатели, которые нужны клиенту, считающиеся по его ТЗ. Вот, кстати, про отчеты частая проблема недопонимания, на которую уходит много времени и нервов: Обращается клиент с просьбой добавить ему в раздел "Адреса" какое-то поле, например, количество поездок по отправлению в выдаче. На самом деле, добавление такого поля практически исключено по чисто технической причине: для вывода отправлений серверу придется для каждого из них "заглядывать" в "выдачу", и считать их количество. Для 99.999% задач, решаемых пользователями в адресах, эти данные не нужны, но их расчет будет происходить, и замедлять работу всех систем всех наших клиентов. Но возникает и другой вопрос: "зачем вам это поле?". А клиент говорит "Мы будем выводить это поле, выгружать все 10 тыс. заказов с ним в эксель, там формулами считать наценку за лишние поездки, а потом загружать обратно этот эксель с рассчитанными ценами. Сейчас у нас круглосуточно работают 3 человека, которые в каждое отправление заходят, открывают закладку "История выдачи", смотрят, сколько там строк, и вписывают в эксель." Занавес! :-) Чтобы Вы понимали - я не сильно утрирую, когда это пишу: люди действительно совершают ненужные подвиги каждый день. Здесь, если подходить формально, можно просто сказать "Нет, мы этот столбец не добавим". Если немного подумать - можно сделать отдельный отчет, который выведет в эксель требуемый клиентом показатель. Но если подойти к задаче действительно качественно, то в тариф клиента можно добавить услугу повторной доставки, которая сразу будет рассчитываться по тому алгоритму, который нужен клиенту, и процесс расчетов в экселе выпадет полностью, значительно упростив всем жизнь. Чем мы и занимаемся. Главный принцип хорошего программиста гласит "Клиенту надо дать не то, что он просит, а то, что ему действительно нужно". Тут Вы, наверное, думаете, что пишут Вам тут про каких-то дураков, а Вы-то действительно знаете, как правильно решать Вашу проблему, и не нужно больше ничего выяснять, надо делать то, что Вы говорите. Но на самом деле, люди придумывают такие не конструктивные подходы не потому, что они глупые, а по тому, что они не профессионалы в данной области, они не знают всех технических возможностей и невозможностей. Поэтому есть мы - мы подходим к решению каждой бизнес-задачи системно, прилагая все усилия, чтобы понять корень проблемы, и тогда предлагаем такое решение, которое максимально автоматизирует Ваши процессы, и при этом будет соответствовать базовым принципам построения информационных систем, будет учитывать возможное развитие предложенных процессов.

Надеюсь, что данная статья поможет нам с Вами лучше друг друга понимать, и работать максимально слаженно на общее благо.

Почему доработки стоят денег

Иногда наши клиенты говорят "Я же придумываю вам функциональность, которую вы включите в свою систему и она станет лучше, вы это будете продавать, почему я должен платить за разработку?" На это у нас есть ряд ответов:

• Мы практически не зарабатываем на продажах. На самом деле, мы и на доработках не зарабатываем. Продажи и доработки вместе составляют менее 15% нашего оборота (см. "бизнес-модель"). А увеличение стоимости системы за счет какой-то отдельно взятой доработки и вовсе лежит в пределах погрешности любого измерения.
• Вся та функциональность, которая сейчас есть в системе, и которую Вы приобретаете за смешные, для подобных систем, деньги, так же была до Вас кем-то придумана и оплачена, что позволяет Вам сразу пользоваться всеми этими идеями.
• Мы, естественно, не все доработки делаем платно. При принятии решения о стоимости и сроках выполнения доработки мы опираемся на множество факторов, таких, как востребованность (возможно, потенциальная) другими нашими клиентами, трудозатратность, реальная необходимость доработки именно для Вашего процесса, обслуживаемость данной функциональности в будущем. И на практике, большинство доработок мы делаем по себестоимости. Некоторые - бесплатно, некоторые, если доработка нужна только вам, и больше о ней никто не спрашивал и подобных процессов больше ни у кого нет - то по рыночной цене. Бывают и такие доработки, за которые мы выставляем завышенный ценник, если видим, что подобная доработка может негативно сказаться на стабильности, скорости работы системы, ее масштабируемости. В этом случае ценой можно показать клиенту, что другое решение правильнее, дешевле, а клиент может, так же деньгами, сказать что ему это действительно нужно, что ему это выгодно, и он действительно будет этим пользоваться.
• Если бы мы принимали все идеи к разработке бесплатно, то каждый наш пользователь генерировал бы идеи каждый день, не заботясь о качестве этих идей, об их реальной востребованности в его процессе. Подходил бы с позиции "ну вы сделайте, вдруг пригодится". При этом наш ресурс разработки, как и любой другой ресурс в этом мире, ограничен. Поэтому задачи в работу принимаются либо платно, либо, если их выгода очевидна - бесплатно или дешево, либо, в рамках поддержки, но там тоже есть лимит трудозатрат, включенных в стоимость поддержки, поэтому клиенту приходится подходить ответственно к генерации идей.

Наиболее "больная" тема платных разработок в последнее время - интеграции. Себестоимость разработки интеграции с партнером начинается от 100 т.р., и это объективная реальность. Почему? Дело в том, что в большинстве случаев, одна только техническая документация под API какой-либо компании - это 50-ти страничный документ, описывающий методы, поля, структуры данных и подходы к организации обмена информацией, как правило, чуждые нашей системе (и любой другой, кроме той, от которой приводится документация). Данные нужно адапировать. Статусы нужно транслировать. Далеко не всегда понятно, откуда именно брать требуемые данные, и куда складывать ответные, т.к. объектов, придуманных партнерами в нашей системе просто нет. В большинстве случаев на это еще накладывается "сырость" программного кода на чужой стороне - он работает не так, как описано в документации, и программисты на той стороне на ходу что-то дописывают и исправляют. В лучшем случае исправляют, а в худшем - они просто не идут на контакт. А в случае ошибки в передаче данных приходится поднимать всю историю, трассировать работу ПО, сравнивать данные и т.д. - это большая и кропотливая работа. Самое печальное, что через месяц-другой успешной работы, вдруг что-то ломается. Мы получаем негатив - клиент звонит с претензиями, что не может работать и т.д., мы сутки выясняем, в чем проблема, и оказывается, что партнер просто молча изменил свое API. Поэтому - да, мы делаем интеграции себе в убыток с такими популярными партнерами как СДЭК или Боксберри. Но если Вам нужно интегрироваться с каким-то мало известным партнером, клиентом или сервисом - это стоит денег, причем скорее всего не только разработка интеграции, но и ее поддержка, т.к. сюрпризы подстерегают нас на всем протяжении совместной работы. Наиболее простые интеграции - с провайдерами SMS. Как правило, их API достаточно простое, и программист может его настроить за 1 рабочий день. Однако, это 5 т.р.+ обновление системы, которое тоже бывает платным. В большинстве случаев это не выгодно делать, если какой-то провайдер Вам позвонил, и предложил цену сообщения на 3-5 копеек меньше, чем Вы платите сейчас.