Phát triển phần mềm linh hoạt: Làm thế nào để bạn phản ứng * về mặt tài chính * với việc thay đổi yêu cầu của người dùng?

Có một điều tôi luôn tự hỏi khi đọc về tất cả những thứ "phát triển nhanh" này ở đây trên SE và các trang web khác:

Trong kỹ thuật phần mềm "truyền thống", bạn

1. thu thập các yêu cầu của người dùng,
2. viết một đặc tả dựa trên những yêu cầu này
3. đưa nó cho khách hàng và lập hóa đơn cho anh ta cho công việc được thực hiện cho đến nay,
4. làm một thiết kế kỹ thuật (thô), để bạn có thể ước tính chi phí thực hiện,
5. cung cấp cho người dùng một báo giá cho việc thực hiện,
6. chờ khách hàng ký tên vào thông số kỹ thuật và chấp nhận đề nghị,
7. thiết kế, thực hiện, thử nghiệm,
8. hóa đơn.

Nếu trong quá trình, các yêu cầu thay đổi, bạn gửi một đề nghị (có giá) cho các thay đổi mong muốn (hoặc thực hiện miễn phí nếu thay đổi nhỏ, bạn thích khách hàng và khách hàng không làm điều đó quá thường xuyên) .

Vì vậy, làm thế nào để công việc này (về mặt tài chính) trong một dự án nhanh, trong đó những thay đổi yêu cầu thường xuyên là một phần của quy trình?

• Bạn có viết một đề nghị cho mỗi thay đổi thiết kế? (Đây có phải là một mớ hỗn độn không?)
• Hay bạn thương lượng một mức giá cố định và hy vọng rằng khách hàng không thay đổi các yêu cầu quá thường xuyên? (Có thể có rủi ro, tôi biết những khách hàng sẽ sử dụng cơ hội này để yêu cầu các tính năng mới trong nhiều năm trước khi chấp nhận rằng dự án đã hoàn thành.)
• Hay bạn chỉ lập hóa đơn cho khách hàng trong tổng thời gian cần thiết? (Có thể gây rủi ro cho khách hàng, người không biết trước chi phí.)

Trong một thế giới Agile lý tưởng, bạn đồng ý giá trước và một số giờ, nhưng không phạm vi. Khách hàng quyết định sản phẩm hữu ích tối thiểu là gì, thay vì sản phẩm họ thực sự muốn, và điều đó sẽ ước tính rất ngắn số giờ đã thỏa thuận.

Sau đó, bạn giao hàng cho họ lặp đi lặp lại và họ thay đổi suy nghĩ của họ tất cả những gì họ muốn, nhưng bạn không bao giờ vượt quá số giờ đã đồng ý. Về lý thuyết, và thường trong thực tế, họ kết thúc với sản phẩm họ thực sự cần hơn là sản phẩm họ thực sự muốn.

Và nếu họ muốn tiếp tục trả tiền cho bạn thêm giờ sau giá trị thỏa thuận ban đầu, điều đó cũng tốt. Nếu bạn làm một công việc đủ tốt để hiển thị tiến bộ, thông qua thẻ câu chuyện, Greenhopper hoặc bất cứ điều gì, bạn có thể làm cho khách hàng thấy rõ những tính năng mà họ đang mất (hoặc ít nhất là khử vũ khí) mỗi khi họ thêm một thứ gì đó mới một điểm dừng cho những thay đổi phù phiếm.

Có hai rủi ro đáng lưu ý ở đây. Đầu tiên là khách hàng có thể sợ hãi, nếu anh ta không hiểu Agility từ trước. Có vẻ như anh ấy chấp nhận mọi rủi ro. Chỉ có kinh nghiệm cho thấy anh ta không thực sự.

Thứ hai là họ phải được tham gia, trong toàn bộ quá trình, hoặc tất cả mọi người sẽ mất. Nhiều khách hàng không hiểu họ phải tham gia như thế nào cho đến khi quá muộn.

Nhưng nếu bạn, với tư cách là một công ty, giải thích nó đủ tốt, mọi người đều là người chiến thắng.

Một số người đã cố gắng để cung cấp cho các giải pháp để sử dụng nhanh nhẹn trong các dự án giá cố định trong quá khứ. Cá nhân tôi nghĩ rằng nó thường không thể.

Scrum đặc biệt phù hợp với các công ty phần mềm sản phẩm và ít được sử dụng trong các công ty dịch vụ.

Bạn có thể sử dụng một số sự nhanh nhẹn trong các dự án của mình, chẳng hạn như lặp đi lặp lại, đứng lên hàng ngày, burndorn, v.v. bạn sẽ có một vấn đề.

Vui lòng không phục vụ nước sốt Agility à toutes les . Chúng ta phải sử dụng giải pháp thích hợp cho một vấn đề nhất định.

Điều này không thực sự liên quan đến lập trình Agile hoặc bất kỳ mô hình nào bạn sử dụng. Làm việc như một freelancer, tôi sử dụng kết hợp giữa Waterfall và V-model, nhưng vẫn có cùng một vấn đề: nếu khách hàng muốn thay đổi điều gì trong quá trình thiết kế chi tiết thì sao? Nếu anh ấy thay đổi trong khi thực hiện thì sao?

Cách tiếp cận bạn phải sử dụng phụ thuộc vào khách hàng và mối quan hệ của bạn.

Nếu một liên hệ là phải có cho tất cả mọi thứ bạn làm cho khách hàng này, bởi vì bạn biết rằng anh ta cố gắng không trả tiền khi anh ta có thể, hoặc anh ta sẽ cố gắng kiện bạn bất cứ khi nào có thể, thì có, bạn phải viết một đề nghị cho mọi thay đổi nhỏ trong các yêu cầu. Đó không phải là một mớ hỗn độn: nếu bạn được tổ chức tốt, có thể không quá khó để đáp ứng một yêu cầu mới trong quá trình phát triển. Nhưng chắc chắn, đó là mất thời gian và tiền bạc, và thật lạ khi phải ký một đề nghị thay đổi sẽ khiến bạn mất hai giờ để thực hiện.

Đối với các khách hàng khác, cách tiếp cận hoạt động tốt là như sau:

• Khi ký đề nghị đầu tiên, chỉ định chi phí ước tính và chi phí tối đa. Chi phí ước tính không có nghĩa gì về mặt pháp lý: đó chỉ là ước tính. Chi phí tối đa có giá trị pháp lý: nếu bạn nói rằng sản phẩm sẽ có giá 3.000 đô la cho khách hàng của bạn và cuối cùng chi phí của bạn là 3.157,24 đô la, khách hàng vẫn sẽ phải trả 3.000 đô la. Trong thực tế, trong hầu hết các trường hợp, chi phí thực sẽ thấp hơn mức tối đa nhất định và gần với ước tính của bạn hơn.

• Khi khách hàng yêu cầu thay đổi một yêu cầu, hãy ước tính chi phí mà nó có và so sánh nó với chi phí và trạng thái thực tế. Nếu bạn gần hoàn thành sản phẩm và chi phí thực là $ 2,108,36 và chi phí thay đổi được ước tính là $ 150, chỉ cần làm điều đó. Mặt khác, nếu có rủi ro đạt đến mức tối đa, thì hãy nói với khách hàng của bạn rằng bạn phải đánh giá lại chi phí chung.

Agile và 'Viết lời đề nghị' có vẻ như là một phản đề :) - thứ hai không phải là kỹ thuật phần mềm hiệu quả: D

Được rồi, bây giờ chúng ta có trò đùa trên đường - trở lại với thực tế.

"Làm thế nào nó hoạt động trong Agile ?" - hợp đồng làm phức tạp mọi thứ nhưng tôi hy vọng sẽ làm cho nó rõ ràng. Agile được thành lập dựa trên sự tin tưởng của 'niềm tin' và 'hợp tác', điều đó có nghĩa là khách hàng được phép thay đổi bất cứ điều gì, bất cứ khi nào và hiểu rằng nó có thể tốn thêm một chút hoặc nếu không xâm phạm, có thể không phải trả thêm phí.

Điều đó có nghĩa là gì? Điều đó có nghĩa là hợp đồng nói rõ rằng chúng tôi (khách hàng) sửa chữa ước tính ban đầu về chi phí và% /% phương sai mà chúng tôi có thể xử lý, ví dụ: giá thầu 100 nghìn đô la nhưng tôi sẵn sàng lên tới 120 nghìn đô la (điều này CÓ THỂ không một phần của hợp đồng, nhưng trong tâm trí của khách hàng).

Bây giờ, khi một sự thay đổi thiết kế xuất hiện, bạn sẽ nhanh chóng với việc ước tính và lập kế hoạch - bạn kết hợp nhóm của bạn lại và hỏi họ về "độ phức tạp của câu chuyện" để ước tính sự phức tạp của việc thay đổi. Nhờ có một số ước tính vận tốc, bạn có thể nhân chúng và đưa ra ước tính lịch trình. Sẽ tương đối dễ dàng để giảm chi phí cho mỗi điểm câu chuyện nếu bạn biết nhóm và mức lương tương đối của họ (vui lòng không trung bình trên MỌI NGƯỜI, bạn sẽ chịu thua lỗ hổng trung bình).

Bạn có cần phải quay lại với khách hàng với tài chính? KHÔNG. Không cần thiết. Bạn sẽ có khách hàng ưu tiên những thứ này và chèn chúng vào đúng vị trí trong hồ sơ tồn đọng. Bây giờ bạn đã biết kích thước của hồ sơ tồn đọng (nếu bạn chưa có) và dựa trên tài chính (chi phí cho mỗi điểm câu chuyện), bạn biết những yêu cầu ưu tiên thấp nào có thể không thực hiện được với ngân sách nhất định. HIỂN THỊ cho họ các hồ sơ tồn đọng được sắp xếp lại với ước tính các tính năng có thể thực hiện được theo hợp đồng $$. Sau đó, hãy để THEM quyết định xem họ có sẵn sàng trả nhiều tiền hơn để nhận thêm nếu / khi bạn / họ đến đó. Nếu họ muốn nó miễn phí ... bạn hãy đứng lên và NÓI cho họ, nó sẽ có giá cao hơn.

Điều này sẽ giúp ích mà không cần bạn liên tục quay lại với tài chính nếu bạn có thể đưa biểu đồ này lên một nơi nào đó để khách hàng nhìn thấy.

Hi vọng điêu nay co ich!

Trải nghiệm của người khác có thể sẽ khác nhau, nhưng một cách tôi đã thấy nó thực hiện phần lớn giống như "truyền thống" của bạn với một số điều cần lưu ý:

1. Xây dựng trong một số chi phí thay đổi (ví dụ: 10%)
2. Đánh giá và lập hóa đơn riêng cho các thay đổi lớn hoặc tổng hợp và thay đổi hóa đơn vượt quá chi phí tích hợp (tốt, mặc dù không lập trình, ví dụ là công việc thiết kế, trong đó thường là chi phí ban đầu bao gồm 3 lần sửa đổi và các lần sửa đổi tiếp theo hoặc có thể là tổng số lần làm lại thêm)

Thông thường, các dự án nhanh cũng bắt đầu như một mục "cốt lõi" và xoay vòng từ đó theo cách thức mô đun trên cơ sở khi cần thiết (tôi đã thấy điều này xảy ra khá nhiều trên các dự án mà tôi tham gia). Vì vậy, bạn bắt đầu với một sản phẩm cốt lõi, giả sử đó là một ứng dụng bản đồ. Việc triển khai đầu tiên chỉ là một bản đồ tập trung vào vị trí hiện tại của bạn (những gì khách hàng đặt mua ban đầu).

Sau đó, khách hàng quyết định họ muốn có những giọt pin hấp dẫn nhất định xung quanh bạn. Được rồi, đó là một phần khá lớn (tương đối nói), vì vậy bạn lập hóa đơn dưới dạng "mô-đun" mới hoặc đơn đặt hàng. Thay đổi đối với những thứ như màu sắc hoặc thiết kế của những chiếc ghim đó được tích hợp vào chi phí của đơn đặt hàng đó. Chỉ đường và lớp phủ là một đơn đặt hàng mua khác, vì chúng không được yêu cầu cho đến sau khi đơn đặt hàng khác đang được tiến hành, v.v.