Làm thế nào để tiếp cận ol ', đây sẽ chỉ là một ứng dụng nhỏ? Vâng phải không?

Ok tôi đã gặp phải điều này nhiều lần, nhưng đây là trường hợp xấu hơn là hơi phóng đại.

Một khách hàng nói rằng "hey bạn có thể làm cho chúng tôi mô-đun nhỏ này để thực hiện nhiệm vụ nhỏ này không"?
Tôi: "Chắc chắn không có vấn đề".

Vì vậy, dựa trên ngân sách và các ràng buộc, v.v., tôi bỏ qua một số kiến ​​trúc và lặn ngay vào và làm cho nó không có mồ hôi.

Sau đó, họ yêu cầu một mô-đun khác. Và một cái khác. Và một số cải tiến. Và tất cả điều này xảy ra rất chậm tâm trí bạn, trong nhiều năm. Và trước khi bạn biết điều đó, bạn có ứng dụng quái vật này được kiến ​​trúc khủng khiếp.

Bạn làm gì khi bạn được yêu cầu làm một cái gì đó nhỏ? Bạn không biết liệu nó có tiếp tục phát triển không ... nếu khách hàng sẽ tiếp tục yêu cầu bổ sung (và họ cũng không).

Bạn không thể kiến ​​trúc sư quá mức, bởi vì cuối cùng nó chỉ là một ứng dụng nhỏ và họ sẽ đi đến một nơi khác nếu bạn nói (trong đó tôi biết tất cả giọng nói) "Trong trường hợp, hãy để kiến ​​trúc sư này thành lớp trên cùng - thực tế, chúng ta hãy sử dụng một công cụ tiêm phụ thuộc thực sự sẽ làm cho điều này trở nên tuyệt vời blah blah blah ".

Họ sẽ nói "đúng rồi" và đi đến một người khác.

Ngân sách, thời gian và nhận thức cũng quan trọng như kiến ​​trúc ứng dụng.

Làm thế nào điều này nên được tiếp cận?

Tôi đoán câu hỏi thực sự sôi nổi "Khi bạn không có tất cả thông tin cho kết quả cuối cùng của một ứng dụng nhỏ, làm thế nào để bạn tránh (hoặc giảm thiểu) việc đưa ra quyết định thiết kế và kiến ​​trúc sớm sẽ hoàn toàn không phù hợp sau này?

Tôi đã gặp khá nhiều trong số này và những gì tôi thường làm là chính xác những gì bạn đã làm, lặn ngay và hoàn thành nó.

Khi họ quay lại nhiều hơn, điều đó có nghĩa là mô hình kinh doanh của họ đang hoạt động và họ nên sẵn sàng đầu tư thêm một chút. Đó là khi tôi ngồi xuống (thường là mô-đun thứ 3 tùy theo độ phức tạp) và báo cho họ những tin xấu.

Tôi sẽ đặt mọi thứ trên bàn, đề nghị làm lại toàn bộ mọi thứ bao gồm cả mô-đun mới nhất và cho anh ta biết nó sẽ có giá bao nhiêu. Họ thường sẽ có một số cú sốc nhãn dán khi bắt đầu nhưng nếu bạn có một mối quan hệ làm việc tốt và công cụ của bạn hoạt động, đó không phải là một vấn đề lớn.

Hãy chắc chắn rằng họ hiểu ba điều:

1. Nếu họ thực sự không muốn làm phiền với việc viết lại hoàn chỉnh, bạn vẫn sẽ thực hiện mô-đun thứ 3. Bạn có thể mất thêm vài giờ nữa và bạn sẽ lập hóa đơn cho họ. Nhắc nhở họ rằng họ thực sự nên nghĩ về việc viết lại trong tương lai, vì họ càng chờ đợi lâu, chi phí sẽ càng cao.

2. Nó thực sự sẽ khiến họ tốn nhiều tiền hơn để khiến người khác làm điều đó. Người mới phải thiết kế lại mọi thứ với sự hiểu biết tối thiểu về nhu cầu và sự kỳ quặc của họ, điều đó có nghĩa là thời gian viết lại thêm và nguy cơ anh ta sẽ không làm tốt công việc.

3. Rằng bạn không cố gắng kiếm tiền nhanh chóng. Điều cần thiết kế lại.

BTW, nếu thói quen thanh toán của bạn giống như một nửa bây giờ, một nửa khi hoàn thành, bạn có thể xem xét cung cấp cho họ các điều khoản thanh toán mở rộng. Thay đổi nó thành một nửa bây giờ và chia số dư trong khoảng thời gian mà bạn sẽ làm việc với nó. Điều đó có thể giảm bớt sự chèn ép nếu họ có vấn đề về ngân sách.

Chỉ cần làm cho anh ta một ứng dụng nhỏ và được trả tiền cho nó.

Theo kinh nghiệm của tôi, việc đầu tư nhiều thời gian ngay từ đầu hơn là thực sự cần thiết, chỉ trong trường hợp khách hàng muốn nhiều hơn. Nhưng bạn phải cân nhắc hiệu quả trong việc thực hiện nó (bạn có được trả tiền cho nó không) so với khả năng mà tất cả những thay đổi bổ sung này thực sự sẽ xảy ra. Toàn bộ ứng dụng có thể được thay thế hoàn toàn sau một năm.

Và bằng cách đầu tư thời gian vào kiến ​​trúc ban đầu, bạn có thể cảm thấy rằng bạn tự giúp mình. Nhưng thực sự, bạn chỉ cần làm cho khách hàng một lợi ích bằng cách làm cho các mô-đun khác rẻ hơn cho anh ta.

Chỉ cần lập hóa đơn cho khách hàng của bạn thêm một chút cho mỗi mô-đun thành công và từng bước cấu trúc lại dự án ban đầu, nhưng luôn luôn chỉ để phù hợp với nhu cầu của khách hàng.

Câu trả lời trước là tốt và, nếu tôi trung thực, những gì tôi có thể sẽ làm. Điều đó nói rằng, tôi hơi khó chịu với cách tiếp cận này ở chỗ bạn đang đưa ra quyết định thuộc về khách hàng, dựa trên giả định về những gì họ muốn (và mong muốn có được công việc)

Tôi không thể giúp người ta cảm thấy nên làm là trung thực với khách hàng và cho họ lựa chọn: 1. Bây giờ tôi có thể làm điều này nhanh chóng và (tương đối) với giá rẻ. Nó sẽ rất tuyệt - nó sẽ hoạt động - nhưng các cải tiến trong tương lai sẽ có giá cao hơn một chút 2. Tôi có thể dành nhiều thời gian hơn cho nó trước, sẽ tốn thêm một chút và không thêm bất kỳ lợi ích thực sự nào cho người dùng, NHƯNG nó sẽ giúp bạn tiết kiệm tiền trong thời gian dài nếu bạn cần thêm các tính năng mới.

Lý tưởng nhất là bạn sẽ có thể cung cấp cho họ một số số liệu về thời gian / chi phí của công viên bóng - nếu không cuộc trò chuyện có thể quá hàn lâm - nhưng tôi đánh giá cao việc đến những con số này cũng có thể mất công sức. Ít nhất, việc đóng khung thảo luận về các dự án trước sẽ giúp cuộc sống của khách hàng dễ dàng hơn (và làm cho cuộc sống của khách hàng dễ dàng hơn nên là ưu tiên hàng đầu :-))

Những bình luận khác đã được đưa ra về việc có một mối quan hệ làm việc tốt được chú ý - nhưng bạn có thể bắt đầu quá trình đó bằng cách thành thật với chính mình. Nếu khách hàng là loại mà bạn thậm chí không thể có cuộc trò chuyện đó, thì bây giờ có thể là lúc bạn tự hỏi mình cần bao nhiêu công việc này ...

Tôi sẽ coi mỗi "lần lặp" này là một dự án riêng biệt. Bạn nên đóng các dự án này khi mỗi mô-đun nhỏ hoặc bổ sung được thực hiện. Sau đó, khi họ muốn một cái gì đó khác, hãy soạn thảo giấy tờ. Và khi thời gian trôi qua, phần mềm trở nên đắt hơn ... điều đó có nghĩa là bạn sẽ tính phí nhiều hơn cho mỗi dự án nhỏ.

Đó là một cách để xem xét nó, thay vì một ... dự án LONGGGGGG.

Làm thế nào để bạn tránh (hoặc giảm thiểu) đưa ra quyết định thiết kế và kiến ​​trúc sớm về điều đó sẽ hoàn toàn không phù hợp sau này?

Bạn không thể . Lập trình viên không tâm lý. Mặc dù chúng tôi có thể dự đoán những điều đơn giản hoặc xem các cải tiến UI, chúng tôi thực sự không thể viết mã vượt quá những gì chúng tôi không biết khách hàng có thể muốn sau này (bạn có thấy sự điên rồ ở đó không?).

Câu hỏi của bạn đề cập rằng nó có quy trình kinh doanh nhưng tôi không chắc liệu chúng có phải là quy trình tốt hay không. Đây là một số gợi ý:

• Yêu cầu tất cả các thay đổi và bổ sung được ký bằng văn bản và với ngân sách.
  • Bởi vì bạn có hóa đơn để thanh toán
  • Phần viết và ký đã đảm bảo đó là những gì họ thực sự muốn và cắt giảm 90% những điều phù phiếm mà khách hàng thay đổi suy nghĩ nửa chừng trong suốt dự án

Sản phẩm phát triển quá mức của bạn

Nó xảy ra cho tất cả chúng ta. Xây dựng lại từ đầu thường là một ý tưởng tồi tệ, đặc biệt là xem xét nó sẽ được thực hiện lại trong tương lai.

Thay vào đó, tôi ký hợp đồng cho những thay đổi mà người dùng yêu cầu. Thêm thời gian thêm cho mỗi tính năng, sử dụng thời gian ban đầu để làm việc trên tính năng và thêm thời gian để cải thiện kiến ​​trúc tổng thể, một cải tiến nhỏ tại một thời điểm. Mục tiêu không phải là hoàn toàn "sửa chữa" kiến ​​trúc trong một hợp đồng, mà thay vào đó là từ từ sứt mẻ nó theo thời gian.

Từ từ cải thiện mã lặp bằng cách lặp, tập trung vào các phần thực sự quan trọng.