의사소통 격차:사용자 대 분석가-디자이너

Question

일반적인 관행은 사례 연구를 사용하고 작업 및 데이터 흐름을 구성하는 것 등입니다.그러나 이것이 반드시 사용자/스폰서와 분석가-설계자 사이에 공유 어휘를 생성하는 것은 아닙니다.둘 중 하나는 일반적으로 다른 전문 분야의 "내부"에 대한 용어와 견해를 획득해야 하며 이는 일반적으로 오해와 설명을 위한 회의(진화 프로토타이핑과 같은 RAD 기술 입력)로 이어집니다. .

사용자/후원자는 자신의 필요/환경에 초점을 맞추고 있으며, 자신의 관점에서 관련 없는 '프로그래밍 용어'를 취득하기를 원하지 않으며 취득하도록 강요받아서도 안 됩니다.새로운 환경을 배우는 책임은 분석가/설계자(/프로그래머)에게 있습니다.

학습 곡선을 어떻게 극복합니까?소프트웨어 솔루션을 원하는 사용자를 만날 때 무엇이 ​​당신에게 도움이 됩니까?

Answer 1

최대한 많이 제거해 보세요 중간 단계 가능한 한 사용자와 최종 구현자 사이에.그러한 모든 단계에서는 정보가 모호해지고 손실됩니다.팀에서 가장 귀중한 구성원은 다음을 수행할 수 있는 사람일 수 있습니다. 두 정장 모두 - 사용자와 "인터페이스"하고 실제로 구현합니다.

그렇지 않다면, 가지고 있는지 확인하세요 빠른 반복 반복적으로 구현합니다.점진적으로 혼동하기 쉽습니다.차이점은 반복적 접근 방식을 사용하면 작지만 균일한 수준으로 광범위한 기능을 구현할 수 있다는 것입니다.증분 방식에서는 큰 기능 덩어리를 차례로 구현합니다.

반복적 접근 방식에서는 다음과 같은 이점이 있습니다. 민첩. 사용자가 마음을 바꾸었습니까, 아니면 오해가 있었습니까?문제 없습니다. 아직 변경할 여지가 있습니다.다행히도 많은 노력이 소비되지 않았습니다.

Answer 2

댓글을 활용해요

"바텐더에게 물리학을 설명할 수 없다면 그것은 그다지 좋은 물리학이 아닙니다." 그리고 "할머니에게 설명할 수 없으면 뭔가를 실제로 이해하지 못하는 것입니다"(러더퍼드와 아인슈타인에게 귀속됨)

고객과 요구사항을 논의할 때 진언으로 사용합니다.

높은 수준의 Powerpoint 또는 화이트보드 프레젠테이션과 사용자가 POC 또는 모형에 느슨해지게 할 수 있는 경우 두 가지 접근 방식을 취하십시오.

그런 다음 한 줄씩 세부적인 요구 사항을 수행하십시오.악마는 디테일에 있다.세부 사항에 대해 승인을 받도록 하세요.한 줄씩 분석할 수 있도록 라벨을 붙이고 번호를 매깁니다.

높은 수준의 설정 이전에 세부 요구 사항을 수행하면 사용자는 디자인의 어떤 개념도 파악하지 못하고 가장 작은 세부 사양에 갇히게 됩니다.어떤 프레임 작업이나 개념도 없이 사용자는 핀 머리에 있는 천사 수를 중심으로 회전하게 됩니다.

고객과 개발팀이 비슷한 언어로 대화할 수 있다면 민첩성과 반복은 좋습니다.기대치가 설정되고 충족되었는지 확인합니다.

Answer 3

훌륭한 상호작용 디자이너는 소프트웨어 작동을 일반인의 용어로 설명할 수 있어야 합니다.그렇지 않다면 프런트엔드를 수행해서는 안 됩니다. IMHO.

Answer 4

이를 위해서는 다양한 기술이 필요하며 양측은 상대방의 비즈니스를 어느 정도 이해하는 방법을 배워야 합니다.즉.분석가는 사용자의 영역을 이해해야 하며 사용자는 분석가의 일부 기술에 익숙해져야 합니다.

나는 프로세스 흐름이 비즈니스 운영 방식에 대해 높은 수준에서 합의를 시작하는 좋은 방법이라고 생각합니다.일부 사용자는 데이터 모델(예: ERD)에 능숙하지만 일반적으로 그렇지 않다고 말하고 싶습니다.규칙이 텍스트로 설명되어 있을 때 더 잘 반응하는 경우가 많습니다.

• 주문은 하나 이상의 주문 라인으로 구성될 수 있습니다.
• 각 주문에는 고유한 10자리 참조 번호가 있습니다.

그들은 ERD의 품질을 확인하는 것보다 훨씬 더 쉽게 내용을 읽고 체크하거나 교차할 수 있습니다.

다음으로, 사용자가 원하는 세부 사항에 집중할 수 있도록 입력 화면과 보고서를 스케치하는 것보다 더 좋은 것은 없습니다.