Làm thế nào để bán phát triển Agile cho khách hàng (thác nước)

Cửa hàng phát triển của chúng tôi thực sự muốn thực hiện các dự án nhanh hơn nhưng chúng tôi gặp vấn đề khi đưa khách hàng lên tàu. Nhiều khách hàng muốn có ngân sách và thời hạn. Thật khó để bán một khách hàng trong một dự án nhanh nhẹn khi các đối thủ của chúng tôi đưa ra thời hạn cố định dựa trên thác nước và giá cố định. Chúng tôi biết số cố định của họ là xấu, nhưng khách hàng không biết điều đó. Vì vậy, cuối cùng chúng tôi trông có vẻ tệ cho khách hàng vì chúng tôi không thể sửa giá hoặc thời hạn nhưng đối thủ của chúng tôi thì có thể.

Vì vậy, làm thế nào bạn có thể khiến lực lượng bán hàng của mình bán thành công một dự án sử dụng các phương thức phát triển nhanh, hoặc một sản phẩm được phát triển bằng các phương pháp đó? Tất cả các thông tin tôi tìm thấy dường như tập trung vào quản lý dự án và nhà phát triển.

Chìa khóa để làm tốt điều này là bằng cách sử dụng hợp đồng hỗ trợ.

Về cơ bản, khi bạn bán khách hàng lần đầu tiên, bạn bán cho họ dựa trên chuyên môn của bạn và bạn làm điều đó. Điều đó có nghĩa là một hợp đồng đặt ra phạm vi và một hạn chót vững chắc. Đây là những gì khách hàng muốn. Các khách hàng ít nhiều biết phạm vi. Thác nước hoạt động rất tốt, trong một môi trường phạm vi cố định và xác định, tôi sẽ nói nó hoạt động tốt hơn nhanh nhẹn trong các môi trường như vậy. Và trong trường hợp này, nó mang lại cho khách hàng mức độ thoải mái khi xu hướng lo lắng vì anh ta chưa bao giờ làm việc với bạn trước đây. Đó là Ok, Agile không phải lúc nào cũng tốt hơn thác nước.

Vì vậy, bạn có một hợp đồng giá cố định cho phạm vi X. Sau đó, bạn nói với khách hàng Nhìn, bạn sẽ muốn thực hiện thay đổi và bạn sẽ cần chúng tôi hỗ trợ bạn đăng sản xuất, hãy dành 20% ngân sách của bạn cho những thứ này được sử dụng theo nhu cầu có nghĩa là hợp đồng hỗ trợ .

Nếu một sự thay đổi xuất hiện trong dự án, chỉ cần trì hoãn nó để được xử lý theo liên hệ hỗ trợ. (Giả sử thay đổi này sẽ gây ra sự gián đoạn nghiêm trọng cho dự án)

Các điều khoản của liên hệ hỗ trợ như sau “ làm việc phải được thực hiện trên cơ sở mỗi giờ, theo yêu cầu của khách hàng, có thể được sử dụng cho các yêu cầu thay đổi hoặc hỗ trợ hệ thống nói chung và bảo trì .” BAM! Bạn đang ở Agile.

Sau đó, bạn có thể tiếp tục mở rộng liên hệ hỗ trợ và chỉ cần sử dụng liên hệ hỗ trợ làm phương tiện để chạy các dự án mới. Ngoài ra, nếu những giờ này được mua và trả tiền trước , chúng tôi thường giảm giá cho khách hàng 15%. Đó là Win-Win.

Agile không loại trừ thời hạn và ngân sách. Nếu tôi là khách hàng và tôi đã đến một nhà phát triển và họ nói với tôi rằng họ không thể cho tôi thời hạn hoặc chi phí ước tính, tôi sẽ nghi ngờ sự tỉnh táo của họ. Và nói với họ rằng họ không hiểu sẽ không hoạt động: họ cần có khả năng lập ngân sách và kế hoạch.

Họ không cần biết quá trình phát triển của bạn. Họ cần biết sẽ mất bao lâu để phát triển các tính năng và chi phí của nó là bao nhiêu. Cung cấp cho họ một số dựa trên giả định (giả) rằng các yêu cầu của họ là chính xác 100% và khi yêu cầu của họ thay đổi, sau đó thay đổi ước tính của bạn.

Điều này cung cấp cho họ các chi tiết đơn hàng ngân sách và ngày triển khai mà họ muốn và khi mọi thứ thay đổi, quy trình của bạn cho phép bạn trông linh hoạt và có sức chứa.

Có vẻ như nhân viên bán hàng của bạn đang tạo ra một lớp thông tin sai lệch giữa các nhóm phát triển và khách hàng của bạn. Nếu họ đã không bán hàng trên thị trường CNTT trong một thời gian dài, họ có thể xem vai trò của họ là "di chuyển sản phẩm", nghĩa là có được chữ ký trong hợp đồng "bất cứ điều gì cần thiết". Nói tóm lại, họ có động lực để đóng, bất kể họ hứa hẹn điều gì. Trong những trường hợp như vậy, họ sẽ theo dõi ngôn ngữ của khách hàng càng chặt chẽ càng tốt.

Tôi là một bản ghi bị hỏng trích dẫn điều này, nhưng đây là: bạn đang ở trên bàn mổ và khi bạn đi theo bác sĩ phẫu thuật nói rằng 'chúng tôi sẽ đưa bạn ra khỏi đây đúng giờ và trong ngân sách'. Tuyệt quá. Tôi sẽ còn sống chứ?

Nếu bạn đang làm việc trên các cơ quan nội bộ của một doanh nghiệp, bạn có dừng lại ở một số điểm tùy ý không? Thông thường, một ứng dụng bị ảnh hưởng bởi các lực lượng mà cả bạn và khách hàng của bạn không kiểm soát - quy định, môi trường kinh doanh, hành vi của đối thủ cạnh tranh, sự xuất hiện của một số mô hình mới, v.v. Nếu bạn chỉ cần nói 'chúng tôi sẽ làm' điều x 'cho' giá y '' khách hàng sẽ quay lại ba tháng sau và nói - 'tốt ...'. Nói chung có nghĩa là họ biết điều gì đó mà họ không biết khi bạn đồng ý với dự án thác nước.

Những gì có thể làm việc trong một tình huống như vậy là chứng minh cho nhân viên bán hàng của chính bạn xem việc lái xe qua hẻm núi là như thế nào. Ở mỗi lượt đều có những bất ngờ. Không thể thấy hơn ba tháng nữa, vì vậy nếu khách hàng yêu cầu dự án 18 tháng thì sẽ không thể nhận ra được vào thời điểm bạn sắp hoàn thành. Do đó, đại diện bán hàng của bạn cần bắt đầu bằng cách tìm ra khoản thanh toán tài chính của dự án. Điều này sẽ tăng doanh số 10 triệu đô la? Nếu vậy, có đáng để đầu tư 2.000.000 đô la để kiếm thêm 10 triệu đô la đó không? Nếu khách hàng và đại diện bán hàng đang hội tụ một cam kết trị giá 500.000 đô la, thì điều gì đó có thể sai và không ai có thể nói đó là gì - điều đó không đúng. Điều 'không cảm thấy đúng' là một cam kết làm điều gì đó có nguy cơ trở nên vô dụng.

Hai mẫu máy bay phản lực mới nhất đã có lịch sử về snafus. Chăm sóc sức khỏe thậm chí không cần thảo luận. Nếu bạn có thể tìm thấy những cuốn sách hoặc trao đổi những câu chuyện báo chí trên máy bay, bạn có thể đưa ra những giả định nhất định đã được chứng minh là lạc quan và các dự án liên tục bỏ lỡ thời hạn. Thường thì điều này là do sự đánh giá thấp sự phức tạp. Nếu bạn thực sự không thể hiểu được mức độ phức tạp của nó cho đến khi bạn bắt đầu viết mã, bạn sẽ cần một 'vòng ban đầu' để hiểu rõ hơn về các vấn đề thực sự. Việc cắt giảm ngân sách nên là một phần nhỏ trong tổng lợi nhuận bổ sung (hoặc doanh thu trong một số trường hợp) và con số đó phải nhiều hơn bất cứ ai nghĩ rằng dự án hiện tại sẽ có giá. Nếu bạn có thể chỉ ra cách cột mốc cuối cùng có thể được thông qua mà không vượt quá 'giới hạn thanh toán',

Rào cản chính trong việc đạt được các lợi ích của Agile-Scrum bên ngoài phát triển phần mềm là tích hợp nó với các cơ chế kiểm soát hiện có. Các cơ chế kiểm soát này được quy định do các điều kiện tiên quyết tổ chức khác nhau và thường được hiện thực hóa bằng cách sử dụng phương pháp và phương pháp Thác tuyến tính.

Bốn trong số các điều kiện tiên quyết tổ chức điển hình được mô tả dưới đây:

• Các tập đoàn toàn cầu lớn - trong các tổ chức ma trận phân cấp này, kiểm soát danh mục đầu tư từ trên xuống là quy tắc trong ngày. Cách tiếp cận nhanh nhẹn tự do có một thời gian khó khăn để điều chỉnh theo các điều khiển nghiêm ngặt. Cụ thể là các khái niệm không có kế hoạch Agile vốn có, làm cho tổ chức Agile-Scrum khó nuốt.

• Các ngành công nghiệp có quy định cao - một số ngành được các cơ quan quản lý và tuân thủ yêu cầu phải có cơ chế kiểm soát ràng buộc chặt chẽ. Đây có thể là các thiết bị y tế, máy bay, và các đơn vị kinh doanh nghiên cứu và phát triển sản phẩm dược phẩm. Trong khi các nhóm riêng lẻ có thể vận hành Agile-Scrum, quá trình phát triển phải tuân theo phương pháp tiếp cận Thác tuyến tính cứng nhắc để truy xuất nguồn gốc và quản trị.

• Các sản phẩm được xác định trước phức tạp - một số sản phẩm tích hợp bao gồm cả phần cứng, phần mềm, được nhúng và nhiều sản phẩm khác được phát triển như một hợp đồng với khách hàng cuối theo một bộ yêu cầu được xác định trước. Trong những trường hợp này, mức độ linh hoạt yêu cầu là nhỏ, mặc dù lớn hơn so với dự đoán ban đầu. Khái niệm tồn đọng hoàn toàn linh hoạt của Agile-Scrum chịu đựng đáng kể trong những trường hợp này.

• Các phòng CNTT chung - phần lớn các hoạt động hàng ngày và hàng tuần trong các phòng CNTT thúc đẩy bảo trì là đặc biệt. Thay đổi lịch trình hàng ngày là rất nhiều và ngay lập tức. Can thiệp liên tục trong các nhóm làm việc là tiêu chuẩn. Khái niệm về quyền anh thời gian và không can thiệp rất khó để duy trì trong những tình huống này.

Đương nhiên - nhiều lần bốn loại riêng biệt chi tiết ở trên, thực sự trộn lẫn; Vì vậy, thông thường tìm thấy một sản phẩm phức tạp trong một công ty lớn toàn cầu cần phải tuân thủ các quy định của công ty.

Dựa trên kinh nghiệm thực tế, phương pháp được đề xuất để giải quyết các kịch bản này và các kịch bản khác là trao quyền cho PMO Agile hoạt động như một người tạo môi trường, người điều khiển và dịch giả giữa các nhóm Agile-Scrum mới nổi và các thành phần Thác tuyến tính.

Tham khảo bảng dưới đây để biết hướng dẫn cụ thể

Nguồn - Giao diện giữa thác tuyến tính và phương pháp tiếp cận nhanh của Michael Nir

Chúng tôi thiết lập 2 hoặc 3 phiên ước tính với khách hàng tiềm năng và nhà phát triển của chúng tôi, nơi chúng tôi thảo luận về công việc và đưa ra các tiêu chí chấp nhận. Các nhà phát triển ước tính công việc trong các điểm câu chuyện trong cuộc họp.

Sau đó chúng tôi bán cho khách hàng một số điểm câu chuyện. Điều này là có thể bởi vì anh ta có một ý tưởng tốt về giá trị của các điểm câu chuyện. Chúng tôi nói với anh ta rằng anh ta có khả năng tinh chỉnh backlog / scope của mình trong dự án và điều đó sẽ dễ dàng do sử dụng các điểm câu chuyện. Chúng tôi cũng nói với anh ấy rằng sẽ có một phần mềm làm việc thường xuyên để anh ấy có thể theo dõi tiến trình và có được những hiểu biết mới.

Bằng cách đồng ý về một số điểm câu chuyện, khách hàng được đảm bảo nhận được giá trị đồng tiền của mình. Nếu anh ấy không thay đổi tồn đọng, anh ấy có dự án giá cố định / phạm vi cố định, nhưng kinh nghiệm của tôi là anh ấy sẽ thay đổi. Bằng cách ước tính với sự có mặt của khách hàng tiềm năng, chúng tôi cố gắng xây dựng mối quan hệ dựa trên sự cởi mở và tin tưởng.

Chúng tôi quản lý để thuyết phục khách hàng như bạn mô tả, những người "muốn có ngân sách và thời hạn" và họ rất vui khi chúng tôi muốn thực sự hiểu những gì họ cần, thay vì làm việc từ một tài liệu. Chúng tôi đã cho thấy rằng chúng tôi muốn đầu tư vào các dự án này.

Trong các phiên ước tính, chúng tôi ước tính toàn bộ hồ sơ tồn đọng của họ. Điều này đã cho x điểm câu chuyện. Chúng tôi đã đề xuất thêm 25% cho những tính năng chưa rõ ràng hoặc được biết đến vào thời điểm đó. Với các hồ sơ tồn đọng ước tính kèm theo hợp đồng, họ được đảm bảo rằng họ sẽ nhận được mọi thứ cho ngân sách cố định.

Ban đầu giá thầu là thời gian và vật chất. Vì họ muốn có một giá thầu cố định, chúng tôi đề nghị làm việc với giá mà chúng tôi đã đưa cho họ và sử dụng 25% điểm câu chuyện thêm cho dự phòng. Nếu mọi việc suôn sẻ, phần 25% không được sử dụng để bù đắp sự chậm trễ mà chúng tôi gặp sẽ được sử dụng để cung cấp thêm chức năng cho khách hàng.

Điều này đã kích thích họ theo một số cách: đầu tiên, họ đã làm mọi thứ có thể để cho phép các nhà phát triển của chúng tôi làm việc nhanh nhất có thể, vì điều này rõ ràng là vì lợi ích của riêng họ. Chúng tôi không bao giờ phải chờ câu trả lời cho câu hỏi. Thứ hai, họ thực sự hiểu khái niệm về các điểm câu chuyện. Trước khi dự án bắt đầu, họ đã gỡ bỏ một số câu chuyện và yêu cầu chúng tôi ước tính những câu chuyện khác. Không có cuộc đàm phán hợp đồng phức tạp là cần thiết cho việc này.

Chúng tôi đã thông báo cho họ về tiến trình và giữ một thông tin liên lạc rất cởi mở. Họ đã nhận được một báo cáo tiến độ cứ sau 2 tuần: x% số điểm câu chuyện được thực hiện trong y% thời gian ước tính để lại z% số điểm câu chuyện thêm có sẵn. Chúng tôi đã có một chút khởi đầu khó khăn nhưng đã cố gắng bắt kịp các ước tính vào cuối dự án, điều này khiến 100% các điểm câu chuyện thêm có sẵn để phát triển thêm. Khách hàng rất vui vì anh ta có mọi thứ anh ta thực sự cần (và khác một chút so với các tính năng được yêu cầu ban đầu của anh ta, anh ta đã xóa một số và thêm vào những thứ khác).

Khách hàng cũng rất vui vì mọi thứ được phân phối theo khung thời gian dự kiến ​​(nơi anh ta cũng làm mọi thứ có thể để giúp chúng tôi thích đuổi theo vé, trả lời các câu hỏi ngay lập tức, liên quan đến người dùng trong các cuộc họp phân tích hàng tuần và cũng liên quan đến họ trong thử nghiệm chức năng).

Công ty của tôi rất vui vì chúng tôi giao hàng đúng thời gian và ngân sách. Công ty của tôi cũng rất vui vì thành công của dự án này đã mở ra cơ hội cho nhiều dự án hơn. Chúng tôi thậm chí đã được đề cập trong tạp chí hàng tháng của khách hàng đã được gửi đến mọi người trên toàn thế giới.

Thực hiện các ước tính tốt là phần khó nhất của dự án, nhưng việc có các phiên ước tính trước giúp chúng tôi hiểu được khó khăn và rủi ro. Nó cho phép chúng tôi đưa ra ước tính dựa trên sự thật và loại bỏ rất nhiều điều chưa biết.

Cố gắng sử dụng các phương pháp Agile trong môi trường tư vấn / đấu thầu là rất khó khăn khi khách hàng không ở trên tàu.

Nếu chúng được sử dụng theo kiểu Thác nước "đây là yêu cầu của chúng tôi, thì sẽ mất bao nhiêu và mất bao lâu?" loại dự án và đưa nó ra đấu thầu thực sự không có thời gian để thuyết phục họ rằng Agile hoặc bất kỳ cách nào khác là tốt hơn.

Agile có lợi thế của nó (và tất nhiên là nhược điểm), nhưng thật lòng mà nói, khách hàng thường không biết hoặc không quan tâm đến chi tiết đằng sau hậu trường.

Họ muốn 2 thứ - chi phí và quy mô thời gian. Và một khi bạn nói với họ điều đó, thì họ muốn nó rẻ hơn và sớm hơn. Và bạn biết những gì, chúng tôi muốn tất cả. Tất cả các yêu cầu. Không ai có thể chờ đợi, hoặc được cắt nhỏ.

Và cũng như tôi không thích những người bán hàng trong hầu hết các lĩnh vực của cuộc sống, đừng quá khó khăn với những người bán hàng. Đó là một công việc khó khăn.

Họ không xây dựng phần mềm, họ hầu như không biết làm thế nào tất cả hoạt động qua các từ buzz.

Tuy nhiên, họ phải đưa ra quy mô thời gian và chi phí dựa trên một số cuộc họp yêu cầu len lỏi. Có thể họ có một số anh chàng công nghệ cùng với họ để cai trị họ, nhưng họ cần phải bán hàng để giữ cho mọi thứ diễn ra.

Vì vậy, làm thế nào bạn có thể khiến lực lượng bán hàng của mình bán thành công một dự án sử dụng các phương thức phát triển nhanh, hoặc một sản phẩm được phát triển bằng các phương pháp đó?

Bằng cách có lực lượng bán hàng của bạn mang khách hàng đến văn phòng. Toàn bộ điểm nhanh nhẹn là nhận phản hồi ngay lập tức từ khách hàng để bạn có thể tạo ra những gì họ muốn (và không còn nữa). Mang họ vào, hỏi những gì họ muốn. Hai tuần sau, mang chúng vào và cho chúng xem bản demo / nguyên mẫu. Bán chúng trên sự tương tác đó. Cho họ thấy sự tiến bộ và giải thích rằng loại lặp này là những gì bạn muốn làm để họ có được chính xác những gì họ muốn.

Đưa ra ước tính cho số lượng công việc cần thiết (rốt cuộc đó là ngân sách nào), nhưng hãy để họ có quyền lực (đọc: trách nhiệm) để bao gồm những gì họ muốn phù hợp với ngân sách của họ .

Tôi nghĩ rằng câu trả lời là trong hầu hết các trường hợp, bạn có thể sẽ không. Tôi sẽ thử và xem điều này ban đầu là một phần nhỏ trong doanh nghiệp của bạn - có thể là 20%, phần còn lại theo mô hình truyền thống. Theo thời gian, tôi sẽ cố gắng tập trung nhiều hơn vào các sản phẩm và khách hàng của Agile và cố gắng làm cho phần đó phát triển hơn nữa.

Một phần khác của việc giải quyết vấn đề này có lẽ là thử và sử dụng cả hai phương pháp. Sử dụng phương pháp tiếp cận thác nước với những người đàm phán hợp đồng và quản lý cấp cao. Ví dụ: 'một hệ thống cho phép khách hàng duy trì danh mục đầu tư và đưa ra quyết định đầu tư bằng cả thiết bị điện thoại di động và trình duyệt (Apple và Android).' hoặc điều tương tự. Sau đó, sử dụng Agile để phát triển nhóm phát triển trên các tính năng chi tiết hơn, ví dụ: Tạo Trang chủ, Tạo Trang đăng nhập, Tạo Lịch sử quản lý Portolio, Tạo Đăng nhập di động, v.v.

Một ý tưởng khác là làm cho Agile trở thành điểm khác biệt của bạn. Tôi biết rằng nhiều người nếu không phải hầu hết các tổ chức lớn không làm Agile. Tuy nhiên, hầu hết (phần lớn theo kinh nghiệm của tôi) của các công ty nhỏ là. Tôi nghĩ rằng Agile đang phát triển nhanh chóng và điều này sẽ tiếp tục. Ưu điểm của tuyến đường này là bạn đang giới thiệu những gì bạn muốn làm nhất cho những khách hàng đã nhận ra nó. Cách tiếp cận này sẽ yêu cầu một số công việc theo thời gian mà không đảm bảo thành công.

Bạn cũng có thể tìm thấy một số lực kéo nếu khách hàng của bạn thích thử nghiệm. Có các sản phẩm được thử nghiệm tốt có thể là một bán dễ dàng hơn cho một số khách hàng. Một cuốn sách mà tôi thấy hữu ích trong lĩnh vực này là 'Thử nghiệm nhanh' của Adison Wesley Press.

Bạn cũng có thể sử dụng các sự kiện hiện tại để hỗ trợ trường hợp của bạn. Ví dụ, trang web chăm sóc sức khỏe hiện tại (viết vào tháng 10 năm 2012) là một trường hợp tuyệt vời về cách KHÔNG xử lý các thay đổi cần thiết 2 tuần trước khi đi vào hoạt động. Ngoài ra, kỹ thuật quá mức rõ ràng có thể đã được giải quyết tốt hơn các phương pháp nhanh nhẹn hơn.

Liên hệ với khách hàng trước đó hài lòng với công việc của bạn. Đặc biệt nếu họ là những người chuyển đổi từ Thác nước sang Agile. Ít nhất, chuyển đổi không phải là khách hàng của bạn.

Lời chứng thực của họ (với tư cách là một khách hàng) sẽ vượt xa mọi thứ và mọi thứ bạn có thể nói. Họ có thể giải quyết các mối quan tâm và lo ngại về khách hàng mới của bạn hơn bao giờ hết.

Từ góc độ quản lý, ngân sách và thời hạn là một nhu cầu kinh doanh cho dự án. Bạn cần đảm bảo rằng bạn đang giải quyết những nhu cầu đó và nếu bạn xem những lời chứng thực của một doanh nghiệp về việc chuyển đổi, bạn sẽ nhận thấy điều đó xuất hiện trực tiếp. Nếu bạn xem lời chứng thực của nhà phát triển về việc chuyển đổi, bạn sẽ nhận thấy rằng thường thì không.