Comments 47
Вы очень напутали сравнив программистов с автомеханиками. Дело в том что у автомеханика как ни странно есть очень четкое ТЗ в виде образа идеала. А аналогом просьбы «уволить двух бухгалтеров» будет приезд на самодельном мопеде (конечно использующим водород) и просьбой добавить к нему возможность ездить по воде.
Если у вас есть бизнес задачи, то вам нужен в первую очередь не программист, а тот легендарный менеджер. Ну или школьник с горящими глазами, который вникнет и поймет что то большую часть времени делает один из бухгалтеров можно заменить на коленке написанным скриптом (на практике его решение окажется недостаточно гибким). А уж если вы директор и вроде сами должны отлично знать все узкие места бизнес-процессов, то непонятно почему формирование более-менее точной формулировки задачи вызывает у вас столько проблем. Создается ощущения что от программиста вы ждете понимания бизнес процессов на уровне менеджера, что редко встречается.
Если у вас есть бизнес задачи, то вам нужен в первую очередь не программист, а тот легендарный менеджер. Ну или школьник с горящими глазами, который вникнет и поймет что то большую часть времени делает один из бухгалтеров можно заменить на коленке написанным скриптом (на практике его решение окажется недостаточно гибким). А уж если вы директор и вроде сами должны отлично знать все узкие места бизнес-процессов, то непонятно почему формирование более-менее точной формулировки задачи вызывает у вас столько проблем. Создается ощущения что от программиста вы ждете понимания бизнес процессов на уровне менеджера, что редко встречается.
А уж если вы директор и вроде сами должны отлично знать все узкие места бизнес-процессов,
вы видели таких директоров за пределами малого бизнеса?
Предполагается масштабируемость, в малой фирме (< 20 человек), директор вполне может знать все процессы. В бОльшем варианте есть руководители отделов (с подруководителями и под… подруководителями). В любом случае все процессы покрываются вниманием, в отделе его руководителем, а между отделами директором и участниками.
Конечно на практике такое встречается не всегда, но писать программы когда этого нет сизифов труд, и просто попытка заменить программой человека.
Конечно на практике такое встречается не всегда, но писать программы когда этого нет сизифов труд, и просто попытка заменить программой человека.
Детский сад какой то!
Уже лет 50 как появилась такая специальность –аналитик. В сложных и больших проектах системах есть аналитик от IT и аналитик о бизнеса. А для очень сложных систем есть еще системный архитектор. Для длительных проектов вводится менеджер проекта.
Так же ни кто не запрещает программисту для примера купить книжку «Бухучет» или «Современные методики выращивания гидропонных культур». Так и бухгалтеру не плохо прочитать что то типа «Основа баз данных» или «Администрирование компьютерных сетей». Хотя это все есть «изучения клингонского языка», но первый абзац ни кто не отменял.
P.S. И товарищи программисты, если вы ощущаете себя инженерами, то будьте Инженерами! Настоящий инженер это такой товарищЪ у которого так называемый кругозор или по модному soft skills это как минимум половина инженера!
Уже лет 50 как появилась такая специальность –аналитик. В сложных и больших проектах системах есть аналитик от IT и аналитик о бизнеса. А для очень сложных систем есть еще системный архитектор. Для длительных проектов вводится менеджер проекта.
Так же ни кто не запрещает программисту для примера купить книжку «Бухучет» или «Современные методики выращивания гидропонных культур». Так и бухгалтеру не плохо прочитать что то типа «Основа баз данных» или «Администрирование компьютерных сетей». Хотя это все есть «изучения клингонского языка», но первый абзац ни кто не отменял.
P.S. И товарищи программисты, если вы ощущаете себя инженерами, то будьте Инженерами! Настоящий инженер это такой товарищЪ у которого так называемый кругозор или по модному soft skills это как минимум половина инженера!
В сложных и больших проектах системах есть аналитик от IT и аналитик о бизнеса. А для очень сложных систем есть еще системный архитектор. Для длительных проектов вводится менеджер проекта.
итого, три чувака, необходимость которых очевидна только им самим?
И тем, кто хочет решить проблему, а не сделать вид что решает.
Если бизнесу с большими IT проектами не очевидна необходимость в таких людях — то это такой себе бизнес. Нормальные программисты вряд ли там будут задерживаться, соответственно, качество IT продукта будет не очень. А это скорее всего будет вести к убыткам.
То есть вы предлагаете добавить к должности разработчика еще и анализ и перевод бизнес-требований на технический язык? А не треснет ли?
Когда бизнесу надо фичу, которая на бумаге выглядит раз-два и готово, и нужно её уже вчера, а в текущей информационной системе для её реализации требуется неделя. Бизнес-аналитикам платят за то, чтобы держать бизнес-контекст в голове и накладывать его на информационную систему с её ограничениями за приемлимое время с приемлимым качеством.
Вот только упускается один момент — перекладывая эту деятельность на плечи разработчика его зарплата не увеличивается. Смешение компетенций пока не выигрывает в молотилове технологий и подходов в IT. Я считаю что компетенция в бизнес-аналитике для разработчика это приятный бонус для бизнеса, но платить за это отдельно пока не хотят. Не отрицаю, что есть окружения, где разработчики широкого профиля получают достаточно, но лично мне пока бывать там не доводилось.
Когда бизнесу надо фичу, которая на бумаге выглядит раз-два и готово, и нужно её уже вчера, а в текущей информационной системе для её реализации требуется неделя. Бизнес-аналитикам платят за то, чтобы держать бизнес-контекст в голове и накладывать его на информационную систему с её ограничениями за приемлимое время с приемлимым качеством.
Вот только упускается один момент — перекладывая эту деятельность на плечи разработчика его зарплата не увеличивается. Смешение компетенций пока не выигрывает в молотилове технологий и подходов в IT. Я считаю что компетенция в бизнес-аналитике для разработчика это приятный бонус для бизнеса, но платить за это отдельно пока не хотят. Не отрицаю, что есть окружения, где разработчики широкого профиля получают достаточно, но лично мне пока бывать там не доводилось.
Есть маленькая проблема — у среднего российского бизнеса, о котором статья, обычно нет денег на компетентных бизнес-аналитиков.
Бизнес-аналитикам платят за то, чтобы держать бизнес-контекст в голове и накладывать его на информационную систему с её ограничениями за приемлимое время с приемлимым качеством.
они справляются?
В разделе «Упражнения» — не эльфийский. Это язык Эллочки-людоедки.
Посыл статьи "Каждая кухарка Каждый программист должен быть и программистом и CFO одновременно" непонятен. Зачем это надо? Просто из-за того, что руководству жалко денег на бизнес-аналитика?
Посыл статьи "
а там, где есть бизнес-аналитики, все хорошо? Работает этот метод? Решаются проблемы бизнеса?
Лучше, чем там, где их нет. Проблемы решаются быстрее (без аналитика, имеющего общую структуру действительо масштабного проекта, всё происходит дольше (куча согласований точка-точка, которые часто дают неверный/неполный результат)).
Заодно, и выгонит горе-переводчиков, вроде бизнес-аналитиков.
Поздравляю, бизнес ограничил возможности соих проектов (большой не поятнут, возьмут — надорвутся и на штрафники влетят), а накладные расходы повысил очень сильно. Вот это и будет результатом, который декларативно важен, но на самом деле нет.
Брат, толмачами с бизнес-языка на ТЗ для разработчиков кормится целая плеяда аналитиков (и ваш покорный в их числе).
Проблемы могут быть только у заказчиков, которые не забюджетировали адекватных денег на нашу работу.
Проблемы могут быть только у заказчиков, которые не забюджетировали адекватных денег на нашу работу.
Адекватных денег?!
Ну да, берите бюджет разработки, умножайте на 0.1
ну да, в статье так и написано: «Бизнес, оценив преимущества, сделает двуязычных программистов стандартом в своей компании. Заодно, и выгонит горе-переводчиков, вроде бизнес-аналитиков.»
Если у вас даже на горе-БА нет грошей, как вы собрались нанимать чудо-единорогов, двуязычных разработчиков (котоыре наверняка у вас и в тесты могут, и поменеджерить, и сейлзам помочь продукт продавать)?
Работать в нашей компании большая честь? )
Работать в нашей компании большая честь? )
Думаю, важнее результат, чем параметры — сколько там БА или программистов.
Была компания, тратившая на БА, внутренних и внешних, порядка 1 млн. в месяц. Толку — ноль. Им что делать? Других БА искать? Или побольше нанять?
Была компания, тратившая на БА, внутренних и внешних, порядка 1 млн. в месяц. Толку — ноль. Им что делать? Других БА искать? Или побольше нанять?
Если вы тратитие 1кк в мес на БА без результатов, то надо искать причины не в БА, а в руководстве, инфа сотка.
Даже за 400-500 в месяц (т.е. белые 200-300 на руки) на рынке РФ масса достойных кандидатов. За 1кк пока что можно целый дрим тим собрать.
Даже за 400-500 в месяц (т.е. белые 200-300 на руки) на рынке РФ масса достойных кандидатов. За 1кк пока что можно целый дрим тим собрать.
я Аналитик, согласен и с основной мыслью статьи и про «паразитов»:
Фокус в том что, двуязычные Программеры стоят гораздо дороже, чем Аналитик.
И как правило, такие Программеры очень быстро становятся «Директорами по Развитию» и т.д.
Могут быть разные модели: «с Аналитиком» или «Двуязычные Программеры»
И они могут быть одинаково эффективны в каждом отдельном случаи со своей спецификой и т.д.
Главное что бы выбор той или иной модели был осознанным и управляемым, что не отменяет возможности смешанного варианта, и изменения во времени.
Если вы тратитие 1кк в мес на БА без результатов, то надо искать причины не в БА, а в руководстве, инфа сотка.
Фокус в том что, двуязычные Программеры стоят гораздо дороже, чем Аналитик.
И как правило, такие Программеры очень быстро становятся «Директорами по Развитию» и т.д.
Могут быть разные модели: «с Аналитиком» или «Двуязычные Программеры»
И они могут быть одинаково эффективны в каждом отдельном случаи со своей спецификой и т.д.
Главное что бы выбор той или иной модели был осознанным и управляемым, что не отменяет возможности смешанного варианта, и изменения во времени.
Эх. Слишком заинтриговал заголовок, думал хотя бы мелкое описание каждого из языков будет или что-нибудь в их стиле написано, а прочитал — опять про экскаватор и лопаты(кто не в теме, была такая аллегория, что заказчик просит огромную лопату не зная о возможности создать экскаватор).
Так можно написать про любую инженерную специальность. Например: решила конторка зарабатывать на запуске космических ракет, а для этого, оказывается, нужен космодром. Приходят, значит, они к строителям и говорят на своем эльфийском: «хочу, короче, дом такой, чтобы из него ракеты вылетали!». Ну и попробуй реши такую вот эльфийскую проблему.
Если поразмыслить, как может представитель бизнеса – директор, руководитель отдела, продавец, бухгалтер и т.д. – составить техническое задание на разработку программного продукта?
Эм… по ГОСТ'у например. Его потому и придумали.
Между бизнесом и программистами есть граница – языковой барьер. Бизнес не понимает языка информационных систем, программисты не понимают языка бизнеса. Чтобы хоть как-то существовать, и хоть чего-то делать, обе стороны изобрели суррогатный язык – некий аналог эсперанто, одинаково понятного и непонятного обеим сторонам.
Вам нужно почитать Эванса. В своей "большой синей книге", он подробно излагает, как правильно вырабатывать такой словарь.
Было бы здорово, конечно, если бы программисты создали отторгаемую систему, на которую бизнес посмотрел бы со стороны, и принял решение – брать или не брать.
Вы не поверите, но программисты ежедневно занимаются созданием таких систем. Так работают все SaaS решения.
Вообще, необходимость выработки общего языка давно известна. Это касается не только бизнеса, но и любого процесса который возникает необходимость автоматизировать. Вся первая часть книги "Предметно ориентированное проектирование" Эванса, посвящена именно этой проблеме. И любой, более-менее толковый специалист в области анализа и проектирования систем, прочитал ее хотя бы однажды. Если же вам попадались другие специалисты… то хреновые специалисты вам попадались.
Выработка общего словаря между условным заказчиком и условным исполнителем — вообще необходимый минимум, для создания хоть сколь нибудь сложной системы.
Для примера: на текущем проекте, нам понадобилось около полугода только для того, чтобы выработать такой словарь.
А вот выработать такой универсальный словарь для всех — на практике, почти не представляется возможным. Это слишком живой язык, и скорость его изменения не позволяет создать учебник, который был бы актуален хотя бы пару лет. Не говоря уже о бесчисленном множестве диалектов.
Эсперанто, в целом, неплох, но очень скуден – у него очень небольшой вокабуляр, т.е. словарный запас.
Вот взяли и на ровном месте обосрали язык. Словарный запас эсперанто был скуден разве что в самом начале, сразу после создания языка (917 словообразовательных элементов). И то — уже тогда из этих элементов можно было создать многия тысящи слов. В современных словарях эсперанто количество слов — десятки тысяч.
Ложными аналогиями лежит дорога в ад к ложным выводам.
К автомеханику приходят конечные клиенты, и то даже не к нему напрямую, а к человеку, принимающему заказы, он уже может осуществить первичный перевод с пользовательского на автомеханический, к программисту может придти как конечный клиент в виде районной булочной, которая хочет сайт, так и копроративный клиент, который хочет самотрансформирующуюся шатл-субмарину, в первом случае программист не будет грузить булочника выбором CMS, баз данных и хостингов, а во втором, механик, делающий винты на субмарину получит многотысячный текст, описывающий нагрузки, форму, массу, прочность и тысячи других параметров, а также процедуры приёмки готового изделия и неустойки в случае чего.
К автомеханику приходят конечные клиенты, и то даже не к нему напрямую, а к человеку, принимающему заказы, он уже может осуществить первичный перевод с пользовательского на автомеханический, к программисту может придти как конечный клиент в виде районной булочной, которая хочет сайт, так и копроративный клиент, который хочет самотрансформирующуюся шатл-субмарину, в первом случае программист не будет грузить булочника выбором CMS, баз данных и хостингов, а во втором, механик, делающий винты на субмарину получит многотысячный текст, описывающий нагрузки, форму, массу, прочность и тысячи других параметров, а также процедуры приёмки готового изделия и неустойки в случае чего.
Нужна мотивация, чтобы програмист начал вникать в бизнес процессы. Я бы предложил рассматривать написание подобных систем как инвестиции в бизнес, с которых положено отдавать часть %% от прибыли либо — % от высвобожденных средств.
Например, в случае «Что можно автоматизировать, чтобы сократить количество бухгалтеров?» —
будет ли программист после успешного внедрения написанной им приблуды пожизненно
получать % от заработка этих двух уволенных бухгалтеров? Если вопрос поставить
таким образом, то будет выгодно создавать системы автоматизации в которых
необходимость участия самого программиста будет сведена к минимуму или нулю — тогда
программист будет иметь стимул к написанию множества подобных систем, внедрению их
на разных предприятиях. Когда же таких программистов станет много, то %
выплат от заработка уволенных/переведенных на другие должности будет уменьшаться просто в
следствие конкуренции.
Если же речь идёт про написание подобной системы без подобных отчислений, просто за то, что
чувак сидит на окладе в NN-MM к.р., которые считаются крутым зарабоком в его захолустье и
бизнес пытается продавить написание такой системы, то у программиста появляется стимул
к изучению английского (а он его еще не знал?) и выход на международный рынок, где есть
четкая специализация и четкое разграничение зоны ответственности и влияния. Рынок этот большой
и, даже составляя конкуренцию армии индусов, наши соотечественники будут в более выигрышном
финансовом положении, чем большинство ИТР в местном захолустье — просто в следствии слабого рубля.
Да — звёзд с неба не достанут, но обеспечить себя, свою семью, дать образование своим детям,
решить жилищный вопрос — смогут. По мне так очень хорошо, что есть доступ к внешнему рынку.
В общем, создание подобных систем — вопрос стимула и времени. А что бы не соблазнять бизнес на разного рода хитрости в части отчуждения созданной системы, сделать эту систему в виде облачного сервиса (всё уже придумано до нас). Это же просто: платишь за сервис — он тебе доступен, можешь выгонять пару ненавистных бухгалтеров, не платишь — нет сервиса, привет «табор» бухгалтеров) Конечно, бизнес негативно относится к тому, чтобы передавать информацию куда-то за пределы своего предприятия и это тормозит развитие подобных сервисов.
Например, в случае «Что можно автоматизировать, чтобы сократить количество бухгалтеров?» —
будет ли программист после успешного внедрения написанной им приблуды пожизненно
получать % от заработка этих двух уволенных бухгалтеров? Если вопрос поставить
таким образом, то будет выгодно создавать системы автоматизации в которых
необходимость участия самого программиста будет сведена к минимуму или нулю — тогда
программист будет иметь стимул к написанию множества подобных систем, внедрению их
на разных предприятиях. Когда же таких программистов станет много, то %
выплат от заработка уволенных/переведенных на другие должности будет уменьшаться просто в
следствие конкуренции.
Если же речь идёт про написание подобной системы без подобных отчислений, просто за то, что
чувак сидит на окладе в NN-MM к.р., которые считаются крутым зарабоком в его захолустье и
бизнес пытается продавить написание такой системы, то у программиста появляется стимул
к изучению английского (а он его еще не знал?) и выход на международный рынок, где есть
четкая специализация и четкое разграничение зоны ответственности и влияния. Рынок этот большой
и, даже составляя конкуренцию армии индусов, наши соотечественники будут в более выигрышном
финансовом положении, чем большинство ИТР в местном захолустье — просто в следствии слабого рубля.
Да — звёзд с неба не достанут, но обеспечить себя, свою семью, дать образование своим детям,
решить жилищный вопрос — смогут. По мне так очень хорошо, что есть доступ к внешнему рынку.
В общем, создание подобных систем — вопрос стимула и времени. А что бы не соблазнять бизнес на разного рода хитрости в части отчуждения созданной системы, сделать эту систему в виде облачного сервиса (всё уже придумано до нас). Это же просто: платишь за сервис — он тебе доступен, можешь выгонять пару ненавистных бухгалтеров, не платишь — нет сервиса, привет «табор» бухгалтеров) Конечно, бизнес негативно относится к тому, чтобы передавать информацию куда-то за пределы своего предприятия и это тормозит развитие подобных сервисов.
greabock выше уже упомянул, я вынесу в отдельный коммент.
Почитайте Domain Driven Development Эванса. Это знаменитая «большая синяя книга» как раз посвящена проблемам коммуникации между заказчиком и командой разработчиков. Передача доменных знаний, выстраивание общего словаря, как органично вписывать бизнес-логику в код.
Почитайте Domain Driven Development Эванса. Это знаменитая «большая синяя книга» как раз посвящена проблемам коммуникации между заказчиком и командой разработчиков. Передача доменных знаний, выстраивание общего словаря, как органично вписывать бизнес-логику в код.
Статья годная. Не понимаю почему её заминусовали…
По той простой причине, что статья хочет добавить обязанностей таргет группе ресурса. Причем не желанных. Достаточно много людей идет в программисты, поскольку любят программировать, и по жизни они занимаются любимым делом. А тут им хотят добавить в обязанности понимать нужды бизнеса на уровне директора\руководителя\бизнес-аналитика. Еще и не планируя увеличить их зарплату на порядок, а ведь программисту с такими навыками ваш бизнес зачастую не нужен, у него достаточно навыков для поднятия своего.
статья хочет добавить обязанностей таргет группе ресурса
Это с одной стороны. А с другой – получается сосредоточение компетенций в одних руках. Если раньше была система из двух человек «аналитик + программист», и любого из них можно было при необходимости почти моментально заменить за N рублей, то теперь это один человек, заменить которого будет стоить уже не 2N рублей, а как минимум 3N, плюс убытки за время простоя (найти и обучить такого человека весьма непросто).
Есть кино «Законопослушный гражданин», где некий человек в самом начале теряет семью во время ограбления. Далее судебная система показывает свою (им)потенцию, наказывая плохишей как-то совсем несерьезно за их преступление.
Как впоследствии оказывается, пострадавший гражданин говорит не только по эльфийски (язык судей и иных персонажей исполнительной системы), эсператно (язык адвокатов и прокуроров) и клингоски (в данном-конкретном случае — язык бандитов, анархистов и само-мотивированных палачей), но владеет магией вуду и языком атлантов. В общем, этот законопослушный гражданин показывает вообще всем вокруг полную кузькину мать, особо циничным образом укокошив всех причастных к неправильной по его мнению интерпретации величины возмездия за совершенные проступки. То есть берет на себя роль Судьи, Прокурора, Адвоката, Полиции, Тюрьмы и иных лиц причастных к приведению наказания в исполнение.
В пример это кино я привел исходя из нескольких постулатов:
— можно овладеть любыми языками, это сложно но возможно, но для этого нужны определенные предпосылки — определенный IQ, сила воли, образование и т.п., то есть совершенно точно, что это не дано условному большинству (а в фильме чувак ну реально какой-то гений);
— можно взять на себя исполнение любых возможных ролей — Судьи, Палача (Аналитика, Архитектора, Программиста) и иже с ними, но для того чтобы своими руками начать делать несвойственную (не ту на которую изначально учился, не ту в которой у тебя максимальный опыт и т.п.) тебе работу — надо быть просто писец каким на это замотивированным, до такой степени, что «если не сделаю, то край совсем»;
— когда человек берет на себя роль "… и швец, и жнец, и на дуде игрец" то он берет на себя и Ответственность, чтобы и кафтан сидел по фигуре, и поле было убрано, и все вокруг были довольны исполненным концертом. Тут важно, что от той самой Ответственности за правильное толкование, за правильную постановку задач, за правильное ее исполнение, развертывание, ПСИ и прочую имплементацию — люди _как_правило_ бегут сломя голову. Те самые БА, Архитекторы, РП и прочие — это не только толмачи, это еще и буфера на которых оседает по кусочку Ответственности на каждом.
Стоимость ошибки в случае передачи большого количества задач из разных областей деятельности на одного человека, или распределения их между коллективом — сильно меньше в случае с коллективом, который в высокой степени саморегулирует друг друга, и помимо этого, еще и митигирует риски, коих в каждом виде деятельности хоть пруд пруди.
Как впоследствии оказывается, пострадавший гражданин говорит не только по эльфийски (язык судей и иных персонажей исполнительной системы), эсператно (язык адвокатов и прокуроров) и клингоски (в данном-конкретном случае — язык бандитов, анархистов и само-мотивированных палачей), но владеет магией вуду и языком атлантов. В общем, этот законопослушный гражданин показывает вообще всем вокруг полную кузькину мать, особо циничным образом укокошив всех причастных к неправильной по его мнению интерпретации величины возмездия за совершенные проступки. То есть берет на себя роль Судьи, Прокурора, Адвоката, Полиции, Тюрьмы и иных лиц причастных к приведению наказания в исполнение.
В пример это кино я привел исходя из нескольких постулатов:
— можно овладеть любыми языками, это сложно но возможно, но для этого нужны определенные предпосылки — определенный IQ, сила воли, образование и т.п., то есть совершенно точно, что это не дано условному большинству (а в фильме чувак ну реально какой-то гений);
— можно взять на себя исполнение любых возможных ролей — Судьи, Палача (Аналитика, Архитектора, Программиста) и иже с ними, но для того чтобы своими руками начать делать несвойственную (не ту на которую изначально учился, не ту в которой у тебя максимальный опыт и т.п.) тебе работу — надо быть просто писец каким на это замотивированным, до такой степени, что «если не сделаю, то край совсем»;
— когда человек берет на себя роль "… и швец, и жнец, и на дуде игрец" то он берет на себя и Ответственность, чтобы и кафтан сидел по фигуре, и поле было убрано, и все вокруг были довольны исполненным концертом. Тут важно, что от той самой Ответственности за правильное толкование, за правильную постановку задач, за правильное ее исполнение, развертывание, ПСИ и прочую имплементацию — люди _как_правило_ бегут сломя голову. Те самые БА, Архитекторы, РП и прочие — это не только толмачи, это еще и буфера на которых оседает по кусочку Ответственности на каждом.
Стоимость ошибки в случае передачи большого количества задач из разных областей деятельности на одного человека, или распределения их между коллективом — сильно меньше в случае с коллективом, который в высокой степени саморегулирует друг друга, и помимо этого, еще и митигирует риски, коих в каждом виде деятельности хоть пруд пруди.
Осталось только правильно организовать этот процесс – обучения программистов эльфийскому языку.
Ну то есть мало программисту одной фул-тайм компетенции (собственно, разработки), ему надо к ней добавить еще одну — бизнес-анализ (а я, кстати, хорошо вижу в жизни, насколько это непростая компетенция). Поскольку чудес не бывает, результатом этого будет падение производительности в первой компетенции.
Ну а дальше мы, собственно, получаем совершенно обычный и понятный выбор: специализация или универсализм. И давно понятно, казалось бы, что единого правильного ответа в этом выборе просто нет.
В любом процессе на определенном уровне сложности вылезает «переводчик», который связывает потребности заказчика и то, что по факту делает исполнитель. Почему существование прораба и архитектора в строительстве никого не напрягает, а бизнес-аналитик — это вдруг дармоед?
Был бы автор строителем – он бы архитектора в дармоеды записывал)
Есть теория, а есть практика суровых Челябинских будней, где до ближайшего грамотного бизнес-аналитика тыщу км и полбюджета проекта…
У архитекторов есть портфолио и список тестовых вопросов, которые позволяют различить делающих красиво и делающих комфортно, у бизнес-аналитиков (ну, не было нужды общаться) наверняка тоже есть подобное. Понятное дело, на конференции не скажут «с этим человеком мы просадили вникуда кучу денег», а вот в более приватной обстановке…
Если бы мастер в автосервисе на такой вопрос сказал что-то вроде «говорите конкретно, что надо сделать с вашей машиной», продолжили бы вы пользоваться его услугами?
Клиент не должен говорить начальнику бригады, что конкретно исправить, а начальник должен сказать всем рабочим кто что конкретно будет делать. Вы должны давать ТЗ подчиненным, а не клиент. И уж тем более ТЗ должен давать конструктор рабочим на заводе при производстве машины.
Все вопросы заданные в конце статьи не имеют вообще никакого отношения к ИТ и тем более к программисту как таковому.
Видимо подразумевается некий контекст, но исходя из очень общего взгляда на вещи представленного в статье, все эти вопросы должны быть темой для какой-то планерки или разработки плана стратегии предприятия. Их нужно адресовать самому директору и руководителям подразделений.
Автор видимо подразумевает что руководители подразделений «переводят стрелки» на ИТ отдел и винят в проблемах недостаточную или неверную автоматизацию. Но это, извините, никак не вытекает напрямую из заданных вопросов. А ответы на эти вопросы чаше всего никак не относятся к программисту.
Пытаясь следовать аналогии с автомехаником: вы же не будете его спрашивать как избежать пробок на дороге?
Видимо подразумевается некий контекст, но исходя из очень общего взгляда на вещи представленного в статье, все эти вопросы должны быть темой для какой-то планерки или разработки плана стратегии предприятия. Их нужно адресовать самому директору и руководителям подразделений.
Автор видимо подразумевает что руководители подразделений «переводят стрелки» на ИТ отдел и винят в проблемах недостаточную или неверную автоматизацию. Но это, извините, никак не вытекает напрямую из заданных вопросов. А ответы на эти вопросы чаше всего никак не относятся к программисту.
Пытаясь следовать аналогии с автомехаником: вы же не будете его спрашивать как избежать пробок на дороге?
Все эти проблемы с созданием ТЗ уже давно регламентированы ГОСТом.называется «Предпроектное исследование» с формированием Функциональных Требований к проекту на основе которых и создается ТЗ. Ориентировочная цена 10% от стоимости проекта. Все остальное эта попытка бизнеса (и на елку влезть и на ...............) получить блага не затратив денег :)
Вот вам более правильная аналогия программистов и автомехаников: приходит водитель в автосервис и просит сделать так, чтобы его пепелац тратил на 5% меньше тория, а заодно вывести крыс в трюме.
Как уже сказали, автомеханикам не нужен ТЗ, потому как у них уже расписаны все типовые сценарии анализа и починки.
Программисту же чаще приходит нечто неведомой конструкции, пусть даже и собранное из известных материалов и узлов (ох, не всегда...), но без инструкции и чертежей, и заказчик, причитающий «хочу, чтобы мне было хорошо».
Как итог, всякий нестандартный проект разработки (не только ИТ), требует двух «переводчиков»: один переводит мысли заказчика в формализованное изложение, а другой переводит эту формализацию в спецификацию конкретного исполнителя.
Как уже сказали, автомеханикам не нужен ТЗ, потому как у них уже расписаны все типовые сценарии анализа и починки.
Программисту же чаще приходит нечто неведомой конструкции, пусть даже и собранное из известных материалов и узлов (ох, не всегда...), но без инструкции и чертежей, и заказчик, причитающий «хочу, чтобы мне было хорошо».
Как итог, всякий нестандартный проект разработки (не только ИТ), требует двух «переводчиков»: один переводит мысли заказчика в формализованное изложение, а другой переводит эту формализацию в спецификацию конкретного исполнителя.
А где тут Продукт менеджер, Деливери менеджер? В нашем случае, именно они и являются той прослойкой, которая и переводит все. Они, если выражаться в контексте этого поста, полиглоты, которые понимают всех участвующих в процессе.
Автосервис работает по ТЗ (а точнее, как верно было замечено выше, по операционным картам) автопроизводителя.
Что касается вопроса, как при автоматизации сократить двух бухгалтеров, то он настолько идиотский, что его нет нужды куда-либо переводить. Для начала надо понять, что место двух бухгалтеров неизбежно займут три айтишника. Автоматизация может повысить качество продукции, технологичность бизнеса и, в отдельных случаях, даже производительность труда, но она, как и никакая другая бюрократическая реформа, никогда не сокращает общее количество работников.
Что касается вопроса, как при автоматизации сократить двух бухгалтеров, то он настолько идиотский, что его нет нужды куда-либо переводить. Для начала надо понять, что место двух бухгалтеров неизбежно займут три айтишника. Автоматизация может повысить качество продукции, технологичность бизнеса и, в отдельных случаях, даже производительность труда, но она, как и никакая другая бюрократическая реформа, никогда не сокращает общее количество работников.
UFO just landed and posted this here
Если и проводить аналогию оптимизаторов бизнес-процессов с автомеханиками, то это будут автомеханики одной из конюшен Формулы 1. Вы можете себе представить, что механики команды Феррари пригоняют болид в уличный автосервис? Дают ТЗ в виде: «Машина едет 355 км/ч на максимуме, сделайте так, чтобы ехала 380 км/ч, мы тогда всех конкурентов уделаем», автосервис кивает головой, и на следующее утро отдаёт машину, уже отвечающую заданным характеристикам. Нелепо, правда?
Дело в том, что бизнес — это не те, кто «ездят на автомобиле». Это люди, которые автомобилем управляют, кто автомобиль ремонтирует, кто продумывает его конструкцию, и их задача в том, чтобы автомобиль ездил быстрее всех на рынке, был самым надёжным и при этом жрал по минимум топлива и соответствовал всем техническим ограничениям. И если уличный автосервис за одну ночь и за 30 тысяч рублей может сделать машину лучше, чем команда механиков за 10 лет и за 150 миллионов долларов, то что эти механики делают в «конюшне» Формулы 1?
Бизнес иногда может обращаться на аутсорс для решения узких экспертных задач. Например, в случае с механиками Формулы 1 «конюшня» может обратиться в инженерную фирму с задачей: «Мы хотим перейти с толстостенных топливных трубок на тонкостенные. Но мы такую задачу сами решить не можем, трубки взрываются. Мы готовы заплатить 30 миллионов долларов, если вы сделаете нам надёжные трубки, которые будут на 20% легче существующих». Но инвестор не может прийти в автосервис с задачей «Вот вам миллиард долларов, сделайте мне болид по всем характеристикам превосходящий Феррари». Не сделают. Потому что те, кто умеет делать лучший в мире болид Ф1, уже работают в Феррари.
Бизнес ценен только своими конкурентными преимуществами. Они бывают разные: у кого-то это связи собственника «наверху», через которые бизнес получает многомиллиардные госзаказы, у кого-то это огромный завод, по мутным схемам полученным в 90-е годы, и приносящий теперь гигантские прибыли, у кого-то это огромная доля рынка, которую фиг отожмёшь без гигантских инвестиций, которые сделают весь проект заведомо убыточным, у кого-то неповторимая система менеджмента организации, у кого-то сразу несколько таких конкурентных преимуществ. Но ключевое слово здесь — _своими_ конкурентными преимуществами. Свой собственник с нужными связями, свой завод, своя доля рынка и так далее. Вы не можете построить бизнес, просто собрав его из чужих кирпичиков. Вам эти кирпичики обойдутся заведомо дороже, чем они могут впоследствии принести прибыли. Потому что если у кого есть такой кирпичик, курица, несущая золотые яйца, то зачем он будет продавать его вам дешевле, чем стоят яйца, которые этот кирпичик приносит?
Дело в том, что бизнес — это не те, кто «ездят на автомобиле». Это люди, которые автомобилем управляют, кто автомобиль ремонтирует, кто продумывает его конструкцию, и их задача в том, чтобы автомобиль ездил быстрее всех на рынке, был самым надёжным и при этом жрал по минимум топлива и соответствовал всем техническим ограничениям. И если уличный автосервис за одну ночь и за 30 тысяч рублей может сделать машину лучше, чем команда механиков за 10 лет и за 150 миллионов долларов, то что эти механики делают в «конюшне» Формулы 1?
Бизнес иногда может обращаться на аутсорс для решения узких экспертных задач. Например, в случае с механиками Формулы 1 «конюшня» может обратиться в инженерную фирму с задачей: «Мы хотим перейти с толстостенных топливных трубок на тонкостенные. Но мы такую задачу сами решить не можем, трубки взрываются. Мы готовы заплатить 30 миллионов долларов, если вы сделаете нам надёжные трубки, которые будут на 20% легче существующих». Но инвестор не может прийти в автосервис с задачей «Вот вам миллиард долларов, сделайте мне болид по всем характеристикам превосходящий Феррари». Не сделают. Потому что те, кто умеет делать лучший в мире болид Ф1, уже работают в Феррари.
Бизнес ценен только своими конкурентными преимуществами. Они бывают разные: у кого-то это связи собственника «наверху», через которые бизнес получает многомиллиардные госзаказы, у кого-то это огромный завод, по мутным схемам полученным в 90-е годы, и приносящий теперь гигантские прибыли, у кого-то это огромная доля рынка, которую фиг отожмёшь без гигантских инвестиций, которые сделают весь проект заведомо убыточным, у кого-то неповторимая система менеджмента организации, у кого-то сразу несколько таких конкурентных преимуществ. Но ключевое слово здесь — _своими_ конкурентными преимуществами. Свой собственник с нужными связями, свой завод, своя доля рынка и так далее. Вы не можете построить бизнес, просто собрав его из чужих кирпичиков. Вам эти кирпичики обойдутся заведомо дороже, чем они могут впоследствии принести прибыли. Потому что если у кого есть такой кирпичик, курица, несущая золотые яйца, то зачем он будет продавать его вам дешевле, чем стоят яйца, которые этот кирпичик приносит?
Sign up to leave a comment.
Эсперанто, эльфийский и клингонский