Изменения

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

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