как я и боялся, все сильно хуже. Замена ручного (человеческого) труда на некий «нечеловеческий» не является «автоматизацией», это обычная, допотопная уже механизация. Но Вы не поняли основной проблемы. Вы не «механизировали» труд, незаметным для пользователя образом. И даже не упростили ему жизнь. В итоге Вы (или не Вы лично, а Ваши коллеги) кардинально сменили интерфейс и назвали это — автоматизацией. Видать видео про лифт и ирландцев, желающих попасть на 11й этаж, надо обязательно показывать всем, кто хочет что-то «автоматизировать» :)

А результат вполне ожидаем — «механизированный бардак». И дело тут не только в технологиях.

Странно, но создается впечатление, что авто сознательно подменяет понятие «смена интерфейса» на «автоматизация». Все, о чем пишется в статье — к автоматизации имеет лишь опосредованное отношение. Поскоьку задача стоит не столько облегчить жизнь оператору/сотруднику выписки (автоматизация), сколько — убрать оператора (сменить интерфейс/способ общения с заказчиком). С этой очевидной ошибки и растут проблемы. Не проанализировав, что именно нужно, народ расчехлил шашки и помчался на нечто грохочущенее в клубах пыли и дыма :)

Это еще не учитывая, что даже нормальный, напечатанный текст, ПО не способно обработать даже с 80% точностью (кто сомневается, переводческое ПО в помощь). Поэтому, автору могу лишь порекомендовать разобраться, что именно нужно заказчику, а уже только потом думать о том, что и как лучше делать.

Что касается голосовых интерфейсов, то они убоги, что называется, по определению — поскольку с одной стороны (человек) имеется источник неформализованных/неформатированных данных, а с другой (система распознования) система, которая может работь только с данными в рамках известных ей форматов и форм.

Если брать примеры, то самым простым вариантом «телефонного меню», будет система. где от человека требуется лишь отвечать «да» или «нет». Применительно к продаже билетов, я бы рекомендовал следующие вариант " «автозаказов»
1. выбрать с 5к самых популярных направлений. и просто спрашивать заказчика, в какой из пунктов он хочет.
что-то типа «Пожалуйста, ответьте да или нет на следующий несколько вопросов»
— Нужен билет в Сочи?
— Нужен билет в Санкт-Питербург?
— Нужен билет в Минск
и так далее, не более 5 вариантов в сумме.
2. Если человеку нужны другие направления, то переключаться на оператора — и далее как всегда (можно, конечно, паралельно включить автораспознование, чтобы оператор меньше вводил, а заодно и проверял).
3. Если какой-то их преложенных вариантов, то включить запись, и попросить человека четко произнести количество билетов, дату и ФИО пассажиров.
4. Сообщить, что на СМС ему придет подтверждение заказа.
5. автоматически распознать произнесенное и передать информацию оператору для проверки.
6 Оператор внесет необходимые изменения и дальше система работает как обычно

Это самый простой и достаточно удобный вариант работы с системами распознования речи на неком сферическом примере.

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

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

Не так, конечно. Если эти инженеры разрабатывают ПО для конструирования водомётных установок, то их областью компетенции является разработка ПО в области конструирования водомётных установок.

А почему не разработка водометных установок? Или все же компетенции разработчиков ПО недостаточно чтобы быть экспертами в данной предметной области (в разработке водометных установок)?

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

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

Ну, да, предлагали. Вот здесь:
«я не хочу делать процессы, оценивать результаты, управлять приоритетами, ставить задачи,… "

Вы прекрасно поняли, что «ставить задачи» в данном контексте относилось к тому, что брать в работу из бэклога/пула/списка заданий. Менеджер не говорит что конкретно и как должно быть реализовано в рамках продукта. Поэтому Ваше передергивание не уместно.

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

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

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

И что это должно опровергнуть? Задачи ставит специалист, а разработчики ее (задачу) реализуют.

Руководство хирургическим отделением ни как не получится соотнести с инженерной деятельностью даже если удастся натянуть сову на глобус.

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

Наверное, «системки», которые из сырых данных мрт сканирования собирают вот те самые красивые 3д картиночки человеков в разрезе? :) тогда ваш знакомый — гений! Поздравляю вас, вам сильно повезло, что вы знакомы с таким человеком.

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

Почему сводить баланс? Это тоже из области совы на глобусе. Это не его дело. А вот написать программы, соотносящие конкретные бизнес-процессы с конфигурацией платформы — разумеется.

То есть Вы подтверждаете, что программист не в состоянии свести баланс предприятия и/или найти ошибки в нем? То есть программист не является экспертом в области бух.учета? Ч.Т.Д. Будь разработчики (да и постановщики задач) экспертами, то не было бы тучи 1Сников чуть не каждой конторе с количество сотрудников от 50 человек.

И главбух программирует их на 1с? Хммм.

Нет, главбух говорит что и как разработчики должны делать.

То, что у вас нет достаточно времени, это ваши проблемы, а вот каким образом разрабатывать и отлаживать систему решения гидромеханических задач, не разбираясь в гидромеханике (тому же 1с-нику), мне по-прежнему интересно было бы узнать.

Этим занимается математик и инженер-расчетчик. Программист лишь реализует то, что скажут специалисты. И без минимальной мат.подготовки (которая и дается в ВУЗе) он их просто не поймет.

Я, как-то пытался во времена оны реализовать какой-то хитрый способ решения систем жёстких дифференциальных уравнений по формальному описанию, ничего в этом на тот момент не понимая… Такая хрень получилась! :)

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

Извиняюсь что вмешиваюсь, но мои краткие комменты

Йеп! И гидромеханика, как ни странно, является одним из её разделов. :)

Гидромеханика является частью физики, а не математики.

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

Если не выдумывать, а внимательно слушать и читать оппонента, то наконец услышите, что я утверждал и утверждаю, что программисты не являются экспертами в предметных областях и не могут принимать решения о том, что и в каких объемах должно быть сделано. Надеюсь теперь Вы наконец поймете о чем и что именно я говорил.

К сожалению, дискуссия потеряла смысл в виду передергиваний и выдумок оппонента.

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

Хм… тогда у меня два вопроса всего: что за предметная область и зачем вы тратите деньги на продакт менеджера?

Инженер — это, вообще говоря, лицо, способное к принятию решений по предмету, входящему в его область компетенции.

Отличная формулировка. Так вот, областью компетенции Инженера является разработка ПО. А не конструирование водометных установок, например. Не так ли?

Я, давайте, повторю вопрос — вы в самом деле уверены, что можно написать бухгалтерскую систему силами «разработчиков» ничего не смыслящих в бухучёте?

Давайте. Не будем далеко ходить, возьмем «1С». Вы доверите разработчику платформы (именно платформы, а не конфигураций, даже с учетом того, что там значительный объем кода от майкрософт) сводить баланс Вашей организации? Или формировать для нее учетную политику? Это обычные задачи главбуха, кстати.

Даже если в предполагаемой системе есть некий «аналитик», то это ведь не менеджер?

Я где-то предлагал менеджеру ставить задачи программисту? Мое замечание относилось к предложению некоего менеджера, чтобы сами разработчики себе ставили и/или уточняли задачи.

Ну, в моей вселенной «программист» — это, как правило, инженер с высшим математическим или, в крайнем случае, техническим образованием. Да, в принципе, ему нет проблем в этом разобраться.
А вот каким образом вы сможете озадачить вашего ПТУшника реализовать и отладить решение гидродинамической задачи без погружения в предмет, хотел бы я посмотреть. «Вот цифры на входе, на выходе должны быть вот эти цифры?»

Причем тут «ПТУшник». Альтернативно одаренных с дипломами МФТИ есть, причем в товарных количествах. Кроме того, я не слышал ни об одном «инженере-программисте» который бы сделал систему, помогающую в анализе данных с геолокатора, хотя лично знаю геолога, писавшего таковую. Или сколько «инженеров-программистов» руководят хирургическими отделениями? При том, что лично сталкивался с практикующим хирургом, который на Objective-C пишет системки, помогающие ему в этой работе.

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

Даже в стартапе, как только появляется он-лайн документация и материалы для обучения — все направляются туда прямыми сслыками. Реально, сапортерам итак достаточно забот.

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

cut

Хотя «правила» и корректные, с точки зрения CRM, но, как я уже писал, в итоге смешали в кучу консультации клиенту и непосредственно техническую поддержку. ОТП не должен консультировать заказчика по вопросам использования продукта. Это прерогатива отдела обучения и внедренцев (проф. сервиса). В SLA эти пункты должны быть четко обозначены и описаны. Если сотрудники заказчика не хотят учить продукт, то их работу с удовольствие сделают внедренцы компании. За отдельные деньги. Если же хотят, то отдел обучения всему научит или предоставит необходимые материалы для самостоятельного обучения.

Ну и пунктом 0 в данным правилах я бы добавил следующий:

Прежде чем отвечать на вопрос, убедись что понимаешь что именно хочет сделать заказчик и для чего

Если в Вашем варианте вселенной разработчики разбираются в предметной области лучше специалистов

Лучше менеджеров? Скорее всего, да.

Лучше продукт-менеджера? И лучше аналитиков? Ведь вопрос стоял не в том, чтобы разработчики слушали каких не попадя «менеджеров», а в том, чтобы они не принимали решений на основе «своего видения», как рекомендуется в статье.

А кто может в вашем варианте вселенной? Неужели их менеджер? Мы ведь про работу менеджера толкуем.

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

Почему непонятно? Как правило, понятно. Только не так, как должно быть :). В этом и проблема.

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

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

На приктике мы имеем модули в которые вносят исправления десятки человек, и через несколько лет никто не способен сказать, что там, как и почему. Так что уже пусть будет лучше «цирк с конями», чем сотня спутавшихся и сросшихся от времени осминогов, из которых надо сделать «трепетную лань»

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

Ну то есть в итоге в предметной области разбирается не каждый разработчик, а некий «аналитик», что и противоречит статье. Но если Вы ожидаете. что простой программист легко разберется в тензорном исчислении, в гидродинамике, расчете усталостных изменений некой двутавровой балки, или даже в области финансового планирования, то я хочу в эту вселенную все сильнее )

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

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

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

З.Ы. А вот почему у вас менеджеры носятся по офису в мыле и запарке — это уже вопрос к Вам. Вы их наверно дустом душите? ))

причет тут дикие глаза и сваливание на сотрудников обязанностей менеджера? Разработчики нужны чтобы разрабатывать продукт в рамках спецификаций. И это их работа и они это умеют делать лучше всего. А раздумывания в стиле «а какой смысл в этой фиче?», «почему именно она нужна заказчикам?», «а хорошо ли я работал этот квартал» — только мешают этому процессу. Более того, они ломают всю идею с управлением разработкой, когда разработчики начинают проявлять инициативу в неожиданных местах. Это хорошо, если сроки «резиновый» и на бюджет наплевать. Но когда мы работаем на тот-же «Fix Price» или даже «T&M», когда необходимо защищать бюджет и показывать результаты, то восторгов от заказчика может не оказаться.

Поэтому все эти советы — очередные костыли, когда менеджеры просто не знают как организовать работу своих сотрудников, и заставляют их самих «эксперементировать» на себе.

Это предложение не о том. Оно о отлаженных процессах.

К сожалению, статья как раз про то что «я не хочу делать процессы, оценивать результаты, управлять приоритетами, ставить задачи, руководить отделом, вы там сами как-нибудь разберитесь, а я потом приду и накажу кого захочу» ))

Прошу прощения, что вмешиваюсь :)
Проблема не в правилах, и даже не в их количестве. Проблема в непонимании руководителями и административными работниками — почему эти самые правила понадобились. А понадобились они по одной простой причине — никто не подумал о том, как все работает и как должно работать. В итоге сотрудники вынуждены каждый раз принимать управленческие решения (как ответить, кому ответить и т.д.). И ожидаемо, делают это как могут, поскольку их должности и зоны ответственности не предполагают этого. В этом случае правила не решают проблемы отсутствия процессов, они лишь играют роль «костыля».

прошу прощения за задержку ответа, был в дали от цивилизации.

Чтобы ответить на вопрос «что является целью бизнеса», сначала нужно понять, что Вы понимаете под словом «бизнес». Особенность английского языка — контекст, то есть множественность значений одного и тогоже слова в зависимость от ситуации его употребления. Для примера — значения слова «бизнес» из словарей: dictionary.com, Cambridge и Oxford. Как мы видим, в узком смысле, под «бизнесом» можно понимать «коммерческие операции» или «действия ради получения прибыли» вообще. Однако в более общем смысле, «бизнесом» является некая регулярная и определенная деятельность. В случае же «бизнес-анализа», именно последний вариант и рассматривается. При этом следует учитывать, что требования и решения по тем или иным бизнес-процессам принимают юристы, коммерсанты, технологи, маркетологи и прочие люди, действующие за пределами этих самых бизнес-процессов. Таким образом, в случае бизнес-анализа ( а не аудита, например) «бизнес-целью» не может являться «прибыль».

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

Да, целью владельцев компании автопроизводителя — является увеличение прибыли. А вот целью процесса производства автомобиля — производство автомобиля согласно заранее известных требований.

Во-первых, спасибо за вопрос и замечание. Теперь по пунктно

Вопрос: зачем стрелка от «поиска способов доставки бандероли» к «уточнению деталей и пожеланий»?
У нас, по сути, идёт последовательность, то есть, человек обратился и ждёт обратной реакции.

Синие «толстые» стрелки подразумевают не столько действие, сколько некое событие, сигнал. Подразумевается, что отправитель сигнализирует (путем звонка, или личного присутствия), что ему нужна такая-то услуга. И именно это «Оператор» и фиксирует. После чего, они уже паралельно переходят на стадию обсуждения. Поэтому никакого ожидания отправителем не предусматривается.

Пунктирные стрелочки в ЖУ, ЖО, СУ (первая часть диаграммы) непонятны, то есть, непонятно что нужно с ними делать.

Эти «стрелочки», по направлению к набору данных — подразумевают занесение информации в этот набор/журнал. Стрелочки от набора данные — получение информации, которая в нем хранится. В принципе, ниже Вы об этом догадались.

На мой взгляд, хоть схема и разрастётся, но она станет более однозначно понятной для всех кто её просматривает, если вместо «Принятие обращения» написать «принятие обращения с его записью в журнал обращений за услугами»

вполне возможно, что я тут перестарался но ниже я пояснил, почему так поступил.

С задачей «консультация заказчика» чуть сложней, так как по сути, это две задачи: «использование справочника услуг» и «запись в журнал обращений», если я правильно понимаю пунктирную стрелочку к ЖУ.

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

Еще раз огромное спасибо за замечания.

очень рад, что понравилось. спасибо

не уверен, что кто-то из маркетинга владеет подобным мат.аппаратом. По сути там больше психологии (управление спросом) чем ожидание в стиле «угадали или не угадали»
С другой стороны, было бы интересно посмотреть, как «байес» работает в этой области.

Боюсь, анлийские слова в русском языке, как обычно, путают Вас. Бизнес не значит «зарабатывание денег». Думаю Вас сильно удивит выражение «некоммерческий бизнес» — «non-profit business». Первая попавшаяся ссылка: тыц.

Поэтому давайте разделять бизнес и коммерческие составляющие. Бизнес — это просто способ что-то делать. Коммерция — это зарабатывание денег.

спасибо :)

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

Тут дело в удобстве. Если каталогизатора + легкой коррекции достаточно, это замечательно.

Цветоделение и иногда интересные плагины в фотошопе — так и остались незаменимы. Но это уже больше к печати. А для экрана фотоимпакта хватало за уши :)