Trong một thế giới lý tưởng, tốt nhất là đáp ứng thời hạn với ít lỗi hơn. Nhưng từ kinh nghiệm của bạn, đó là thích hợp hơn / chấp nhận được:

1. Đáp ứng thời hạn nhưng có một số lỗi vì nhà phát triển lao vào mọi thứ
2. Ít lỗi hơn nhưng không hoàn toàn đáp ứng được thời hạn vì nhà phát triển rất nghiêm ngặt trong việc viết mã

Câu trả lời cho câu hỏi này phụ thuộc rất nhiều vào mục tiêu kinh doanh, cũng như khách hàng.

Doanh nghiệp :

Nếu bạn đang làm việc với một khách hàng cấp doanh nghiệp được thiết lập tốt trên thị trường, họ sẽ không linh hoạt và không thể thích ứng với các thay đổi nhanh chóng. Do đó, sự ổn định là một yêu cầu tuyệt đối trong hầu hết các trường hợp. Có những trường hợp ngoại lệ cho nghiên cứu và phát triển và đi vào ngành dọc mới. Hoàn thành nhanh hơn đầu tiên trong một số trường hợp.

Những loại khách hàng này thường hiểu rằng phần mềm tốt cần có thời gian để phát triển và sẽ làm việc với bạn để thử và đáp ứng các mục tiêu.

Khởi nghiệp :

Đối với một khởi nghiệp mới, các quy tắc rất khác nhau. Là một người khởi nghiệp, bạn cần biết ngay nếu sản phẩm mà bạn đang xây dựng thực sự sẽ đáp ứng nhu cầu như nghiên cứu tiếp thị của bạn dự đoán. Đối với một công ty mới thành lập, việc đưa một nguyên mẫu ra thị trường càng nhanh càng tốt có thể thu được nhiều phản hồi có giá trị về hướng sản phẩm nên đi.

Nó cũng có thể thiết lập bạn là người dẫn đầu thị trường, giúp bạn có được thị phần có giá trị theo chiều dọc mới trước khi nó trở nên bão hòa với cạnh tranh.

Vì các công ty khởi nghiệp nhỏ, linh hoạt và có thể nhanh chóng thích nghi với sự thay đổi, mô hình này hoạt động tốt nhất cho họ.

Tóm lại, có những yếu tố khác để xem xét, nhưng ý tưởng chính là mỗi dự án đều khác nhau và sẽ có chất lượng và thời gian khác nhau để đạt được mục tiêu thị trường. Tùy thuộc vào sự lãnh đạo điều hành để xác định một chiến lược kinh doanh hiệu quả bao gồm phân tích kỹ lưỡng về chi phí cơ hội của việc lựa chọn phương pháp này so với phương pháp khác.

hoặc ... 3. Cắt chức năng không thiết yếu

Đôi khi, do kẹo kỹ thuật hoặc các tính năng kẹo được khách hàng yêu cầu, thời hạn rất khó để đáp ứng và vốn đã xuất hiện một loạt lỗi lớn hơn. Đó là các nguyên tắc KISS và YAGNI được áp dụng.

Trích dẫn từ cuốn sách này , "Làm lại", yếu tố cần thiết / cốt lõi / trung tâm từ phần mềm của bạn là những gì doanh nghiệp cần để hoạt động, giống như một quầy bán xúc xích có thể là một quầy bán xúc xích mà không cần lật đổ, những gì bạn không thể cắt bỏ là Những con chó nóng.

Tái đàm phán

Một trong những điều khó nhất để học là làm thế nào để giữ cho khách hàng hài lòng, và theo kinh nghiệm của tôi, điều này có thể dễ dàng thực hiện hơn với các lần lặp sản phẩm nhỏ hơn.

Đôi khi thời hạn yêu cầu phần mềm làm việc ở mức sản xuất nặng kể từ ngày đầu tiên. Người quản lý / khách hàng không phải lúc nào cũng biết (phần lớn thời gian) những gì họ thực sự cần cho phần mềm. Vì vậy, hãy cố gắng cắt giảm chức năng không cần thiết và giữ chất lượng. Cuối cùng, nó phụ thuộc vào mức độ quan trọng của môi trường sản xuất, nhưng cố gắng cắt bỏ các tính năng bổ sung và cung cấp chất lượng. Trích dẫn một lần nữa từ "Làm lại":

Làm sau cũng có nghĩa là làm tốt hơn

... và cũng đáp ứng thời hạn với ít lỗi hơn

Chà, bạn có thể đóng khung nó theo cách này: bạn muốn trả tiền cho chất lượng bây giờ hay sau này? Hoặc dành thời gian để làm điều đó tốt ngay từ đầu, hoặc dành thời gian sau đó để khắc phục tất cả các vấn đề. Tôi sẽ lập luận rằng giai đoạn sửa lỗi sau phát triển tính năng này có thể tốn kém hơn bởi vì nó cũng có thể rủi ro hơn và dễ bị các giải pháp hack hơn vì mã hiện có đã có và có thể không đủ chất lượng.

Đáp ứng thời hạn, và trình bày một danh sách các vấn đề đã biết .

Mọi người ghét tìm lỗi, nhưng nếu chúng được thông báo trước, chúng có xu hướng khoan dung hơn nhiều.

Điều này phụ thuộc hoàn toàn vào tình huống ....

Có nhiều yếu tố để xem xét:

1. Làm thế nào dễ dàng để tung ra các bản vá?
2. Có thể phát hành một phiên bản rút gọn cơ bản và sau đó vá chức năng mới (trường hợp cạnh) theo thời gian?
3. Văn hóa chung của ngành công nghiệp khách hàng cho một sản phẩm như vậy là gì? Họ có mong đợi các bản phát hành hoàn hảo một lần, hoặc họ đã quen với ý tưởng về một hệ thống phát triển có thể có lỗi khi phát hành lần đầu tiên?
4. Làm thế nào nhiều rủi ro cho doanh nghiệp làm một phiên bản ban đầu lỗi, trái ngược với thời hạn cuối cùng?

Nói tóm lại, không có câu trả lời trắng đen cho vấn đề này. Ví dụ: Đối với một cái gì đó giống như một hệ thống nhúng rất khó khăn và tốn kém để triển khai cho các thiết bị trong lĩnh vực này, tốt nhất bạn nên cố gắng chờ đợi (đàm phán lại thời hạn nếu có thể) và đưa nó ra ngoài không có lỗi. Mặt khác, đối với một cái gì đó giống như một hệ thống cổng thông tin web lớn (được viết dưới dạng một ứng dụng web) có thể dễ dàng nâng cấp bất cứ lúc nào bằng cách tung ra các bản sửa lỗi khi chúng ra mắt, có thể có ý nghĩa hơn khi phát hành một phiên bản tinh ranh ban đầu, và sau đó vá các vấn đề (và funcionality trường hợp cạnh) khi bạn nhận được nó.

Nhưng vào cuối ngày, theo kinh nghiệm của tôi, đây là một quyết định kinh doanh nhiều hơn là một quyết định công nghệ. Nếu bạn đang ở trong tình huống thiếu thời hạn là một vấn đề cực kỳ lớn, trong khi phiên bản ban đầu có lỗi không phải (hoặc ngược lại) - bạn sẽ muốn cân nhắc những điều này khi đưa ra quyết định.

LƯU Ý: Là một lập trình viên, tất nhiên tôi thích ý tưởng đánh bóng sản phẩm càng nhiều càng tốt trước khi phát hành nó (quái gì, tôi thà không có thời hạn nào cả, bao giờ;)). Nhưng thực tế, điều này là không thể trong cuộc sống thực. Thông thường, một bản phát hành ban đầu bị tước bỏ là một giải pháp trung gian tốt.

Tôi đã thấy rất nhiều Thủ tướng ngại nói với khách hàng rằng chúng tôi không thể đáp ứng lịch trình và khăng khăng chúng tôi giao hàng với các lỗi đã biết. Tôi có thể nói với bạn rằng mỗi khi họ nói với khách hàng, anh ta thường quan tâm nhiều hơn đến ít lỗi hơn và thời hạn chuyển đi. Tôi đảm bảo họ sẽ nhớ các lỗi nhiều hơn thời hạn bị bỏ lỡ trừ khi thời hạn hoàn toàn không thể điều chỉnh được (chẳng hạn như bắt đầu mùa nộp thuế khi bạn đang làm phần mềm thuế) hoặc sẽ ảnh hưởng đến một số điều khác sẽ rất tốn kém khi di chuyển (IMHO 98% tất cả các thời hạn không đáp ứng các tiêu chí này).

Tôi nghĩ rằng nó phụ thuộc vào lỗi. Bạn có muốn trì hoãn một bản phát hành để sửa lỗi trong đó ứng dụng gặp sự cố ngay khi nó khởi chạy trên bất kỳ máy tính nào không? Vâng chắc chắn. Bạn có cần sửa một lỗi chỉ xảy ra trên Windows ME trong khi có trăng tròn không? Điều đó có thể chờ đợi.

Nếu đó là một lỗi nghiêm trọng, tốt nhất là nên xử lý số 2. Lý do là chi phí khắc phục theo cấp số nhân sẽ tăng theo cấp số nhân nếu bạn phải đẩy bản sửa lỗi đó ra trong bản cập nhật.

Đối với các bản cập nhật ít quan trọng hơn, bạn có thể phát hành bản cập nhật đi kèm giúp giảm chi phí ở một mức độ nào đó.

Khi nghi ngờ, tôi nói bạn đi với số 2, nhưng tôi sẽ không ngạc nhiên khi nhận được phản hồi từ ban quản lý với cách tiếp cận đó. Tôi nghi ngờ rằng các nhà quản lý có xu hướng được đánh giá nhiều hơn bằng cách họ đáp ứng thời hạn tốt hơn so với việc họ không gây ra các cập nhật quan trọng không cần thiết.

Cũng không. Tại sao không nướng chất lượng với mã của bạn? Có thể đáp ứng thời hạn với mã chất lượng? Bạn có thể đẩy ra ít tính năng hơn, nhưng nếu chất lượng được đưa vào quy trình, bạn có thể đạt được cả hai.

Điều xảy ra bây giờ là bạn sẽ cần một người lãnh đạo nhóm được trao quyền hoặc người quản lý dev, người có thể đẩy lùi doanh nghiệp và có cuộc trò chuyện xung quanh 2 điều:

1. Chất lượng nướng thành mã = ​​2 tính năng ít hơn trên mỗi bản dựng
2. Ưu tiên các tính năng cần thiết cao nhất từ ​​các bên liên quan như những gì họ THỰC SỰ cần.

Sau đó, bạn có thể tập trung vào các tính năng giá trị cao nhất và đẩy chúng ra một cách xuất sắc.

Theo như thử nghiệm thì không bao giờ kết thúc. nó đã kết thúc nhưng không bao giờ kết thúc

Đi cho ra mắt với các lỗi với mức độ nghiêm trọng và ưu tiên nhiều hơn được chăm sóc.

Đáp ứng thời hạn với rất nhiều lỗi khiến bạn kém trong ngành và khách hàng sẽ không đến với bạn nữa. Bạn có thể nói chuyện với khách hàng để nhận được sự chậm trễ trong hai hoặc ba ngày.

Nếu bạn xem xét điều này từ người dùng cuối cùng, tôi sẽ khá thất vọng nếu ai đó hứa sẽ làm điều gì đó vào thứ hai và khi tôi cố gắng sử dụng thì nó không hoạt động, hoặc tất cả đều có lỗi.

Nhưng nếu bạn nhìn vào khía cạnh "thủ tục", điều đó có nghĩa là ứng dụng cần thử nghiệm nhiều hơn và là một phần của cuộc sống tự nhiên của phần mềm.

Cách tiếp cận tốt nhất của tôi là cố gắng làm mọi thứ hoạt động theo cách chúng nên hoạt động (nếu là mô-đun chính, không chú ý đến chi tiết, đăng nhập dưới dạng nên đăng nhập nhưng bất kỳ ai cũng sẽ bị tắt nếu bạn không hiển thị thông báo sau đó).

Đây là một câu hỏi chỉ bạn có thể trả lời. Nó phụ thuộc vào loại sản phẩm, khách hàng là ai, khách hàng yêu cầu gì, v.v. Không có cách nào để chúng tôi đưa ra câu trả lời 'a hoặc b' đơn giản. Tình hình hoàn toàn phụ thuộc.

Nhưng tôi sẽ nhắc nhở bạn rằng chi phí sửa lỗi sau khi phát hành cao hơn nhiều so với sửa lỗi trước khi phát hành. Vì vậy, yếu tố trong khi quyết định có nên đợi đến khi phát hành bài để sửa lỗi hay không, vì bạn sẽ tốn nhiều thời gian / công sức / tiền hơn cho nó.