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


11

Я был разработчиком некоторое время. Я далеко не лучший там. (Сидя в одиночестве в этой комнате, я задаюсь вопросом, а не лучше ли я здесь?) Однако я пришел к пониманию своих инструментов и поверил в свою способность рассуждать и учиться.

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

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

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


3
Это очень хороший вопрос для обсуждения с другими программистами, но, к сожалению, он не по теме для этого сайта вопросов и ответов: он слишком широкий (о нем можно многое сказать) и в первую очередь основывается на мнениях (разные люди скажут вам по-разному) вещи, по сути, что работает для них ... как вы собираетесь выбрать «правильный» ответ?).
Андрес Ф.

Ответы:


4

Для меня это путем чтения и понимания кодовых баз.

Я говорю это по двум ключевым причинам:

  1. Люди сосут. О, не намеренно (обычно), но в бизнесе я обнаружил, что люди часто немного различают понимание бизнес-правил. И у каждого есть своя ментальная модель, которая в свою очередь теряет верность, пытаясь донести ее до вас. Но код не лжет. Люди могут думать, что они хотят о том, как все должно работать, но код верен.

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


2
Ваш подход звучит немного как курица и яйцо.
Роберт Харви

@RobertHarvey Можете ли вы объяснить, что вы подразумеваете под «курицей и яйцом»?
Falgantil

3
@ BjarkeSøgaard: вы пишете код для понимания бизнес-правил, не понимая сначала бизнес-правил, чтобы вы могли написать соответствующий код. Смотрите также Цыпленок и Яйцо, если вы спрашиваете, что означает эта идиома.
Роберт Харви

Чтобы было ясно, я сосредоточен на чтении кода в первую очередь.
Теластин

1
@Telastyn Иногда код неполный или неправильный - или вообще отсутствует. Мне пришлось писать код для недокументированных бизнес-процессов - либо как новую функцию, либо как новую систему. Кроме того, часто код не является всеобъемлющим, когда речь идет о бизнес-правилах - код для системы инвентаризации может показать вам, как работает процесс, но не обязательно, почему процесс определяется так, как он есть. Я считаю, что знание того, почему что-то работает и почему это делается, всегда приводит к лучшим решениям.
lunchmeat317

3

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

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

  1. Планируйте свое время и уважайте их, но получайте как можно больше.
  2. Вам нужно будет задать вопросы. Они не думают, как программисты, все ломают и полностью понимают, как информация связана друг с другом.
  3. Не притворяйся, как понимаешь. Если бы вы знали столько же, сколько другие деловые люди, они бы заставили вас выполнять обе работы. Смотрите № 2.
  4. Не ожидайте документации. Предложите много похвал, если вы когда-либо получите.
  5. Держись подальше от критики. Процессы и процедуры могут иметь избыточность и другие потенциальные недостатки, но может быть причина для этого. Узнайте, почему, но не удивляйтесь, когда говорят: «Мы всегда так делали».
  6. Будьте вежливы, добры и поделитесь своими закусками. Ты имеешь дело с людьми. Скажи привет. Спросите, как у них дела. Спросите о том, почему они вошли в индустрию, как долго они работают в компании.

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


Я действительно должен работать над # 5 ..... Я постараюсь запомнить это.
lunchmeat317

№ 5 абсолютно огромный. Я работаю в аптеке. Может возникнуть вопрос: «Я не знал, что компьютер может это сделать» или «Если мы не будем следовать этому, люди могут умереть ». В этом ключе, никогда, никогда не говорите «почему бы вам не просто », потому что «просто» будет часто показывать ваше незнание сложности данного взаимодействия.
Алан Шутко

3

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

Вот несколько интересных моментов из книги:

Овладеть основами

Если вы не знаете основ, вы будете строить свое понимание на шаткой основе. Поэтому вам нужно задавать эти глупые вопросы, которые никто не задает.

Пусть ошибки будут вашим руководством

Иногда это помогает задавать вопросы, которые явно неправильны, чтобы вы могли обнаружить свое непонимание. (Пример: Вы имеете в виду, что администраторы имеют доступ к каждому документу? О. Почему?)

Научите или объясните это другим

Когда вы попытаетесь научить кого-то этому, вы начнете раскрывать, где у вас проблемы с пониманием.

Надеюсь, это поможет!


0

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

Как я начал это решать?

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

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

Это привело меня к вопросам и сомнениям. Я печатаю каждого из них и, наконец, назначаю встречу с тем, кто может разрешить мои сомнения.

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

Обучение> Сомнения> Вопросы> Ответы> Понимание (повторять цикл снова и снова)

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.