Всего и побольше!

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

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

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

Мы часто вступаем в диалог с клиентом, если у него появляются такие фантазии, наверняка все его запросы можно решить малой кровью, предложить другой вариант реализации, уверен, это ТЗ будет изменено. Если этого не произойдёт, могу предположить такой сценарий развития данного проекта: через месяц после интеграции все поля не относящиеся к заказу, все эти смарт-задачи и прочее будет заполняться бессмысленными знаками препинания, у торгового представителя будет уходить заметно больше времени на работу в точке для того, чтобы просто выполнить базовые задачи (взять заказ, проверить задолженность, сделать фото-отчёт), о программе будут отзываться как о самой неудобной в мире, ни для нас, ни для заказчика это не интересно, так зачем это всё?

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

Смотрите трезвее на вещи и не жадничайте, никуда этот функционал от вас не убежит.