Sau khi quen với việc sử dụng “story point” (sau đây gọi tắt là “point”), nhóm nhận thấy có thể tính toán chi phí trên mỗi “point” (CPP). Nhờ đó, Product Owner (PO) có thể sử dụng hệ số này để đưa ra những quyết định quan trọng. Ví dụ, nếu như CPP của nhóm là $2,000, PO có thể ước lượng nhanh với một hạng mục 10 “point” sẽ có chi phí khoảng $20,000 và PO có thể quyết định liệu hạng mục đó có đáng để đầu tư hay không.
Mặc dù nhiều nhóm đều thấy cách tính toán này khả thi, nhưng họ vẫn e ngại rằng liệu có bất kỳ nguy cơ nào không khi sử dụng hệ số CPP.
Trước khi xem xét về độ rủi ro của nó, hãy cùng tìm hiểu về cách tính hệ số CPP và cách sử dụng nó.
Để có thể tính được hệ số CPP của một nhóm, đầu tiên chúng ta cần xác định được khoảng thời gian thích hợp để thực hiện phép tính, nên từ 03 sprints trở lên. Thực ra, nếu có thể thì 03 tháng sẽ tốt hơn, vì sẽ có nhiều sprints hơn, tuy nhiên điều này còn phụ thuộc vào độ dài của mỗi sprint.
Trong một khoảng thời gian xác định, tính tổng số “points” đã được chuyển giao. Đơn giản chỉ cần tính tổng vận tốc của nhóm trong mỗi sprint. Trong biểu đồ minh họa dưới. đây, sau 07 sprints (tương đương 14 tuần), nhóm này đã chuyển giao 167 “points”
.jpg)
Tiếp theo, cần xác định xem nhóm được trả bao nhiêu trong khoảng thời gian này. Đương nhiên bộ phận nhân sự sẽ không công khai mức lương từng người, nhưng họ có thể cho bạn biết tổng chi phí của cả nhóm trong khoảng thời gian đó và như thế là đủ.
Bạn cũng cần nghĩ xem có nên tính thêm chi phí cho người nào nữa không vì thỉnh thoảng nhóm của bạn cần tham khảo ý kiến của một kiến trúc sư hệ thống (architect) hay làm việc với một kỹ sư DevOps, những người không phải là thành viên chính thức của nhóm nhưng đã hỗ trợ nhóm vài lần mỗi tuần. Việc có tính luôn phần lương của những người này vào hay không là tùy thuộc vào bạn, nhưng thông thường những người làm bán thời gian như họ sẽ không ảnh hưởng đến các quyết định dựa trên hệ số CPP của nhóm.
Ngoài ra, bạn sẽ cần quyết định giữa việc sử dụng lương hay là tổng chi phí lao động. Tổng chi phí lao động sẽ bao gồm thêm những khoảng chi phí khác như chi phí thuê văn phòng, những lợi ích khác, chi phí trả cho những ngày nghĩ phép, … Ví dụ một thành viên kiếm được $40 mỗi giờ thì chi phí công ty phải trả sẽ nhiều hơn con số đó. Thông thường bạn sẽ biết được con số đầy đủ từ đại diện bộ phận tài chính của công ty.
Chúng ta không nên bận tâm về tổng chi phí lao động, bởi vì cũng như trường hợp những người ngoài nhóm làm việc bán thời gian, điều đó sẽ không khiến quyết định bị thay đổi.
Ví dụ, giả sử có một nhóm 8 thành viên, được trả tổng cộng $160,000 cho 14 tuần làm việc. Từ biểu đồ Velocities/Sprints trên đây chúng ta xác định nhóm này đã chuyển giao 167 “points”. Để tính được hệ số CPP, lấy tổng chi phí được trả $160,000 chia cho tổng số “points” 167 sẽ được đáp án là $958 (CPP).
Có nhiều cách sử dụng hệ số CPP hiệu quả, trong đó có hai trường hợp phổ biến. Thứ nhất, hệ số CPP rất hữu ích với PO, người cần phải quyết định liệu rằng một tính năng có khả dĩ để phát triển hay không.
Hãy tưởng tượng bạn là PO, nhóm của bạn đã ước lượng một tính năng trước đó là 40 “points”. Biết rằng hệ số CPP là 958, vậy câu hỏi trong đầu bạn là liệu có đáng bỏ ra $38,320 (958 x 40) cho tính năng đó không?
Thậm chí sẽ tốt hơn khi PO hiểu rằng 40 points chỉ mới là ước lượng của nhóm. Chi phí nên được trừ hao thêm đễ đảm bảo an toàn cho khi quyết định xây dựng một tính năng mới. PO nên cộng thêm ít nhất 50% và nghĩ xem liệu chi phí đó có hợp lý hay không.
Có thể sử dụng hệ số CPP để ước lượng chi phí phát triển của một dự án, một sản phẩm hoặc một nhóm các tính năng. Việc này thường xuyên xảy ra trong quá trình thương thảo hợp đồng. Giả sử một công ty đang thương thảo hợp đồng phát triển một sản phẩm mới, nhóm ước tính sản phẩm khoảng 200 “points”. Như chúng ta đã biết, hệ số CPP là $958, vậy sản phẩm mới sẽ có giá gần $200,000 (200 points * $958)
Lưu ý rằng $200,000 không phải là giá chào vì giá đó chưa bao gồm chi phí lao động hay phụ cấp, nhưng có thể xem $200,000 là giá ban đầu và những mục bổ sung sẽ được thêm sau.
Lưu ý cả hai cách sử dụng hệ số CPP ở trên thì chi phí được tính cho một nhóm, không phải là chi phí của một cá nhân làm công việc nào đó. Nó là chi phí trung bình tính trên một số lượng “points” lớn (ví dụ: 40, 200)
3.1 Sử dụng hệ số CPP quá hẹp.
Nhiều thứ có thể đi sai hướng nếu hệ số CPP được sử dụng quá hẹp. Một sai lầm thường gặp là việc mọi người nhìn vào hệ số CPP ở cấp độ cá nhân, dựa trên “velocity” của từng cá nhân thành viên, đây là một sai lầm.
Không thể tính toán velocity cho từng cá nhân cụ thể vì không có bất kỳ một hạng mục nào có thể chuyển giao bởi duy nhất một người trong nhóm. Mỗi một hạng mục yêu cầu sự tham gia của một lập trình viên, một kiểm thử, một DBA (Quản trị cơ sở dữ liệu), một người phân tích, một thiết kế và còn những người khác nữa. Với quá nhiều loại công việc khác nhau như thế, việc phân bổ “points” cho từng vai trò/ cá nhân cụ thể là đều không thể. Vì vậy velocity chỉ có thể được tính ở cấp độ nhóm.
Nguy cơ cũng có thể xảy ra khi ta dùng để tính chi phí cho những hạng mục nhỏ. Giả sử một hạng mục chỉ có hai “points” và chỉ bao gồm hai công việc là viết mã và kiểm thử. Nhóm chỉ có một người kiểm thử, nhưng có hai người viết mã, mỗi người đều có khả năng nhận công việc như nhau. Kết quả là một nhà phát triển có thể kiếm được hai lần lương nhưng thực tế “code” nhanh gấp ba lần. Vì vậy với những hạng mục nhỏ, hệ số CPP có thể bị ảnh hưởng bởi thành viên nào làm công việc đó.
Nhưng nếu cũng nhóm đó sử dụng hệ số CPP để đưa ra quyết định cho công việc có 100 “points”, công việc đó sẽ không thể hoàn thành bởi một người. Do vậy, với khối lượng công việc lớn hơn, mọi thứ sẽ ổn.
Bạn cần phải cẩn thận khi sử dụng hệ số CPP ở mức độ quá hẹp.
3.2 Dùng hệ số CPP để so sánh các nhóm
Nguy cơ lớn nhất là ai đó dùng hệ số CPP để so sánh các nhóm với nhau. Điều này là bất hợp lý vì không thể so sánh “velocity” của hai nhóm trừ khi những nhóm này đã thiết lập một cơ sở chung cho việc tính “point” và duy trì nó. Tuy vậy, việc thiết lập một cơ sở chung cho cách tính “point” không phải là một ý tưởng hay.
Việc so sánh nhóm dựa vào hệ số CPP đến từ suy nghĩ sai lầm rằng “velocity” có thể được dùng như một cách để đo lường hiệu suất công việc. Điều này không đúng vì một nhóm với “velocity” thấp hoàn toàn có khả năng làm việc hiệu quả hơn một nhóm có “velocity” cao hơn.
Hệ số CPP hỗ trợ cho việc đưa ra quyết định
Hệ số CPP của nhóm có thể giúp chúng ta có thêm những sự chọn lựa. Nó dễ tính và dễ sử dụng trong các tình huống đặc biệt; chỉ cần làm việc với những con số làm tròn và ước lượng sơ bộ là đủ để giúp PO quyết định xem tính năng đó có xứng đáng với nổ lực bỏ ra hay không.
Hạn chế chính của hệ số CPP trong việc sử dụng nó để so sánh các nhóm đã không còn là vấn đề mới mẻ đối với hầu hết Scrum Masters hay Coaches. Stakehodlers thường hay so sánh các nhóm với nhau, nhưng họ sẽ chỉ hay so sánh về velocity, vì vậy việc biết thêm hệ số CPP của nhóm cũng không làm mọi thứ tệ hơn.
Nguồn: https://www.mountaingoatsoftware.com/blog/is-it-dangerous-to-calculate-the-cost-per-point
