이 때 많은 비즈니스 사용자와 클라이언트 사이에 일반적인 개념이 보이는 완료, 거의 완료가. 아시다시피, 이것은 진실과 거리가 멀습니다. 하나는 멋지게 보일 수 있지만 백엔드는 없으며 일부 사용자는 20 % ( 또는 다른 80 % )가 아니라 80 %의 작업으로 생각합니다 .

셀 수없이 많은 개발자들이 이에 대한 공포 이야기를 들려 줄 수 있습니다. 다른 도구의 스크린 샷을 사용하여 Microsoft Word에서 페이지를 모방하고 클라이언트가 “거의 완료 했습니까?”

모든 부품이 완성되면 속도를 조절해야합니다. 모든 백엔드를 먼저 수행 한 다음 모든 프론트 엔드를 시도하면 최종 사용자가 아무것도하지 않는다고 생각하고 표시 할 것이 없을 때 왜 돈을 받고 있는지 묻습니다. 다른 한편으로, 프론트 엔드를 먼저하면 최종 사용자가 변화를 겪고 우리의 시간을 소비한다는 것을 알게 될 것입니다.

‘첫 번째와 다른 하나’의 최악의 경우는 다른 부분에 도달했을 때 디자인에 전혀 맞지 않는 것입니다.

따라서 둘 다 빌드하십시오. 프론트 엔드에서 진행 상황을 보여주고, 백엔드가 당신이 만들고있는 것을 사용하도록하십시오. 많은 경우 증분 빌드를 제공하고 클라이언트가 원하는 것을 만들고 있는지 확인하는 것이 좋습니다 (이것은 Agile에 해당). ‘눈에 띄는 진보’를하지 않고 너무 오래 가면 고객 관계가 손상 될 수 있습니다 ( ‘모든 것은 조기에 해본 것’과 ‘끝까지 아무 것도 이루어지지 않은’ 두 경우 모두에 해당합니다. 단위 테스트 또는 데이터 위생 처리 진행).

Joel은 이에 대해 빙산의 비밀 에 다음과 같이 기록했습니다 .

중요한 추론 2. 프로그래머가 아닌 사용자에게 100 % 아름다운 사용자 인터페이스가있는 화면을 표시하면 프로그램이 거의 완료된 것으로 간주합니다.

프로그래머가 아닌 사람들은 단지 화면을보고 일부 픽셀을보고 있습니다. 그리고 픽셀이 무언가를하는 프로그램을 구성하는 것처럼 보인다면, “오, 세상에, 실제로 작동시키기가 얼마나 더 어려울까요?”

여기서 가장 큰 위험은 UI를 먼저 조롱하면 아마도 고객과 대화를 나눌 수 있고 모든 사람들이 거의 다 끝났다고 생각할 것입니다. 그리고 내년에 “표지 아래”에서 일할 때, 아무도 당신이하고있는 일을 실제로 보지 못할 것이고 그들은 아무것도 아니라고 생각할 것입니다.

이것은 블로그 포스트에서 다시 한 번 강조됩니다. 이 유용한 그래프가 있는 데모를 완성하지 마십시오 .

여기서 두 가지 옵션은 일반적으로 ‘ui를 완료하십시오'(그리고 곧 완료 될 것으로 기대합니다)와 ‘백엔드를 완료하십시오'(고객이 마감 기한을 놓친 것에 대해 걱정합니다)를 반영합니다.

‘완료’된 모습이 ‘완료’된 모습과 일치해야합니다.

모든 소프트웨어 개발자는 경력에서이 경험을 여러 번 경험했습니다. 그러나 데스크톱 출판 도구는 기술 작가들에게도 같은 문제를 야기합니다. 누군가에게 완벽하게 글꼴이 지정되고 서식이 지정된 초안을 표시하면 원하는 것보다 더 완성 된 것으로 간주됩니다. 우리는 우리가있는 곳과 다른 사람들이 우리를인지하는 곳이 일치해야합니다.

이 기사는 또한 사용자 인터페이스의 다양한 수준의 피드백으로 얻는 피드백 유형 에 대한 중요한 요점을 제공합니다 . 완성 된 것으로 보이는 경우 “이 레이아웃이 작동하지 않습니다. 탭이 너무 많습니다”보다 “글꼴을 변경할 수 있습니까?”에 대한 피드백을받을 가능성이 높습니다.

Java Swing 세계에서 이와 싸우고있는 사람들에게는 Napkin 이라는 모양과 느낌 이있어 UI가 완벽하게 보이지 않게합니다.

열쇠는 여기가되지 않도록 그것을 확인하는 것입니다 봐 다. UI가 완성 된 것처럼 보이게하는 것은 많은 비즈니스 사용자에게 응용 프로그램이 완벽하다는 신호입니다 (어떤 로직 페이지 나 인터페이스 빌더에 내장되지 않은 정적 페이지가 몇 개인 경우에도).

추가 자료 (및 기사의 링크) :

• 빙산의 비밀, 공개
• 데모를 완료로 표시하지 마십시오
• 냅킨 룩앤필 스윙
• xkcd 스타일 그래프가 중요한 이유

답변