개발자 중심의 제품이 좋은가요?

저는 CEO가 제품 팀을 관리하는 회사에서 일하고 있습니다. 기능 팀은 기능을 모형화하고 개발자를 끌어 들여 해당 기능을 구현합니다. 물론 일부 반복이 있으며 개발자의 의견이 존중됩니다. 그러나이 과정이 얼마나 효과적인지 궁금합니다.

Jason Calacanis는 다음 과 같이 썼습니다 .

Zuckerberg Doctrine : 개발자는 제품 관리자 및 설계자에 비해 속도와 기능이 크게 개선되어 잠재적 인 실수와 단점을 능가하는 제품을 설계합니다.

...

개발자 중심의 스타트 업은 항상 제품을 더 빨리 생산합니다.

주커 버그가 그의 다음 기능을 코딩하는 동안 우리의 비 기술적 인 사람들은 토론과 토론을하고 있습니다. 그래서 아무도 페이스 북을 따라갈 수 없었습니다!

MySpacers는 제품을 반복하는 방법에 대해 토론했지만 Facebook은 간단히 시도했습니다.

실제로 실제로 더 잘 작동합니까?

제품은 고객 중심 이어야합니다 .

고객이 소프트웨어 개발자이고 자신의 제품을 사용하는 경우 (어쨌든 사용해야 함) 자신의 최고의 고객이 될 수 있다고 생각합니다.

그러나 개발자로서, 당신의 관점은 이미 후드 아래에서 일어나는 일로 인해 손상되었습니다. 고객은 사용자 인터페이스 또는 응용 프로그램 워크 플로로 수행하는 작업이 구식이며 이해가되지 않는다고 설명해야합니다.

개발자는 이해 관계자에게 물어볼 수있는 올바른 질문을 알아야 경험을 최상의 제품을 생산하려는 요구와 결합 할 수 있습니다.

개발자로서 우리는 관리자와 디자이너보다 더 나은 일을하고 싶다고 생각합니다. 그러나 나는 당신이 일반화 할 수 있다고 생각하지 않습니다.

설계를 수행하는 개발자의 문제 중 하나는 최종 사용자의 요구에 부응하지 않을 수 있으며 올바른 사람들에게 올바른 질문을하는 데 능숙하지 않을 수 있다는 것입니다. 관리자, 특히 훌륭한 디자이너가이를 파악하는 것이 좋습니다.

그러나, 나는 좀 더 단호한 것은 사람들이 아니라 그들이 어떻게 접근 하는가에 대한 문제라고 생각합니다. 효과적인 접근 방식은 끝없는 회의를하고 나무를 줄여 "이상적인"디자인을 만드는 대신 물건을 내려 놓고 구현하는 것입니다. 그것은 실제로 재검토 된 민첩한 대 폭포입니다.

(페이스 북이 어떻게 행동하지 않는지에 대한 예라는 것이 분명하다. 예를 들어, 프라이버시 문제에 대한 그들의 무심한 접근은 법적 문제를 일으키기 시작했다 ...)

IMHO, 나는 당신이 부분적으로 옳다고 말합니다. 합리적으로 들립니다. 그러나 모든 제품 / 소프트웨어에 적용되는 것은 아닙니다. 그래서 저는 이것을 이렇게하겠습니다. 디자이너는 자신의 벨트 아래에 충분한 개발 경험이있는 사람이어야하며, 그뿐만 아니라 디자인 만하는 것이 아니라 코딩해야합니다.

짧은 대답 : 때때로.

긴 대답 : 고객이 누구인지 알고 고객이 원하는 것을 알고 있다면 고객 중심 개발이 작동합니다.

개발자 중심 개발은 아직 유용하지 않은 사람들에게 장점이 있습니다. 다시 말해 고객이 원하는 것을 항상 알 수없는 경우가 있습니다. 새로운 요구 사항은 기존 제품의 결함에 대한 기존 경험에서 비롯 될 수 있습니다. Zuckerberg는 Facebook에 대한 고객이 없었기 때문에 질문 전에 답변 한 제품을 만들었습니다. 이제 설립 된 Facebook은 고객의 영향을 받지만 제작되기 전과 제작 과정에서 개발자 중심의 아이디어였습니다.

고객 중심의 개발은 같은 시장에서 기존의 성숙한 제품으로 돈을 벌거나 새로운 제품을 반복하는 데 이상적입니다. 고객의 희망을 무시하는 것은 미래의 수입원에 매우 해 롭습니다.

개발자 중심 개발은 부수적 인 프로토 타입 제작 활동으로 Google 20 % 영역에 속하며 개발자는 작업 시간의 20 %를 자체 프로젝트에 소비합니다.

좋은 제품을 디자인하려면 문제 영역에 대한 많은 지식이 필요합니다. 페이스 북과 같은 일반 공개 제품은 개발자가 가지고있는 문제도 해결하기 때문에 개발자가 주도 할 수 있습니다. 친구와 연결하고 연락하는 방법 등 소프트웨어 개발자를위한 제품의 경우에도 마찬가지입니다. IDE가해야 할 일과 방법.

그러나 다른 많은 문제 영역의 경우 개발자는 종종 충분하지 않습니다. 일반적인 통찰력과 경험이 있어도 구현 하기 쉬운 멋진 기능 을 구현하는 경향이 있지만 고객에게 많은 가치를 부여하지 않고 제품을 더 복잡하게 만듭니다. 도메인 전문가가 제품을 주도해야하는 경우입니다.

필자는 이것이 AWS 나 Visual Studio와 같은 개발자 지향 제품에 대한 최선의 접근 방법이라고 생각하지만 일반적으로 더 나은 접근 방법인지 확실하지 않습니다. 나는 보통 다른 방식으로 일이 일어나는 것을 본다. 개발자는 비 기술적 인 사람들이 신속하게 결정을 내리는 동안 최선의 접근 방식을 주장하는 것에 반대한다. 개인적으로, 나는 정답이 중간에 있다고 말하는 경향이 있습니다. 개발자가 구현할 광범위한 방향을 설정할 수있는 제품 관리자가 있어야합니다.

대부분의 경우 개발자 중심 소프트웨어가 관리자 중심 소프트웨어보다 낫습니다. 관리자는 광고에서 잘 보이거나 연설에 사용할 수있는 기능 (주로 유행어 기능)에서 가장 큰 가치를 봅니다. 개발자는 성능, 버그 감소, 희박한 디자인, 유지 관리 성 등 다른 가치를 보게됩니다. 이는 거의 더 나은 소프트웨어로 이어집니다.

그러나 가장 좋은 것은 사용자 중심 소프트웨어입니다. 사용자는 필요한 것이 무엇인지, 실제 작업을 수행하는 데 무엇이 도움이되는지 알고 있습니다. 그것이 이상적입니다.

아무도 사용하고 싶지 않은 제품을 더 빨리 생산한다면 어떻게 될까요?

단일 속성 (기능, 출시 시간, 가격, 품질 등)에 중점을두면 특정 시점에 적합합니다. 예를 들어 애플은 아이폰과 아이 패드를 문 밖으로 밀어 냈다. 품질에는 약간의 어려움이 있었지만 처음부터 매우 중요했습니다.

장기적으로 만 한 측면에만 집중한다면 그것은 당신에게 상처를 줄 것입니다.

실제 문제를 해결하지 않는 한 아니요

• 프로그래머는 일반적으로 문제 해결을 좋아하며 때로는 아직 존재하지 않는 문제도 있습니다. :)
• 프로그래머는 보통 이차적 인 생각 때문에 끔찍한 GUI를 만듭니다.
• 대부분의 사용자 문제 는 프로그래머 문제 와 다릅니다 .
• 따라서 프로그래머 중심 제품은 일반적으로 다른 프로그래머에게는 좋지만 사용자에게는 좋지 않습니다.

페이스 북에 대한 참고 사항 :

페이스 북의 성공은 기술적 장점과 전혀 관련이 없으며, 실제로 큰 눈덩이를 잡은 피기 백 아이디어입니다. 페이스 북은 "Google Blue Moon"에서 한 번만 발생합니다.

하나:

• 프로그래머에게 실제 "사용자"문제가있는 경우 프로그래머 문제가 아닙니다. 그렇다면 그것의 아주 좋은 것입니다. 이해 관계자는 개발자이기도 한 경우 문제와 관련하여 중대한 제품 솔루션에 이상적인 상황이다는.

(오 세상에 ... 방금 "좋은 아이디어를 얻었습니다! 필요한 것은 개발자입니다."와 같은 내용을 읽은 곳은 일주일 내였습니다. 어쨌든 ...)

훌륭한 아이디어는 수십 가지입니다. 문제를 구현하는 것이 중요합니다. 개발자가 훌륭한 아이디어를 가진 사람이라면 구현할 수 있습니다.