경영진이 프로토 타입을 폐기하도록 어떻게 확신하십니까?

UI를 사용자 앞에 놓을 수있는 빠르고 효과적인 방법으로 프로토 타입 제작을 좋아합니다.

그러나 경영진은 부리에 방해가되며 프로토 타입은 주류 개발에 쫓겨나고 비명을 지르고 있습니다.

이 작업을 수행하지 않도록 관리를 어떻게 관리합니까?

Microsoft SketchFlow 와 같은 도구를 사용 하거나 다른 언어 또는 플랫폼으로 프로토 타입을 제작하여 기본 개발에 통합하는 것이 거의 불가능합니다.

스크린 샷과 프로토 타입을 보여주는 것에 대한 joelonsoftware 에세이 도 있습니다. 여기에서 그는 구현되지 않은 부분과 작동하지 않는 부분이 분명히 깨지거나 구현되지 않은 것처럼 보이게하여 작업이 여전히 필요한 곳을 명확하게 보여줍니다.

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

...

이것에 대해 무엇을 할 수 있습니까? 빙산의 비밀을 이해하면 쉽게 사용할 수 있습니다. 어두운 방에서 프로젝터를 사용하는 데모는 모두 픽셀로 표시됩니다. 가능하면 완성되지 않은 부분이 완성되지 않은 방식으로 UI를 빌드하십시오. 예를 들어, 기능이 나타날 때까지 도구 모음의 아이콘에 대해 낙서를 사용하십시오. 웹 서비스를 구축 할 때 해당 기능이 작성 될 때까지 실제로는 홈페이지에서 기능을 제외하는 것이 좋습니다. 그렇게하면 사람들은 더 많은 것들이 만들어 짐에 따라 홈페이지가 3 개의 명령에서 20 개의 명령으로 이동하는 것을 볼 수 있습니다.

따라서 Visual Studio 대신 Photoshop에서 프로토 타입을 제작 해보십시오.

작동 코드로 프로토 타입을 만들지 마십시오. 연필과 종이로 시제품 또는 이와 동등한 소프트웨어 .

목업을 사용하면 그림과 같은 느낌이 들지만 디지털 방식이기 때문에 쉽게 조정할 수 있습니다. 팀은 회의 중에 디자인을 만들어 실시간으로 반복 할 수 있습니다.

종이를 사용하면 팀 구성원들이 쉽게 뛰어들 수 있다는 이점이 있으며, 모두가 그 종이가 단지 빈 종이라는 것을 이해합니다. 이것은 덜 귀중 해 보입니다.

코드 품질을 타협하지 마십시오.

정크 코드 작성은 잘못된 경제입니다.

다른 포스터에서 제안했듯이 모형을위한 특정 도구를 사용하여이를 달성 할 수 있습니다.

그러나 프로토 타입을 제작하는 데는 여러 가지 이유가 있습니다. 때로는 코드를 작성하지 않고 필요한 것을 보여줄 수 있지만 종종 그렇지 않습니다. 이해 관계자는 기능의 기술적 타당성을 입증하기를 원할 수 있습니다.

기능을 시연하고 개념을 증명할 수있는 가장 간결한 것을 구축하십시오. 다른 것은 버리십시오.

UI 기능의 경우 서버에서 아무것도 개발하지 않도록하십시오. 전혀 만지지 마십시오. 내장 된 모의 / 가짜를 다시 개발하십시오.

UI를 나머지 응용 프로그램의 스타일에 맞추기 위해 노력해야하는 경우 귀찮게하지 마십시오. 아무 노력 없이도 좋아 보인다면 색상을 변경하여 눈에 띄게 만들거나 워터 마크로 프로토 타입임을 알 수 있습니다.

프로토 타입이 프로덕션 코드로 바뀌는 가장 큰 원인은 영업 사원이라는 것을 알았습니다. 그들은이 새로운 기능이 없으면 고객이 서명하지 않았을 때 귀하의 제품을 새로운 고객에게 판매 할 것입니다. 당신은 그들을 비난 할 수 없습니다, 그들은 목표를 가지고 있습니다. 그들에게 조심하십시오; 그들이 프로토 타입임을 나타내는 것을 꺼내지 않도록하십시오. 당신은 자신의 입장을 견뎌야합니다. 어쨌든 그들은 고객을 오도하지 않아야합니다.

경영진이 프로토 타입을 한 조각 씩 생산 코드로 바꾸도록 강요하기 시작할 수 있습니다. 처음으로 충고를 따르지 않은 코드를 작성하지 않으면 아무런 문제가 없습니다. 점차적으로 타협없이 소프트웨어를 구축합니다.

그런 다음 경영진이 품질 저하를 강요하기 시작하면 그 이유를 스스로에게 문의해야합니다. 그들은 수동적입니까? 약한? 절망? 그러한 것들 중 어느 것도 회사에서 고집해야 할 좋은 이유는 없습니다.

정말 간단합니다. 그들이이 버그가 많은 엉망진창을 보여 주면 그들이 가장 좋아하는 고객을 잃게 될 것이라고 말한다.

그리고 그들이 정말로 더 잘 알고 있다면 기회를 잡으라고 요청하십시오.

마지막으로, 프로토 타입에 특정 버그 A, B 및 C가 있다고 말하지 마십시오. 그런 다음 버그를 수정하게되면 경영진은 소프트웨어 제작 준비를 위해 에너지를 채널 화했다고 주장합니다.

이러한 성과 보너스와 미래의 주식 보조금이있을 가능성이 높습니다.

우선 문제를 회피하십시오. 끝내지 마십시오. 즉, 사이트의 기존 스타일에 적합하거나 예쁘게 보이게하지 마십시오. 목표는 가능한 가장 조잡한 작업 버전을 얻는 것이므로 매우 기본적인 UI 흐름이 작동 함을 알 수 있습니다. 기존 사이트 스타일을 버리거나 과도하게 연마하면 "플러그인"만 가능하다고 가정합니다. 관리는 Star Trek의 Pakleds와 같습니다. 그들은 단지 당신이 "그것을 만들어"원합니다. 더 많이 보일수록 더 많이 생각할 것입니다.

그래도 문제가 해결되지 않으면 1 년 동안 잘 알려진 브랜드 이름을 가진 하나 이상의 회사에서 일자리를 구하십시오. 이메일과 전화 번호를 온라인 이력서에 넣으면 채용 담당자와 막대기로 다시 싸울 수 있습니다. 그러면 직원들은 자신이하는 일을 알고 새로운 일자리를 얻을 수있는 개발자의 확신을 가지고 "절대적으로"말할 수 있습니다. 내일 바라건대 당신의 전문 지식이 더 심각하게 받아 들여지기를 바랍니다.

저는 현재 Rails, .NET 및 Java의 두 가지 스택이 아닌 트리플 스택이있는 코드베이스에서 작업하고 있습니다. 우리가 Rails를 채택한 이유는 Rails에서 프로토 타입이 만들어졌고 회사의 최고 개가 "만들었다"고 말했기 때문입니다. 때때로 거절 할 필요가 있습니다. 우리가 항상하지 않는 한 그들은 우리를 진지하게 받아 들여야합니다.

그러나 예, 프로토 타입으로 무엇을 하든지 실제로 시작하기는 쉽지 않습니다.

그것에 대해 걱정하지 마십시오.

"프로토 타입"에 대한 UI 컨트롤을 앉아서 버린다면, 그 디자인을 자동으로 버려야 할 이유는 정확히 없습니다. 관리를 보여주기에 충분하다면 "실제"프로그램을 코딩 할 때 시작하기에 좋은 곳입니다.

프로토 타입에서보다 "연마 된"UI로 전환하는 것은 완전히 정당화 가능한 일련의 단계에 지나지 않습니다. 두 번째 버튼을 추가해야했습니다. 사용자가 주문이 혼란 스럽다는 의견을 받았습니다. 조직의 표준 그룹이 약간의 변경을 지시했습니다. 국제화를 위해 텍스트 상자의 크기를 변경해야했습니다.

그 이유 중 하나가 "음, 그것은 단지 프로토 타입 일뿐"입니다. UI 디자인이나 코드 또는 서면으로, 모든 것이 영원히 살 수 있습니다. 그리고 모두가 그렇지 않은 사람들은 그들을 죽일만한 충분한 이유가 있어야합니다.

그리고 관리는 신경 쓰지 않을 것입니다.

현실적으로 UI에 기존 코드를 넣지 않은 이유가 "올바른 프레임 워크에서 다시 작성해야했다"는 것이 충분한 이유입니다. 그렇지 않은 경우 UI 프레임 워크 자체에 대한 논의가 필요할 수도 있지만 이는 또 다른 질문입니다.

나는 이것이 문제가 아니라는 점을 깨달았을 때까지 대부분의 상점에 부과 된 다소 오래된 개발 표준에서 벗어날 수있을 때까지이 문제를 겪었다.

따라서 경영진에게 프로토 타입을 작성하고이 문제 영역에 가장 적합한 기술을 선택한 다음 프로덕션에 사용될 지식을 완전히 작성하여 소프트웨어를 작성합니다.

"애플리케이션은 웹을 사용하여 Java 1.6에 있어야합니다 (선택한 값 비싼 J2EE 엔진 선택)"및 무의미한 명명 표준 등을 피하십시오.

현재 선택하고있는 프로토 타입 언어는 "php"(엄격한 프로덕션 환경으로 확장 가능-Facebook에 문의하면 됨)와 Groovy / Java와 Tomcat 또는 Jetty의 매우 우아한 조합입니다.

groovy / java 조합은 신속한 개발에 좋습니다. Groovy는 빠르게 개발하는 것이 좋지만 노인 달팽이처럼 작동하지만 성능이 중요한 섹션을 순수한 Java로 리팩터링하는 것은 쉽지 않습니다. 애플리케이션을 Tomcat 또는 Jetty로 웨딩하면 EJB 및 기타 J2EE 공포를 다시 처리 할 필요가 없습니다.

여러 포스터에서 제안한 스케치와 달리 프로토 타입이 작동하는 주요 장점은 사용자 피드백입니다. 프로토 타입은 비즈니스를 디자인에 실제로 참여시키는 좋은 방법입니다. 일단 그들이 "그 분야는 메인 화면에 없어야한다"와 같은 말을 할 수 있다는 사실을 깨닫고 이제는 저주를 할 것입니다! 다음 데모에서 메인 화면에 몇 년 동안 귀중한 비즈니스 경험을 제공하는 디자인에 참여하게됩니다.