개발자가 시스템의 이해 관계자입니까?

제품 개발자는 이해 관계자로 간주됩니까?

일반적으로 개발자는 소프트웨어 프로젝트의 이해 관계자입니다. 이는 용어 사전 정의 와 일치 합니다 . 다양한 간행물에서 이해 관계자에 대한 정의는 다음과 같습니다.

Karl Wieger의 소프트웨어 요구 사항 :

이해 관계자 프로젝트에 적극적으로 참여하거나 결과에 영향을 받거나 결과에 영향을 줄 수있는 개인, 그룹 또는 조직.

이안 솜 버빌의 소프트웨어 엔지니어링 8 :

이해 관계자 라는 용어 는 직간접 적으로 시스템의 영향을받는 개인 또는 그룹을 지칭하는 데 사용됩니다. 이해 관계자에는 시스템과 상호 작용하는 최종 사용자 및 해당 시스템의 영향을받을 수있는 조직의 모든 사용자가 포함됩니다. 다른 시스템 이해 관계자는 관련 시스템, 비즈니스 관리자, 도메인 전문가 및 노조 대표를 개발하거나 유지 관리하는 엔지니어 일 수 있습니다.

Roger S. Pressman의 소프트웨어 엔지니어링 : 실무자의 접근 방식 (6 판) 은 5 가지 그룹 또는 이해 관계자를 정의합니다. 비즈니스 문제를 정의하는 선임 관리자, 실무자를 구성 및 제어하는 ​​프로젝트 / 기술 관리자, 시스템을 엔지니어링하는 실무자, 요구 사항을 지정하는 고객 제공된 시스템과 상호 작용할 소프트웨어 및 최종 사용자를 위해.

Scott Ambler의 적극적인 이해 관계자 참여 : 민첩한 모범 사례 :

프로젝트 이해 관계자에 대한 나의 정의는 직접 사용자, 간접 사용자, 사용자 관리자, 선임 관리자, 운영 직원, 프로젝트 자금을 지원하는 "금 소유자", 지원 (헬프 데스크) 직원, 감사 자, 프로그램 인 사람입니다. / portfolio 관리자, 개발중인 시스템과 통합 또는 상호 작용하는 다른 시스템에서 작업하는 개발자 또는 소프트웨어 프로젝트의 개발 및 / 또는 배포의 영향을받는 유지 관리 전문가.

...

이 정의에서 나는 프로젝트를 수행하는 개발자를 제외하기로했다. 개발자가 자신이 작업하는 프로젝트에 중요한 지분을 가지고 있기 때문에 처음에는 이상하게 보일 수 있습니다. 예, 개발자는 프로젝트 이해 관계자입니다. 개발자와 프로젝트 이해 관계자를 계속 구별하는 이유는 무엇입니까? 용어를 구별하기 위해 편리한 용어를 원하기 때문에“개발자 이해 관계자”와“비 개발자 이해 관계자”를 좋아하지 않으며 프로젝트에서 다른 역할을 수행하기 때문입니다.

실제로, 나는 일반적으로 이해 당사자들을 그룹으로 나누는 것을 보았고 한 그룹에는 시스템을 구축하는 사람들이 포함되어있었습니다. 시스템을 구축 할 때 개발자는 다른 모든 사람의 요구와 균형을 이루어야하는 요구와 관심이 있다는 것을 인식하는 것이 중요합니다. 그러나 이것들은 우선 순위를 정하고 다른 모든 요구와 함께 고려해야합니다.

일반적으로 아니요, 그러나 예외가있을 수 있습니다. " 자신의 개밥을 먹는 것 "은이 경우 개발자가 직접 만든 것을 사용하여 어느 정도 이해 관계자가되는 주요 예외로 생각됩니다. 그러나 이것이 전체 개발자의 몇 퍼센트 이상인지 질문합니다.

예-계속 유지되고 유지 될 시스템의 경우. 개발자는 코드를 사용하여 초기 팀이 프로젝트를 종료 한 후에도 버그를 수정하고 새로운 기능을 도입 할 수 있습니다. 수명이 긴 시스템에 대한 중요한 요구 사항은 유지 관리 기능이며 개발자가 아닌 경우 누가 지분을 보유해야합니까?

이것이 스크럼과 관련하여 요청되면 아니오 ...

... 프로젝트 이해 관계자의 정의는 직접 사용자, 간접 사용자, 사용자 관리자, 선임 관리자, 운영 직원, 프로젝트 자금을 지원하는 "금 소유자", 지원 (헬프 데스크) 직원, 감사 인, 프로그램 / 포트폴리오 관리자, 개발중인 시스템과 통합 또는 상호 작용하는 다른 시스템에서 작업하는 개발자 또는 소프트웨어 프로젝트의 개발 및 / 또는 배포에 영향을받는 유지 관리 전문가 ...

이해 관계자는 현재 제품 개발 팀 외부의 한 형태 또는 다른 형태의 개인입니다. 팀 X에 있고 다른 개발자가 팀 Y에 있고 나중에 서로 상호 작용하는 다른 제품을 개발하고 있다면 서로의 제품에 대한 이해 관계자가됩니다.

약간의 인터넷 검색 후, 나는 이것이 대답 할 수없는 질문이라고 말해야합니다. 이해 관계자에 대한 정의는 없으며 소스마다 다르게 사용합니다.

Aaron에 의한 Scott Ambler의 언급에서 알 수 있듯이, 하나 이상의 방법론이이 용어를 완전히 피합니다. 다른 사람들은이를 여러 범주의 이해 관계자로 분류하려고합니다. 결과적으로 이해 관계자가 "관심있는 사람"이라는 일반적인 의미가 있지만 정확한 의미는 없어집니다.

그 관심사가 내 마음에 두 가지 의미 중 하나에 온다 :

• 응용 프로그램에서 기본 가치를 이끌어 낼 것으로 기대하는 사람들

또는

• 프로젝트 결과에 투자 할 사람들.

후원 기관은 어느 쪽의 정의에도 적합합니다. 최종 사용자가 후원 기관에 어떻게 적응 하는가는 또 다른 주제입니다. 지금은 머리카락을 쪼개지 않기 때문에 적합하다고 가정 해 봅시다. 프로젝트 팀의 누구라도 두 번째 의미에 적합합니다.

결국 중요한 것은 우리의 응용 프로그램에서 가치가 도출되고 스폰서가 최종 단어를 얻는다는 것을 이해합니다.

필자의 일반적인 생각은 개발자가 "이해 관계자"그룹에 집중하기를 원하는 사람들은 개발자가 기계에서 톱니로 취급되고 결과적으로 빈약하게 취급되는 상황을 보았 기 때문에 크게 관심이 있다는 것입니다. 요구 사항에 대한 피드백은 허용되지 않으며, 상당한 무급 초과 근무는 필수입니다. 등 예상보다 많은 시간과 정신을 포기하고 있기 때문에이를 투자라고 생각하는 사람들이 있습니다. 개발팀은 이해 당사자이므로 투자 = 지분을 생각하십시오.

결과적으로 저는이 용어의 팬이 아닙니다. "스폰서"는 분명하다. "이해 관계자"는 아닙니다.

그렇습니다. 제품이 완성 된 후의 위치가 이전과 다를 경우 이해 관계자입니다. 예를 들어, 개발자가 회사의 소프트웨어를 개발하기 위해 급여를받는 경우 제품이 제공되는 것을 변경하는 데 아무런 변화가 없기 때문에 이해 관계자가 아닐 가능성이 높습니다. 그러나 그가 성공한 제품에 따라 재무 상태가 달라지는 신생 기업의 파트너라면 그가 이해 관계자라고 주장합니다.

또 다른 예로는 개발자가 사용할 소프트웨어를 만드는 경우가 있습니다. 이 경우 소프트웨어가 올바르게 작동하는 데 관심이 있기 때문에 그는 이해 관계자입니다.

개발자는 실제로 시스템을 개발 한 사람과 시스템을 유지하는 사람 모두에게 이해 당사자 (생성물에 의해 영향을 받음)입니다. 전자는 신기술에 관심이 있고 기술 기반을 늘리는 반면 후자는 일반적으로 유지 관리해야하는 많은 수의 시스템을 따라갈 수 있기를 원합니다.

그러나 '합법적 인'이해 관계자는 또 다른 질문입니다. 요구 사항의 균형을 잡을 때, 모든 이해 당사자들은 그들의 만족이 해결되는 문제를 찾지 못할 것입니다. 귀사는 최고의 개발자를 잃을 까 걱정하고 있습니까? 개발자의 관심을 높이십시오. 그렇지 않은 경우 개발자는 토템 기둥에서 상당히 낮은 경향이 있습니다. 불행하게도, 이것은 유지 보수성도 무시하고 내일이없는 것처럼 기술적 부채를 쌓는 효과를 가져올 수 있습니다.

아니야, 그들은 그렇지 않아.

이해 관계자 : 프로젝트 또는 조직의 성공 또는 실패로 영향을받을 수있는 개인 또는 조직

출처 : http://www.site.uottawa.ca:4321/oose/index.html#stakeholder

기본적으로 이해 관계자는 개인 또는 조직이거나 간단히 말해서 "프로젝트 완료에 좋은 / 나쁜 영향을 미치는 개체"입니다.

프로젝트 성과에있어 이해 관계자는 매우 중요합니다. 이해 관계자는 고객, 사용자 그룹, 프로젝트 관리자, 프로젝트 리더 또는 코디네이터 일 수 있습니다.

프로젝트 완료시 이해 관계자의 기대를 충족시켜야합니다.

나는 그것이 프로젝트에 달려 있다고 생각합니다.

스테이크 보유자에는 시스템이하는 일에 대한 이해 또는 관심이있는 사람이 포함됩니다. 따라서 코드를 단순히 밀어 내고 잊어 버린 프로젝트에 개발자를 포함 시키지는 않지만 프로젝트를 지원하거나 확장하는 경우 개발자를 포함하여 개발자가 시스템을 유지 관리 가능 / 확장 가능하도록 요구합니다.