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

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

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

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

О системе

На сегодняшний день система «Курьерская служба» отметила своё четырнадцатилетние. За это время её положительно оценили и активно с нами сотрудничают более 300 компаний. Наши партнёры находятся в самых разных странах мира, таки как Россия, Казахстан, Украина, Белоруссия, Киргизия, Латвия. С помощью нашего сервиса ежедневно 4,5 тысячи курьеров доставляют 60 тысяч отправлений от 11 тысяч клиентов. Сама созданная нами «Курьерская служба» состоит из 207 связанных друг с другом таблиц, в некоторых из которых встречается по 50 миллионов записей. Над её совершенствованием трудиться целый штат высококлассных специалистов. « – Для чего они нужны?» – спросите Вы. Мир не стоит на месте, он меняется, и мы не отстаём от времени. Если завтра кто-то решит избежать пробок и доставлять корреспонденцию дронами – мы сможем адаптировать систему под его нужды. Если через десять лет откроют телепортацию и будут доставлять заказы с её помощью – мы сможем подстроиться и под этот метод доставки. Наша команда работает, что бы Вам было удобно!

Бизнес-модель

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

Я делю рынок курьерских компаний на 3 части:

Мелкие компании - стартапы и прочее, со штатом до 10 курьеров. Такие компании не очень интересно автоматизировать - выигрыш производительности труда от ведения базы данных, штрих-кодирования, расчета зарплаты и т.д. - минимальный, если вообще есть. Такие компании неплохо (если такое слово вообще применимо к подобным компаниям) себя чувствуют и в экселе, а учет отправлений сводится к фразе "ну я тебе давал отправление, ты его доставил?". Понятно, что для вменяемой автоматизации у такой компании нет ни денег ни потребности. Мы на такие компании никогда не нацеливались, и в свое время у нас получался неплохой симбиоз с системами вроде "Аурамы", которая позволяла подобной компании начать работать "в один клик" за 3 копейки. Это позволяло компании слегка подрасти, и при приближении к 10 сотрудникам их система переставала справляться, они переходили в следующую категорию и приходили к нам. "Конкуренты" "выращивали" нам клиентов! В последнее время ситуация изменилась: подобные системы стали дороже нашей, и клиенты из данной категории стали к нам приходить сразу. Надо, может, приподнять цены уже наконец? Подумаю.
Средние компании - со штатом курьеров от 10 до 200 курьеров. Это наша ниша рынка. Самая распространенная, созревшая к автоматизации. Здесь можно добиться действительно большого роста эффективности труда. В тоже время, как правило, компаниям из этой категории хватает функциональности нашей системы "из коробки", процесс внедрения прост и надежен. Хотелки по доработкам если и возникают, то уже в процессе работы, а не на старте, что сильно упрощает их реализацию.
Крупные компании - более 200 курьеров. Данная ниша гораздо меньше предыдущих, компании как правило уже чем-то автоматизированы, что создает много проблем при внедрении: в "их" системе что-то было реализовано по-другому, пользователям всегда не удобно переучиваться. Бизнес-процессы уже отлажены, и встроиться в них, повторить, нужно практически без репетиции. Нужно вести длительные переговоры, совещания, анализировать бизнес-процессы, составлять ТЗ на доработки для тех участков, которые у них уже были как-то реализованы, дорабатывать без тестирования на продакшене, как мы любим. В общем, очень много непродуктивной деятельности. В проекте внедрения занято куча народа, всякого рода руководители направлений
Риторический вопрос: Сколько руководителей нужно привлечь к проекту, чтобы его провалить?
и даже "менеджеры самого среднего звена". Вероятность успеха проекта внедрения граничит с авантюрой. Такие клиенты у нас тоже есть, в основном выросшие из 2-й категории. Не бросать же людей из-за того, что они выросли! Мы в ответе за тех, кого приручили ©.

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

Итак, наши клиенты из второй группы, со средним чеком в районе 20 т.р. в месяц, но их достаточно. У нас нет якорного клиента: поступления от самого крупного клиента не превышают 5% всего бюджета. Это позволяет мне быть действительно не предвзятым и уверенным в надежности выстроенной структуры. Так же, очень важный момент: это позволяет мне не играть в политику, балансируя между "хочу" отдельных клиентов и правильностью разработки с точки зрения системы, а ставить во главу угла именно архитектуру, гибкость, масштабируемость и поддерживаемость системы.

Бюджет, в основном, складывается из регулярных платежей наших клиентов: за аренду и поддержку. Продажа системы, равно как и платная доработка, в финансовом отношении мало эффективна, т.к. это разовые вещи, на которых построить надежный прогнозируемый бюджет невозможно. Подобные разовые платежи в сумме обеспечивают нам 10-15% бюджета, что, согласитесь, пренебрежимо мало. Поэтому мы ориентируемся на долгосрочное взаимовыгодное сотрудничество со всеми нашими клиентами. Мы заинтересованы в росте бизнеса всех наших клиентов, и способствуем этому всеми доступными нам способами.

Эффективность

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

Команда

Для эффективной работы команда должна быть компактной. Оптимальный размер команды для разработки ПО - 7-15 человек. Это тот объем, который позволяет руководителю дотянуться до каждого сотрудника, проконтролировать работу, объединить усилия всех сотрудников в единый организм и комплексно, целенаправленно решать стратегические задачи. Понятно, что написать Windows с такой командой невозможно, ее нужно сильно расширять. Однако это требует существенного расширения сопутствующего персонала. К сожалению, речь идет не только о найме проект-менеджера на каждую группу по 7 человек (зарплаты которых измеряются сотнями тысяч рублей), но и раздутии штата прочими сотрудниками, напрямую в процессе разработки/сопровождения не занятыми, поскольку работу групп нужно координировать, большую задачу нужно разбить на блоки, требования, функциональность, методы тестирования, интерфейсы взаимодействия которых нужно полностью задокументировать. Объем технической документации при "правильном" подходе занимает больше времени и стоит дороже, чем сам процесс разработки. После разработки каждого куска его надо тестировать отдельными штатными единицами, а потом пытаться склеить эти блоки вместе. В случае же с компактной командой ее можно просто собрать вместе, и сказать: "Давайте сделаем вот это. Ты делаешь это, а ты - вон то, через 2 дня собираемся вместе и проверяем". Поэтому я стараюсь удержать размер команды в оптимальном диапазоне. Пусть мы не можем такими силами взяться за какие-то глобальные мегапроекты, зато предельно эффективно решаем свои конкретные текущие задачи.

Задачи

Экстремальное программирование

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

, а с нашей - это недофича, которой могло и не быть, и никто бы не узнал, что она могла быть

.

Коммуникация

Бюрократия

Поддержка

Эволюция

Отказ от ответственности

Что входит в покупку (аренду) системы

Что входит в поддержку

Тариф 1

Тариф 2

Тариф 3

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

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

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

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

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

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

Предоставить полную информацию Очень важно предоставить исчерпывающую информацию о своем вопросе. Номер заказа, с которым возникла проблема, или название клиента, если проблема с клиентом. Обратите внимание: если проблема касается сразу группы заказов – это хорошо, что Вы например, заметили "Во всех позавчерашних заказах происходит ...", и это даже может нам помочь, но номер конкретного заказа, хотя бы одного из той группы, нужно назвать. Сотрудник технической службы должен увидеть проблему, иначе может случиться так, что, просмотрев несколько заказов и не увидев никаких ошибок, он сочтёт, что дело в «человеческом факторе» и закроет тикет. Это абсолютно нормально и логично: люди ошибаются намного чаще машин! Если вопрос по отчету – укажите точную последовательность действий для его получения, какие пункты меню выбирали, какие данные вводили, приложите сам отчет. Если загружаете файлы – обязательно приложите исходные файлы и опишите, как загружаете. Будьте точны в формулировках! Неправильно сформулированное описание проблемы может привести к тому, что наш специалист будет искать возникшую проблему совсем не там, где она находится, и потеряет Ваше и наше время. Например, после получения формулировки "В подключении дата стоит не такая" последует вопрос о том, что же такое, в Вашем представлении "подключение", и эту потерю времени можно предотвратить, указав понятные нашим сотрудникам термины, а еще лучше – приложить скрин-шот, на котором было бы сразу видно, и какую именно Вы имеете в виду дату.

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

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

Важно! Такие задачи, как наименее продуктивные, получают низший приоритет, поэтому потратьте пять минут и сформулируйте всё в деловом ключе: чётко, полно, объективно.

UPDATE В последнее время получил несколько вопросов о программе по Whatsapp'y на личный мобильный телефон с неизвестных номеров. Такие обращения сразу отмечаются как спам, и номера банятся. Коллеги! Ну давайте уже уважать друг друга!

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

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

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

Почему не нужно обращаться к программистам или директору

Ответ на этот вопрос очевиден: первое, что Вас спросят: какой ответ Вы получили, обратившись в службу поддержки? Не забывайте, что все мы – люди, у всех есть масса важных и нужных дел, и отрывать от них и требовать внимания к себе в обход наших внутренних корпоративных правил – не лучший способ заручиться нашей поддержкой. Вас просто направят прочитать, кому нужно звонить в случае возникновения проблем, а приоритет Вашего дела может быть понижен.

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

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

Сообщаем, и постоянно! В нашей википедии все изменения, которыми мы улучшаем сервис «Курьерской службы», отражаются ежедневно. Напоминаю: у нас работает команда специалистов, которая следит за любыми изменениями в мире и использует их, что бы совершенствовать нашу «Службу». Вряд ли Вы хотите ежедневно получать длинные простыни с различными изменениями и дополнениями, вносимыми в программу. Но можете быть уверенны: эти изменения никак не затронут функциональность существующих решений, а пользу приносят огромную. Любое изменение вначале тестируется с учётом того, как оно отразиться на работе клиентов. Именно поэтому нам очень важно знать, как Вы используете систему, и стараться своевременно предотвратить использование ее механизмов не по назначению.

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

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

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

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

Ошибки в программе

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

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

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

Как я уже писал, в день, в среднем, мы обрабатываем 30 обращений. Из них 2-3 шт звучат примерно как "А добавьте в карточку курьера галку "Выдан фирменный портфель"" (№1) или "А сделайте, чтобы на каждый район на карте можно было назначить отдельного курьера на каждый день недели" (№2). "А добавьте в отчет "количество доставок по клиентам"" поле "Среднее отношение количества выездов курьера к километражу между точками, умноженному на средний счет клиента" (№3).

За 200 (примерно) рабочих дней в году мы бы за год добавили бы минимум 500 таких галок, кнопок и полей, а за 10 лет - 5000. На самом деле - добавили бы гораздо больше, т.к. они тянут друг друга.

По первому примеру: – А завтра Вы, наверное, попросите добавить галку "Выдан планшет", а потом "Выдан проездной", плащ-палатка, футболка и солнечные очки? Клиент говорит "Ну, видимо, да...". Представляете, насколько система была бы не управляема сейчас? На практике, конечно, мы находим решение задач, главное - понимать, что именно он хочет. В первой - клиенту нужно учитывать выдачу сотрудникам и прием неограниченного количества видов инвентаря. И так в модуле складского учета, в номенклатуре, появилась галка "инвентарь", и клиент, помимо того, что просил, получил еще средство контроля за остатками своих фирменных портфелей на складе.

По второму пункту - понятно же, что в 95% случаев на одном районе курьер будет работать каждый день недели, а то, что в выходные у них работает другой курьерский состав на тех же районах - это исключение. С гораздо большей вероятностью, вместо разных курьеров по дням недели, нашим клиентам понадобятся разные курьеры в зависимости от массы отправления (пешие/вело/авто курьеры), или срочности. Если бы мы добавляли возможность указания разных курьеров для всех этих вариаций (а сколько их еще можно придумать!), схемами на карте стало бы невозможно пользоваться. Понимая задачу, которую решает клиент, мы делаем возможность копирования схем. И клиент может нарисовать районы, скопировать схему, и 2 схемы назвать "будни" и "выходные", и назначить разных курьеров. А можно - сделать 7 схем по дням недели. А можно - отдельно для пеших, и отдельно - для автокурьеров.

По третьему эпизоду совсем все просто: Делается отдельный отчет в "доп. возможности", в котором выводятся те показатели, которые нужны клиенту, считающиеся по его ТЗ.

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

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

Как сделать быстрее

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

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

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

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

Как сделать дешевле

Почему доработки доступны всем

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

Если доработка полезная еще кому-то: Представьте, что мы с Вами договорились на такие условия - вы платите (с наценкой за эксклюзивность), мы делаем только для вас. Через месяц к нам приходит другой клиент и просит примерно тоже самое. Мы должны ему отказать в самой возможности реализации его хотелки? Или мы должны взять с него денег как за обычную, не эксклюзивную доработку, и открыть эту функциональность всем остальным?
Если доработка не полезная другим: Я понимаю, что вы свято верите в то, что именно ваша идея - самая нужная всем. Но на практике - большинством доработок надо людей еще заставить пользоваться, если мы знаем, что они им полезны. А в других случаях и заставить не удастся.
Вы тоже получаете все доработки от других клиентов. И из этого состоит вся наша система. Если бы все заказывали доработки только для себя - наша система не существовала бы. И вам пришлось бы нанимать программистов и писать систему самостоятельно с нуля. Собственно, что вам мешает сделать это сейчас? То, что наша система заведомо впереди? Это и доказывает правильность нашей политики разработки.