Trong phát triển phần mềm tự do, các công ty nên có những hình phạt nào khi họ bỏ lỡ thời hạn? [đóng cửa]


12

Tôi đã nói chuyện với một nhà đồng phát triển.

Anh ta có một khách hàng muốn đảm bảo rằng anh ta giao hàng đúng hẹn. Khách hàng muốn hậu quả cho thời hạn bỏ lỡ.

Trong khi tôi không làm công việc tự do, tôi không thể đưa ra câu trả lời.

Vì vậy, câu hỏi của tôi là:

Những hậu quả nào mà bạn (dịch giả tự do) đồng ý với khách hàng của bạn nếu bạn bỏ lỡ thời hạn trên các sản phẩm của bạn (ngoài việc bị sa thải)?


2
Anh ta sẽ thật ngu ngốc khi chấp nhận bất kỳ hình phạt nào, ít nhất là không có điều khoản thoát ra dựa trên các yêu cầu thay đổi. Ước tính nhiệm vụ là không chính xác vào thời điểm tốt nhất, trước khi đưa vào quản lý thay đổi tài khoản. Về cơ bản. Chạy
Matt D

4
Vì vậy, khách hàng sẽ có một lợi ích tài chính trong việc bạn bỏ lỡ thời hạn? Nghe có vẻ không phải là một ý tưởng thực sự tốt. Điều này sẽ chỉ có ý nghĩa nếu khách hàng cũng bị tổn thất tài chính nghiêm trọng khi bạn đến trễ (như trong ví dụ về MainMa).
Doc Brown

2
Điều này có vẻ hoàn toàn chấp nhận được với tôi. Tôi khá bất ngờ trước những bình luận. Bạn mong đợi mọi người trả tiền cho công việc, không có thời hạn và không có động lực để đáp ứng thời hạn? "Ước tính nhiệm vụ là không chính xác" - nó không phải như vậy.
NimChimpsky

@DocBrown khách hàng có lẽ có lợi ích tài chính lớn hơn nhiều trong việc đáp ứng thời hạn, do đó trả tiền cho công việc với thời hạn. Đôi khi tôi thấy các lập trình viên không thích thời hạn và cấu trúc tuyệt vời. Hãy tưởng tượng có một nhà bếp mới được trang bị và cửa hàng nói oooooo không chúng tôi không thể cho bạn biết khi nào nó sẽ hoàn thành, sẽ chỉ tính phí cho bạn theo giờ. Tôi sẽ chạy một dặm từ đó. Lập trình không khác biệt về chất với bất kỳ dự án nào khác.
NimChimpsky

5
Nếu bạn đang trang bị một nhà bếp mới, bạn sẽ được trích dẫn xây dựng như thông số kỹ thuật. Nếu bạn bắt đầu thay đổi bề mặt cắt, gạch, vòi và vật liệu chìm bạn sẽ phải trả thêm phí cho cả vật liệu bị lãng phí và thời gian sử dụng. Thật dễ hiểu tại sao bạn bị buộc tội trong trường hợp này, có một mối quan hệ vật lý. Việc thay đổi các yêu cầu phần mềm thường không đi cùng với sự hiểu biết này và bất kỳ hợp đồng nào yêu cầu bạn cung cấp X theo Y trong đó X không bị đóng đinh chính xác là yêu cầu sự cố. Mọi thứ sẽ thay đổi, không thể giải thích cho điều đó là ngu ngốc.
Matt D

Câu trả lời:


25

Một trong những cách hiệu quả nhất: phạt theo ngày trì hoãn. Đây cũng là những gì được thực hiện cho các dự án lớn, hình phạt đôi khi là hàng ngàn đô la mỗi ngày.

Nếu thời hạn chính xác có vấn đề (ví dụ: nếu một người phát triển cho Thế vận hội Olympic, một ứng dụng web sẽ xử lý việc phát sóng sự kiện vào năm 2014, thì thời hạn sẽ là sự khởi đầu của Thế vận hội Olympic năm 2014), thì biện pháp hiệu quả có thể là một trường hợp khi dự án bị trễ, công ty hoàn toàn không được trả tiền, và cũng nên trả tiền phạt.

Nếu các biện pháp quyết liệt như vậy là không phù hợp, thì thực tế duy nhất là một khách hàng được trả lương cao sẽ rời đi nếu dự án bị chậm trễ có thể thực hiện thủ thuật.

Lưu ý cho khách hàng:

  1. Nhiều sự chậm trễ là lỗi của chính khách hàng. Nguyên nhân có thể là nhiều:

    • Không có SRS, nhưng thay vào đó, hai đoạn mô tả một cách thất vọng những gì khách hàng tưởng tượng là nhu cầu của mình (và tất nhiên, khách hàng không muốn trả tiền cho việc thu thập các yêu cầu, coi bước này là mất thời gian).

    • Đến hai tuần trước thời hạn cuối cùng và nói rằng dự án đã được thực hiện bằng Java cho đến tận bây giờ và sử dụng Oracle: bắt buộc phải viết lại bằng Python và sử dụng MySQL, vì khách hàng đã đọc một tạp chí ngày hôm qua nói rằng những công nghệ đó là tương lai.

    • Đi kèm với một loạt các yêu cầu mới trong mỗi cuộc họp. Điểm thưởng khi những yêu cầu đó mâu thuẫn với gần như mọi yêu cầu được đưa ra cho đến bây giờ.

  2. Giao tiếp tốt là điều cần thiết cho một dự án tốt.

    Nhiều sự chậm trễ khác là do thiếu giao tiếp. Thực tiễn khi khách hàng không có bất kỳ liên lạc nào trong nhiều tháng với công ty và chỉ mong được liên hệ sau khi sản phẩm được hoàn thành và đánh bóng mời một thảm họa.

  3. Gieo nhân nào gặp quả nấy.

    Có các quy trình cụ thể giúp giữ cho dự án được tổ chức, và thực tế, lập trình chỉ nên mất 10 đến 15% thời gian cho các dự án lớn và 15% đến 20% thời gian cho các dự án trung bình. Những dự án đó cũng nên được thực hiện bởi những người biết họ đang làm gì.

    Trong thực tế, khách hàng không sẵn sàng trả 800 đô la / ngày cho một nhà phân tích, người sẽ tạo ra kiến ​​trúc và thiết kế phần mềm và họ cũng không muốn trả tiền cho các bước khác. Một lập trình viên người Albania mới vui vẻ làm việc với giá 50 đô la / ngày có vẻ thuận lợi hơn nhiều.

    Đừng phàn nàn rằng dự án là một thảm họa khi bạn chỉ sẵn sàng trả tiền cho các dự án thảm họa.

  4. Đừng thương lượng thời gian cần thiết để thực hiện công việc.

    Tôi thường gặp các cuộc thảo luận như thế:

    Nhà phát triển: đưa ra các yêu cầu, tôi có thể cung cấp trong bốn tháng.
    Khách hàng: không thể. Dự án nên được thực hiện trong hai tháng.
    Nhà phát triển: tốt, trừ khi bạn cắt bỏ một số tính năng ...
    Khách hàng: Tôi không thể! Tất cả các tính năng là cần thiết. Tại sao bạn không thể thực hiện công việc trong hai tháng? Tôi đã liên lạc với một lập trình viên Ấn Độ, một người bạn của tôi, anh ta có thể giao nó trong một tháng rưỡi, và chỉ hỏi một nửa giá!

    Thời gian đàm phán là một công thức cho thảm họa.

  5. Biết ưu tiên của bạn.

    Hãy tính đến quy tắc 90%. Khi dự án được quản lý không chính xác, không có gì lạ khi thấy các nhà phát triển nói rằng họ đã thực hiện 90% dự án một tháng sau khi bắt đầu dự án. Sau đó, một tháng sau, nó vẫn còn 90%. Và một tháng sau.

    Điều này có thể có hai nguyên nhân:

    • Khi dự án không được thực hiện đúng, tức là 100% thời gian dành cho lập trình, để lại 0% cho các yêu cầu thu thập, kiến ​​trúc, thiết kế và thử nghiệm, điều xảy ra là các lập trình viên không biết gì về công việc phải làm và họ khám phá ra nhiệm vụ mới trong suốt cuộc đời của dự án. Chuẩn bị dự án sẽ giúp có một sự hiểu biết lớn hơn về tất cả các nhiệm vụ cần hoàn thành.

    • Khi khách hàng vội vàng, không có gì lạ khi một số công ty cung cấp nhanh một số thứ nhảm nhí, sau đó dành một lượng lớn thời gian để giải quyết lỗi. Một số công ty chỉ làm việc như vậy, điều này giúp họ duy trì tính cạnh tranh và nói rằng họ đã hoàn thành một dự án nhất định trong ba tuần, ngay cả khi sau đó, họ đã dành ba năm để giải quyết mớ hỗn độn.

    Bằng cách đặt các ưu tiên thẳng và yêu cầu dự án phải được thực hiện một cách chính xác giúp loại bỏ các công ty đó khỏi danh sách các ứng cử viên.


3
"Đừng phàn nàn rằng dự án là một thảm họa khi bạn chỉ sẵn sàng trả tiền cho các dự án thảm họa." Tôi có thể sử dụng nó? Đây là một bài btw tuyệt vời, và tổng hợp những rủi ro từ cả hai phía.
Matt D

+1 Điểm rất tốt. Ngoài ra, rất vui được đọc :)
Radu Murzea

5
@MattD: các câu trả lời trên Stack Exchange được cấp phép theo Creative Commons Attribution-ShareAlike 3.0 Unported, vì vậy, bạn có thể. Ngoài ra, vui lòng đọc một bài đăng liên quan trên blog của tôi: Định lượng thời gian và chi phí: Tại sao chúng ta luôn hiểu sai? , cũng như câu trả lời cho câu hỏi của tôi ở đây: lập trình
viên.stackexchange.com / q / 158640/6605

Tại sao không có phần 4, 5, 6, v.v. cho bài đăng trên blog đó?
Radu Murzea
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.