개발자가 비즈니스 영역을 이해해야합니까, 아니면 사양이 충분해야합니까?

전자 분야의 첨단 기술이기 때문에 도메인을 이해하기 어려운 회사에서 일하고 있지만 복잡한 도메인의 모든 소프트웨어 개발에 적용 할 수 있습니다.

내가 작업하는 응용 프로그램에는 도메인에 대한 경험이 없으면 이해하기 어려운 많은 정보, 차트 및 메트릭이 표시됩니다. 개발자는 사양을 사용하여 특정 차트에 이러한 종류의 메트릭이 표시되도록 지정하고이 메트릭은 다음과 같은 산술 공식과 같이 소프트웨어가 수행해야하는 작업을 설명합니다.

이런 식으로 개발자는 비즈니스를 이해하지 못하고이 작업을 수행하는 이유 / 이유를 이해합니다. 사양이 실제로 상세하지만 사양이 정확하지 않거나 작성자가 유스 케이스를 잊어 버린 경우 개발자가 솔루션을 찾기가 매우 어렵습니다.

반면, 모든 개발자에게 모든 비즈니스 측면에 대한 교육은 매우 길고 어려울 수 있습니다.

우리가 세부 사양을 더 중요하게 생각해야 하는가 (그러나 우리가 알고 있듯이 완벽한 사양은 존재하지 않음) 모든 개발자가 비즈니스 영역을 이해하도록 훈련시켜야합니까?

편집 : 회사가 외부 개발자를 사용할 수 있으며 모든 도메인을 형성하는 데 약 2 주가 걸릴 수 있다는 귀하의 답변을 명심하십시오.

사양은 사실상 충분하지 않습니다. 도메인 지식이없는 개발자는 사양에 오류가있는 시점 (대부분의 경우가 자주 발생 함)을 지적하고 설계를 잘못 선택할 수 없습니다.

내 경험에 따르면, 지금 3 가지 매우 다른 산업에서 일한 후에는 도메인에 대해 많이 알지 못하지만 결국 학습해야하며 누군가는이를 자세히 이해해야합니다.

근본적인 문제는 클라이언트 개발자의 임피던스에 달려 있습니다. 그들은 무언가를 원하지만 그것을 볼 때만 알고 문제를 해결하려고하지만 항상 그 문제가 무엇인지 명확하게 알 수는 없습니다. 고객 (개발자)이 가져올 수있는 (클라이언트) 산업에 대한 도메인 지식이 많을수록 모호한 "원인"을 구체적인 "문제"로 쉽게 변환하고 해결할 수 있습니다.

일화적인 예로서, 저의 이전 직업은 플랜트 관리 소프트웨어와 관련된 화학 산업에있었습니다. 도메인에 대한 지식은 사실상 제로로 시작했지만 선임 개발자와 고객이 나에게 제시 한 하위 문제를 해결하는 데 필요한 코드를 구현할 수있었습니다. 시간이 지남에 따라, 나는 고객의 수준에서보다 쉽게 ​​의사 소통 할 수 있도록 업계를 배우려고 노력했습니다. 그들의 산업을 이해하면서 실제 문제가 무엇인지 이해하기 시작했습니다. "이 모듈의 모든 데이터 값을 추적해야합니다"와 같은 내용을 말할 때 실제로 의미하는 바, 즉 "이 센서가 생성하는 각 값의 기록을 X 일 동안 저장해야합니다. 유지하지만 항상 해당 센서의 최신 측정 값을 기준으로 평가됩니다. "

예, 도메인 문제는 코드 문제가 아니고 둘 사이의 번역이 사소하지 않기 때문에 누군가 도메인 지식이 필요하며 개발자가 필요합니다. 결국 팀을 유지할 가치가있는 개발자는 도메인을 선택해야 코드의 뉘앙스에 대해보다 많은 정보를 선택할 수 있습니다.

프로젝트의 누군가는 상당히 완전한 도메인 지식을 가지고 있어야합니다. 그 사람은 개발자 일 수도 있고 아닐 수도 있습니다.

애자일 프로젝트에서 클라이언트 프로젝트 소유자는 그 사람이며 팀과 협력하고 긴밀하게 협력하고 있습니다. 민첩하지 않은 프로젝트에서 팀의 누군가는 그 지식을 습득해야하지만 일반적으로 그렇지 않습니다. 이것이 민첩하지 않은 프로젝트가 실패하기 쉬운 이유입니다.

훌륭한 답변이 많이 있습니다. 나는 그것들을 읽고 검색 한 후에 아무도 핵심 문제에 대해 언급하지 않았기 때문에 내 자신을 추가합니다 : bugs .

충분한 권한과 도메인 전문 지식을 갖춘 충분한 인력을 팀에 제공하지 않으면 조만간 버그가 발생할 수밖에 없습니다. 도메인에 대한 지식이 있으면 불가능하거나 의미가없는 가치 / 결과 / 관계가 있습니다. 사양이 명시 적으로 지적하기를 희망 할 수 있지만 실제로는 도달 할 수있는 최선의 방법은 가장 명백한 것을 피하는 것입니다 (금리가 마이너스가되거나 그와 같은 것이 있으면 저를 경고하십시오-이것은 오류 일 수도 있고 아닐 수도 있지만 주목할 정도로 이상합니다).

이것은 선택의 이유를 이해하는 것과 밀접한 관련이 있으며, 가장 좋은 경우에는 요청의 이유를 실제로 알고 있으면 주어진 것으로 받아들이지 않고 생각할 수 있기 때문에 더 나은 소프트웨어로 연결됩니다. ).

아인슈타인은 "하지만 공식과 사상은 모든 물리 이론의 시작이라고 생각 한다 " 는 점을 기억하십시오. 즉 , 그것은 추상 공식과 아이디어가 아니라 생각입니다.

영어 만 아는 사람과 일본어 만 아는 사람을 한 방에두면 각 언어의 전문가 임에도 불구하고 일본어를 영어로 번역 할 수 없습니다. 같은 이유로, 도메인 지식이없는 전문가 프로그래머조차도 소프트웨어 개발 전문가가 아닌 최고의 도메인 전문가에게 연중 무휴 액세스 할 수있는 경우에도 구축해야 할 사항을 파악할 수 없습니다.

스펙은 도메인 요구 사항의 "일본어"를 프로그래밍 요구 사항의 "영어"로 변환하려는 시도입니다. Google 번역의 번역 품질과 비슷한 번역 품질을 얻을 수 있다면 행운의 날입니다. 대부분의 시간, 품질은 그냥이있다, 그래서 당신은 적어도 취득 주위에 방법이 없다 일부 도메인 지식을. 일부 지속성이 있으면 프로젝트가 끝날 때까지 "번역가"가되어 회사에 대한 가치가 크게 높아집니다. 대부분의 경우 프로세스에서 많은 즐거움을 얻으므로 상생의 상황입니다.

비즈니스 지식의 일부가 없다면, 질문을하지 않고 스펙의 내용을 무의식적으로 코딩하는 개발자가됩니다. 키보드를 사용할 수있는 사람뿐만 아니라 좋은 소프트웨어를 만들기 위해서는 "Thinkers"가 필요하다고 생각합니다. "무엇을하고 있는지"뿐만 아니라 "왜"를 이해하고 더 큰 그림에 어떻게 맞는지 이해하면 개발 팀에 더 큰 만족을 줄 수 있습니다.

도메인 지식을 얻으려고 노력해야한다고 생각합니다. 사양은 최종 제품이 무엇을해야하며 제품의 유효성을 검사하는 데 필요한 검사 목록입니다. 개발자는 항상 해결하려는 실제 문제가 무엇인지 이해하려고 노력해야합니다 . 도메인 지식을 얻으면 이해하는 데 도움이됩니다.

변경되는 부분 (예 : 규칙 세트)을 이해하고 개별적으로 배치 할 때 쉽게 디자인하고 코딩하는 데 도움이됩니다. 마스터 일 필요는 없지만 최종 사용자와 그들의 언어로 대화 할 수 있습니다 .

기본적인 지식으로 자동차를 운전할 수 있습니다. 그러나 타기를 즐기고 싶다면 정확하게 사용하는 방법에 대해 더 많이 알아야합니다. 다른 거래와 마찬가지로 도메인을 이해하는 것이 필수는 아니지만 그렇게 할 때 재미 있습니다 .

비즈니스를 아는 개발자는 금의 무게가 가치가 있다고 생각합니다.

비즈니스에 일부 요구 사항이 있고 일부 비즈니스 분석가가 해당 요구 사항을 기술 요구 사항으로 변환 하는 "전통적인"시나리오에서 개발자는 필연적으로 두 가지 발생할 수있는 작업을 수행합니다.

1. 여러 실패 지점이 있습니다. 비즈니스 분석가가 모든 비즈니스 요구 사항을 완벽하게 번역하지 않았거나 개발자가이를 기술 사양으로 완벽하게 번역하지 않았을 수 있습니다. "방 주위의 비밀"시나리오에 대한 변형. 의사 소통의 긴급 성.

2. 비즈니스 소유자, 비즈니스 분석가 또는 개발자 중 하나 또는 모두가 조직에서 일반적으로 생각하지 않는 핵심 항목을 놓치기에 충분히 새롭습니다. 비즈니스를 잘 알고있는 노련한 개발자는 다른 역할을 담당하는 사람들을 교육하여 제품을보다 완벽하게 만들 수 있습니다.

사양에서 각 기능의 가치, 사양을 얼마나 가치있게 구현해야 하는가, 사양 기능의 조합을 충족시키는 비용 사이에는 거의 항상 상충 관계가 있습니다. 위의 모든 작업에 대한 지식이 한 사람 또는 실제 소프트웨어 아키텍트 및 / 또는 코더를 포함하여 긴밀하게 작업하는 팀에 존재하는 경우에만 좋은 절충이 이루어질 수 있습니다.

그러한 극도로 현지화 된 지식과 어쩌면 감정이 없으면 결과는 서면 사양에 매우 부합하는 거의 비용이 거의 쓸모없는 제품으로 쉽게 끝날 수 있습니다.

위의 문제가없는 사양을 만드는 데 드는 비용은 건축가 및 / 또는 코더가 덜 상세한 사양으로 작업하기에 충분한 도메인 지식을 갖도록 교육하는 것보다 더 클 수 있습니다 (법률 및 비즈니스 계약에서 허용한다고 가정).

예, 개발자는 비즈니스를 어느 정도 알고 있어야합니다. 매 순간 세부 사항을 알 필요는 없지만 X 보고서의 용도와 비즈니스 프로세스에서 보고서 X가 어떻게 사용되는지에 대한 기본적인 이해가 필요합니다. 개발자가 비즈니스에 대해 이해하면할수록 더 나은 솔루션을 제공 할 수 있습니다.

내 경험에 비추어 볼 때, 문제 영역에 대한 지식과 소프트웨어 개발에 대한 지식이 풍부한 개인은 문제 영역에 대한 우수한 지식과 지식에 대한 지식을 갖춘 두 사람보다 문제에 대한 최적의 솔루션을 찾을 가능성이 높습니다 소프트웨어 개발, 협력.

개인의 두뇌에서 일어나는 의사 소통이 개인 간의 의사 소통보다 몇 배 빠르고 빠르다는 단순한 사실에 기인한다고 생각합니다.

*이 질문에 대답하기 위해 내가 그리는 주요 경험은 회계 소프트웨어 패키지를 개발하는 데 10 년 이상 (시작부터 '유지 관리 모드'까지)입니다. 동료들에 비해 소프트웨어 개발에 대한 지식은 꽤 좋았지 만 문제 영역에 대한 이해 부족으로 종종 장애를 느꼈습니다.

거래의 기본을 배우는 데 관심이 거의없는 개발자와 함께 일하는 비즈니스 측면에서 누군가가 대답하고 싶습니다. 때로는 그 기본에 대해 알 필요가 없다는 것을 자랑스럽게 생각합니다. 개발자는 세부적인 테스트 사례 (최근까지 개발하지 않은) 또는 결과의 지속적인 감독이 필요한 결과를 한눈에 볼 수 없습니다 (불확실한 결과, 잘못된 부호 등). 의사 소통을 쉽게하기 위해 소프트웨어 개발의 기초를 배우고 자하는만큼 개발자들도 그렇게하도록 촉구하고 싶습니다.

그럴 필요는 없지만 왜 원하지 않습니까?

나는 꺼리고 특히 어느 정도 도메인을 배울 수없는 프로그래머에 대해 걱정할 것이다. "아이보리 코드 타워"에서 한 번에 나가는 것이 중요합니다.

어떻게 사용되는지, 어떤 목적으로 끔찍한 일처럼 들리지도 모릅니다. 성당을 지을 때 벽돌을 깨고 싶은 사람은 누구입니까?

개발자가 참여할수록 비즈니스에 더 많이 관여할수록 적어도 중간 수준의 도메인 지식을 보유하는 것이 중요해 지거나 중요 할 수있는 해당 산업의 미묘한 영역을 개발자 팀이 이해하지 못할 것입니다.

그러나 하위 수준의 작업에는 사양이 충분해야합니다. 요컨대, 인력을 더 낮은 수준으로 훈련시키는 것이 가장 좋습니다. 그들은 세계 최고의 폴리 글 로트 프로그래머 일지 모르지만 문제를 상당히 깊이 이해할 수 없다면 항상 실패 또는 죽음의 행진 프로그래밍에 파멸됩니다.

항상 일부 사양 이 있어야합니다. 모든 개발자가 도메인 전문가가 될 것으로 기대할 수는 없습니다. 동시에 개발자가 사양을 실제로 이해하지 않고 맹목적으로 맹목적으로 따르면 결과는 실제로 고객이 원하는 것이 아닐 수도 있습니다. 개발자가 다소 괜찮은 수준이지만 (전문가는 아님) 이해 수준이 높으면 사양에서 오류와 누락을 발견 할 수 있습니다. 또한 최종 제품을 훨씬 향상시킬 수있는 프로세스에 기여하고 피드백을 제공 할 수 있습니다.

클라이언트와 개발자 사이에 연락하여 개발자에게 더 나은 이해를 제공하고 사양을 작성하는 데 도움이되는 일부 도메인 전문가를 고용하는 것이 좋습니다.

어느 쪽이든 대답하기가 어렵다고 생각합니다.

예를 들어, 프리랜서 개발자가 개발하는 모든 단일 응용 프로그램의 비즈니스 (또는 과학)를 어떻게 이해할 수 있는지 알기가 어렵습니다. 이 상황에서 개발자가 비즈니스 자체를 실제로 이해하는 것보다 사양 또는 비즈니스 모델에 대한 올바른 질문을하는 것이 더 중요하다고 생각합니다.

반면에 같은 기간 동안 동일한 비즈니스에 종사하고 있다고 가정하는 기업 개발자는 실제로 몇 개월 (또는 아마도 몇 년) 후에 비즈니스가 어떻게 작동하는지 배워야합니다. 대규모 팀에서는 개발자보다 비즈니스를보다 명확하게 이해하는 건축가가있을 수도 있습니다.

고독한 개발자가있는 SME에서는 개발자가 잘못된 일을 피하고 이행하지 않도록 소유자 / 관리자와 자주 논의하는 것이 중요합니다.

따라서 이것에 대해 생각할 수있는 방법이 많이 있지만, 열쇠는 모든 경우에 동일합니다 : 의사 소통 .

소프트웨어 개발은 ​​내가 아는 유일한 직업으로, 자신의 직업에 능숙 할뿐만 아니라 현재 일하고있는 직업에 대한 기본적인 이해가 필요합니다. 클라이언트 언어의 다른 개발자. 개발자는 항상 다른 사람에게 당신을 훈련시킬 수는 없습니다. 때로는 개인적인 연구, 종종 일반적인 근무 시간 이외의 시간에 스스로 연구해야합니다.

우리는 관광 산업의 회사로서 동일한 문제에 직면했기 때문에 여기서 의미하는 바를 정말로 이해합니다. 저는 주니어 개발자 였을 때 대학에서 관광을 공부하고있었습니다. 그래서, 당신은 내가 컴퓨터 과학 배경에서 오지 않고 있지만 내 관광 지식은 높다고 추측 할 수 있습니다.

당시 다른 소프트웨어 회사와 관련하여 제품을 개발하고 있었지만 도메인 별 지식은 많이 부족했습니다. 설명했듯이, 교차 절단 문제 등이 많기 때문에 관광 산업에서 제품을 제작하는 경우 올바르게 얻는 것이 실제로 어렵습니다.

따라서이 운동은 장기적으로 많은 나쁜 결과를 낳았습니다. 그런 다음 우리는 큰 발전을 이루었고 프로젝트의 비즈니스 부분보다는 개발에만 초점을 맞추기 시작했습니다. 산업 지식과 프로그래밍 지식이 있으면 프로젝트가 그 어느 때보 다 효율적으로 성장합니다. 말할 것도없이, 동전의 양면에 대한 경험이 있기 때문에 더 빨리 결정을 내릴 수 있습니다.

귀하의 질문에 대한 구체적인 답변으로, 그것은 내 개인적인 견해로는 분명히 그렇습니다. 팀이 진행중인 프로젝트가 장기 프로젝트 인 경우 어려운 길을 가고 직원에게 도메인 별 기본 사항과 세부 사항을 교육하십시오.

개발자가 오랜 기간 동안 회사 / 산업에 머무르면 느리지 만 확실하게 "비즈니스"를 배우게됩니다.

일부 회사는 "사업"에 대한 교육을 인정하고 제공합니다. 금융 회사가 이에 대한 좋은 예입니다.

비즈니스를 많이 배울수록 사용자와 더 쉽게 대화 할 수 있습니다. 그들은 당신에 대해 더 많은 자신감을 느낄 것입니다. 시스템이 사용자에게 예상대로 작동하지 않으면 시스템이 잘못 될 수있는 문제를보다 쉽게 ​​이해할 수 있습니다.

귀하의 질문에 대답하기 위해, 사양은 결코 내 경험으로는 충분하지 않습니다. 일반적인 문제는 정보가 충분하지 않아서 빨리 최신 정보를 얻을 수 없다는 것입니다.

일부 회사에서는 비즈니스 영역에 대한 경험이 필수적 일 수 있습니다. 그들은 고용 할 때 도메인에 경험이있는 개발자를 찾습니다. 일부 회사는 이것을 실제 기술 기술보다 높게 설정하기도합니다. (영국에서는 확실히 재정적 경험이나 인터뷰가없는 것이 일반적입니다).

개인 경험을 바탕으로, 팀 지식이있는 팀원과 함께 일하는 한 사양이 충분합니다.

저는 매우 전문화 된 산업에서 일하고 있습니다. 방송 미디어 용 소프트웨어를 만듭니다. 나는 방송에 대해 거의 알지 못하지만 코드와 데이터를 알고 있으며 프로젝트 관리 팀에 방송을 이해하는 좋은 사람들이 있습니다. 그 공식은 지난 몇 년 동안 클라이언트가 좋아하는 좋은 기능을 생각해 내기에 충분했습니다.