Làm thế nào để bạn đo giá trị của phần mềm của bạn?

Một trong những nguyên tắc nhanh nhẹn là bạn nên đo phần mềm làm việc:

Phần mềm làm việc là thước đo chính của sự tiến bộ - 12 nguyên tắc của Agile

Vấn đề là, trong khi tôi có thể đo phần mềm của mình theo các câu chuyện được thực hiện, các lỗi bị đè bẹp hoặc khối lượng báo cáo lỗi giảm, tôi vẫn bế tắc về cách đo giá trị của phần mềm.

Nếu tôi sử dụng Mike Cohn làm ví dụ và việc anh ấy giúp SalesForce.com mang lại giá trị cao hơn 500% cho khách hàng của mình so với năm trước * - làm thế nào để tôi đo mức tăng đó? Làm thế nào để tôi đo được nơi tôi đang ở ngay bây giờ?

Các số liệu khác anh sử dụng là số lượng tính năng và số lượng tính năng cho mỗi nhà phát triển. Đây là điều tôi có thể giải quyết nếu tồn đọng của tôi theo thứ tự tốt và các câu chuyện đã bị cắt xén bởi 'tính năng', nhưng chúng tôi mới bắt đầu với Agile, vì vậy tôi cần một số cách để tìm ra giá trị mà chúng tôi cung cấp bây giờ , sau đó sử dụng một số liệu tương tự trong sáu tháng, để xem liệu chúng tôi đã tăng sản lượng của mình chưa.

Tôi đã nghe nói về việc đo lường giá trị của phần mềm bằng cách tăng doanh thu, hoặc tăng sự hài lòng của khách hàng (bạn sẽ đo lường như thế nào?) Nhưng những sự gia tăng đó có thể được quy cho bất cứ điều gì trong công ty (bán hàng, kế toán, hỗ trợ) chứ không phải trực tiếp đến công việc bộ phận của tôi đang làm.

Vì vậy, làm thế nào để các bạn đo lường giá trị của phần mềm của bạn và bạn đã bắt đầu như thế nào?

* Thành công với Agile - Mike Cohn

Đây là cách tôi định nghĩa giá trị nói chung (ngay cả phát triển phần mềm bên ngoài)

Bạn xác định giá trị là gì .

Nếu giá trị là số tiền kiếm được / được lưu nhờ phần mềm, giá trị sẽ là:

Doanh thu - Chi phí phát triển = Giá trị

hoặc là

Chi phí hoạt động đã lưu - Chi phí phát triển = Giá trị

Nó có thể được lật lại. Bạn có biết những gì chi phí doanh thu trong công ty của bạn? Nếu bạn có thể đo lường nó, giảm 50% doanh thu của bạn nhờ nhanh nhẹn sẽ cho phép bạn tính giá trị mà nó cung cấp:

Giảm 50% doanh thu = (Chi phí doanh thu / 2) = Giá trị

Giá trị có thể là bất cứ điều gì quan trọng với bạn , người xác định giá trị là gì.

Đó là lý do tại sao giá trị được đánh giá theo điểm nhanh nhẹn. Điểm được so sánh với điểm câu chuyện để giúp bạn ưu tiên giá trị. Bởi vì bạn phải so sánh giá trị (kinh doanh) (tùy ý) với giá trị điểm câu chuyện (chi phí).

Trong nhiều trường hợp, giá trị của phần mềm được đo bằng cách tính "thu nhập tăng thêm" hoặc "tiết kiệm chi phí đạt được".

Trong các trường hợp khác, nơi phần mềm được tích hợp một phần của một hệ thống lớn hơn (tức là phần mềm điều khiển xe hơi), điều đó khó khăn hơn. Bạn đo lường chi tiêu để thực hiện (giá trị = chi phí) hoặc bạn tính giá trị của toàn hệ thống (thu nhập tăng thêm / tiết kiệm chi phí lưu trữ) và phân bổ một phần nếu cho phần mềm (ví dụ tỷ lệ với chi phí của phần mềm so với tổng chi phí)

Đơn giản chỉ cần đặt bạn phải tìm ra sự khác biệt tài chính giữa việc có nó và không có nó là gì.

Nếu một chút phần mềm tự động hóa một quy trình có nghĩa là hai người làm việc toàn thời gian không phải thực hiện nhiệm vụ đó nữa, thì đó là tiết kiệm tiền lương hàng năm của họ (cộng với chi phí liên quan) cho công ty. Nếu nhân viên bán hàng trung bình bán nhiều hơn 10% so với những người không sử dụng hệ thống mới, lợi ích là 10% tổng doanh số cho tất cả nhân viên bán hàng có thể sử dụng phần mềm.

Các số liệu có thể chỉ thô và sẵn sàng nhưng hầu hết mọi thứ có thể được định lượng đủ để cung cấp cho bạn một số ấn tượng hữu ích về những gì mong đợi.

Đây là một câu hỏi mẹo. Tôi không chắc chắn tôi thích số liệu "tính năng / nhà phát triển", vì không phải tất cả các tính năng đều được tạo như nhau. Một số tính năng là "Phải có" và sẽ đánh cắp khách hàng khỏi đối thủ cạnh tranh của bạn. Một số tính năng tối nghĩa và có thể được sử dụng bởi 0,1% khách hàng của bạn và họ cũng có thể làm tốt nếu không có nó.

Upticks trong doanh thu là tốt nếu bạn có thể dễ dàng tương quan nó với sự đột ngột của doanh số / gia hạn phần mềm với thời điểm phát hành mới. Ngoài ra nếu bạn bằng cách nào đó có thể theo dõi chuyển đổi người dùng từ sản phẩm cạnh tranh sang bản phát hành mới. Sự hài lòng của khách hàng có thể được đo lường bằng số lượng cuộc gọi vui vẻ (hoặc thiếu cuộc gọi tức giận) được chuẩn hóa theo số lượng khách hàng hoặc doanh số. Để liên hệ trực tiếp những điều này với bộ phận của bạn, điều quan trọng có thể là thời gian của những thay đổi này và thời gian của phần mềm bạn phát hành.

Phần mềm làm việc là biện pháp. Lắng nghe công khai với người dùng của bạn và liên quan đến họ trong quá trình phát triển. Thường xuyên cung cấp các chức năng mà họ nói với bạn là cần thiết khi họ cần. Cung cấp trong khối nhỏ để người dùng cảm thấy tiến bộ.

Nếu bạn chỉ mới bắt đầu phát triển nhanh hoặc thậm chí là một dự án mới ... thì các bên liên quan cần phải có một chút niềm tin. Điều này đòi hỏi chủ sở hữu sản phẩm phải nói rõ tại sao nhanh nhẹn hơn các quy trình khác (tôi cho rằng bạn nghĩ rằng đó là trong tình huống cụ thể của bạn).

Nếu chủ sở hữu sản phẩm không chắc chắn tính năng (câu chuyện) nào mang lại giá trị tương đối nhất thì bạn cần phải ngồi lại với các bên liên quan và tìm ra nó. Lập kế hoạch poker là một công cụ tốt cho điều đó. Việc chỉ định giá trị doanh nghiệp tương đối cho mỗi câu chuyện cũng giúp ưu tiên nhưng hãy cẩn thận không nói chuyện với các quầy đậu về "Giá trị doanh nghiệp nhanh" không giống như ROI!

Thường có một dòng dưới cùng "cứng" có thể dễ dàng đo lường để giữ cho quầy đậu hạnh phúc, "Tính năng X đã tăng doanh thu của chúng tôi thêm 150%". Nhưng thường xuyên hơn không phải là sự kết hợp của các giá trị 'cứng' và 'mềm' "Doanh thu của chúng tôi tăng 160% và chúng tôi nghĩ rằng chúng tôi có thể quy cho sự thay đổi phần mềm khi trung bình khách hàng cho chúng tôi xếp hạng cao hơn 11% với tính năng UI mới ".

Thật sự rất khó để đo lường những điều này một cách chính xác - hãy thử nhìn nó một cách toàn diện nhất có thể.