프로그래머로서 비즈니스 규칙에 대한 채택과 이해를 빠르게하려면 어떻게해야합니까?

나는 한동안 개발자였다. 나는 거기서 최고가 아닙니다. (이 방에 혼자 앉아있을 때, 나는 여기에서도 최고가 될지 궁금하다.) 그러나 나는 나의 도구를 이해하게되었고, 나는 추론하고 배우는 나의 능력을 신뢰하게되었다.

새로운 직업을 시작할 때, 나는 내가 알고있는 언어라면 코드베이스를 배울 수 있다고 항상 믿는다. 그것이 내가 아는 언어 나 틀이 아니라면, 나는 그것을 배우기에 충분한 개념을 파악할 수 있다고 생각합니다. 이것은 프로그래머로서 우리의 스킬 셋의 일부이며이 표준을 준수 할 수 있다는 것을 자랑스럽게 생각합니다.

그럼에도 불구하고, 나의 주요 약점 중 하나는 내가 유급 직원이든 계약자이든 관계없이 내가 일하고있는 고객을 위해 비즈니스 규칙을 배우고 내면화하는 것입니다. 코드베이스에는 문제가 없지만 특정 비즈니스에 대한 비즈니스 규칙과 프로세스는 항상 완전히 이해하는 데 시간이 걸리는 것 같습니다. 예를 들어 엔터프라이즈 응용 프로그램을 다시 작성할 때이 문제가 발생할 수 있습니다.

개발자로서 비즈니스 규칙과 프로세스를 빠르고 효율적으로 동화하는 가장 좋은 방법은 무엇입니까? 주제 전문가가 아니거나 고객, 회사 또는 비즈니스에 대한 수년간의 경험이없는 것이 가능합니까?

저에게는 코드베이스를 읽고 이해하는 것입니다.

나는 두 가지 주요 이유 때문에 다음과 같이 말합니다.

1. 사람들은 빨다. 오, 고의적으로 (보통), 사업에서는 사람들이 종종 사업 규칙에 대한 이해가 미묘하게 다르다는 것을 알았습니다. 그리고 모든 사람들은 자신의 정신 모델을 가지고 있으며, 그들은 당신에게 그것을 전달하려고 할 때 충실도를 잃습니다. 그러나 코드는 거짓말하지 않습니다. 사람들은 일을하는 방법에 대해 원하는 것을 생각할 수있는 가정 일에,하지만 코드는 권리입니다.

2. 먼저 기초를 구축하십시오. 모든 사람이 이러한 비즈니스 별 용어 및 프로세스가 무엇인지에 대한 자신의 정신 모델을 가지고 있다면 어떻게 구축합니까? 저에게는 많은 프로그래머가 필요하기 때문에 코드에서 최고의 정신 모델을 구축합니다. 코드에는 패턴이 있습니다. 코드에는 추상화가 있습니다. 코드를 작성하고 그로부터 정신 모델을 구축하는 데 많은 경험이 있습니다. 나는 상황이 존재하는 것을 적어도 막연한 모양을 가지고 그들이 어떻게 관련되는지, 일단 다음 나는 사업 사람들에게 이야기 할 수 있습니다. 그런 다음 올바른 질문을하고 그들의 대답을 퍼즐에 더 잘 맞출 수 있습니다.

너무 열심히하지 마십시오. 때때로 그들은 왜 그들이 "비즈니스 규칙"이라고 부르는 지 궁금해하지만, "적용하는 다른 일이 없다면 다르게 행동하지 않는 한 우리가 일반적으로하는 방식"이라고 부르는 것 같습니다. 사업은 지저분합니다. 고객, 법률 기관, 회계, 규정, 공급 업체, 직원, 관리자 및 지방 정부의 요구를 해결합니다. 그들은 항상 이유가 없습니다.

최선의 방법은 가능한 많은 비즈니스 사람들과 시간을 보내는 것입니다. 기술적 인 위치에있는 일부 사람들에게는 어려울 수 있습니다.

1. 시간을 정하고 그들의 시간을 존중하되 최대한 많은 것을 얻으십시오.
2. 질문을해야합니다. 그들은 프로그래머처럼 생각하지 않고 모든 것을 분해하고 정보가 서로 어떻게 관련되어 있는지 완전히 이해합니다.
3. 당신이 이해하는 것처럼 가짜하지 마십시오. 다른 사업 사람들만큼 많이 알고 있다면 두 가지 일을 모두 할 수 있습니다. # 2를 참조하십시오.
4. 문서를 기대하지 마십시오. 혹시라도 칭찬을 많이 받으십시오.
5. 비판을 미루십시오. 프로세스와 절차에는 중복성과 다른 잠재적 인 효율성이있을 수 있지만 그 이유가있을 수 있습니다. "우리는 항상 그렇게했습니다."라고 말할 때 충격을받지 마십시오.
6. 정중하고 친절하며 간식을 나누십시오. 당신은 사람들을 다루고 있습니다. 인사하세요. 그들이 어떻게 지내고 있는지 물어보십시오. 그들이 왜 업계에 들어 왔는지, 회사에 얼마나 오래 있었는지 물어보십시오.

당신은 프로그래머라고 불리는 공허가 아니며, 당신은 사람입니다. 그들이 당신의 일을 더 쉽게하기 위해 거기에 있다는 것을 알려주십시오. 불행히도, 당신은 영웅이나 염소가 될 수 있습니다. 우리 사업의 본질입니다.

Edward Burger와 Michael P. Starbird의 효과적인 사고의 5 가지 요소라는 책을 읽는 것이 좋습니다. 일반적으로 새로운 개념을 이해하는 것과 관련이 있지만이 상황에 적용되는 것 같습니다.

이 책의 흥미로운 점은 다음과 같습니다.

기본 사항 익히기

기초를 모른다면 흔들리는 기초에 대한 이해를 쌓게 될 것입니다. 따라서 아무도 묻지 않는 바보 같은 소리의 질문을해야합니다.

오류를 가이드로 삼으십시오

때로는 명확하지 않은 질문을하는 데 도움이되므로 이해 부족을 발견 할 수 있습니다. (예 : 관리자가 모든 문서에 액세스 할 수 있다는 의미입니까? 왜 그렇습니까?)

다른 사람들에게 가르치거나 설명하십시오

다른 사람에게 가르치려고 할 때 이해하기 어려운 부분을 발견하기 시작합니다.

희망이 도움이됩니다!

개발자로서 나는 비즈니스를 코드, 데이터 구조, 가능한 클래스 등으로 직접 변환한다는 것을 깨달았습니다. 나는 추상적이고 종종 정의되지 않은 무언가, "모양"을 가진 무언가로 이동합니다. 나는 즉시 코딩을 시작하고 정보가 부족 하여 자주 리팩터링을합니다. 모든 리 팩터는 비즈니스에 대한 이해에 너무 많은 차이가 있다고 생각합니다 .

이 문제를 어떻게 해결하기 시작 했습니까?

나는 기능 분석과 초기 단계에서 작성된 모든 문서를 스스로 읽도록 강요합니다. 나는 고객 또는 최종 사용자로서 그것을하려고합니다 . 이러한 응용 프로그램 및 요구 사항으로 고객이 무엇을 찾고 있는지 이해해야합니다. 그러나 나는 내가있는 개발자로부터 떨어져 있어야합니다.

우리의 직업은 고객에게없는 훌륭한 기술을 제공합니다. 우리는 조건부 구조에서 다른 사람들이하지 않는 방식으로 생각합니다. 그래서 요구 사항에 직면하기 시작합니다. 모순 또는 불일치 찾기 . 내가 이해 한 것에 대해 약간의 뇌가 쏟아졌다. 가상 시나리오 공식화.

그것은 질문과 의심으로 이어집니다. 나는 그들 모두를 타이핑하고 마침내 내 의심을 해결할 수있는 사람과 회의를했다.

요약하면 관점이 바뀝니다. 다른 관점에서 문제를 보려고합니다. 그러나 나는 그 과정에 일부 개발자의 기술을 썼습니다. 해결해야 할 많은 질문과 의심으로 끝나는 것. 일단 해결되면 사업에 대한 나의 이해가 깊어집니다.

학습> 의심> 질문> 답변> 이해 (반복 반복)