Эсперанто, эльфийский и клингонский

14.06.18

Архитектура

Почему бизнес и ИТ не понимают друг друга? И как сделать, чтобы понимали?

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

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

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

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

Если поразмыслить, как может представитель бизнеса – директор, руководитель отдела, продавец, бухгалтер и т.д. – составить техническое задание на разработку? Понятно, что какой-то документ совместными усилиями родится, но каково будет его качество? Даже если у вас толковые архитекторы, которые умеют анализировать бизнес-требования и переводить их на язык программистов, можете ли вы быть уверены, что он вас правильно понял?

Бизнес-требования, которые вы озвучили, вам понятны. Техническое задание, которое написали программисты под ваши бизнес-требования, вам не понятно. Вы просто верите программистам, что их доработки решат ваши бизнес-задачи.

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

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

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

Работу вам придется принять, так или иначе. С оговорками, с перечнем дополнительных требований, но – принять. И пользоваться.

Языковой барьер

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

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

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

Хотя, все мы знаем примеры, когда подобные задачи средствами автоматизации решались. Значит, в принципе, клингонский язык способен такие сложные конструкции выразить. Но как такое получается?

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

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

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

Попробуйте, шутки ради, перевести в google translate на английский стихотворение, например, вот такое:

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

Что получится?

The storm darkness covers the sky, Whirlwinds whirling. Then as she bewail the beast, That will cry like a child.

Я английский знаю плохо, поэтому для меня этот перевод выглядит, как клингонский. Ну, вроде, похоже на правду. Слова некоторые знакомы, строк и запятых вроде столько же. Наверное, перевод выполнен правильно. Как проверить? Попробуем обратно, с английского на русский:

Штормовая тьма покрывает небо, Кружатся вихри. Затем, когда она оплакивает зверя, Это будет плакать, как ребенок.

Что-то не так… Шлюз работает не очень хорошо, хотя общий настрой, вроде бы, передан верно. Но в деталях, смысле, поэзии текст потерял почти все.

Пример, конечно, из области юмора, но в нашем эсперанто все происходит примерно так же. Вроде все понятно, тема избитая, и картинку красивую с качелей на дереве все помнят. Но живем же как-то? Что не так-то?

Последствия

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

Нет поэзии, произведений искусства, вау-эффектов и взаимного обожания бизнеса и ИТ. Говоря приземленно, нет ИТ-решений, реально помогающих бизнесу.

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

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

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

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

Страдают обе стороны, и обе стороны винят друг друга в своих напастях. Хотя, нет, уже не винят – привыкли как-то, более-менее запомнили этот эсперанто, и уже считают, что так оно и должно быть. У всех же так? Раз у всех, значит все в порядке. Ну ладно, скажете вы, это все понятно и без тебя. Делать-то что?

Да вы и так знаете, что делать. Учить языки. И совершенствовать эсперанто.

Учить языки

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

Первый вариант – пусть бизнес учит клингонский. Как вам такой вариант? Если вы – программист, то, наверное, вам такое по душе. Хотя, нет, это чревато – ведь, если бизнес разберется в информационных технологиях, то вам, как ни крути, придется работать по-настоящему. Сейчас вы, так или иначе, можете скрывать – и возможности, и решения, и косяки.

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

Можно сказать – ладно, пусть бизнес не знает деталей, но по верхам-то может пройтись? И поддерживать актуальность этих знаний. Может, конечно, только это будет тот же эсперанто. Это мы уже проходили.

Намного проще поступить противоположным образом – программисту изучить язык бизнеса.

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

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

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

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

Системы управления, как подкласс процессов, тоже ничего сложного собой не представляет. Причем, бизнес в системах управления сам не очень разбирается, обычно. Это несложно проверить – попробуйте в своей компании найти хоть один процесс управления. Разумеется, если у вас внедрен ISO, то есть там такой процесс – «Менеджмент организации», но его считать не будем, это просто бюрократическая бумажка. Найдите инструкцию для руководителя, где сказано, что, когда и как он должен делать. Их нет, потому что создание систем управления – относительно новая область, которая не выйдет из недр менеджмента, потому что его же и погубит.

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

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

Зачем?

Тут сразу два вопроса: зачем это бизнесу и зачем это программистам.

С бизнесом понятно. Это – жизненная необходимость. Мир ИТ движется к такой модели – интеграции компетенций, потому что иначе беседы глухих со слепыми будут продолжаться до бесконечности.

Бизнес проблему, зачастую, понимает, но решения не знает, не видит. Теперь знает и видит. Осталось только правильно организовать этот процесс – обучения программистов эльфийскому языку. Можно делать это самостоятельно, только толку мало будет. Чтобы научить клингона эльфийскому, нужно знать оба языка, а этого нет. Хотя, Тарзана же как-то научили. Если помните, читать по-французски, а говорить по-английски.

Зачем это программистам? Ну, во-первых, если бизнес, в котором сидят программисты, грамотно возьмется за дело, то и деваться им будет некуда. Разве что, уйти на другую работу, где еще не слышали о новомодных тенденциях.

Но можно и переставить проактивное начало в ИТ-отдел. Никто ведь не запрещает программистам развивать компетенции в смежных областях? Например, подучить эльфийский. А потом, между делом, объявить, а лучше показать на практике свои новые умения. Бизнес, оценив преимущества, сделает двуязычных программистов стандартом в своей компании. Заодно, и выгонит горе-переводчиков, вроде бизнес-аналитиков.

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

Рано или поздно, бизнес найдет выход. Лучше ему этот выход подсказать – выгодный и эльфам, и клингонам.

См. также

Как мы автоматизировали башню раздачи воды

Кейсы автоматизации Платформа 1С v8.3 Энергетика и ЖКХ Россия Бесплатно (free)

Делимся опытом автоматизации учета башни раздачи воды.

27.12.2023    1422    0    slavik27    4    

14

Управленческие аналитики для 1С:Бухгалтерии – отчеты для принятия верных решений

Отчеты и дашборды Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бухгалтерский учет Бесплатно (free)

Если вы привыкли выгружать бухгалтерские операции в Excel и дополнять их там управленческой информацией, вы сможете значительно сэкономить время, получая нужные управленческие отчеты в бухгалтерской программе сразу, без лишних движений. Представляем решение для самостоятельного внедрения управленческого учета в 1С:Бухгалтерии.

11.12.2023    1640    0    Serg_Tangatarov    2    

15

Архитектурное ревью. Процесс разработки

Архитектура решений Бесплатно (free)

Рассмотрим применение архитектурной проверки задач в процессе разработки.

30.10.2023    3828    0    ivanov660    10    

29

Технология разработки Рабочих мест для автоматизации производственных процессов и управленческого учета

Кейсы автоматизации Работа с требованиями Анализ бизнес-процессов Бесплатно (free)

Автоматизировать производственные процессы в 1С:ERP без доработки типовых механизмов очень сложно. А дорабатывать типовые механизмы 1С:ERP не всегда оправданно. Решением может стать технология разработки Рабочих мест, которая позволяет автоматизировать самые сложные участки последовательно – шаг за шагом, процесс за процессом. Расскажем о том, как помочь пользователям вводить большое количество данных, не нарушая порядок ввода и полноту заполнения всех необходимых реквизитов, и как вовлечь сотрудников Заказчика в разработку и тестирование функционала Рабочих мест.

26.10.2023    1818    0    user1754524    15    

15

Опыт оптимизации системы ERP на примере железнодорожного холдинга численностью 10 тыс. человек

Кейсы автоматизации Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

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

29.08.2023    2858    0    ke_almaty    0    

14

5 подходов при доработке конфигурации 1С, чтобы в будущем не было мучительно больно её обновлять

Архитектура Рефакторинг и качество кода Обновление 1С Платформа 1С v8.3 Бесплатно (free)

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

10.08.2023    9582    0    1c-izhtc    37    

21

Внедрение системы технологического контроля (практический кейс)

Кейсы автоматизации Платформа 1С v8.3 1С:Управление нашей фирмой 3.0 Управленческий учет Бесплатно (free)

Стабильное качество выпускаемой продукции и ее соответствие нормативным документам (ТУ, ГОСТам, СМК) для активного предприятия является конкурентным преимуществом, так как оно подчеркивает, что на предприятии отлажены контрольные процедуры на входящее сырье, производство полупродуктов и готовой продукции, доставки. В своей практике я принимал участие во внедрении цифровых инструментов в сельском хозяйстве, где показателями зерна служат влажность, засоренность, крупность и т.д.; в металлургии — перед литьем в формы надо проверить сплав на содержания железа, алюминия, магния и т.д.; в кабельной промышленности в дополнение к физическим свойствам типа геометрии, длины, шероховатости, надо выдерживать и электротехнические показатели. 

22.05.2023    1384    0    Ingraf    0    

15
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. JohnGalt 57 14.06.18 13:03 Сейчас в теме
Бизнес с автомобилем если и можно сравнить, то только в нескольких конкретных случаях. В остальном же, автомобиль это завершенный продукт. В мастерской не просят его ускорить в несколько раз, сделать из него самолет, корабль, танк и т.д.
Представители бизнеса изначально конечно не могут написать ТЗ, но должны к этому стремиться. Зачем они тогда нужны, если не могут объяснить, чем они занимаются и что им нужно. Тогда комании будет хватать только ИТ-отдела с программистами из разными направлениями/опытом для решения задач бизнеса и отдела операторов, которые просто будут заполнять нужные данные.
Мотивация - это краеугольный камень любых начинаний и процессов. Именно мотивация определит, будет ли движение и в какую сторону. Именно отсутствие мотивации со стороны руководителей бизнеса мешает развивать что-либо. Собственники и руководители хотят видеть уже опытного сотрудника, который будет сам все делать, позволяя руководству/собственникам ничего не делать. И чем больше, тем лучше.
JohnyDeath; Stref75; artempo; pfilyk; Trancer64; 7OH; nata_07; корум; A_Max; Art1387; kalyaka; Tavalik; jONES1979; Ponommax; qwinter; Interrupted; paulpit; surikateg; +18 Ответить
2. Vovan1975 13 14.06.18 13:48 Сейчас в теме
На шкале истории бизнеса просто есть маленький отрезок, который называется «увлечение информационными технологиями», который начался весело и интересно, а превратился в глобальное мошенничество.

О, мошенничество значит....
Автор, вы давно в какой-нить ашаниум заходили? Вы так для интереса можете представить сколько времени будет составляться один отчет о продажах, которые каждый ашаниум и не только он обязаны делать каждые сутки? Так, без компа, чисто ручка + бумажка?

Банальная фигнюшка - этикетка со штрихкодом - это тоже информационные технологии, представляете? А благодаря этому + POS один кассир заменяет 3-4 кассиров "без штрихкода".

Это так, вполне себе очевидные для всех применения этих самых технологий.

Так что с мошенничеством вы как-то погорячились
artempo; pfilyk; корум; kinazarov; alexander-pro; Art1387; Serega-artem; rpgshnik; CyberCerber; t.v.s.; +10 Ответить
3. genayo 14.06.18 13:53 Сейчас в теме
Осталось найти достаточное количество управленцев, владеющих эльфийским, а не детским лепетом...
pfilyk; Trancer64; корум; kinazarov; Silenser; Vladimir Litvinenko; Leon75; +7 Ответить
4. pm74 199 14.06.18 14:20 Сейчас в теме
Чтобы два носителя разных языков смогли нормально, содержательно и интересно поговорить, кто-то должен знать два языка – свой и собеседника

может быть вместо google translate поискать грамотного "переводчика" ?
zqzq; Tavalik; AlX0id; Infector; +4 Ответить
52. tindir 17.05.21 06:08 Сейчас в теме
(4) да да да. Переводчика, стенографиста для фиксации переводов, сортировщика стенограмм, старшего печатника и пучок печатников.
5. Infector 199 14.06.18 14:23 Сейчас в теме
Спорно. Я сторонник того, чтобы Эльфийский учил тот, кто бегает по совещаниям и кого автор в других своих статьях назвал координатором, а затем переводил для всей команды. Видится более эффективным решением, чем обучение ослов богословию.
Denium79; Trancer64; grfsd; +3 Ответить
6. Leon75 14.06.18 15:05 Сейчас в теме
Человечество не молодо. И период взаимопонимания, судя по выдолбленным в горных массивах дворцовых комплексах, у него позади.
К выполненной задаче наш вид очень быстро охладевает. Я думаю, сейчас нет цели, чтобы было все хорошо. (но, см. PS)
Другое дело - устроить шабаш юз пользователей, которые вводят в ТЧ и справочники ахинею, несмотря на проверки заполнения и фильтрацию ввода значений на двойные/тройные пробелы.
Разозлить "умного" программиста и сделать из него тупого - это же очень интересная игра в стиле Огги и коркоачес,

P.S. Но стремиться к совершенству - это мне по душе. Несмотря на искусственные сложности.
7. whitedi 17 14.06.18 15:22 Сейчас в теме
Вот читаю очередную крутую статью автора и просто даже подумать страшно, как его трясет на всевозможных совещаниях и обсуждениях в его очередной организации от бессилия, когда очередной главный бухгалтер или начальник снабжения начинает предлагать что-то "новое и эффективное")
Написано все красиво, но донести до конкретных людей все эти знания и выводы практически невозможно - слова всегда останутся только словами, какими бы логичными и четкими они не были) Только испытания на собственной шкуре дают людям мудрость, к сожалению. Тем более программист в организации - это не тот советчик, которого будут слушать, даже если этого программиста назвать аналитиком бизнес-процессов, начальником службы автоматизации бизнеса и прочими красивыми должностями.

В любом случае, удачи автору в достижении своей благородной цели)
8. herfis 498 14.06.18 15:34 Сейчас в теме
"Почему бизнес и ИТ не понимают друг друга?"
Потому что они немного про разное.
"И как сделать, чтобы понимали?"
Добавлять одной из сторон понимания другой стороны. Очевидно, что гораздо проще добавить ИТ понимание бизнеса, чем наоборот.
Вау.
pfilyk; корум; alexander-pro; A_Max; docerman; citicat; Степной; Nadushka74; +8 Ответить
18. FesenkoA 57 15.06.18 18:57 Сейчас в теме
(8) Если представители ИТ поймт бизнес - зачем им тогда им нужен, они откроют свой бизнес, а со знаниями ИТ они заткнут бывших заказчиков, а ныне конкурентов за пояс!

та прослойка - это, как правило, тимлид, или директор (если фирма небольшая) - то есть тот, кто сам в этом варился/варится, и не уйдет, набравшись знаний. Тимлид, а особенно если он хороший аналитик, видит что 2 бухгалтера делают тупую работу 7 часов в день, и дает задачу на доработку, чтобы заменить их 1 обработкой. Я такое не раз делал, но понять что именно сделать, и где та самая "дырка" - работа ТЛ. Собсно поэтому тимлид получает больше архитектора, хотя знает в ИТ и меньше..
artempo; zqzq; +2 Ответить
9. Kutuzov 736 14.06.18 16:38 Сейчас в теме
Я думаю, вопрос решения бизнес-задач несколько глубже, чем просто бизнесменам и программистам научиться друг друга понимать. В ваших статьях я уловил некую мысль, что якобы существуют какие-то "бизнес-программисты", которые способны решать задачи вроде "уволить двух бухгалтеров", "снизить остатки на складе на 50%", а то и "повысить продажи в два раза". Ни один программист не способен решить такую задачу, это полностью другая область деятельности. И я скажу больше, ни один начальник, который приходит к программисту с очередной задачкой "сделай мне вот такой отчет" - тоже не знает решения. Т.е. нет однозначного решения, что вот этот вот отчет делает работу одного бухгалтера не нужной. Можно лишь пробовать, тестировать. Глядишь, на 100-й раз что родится путное, продвинет бизнес вперед. Программирование - это вообще про другое. Это про то, как в условиях ограниченных данных составить какой-то понятный алгоритм действий. В реальном бизнесе очень мало понятных алгоритмов действий. Методик и технологий много, но что сработает для конкретного бизнеса - большой вопрос. Поэтому четких алгоритмов решения задач (с понятными исходными данными, ресурсами, результатами) - не существует, поэтому навыки программистов для решения таких задач малоприменимы.
Trancer64; корум; user811769; alexander-pro; kalyaka; Tavalik; zxcvb98765; citicat; Bassgood; profiprog1c; +10 Ответить
11. genayo 14.06.18 20:07 Сейчас в теме
(9) Вопрос оптимизации существующих процессов программист таки может решить удачно.
12. Kutuzov 736 14.06.18 20:27 Сейчас в теме
(11) Вряд ли, ведь он не понимает, как именно существующий процесс влияет на деньги. Т.е. взять произвольную компанию - и дать задачу программисту: "на-кось, оптимизируй", то результат будет нулевой или отрицательный.
13. genayo 14.06.18 21:25 Сейчас в теме
(12) Это весьма спорное заявление. В большинстве случаев разобраться, как процесс влияет на деньги, не представляет особой сложности.
СергейК; alexgood; +2 1 Ответить
45. pfilyk 22.06.18 15:47 Сейчас в теме
(12) там и понимать нечего, сокращения времени выполнения процесса напрямую влияет на деньги. потому что время всегда деньги.
47. Kutuzov 736 22.06.18 16:00 Сейчас в теме
(45) свободное время ваших сотрудников - это просто дополнительно выпитые чашки чая :) Если у вас был случай в практике, когда вы что-то автоматизировали, сократили время какого-то важного процесса, и тем самым увеличили поток прибыли компании - расскажите, пожалуйста.
48. genayo 22.06.18 16:10 Сейчас в теме
(47)Это если это освободившееся время ничем другим не занимать. 99% сотрудников сами не придумают, чем им для пользы компании заниматься :)
50. strange2007 144 14.08.18 07:45 Сейчас в теме
(12) Не соглашусь. Например, в одной конторе за несколько лет только недавно сумели посчитать прибыль, со всеми вытекающими. Мне кажется это нифига не минус, а живые деньги. Или, например, в одной конторе уменьшили воровство. Тоже вроде как деньги. Конечно, это работа не только программиста, а целой команды, состоящей из программиста, гл.буха и директора. Только почему-то раньше эти задачи не могли решиться и все бились головой об стену.
В общем, может и ошибаюсь сильно, но так смело бы не утверждал про программистов.
10. Vovan1975 13 14.06.18 16:38 Сейчас в теме
Нет поэзии, произведений искусства, вау-эффектов и взаимного обожания бизнеса и ИТ. Говоря приземленно, нет ИТ-решений, реально помогающих бизнесу.

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

Поэтому Вы про них и не знаете.
pfilyk; корум; alexander-pro; Serega-artem; Waanneek; citicat; qwinter; genayo; +8 Ответить
14. Aphanas 92 15.06.18 07:54 Сейчас в теме
Язык бизнеса невозможно выучить, потому что у бизнеса нет языка. Стоит перейти с одного предприятия на другое - становится ясно, что эльфийский язык - это ересь и абракадабра. Все разговаривают на языке руководства. У каждого директора свой язык. Предметная область - это хаос, который будут бесконечно автоматизировать, но дело, по сути, с места так и не сдвинется. И тут даже серебряная пуля ни чем не поможет.
Проблема в том, что, если язык ИТ строг, устойчив, функционален и полностью выполняет свою задачу, то язык бизнеса находится на первобытном, пещерном уровне развития. Это еще даже не язык вовсе, а скорее невнятные мычания, изредка напоминающие хоть какой-то набор слов.

Что нужно, чтобы было хорошо? Первое и главное - всеобщая консолидация бизнес-знаний, полная ревизия, классификация и каталогизация всех понятий. К сожалению, ничего подобного в ближайшем будущем не просматривается. Так что можно спокойно продолжать автоматизацию хаоса. Это не мы сделали бизнес таким, и его языковые трудности - не наша сфера. Это забота тех, кто занимается бизнесом. Так пусть они поднимут голову над своей делянкой и займутся своим языком.
artempo; kostas; Silenser; alexgood; pm74; +5 Ответить
16. пользователь 15.06.18 09:11
Сообщение было скрыто модератором.
...
19. Leon75 15.06.18 20:40 Сейчас в теме
(14)Римляне тоже считали северные племена варварами. И им вроде как казалось, что они говорят бар-бар-бар.
Но Империя пала.
Я скажу так: если хаос есть, то значит он для чего-то нужен. Были девяностые, государство показывало бизнесу "кто здесь папочка". И организация может вести себя исторически как стая мелких рыбешек (даже если схватишь одну - из нее ничего не вытащишь, так как она сама ничего не знает).
15. AnSk 15.06.18 09:05 Сейчас в теме
Когда вы приезжаете в автосервис, вы пишете ТЗ?


Нет, конечно. Только сравнение некорректное. Автосервис это уровень техподдержки - возникла ошибка, не проводится, проводится не так.

Но если вы приедете в тюнинг-ателье, то от вас захотят конкретное ТЗ. Иначе сделают на свой вкус. А там нравится или нет - не их проблема. Плати деньги и забирай. Или второй вариант - давай конкретное ТЗ и плати повторно чтоб переделали.
artempo; pfilyk; kostas; monkbest; корум; zqzq; alexander-pro; Поручик; A_Max; Art1387; Vladimir Litvinenko; Silenser; alexgood; Tavalik; Leon75; itriot11; acanta; VladimirMelnychenko; Serega-artem; dmpas; docerman; thunder84; zxcvb98765; V.Stavinsky; qwinter; user605780_L.Alexander8; ladon; +27 Ответить
17. acsent 1199 15.06.18 18:42 Сейчас в теме
Задача: Сеалать чтоб не было дефецита (добавить кнопку "Сделать хорошо") - это не задача.
Большинство бизнюков - не знает никакого языка бизнеса. И эти процессы от них так же далеки как и програмный код.

ну и вообще - это отдельная профессия "бизнес-аналитик", который может посмотреть как есть и предложить как нужно.
И совет из серии: мышки - становитесь ежиками
pfilyk; корум; Silenser; +3 Ответить
29. 1c-intelligence 12771 19.06.18 07:31 Сейчас в теме
(17)
Задача: Сеалать чтоб не было дефецита (добавить кнопку "Сделать хорошо") - это не задача.

это вы два стереотипа в кучу смешали. Никто не понимает задачу устранения дефицитов, как большую кнопку "Сделать хорошо".
Такую задачу просто не ставят, заранее считая ее не решаемой, именно в такой постановке. Сразу, в ходе первого же обсуждения, начинают дробить на куски, раздавать в разные отделы, тем самым переводя цель в разряд недостижимых. В терминах статьи - сразу переводят на эсперанто.
20. Tavalik 3350 16.06.18 06:53 Сейчас в теме
Заодно, и выгонит горе-переводчиков, вроде бизнес-аналитиков.


А бизнес-аналитикам то за что досталось?

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

В IT-компаниях (НЕ в 1С-ном мире уже давно, в 1С-ном пока не везде, но процент растет) уже давно произошло разделение на аналитиков и разработчиков (а также тестировщиков, администраторов и др.). Появились аналитики (или консультанты) уже и на конечных предприятиях. Здесь каждый участник команды хорошо знает именно свою область и работу: аналитики общаются с бизнесом, разработчики программируют. Узкая специализация и разделение труда - хорошо это или плохо? Не мне судить. Но я убежден, что команда из 3 хороших аналитиков и 2 разработчиков сделает работу намного эффективней (качественней, быстрее, дешевле), чем 5 разработчиков 1С, пытающихся разговаривать с бизнесом на их языке.
artempo; user811769; A_Max; edkuznetsov; Art1387; vcv; kalyaka; papche; json; dmpas; Silenser; +11 Ответить
28. 1c-intelligence 12771 19.06.18 07:28 Сейчас в теме
(20)
Но я убежден, что команда из 3 хороших аналитиков и 2 разработчиков сделает работу намного эффективней (качественней, быстрее, дешевле), чем 5 разработчиков 1С, пытающихся разговаривать с бизнесом на их языке.


убежденность - это хорошо. На фактах удавалось проверять?

Я вот прям сейчас наблюдаю картину, когда 2 хороших аналитика, очень глубоко понимающих бизнес, ставят трем крутым js-разработчикам такие задачи, что плакать хочется.
43. Tavalik 3350 21.06.18 12:34 Сейчас в теме
(28)
Ну что же? Всяко бывает. Вполне возможно, что поработав таким составом, сделав несколько совместных проектов, вы в итоге выйдете на пик производительности команды. А аналитики научатся ставить задачи и таким крутым разработчикам, особенно если крутые разработчики им в этом помогут.
46. pfilyk 22.06.18 15:53 Сейчас в теме
(28) лучший аналитик, это бывший разработчик, который перешел
30. пользователь 20.06.18 09:49
Сообщение было скрыто модератором.
...
31. Aphanas 92 20.06.18 09:57 Сейчас в теме
(20) Нет такой науки "экономика", есть наука "математика" (с)
Кто такой аналитик?
Лично у меня сам факт существования такой профессии вызывает некоторый разрыв шаблона.
3 аналитика на 2-х разработчиков??? о_О
32. Aphanas 92 20.06.18 10:00 Сейчас в теме
(20)(20) Нет такой науки "экономика", есть наука "математика" (с)
Кто такой аналитик?
Лично у меня сам факт существования такой профессии вызывает некоторый разрыв шаблона.
3 аналитика на 2-х разработчиков??? о_О
33. genayo 20.06.18 10:22 Сейчас в теме
(32) Языки видимо совсем сложные (хотя, скорее всего, языка как такового нет), раз 3 переводчика нужны...
34. Артано 760 20.06.18 11:01 Сейчас в теме
(32) Сформулировать проблему или потребность, как правило, сложнее чем реализовать. Если цель очевидна, то нет затрат времени разработчика на бесконечные уточнения требований
35. пользователь 20.06.18 11:27
Сообщение было скрыто модератором.
...
36. Aphanas 92 20.06.18 11:28 Сейчас в теме
(34) (34) Напоминает ситуацию, когда один "копает", а всё остальные только "ставят задачи". Видели такую картинку?
Прикрепленные файлы:
37. Артано 760 20.06.18 12:07 Сейчас в теме
(36) Не видел, мне только вчера интернет провели.

По сущетсву вопроса: какая разница что это может напоминать если так эффективнее? Другой вопрос если эти три аналитика там потому что "так у других, а мы чем хуже?" Но это скорее подтверждает утверждение, чем его опровергает.
38. Aphanas 92 20.06.18 13:15 Сейчас в теме
(37)
если так эффективнее

ИМХО, сомневаюсь.
Уж скорее эти три аналитика там просто потому что нет трёх дополнительных разработчиков.
42. Tavalik 3350 21.06.18 12:06 Сейчас в теме
(32)
Лично у меня сам факт существования такой профессии вызывает некоторый разрыв шаблона.

У меня не вызывает. Работаем по такой схеме много лет.

(32)
3 аналитика на 2-х разработчиков??? о_О

Да, именно так. В среднем отношение 1:1, все зависит от стадии проекта.

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

Если всей перечисленной работой аналитиков вы хотите заниматься сами, то пожалуйста. Каждый делает то, что ему нравится. Просто вы работаете не разработчиком 1С, а консультантом-разработчиком 1С. И я не говорю, что это плохо. Мне просто почему то кажется, что при прочих равных моя команда эффективней, хотя подтвердить это цифрами я не могу, да.
44. Aphanas 92 21.06.18 14:09 Сейчас в теме
(42) Наверное вы правы, просто в наших краях таких аналитиков очень мало
21. julego 16.06.18 15:50 Сейчас в теме
Ну, собственно, верно всё. А ещё слух был, что придумали зачем-то строительных архитекторов, сметчиков, каменщиков, крановщиков, штукатуров, маляров, дизайнеров интерьеров ... Выдумают же, вот чесслово :) Туалет на даче и без всей этой братии могу построить, легко! Хотя погодите, говорят, в городах то туалеты прям в домах, да ещё и в несколько этажей...
strange2007; Tavalik; nata_07; +3 Ответить
22. acanta 17.06.18 12:18 Сейчас в теме
Имхо, эта проблема связана либо с аутизмом (диагноз) либо с саботажем / прокрастинацией в случаях не связанных с нарушением психики. И то и другое форс мажорные обстоятельства. В первом случае бизнесу придется и учить клингонский и нанимать аналитиков или менять разработчиков. Во втором поможет примитивный аджайл с увеличенным интервалом между спринтами, чтобы разработчик, который погружается в проблему полностью, имел возможность выйти из астрала (или вынырнуть из выгребной ямы, называемой конфигуратор) и обратить свой взор на реальные проблемы как собственные, так и проекта. Или так же как в первом случае
нанимается аналитик или меняется разработчик. Понимает разработчик эльфийский или нет значения не имеет. понимание бизнесом клингонского снижает количество архитектурных ошибок. Понимание программистами эльфийского уменьшает ошибки кодирования и модификации. Тот кто идет в лес может делать себе посох из подножных материалов. Но если он ищет в нем партизан, то деревьев не увидит. В этом кроется причина бесполезности ежедневных и вообще периодических планерок и совещаний. Они проводятся перед началом и по окончании спринта. Если этого недостаточно, меняется размер спринта.
23. acanta 17.06.18 13:23 Сейчас в теме
Мой вывод из статьи - в понимании нет необходимости. Достаточно исполнительной дисциплины и работающего отдела кадров. Но этот вывод сделан на базе отношения с работниками фикси, фри или франчи - не важно.
24. acanta 17.06.18 13:32 Сейчас в теме
Нюанс в том, что при отношениях между клиентами и командой разработчиков проблемы понимания не возникает. Будь то отдел разработки, франч или отдельный фикси. Как в стране Оз. Говорят и понимают на всех языках даже Тотошка со Страшилой. В отличие от хоккея или футбола состав команды может меняться в процессе матча лиги чемпионов причем на место вратаря и нападения ставят свежих нетренированных новичков, которых срочно нужно прокачать ( они дешевле и не защищены контрактом). А состав тренеров вполне может в это время сделать ставку на победу противника или конкурента. Предметом обсуждения будет кто на сколько попал или кто кого кинул( выражаясь по эльфийски). Каковы принципы работы в такой команде?
25. vcv 89 17.06.18 16:24 Сейчас в теме
Сравнение с автосервисом категорически неверное. Ваш автосервис - это аутсорсинг по обслуживанию компьютеров и сети. Они не спрашивая ТЗ почистят сеть от вирусов, настроят бэкапы, дадут рекомендации по замене оборудования... Но они не модернизируют ваш программный продукт. Так же как и большинство автосервисов не возьмётся установить на вашу малолитражку 30" колёса и движок на четыреста лошадей. А вот если вы таки захотите подобное и найдёте где, вот тут уже с вас запросят много-много дополнительной информации. Потому что вы хотите только колёса и движок, а надо бы еще корпус укреплять, амортизаторы другие, глушитель на крышу поднять и тому подобное.
pfilyk; корум; +2 Ответить
26. Поручик 4670 18.06.18 07:36 Сейчас в теме
Наша контора в основном занимается разработкой и сопровождением ПО, в том числе сайтов, для организаций в области экспертизы строительных проектов. Нам учить язык и вникать в дебри экспертизы строительства? Там много специфичного.
27. 1c-intelligence 12771 19.06.18 07:25 Сейчас в теме
(26) вы наверняка уже вникли.

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

Это все равно, что для программиста понимать алгоритмы, функции, классы, методы, свойства, асинхронность, запросы и т.д.

В разных языках и средах программирования есть свои особенности, но базовые понятия остаются на месте. То же и в бизнесе.

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

Так же, как вы можете написать функцию или сортировать массив на любом языке программирования, освоив его базовый синтаксис.
39. starik-2005 3033 20.06.18 13:33 Сейчас в теме
У бизнеса одна задача - создать стоимость. Заработать. Как это будет решаться в каждой конкретной организации - дело управленческое. Но любое "заработать" состоит из стоимости продажи за вычетом стоимости приобретения (создания, придумывания, ...). В итоге любой бизнес хочет как можно больше заработать и как можно меньше потратить, но из-за лени и некомпетентности руководства, как основных стейкхолдеров, влияющих на стоимость, часто принимаются компромиссные решения типа "сделать это с минимальными телодвижениями с нашей стороны", т.к. руководство - это не владельцы бизнеса, а те же наемные сотрудники. И только владелец (если это конкретный человек) может мыслить немного по-другому, предъявляя требования не столько к продукту, сколько к снижению стоимости владения при достаточном на его взгляд снижении затрат (ибо ИТ - это в первую очередь именно снижение затрат, но оно должно быть выше стоимости владения) или увеличении производительности труда (что, опять же, влечет за собой снижение затрат на единицу продукта).


В итоге бизнес в лице владельца хочет от ИТ снижения затрат и увеличения производительности труда, а управленцы - минимального движения их телесами, при котором можно сохранять статус кво или даже продвигаться вверх. Вот и весь язык бизнеса. Есть еще пограничные варианты, но мотивация у всех - больше денег и меньше движений.
pfilyk; zinal; acanta; +3 Ответить
40. zinal 46 20.06.18 17:46 Сейчас в теме
Не могу согласиться с базовым тезисом.
Нельзя поставить программистам задачу «оптимизируй учет так, чтобы можно было уволить двух бухгалтеров» или «сделай так, чтобы не было дефицитов».

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

Вся так называемая ИТ - "неизбежное зло" по определению, потому что бизнесу не нужны "компьютерные программы". Бизнесу нужны решения задач.
Если задача решается программой или её доработкой - это хорошо (причина терпеть), программы и их доработки стоят денег и требуют времени (несомненное зло).
41. starik-2005 3033 20.06.18 17:59 Сейчас в теме
(40)
Не могу согласиться с базовым тезисом.
И тут же:
Программистам - действительно нельзя.
Что-то я потерял нить.

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

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

Отсюда как бы мораль: разделение труда - это хорошо. Аналитику аналитиково, программисту программистово. Не нужно все в одну кучу - лучше будет. Но если вдруг изъявит кто желание разобраться в языке бизнеса - молодцом будет и ожидает его долгая дорога по карьерной лестнице.
49. 1c-intelligence 12771 06.07.18 09:36 Сейчас в теме
Друзья, прошу прощения за спам - поучаствуйте в голосовании.
51. user1082343 04.11.18 12:48 Сейчас в теме
Эсперанто - ущербный суррогатный монотонный как заевшая пластинка недоязык, основанный на латинской лексике романских языков, по сути суррогатный итальянский. Лучше использовать настоящий итальянский, он намного изысканнее и интереснее!
Оставьте свое сообщение