Dự án tài trợ Agile


13

Công ty tôi làm việc đang tạm thời tiến tới chiến lược quản lý dự án Agile - đã từng trải qua "niềm vui" của thác nước đối với nhiều người. Chìa khóa cho vấn đề này là sự thay đổi tập trung vào việc cung cấp chức năng thay vì đáp ứng thời hạn khó khăn.

Mặc dù quá trình phát triển và mối quan hệ khách hàng chắc chắn đã được cải thiện nhờ các bản phát hành lặp được thúc đẩy thông qua Agile, nhưng điều đó chứng tỏ phần nào khó khăn hơn khi áp dụng lý do tương tự cho các chiến lược tài trợ cho dự án. Khách hàng thường không quen thuộc với các khái niệm như Agile và bày tỏ mối quan tâm lớn với những gì họ nhận được như một trường hợp "nó sẽ sẵn sàng khi nó sẵn sàng".

Tôi muốn nghe suy nghĩ và kinh nghiệm của mọi người trong việc tài trợ cho các dự án Agile

chỉnh sửa: Tôi muốn nhấn mạnh rằng tôi không yêu cầu mọi người giải thích những ưu và nhược điểm của phương pháp Agile với tôi, tôi cũng không tin Agile đồng nghĩa với "nó sẽ sẵn sàng khi nó sẵn sàng", đây là nỗi sợ được thể hiện bởi khách hàng / doanh nghiệp tôi đã làm việc khi ủng hộ các thực tiễn phát triển Agile.

Điều tôi quan tâm là những kinh nghiệm mà mọi người đã giải quyết được mâu thuẫn giữa các phương pháp ngân sách thác nước "truyền thống" cố thủ trong các mối quan hệ / khách hàng doanh nghiệp và các phương pháp phát triển tiến bộ hơn - và các chiến lược ngân sách mà họ đã áp dụng để hỗ trợ sự tiến hóa đó.


2
Lisa Crispin và David Norton từ Gartner có một số ý tưởng hay về "Bán Agile". Hãy xem những gì họ nói: bit.ly/rlRF4U
Hướng đạo sinh Agile

Câu trả lời:


4

Nếu bạn đã có thể đưa ra một trích dẫn về một dự án với ngày cuối cùng chính xác về tất cả các tính năng, tại sao bạn lại chuyển sang một cách tiếp cận nhanh? Bạn và mọi người khác đấu tranh với điều này và một cách tiếp cận nhanh nhẹn đang ở phía trước với thực tế này. Sử dụng nó như là tuyên truyền chống lại sự cạnh tranh. Hãng hàng không Tây Nam không hứa hẹn cho bạn một chỗ ngồi giống như những người khác và sau đó trao nó cho người khác.

Tất nhiên khách hàng muốn một ngày kết thúc chính xác. Họ muốn phần mềm không có lỗi, rẻ tiền được phân phối trước thời hạn bất kể mọi thay đổi đối với yêu cầu ban đầu. Nói với bạn đội ngũ bán hàng để tìm hiểu làm thế nào để bán một dự án bằng cách sử dụng các nguyên tắc nhanh. Càng nhiều tương tác bạn đi qua càng gần bạn có thể biết khi nào dự án sẽ kết thúc. Khách hàng cũng học cách tính đến các tác động của các yêu cầu thay đổi.


"Nói với nhóm bán hàng của bạn để tìm hiểu cách bán dự án bằng các nguyên tắc nhanh nhẹn" - Tôi sẽ cho đó là cú đánh tốt nhất của tôi ... {;)
sunwukung

5

Các dự án Agile không hoạt động theo dòng "nó sẽ sẵn sàng khi nó sẵn sàng". Đó là một dòng cổ điển từ kỹ thuật thác nước.

Các dự án Agile hoàn tất khi khách hàng quyết định rằng anh ta không muốn chi thêm tiền cho các tính năng bổ sung. Điều đó có thể được chuyển đổi thành một điểm bán hàng quan trọng bởi những người bán hàng của bạn. Thay vì cam kết với một bộ tính năng cố định (nhu cầu trả trước có thể hoặc không thể biết trước) cho một khoản tiền cố định, khách hàng có thể bắt đầu với số tiền ban đầu cho một bộ tính năng ban đầu và sau đó thực hiện theo từng giai đoạn. Điều này sẽ đảm bảo một vài điều:

  • Miễn là danh sách tính năng được ưu tiên chính xác, khách hàng luôn nhận được các tính năng quan trọng nhất tiếp theo được phân phối tiếp theo, từ đó tối đa hóa lợi ích của anh ta từ chi tiêu của anh ta (anh ta nhận được "khoản tiền lớn nhất cho số tiền của mình").
  • Nếu khách hàng hết tiền, anh ta đã tối đa hóa khoản đầu tư bạn đã được trả tiền cho những gì bạn đã giao. Không ai bị tổn thương, mọi người đều có lãi.
  • Khách hàng có thể thay đổi suy nghĩ về các ưu tiên và tính năng ở mỗi vòng quay của bánh xe (mỗi đầu của một giao thoa). Một lợi thế khác biệt so với hợp đồng giá cố định bình thường.

Có thể có nhiều hơn, nhưng những điều trên là đủ để đưa nhân viên bán hàng của bạn đi đúng hướng.


Re: "Không ai bị tổn thương, mọi người đều có lãi" - Ngoại trừ anh chàng bị đuổi việc vì anh ta hứa với sếp rằng với $ X, anh ta sẽ nhận được gói phần mềm có XYZ. Thật không may, nhờ nhanh nhẹn, gói phần mềm chỉ thực hiện XY. Bỏ quản lý, sa thải anh chàng dưới tuổi. Có lẽ tôi chỉ ở trong các ngành hoàn toàn khác với hầu hết những người đề xướng nhanh nhẹn, bởi vì họ không thể thấy vấn đề trong việc chỉ cung cấp giải pháp một phần cho khách hàng. OTOH, tôi không thể thấy mục đích của việc cung cấp một giải pháp một phần vì tỷ lệ cược là làm cho sản phẩm trở nên vô dụng đối với khách hàng.
Dunk

Rõ ràng bạn chưa làm việc trong một môi trường nhanh nhẹn thích hợp, nếu không bạn sẽ không đưa ra nhận xét này. Nếu XYZ là bắt buộc, thì XYZ sẽ được giao. RST và UVQ có thể không được giao, nhưng vì chúng có mức độ ưu tiên thấp hơn nên khách hàng cũng không phải trả tiền cho họ. Tất nhiên, nếu các nhà phát triển của bạn không đạt được ước tính của họ rằng họ thậm chí không thể cung cấp XYZ theo ước tính của riêng họ, thì sẽ có những bài học cần rút ra.
wolfgangsz

3

Chà, tôi không coi đó là một trường hợp "Nó sẽ sẵn sàng khi nó sẵn sàng". Phương pháp nhanh nhẹn thúc đẩy việc cung cấp các sản phẩm giao hàng một cách thường xuyên, như hai tuần một lần. Đó là lý do tại sao khách hàng là một phần quan trọng và rất tích cực của dự án trong suốt vòng đời của họ khi họ cung cấp hướng dẫn về cách các tính năng của sản phẩm của bạn sẽ hình thành. Nếu bất cứ điều gì, một khách hàng sẽ bắt đầu thấy kết quả sớm hơn, thay vì vào cuối của một dự án, như trong cách tiếp cận thác nước.

Miễn là bạn nhắc lại thực tế rằng khách hàng sẽ là một phần tích cực của dự án và họ sẽ thấy dự án bắt đầu hình thành sớm, điều đó có thể đảm bảo với họ rằng đó không phải là trường hợp chờ đợi cho đến khi hoàn thành.


chỉ cần rõ ràng - Tôi không nói rằng tôi tin rằng Agile tương đương với mô tả đó, nhưng đó là cách khách hàng / bán hàng thường thấy nó. Agile rất tuyệt ở các lần lặp - nhưng làm cho nó khó xác định được kết thúc của dự án phải không?
sunwukung

4
@sunwukung - Đội ngũ bán hàng của bạn không bán thực tế là không ai có thể dự đoán được sự kết thúc của một dự án dài với bất kỳ độ chính xác nào ngay từ đầu.
JeffO

Tôi tưởng tượng cách tốt nhất để có một ý tưởng cho phần cuối của dự án là có một cuộc họp lập kế hoạch dự án với khách hàng của bạn và liệt kê tất cả các tính năng mà họ muốn. Sau đó, bạn có thể xây dựng một dự án tồn đọng đầy đủ và đầy đủ. Ngồi xuống với nhóm của bạn và yêu cầu họ điền vào các ước tính cho toàn bộ hồ sơ tồn đọng. Sử dụng các ước tính này như một hướng dẫn sơ bộ khi nào dự án của bạn sẽ kết thúc.
JuniorDeveloper1208

1
@sunwukung - Không, không thực sự, ngồi và lên kế hoạch tồn đọng cũng là một ý tưởng tốt cho Agile, đó là việc thực hiện quy trình phát triển khác biệt với Agile với Waterfall (Agile lặp đi lặp lại nhiều hơn). Tôi nghĩ trở ngại chính của bạn sau khi bán Agile cho người tiêu dùng của bạn thực sự sẽ triển khai nó, tôi đã trải qua điều này một vài lần và nó có thể là một quá trình đau đớn.
JuniorDeveloper1208

1
xin lỗi - vâng, tôi hiểu - chúng tôi đã sử dụng phương pháp tồn đọng để xử lý cửa sổ phân phối ước tính (sử dụng Pivotal Tracker, ứng dụng tuyệt vời btw). Sự căng thẳng phát sinh từ sự mờ nhạt mà phương pháp này tạo ra về sự khác biệt giữa các cột mốc ban đầu có được từ phương pháp này và ETA thực tế một khi vận tốc bắt đầu lắng xuống. IMO đó là tất cả về cách chúng tôi xử lý mối quan hệ khách hàng - nhưng đó là một thành phần chính trị
sunwukung

2

Mặc dù nơi tôi làm việc thực hiện một sự khốn khủng khiếp của Agile, tôi nghĩ rằng khách hàng có nhiều khả năng thích phát triển phần mềm trong các lần lặp hơn là các bản phát hành đầy đủ.

Lặp đi lặp lại cho vay theo yêu cầu cá nhân của khách hàng, trong đó họ yêu cầu một cái gì đó và họ nhận được nó khi tính năng được triển khai, không chỉ khi nó được thực hiện và tất cả những thứ khác được nhóm với nó để phát hành cũng được thực hiện.

Tôi chưa bao giờ thấy một khách hàng nói: "Chúng tôi muốn tính năng này và chúng tôi muốn đợi 8 tháng để nó được phân phối với một loạt các tính năng khác mà chúng tôi không quan tâm."


1
Điều này có thể phụ thuộc vào kích thước của khách hàng. Tôi nghĩ trong trường hợp phần mềm máy tính để bàn, không có gì lạ khi các công ty lớn hơn không muốn trải qua quá trình cài đặt lại / kiểm tra hình ảnh hàng loạt / v.v. thường xuyên và trong những trường hợp đó, họ thích "phát hành" ít thường xuyên hơn. Tuy nhiên, nhà phát triển vẫn có thể thực hiện các bước lặp trong nội bộ và chỉ cần đưa ra một bản cắt chính thức của ứng dụng cho những khách hàng đó ở bất kỳ khoảng thời gian nào khách hàng thích.
Adam Lear

+1 cho "Chúng tôi muốn tính năng này và chúng tôi muốn đợi 8 tháng để nó được phân phối với một loạt các tính năng khác mà chúng tôi không quan tâm."
sunwukung

2

Làm thế nào về việc thiết lập một chu kỳ thanh toán phù hợp với các lần lặp? Ý tưởng của agile là bạn chỉ có thể thực sự lập kế hoạch và ước tính trong các bước ngắn, và sự thúc đẩy và cam kết vẫn mạnh mẽ cho các chu kỳ ngắn này. Vậy tại sao không nhắm mục tiêu tài trợ theo cùng một cách - để khách hàng đóng góp cho công việc với $$ đồng thời họ đang đóng góp với sự hướng dẫn. Rốt cuộc, nếu họ không có được thứ họ muốn, họ không nên trả tiền cho nó.

Và sau đó tìm ra những gì xảy ra khi chấm dứt một dự án - ví dụ, khách hàng có sở hữu mã này không, hay chỉ là thực thi? Nhưng điều đó sẽ phù hợp với các dự án kiểu thác nước trước đây.


Tôi đồng ý với điều này, tôi nghi ngờ một phần của vấn đề đối với doanh nghiệp nằm ở dự phóng doanh thu hàng năm (do đó làm hài lòng các nhà đầu tư) với các đợt bùng nổ tài trợ "ngắn hạn" này.
sunwukung

Tôi tự hỏi nếu bạn có thể ăn cắp từ một mô hình hợp đồng? Nó có thêm rủi ro về thời gian chết nếu khách hàng đột ngột nói "cảm ơn nhưng không", điều này có giống với mô hình lao động hợp đồng không?
bethlakshmi

1

Ý tưởng của Agile là bạn lặp lại nhanh chóng và thiết lập chính xác những gì bạn sẽ cung cấp vào cuối mỗi lần chạy nước rút, vì vậy khi 2/3/4 tuần nước rút của bạn kết thúc, bạn có các tính năng hữu hình trong ứng dụng / dự án của mình mà bạn có thể trình bày cho khách hàng của mình và nhận phản hồi.

ETA: Bạn có thể tập hợp 'nước rút' thành 'cột mốc', với các sản phẩm được thiết lập và nhận thanh toán trên mỗi cột mốc.


Đây là những gì tôi đang cố gắng quảng bá trong kinh doanh - trả tiền cho "cổng sân khấu". Vấn đề chính là ngày giao hàng cuối cùng - khách hàng có phải từ bỏ thời hạn cuối cùng cụ thể đó không?
sunwukung

Khó có thể nói, sau một vài lần chạy nước rút, bạn sẽ có thể thiết lập vận tốc nhóm của mình (Số lượng công việc bạn có thể làm cho mỗi lần chạy nước rút) và chứng minh bạn có một hồ sơ tồn đọng đầy đủ và đầy đủ (Danh sách các nhiệm vụ / câu chuyện người dùng tạo nên dự án hoàn thành) bạn sẽ có thể dự đoán hợp lý ngày kết thúc của mình bằng cách xem xét các điểm bị đốt cháy của bạn (Biểu đồ vận tốc nhóm mà bạn có thể sử dụng để ngoại suy ngày kết thúc của mình và xem liệu bạn có thể hoàn thành tất cả công việc trong giai đoạn nước rút không ).
JuniorDeveloper1208

2
@sunwukung, Một lần nữa, bạn đang thiếu điểm sau khi mọi người mô tả nó một cách hoàn hảo cho bạn. Agile đảm bảo rằng khách hàng có được phần mềm làm việc vào cuối mỗi lần chạy nước rút. Nếu họ vẫn muốn NGÀY ĐẦU TIÊN cho TẤT CẢ CÁC TÍNH NĂNG ĐỂ HOÀN THÀNH thì họ có thể có điều đó nhưng chỉ với các tính năng đã thỏa thuận khi họ ký thỏa thuận. Thật không công bằng và không hợp lý khi họ thay đổi yêu cầu của họ và mong đợi thời hạn sẽ TRỞ THÀNH CÙNG!
maple_shaft

1
Chà, chỉ cần nói với họ rằng trong quá trình phát triển, họ sẽ có thể xem dự án của họ vào cuối mỗi lần chạy nước rút, luôn trong trạng thái hoạt động và sẵn sàng phản hồi, không nên bán khó, nhanh nhẹn là tuyệt vời.
JuniorDeveloper1208

1
@sunwukung, Có vẻ như công ty sẽ làm tốt hơn nếu BẠN đại diện cho bộ phận kinh doanh trong trường hợp này :) Tôi không biết bạn có thể nói gì với bộ phận kinh doanh để thuyết phục họ những gì bạn đã biết. Họ có thể sẽ không lắng nghe bạn. Thật không may, có vẻ như phía kỹ thuật đang phát triển vào thế kỷ 21 và phía kinh doanh là trong quá khứ. Đây không phải là một vấn đề dễ dàng và bạn có thể không ở vị trí để khắc phục điều này.
maple_shaft

1

Bản thân tôi không tin rằng bạn nên bán một dự án cố định và xử lý Agile về phía bạn, mà là bán các công việc lặp lại cho khách hàng của bạn.

Lặp đi lặp lại là rõ ràng để hiểu và bạn không trộn lẫn hai khái niệm.

Hai tài liệu sau đây sẽ cung cấp cho bạn một số thông tin về tương tác quy trình bán hàng và quản lý Agile:

http://www.nayima.be/html/fixedpriceprojects.pdf & http://www.nayima.be/html/agilefixedprice.pdf

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.