Estimate công việc thế nào để không bị Stress???

Lời tựa:

Hiện nay, những mô hình quản lý mới như: Scrum, Agile...v.v đang ngày càng được ứng dụng rộng rãi trong việc phát triển phần mềm. Mục đích chung của các mô hình này đều hướng đến việc tạo ra sản phẩm tốt, bàn giao cho khách hàng đúng deadline. Tuy nhiên, trong quá trình phát triển, cũng có rất nhiều yếu tố ảnh hưởng đến chất lượng công việc. Một trong số đó là việc estimate thời gian? Estimate thời gian hợp lý, đảm bảo tiến độ dự án luôn là bài toán đau đầu với những nhà quản lý.

Bài viết này của một tác giả người Nhật, đề cập đến cách Estimate công việc một cách hiệu quả, giải thoát bạn khỏi Stress và nỗi bất an. Mình thấy khá hay nên muốn chia sẻ cùng các bạn^^

h1<Phương pháp estimate và lên kế hoạch giúp giải thoát bạn khỏi bất an và Stress>

Nếu phải bắt đầu bài viết từ đâu thì tôi xin phép bắt đầu từ mệnh đề: Con người cảm nhận được nỗi "Bất an".

Con người là một sinh vật sống có thể suy nghĩ về tương lai. Chính vì có năng lực khác biệt này, con người có khả năng dự liệu được những việc có thể sẽ xảy ra, và ngay lập tức bật công tắc "Bất an" lên. Khi làm việc hay trong 1 dự án, con người thường có xu hướng nghĩ về những việc ở thì tương lai, như : "Nếu không kịp tiến độ thì sao nhỉ?", "chả biết việc này có hoàn thành suôn sẻ không đây?"...v.v Những suy nghĩ đó dần tích tụ và ngày càng gây nên cảm giác hoang mang, "bất an" hơn.

Thêm nữa, việc chịu đựng cảm giác bất an cũng tốn rất nhiều năng lượng. Chắc hẳn nhiều người trong các bạn đều đã trải qua tình huống: Khi đang bận học, tập trung ôn thi...v.v, bản thân không muốn dọn dẹp phòng, nhà cửa. Nhưng bạn không thể ngừng suy nghĩ về việc dọn dẹp, cứ lo ngay ngáy về việc “mình không dọn phòng”. Rốt cuộc bạn lại mất thời gian vào lo lắng, có phải không ?

Mặt khác, con người lại có thói quen: Lảng tránh những việc mà họ vô thức cảm thấy là không an toàn. Bài viết này sẽ phân tích về: "Nỗi bất an của bạn trong project là gì?" và đưa ra phương pháp estimate, lên kế hoạch nhằm giảm sự bất an xuống mức tối thiểu.

ESTIMATE QUÁ LẠC QUAN, ESTIMATE QUÁ BI QUAN

Tôi thường nhận được những vụ nhờ tư vấn từ các venture company (các công ty đầu tư trong lĩnh vực mới, nhiều tính rủi ro, mạo hiểm). Mặc dù đang nắm trong tay những kỹ sư có ý thức trách nhiệm cao với công ty, có tinh thần phấn đấu nhưng tại những công ty đó vẫn xảy ra tình trạng: nhân viên “Không hoàn thành các chức năng đúng thời hạn bàn giao sản phẩm (release). Có thể năng lực họ vẫn còn yếu, nhưng tuyệt nhiên họ không phải là những kẻ lười biếng.Dường như, một trong những nguyên nhân chính dẫn đến tình trạng trên là do: Họ đã quá lạc quan khi estimate thời gian thực hiện công việc.

Ngược lại, tôi cũng thường được nghe câu chuyện: các member có xuất thân từ SI (System Integration) thường estimate thời gian quá dài so với mức thônng thường. Tại sao họ lại estimate bi quan đến vậy?

Những người thuộc loại thứ nhất (estimate quá lạc quan) là những người có ý thức commit thành tích quá cao, tới mức thừa thãi. Vì vậy, họ estimate ngắn hạn và đặt mục tiêu sẽ nỗ lực hết mình để hoàn thành mục tiêu. Còn những người thuộc loại thứ 2 lại là những người có ý thức trách nhiệm về mặt thời hạn bàn giao sản phẩm quá lớn. Có lẽ chính vì muốn đảm bảo về mặt thời gian như vậy nên họ đã vô tình estimate thời gian quá dài.

Những lúc gặp phải tình huống như vậy, trong câu chuyện với các businessman, người phụ trách dự án…v.v, tôi thường đưa ra lời khuyên: “Hai bên quản lý-nhân viên nên cùng nhau tìm hiểu, nắm bắt các nguyên nhân gây chậm tiến độ và đặt mục tiêu chung là: "không được chậm deadline" ”. Điều này cũng có nghĩa là: tập trung vào nỗi “bất an”, chúng ta có thể kiểm soát tình hình dự án.

BIỂU ĐỒ HÌNH NÓN VỀ "TÍNH KHÔNG CHẮC CHẮN"

Các bạn đã từng nghe thuật ngữ “biểu đồ hình nón về Tính không chắc chắn” bao giờ chưa?

Đây là một loại biểu đồ nhằm theo dõi “tính không chắc chắn”- một yếu tố song hành với tiến độ của dự án, từ khi bắt đầu cho đến khi kết thúc. Nhìn vào biểu đồ này, ta có thể biết “tính không chắc chắn” đang ở mức nào? Phần trên của biểu đồ là “tính không chắc chắn” dự kiến, phần dưới là “tính không chắc chắn” đang tồn tại trong thực tế.

Tuy nhiên, trong quá trình làm dự án, do nhiều yếu tố khác nhau, hình dạng của biểu đồ nón sẽ không thể đẹp được như hình vẽ trên. Nhìn vào biểu đồ, có thể dễ dàng nhận thấy: Phần lớn các yếu tố gây hoang mang, không chắc chắn đều tập trung vào thời kỳ đầu của dự án. Với biểu đồ hình nón này, chúng ta có thể dễ dàng nhận biết những thay đổi khi “tính không chắc chắn” dần giảm xuống.

Việc phát triển phần mềm, bản thân nó đã là một công việc đòi hỏi tính sáng tạo. Do đó, một dự án là một tổng thể của sự kết hợp giữa hai phần “Không hiểu” và “Chưa từng làm bao giờ”

Ngược lại, thị trường của ngành phát triển phần mềm hiện nay hầu như đang làm việc theo các kế hoạch kinh doanh, được lập ra chi tiết cao độ - dựa trên kế hoạch phát triển. Thời hạn deadline cho phép cũng được chỉ định nghiêm ngặt. Những điều này là những yêu cầu về mặt business nên không thể thay đổi được.

Tuy nhiên, khi tôi hỏi business man hoặc những người quản lý dự án câu hỏi: “Nếu kế hoạch phát triển bị muộn N tháng nhưng bạn chỉ biết được điều đó trước M tháng, liệu bạn có thể xử lý được không?” thì trong hầu hết các trường hợp, tôi đều nhận được câu trả lời là “Có”.

Cách thức xử lý cho case này có thể kể đến các phương án sau: Kéo dài thời gian press release (đưa ra thông báo về việc release muộn), điều chỉnh những người có liên quan, yêu cầu cắt giảm chức năng, điều thêm người vào dự án...v.v

Ý nghĩa của những việc này chủ yếu là để: chia sẻ và sớm xử lý được các rủi ro, giúp dự án tiến triển suôn sẻ và đạt được mục tiêu trong business.

BẤT AN VÀ TÍNH KHÔNG CHẮC CHẮN

Trong dự án, nỗi bất an xảy ra tại 2 thời điểm.

Một là: Khi người quản lý không nhận thấy bất cứ dấu hiệu nào của “tính không chắc chắn”. Thời điểm còn lại là khi: Có quá nhiều các công việc lúc nhìn ra được “Tính không chắc chắn” – điều mà trước đây bản thân họ không nhận ra.

Nếu không nhận thấy “Tính không chắc chắn” , khi phát triển dự án, mọi người sẽ có xu hướng xử lý các công việc dựa theo những gì đã được làm rõ, những điều chắc chắn.

Kết quả là, họ sẽ luôn canh cánh trong lòng về những vấn đề chưa rõ ràng, ngày qua ngày phải chịu đựng sự bất an đó. Việc này sẽ gây ra cho developer stress, cảm giác như họ đang bị một sợi tơ cuốn quanh cổ và dần bị siết lại.

Mặt khác, cũng tồn tại một rào cản rất lớn khi mọi người đã cố gắng và tìm ra được yếu tố mang “tính không chắc chắn”. Lý do là vì: Con người luôn cố gắng lảng tránh, không muốn đối diện trực tiếp với nỗi bất an. Có thể nói, việc đưa vấn đề chứa đựng “tính không chắc chắn” ra ánh sáng chính là công việc của Project leader, Scrum master...v.v

Ví dụ 1: trong Daily scrum, bằng việc phân công “Task thực hiện trong ngày hôm nay”, người quản lý sẽ giúp member không suy nghĩ về tương lai nữa, chỉ tập trung cho công việc của ngày hôm nay.

Ví dụ 2: nếu làm với Backlog grooming hay kế hoạch theo Sprint...v.v: Do tất cả các member đều có thể nhìn thấy hiện trạng dự án, gây nên tâm lý lo lắng về tương lai. Kéo theo đó, từng cá nhân sẽ khó vượt qua được rào cản bất an đã nêu ở trên.

Bằng việc làm sáng tỏ, giảm thiểu được các vấn đề có chứa “tính không chắc chắn”, kể cả các vấn đề phát sinh do những nguyên nhân khác hai nguyên nhân đã kể trên, người quản lý đồng thời cũng đã giúp giảm nguyên nhân gây stress cho member của mình.

Ngược lại, nếu không thể thực hiện được những điều trên, thì dù có sử dụng phương pháp quản lý theo Scrum hay Agile...v.v đi chăng nữa, thì rồi cũng trở thành “Dự án chỉ bàn giao được theo từng sprint”, bản thân phương pháp quản lý vốn linh động, hiệu quả lại bị biến tướng thành các nguyên nhân gây stress.

<Đường giới hạn thời gian và feature>

Các project thường được phân thành 2 loại.

Loại thứ nhất là “Dự án bị giới hạn thời gian”. Loại này là dự án: Đến ngày đã chỉ định là phải release.

Loại thứ hai là “Dự án giới hạn chức năng”. Đây là loại dự án: Sau khi thực hiện xong một chức năng nhất định, sẽ tiến hành release luôn.

Trong thực tế, với những dự án giới hạn thời gian, thì “Schedule buffer” sẽ được tính thêm. Còn với những dự án giới hạn chức năng, thì sẽ được thiết lập thêm “Feature buffer”.

Schedule buffer là: Nếu muốn sau 10 tháng nữa dự án release: thì phải xác định thời gian dự kiến hoàn thành là 9 tháng, còn lại 1 tháng là thời gian buffer.

Trong khi đó, với Feature buffer: Các chức năng sẽ được sắp xếp theo thứ tự ưu tiên, rồi phân chia thành hai loại: “Chức năng mong muốn ngay từ đầu” và “Chức năng có mức độ cần thiết thấp nhất”. Nói một cách ngắn gọn: Dù tồn đọng “Chức năng có mức độ cần thiết thấp nhất” thì vẫn có thể release, bàn giao sản phẩm được.

Kết hợp hai phương án này lại với nhau, cũng có những dự án mà các bạn có thể áp dụng cả hai phương pháp. Nếu có điểm nào chung nhau trong hai phương án trên, thì có thể thấy: Đảm bảo thời gian “release” chính là điểm chung đó.

Feature buffer sẽ phát huy hiệu quả khi người quản lý lo lắng : “Tính không chắc chắn” lớn nhất trong dự án là “thị trường”. Phương pháp này dựa trên hướng suy nghĩ: Không biết phản ứng của người dùng với sản phẩm cho đến khi release. Vì vậy, họ cần release xong rồi mới thực hiện các “chức năng có mức độ cần thiết thấp nhất”. Việc này sẽ giúp giảm thiểu được “tính không chắc chắn” không cần thiết khi làm việc.

Schedule buffer sẽ phát huy hiệu quả tốt khi người quản lý lo lắng: “Tính không chắc chắn lớn nhất trong dự án là KHI NÀO có thể release được. Phương pháp này dựa trên hướng suy nghĩ: Nếu ngày release bị chậm thì sẽ gây những thiệt hại rất nghiêm trọng, gây ảnh hưởng đến: đánh mất cơ hội, gây ra những tổn thất về mặt hợp đồng…v.v nên nếu giảm thiểu được “tính không chắc chắn” của Schedule thì sẽ đem lại kết quả tốt.

Trong thực tế, có khá nhiều các dự án kết hợp cả hai phương pháp estimate trên.

Sở dĩ có việc này là do: Việc estimate còn liên quan đến: Marketing, uy tín với đối tác kinh doanh, rồi còn cả sự thành bại khi bị đánh giá trên của thị trường…v.v Chính vì thế, dựa theo tính chất của dự án, việc kết hợp hai phương pháp estimate là rất quan trọng. Nên sử dụng Feature buffer ở mức độ nào? Nên lập Schedule feature ở mức độ nào? Người quản lý phải lựa chọn sao cho hợp lý.

Dù là phương pháp nào đi chăng nữa thì hai loại buffer này đều giúp thúc đẩy tiến độ dự án và làm giảm “tính không chắc chắn”. Khi “tính không chắc chắn” giảm xuống thì đồng thời cũng giảm nỗi bất an cho cả team.

BẤT AN VÀ ĐỊNH LƯỢNG HÓA

Lấy ví dụ với Schedule Buffer, chúng ta hãy cũng suy nghĩ về phương pháp định lượng hóa lượng nỗi bất an, hay nói cách khác là định lượng hóa “tính không chắc chắn”.

Để định lượng được, chúng ta sẽ sử dụng phương pháp được gọi là SRSS (Square Root Sum of Squares).

Đây là phương pháp: với mỗi task, người quản lý sẽ ước tính và đưa ra hai thông số: “Story point trung bình” (tính theo đơn vị thời gian cũng OK) và “Story point trong trường hợp xấu nhất”.

Lấy “Story point trong trường hợp xấu nhất” trừ đi “Story point trung bình”, rồi bình phương kết quả đó lên. Sau đó tính tổng của các số bình phương rồi lấy căn bậc hai kết quả thì sẽ ra thời gian buffer thêm. Xác suất này chính xác tới 95%.

Ví dụ trong dự án trên: Lấy 14-8=6. Bình phương kết quả →36. Tương tự như vậy, 20 – 9 =11. Bình phương kết quả →121 ...v.v đến task 10

Tổng các bình phương là 213. Lấy căn bậc hai của 213 thì ra kết quả là 14.6

Vì schedule buffer là 14.6 nên nếu 1 story point tương đương với 1 man day thì sẽ lấy buffer là 15 man.day. Nếu ước tính theo phương pháp này, hầu hết các dự án sẽ hoàn thành đúng trong thời hạn. Để cắt giảm tối thiểu “Hàm lượng bất an” dựa trên cách tính trên, chúng ta nên lên kế hoạch thế nào để mang lại hiệu quả tốt nhất? Vì vậy trong phát triển phần mềm, điều quan trọng là làm thế nào để rút ngắn thời gian buffer của dự án xuống càng ngắn càng tốt.

Chính vì thế, việc hoàn thành các Task theo thứ tự từ lớn đến bé của chỉ số “Bất an bình phương” như trên là hiệu quả nhất. Ở đây, tôi lấy ví dụ với 100 task random. Chúng ta hãy cùng xem xét biểu đồ phía dưới sẽ thay đổi như thế nào đối với hai trường hợp sau:

-Trường hợp hoàn thành các task theo thứ tự random

-Trường hợp hoàn thành các task khi được sắp xếp theo thứ tự từ trên xuống của chỉ số “bất an”^2

Chú thích: * chia task chính xác * giá trị trong trường hợp xấu nhất: là giá trị random bằng 2 lần giá trị lớn nhất.

Như vậy, với việc xử lý các Task theo thứ tự “Lượng bất an” từ cao xuống thấp, chúng ta có thể giảm được thời gian Schedule buffer (thời gian cộng thêm để back up). Hiện nay, phương pháp làm Task theo estimate dựa trên chỉ số “Bất an bình phương” đã giúp làm giảm “tính không chắc chắn” trong Project xuống còn ¼. Trong khi với phương pháp làm task theo thứ tự random, trên ¾ “tính không chắc chắn” vẫn còn tồn đọng.

Với các dự án trong thực tế, việc so sánh, cân nhắc “tính không chắc chắn” của schedule và tính hiệu quả của feature để đưa ra phương án thích hợp cho việc kinh doanh là rất quan trọng. Vì vậy, bằng việc sắp xếp vị trí ưu tiên dựa trên “tính không chắc chắn” của schedule như đã nêu trên sẽ nhanh chóng giúp cắt giảm thiểu schedule buffer, tăng tính cạnh tranh cho công ty của bạn.

Với các Project mà schedule có mức độ “bất an” lớn thì phương pháp này là một cách tiếp cận có hiệu quả.

GIẢM THIỂU “LƯỢNG BẤT AN” BẰNG CÁCH PHÂN CHIA CÁC STORY

Tuy rất ưu việt như đã trình bày ở trên, nhưng có phải việc sắp xếp thứ tự ưu tiên khi làm Task là cách duy nhất để làm giảm “lượng bất an”???

Tất nhiên là không phải như vậy rồi.

Có nhiều trường hợp, trong dự án tồn tại nhiều nguồn phát sinh gây nên “tính không chắc chắn” khác. Dưới đây là một số ví dụ:

• Sử dụng Middle ware chưa từng dùng qua.

• Sử dụng Algorithm mà bản thân chưa hiểu rõ

• Liên kết ngoài

• Spec cụ thể chưa được quyết định.

….v.v

Vậy làm cách nào để sáng tỏ các vấn đề trên? Bằng việc chia nhỏ Task và story, nhà quản lý có thể giảm được “tính không chắc chắn” và “story point”. Ở một mức độ nào đó, nếu nắm bắt được hai điều trên trước khi start dự án, người quản lý có thể lên kế hoạch từ Sprint zero, và có thể đối ứng bằng các phương pháp, ví dụ như: Viết code PoC (Proof of Concept) , tổng hợp spec cụ thể...v.v

Ngoài ra, trong dự án, khi phát sinh task có “lượng bất an lớn”, srum master và member cũng có thể trao đổi, thảo luận với nhau để làm giảm lượng bất an đó khi phát triển phần mềm.

LOẠI BỎ “TÍNH KHÔNG CHẮC CHẮN”.

Ở một trường hợp khác, khi áp dụng Feature buffer, ta cũng có thể xem xét và và loại bỏ các task có “tính không chắc chắn” cao. Các task này là các task có hiệu quả mong đợi thấp, “tính không chắc chắn” cao. Tuy nhiên trong dự án, những task này lại không phải là các rủi ro. Bằng việc đánh giá “tính không chắc chắn” của schedule, nhà quản lý có thể xem xét các task như trên và remove những task đó ra khỏi kế hoạch release.

KẾT LUẬN

Project là một tổng thể đi kèm những vấn đề chứa đựng “tính không chắc chắn”. Tuy nhiên “Tính không chắc chắn” hoàn toàn có thể xử lý bằng cách ước tính theo Feature buffer và Schedule buffer.

Nhìn nhận và cắt giảm các yếu tố buffer dựa trên tiến độ của dự án, nhà quản lý có thể loại bỏ phần “Bất an” và “Stress” ra khỏi team của mình. Khi thực hành phát triển phần mềm theo mô hình Agile, hầu hết các kế hoạch được giới thiệu đều tập trung vào Feature buffer nên mọi người thường bị hiểu sai. Nếu hiểu rõ và áp dụng Scrum linh hoạt, thì dù là các project có schedule “khó nhằn”, chúng ta vẫn có thể giải quyết, không gặp phải vấn đề gì.

Srum Master , giám đốc dự án …v.v chính là những người đóng vai trò xóa bỏ “tính không chắc chắn” – nguyên nhân gây bất an, giúp nâng cao hiệu quả làm việc của cả Team.

Project owner có thể kết hợp linh hoạt giữa hai phương án buffer tác giả đã nêu và lựa chọn kế hoạch phù hợp với môi trường kinh doanh của công ty mình.

Cuối cùng, tác giả hy vọng bài viết này sẽ giúp ích cho các bạn trong việc quản lý project^^.

Link bài gốc:

http://qiita.com/hirokidaichi/items/5a204a57a200569f755d?utm_source=Qiitaニュース&utm_campaign=2d3c14af0f-Qiita_newsletter_225_09_14_2016&utm_medium=email&utm_term=0_e44feaa081-2d3c14af0f-32962049

                                                         Người dịch: Thanh Thảo