Как вы соотносите изменения бизнес-процессов с проблемами, связанными с изменением программного обеспечения?

Question

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

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

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

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

Answer 1

Прежде чем вы сможете что-либо сделать, вам лучше отступить назад и попытаться понять суть дела. Если они реагируют на изменения, адаптируя свои процессы, это ХОРОШО. Когда они годами оставляют вещи совершенно одинаковыми, вы можете забыть о том, что они останутся компанией. Однако вы должны убедиться, что изменение, на которое вы реагируете, не окажет негативного влияния на бизнес-процессы, работающие в восходящем или нисходящем направлении. Подразделения не часто делают эту проверку. Но когда все идет к черту, ты знаешь, кого они будут обвинять, верно? Делая это, вы можете устранить эти проблемы и проповедовать «лучшие способы». Не делать это - рецепт вечного разочарования.

Изучите их бизнес, прежде чем даже подумать о его кодификации.

Что касается механики: Мои команды всегда писали «общее программное обеспечение». Некоторому бизнес-подразделению мог понадобиться способ получить форму и создать отчет. Хорошо, достаточно просто, верно? Неправильно. Всегда рассматривайте запрос как нечто * 200. Хотели бы вы поддерживать 200 таких приложений, все из которых почти делают то же самое? Не я. Слишком ленивый.

Я поручил своим командам создать общую систему форм и использовать автономные или общие механизмы отчетности. И я подчеркнул, насколько это возможно, использование XML / XSLT (не полагаясь, например, на технологии Microsoft, позволяющие легко печь, которые, похоже, ломаются с каждым новым выпуском). Затем, когда другое бизнес-подразделение захотело «что-то похожее, но с изменениями», ядро ​​уже было здесь - нам была нужна только новая папка, модифицированный XML / XSLT, и мы закончили.

Это всегда - ВСЕГДА - облегчало обработку будущих изменений. «Нужно новое поле? Изменить XML-файл. Нужно изменить способ создания отчета? Изменить XSLT. Никаких изменений программы». Возьми? НЕТ программных изменений. Держите как можно больше вне логики. Даже бизнес-процессы могут быть представлены в XML / XSLT.

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

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

Answer 2

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

Answer 3

Вы можете посмотреть на

Семь навыков высокоэффективных Люди

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

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

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

Эра еретиков

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

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

Answer 4

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

Если бы у технологов был свой путь, графический интерфейс и мышь / указатель никогда бы не вышли из лаборатории. Для обычных пользователей они здесь, чтобы остаться.

Answer 5

• Когда вы сталкиваетесь с возрастающей сложностью бизнес-правил по отношению к текущей форме программного обеспечения, попробуйте рассмотреть вариант Aspect-Oriented-Software-Development , чтобы добиться лучшей модульности и разделения проблем. Таким образом, новые или изменяющиеся бизнес-правила, как они появляются, могут быть интегрированы в существующую кодовую базу в виде подключаемых модулей только к тем модулям, которые в них нуждаются, при этом нет необходимости переписывать большие объемы несвязанного кода.
• Идея состоит в том, что, в конце концов, многие бизнес-правила основаны на конкретном законодательстве, и ответственность за их внедрение и адаптацию несет бизнес, передаваемый также программному обеспечению. Я лично считаю, что отсутствие воли следовать спецификациям из-за предполагаемой трудности - это то, что заставляет большинство веб-браузеров более или менее отставать от веб-стандартов - изменение правил было временным обходным решением, которое со временем привело к гораздо большей накопленной стоимости за счет поддержки специфические особенности каждого браузера. Старайтесь внедрять новые бизнес-правила так быстро, как они появляются или меняются - если этого не сделать, это приведет к нехватке поддержки новых функций и в конечном итоге сделает ваше программное обеспечение устаревшим.

Answer 6

К сожалению, это полностью зависит от ситуации.

Даже имея большой опыт в бизнесе и программном обеспечении, это все еще сложная проблема.

Насколько ваши конкретные вопросы:

1. Как только ты их увидишь. Что важно, так это сформулировать ваше предложение в конструктивной форме. Также используются термины, относящиеся к бизнесу (ROI, NPV и т. Д.). И поиск дополнительных выгод (). Таким образом, если изменение программного обеспечения действительно не смягчает бизнес-проблему, затраты высоки, а исправление бизнес-процесса приводит к значительной экономии вспомогательных затрат, вы представляете совершенно другой сценарий, чем просто говорите: «Мы не можем сделать это, потому что это стоит слишком дорого». ».

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

Answer 7

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

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