개발자가 제품 소유자에게 기능 아이디어를 제안하는 것이 정상입니까? [닫은]

나는 최근에 시스템 관리자로 일한 경험이있는 개발자로 일하기 시작했습니다.

Agile 기능을 사용하는 소프트웨어 개발 팀이 어떻게 "우리가 구현해야하는"커뮤니케이션은 주로 제품 소유자에서 개발자까지 한 방향으로 이루어집니다. 개발자는 기술 부채에 대해 제품 소유자에게 우려를 표명 할 수 있지만 기능 아이디어를 내놓는 것이 주요 책임 중 하나가되어서는 안됩니다.

내가 일하는 회사는 다른 견해를 가지고 있습니다. 개발자에게는 기능 아이디어를 제안하기 위해 자신의 팀의 제품 소유자뿐만 아니라 다른 팀의 제품 소유자에게도 해당 팀의 제품에 기여할 것이 있다고 생각되는 경우 개발자에게 전달해야합니다. 아이디어는 우리 모두 하나의 큰 팀 <회사 명>이며 모든 개발자는 자신의 전문 지식을 사용하여 유용하다고 생각되는 기능을 푸시해야합니다.

더 나은 단어가 없기 때문에 그러한 접근법이 "정상적인"방법입니까? 너무 소극적입니까, 주도권을 잡고 제품 소유자에게 아이디어를 제공해야합니까? 반대로, 회사가 완전히 잘못 알고 다른 곳에서 일자리를 찾아야합니까?

기능 아이디어의 의미에 따라 다릅니다.

계획 게임에서 개발자가 반복으로 끝날 수있는 스토리에 대한 정보를 제공하는 것은 드문 일이 아닙니다. 그러나 이것은 독자적으로 스토리를 만드는 개발자와는 매우 다릅니다.

성숙한 시스템에서 개발자는 알려진 문제를 해결하여 반복으로 만들 수있는 방법을 제안 할 수 있습니다.

예를 들어 보고서에 그래프를 추가하는 등의 개선이 가능할 수 있지만, 개발자가 선의의 새로운 이야기를 들으면 알람 벨이 울릴 것입니다. 이것에 진정한 가치가 있다면, 왜 이것에 대한 기존의 구현되지 않은 이야기가 없었는지 또는 왜 회고에서 결코 나오지 않았는지 의문입니다.

많은 개발자들이 "수동적"인 이유는 좋은 제품 아이디어가 나오기 전에 어느 정도의 도메인 지식과 경험이 필요하기 때문입니다. 그러나 그들이 올 경우, 그들을 제안하고 챔피언하지 않을 이유가 없습니다.

명심하십시오-개발자, 제품 소유자, 영업 사원 등은 모두 동일한 팀에 있으며 동일한 목표를 가지고 있습니다. 성공적인 제품을 구축하는 것입니다. 그러나 그 목표를 향해 노력하십시오.

개발자와 제품 소유자에 대해 이야기하면 조직의 기능을 담당하는 중개인이없는 것 같습니다.

글쎄, 내 조직에서 나는 그 사람입니다. 나는 좋은 사양을 만들고 사용자 친화적 인 인터랙션 디자인의 고품질 소프트웨어를 만드는 기능을 선택하는 방법을 배운 요구 엔지니어입니다. (다른 조직에서는 동일한 직업을 얻는 것이 UX 담당자입니다. 해당 용어에 대해 더 잘 알고있을 것입니다).

그리고 나는 당신에게 말할 수 있습니다 : 좋은 사양을 얻는 것은 어렵습니다. 물론 개발자들은 그렇게하는 것을 싫어합니다. 그들에게는 부담입니다-소프트웨어를 구축해야하며 이해 관계자 간의 권력 놀이와 게으른 사용자의 정신 모델을 생각하지 않아야합니다. 그러나 당신은 무엇을 알고 있습니까? 제품 소유자에게도 부담이됩니다. 개발자 나 사용자보다 소프트웨어에 어떤 기능이 포함되어 있는지 더 잘 모릅니다. 실행 가능한 사양을 만드는 것은 습득 된 기술이며, 습득하지 않으면 능숙하게 사용할 수 없습니다. 물론, 이전 프로젝트에서해야했기 때문에 개발자와 제품 소유자가 많을 수 있습니다. 그러나 일반적인 제품 소유자 나 개발자는 당연히 자신의 일이 아니기 때문에 어려움을 겪습니다. 자동차를 운전할 수있는 모든 사람이 자동차를 설계 할 수있는 것은 아닙니다. 비슷하게,

요구 엔지니어없이 소프트웨어를 개발할 수 있습니까? 물론 넌 할 수있어. 그러나 제품 소유자의 어깨에 사양의 전체 무게를 두는 것은 공평하지 않으며 프로젝트 결과에 좋지 않습니다. 특히 그는 자신에게있어 어려운 일에 직면 해 있기 때문에 다른 사람들의 의견을 듣고 도움을 얻는 것이 매우 도움이됩니다. 그러한 상황에 처한 경우 불량 제품 소유자를 보지 말고 "어떻게해야하는지 말해 주시오"라고 말하지 마십시오. 그러나 당신과의 토론은 그가 그의 생각을 표현하고 그의 아이디어를 탐구하는 데 도움이 될 것입니다.

프로젝트 구조에 요구 엔지니어가없는 경우 다른 문제가 있습니다. 중재자가 없습니다. 모든 개발자는 기술적 인 측면에 있으며 모든 제품 소유자는 비즈니스 측면에 있습니다. 두 문화가 충돌 할 때, 각자의 가치 체계를 사용하여 판단하기 때문에 양측이 상대방을 어리 석고 판단 할 수없는 갈등이 발생할 수 있습니다. 따라서 가능한 기능에 대해서는 제품 소유자와상의하되, 가치가 없다고 생각 될 때도 예의 바르게 행동하십시오. 프로젝트 성공은 두 사람이 얼마나 잘 지낼 수 있는지에 달려 있으며 때로는 충돌로 인해 전혀 결정을 내리지 않는 것보다 차선책을 취하는 것이 낫습니다. 교착 상태 충돌을 방지하므로 계층 구조를 설정하고 두 명 중 한 명에게 마지막 단어를 제공하면 도움이 될 수 있습니다. 그가 마지막 단어를 받으면 불공평하다고 생각하더라도 그것을 연기하십시오.

"수동적 인"부분에 관하여 : 아이디어가 없다면, 단지 활동을 보여주기 위해 무언가를 시도하지 마십시오. 제품 소유자가 이미 안전하지 않고 자신의 아이디어를 평가하기위한 좋은 기준을 모른다면 이상한 아이디어가 "무언가를 갖기"만하면 이미 어려운 상황이 더욱 어려워 질 것입니다. 좋은 기능 아이디어를 생각해내는 것은 마술이 아니지만 지식이 필요합니다. 교과서에서 배우지 않았다면, 특히 뇌가 자체 패턴을 분류하기 전에 사용자 또는 사용자 생성 사용성 데이터 (분석, 만족도 측정)에 노출되는 프로젝트에서 몇 년의 개발자 경험이 필요할 것입니다. 여기에 우리가 해결할 수있는 문제가 있습니다. 이 페이지에 사용자가 누락 된 것 같습니다. 무엇을 할 수 있습니까? 그런 다음 공유 할 좋은 아이디어가 있습니다.

결론 1 : 요구 엔지니어가없는 프로젝트에서는 제안이있을 때 제안하는 것이 좋습니다. 민감성과 전술로 그것을하십시오-그것은 당신의 좋은 생각이 새싹에 빠져 있다는 것을 의미하더라도 갈등을 피하는 것이 필수적입니다.

그리고 요구 엔지니어와 팀을 이루고 있다면?

나는 모든 사람의 기능 아이디어를 듣는 것을 좋아합니다! 예, 때때로 개발자의 아이디어가 끔찍합니다 (사용자 인터페이스가 프로그래밍 로직을 따르도록하려는 경우). 제품 소유자의 아이디어는 종종 끔찍한 일입니다 (구두가 적은 예산으로 태양과 달을 원할 때-오, 사용자는 아무런 대가도받지 않고 최고의 데이터 품질로 개인 정보 페이지를 입력해야합니다). 그러나 팀의 모든 사람에게 적합한 사양을 제시하는 것이 저의 일입니다. 그리고 당신의 아이디어가 결코 효과가 없을지라도, 그것이 당신의 관심사임을 알고 있습니다. 제안하기 위해 잘못된 해결책을 선택했을 수도 있지만 이것이 귀하의 우려를 덜 유효하게 만들지는 않습니다. 당신이 그것을 발견했다면, 아마도 해결해야 할 것입니다 (또는 그것이 위협이 아닌 이유를 생각해 내야합니다). 사양을 담당하는 요구 엔지니어가 있다면 언제든지 주저하지 말고 제안하십시오. 그들이 당신의 말을 듣지 못한다면, 그들은 무언가 잘못하고있는 것입니다.

요구 사항 엔지니어는 각 이해 관계자의 관점에서 프로젝트를 개별적으로 (때로는 동시에) 봐야합니다. 우리는 인간 일 뿐이며 종종 실패합니다. 우리가 생각하는 관점 대신에 진정한 관점을 제공 할 수 있다면 여러분의 의견은 매우 소중합니다.

당신은 여기에서 당신의 행동에 더 자유로울 수 있습니다. 감성 춤을하는 것이 저의 일입니다. 공개적으로 공격하지 마십시오. 이로 인해 제 작업이 방해를 받지만, 자신이 느슨해 질 수 있기 때문에 자제력과 문화 / 통신 인식이 덜 필요합니다. 두 가지 상충되는 아이디어가 있고 어느 쪽이 더 나은지 판단 할 수없는 상황에서 당신은 떠 다니지 않습니다. 나는 그것을 알고 있어야하며, 그것이 효과가 없다면 그것은 올가미에 내 머리입니다.

결론 2 : 팀에 요구 사항 엔지니어가있는 경우 제품 기능 제안 사항으로 이동하십시오. 이번에는 벨벳 장갑이 필요 없습니다.

마지막으로, 요구 엔지니어가없고, 제품 소유자가 압도적이고 아이디어를 위해 고군분투하고, 사장님이 뾰족하게 당신을보고 있으며, 제안 할 아이디어가 없다면 어떻게해야합니까?

몇 가지 옵션이 있습니다. 하나는 당신이 언급했듯이 종료합니다. 모든 조직이 그렇게 작동하는 것은 아니며,이 환경이 적합하지 않은 경우 더 나은 환경을 찾으십시오. 장기적으로 도움이 될 것입니다.

기다렸다가 변경 사항이 있는지 확인할 수도 있습니다. 다음 프로젝트에는보다 숙련 된 제품 소유자 (또는 더 많은 리더십을 가진 사람)가있을 수 있습니다. 그러나 당신은 영원히 실속 할 수 없습니다.

세 번째 옵션은 실제로 일부 요구 사항 엔지니어링을 스스로 배우는 것입니다. 이것은 요즘 많이 찾는 기술입니다. 전임 요구 엔지니어 인 직책을 맡을 계획이 없더라도이 기술을 사용하면 팀 (및 사용자)의 다른 구성원을 더 잘 이해하고 만들 수 있으므로 개발자로서의 가치가 향상됩니다. 개발 과정이 더 순조롭게 진행됩니다. 그리고 당신은 그것의 전체 깊이에 갈 필요가 없습니다. 작업, 워크 플로우, 정신 모델 및 사용자 중심 데이터 모델을 설명하는 엔트리 레벨 교재는 이미 기업가 및 개발자 팀이 설계 한 소프트웨어에서 많은 개선 기회를 발견 할 수 있도록합니다. 님' t 가장 최근의 폴 번역을 영어로 번역하는 것과 같이 학계를위한 참고서로 쓰인 가장 두꺼운 책은 실제로 어떻게해야하는지에 대한 설명없이 작은 단계마다 가능한 모든 방법의 목록입니다. 실습 중심의 것을 선택하십시오.

당신이 그것을 시도하고 당신이 지역에 개인적인 관심이없는 것을 발견하면, 그것은 여전히 ​​괜찮습니다. 자신이 싫어하는 일을 강요하지 마십시오. 그러나 팀 구조가 다른 조직에서 일자리를 찾고있을 것입니다.

결론 3 : 직관적 인 이해를 얻기 위해 몇 년을 기다리는 대신, 한두 권의 책을 읽으면 이미 좋은 아이디어를 얻을 수있을 것입니다

예, 꽤 정상입니다.

구글에는 80 %의 업무-20 %의 혁신 모델이 있으며, 20 %의 사람들은 자신이 좋아하는 것에 헌신합니다. 이러한 방식으로 새로운 기능뿐만 아니라 완전히 새로운 제품 및 서비스를 얻을 수 있습니다.

너무 소극적입니까, 주도권을 잡고 제품 소유자에게 아이디어를 제공해야합니까?

그것은 당신의 성격에 달려 있습니다. 나는 정말 열정적 인 사람들과 함께 일했지만 8 시간 동안 쉬고 집으로 돌아가는 감정이없는 사람들과도 일했습니다.