내가 일하는 회사가 출시 일정을 구현하기 위해 노력하고 내가에 나보다 더 구조화 된 환경에서 일하는 사람들에서 일부 건설적인 피드백을 얻을 싶어요.는 출시 일정을 구현
우리는 하나 개의 제품이 완성되고 여러 고객이 사용하고 있지만, 우리는 작품에 4 개의 추가 제품을 보유하고 있으며 마치 완성 된 것처럼 적극 판매됩니다. (상상해보십시오!)
우리는 매우 작은 회사 (예 : 때때로 엉성함)와 엄격한 마감 기한과 엄격한 예산으로 작성된 요구 사항, 체계적인 품질 보증 프로세스, 기본적으로 회사의 소유자는 개발자 (3 명)에게 아이디어를 제공하고이를 구현합니다. 그런 다음 주제 분야 전문가가 기능을 테스트하여 앱이해야 할 일을하는지 확인합니다.
나는 마지막 단락에서 모든 종류의 "당신이이 방법대로"할 수는 없다는 것을 알고있다. 그러나 나는 그런 필요가 없다. 나는이 접근법이 얼마나 틀린 지 이해합니다. 어느 시점에서 나는 프로젝트 관리자와 품질 보증 담당자를 고용 할 소유자를 알릴 수 있었지만 짧은 시간이 지나면 수익 손실로 인해 해고당했습니다. 우리는 우리가있는 곳이며,이 시점에서 문화가 바뀌지는 않습니다.
내가하려는 것은 기대를 관리하는 것입니다. 우리는 마일 길이의 요청 된 기능 목록을 가지고 있으며 여기에 제가 제안한 것들이 있습니다.
우리는 완제품 생산에 분기별로 석방 할 것입니다. 첫 번째 릴리스는 10 월에 나올 예정입니다. 중/저/낮음 우선 순위를 기준으로 현재와 다음 사이에 수행 될 작업을 관리하기보다는 현재와 9 월 사이에 완료 할 수있는 작업과 수행 할 수없는 작업을 기반으로 기능을 관리합니다. 이 시점에서 우리는 모든 기능 개발을 중단하고 다음 달에 출시 될 제품을 출시하기 위해 결함 테스트 및 수정에 집중할 것입니다. 매 분기마다이 과정을 반복하겠습니다. 기본적으로이 단계는 다음과 같습니다.
1) 모든 중요한 기능을 얼마나 중요한지에 따라 향후 릴리스에 배치하십시오. 2) 분기 중에 이러한 기능을 사용하십시오. 3) 새로운 기능이 요청되면 특정 릴리스주기의 "대기열"에 배치하십시오. 4) 기능이 현재 릴리스로 이동해야하는 경우 다른 기능을 다음 릴리스로 이동하십시오. 5)주기 중에 특정 시점에서 현재 출시되지 않은 기능을 평가하고 그에 따라 조정하십시오. 6) 생산 예정일 최소 30 일 전에 기능 개발을 끝내고 테스트 및 버그 수정에 집중하십시오. 7) 예정된 날짜에 무언가를 생산에 적용한 다음 처음에 합의한 모든 작업을 완료하지 못한 것에 대한 열을가집니다. (이봐, 나는 현실적입니다. 내가 일하는 사람들은 그렇지 않습니다.)
아, 또한, "새로운 일자리를 구하십시오"라고 말하면 대답을 귀찮게하지 마십시오. 지금은 옵션이 아닙니다.
제안 된 접근 방식이나이 프로세스를 구조화하는 방법을 더 잘 이해하는 데 도움이 될만한 리소스에 대한 링크가 있으면 크게 감사하겠습니다.
미리 도움을 주셔서 감사합니다.
다르비스
"나는 할 수 없다."라고 말하면 모든 좋은 답변을 제거했습니다. "이 미분 방정식을 풀어 라. 그러나 수학은 사용할 수 없다." :) – BobbyShaftoe