언제 프로젝트를 완수하기 위해 디자인의 "청결성"을 희생해도 되는가?

조만간 완료되고 잘 작동해야하는 제품을 작업 할 때 신속하게 작업을 수행하고 문 밖으로 나가기 위해 설계의 유지 관리 성과 "청결성"을 희생해도 되는가? 그리고 "정확하게"만드는 데 사용 된 기술이 나에게 새로운 경우에는 어느 정도 괜찮습니까?

사업을 지원하기 위해 고용되어 있음을 기억하십시오. 어떤 식 으로든 소프트웨어가 비즈니스의 수익성에 영향을 미칩니다. 기술적으로 완벽한 솔루션과 제품 출시 시간 및 비즈니스에서 얻을 수있는 이점 간의 균형을 유지해야합니다.

내 경험상 개발자는 종종 기술적 완벽성에 대해 걱정하고 있습니다. 그러나 제품을 더 빨리 출시하기 위해 유지 관리 성 또는 성능과 같은 품질 속성을 희생해야하는 매우 유효한 이유가 있습니다. 비즈니스와 제품에 따라 다릅니다. 그러나 "항상 완벽한 디자인을 추구합니다"는 너무 단순한 접근 방식입니다.

하루가 끝나면 중요한 것은 비즈니스 가치입니다. 단기 및 장기적으로이를 극대화하고 목표를 달성하는 방법을 파악하십시오.

"기술 부채"라는 용어는 이와 같은 비즈니스 결정에 도움이되는 데 매우 편리합니다. 지금하지 않은 작업은 나중에 어느 정도의 작업을 유발합니다. 재정과 마찬가지로 부채를지는 것은 위험하지만 나중에 빚을 갚을 수 있다면 레버리지 가치가 있습니다.

그러나 기술 부채는 투자 회수 시점의 1 : 1 비율이 아닙니다. 릴리스 후 버그를 수정하는 데 비용이 많이 들며 지저분한 레거시 시스템에서 개발할 때 향후 생산성에 미치는 영향은 엄청날 수 있습니다. 오류 수정 시간을 두 배로 늘리거나 인력과 자원의 1,000 배를 소비 할 수 있습니다.

이 결정에서 당신의 임무는 당신이 고려하고있는 특정 코너 절단 부분의 파급 효과를 이해하고 그 파급 효과를 사업 결정을 내리는 사람들에게 알리는 것입니다. 이 특정 추정 기술은 현재 잘 개발하기 위해 많은 연구와 노력을 기울일 수 있지만 경력 중에는 매우 중요합니다.

수락되고 결과가 소유자 / 클라이언트 / 사용자에 의해 이해 될 때.

배관공은 수리를 위해 쓰레기 처리를해야합니다. 그동안 싱크대를 사용하고 싶지만, 부러 질 수있는 테이프를 사용하여 임시 파이프에 넣을 시간과 재료에 대해 요금을 청구해야했습니다. 또한 수리점으로의 처분을 지연시킬 것입니다. 막힐 위험이 있음을 이해하고 추가 청구를 수락하는 경우 처분을 수리하는 데 하루가 더 걸리고, 그것을 되돌릴 수 있기까지는 더 오래 지연 될 수 있습니다.

당신은 지금 시간과 예산에있을 수 있지만, 장기적으로 더 높은 비용을 희생 / 위험하게합니다. 이는 기술이 아닌 사람들이 이해하기 어려울 수 있지만 영업 직원에게는 적합합니다.

많은 사람들이 새로운 것을 배울 때 신속하게 포기하고 항상 해왔 던 방식으로 행동합니다. 이것이 패턴이라면 코드가 손상 될뿐만 아니라 프로그래머로서의 자신의 기술도 제한적으로 유지됩니다.

그러나 하루가 끝날 무렵에는 성공적인 소프트웨어 만 배송됩니다.

소프트 마감일이 지난 후. 그리고 그때조차도 그것은 "OK"의 매우 낮은 정도입니다. 어려운 마감일이 지났을 때, 물론 그것은 헛소리입니다. 그것이 어려운 마감일의 본질이기 때문입니다.

또한 기술 부채가 발생합니다. 모든 시간 / 일마다 git-er-done 사고 방식으로 코너를 절단하는 데 다음 번에이 프로젝트를 수행해야 할 때 대략 두 배의 시간이 소요됩니다. 만약 당신이 서두르고 출동 한 후 즉시 모든 오리 테이프를 고치기 시작하는 것이 가장 좋습니다. 몇 년 후 해킹 된 프로젝트로 돌아 오는 것은 악몽입니다. 다시는 만지지 않을 것이므로 아무도 신경 쓰지 않을 것입니다. 그러나 내가 영원히 프로젝트를 떠난 것은 직업을 바꿀 때뿐입니다.

그러나 이러한 일을 타이밍하는 것은 프로젝트 관리자의 임무입니다. 마감일을 맞추기 위해 서두르면 PM의 잘못입니다. 올바르게하고 한 번만하고 침착하고 올바르게하십시오. 인생은 다른 것에 비해 너무 짧습니다.

여기에 게시 된 다른 모든 답변이 좋습니다. 나는 프로젝트의 개발자로서 당신은 디자인의 청지기 (보호자)라고 덧붙이고 싶습니다.

적절한 기술 솔루션에 맞지 않으면 아무도 약속하지 않습니다. 상사에게 올바른 방식으로 일을한다고 항상 주장해야하며, PM은 마감 시한을 항상 주장해야합니다.

합당한 조직에 있다면 마감 시간을 맞추는 데 도움이되고 디자인에서 너무 멀어지지 않는 절충안에 도달 할 수 있기를 바랍니다.

그 말로 PM의 마감 기한에 도달하지 않으면 세상이 끝나고 프로젝트가 실패한다고 가정하지 마십시오. 일반적으로 흑백이 아니며 PM의 마감 기한이 부드럽고 조정의 여지가 있습니다.

내가 PM 일정에 따른 거의 모든 마감일은 대부분 인공적인 것이었다. 그들은 이빨과 못을 방어하고 그렇지 않으면 다른 척을합니다. 왜냐하면 PM이 마감 시한을 맞추면 PM이 나 빠지기 때문입니다!

PM이 나빠 보인다고해서 프로젝트가 실패한 것은 아닙니다. 이것을 이해하면 PM을 얼마나 많이 구부릴 수 있는지 놀랄 것입니다.

깔끔한 디자인의 고객을 인용하십시오. 해당 견적을 받아 들일 수없는 경우 각 구성 요소의 비용 (일반적으로 비용 == 개발 시간)을 분석하십시오. 그들이 선택한 경우 "일품 요리"에서 물건을 가져 가도록하십시오. 많은 사람들이 테스트 나 디자인과 같은 "쓸모없는"것들을 위해 시간을 허비 할 것입니다. 이 방법의 위험에 대해 설명하지만 위험을 받아들이면 지시에 따라 진행하십시오. 만약 내가 어리석은 차를위한 충분한 돈을 가지고 있다면, 어쩌면 8 개월 안에 고장날 것이라는 것을 알고 있더라도, 나는 어리석은 차를 살 것입니다. 고객은 이러한 위험을 평가하고 그 결과를 수용 할 책임이 있습니다.

당신이 원하지 않는 한 가지는 클라이언트가 테스트되지 않은 쓰레기에 대해서만 지불하고 수령했을 때 아름답게 설계된 소프트웨어를 가지고 있다고 생각하게하는 것입니다. 문제가 발생하면 (첫 번째 시나리오에서는 문제가 발생하지만) 두 번째 시나리오에서는 문제가 발생합니다.

그것은 없다 결코 좋아, 그러나 때때로 당신은 프로젝트를 마무리를 위해 타협해야합니다. 슬픈 현실은 대부분의 비즈니스맨이 완전히 무지하며 나중에 유지 보수성을 기꺼이 희생하려는 것 이상이라는 것입니다. 요령은 균형을 잡는 방법을 아는 것입니다. 어쩌면 프로젝트는 가능한 한 깔끔하지 않을 수도 있지만, 돼지 저금통이 아닌 한 가치있는 타협입니다.

그것은 "당신이나 다른 누군가가 나중에 그것을 수정하고 싶습니까?"라는 질문에 전적으로 달려 있습니다. 그렇다면 "정확한"디자인을 시도해야합니다. 그렇지 않으면 6 개월 후에 모든 것을 버리고 다시 시작할 위험이 있습니다.

물론, 당신은 깔끔함을 너무 멀리 취할 수 있지만 일반적으로 약간의 깔끔함은 나중에 작업을 저장합니다.