Когда вы приезжаете в автосервис, вы пишете ТЗ? Конечно, многие из вас разбираются в автомобилях, и среди моих знакомых есть ребята, которые могут запросто разобрать и собрать обратно коробку передач. Но, все-таки, большинство из нас ставят задачу в виде «что-то стучит, когда еду быстрее 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 и т.д. Эти знания можно смело оставить бизнесу, и не изучать соответствующие разделы эльфийского языка. По крайней мере до тех пор, пока не решите создать свой бизнес.
Зачем?
Тут сразу два вопроса: зачем это бизнесу и зачем это программистам.
С бизнесом понятно. Это – жизненная необходимость. Мир ИТ движется к такой модели – интеграции компетенций, потому что иначе беседы глухих со слепыми будут продолжаться до бесконечности.
Бизнес проблему, зачастую, понимает, но решения не знает, не видит. Теперь знает и видит. Осталось только правильно организовать этот процесс – обучения программистов эльфийскому языку. Можно делать это самостоятельно, только толку мало будет. Чтобы научить клингона эльфийскому, нужно знать оба языка, а этого нет. Хотя, Тарзана же как-то научили. Если помните, читать по-английски, а говорить — по-французски.
Зачем это программистам? Ну, во-первых, если бизнес, в котором сидят программисты, грамотно возьмется за дело, то и деваться им будет некуда. Разве что, уйти на другую работу, где еще не слышали о новомодных тенденциях.
Но можно и переставить проактивное начало в ИТ-отдел. Никто ведь не запрещает программистам развивать компетенции в смежных областях? Например, подучить эльфийский. А потом, между делом, объявить, а лучше показать на практике свои новые умения. Бизнес, оценив преимущества, сделает двуязычных программистов стандартом в своей компании. Заодно, и выгонит горе-переводчиков, вроде бизнес-аналитиков.
Надо лишь понять, что автоматизация бизнеса сейчас, на эсперанто – просто мыльный пузырь. А лопнет он только с одной стороны – там, где сидят важные представители клингонского языка. Бизнес никуда не денется, он жил столетиями и будет жить дальше. На шкале истории бизнеса просто есть маленький отрезок, который называется «увлечение информационными технологиями», который начался весело и интересно, а превратился в глобальное мошенничество.
Рано или поздно, бизнес найдет выход. Лучше ему этот выход подсказать – выгодный и эльфам, и клингонам.
Упражнения
Вы, в терминах статьи, скорее всего, говорите на клингонском. Я попробую написать несколько фраз на эльфийском, а вы, если есть желание, поупражняйтесь в переводе — или на клингонский, или, хотя бы, на эльфийский.
«Хочу знать, как влияет автоматизация на изменения в моем бизнесе».
«Что можно автоматизировать, чтобы сократить количество бухгалтеров?».
«Можно ли сделать так, чтобы разогнать всех менеджеров, ничего не продающих, а только вбивающих заказы с бумажек?».
«Можно как-то сделать так, чтобы не было дефицитов?».
«Как избавиться от дилерского отдела, который только и тем занимается, что организует взаимодействие с партнерами?».
«Что-то можно сделать с кассовыми разрывами?».
«Как бы мне качество производства повысить? Сейчас — просто беда».
«Меня жутко бесят все экономисты, готовящие мне отчеты. Можно как-то от них избавиться, не теряя этих отчетов?».
«А во сколько мне обходится ведение учета? Хотя бы цифру знать, я уж не говорю об оптимизации...».
«Как бы сделать так, чтобы я, и другие руководители, узнавали о проблемах заранее? Чтобы можно было своевременно отреагировать».
Сможете перевести?
Комментарии (46)
Cobolorum
21.01.2019 08:37+2Детский сад какой то!
Уже лет 50 как появилась такая специальность –аналитик. В сложных и больших проектах системах есть аналитик от IT и аналитик о бизнеса. А для очень сложных систем есть еще системный архитектор. Для длительных проектов вводится менеджер проекта.
Так же ни кто не запрещает программисту для примера купить книжку «Бухучет» или «Современные методики выращивания гидропонных культур». Так и бухгалтеру не плохо прочитать что то типа «Основа баз данных» или «Администрирование компьютерных сетей». Хотя это все есть «изучения клингонского языка», но первый абзац ни кто не отменял.
P.S. И товарищи программисты, если вы ощущаете себя инженерами, то будьте Инженерами! Настоящий инженер это такой товарищЪ у которого так называемый кругозор или по модному soft skills это как минимум половина инженера!
nmivan Автор
21.01.2019 09:13-2В сложных и больших проектах системах есть аналитик от IT и аналитик о бизнеса. А для очень сложных систем есть еще системный архитектор. Для длительных проектов вводится менеджер проекта.
итого, три чувака, необходимость которых очевидна только им самим?bromzh
21.01.2019 13:07Если бизнесу с большими IT проектами не очевидна необходимость в таких людях — то это такой себе бизнес. Нормальные программисты вряд ли там будут задерживаться, соответственно, качество IT продукта будет не очень. А это скорее всего будет вести к убыткам.
mikaakim
21.01.2019 08:39+1То есть вы предлагаете добавить к должности разработчика еще и анализ и перевод бизнес-требований на технический язык? А не треснет ли?
Когда бизнесу надо фичу, которая на бумаге выглядит раз-два и готово, и нужно её уже вчера, а в текущей информационной системе для её реализации требуется неделя. Бизнес-аналитикам платят за то, чтобы держать бизнес-контекст в голове и накладывать его на информационную систему с её ограничениями за приемлимое время с приемлимым качеством.
Вот только упускается один момент — перекладывая эту деятельность на плечи разработчика его зарплата не увеличивается. Смешение компетенций пока не выигрывает в молотилове технологий и подходов в IT. Я считаю что компетенция в бизнес-аналитике для разработчика это приятный бонус для бизнеса, но платить за это отдельно пока не хотят. Не отрицаю, что есть окружения, где разработчики широкого профиля получают достаточно, но лично мне пока бывать там не доводилось.gennayo
21.01.2019 08:53Есть маленькая проблема — у среднего российского бизнеса, о котором статья, обычно нет денег на компетентных бизнес-аналитиков.
nmivan Автор
21.01.2019 09:11-2Бизнес-аналитикам платят за то, чтобы держать бизнес-контекст в голове и накладывать его на информационную систему с её ограничениями за приемлимое время с приемлимым качеством.
они справляются?
abyrvalg
21.01.2019 09:01В разделе «Упражнения» — не эльфийский. Это язык Эллочки-людоедки.
Посыл статьи "Каждая кухаркаКаждый программист должен быть и программистом и CFO одновременно" непонятен. Зачем это надо? Просто из-за того, что руководству жалко денег на бизнес-аналитика?nmivan Автор
21.01.2019 09:11-2а там, где есть бизнес-аналитики, все хорошо? Работает этот метод? Решаются проблемы бизнеса?
roscomtheend
21.01.2019 09:42Лучше, чем там, где их нет. Проблемы решаются быстрее (без аналитика, имеющего общую структуру действительо масштабного проекта, всё происходит дольше (куча согласований точка-точка, которые часто дают неверный/неполный результат)).
Заодно, и выгонит горе-переводчиков, вроде бизнес-аналитиков.
Поздравляю, бизнес ограничил возможности соих проектов (большой не поятнут, возьмут — надорвутся и на штрафники влетят), а накладные расходы повысил очень сильно. Вот это и будет результатом, который декларативно важен, но на самом деле нет.
Mimus_spb
21.01.2019 09:04Брат, толмачами с бизнес-языка на ТЗ для разработчиков кормится целая плеяда аналитиков (и ваш покорный в их числе).
Проблемы могут быть только у заказчиков, которые не забюджетировали адекватных денег на нашу работу.
Адекватных денег?!Ну да, берите бюджет разработки, умножайте на 0.1nmivan Автор
21.01.2019 09:10-1ну да, в статье так и написано: «Бизнес, оценив преимущества, сделает двуязычных программистов стандартом в своей компании. Заодно, и выгонит горе-переводчиков, вроде бизнес-аналитиков.»
Mimus_spb
21.01.2019 09:29Если у вас даже на горе-БА нет грошей, как вы собрались нанимать чудо-единорогов, двуязычных разработчиков (котоыре наверняка у вас и в тесты могут, и поменеджерить, и сейлзам помочь продукт продавать)?
Работать в нашей компании большая честь? )nmivan Автор
21.01.2019 09:33Думаю, важнее результат, чем параметры — сколько там БА или программистов.
Была компания, тратившая на БА, внутренних и внешних, порядка 1 млн. в месяц. Толку — ноль. Им что делать? Других БА искать? Или побольше нанять?Mimus_spb
21.01.2019 09:50Если вы тратитие 1кк в мес на БА без результатов, то надо искать причины не в БА, а в руководстве, инфа сотка.
Даже за 400-500 в месяц (т.е. белые 200-300 на руки) на рынке РФ масса достойных кандидатов. За 1кк пока что можно целый дрим тим собрать.Wedma
23.01.2019 15:13+1я Аналитик, согласен и с основной мыслью статьи и про «паразитов»:
Если вы тратитие 1кк в мес на БА без результатов, то надо искать причины не в БА, а в руководстве, инфа сотка.
Фокус в том что, двуязычные Программеры стоят гораздо дороже, чем Аналитик.
И как правило, такие Программеры очень быстро становятся «Директорами по Развитию» и т.д.
Могут быть разные модели: «с Аналитиком» или «Двуязычные Программеры»
И они могут быть одинаково эффективны в каждом отдельном случаи со своей спецификой и т.д.
Главное что бы выбор той или иной модели был осознанным и управляемым, что не отменяет возможности смешанного варианта, и изменения во времени.
sergix
21.01.2019 09:22Эх. Слишком заинтриговал заголовок, думал хотя бы мелкое описание каждого из языков будет или что-нибудь в их стиле написано, а прочитал — опять про экскаватор и лопаты(кто не в теме, была такая аллегория, что заказчик просит огромную лопату не зная о возможности создать экскаватор).
sticks
21.01.2019 09:35Так можно написать про любую инженерную специальность. Например: решила конторка зарабатывать на запуске космических ракет, а для этого, оказывается, нужен космодром. Приходят, значит, они к строителям и говорят на своем эльфийском: «хочу, короче, дом такой, чтобы из него ракеты вылетали!». Ну и попробуй реши такую вот эльфийскую проблему.
greabock
21.01.2019 10:17+2Если поразмыслить, как может представитель бизнеса – директор, руководитель отдела, продавец, бухгалтер и т.д. – составить техническое задание на разработку программного продукта?
Эм… по ГОСТ'у например. Его потому и придумали.
Между бизнесом и программистами есть граница – языковой барьер. Бизнес не понимает языка информационных систем, программисты не понимают языка бизнеса. Чтобы хоть как-то существовать, и хоть чего-то делать, обе стороны изобрели суррогатный язык – некий аналог эсперанто, одинаково понятного и непонятного обеим сторонам.
Вам нужно почитать Эванса. В своей "большой синей книге", он подробно излагает, как правильно вырабатывать такой словарь.
Было бы здорово, конечно, если бы программисты создали отторгаемую систему, на которую бизнес посмотрел бы со стороны, и принял решение – брать или не брать.
Вы не поверите, но программисты ежедневно занимаются созданием таких систем. Так работают все SaaS решения.
Вообще, необходимость выработки общего языка давно известна. Это касается не только бизнеса, но и любого процесса который возникает необходимость автоматизировать. Вся первая часть книги "Предметно ориентированное проектирование" Эванса, посвящена именно этой проблеме. И любой, более-менее толковый специалист в области анализа и проектирования систем, прочитал ее хотя бы однажды. Если же вам попадались другие специалисты… то хреновые специалисты вам попадались.
Выработка общего словаря между условным заказчиком и условным исполнителем — вообще необходимый минимум, для создания хоть сколь нибудь сложной системы.
Для примера: на текущем проекте, нам понадобилось около полугода только для того, чтобы выработать такой словарь.
А вот выработать такой универсальный словарь для всех — на практике, почти не представляется возможным. Это слишком живой язык, и скорость его изменения не позволяет создать учебник, который был бы актуален хотя бы пару лет. Не говоря уже о бесчисленном множестве диалектов.
berez
21.01.2019 10:25Эсперанто, в целом, неплох, но очень скуден – у него очень небольшой вокабуляр, т.е. словарный запас.
Вот взяли и на ровном месте обосрали язык. Словарный запас эсперанто был скуден разве что в самом начале, сразу после создания языка (917 словообразовательных элементов). И то — уже тогда из этих элементов можно было создать многия тысящи слов. В современных словарях эсперанто количество слов — десятки тысяч.
LinearLeopard
21.01.2019 10:38Ложными аналогиями лежит дорога
в адк ложным выводам.
К автомеханику приходят конечные клиенты, и то даже не к нему напрямую, а к человеку, принимающему заказы, он уже может осуществить первичный перевод с пользовательского на автомеханический, к программисту может придти как конечный клиент в виде районной булочной, которая хочет сайт, так и копроративный клиент, который хочет самотрансформирующуюся шатл-субмарину, в первом случае программист не будет грузить булочника выбором CMS, баз данных и хостингов, а во втором, механик, делающий винты на субмарину получит многотысячный текст, описывающий нагрузки, форму, массу, прочность и тысячи других параметров, а также процедуры приёмки готового изделия и неустойки в случае чего.
CombaSoft
21.01.2019 11:04Нужна мотивация, чтобы програмист начал вникать в бизнес процессы. Я бы предложил рассматривать написание подобных систем как инвестиции в бизнес, с которых положено отдавать часть %% от прибыли либо — % от высвобожденных средств.
Например, в случае «Что можно автоматизировать, чтобы сократить количество бухгалтеров?» —
будет ли программист после успешного внедрения написанной им приблуды пожизненно
получать % от заработка этих двух уволенных бухгалтеров? Если вопрос поставить
таким образом, то будет выгодно создавать системы автоматизации в которых
необходимость участия самого программиста будет сведена к минимуму или нулю — тогда
программист будет иметь стимул к написанию множества подобных систем, внедрению их
на разных предприятиях. Когда же таких программистов станет много, то %
выплат от заработка уволенных/переведенных на другие должности будет уменьшаться просто в
следствие конкуренции.
Если же речь идёт про написание подобной системы без подобных отчислений, просто за то, что
чувак сидит на окладе в NN-MM к.р., которые считаются крутым зарабоком в его захолустье и
бизнес пытается продавить написание такой системы, то у программиста появляется стимул
к изучению английского (а он его еще не знал?) и выход на международный рынок, где есть
четкая специализация и четкое разграничение зоны ответственности и влияния. Рынок этот большой
и, даже составляя конкуренцию армии индусов, наши соотечественники будут в более выигрышном
финансовом положении, чем большинство ИТР в местном захолустье — просто в следствии слабого рубля.
Да — звёзд с неба не достанут, но обеспечить себя, свою семью, дать образование своим детям,
решить жилищный вопрос — смогут. По мне так очень хорошо, что есть доступ к внешнему рынку.
В общем, создание подобных систем — вопрос стимула и времени. А что бы не соблазнять бизнес на разного рода хитрости в части отчуждения созданной системы, сделать эту систему в виде облачного сервиса (всё уже придумано до нас). Это же просто: платишь за сервис — он тебе доступен, можешь выгонять пару ненавистных бухгалтеров, не платишь — нет сервиса, привет «табор» бухгалтеров) Конечно, бизнес негативно относится к тому, чтобы передавать информацию куда-то за пределы своего предприятия и это тормозит развитие подобных сервисов.
Oxoron
21.01.2019 11:10greabock выше уже упомянул, я вынесу в отдельный коммент.
Почитайте Domain Driven Development Эванса. Это знаменитая «большая синяя книга» как раз посвящена проблемам коммуникации между заказчиком и командой разработчиков. Передача доменных знаний, выстраивание общего словаря, как органично вписывать бизнес-логику в код.
PavelMSTU
21.01.2019 12:22+1Статья годная. Не понимаю почему её заминусовали…
MKMatriX
21.01.2019 13:50+1По той простой причине, что статья хочет добавить обязанностей таргет группе ресурса. Причем не желанных. Достаточно много людей идет в программисты, поскольку любят программировать, и по жизни они занимаются любимым делом. А тут им хотят добавить в обязанности понимать нужды бизнеса на уровне директора\руководителя\бизнес-аналитика. Еще и не планируя увеличить их зарплату на порядок, а ведь программисту с такими навыками ваш бизнес зачастую не нужен, у него достаточно навыков для поднятия своего.
kinall
21.01.2019 14:45статья хочет добавить обязанностей таргет группе ресурса
Это с одной стороны. А с другой – получается сосредоточение компетенций в одних руках. Если раньше была система из двух человек «аналитик + программист», и любого из них можно было при необходимости почти моментально заменить за N рублей, то теперь это один человек, заменить которого будет стоить уже не 2N рублей, а как минимум 3N, плюс убытки за время простоя (найти и обучить такого человека весьма непросто).
kagarich
21.01.2019 13:55Есть кино «Законопослушный гражданин», где некий человек в самом начале теряет семью во время ограбления. Далее судебная система показывает свою (им)потенцию, наказывая плохишей как-то совсем несерьезно за их преступление.
Как впоследствии оказывается, пострадавший гражданин говорит не только по эльфийски (язык судей и иных персонажей исполнительной системы), эсператно (язык адвокатов и прокуроров) и клингоски (в данном-конкретном случае — язык бандитов, анархистов и само-мотивированных палачей), но владеет магией вуду и языком атлантов. В общем, этот законопослушный гражданин показывает вообще всем вокруг полную кузькину мать, особо циничным образом укокошив всех причастных к неправильной по его мнению интерпретации величины возмездия за совершенные проступки. То есть берет на себя роль Судьи, Прокурора, Адвоката, Полиции, Тюрьмы и иных лиц причастных к приведению наказания в исполнение.
В пример это кино я привел исходя из нескольких постулатов:
— можно овладеть любыми языками, это сложно но возможно, но для этого нужны определенные предпосылки — определенный IQ, сила воли, образование и т.п., то есть совершенно точно, что это не дано условному большинству (а в фильме чувак ну реально какой-то гений);
— можно взять на себя исполнение любых возможных ролей — Судьи, Палача (Аналитика, Архитектора, Программиста) и иже с ними, но для того чтобы своими руками начать делать несвойственную (не ту на которую изначально учился, не ту в которой у тебя максимальный опыт и т.п.) тебе работу — надо быть просто писец каким на это замотивированным, до такой степени, что «если не сделаю, то край совсем»;
— когда человек берет на себя роль "… и швец, и жнец, и на дуде игрец" то он берет на себя и Ответственность, чтобы и кафтан сидел по фигуре, и поле было убрано, и все вокруг были довольны исполненным концертом. Тут важно, что от той самой Ответственности за правильное толкование, за правильную постановку задач, за правильное ее исполнение, развертывание, ПСИ и прочую имплементацию — люди _как_правило_ бегут сломя голову. Те самые БА, Архитекторы, РП и прочие — это не только толмачи, это еще и буфера на которых оседает по кусочку Ответственности на каждом.
Стоимость ошибки в случае передачи большого количества задач из разных областей деятельности на одного человека, или распределения их между коллективом — сильно меньше в случае с коллективом, который в высокой степени саморегулирует друг друга, и помимо этого, еще и митигирует риски, коих в каждом виде деятельности хоть пруд пруди.
lair
21.01.2019 15:11Осталось только правильно организовать этот процесс – обучения программистов эльфийскому языку.
Ну то есть мало программисту одной фул-тайм компетенции (собственно, разработки), ему надо к ней добавить еще одну — бизнес-анализ (а я, кстати, хорошо вижу в жизни, насколько это непростая компетенция). Поскольку чудес не бывает, результатом этого будет падение производительности в первой компетенции.
Ну а дальше мы, собственно, получаем совершенно обычный и понятный выбор: специализация или универсализм. И давно понятно, казалось бы, что единого правильного ответа в этом выборе просто нет.
Gryphon88
21.01.2019 15:41+1В любом процессе на определенном уровне сложности вылезает «переводчик», который связывает потребности заказчика и то, что по факту делает исполнитель. Почему существование прораба и архитектора в строительстве никого не напрягает, а бизнес-аналитик — это вдруг дармоед?
gennayo
21.01.2019 16:01Есть теория, а есть практика суровых Челябинских будней, где до ближайшего грамотного бизнес-аналитика тыщу км и полбюджета проекта…
Gryphon88
21.01.2019 16:05У архитекторов есть портфолио и список тестовых вопросов, которые позволяют различить делающих красиво и делающих комфортно, у бизнес-аналитиков (ну, не было нужды общаться) наверняка тоже есть подобное. Понятное дело, на конференции не скажут «с этим человеком мы просадили вникуда кучу денег», а вот в более приватной обстановке…
michael_vostrikov
21.01.2019 16:48Если бы мастер в автосервисе на такой вопрос сказал что-то вроде «говорите конкретно, что надо сделать с вашей машиной», продолжили бы вы пользоваться его услугами?
Клиент не должен говорить начальнику бригады, что конкретно исправить, а начальник должен сказать всем рабочим кто что конкретно будет делать. Вы должны давать ТЗ подчиненным, а не клиент. И уж тем более ТЗ должен давать конструктор рабочим на заводе при производстве машины.
Zenitchik
21.01.2019 18:48И уж тем более ТЗ должен давать конструктор рабочим на заводе при производстве машины.
Рабочим дают не ТЗ, а операционную карту. И не конструктор, а технолог. А вот конструктор с технологом — получают на вход ТЗ.
dzsysop
21.01.2019 20:29Все вопросы заданные в конце статьи не имеют вообще никакого отношения к ИТ и тем более к программисту как таковому.
Видимо подразумевается некий контекст, но исходя из очень общего взгляда на вещи представленного в статье, все эти вопросы должны быть темой для какой-то планерки или разработки плана стратегии предприятия. Их нужно адресовать самому директору и руководителям подразделений.
Автор видимо подразумевает что руководители подразделений «переводят стрелки» на ИТ отдел и винят в проблемах недостаточную или неверную автоматизацию. Но это, извините, никак не вытекает напрямую из заданных вопросов. А ответы на эти вопросы чаше всего никак не относятся к программисту.
Пытаясь следовать аналогии с автомехаником: вы же не будете его спрашивать как избежать пробок на дороге?
atol
21.01.2019 20:34+1Все эти проблемы с созданием ТЗ уже давно регламентированы ГОСТом.называется «Предпроектное исследование» с формированием Функциональных Требований к проекту на основе которых и создается ТЗ. Ориентировочная цена 10% от стоимости проекта. Все остальное эта попытка бизнеса (и на елку влезть и на ...............) получить блага не затратив денег :)
Mikluho
21.01.2019 21:00+1Вот вам более правильная аналогия программистов и автомехаников: приходит водитель в автосервис и просит сделать так, чтобы его пепелац тратил на 5% меньше тория, а заодно вывести крыс в трюме.
Как уже сказали, автомеханикам не нужен ТЗ, потому как у них уже расписаны все типовые сценарии анализа и починки.
Программисту же чаще приходит нечто неведомой конструкции, пусть даже и собранное из известных материалов и узлов (ох, не всегда...), но без инструкции и чертежей, и заказчик, причитающий «хочу, чтобы мне было хорошо».
Как итог, всякий нестандартный проект разработки (не только ИТ), требует двух «переводчиков»: один переводит мысли заказчика в формализованное изложение, а другой переводит эту формализацию в спецификацию конкретного исполнителя.
Shareef
21.01.2019 22:55+1А где тут Продукт менеджер, Деливери менеджер? В нашем случае, именно они и являются той прослойкой, которая и переводит все. Они, если выражаться в контексте этого поста, полиглоты, которые понимают всех участвующих в процессе.
vadimr
22.01.2019 17:25Автосервис работает по ТЗ (а точнее, как верно было замечено выше, по операционным картам) автопроизводителя.
Что касается вопроса, как при автоматизации сократить двух бухгалтеров, то он настолько идиотский, что его нет нужды куда-либо переводить. Для начала надо понять, что место двух бухгалтеров неизбежно займут три айтишника. Автоматизация может повысить качество продукции, технологичность бизнеса и, в отдельных случаях, даже производительность труда, но она, как и никакая другая бюрократическая реформа, никогда не сокращает общее количество работников.
dyfran
23.01.2019 07:17Надо перестать читать публикации этого автора. Слишком много воды, мысль одна на всю статью, которая повторяется уже чуть ли не в каждой — менеджеры/аналитики г*вно и они никому не нужны, программисты короли, за нами будущее.
Ради интереса автор мог бы взглянуть на ситуацию с другой стороны, а то так до бесконечности можно быть уверенным в своей влажной теории.Zenitchik
23.01.2019 13:15менеджеры/аналитики г*вно и они никому не нужны, программисты короли, за нами будущее.
Странно. А мне показалось, что он пишет «программисты ничего не понимают и должны работать больше».
MKMatriX
Вы очень напутали сравнив программистов с автомеханиками. Дело в том что у автомеханика как ни странно есть очень четкое ТЗ в виде образа идеала. А аналогом просьбы «уволить двух бухгалтеров» будет приезд на самодельном мопеде (конечно использующим водород) и просьбой добавить к нему возможность ездить по воде.
Если у вас есть бизнес задачи, то вам нужен в первую очередь не программист, а тот легендарный менеджер. Ну или школьник с горящими глазами, который вникнет и поймет что то большую часть времени делает один из бухгалтеров можно заменить на коленке написанным скриптом (на практике его решение окажется недостаточно гибким). А уж если вы директор и вроде сами должны отлично знать все узкие места бизнес-процессов, то непонятно почему формирование более-менее точной формулировки задачи вызывает у вас столько проблем. Создается ощущения что от программиста вы ждете понимания бизнес процессов на уровне менеджера, что редко встречается.
nmivan Автор
вы видели таких директоров за пределами малого бизнеса?
MKMatriX
Предполагается масштабируемость, в малой фирме (< 20 человек), директор вполне может знать все процессы. В бОльшем варианте есть руководители отделов (с подруководителями и под… подруководителями). В любом случае все процессы покрываются вниманием, в отделе его руководителем, а между отделами директором и участниками.
Конечно на практике такое встречается не всегда, но писать программы когда этого нет сизифов труд, и просто попытка заменить программой человека.