기능 요청 및 소프트웨어 변경을 어떻게 관리합니까? [닫은]

저는 소프트웨어 엔지니어이며 지난 몇 년 동안 사실상 소프트웨어 프로젝트 관리자가 없었기 때문에 사실상 소프트웨어 프로젝트 관리자가되었습니다. 따라서 R & D / 엔지니어링 부서에서 우리의 정신을 유지하기 위해 고객은 자신의 요청에 대해 내게 익숙해졌습니다. 이 영역에 대한 경험이 없으므로 소프트웨어 프로젝트의 프로젝트 관리자로 활동 한 것은 이번이 처음입니다. 다른 것을 관리했지만 소프트웨어는 관리하지 않았습니다.

그렇다면 소프트웨어 프로젝트를 어떻게 관리하고 우선 순위를 표시합니까? 요청은 가끔씩 이루어 지므로 다른 사람을 위해 무언가를 작업 할 수 있고 다른 사람은 작업을 필요로하는 "러쉬"작업을 시작하게됩니다. First Come, First Serve라고 말하는 것이 더 쉬운가요 아니면 돈이 가장 많은 사람입니까?

고객이 자신의 개발자이기도 한 경우가 아니라면 고객의 요청이 얼마나 긴급한지에 대해 불평할수록 요청이 전혀 시급하지 않다는 것이 일반적으로 좋은 신호입니다. 대학 교수 중 한 명이 항상 긴급한 일을 중단시키지 말라고했습니다.

일반적으로 요청을이 순서 (YMMV)로 분류합니다.

1. 최근 업그레이드 또는 마이그레이션과 관련된 문제 (가장 중요).
2. 보안 수정.
3. 기존 시스템의 기능이 손상되었습니다.
4. RC 및 베타 기능의 기능이 손상되었습니다.
5. 유료 기능 요청.
6. R & D 기능은 사용자 기반의 많은 부분에서 요청합니다.
7. 한두 명의 사용자 만 R & D 기능을 요청할 수 있습니다.

이 마지막 것은 "긴급한 어제 필요"요청 인 경향이 있기 때문에 실제로 더 많은 시간이 걸립니다. 실제로, 사용자는 실제로 필요한 것 또는 비즈니스 모델을 어떻게 지원할 것인지에 대해 완전히 생각하지 않았습니다. 대부분의 경우, 이러한 긴급 요청은 일단 전달되면 한두 번 사용되어 잊혀지 게됩니다. 그리고 잊어 버리면 끝없는 보안 허점과 의도하지 않은 결과가 초래됩니다.

나는 원칙을 좋아 한다.

1. QI-중요하고 긴급한
2. QII-중요하지만 긴급하지 않은
3. QIII-중요하지 않지만 긴급
4. QIV-중요하지 않고 긴급하지 않은

1. 기능 / 버그 / 요청 추적 시스템을 설정하고 고객 / 동료에게 티켓을 제출하도록합니다. 그들이 티켓을 제출하지 않으면, 당신은하지 않습니다. 티켓 은 실행 가능할 정도로 상세해야하며 "긴급"( "지금 필요"대 "좋은")을 지정해야합니다.
2. 새 티켓을 통해 신중하게 범위를 지정하십시오. 티켓의 비용을 달러, 개발자, 리소스 및 / 또는 시간으로 입력하십시오. 이것은 필수 입니다. 고객이 실제로 비용 이 얼마나 드는지 알게되면 "긴급"필드에서 매우 다른 선택을 보게됩니다.
3. 매일, 제출 된 항공권과 긴급성에 따라 일정을 파악하십시오. 일정을 다른 사람이 볼 수있게하여 현재 상황과 향후 요청에 대한 가용성을 명확하게하십시오.

요구 사항 변경이 매우 무거운 변경 제어 시스템으로 관리되는 프로젝트를 보았습니다. 이것은 나쁘다. 고객이 변경 제어를 제출해야하는 번거 로움을 겪지 않기 때문에 많은 중요한 변경이 발생하지 않으므로 소프트웨어가 요구 사항과 일치하지 않습니다. 프로세스를 피하기 위해 "레이더 아래"에 약간의 작은 변경 사항이 적용되어 소프트웨어가 사용자의 생각과 일치하지도 않습니다.

반대로, 프로젝트 관리자가 "반응 적"이라고 생각하는 프로젝트는 코더가 사용자의 모든 요청에 ​​응답하도록하는 것을 의미합니다. 핵심 개발을 결코 수행하지 않으며 코드가 해킹의 큰 혼란에 빠지게됩니다. 마구 자르기. 기본적으로 이제 개발자가 없으며 자격을 갖춘 영업 엔지니어 팀이 있습니다.

따라서이 두 극 사이에 잘 ​​작동하는 상황이 있기를 바랍니다. 나는 당신에게 가장 적합한 것이 개인적 선택이며 위치가 있다고 기대합니다. 각 변경의 비용을 캡처하는 데 확실히 가치가 있습니다. Scrum과 같은 프레임 워크에서 스토리 포인트로 비용을 표현할 수 있으며 팀은 각 반복에서 수행하는 작업과 총 가용 노력을 교환 할 수 있습니다. 제품 관리자가있는 경우 해당 담당자에게 변경 또는 기능 요청의 예상 이점을 수량화 할 수 있습니다. 이는 일반적으로 보호 된 수익 (이를 수행하지 않으면 몇 명의 고객이 떠나는가) 및 이목을 끄는 수익 (이를 수행하면 몇 명의 고객이 도착할 것인가)에 따라 수행됩니다. 이는 우선 순위 결정에 도움이 될 수 있지만 제품 관리자의 편견이나 개인적 선호도를 반영 할 수도 있습니다.

여기 몇 가지 생각 ...

당신을 도와줍니다 시장에서 많은 소프트웨어가 http://www.fogcreek.com/ XPM로 Fogbugz에, GeneXus 미국과 http://www.genexususa.com/xpm 등

새로운 기능 요청과 버그 수정 및 자신의 아이디어의 균형을 맞추는 것은 예술과 같습니다. 다음 겨울에는 음식을 먹어야하지만 오늘도 먹어야합니다.

당신은 시간, 자원 및 범위를 가지고 그것을 최대한 활용하십시오.

헨리 포드 (Henry Ford)는 또한 한 번 유명한 말로“고객의 말을 들으면 더 빠른 말을 주었을 것입니다.”

개인적으로 : 역동적이고, 당신이 말한 것과 같은 규칙을 세우지 말고 다른 사람들의 규칙에주의하십시오.

이제 우리는 현재 프로젝트와 향후 또는 향후 기능 요청에 대해 논의하기 위해 2 개월에 한 번씩 영업 / 엔지니어링 회의를 가졌습니다. 영업 엔지니어는 프로젝트 관리자가되고 최소한 최신 제품 오퍼링에 맞춰 조정됩니다. 과거에는 엔지니어링 부서에 전달하고 잊어 버리는 것이 쉬웠습니다. 이것은 소프트웨어 엔지니어가해야 할 부하를 줄이고 영업 시간을 현명하게 사용하기 위해 영업 및 관리에 부담을 줄 것입니다.

내가 일하는 회사는 프로젝트 관련 측면을 처리하는 JIRA라는 웹 기반 도구와 rfc 기능을 통해 변경 요청을 처리하는 헬프 데스크 시스템이라는 두 가지 주요 응용 프로그램을 사용합니다.

지금까지 내가 본 대답은 좋습니다. 내가 구체적으로 설명 할 한 가지 사항은 일부 요청에 "아니오"라고 말해야한다는 것입니다.

고객이 긴급 성을 설정하도록 허용하면 거의 항상 "높음"이상이됩니다.

귀하 (설정에 따라 귀하 또는 팀)는 이러한 요청을 평가하고 자신의 기준에 따라 우선 순위를 정해야합니다.