프로그래머가 아닌 사람에게 프로젝트 복잡성을 설명하는 좋은 은유가 있습니까?
내가 "정확히 시스 티나 예배당을 짓지 않는다"는 말이 들렸다. 이것은 사실이지만, 나는화물 관리 애플리케이션을 구축하고 있는데, 이것은 폼에 컨트롤을 그리는 것만 큼 간단하지 않다 (벤더가 당신이 그렇게 믿게 할지라도).
나는 그것을 말한 사람에 대해 이것을 견지하지 않지만 내가하는 일의 복잡성이 약간 오해되거나 그 진술이 이루어지지 않았을 것이라고 생각합니다.
프로그래머가 아닌 사람에게 프로젝트의 복잡성을 설명 할 수있는 좋은 은유가 있습니까?
몇 가지 은유 ...
복잡성 측면에서는 마치 처음부터 혼자서 자동차 또는 보트를 만드는 것과 같습니다 . 엔지니어 팀 이 필요한 소프트웨어 프로젝트 는 우주 왕복선을 만드는 것과 같습니다 . 유일한 차이점은 당신이 일을 더럽 히면 사람들은 보통 죽지 않는다는 것입니다. 사람들의 생명이 위태 롭다면 우주 왕복선과 더 비슷합니다. (소프트웨어는 거의 로켓 선만큼 멋지지 않습니다.)
그것은 (? 무엇을) 소프트웨어 프로젝트는 시스 티나 성당없는 것은 사실이다, 그러나 그것은 이다 종류 자체가 매우 복잡화물 관리 시스템을 구축하는 등. 화이트 보드에 몇 가지 다이어그램을 그리거나 시스템 설계 및 데이터 흐름 다이어그램을 가지고 다닐 수 있습니다. 그들이 볼 수 있도록 도와주세요.
" 컴퓨터를 만든 적이 있습니까?"라고 질문하십시오. 모든 구성 요소 선택 및 주문, 컴퓨터 구축, 운영 소프트웨어, 장치 드라이버 선택 및 설치, 최종 결과 구성은 모두이화물 관리 프로젝트보다 시간이 덜 걸리고 훨씬 덜 복잡합니다.
그들이하는 일과 연관시키는 것에 대한 조언은 좋지만 적절한 비유 를하기 위해 그들이하는 일에 대해 충분히 이해해야 합니다. 숙련 된 정비사이고 기화기 (자동 변속기 대신)를 재건하는 것과 비슷하다고 말하면 "좋아요. 그리 복잡하지 않습니다."라고 생각할 수 있습니다.
Neil Ernst는 소프트웨어 은유에 대해 약간 , 가정 계약 은유의 적용 가능성에 대해 이야기 하고 소프트웨어 엔지니어링이 추상적 인 작업 이기 때문에 본질적으로 설명 하기 어렵다는 점을 지적합니다 .
닐 짐 왈도에 의해 에세이에 대한 링크 소프트웨어 엔지니어링 및 디자인의 예술 그가 지적하는,
이런 식으로 우리가 소프트웨어 엔지니어링이라고 부르는 것은 다른 종류의 엔지니어링보다 건축 (건물을 생산하는 실제 건축)에 가깝습니다. 과학의 요소 (건물은 물리학의 법칙을 따라야 함)가 있지만 예술의 큰 요소도 있습니다. 어떤 종류의 소프트웨어를 제작 하느냐에 따라 두 가지의 혼합이 약간 다를 수 있지만 항상 혼합이 있습니다.
따라서 아마도 웅장한 건축 및 건축 업적은 적절한 은유입니다. (우리가하는 일이 시스 티나 예배당에 가까워지는 것이 아니라 그것을 염두에두고 우리가하는 일에 접근해야합니다.)
불행히도 당신의 프로젝트를 사소하다고 일축하는 사람은 이것을 이해하지 못할 것입니다. 그들은 그것을 얻기에 충분히 추상적으로 생각하지 못할 수도 있습니다 . 당신이 바랄 수있는 최선의 방법은 그들이 자동차 나 보트 또는 집의 비유를 이해하거나 다이어그램 으로 볼 수 있도록 도와주는 것 입니다.
편집 : 프로젝트와 "폼에 컨트롤 그리기"간의 상대적 복잡성에 대해 지적했습니다. 아마도 시스 티나 예배당 발언에 "그건 사실입니다.하지만 3 개월 웹 프로젝트가 집 뒤에있는 작은 창고라면이화물 관리 시스템은 Rogers Center 입니다.
연사는 거의 확실히 " 시스 티나 예배당 [천장] 그림 "을 의미했습니다 . 의미있는 유사점이 있습니까?
미켈란젤로는 원래 건축가가 제안한 비계에 몇 가지 문제가있었습니다. 그는 결국 자신의 틀을 구축했습니다.
미켈란젤로는 조각가 였고 그는 의뢰를 완료하기 위해 프레스코 화를 배워야했습니다.
교황 줄리어스 2 세는 원래 12 개의 사도 그림을 원했습니다. 미켈란젤로는 주제를 자유롭게 선택하고 300 개가 넘는 인물을 묘사 한 구약 성경 장면을 전달했습니다. 그는 모든 그림을 직접 그렸습니다.
프로젝트는 계속해서 돈이 부족했습니다 (교황이 주변 국가들과 계속 전쟁을 벌 였기 때문입니다).
그럼 보자. 기술적 인 프리마 돈나에 대한 과도한 의존, 현금 흐름 문제, 고객의 사양에 맞지 않는 ... 당신 말이 맞아요, 제가 들어 본 적이없는 소프트웨어 프로젝트처럼 들리는군요.
한때 들었던 오래된 일화를 회상합니다.
자동차 정비사가 외과의에게 묻습니다. "왜 그렇게 많은 돈을 벌 수 있습니까? 그렇게 복잡한 일을 할 수 있습니까? 엔진 작업이 매우 복잡하고 도전적인 것처럼 보이며 정말 잘하고 있습니다. 엔진에 문제가 있습니다! "
그런 다음 외과의 사는 가서 점화 장치를 켜고 차를 시동합니다. 그런 다음 그는 정비공을 살펴 봅니다. "음, 이제 고쳐주세요."
로켓 수술이 아닙니다.
시스 티나 예배당을 짓는 것과 같지 않다면 집을 짓는 것과 같을 것입니다. 집을 짓는 데에는 많은 다른 것들이 들어가고, 다른 전문 분야에 관련된 많은 사람들이 있습니다. 지나치게 복잡한 것은 없지만 많은 작업이 필요합니다!
문제는 정말 그이다 없는 집을 짓는 것처럼; 그것은 항상 변화 하는 집을 짓는 것과 비슷 합니다 . 그러나 복잡성을 위해 이것은 당신의 요점을 더 효과적으로 설명 할 수 있습니다.
그 사람도 그것을 이해하지 못한다면 은유는 당신에게 아무런 소용이 없습니다. 개인이 이해할 수있는 용어로 복잡성을 설명해야합니다. 가능하다면 그들이 경험할 수있는 복잡한 작업 상황과 연관 시키십시오.
회계사의 경우 다음과 같이 말할 수 있습니다. "이는 계산기를 사용하여 미국 연방 준비 은행을 직접 감사하는 것과 같습니다."
프로그래밍은 아기를 가르치는 것과 같습니다 . 이것에 대해 참아주세요 : 아기에게 당근 쇼핑하는 방법을 설명하고 싶다고 상상해보십시오. 로봇을 가르치는 것과 똑같은 일을 할 것입니다.
먼저 그는 걷는 법을 배워야합니다. 워킹 서브 루틴. 자세한 내용은 다루지 않겠지 만 그는 상대방 앞에 발을 놓고 무게의 균형을 맞춰야합니다. 그가 넘어 지거나 장애물에 직면 한 예외를 관리해야합니다.
그런 다음 그는 슈퍼 마켓의 위치에 대한 지리적 사양이 필요합니다.
그는 시장을 찾을 때까지 걷기 서브 루틴을 사용하도록 지시 받아야합니다. 합리적인 시간 내에 시장을 찾지 못하면 (정의되어야 함) 귀국 루틴을 시작해야합니다.
슈퍼마켓을 찾으면 당근 정찰 알고리즘을 사용하여 당근을 찾아야합니다. 그는 모든 개체를 데이터뱅크의 당근 3D 모델과 비교해야합니다. 다시 합리적인 시간 (또는 시간 초과).
그런 다음 그는 당근에 대한 영구적 인 접근을 얻기 위해 그 당근과 돈을 교환 할 장소를 평가해야합니다. 이 부분은 정말 까다로울 수 있습니다.
그런 다음 그는 현재 당근 국제 가격과 다른 위치에서 더 낮은 가격의 당근을 얻는 데 필요한 자원을 기준으로 가격을 평가해야합니다.
나는 그 과정의 절반 밖에되지 않았고 당신은 나의 표류를 잡는다. 그리고 저는 많은 검사와 예외, 평가, 인정 등을 건너 뛰었습니다. 전체 개발팀이 이것을 프로그래밍하는 데 몇 달, 어쩌면 몇 년이 걸릴 것입니다. 그리고 그것은 단지 당근을 사러갑니다.
제가 말하고자하는 것은 응용 프로그램을 개발할 때 말 그대로 모든 것을 "말"해야한다는 것입니다. 명확하게 지정되지 않은 모든 세부 사항에 대해 "무작위"동작, 오류 또는 간단한 종료와 같은 놀라움이 있습니다. 일반적인 상황에서해야 할 일과 상황이 바뀔 때 적응하는 방법을 프로그램에 알려야합니다. 프로그래밍은 아기에게 매우 복잡한 작업을 가르치는 것과 같습니다.
그런 다음 최악의 부분이 나옵니다. 전체 과정에서 아기의 손을 잡을 수는 없습니다. 그가 모든 것을 가지고 있는지 확인하고 그를 보내십시오. 2 가지 가능한 결과 : 모든 것이 예상대로 처음부터 끝까지 잘 작동하거나 (절대 발생하지 않음) 아기가 작업 중간에 앉아 울고 있는데 무엇이 잘못되었는지 물어볼 수 없습니다. 그는 단지 울고 있고 멈추지 않을 것입니다. 그리고 디버깅이 시작됩니다.
이제 증권 거래소를 관리하는 소프트웨어, 자동 잔디 깎는 기계 또는 비행기를 구축하는 데 얼마나 많은 노력이 필요한지 더 잘 상상할 수 있습니다! 아기에게 비행기 조종 방법을 가르치려면 얼마나 많은 시간이 필요합니까?
아니.
솔직히 없습니다.
당신이 할 수있는 최선의 방법은 최종 사용자가 컴퓨터 역할극을하도록하는 것입니다. 그래서 그들은 프로세스가 본질적으로 얼마나 복잡한 지 깨달을 때까지 각 사용 사례를 생각해야합니다.
수천 줄의 코드를 정말 빠르게 스크롤하십시오. "한 문자가 틀리면이 모든 것이 작동하지 않습니다"라고 말합니다.
다른 것:
하나의 오타 나 문법 오류가있는 경우를 제외하고는 소설을 쓰는 것과 비슷하지만 모든 것이 의미가 없습니다.
평신도들에게 자주 사용하는 은유는 소프트웨어를 만드는 것이 다리를 만드는 것과 같지 않다는 것입니다.
다리를 짓는 경우 I- 빔과 리벳을 구입하고 표준 콘크리트를 부을 수 있습니다. 소프트웨어를 제작하는 경우 자체 I 형 빔과 리벳을 만들어야하며 비표준 콘크리트를 발명해야 할 수도 있습니다.
다리가 반쯤 완성되면 아무도 밤에 드라이브 인 영화관으로 기능해야한다고 말하지 않습니다. 그러나 소프트웨어에서는 최신 변경 요청이 일반적입니다.
다리가 반쯤 완성되면 알 수 있습니다 . 소프트웨어가 언제 반쯤 완성되었는지 알 수 없습니다.
X- 레이, 초음파 및 기타 도구를 사용하면 브리지를 사용하기 전에 브리지에 구조적 결함이 없는지 확인할 수 있습니다. 그러나 테스트의 모범 사례를 사용하더라도 소프트웨어를 사용할 때까지 소프트웨어의 많은 결함을 발견 할 수 없습니다. 그리고 특정 결함을 수정하는 데 시간이 얼마나 걸리거나 마지막 중요한 결함이 발견 된시기를 아는 것은 매우 어렵습니다.
이러한 모든 요소는 소프트웨어 프로젝트에 소요되는 시간을 예측하기 어려운 이유와 소프트웨어 프로젝트가 종종 늦어지는 이유를 설명하는 데 도움이됩니다.
나 자신을 도울 수는 없지만 That Mitchell & Webb Look에서이 비디오를 게시 해야합니다 .
뇌 외과 의사-미첼 & 웹 룩, 시리즈 3-BBC Two
그렇기 때문에 소프트웨어 프로젝트를 계획하는 데는 예배당 건설 계획과 동일한 문제가 많다는 사실을 입증하는 데 도움 이 될 수 있습니다 . 관리해야 할 매우 다른 측면이 많이 있으며 누군가가 기본적으로 실수를하면 전체 생각이 무너질 것입니다.
비즈니스 애플리케이션의 주요 목표는 종종 조직 내에서 의사 소통을 돕는 것입니다. 따라서 비즈니스 응용 프로그램의 복잡성을 설명하려고 할 때 종종 X와 Y 사이의 일상적인 비즈니스 의사 소통을 분해하는 경향이 있습니다. 그리고 그것을 분쇄합니다!
이렇게하면 프로그래밍 경험이없는 사람이 복잡성을 쉽게 전달할 수 있습니다. 왜냐하면 당신은 X와 Y가 말하도록해야 할뿐만 아니라 그들의 언어도 구성해야하기 때문입니다. 기타 등등.
나는 이것이 도움이되기를 바랍니다 =)
이전 소프트웨어 프로젝트와 비교할 수 있습니다.
예전 프로젝트 X를 기억 하시나요? 약 6 개월이 걸렸습니다. 음, 새로운 프로젝트 Y는 대략 그렇게 복잡합니다.
실패하면 프로젝트를 실제 물리적 엔지니어링이 필요한 다른 프로젝트와 비교하십시오. 어떤 프로젝트는 집을 설계하고 짓는 것과 같고 어떤 프로젝트는 다리와 비슷합니다.
회사가 비교를위한 기초로 수행 한 엔지니어링 프로젝트를 찾을 수 있다면 더 좋습니다. 물론 이는 해당 산업에 따라 다릅니다.
기술적 배경이없는 사람들은 우리 (프로그래머를 의미)가하는 일을 지나치게 단순화하는 것이 일반적이라고 생각합니다. 즉, 많은 프로그래머가 우리가하는 일을 지나치게 복잡하게 만들거나 적어도 실제로는 더 큰 일을한다고 생각합니다.
나는 우리 대부분이 작성하는 소프트웨어가 실제로 그렇게 복잡한 작업을 수행하지 않는 것을 모험 할 것입니다 (소란을 일으키기 전에 나는 이것에 대한 많은 예외가 있음을 자유롭게 인정합니다). 우리는 고객이 자신의 요구 사항을 지속적으로 변경하거나 마치 우리 규율에 고유 한 것처럼 완전히 상충되는 요구 사항이있는 집이나 사무실을 짓는 것에 비유를 던지는 것을 좋아합니다. 글쎄, 당신이 대부분의 계약자에게 그 이야기를 들었다면 나는 그들이 당신의 얼굴에 웃을 것이라고 생각합니다. 그들은 우리보다 모순적인 요구 사항, 무의미한 요청 및 변화하는 요구에 더 이상 면역이 없습니다. 순수한 '폭포'접근 방식은 우리보다 그들에게 문제가되지 않습니다.
따라서 비 프로그래머가 특정 작업이나 프로젝트가 왜 어려운지 이해하는 데 도움이되는 가장 좋은 방법은 은유를 생각해내는 것입니다. 그들을 참여시키는 것입니다. 그들에게 사소한 것의 예를 보여주고 그 "사소한"변화에 실제로 얼마나 많은 작업이 들어가야하는지에 대한 통찰력을줍니다.
단위 테스트가있는 경우 한 줄 테스트를 수행 한 다음 테스트 결과 이전 ( 모두 통과 해야 함 )을 보여주고 이후 빨간색 막대 뒤에 빨간색 막대를 표시합니다. "여기, 당신은 지적 할 수 있습니다. 한 줄의 코드가 깨뜨린 모든 것을보십시오. 나는 거기에서 모든 것을 고쳐야합니다." 물론 그것은 짜여진 예입니다.
나는 비유가 우리가하는 일의 복잡성에 대해 프로그래머가 아닌 사람에게 진정한 감사를 줄 것이라고 생각하지 않습니다 (실제로는 그렇게 복잡하지 않다는 경고와 함께). 당신은 당신이하고있는 실제 작업에 대한 통찰력을 그들에게 제공해야합니다. 실제로는 단순하고 영리한 비유보다 훨씬 더 비판적인 생각이 필요합니다.
이것은 소프트웨어 엔지니어링을 설명 할 때 제가 가장 좋아하는 은유 중 하나입니다.
집을 짓고 있다고 상상해보십시오. 집에 대한 계획을 세우고 어떤 재료를 지을 지 결정하고 건축 과정을 구성하는 방법을 결정해야합니다. (대부분의 사람들은 집에서 일을 했으므로 이것에 관련된 대략적인 개념을 가지고 있습니다.)
이제 집을 짓는 것이 아니라 100 층의 사무실이있는 초고층 빌딩을 짓고 있다고 상상해보십시오. 계획은 집에 대한 계획과 어떻게 다릅니 까? 재료는 어떻게 달라야합니까? 주의 깊게 고려해야 할 요소는 무엇입니까?
이제 직접 마천루를 짓지 않고 달로 날아가 그곳에 마천루를 지을 로봇을 만들고 있다고 상상해보십시오. 이제 계획이 어떻게 달라야합니까? 재료는 어떻게 달라야합니까? 모든 결정의 결과를 신중하게 고려해야하는 이유를 아십니까?
원한다면 "skyscraper"를 "화물 관리 시스템"으로 대체 할 수 있으며, 은유가 여전히 유용 할 것이라고 생각합니다.
비현실적인 견적을 생성하는 절름발이 프로젝트 관리로 인해 프로젝트를 늦게 전달할 때 ...
"프로젝트에 프로그래머를 몇 명 더 추가하면 제 시간에 완료 될 것이라고 생각하십니까?"
다음으로 답장 할 수 있습니다.
"아내가 아이를 낳고 있는데 의사가 9 개월이 걸릴 거라고 했어요. 또 다른 2 명의 여성을 사용했는지 물었습니다.
풍부한
다른 사람이 말하고 어려운 질문을하게하십시오. 유효한 전략 일 수도 있습니다. 그의 의견은 어떤 수치를 기반으로합니까?
수치는 이해하기 더 쉽습니다.
당신은 많은
- 목록 항목
- 사용 사례
- 요구 사항
- 유사한 프로젝트에 참여한 개발자
- 회사 또는 필요한 타사 제품
- 사용자
- 사이트
- ...
동기화가 필요합니까? 메타 퍼를 찾는 것도 좋은 점입니다.
위험 관리가 있습니까? 실패의 영향은 무엇입니까? 표준 PC 프로그램은 중요하지 않지만 프로그램이 잘못된 값을 계산하거나 더 이상 작동하지 않으면 어떻게됩니까?
OS 프로그래밍의 어려움은 무엇입니까?-사용 방법을 알고 있습니다. :) 유효한 대답이 아닙니다. 맞습니까?
행운을 빕니다
누구나 맥도날드를 이해합니다. 당신이 현금을 많이 가지고 있다면, 당신은 프랜차이즈를 얻고 누군가가 와서 당신을 위해 모든 것을 설정합니다. 소프트웨어는 프랜차이즈를 얻고 모든 것을 스스로해야하는 것과 같습니다 ...
- 부동산 찾기
- 부동산 입찰
- 부동산 구매
- 다른 McD처럼 보이는 쉘 건물을 짓기 위해 건설 승무원을 구하십시오
- 필요한 장비 찾기 및 구입
- 장비 설치
- 컴퓨터 받기
- POS 소프트웨어 작성
- 드라이브 업 창에 컴퓨터를 놓고 햄버거 플리퍼에게 xmit 명령에 대한 코드를 작성하십시오.
- 타임 카드 소프트웨어 작성
- 급여 소프트웨어 작성
- Install and computerize security system
- Hire competent crew
- Train crew
- Buy stock
- Write software to track stock
- Write software to anticipate orders of stock
- Etc.
You get the idea. There is a lot of stuff that goes into development that the average Joe doesn't realize. McDonalds appear like magic. But there's a lot that goes into getting (and keeping) one running.
Back in 1982 I was designing some new test machine core electronics for Intel. It was for testing of micro-controller chips (8X4X family of micro-controllers). I was asked why it was taking so long by a guy in product engineering (I was in test engineering). But the question had an attitude behind it. I was only one year out of college at the time.
I asked him , "Have you ever designed a test machine?"
He quickly realized the problem with his question.
Hope this helps.
JR
just be thicker skinned. unless it's the boss, you don't have to explain anything. and, btw, you will never get it through to people who think you spend all day on the Internet (how, ironic). This goes for programmers, server people, and so on.
Didn't you know that you did nothing for a living?
edit: I got a down vote with no reason...
Writing a software system is like writing a story. It is a creative endeavor whose coherence is directly dependent on the writer. As a story progresses, plot points (requirements) change, and characters are introduced, shaped, and cut as necessary (refactoring). The understanding of the story (domain) is ever-evolving, and certain details just can't be known until relevant portions of the story are actually written.
Code is an expression of ideas; a developer thus has more in common with being an author than being an engineer. As has been mentioned in other answers, the analogy of building a house (or car or bridge) isn't up to the task. We as a people have been hammering out those patterns for centuries; we've only been developing software for ~60 years (as an industry for ~25). If mechanical engineering were a solid analogy for software development, we wouldn't have the problems we do with estimates.
Talk them through all the logic you had to program in for the edge case scenarios.
For example, they think that the report on Number of Contains Shipped is pretty simple, because they just select a date range and a number comes up. Tell them about how the code has to look for containers that haven't reached their destination yet, it has to check that the containers weren't returned to sender, if the container was held by Customs because it looked suspicious, then you have to connect to a Customs Office web service to check on the status of the container, you need to ignore containers that were cancelled, containers that were lost at sea because a ship sank are counted as shipped, but only if the ship sank more than 120 nautical miles off the coast of the USA, UK, France, Japan or China, or 30 nautical miles off the coast of any other country, containers destroyed during a traffic incident are counted provided the driver of the truck was not at fault, containers that just plain went missing are not counted until they have been lost for at least 6 months, and so on.
This gives people an idea of the overwhelming number of 'minor details' which a programmer has to account for, even in apparently simple programs.
I like to compare programming projects to airplanes. There is a wide range of complexity in aircraft. A low-level, simple but functional app may be a WWII biplane. It’s got limited use but in the right context it’s the right tool. On the other hand when you start looking at a commercial jet liner and the level of detail/complexity needed to build one you have an entirely different story. Not only does it have to be able to fly the people using it need to be safe and comfortable while using it. If the plane (app) crashes or has excessive delays the passenger (user) gets frustrated/dissatisfied. If it happens enough they’ll find a new airline. You can run with the intricacies of the plane along whatever path you need.
The other massive difference in the planes is the skill level and number of people needed to fly/maintain the aircraft. One man can fly/maintain a biplane, but you need a larger crew with more training/man hours to deal with a commercial airliner.
maybe you can not tell why it is complex but you may reference labour on complexity.
you can tell that it is so complex that 10 people should work on this project 2 years?
I might avoid the house metaphor. When we built our house 3 years ago, we were aghast at how unlike an engineering project it was. I swear the plumber and one of the trim carpenters must have been drunk.
Show this guy your functional specs. He'll start to get an idea of how much detail is involved in building the application.
Programming involves a plethora of conditions and actions layered on top of eachother. If one condition isn't 100% correct then the program may perform the wrong action. And computers are not forgiving.
Much like a master chess player anticipating his opponents moves, it's the programmer's job to anticipate every scenario and account for it in code.
As the project grows, the chess board grows and the necessity for perfection becomes exponentially more difficult for a single programmer to handle.
In an interview, I remember Moby saying something to the effect of...
Sometimes I think that I should rephrase "Everything is wrong" to "Everything is complicated."
That's software.
Or they actually read, give them:
I Sing the Body Electronic: A Year with Microsoft on the Multimedia Frontier, which is probably the best book I have read that could give a lay person insight into software development. (In fact, as a non-CS major, it was one of the books that lead me to stay with software).
On some projects I feel like trying to fit an octopus into a small box. And with some projects I feel like I am assembling a jigsaw puzzle made of a running movie. Probably not the metaphor for explaining something to a client, though :)
The first question I would have is who is your audience? Is this management? Why does it matter that this person understands the complexity?
Presuming that it's business-critical that this person has a moderate grasp of the complexity of the system, you could take the tack of showing an overview of the system, getting into the detail of one aspect, and then asking their input on where the system could be simplified. It's also possible that this person truly has a unique aptitude for understanding your complex system, so to them it really isn't complicated. Regardless, getting them involved and invested in the system's development and they may turn from being your harshest critic to your champion.
The problem I found is that sometimes simple things are a lot more complex than imagined. For example, they could simply say, "Everytime this happens, make it do this." And it's simple changes, but ends up requiring a lot of codes or complex/buggy behavior.
To explain it, it's a bit complex. If your project manager is giving you a tough time because it's simple to him, then what needs to happen give it time. Say it's not ready, then show what you have. Eventually they'll learn that when you say it's going to take X amount of time, that you really mean it's going to take X amount of time.
ReferenceURL : https://stackoverflow.com/questions/1278026/are-there-any-good-metaphors-for-explaining-project-complexity-to-a-non-programm
'programing' 카테고리의 다른 글
| iOS는 다른 배열에서 배열 요소를 신속하게 제거합니다. (0) | 2021.01.17 |
|---|---|
| .NET을 사용하여 동일한 프로세스로 여러 명령 줄 실행 (0) | 2021.01.17 |
| C의 삼항 (조건부) 연산자 (0) | 2021.01.16 |
| Java 8보다 Java 11에서 현저하게 느린 스택 추적 소비 (0) | 2021.01.16 |
| MPVolumeView를 사용한 후 시스템 볼륨 오버레이를 다시 켜려면 어떻게합니까? (0) | 2021.01.16 |