어떻게 "이것은 작은 응용 프로그램이 될 것입니다"? 그래 맞아?

좋아, 나는 이것을 여러 번 겪었지만 여기에 최악의 시나리오가 약간 과장되어있다.

고객이 "작은 작업을 수행하기 위해이 작은 모듈을 만들 수 있습니까?"라고 말합니다.
나 : "확실히 문제 없습니다".

따라서 예산과 제약 등을 바탕으로 일부 아키텍처를 건너 뛰고 바로 땀을 흘리지 않습니다.

그런 다음 다른 모듈을 요청합니다. 그리고 또 다른. 그리고 일부 향상되었습니다. 그리고이 모든 일은 몇 년에 걸쳐 매우 느리게 진행됩니다. 그리고 당신이 그것을 알기 전에, 당신은 끔찍하게 설계된이 괴물 응용 프로그램이 있습니다.

작은 일을하라는 요청을 받으면 어떻게합니까? 클라이언트가 계속 추가를 요구할 경우 (또는 둘 다) 계속 증가 할 것인지 여부는 알 수 없습니다.

그것은 단지 작은 응용 프로그램이기 때문에 물건을 과도하게 설계 할 수 없으며, 당신이 (내가 모든 목소리를 알고 있다는 점에서) 말하면 다른 곳으로 갈 것이다. -o-the-line 보안과 우려의 분리. 사실이 사실을 환상적인 blah blah blah로 만드는 의존성 주입 도구를 사용해 보자. "

그들은 "그렇습니다"라고 말하고 다른 사람에게 갈 것입니다.

예산, 시간 및 인식은 응용 프로그램 자체를 설계하는 것만 큼 중요합니다.

어떻게 접근해야합니까?

"작은 응용 프로그램으로 보이는 것의 최종 결과에 대한 모든 정보를 가지고 있지 않은 경우, 아키텍처 및 설계 결정을 조기에 피하는 방법은 무엇입니까? 나중에 부적절한가요?

나는 이것들 중 상당수를 만났으며, 내가 일반적으로하는 일은 정확히 당신이 한 일, 바로 뛰어 들어가는 것입니다.

그들이 더 많이 돌아올 때, 그것은 그들의 비즈니스 모델이 작동하고 있으며 조금 더 투자 할 의사가 있다는 것을 의미합니다. 그때 나는 그것들을 앉아서 (일반적으로 복잡성에 따라 세 번째 모듈) 나쁜 소식을 전합니다.

나는 테이블에 모든 것을 놓고 최신 모듈을 포함하여 전체를 다시 실행하고 비용이 얼마나 드는지 알려 주겠다. 그들은 일반적으로 처음에 약간의 충격을 줄 것이지만, 당신이 좋은 관계를 유지하고 물건이 효과가 있다면 큰 문제가되어서는 안됩니다.

그래도 다음 세 가지 사항을 이해해야합니다.

1. 그들이 완전히 다시 작성하는 것을 귀찮게하고 싶지 않다면 여전히 3 번째 모듈을 수행 할 것입니다. 몇 시간이 더 걸릴 수 있으며 청구 할 것입니다. 앞으로 다시 작성하는 것에 대해 실제로 생각해야한다는 점을 상기 시키십시오. 대기 시간이 길수록 비용이 더 많이 듭니다.

2. 실제로 다른 사람이 할 수 있도록 비용이 더 많이 듭니다. 새로운 사람은 자신의 요구와 단점을 최소한으로 이해하여 모든 것을 재 설계해야합니다. 이는 여분의 재 작성 시간과 그가 일을 잘하지 못할 위험을 의미합니다.

3. 당신이 빨리 돈을 벌려고하지 않습니다. 재 설계가 필요한 것.

BTW, 청구 습관이 지금 절반, 절반이 끝났을 경우 확장 지불 조건을 제공하는 것을 고려할 수 있습니다. 지금 반으로 변경하고 작업 할 기간 동안 잔액을 분할하십시오. 예산 문제가있는 경우 핀치가 줄어들 수 있습니다.

그에게 작은 응용 프로그램을 만들어 지불하십시오.

내 경험상 고객이 더 원할 경우를 대비하여 처음에 실제로 필요한 것보다 더 많은 시간을 투자해야합니다. 그러나 이러한 모든 추가 변경 사항이 실제로 발생할 수있는 가능성과 그에 따른 노력을 기울여야합니다 (비용을 지불합니까). 1 년 후 전체 앱이 완전히 교체 될 수 있습니다.

그리고 초기 아키텍처에 시간을 투자함으로써 자신에게 호의를 느끼게 될 수도 있습니다. 그러나 실제로 다른 모듈을 더 저렴하게 만들어 고객에게 호의를 베풀 수 있습니다.

성공한 각 모듈에 대해 고객에게 조금 더 청구하고 초기 프로젝트를 단계별로 리팩터링하지만 항상 고객의 요구에 맞도록하십시오.

이전의 답변은 좋으며, 정직하다면 아마도 내가 할 것입니다. 즉, 나는 당신이 원하는 것에 대한 가정 (및 직업 착륙 욕구)을 바탕으로 고객에게 적절하게 속하는 결정을 내린다는 점 에서이 접근 방식이 약간 불안합니다.

난 안 도와 느낌 일 수 해야 할 고객과 정직하게 제공 할 수있다 그들에게 1. 나는 빨리이 작업을 수행하고 (상대적으로) 싸게 지금 수 있습니다 선택합니다. 훌륭 할 것입니다. 작동 할 것입니다.하지만 앞으로의 개선 사항은 조금씩 더 비용이 많이 듭니다. 2. 더 많은 시간이 소요될 수 있습니다. 새로운 기능을 추가해야하는 경우 장기적으로 비용을 절약 할 수 있습니다.

이상적으로, 당신은 그들에게 야구장 시간 / 비용의 수치를 줄 수 있습니다. 그렇지 않으면 대화가 너무 학업 적 일 수 있습니다. 적어도 이전 프로젝트와 관련하여 토론을 구성하면 고객의 삶이 더 쉬워 질 것입니다 (그리고 고객의 삶을 더 쉽게 만드는 것이 최우선 순위가되어야합니다 :-)).

다른 사람들이 좋은 업무 관계를 맺었다는 의견은 제자리에 있습니다. 고객이 대화를 할 수없는 사람이라면, 지금이 일이 얼마나 필요한지 스스로에게 물어볼 때가 될 것입니다 ...

이 "반복"각각을 별도의 프로젝트로 취급합니다. 각각의 작은 모듈이나 추가가 완료되면 이러한 프로젝트를 종료해야합니다. 그런 다음 다른 것을 원할 때 서류를 작성하십시오. 시간이 지남에 따라 소프트웨어 비용이 높아집니다. 즉, 각 소규모 프로젝트에 대해 더 많은 비용을 청구합니다.

하나의 ... LONGGGGGG 프로젝트 대신 그것을 보는 한 가지 방법입니다.

아키텍처 및 디자인 결정을 조기에 피하는 방법을 피하거나 완화하는 방법은 나중에 완전히 부적절합니다.

당신은 할 수 없습니다 . 프로그래머는 심령술사가 아닙니다. 우리는 간단한 것을 예측하거나 UI 개선을 볼 수 있지만 클라이언트가 나중에 원하는 것을 모르는 것 이상으로 코딩 할 수는 없습니다 (광기가 보입니까?).

귀하의 질문에 비즈니스 프로세스가 있다고 언급했지만 좋은 프로세스인지 확실하지 않습니다. 다음은 몇 가지 사항입니다.

• 서면으로 그리고 예산으로 서명 된 모든 변경 사항 및 추가 사항이 필요합니다 .
  • 지불 할 청구서가 있기 때문에
  • 작문과 서명 부분은 그들이 실제로 원하는 것을 확인하고 프로젝트 도중 고객이 마음을 바꾸는 사소한 것들의 90 %를 줄입니다.

자란 제품

그것은 우리 모두에게 일어난다. 처음부터 다시 작성하는 것은 일반적으로 끔찍한 아이디어입니다. 특히 나중에 다시 수행 할 것을 고려할 때 특히 그렇습니다.

대신 사용자가 요청한 변경 사항을 계약했습니다. 원래 시간을 사용하여 기능에 대해 작업 시간을 추가하고, 전체 아키텍처를 개선하기 위해 시간을 한 번에 하나씩 조금씩 추가하십시오. 목표는 하나의 계약으로 아키텍처를 완전히 "고정"하는 것이 아니라 시간이 지남에 따라 천천히 칩을 만드는 것입니다.

실제로 중요한 부분에 중점을 두어 반복을 통해 코드 반복을 천천히 향상시킵니다.