프로젝트에서 조심해야 할 운명의 경고 신호는 무엇입니까? [닫은] 경쟁 업체의 출현 오버 /

실패한 프로젝트를 수행 한 것은 사용 된 언어, 산업 또는 경험에 관계없이 대부분의 프로그래머가 공통적으로 가지고있는 몇 안되는 것 중 하나입니다.

이 프로젝트는 훌륭한 학습 경험, 영혼을 부수는 재앙 (또는 둘 다) 일 수 있으며 여러 가지 이유로 발생할 수 있습니다.

  • 마음의 경영 상 변화
  • 미숙련 / 자원 부족 팀
  • 개발주기 동안 우수한 경쟁 업체의 출현
  • 오버 / 언더 관리

이러한 두 가지 프로젝트를 수행 한 후에는 프로젝트가 실패 할 때 정확히 초기 단계에서 인식 할 수 있습니까?

나를 위해 큰 징조는 기능 크리프와 결합 된 단단하고 빠른 외부 마감일을 가지고 있습니다 . 지연된 기능 요청이 시작되고 최종 “전달 가능”항목에 추가되면 프로젝트가 제대로 계획되어 일정대로 진행되고있는 것을 본 적이 있습니다. 이 요청의 제안자들은 “단지 하나만 더”요구하지 않고 거의 방을 나가지 않아 콜럼 보라 는 별명을 얻었습니다 .

머리에 임박한 운명의 알람 벨을 설정 한 경고 표시는 무엇입니까?

답변

영웅적 코딩

늦은 밤에 코딩하고, 오랜 시간을 일하고, 초과 근무를 많이 보는 것은 무언가 잘못되었다는 확실한 신호입니다. 또한 내 경험에 따르면 누군가 프로젝트의 어느 시점에서 늦게까지 일하는 것을 보게되면 더 나빠질 것입니다. 그는 일정대로 자신의 기능 하나를 되찾기 위해 그것을하고있을 수도 있고 성공할 수도 있습니다. 그러나 이와 같은 카우보이 코딩은 거의 항상 계획 실패의 결과로 필연적으로 더 많은 결과를 초래할 것입니다. 따라서 프로젝트의 초기 단계에서 볼수록 결국 더 나빠질 것입니다.

답변

프로그래머가 “코드가 끔찍하기 때문에 처음부터 다시 시작해야합니다.”라는 논쟁에서 승리하기 시작했습니다. 성숙한 응용 프로그램에서.

더 잘 만들 수 있다고 생각하거나 문제를 더 완전히 이해한다고 생각할 수는 있지만 실제로는 그렇지 않습니다. 아 그리고 그 못생긴 패치들? 그것들은 재 작성에서 다시 도입 될 실제 문제에 대한 수정입니다.

또한 언젠가 6 개월 동안 작업 한 후 응용 프로그램을 시작할 때 기능의 거의 85 %와 버그의 150 %에 이르는 이유를 프로젝트 관리자에게 설명해야합니다.

답변

문제 해결사로서의 새로운 도구.

사람들이 익숙하지 않은 도구를 사용하기 시작하면 신경 쓰지 않지만 계속주의를 기울입니다. 그들이 도구에 광고 된 모든 혜택을 일정에 계획하기 시작하면 걱정이됩니다. 재미있는 예 :

  • 우리는 객체 지향 언어를 사용하려고 시도하기 때문에 한 달 일정을 단축 할 수 있습니다 (우리가 가진 모든 것이 c 개발자 임에도 불구하고).
  • 우리는이 새로운 스크럼을 시도해 볼 것입니다. 그것은 모든 프로세스 문제를 해결합니다!
  • 프로젝트가 반쯤 끝났다는 것을 알고 있지만 ORM을 새로운 것으로 바꾸면 어떻게 될까요?

새로운 기술과 관행은 훌륭하지만 거의 모든 이점을 얻을 수는 없습니다.

답변

나에게 가장 큰 문제는 바로 비즈니스가 서면 요구 사항을 시간 낭비로 간주 할 때입니다.

그래서 기본적으로; 서면 요구 사항 없음

죽음의 키스입니다.

답변

관리 연결 해제

마감일, 기능, 인력 등을 담당하는 사람들이 프로젝트를 담당하는 사람들과 연결이 끊어 질 때. 이것은 다음으로 이어질 수 있습니다.

  • 고객이 기능 비용을 이해하지 못하는 사람과 이야기 할 때 기능 크립
  • 새로운 개발자가 도움보다 방해가 될 정도로 늦게 프로젝트에 투입되는 Man-month syndrome
  • 마감 결정의 비즈니스 결과를 처리해야하지만 구현 결과는 다루지 않는 사람들이 만든 비현실적인 마감일.
  • 고객과의 커뮤니케이션이 중간에 관리에 의해 방해 될 때 문제를 해결하지 못하는 제품.
  • 잠재적 인 문제가 개발자와 관리 사이에 조기에 충분히 전달되지 않는 위험 관리 부족.

따라서 경영진이 프로젝트에서 관심이없는 것처럼 보이거나, 의사 소통이 잘되지 않거나, 고객의 말을 듣지 않거나, 개발자의 말을 듣지 않거나, 언덕을 향해 달려갑니다.

답변

  1. 주요 개발자가 떠나고 경영진이 신경 쓰지 않을 때

  2. 주요 개발자가 떠날 때 다른 개발자가 신경 쓰지 않는 경우

첫 번째는 일반적으로 팀 역학 ( “10x 수퍼 스타”, 괜찮은 프로그래머, 서로 상호 작용하는 방식)에 크게 영향을받지 않는 관리자를 나타냅니다.

두 번째 숫자는 일반적으로 나머지 개발자들에게 심각한 관심 부족을 나타냅니다.

답변

누군가가 일반적으로 경영진은 “우리는 할 시간이 없다”고 말합니다.

일반적으로 문서화 또는 코드 검토와 같이 시간이없는 것보다 앞서는 것 (모든 형태의 테스트를 포함하여 다른 어떤 것보다 더 많은 버그를 통계적으로 찾아서 수정)