/ Chuyện đi làm

Công thức Estimate cho mọi thể loại project

Estimate (ước tính khối lượng công việc) thường là chủ để gây tranh cãi lớn nhất giữa dev và quản lý dự án (PM).

Có nhiều người cho rằng estimate là việc lãng phí thời gian. Một số khác lại nghĩ, thực hiện dự án mà không có estimate giống như cứ đi mà không có đích đến.

Tuy nhiên, cả 2 nhóm này đều công nhận một điều "Thật là khó để đội dev có thể estimate được con số chính xác!"

Có một thực tế về estimate, đó là chúng gần như không bao giờ chính xác bởi vì các task phải làm thường là task mới, mơ-hồ và có nhiều yếu tố không-xác-định xuất hiện trong suốt quá trình thực hiện.

Hầu hết mỗi lần bạn nghĩ là bạn sắp hoàn thành công việc, thì đội kỹ thuật thường cho biết là họ đang phải xử lý thêm một mớ lỗi mới và bạn sẽ không thể phát hành sản phẩm đúng hạn.

Tôi đã từng bị rơi vào hoàn cảnh này khá nhiều lần. Mỗi lần tôi được thông báo thể phát hành sản phẩm đúng hẹn, tôi đều ước mình tìm ra một công thức nào đó để lần sau estimate chính xác hơn.

Có một thực tế mà tôi rất ghét phải thừa nhận đó là thỉnh thoảng tôi biện minh rằng estimate giống như việc dự đoán tương lai, bạn phải may mắn lắm mới có một kết quả chính xác. Xác xuất của việc này tương tự như trò ném phi tiêu trúng hồng tâm vậy...rất thấp!

Tôi cùng một vài người bạn cố gắng tìm kiếm trên Internet những đội khác cũng gặp phải vấn đề này và xem xét xem họ đã xử lý vấn đề như thế nào.

Phần lớn các đội đều rút ra được một công thức: “Sau khi bạn estimate thời gian để hoàn thành một tính năng X, bạn hãy gấp ba con số này lên. 😅”

Nguồn: https://xkcd.com/1658/

Hiển nhiên, đây không phải là công thức estimate chính xác.

Trong quá trình tìm kiếm giải pháp cho vấn đề này, tôi đã học được một thứ đó là không hề có mẹo hay lối tắt để giải quyết vấn đề. Chúng ta cần thực hiện đầy đủ tuần tự các bước để có kết quả estimate chuẩn nhất.

Dưới đây là 4 bước mà tôi đã sử dụng để estimate cho các dự án của mình

Bước 1. Phân bổ thời gian dành cho việc estimate

Nếu bạn thực sự muốn đội của mình có thể đưa ra estimate chính xác nhất, cố gắng đừng bắt đầu câu chuyện bằng những câu kiểu như “tôi cần bạn hoàn thành toàn bộ các đầu việc này trước thời điểm X”.

Đưa ra thời điểm cần hoàn thành trước, rồi mới yêu cầu anh em estimate sẽ khiến cho việc estimate không còn đúng với lẽ tự nhiên. Kéo theo kết quả estimate sẽ không gần với thực tế.

Khi anh em dev bị giới hạn thời điểm deadline và liên tục bị giục hoàn thành việc estimate, mọi người sẽ khó có thể nhìn nhận các yếu tố phức tạp của bài toán để estimate, và sẽ estimate theo kiểu cố gắng làm hài lòng người quản lý là chính.

Do vậy, tốt hơn hơn là cho phép cả team một khoảng thời gian, tùy vào khối lượng của project để nhìn nhận được các vấn đề phức tạp tiềm ẩn và không đề cập tới hạn deadline của các tính năng trước khi estimate.

Việc này để để sau khi estimate xong, để quyết định xem có nên xóa một phải chức năng phức tạp quá hay không.

Bước 2. Chia nhỏ công việc thành các công việc con

Thông thường vào thời điểm bắt đầu dự án, bạn không có đủ thông tin chi tiết về tính năng phải làm. Do vậy, số ngày mà bạn estimate được thường không phản ánh đúng số ngày thực tế.

Tuy nhiên, nếu bạn chia nhỏ công việc cần estimate thành những công việc nhỏ hơn, bạn sẽ có khả năng nhìn thấy được cụ thể những bước cần phải. Do vậy, bạn sẽ estimate được chính xác hơn.

"Khi bạn còn chưa biết được cụ thể bạn sẽ làm những gì, bạn sẽ không thể biết khi nào bạn sẽ hoàn thành nó" –Joel Spolsky, Stack Overflow CEO

Nguyên tắc ở đây là bạn cứ tiếp tục chia nhỏ task cho đến khi thời gian estimate hoàn thành mỗi task nhỏ là từ 8-10h.

Bước 3. Phân loại task

Sau khi chia nhỏ công việc thành những công việc nhỏ hơn, bạn cần lùi lại một chút để nhìn được tổng thể những công việc sẽ phải làm. Bạn sẽ để ý thấy được có vô vàn những việc bạn có thể bắt tay vào làm luôn, một vài việc vẫn còn lờ mờ, và một vài việc vẫn có nhiều điều bí ẩn như là vùng tối phía bên kia của mặt trăng.

Cụ thể hơn, chúng ta có 3 loại công việc sau:

Task đã rõ những việc phải làm (Known Tasks)

Đây là những task mà bạn đã biết rõ input, output và cụ thể các bước cần phải làm để có được output. Do vậy thời gian estimate để hoàn thành công việc này là xác định.

Task mới chỉ rõ một phần những việc phải làm (Partially Known Tasks)

Đây là loại task mà bạn mới chỉ nắm được input, output và nắm được sơ bộ cách làm. Tuy nhiên bạn ước lượng sẽ mất chừng 15-30 phút để tìm hiểu thêm hoặc cần thêm sự trợ giúp từ những người đã gặp vấn đề tương tự để có thể hoàn thành được task.

Task không xác định (Unknown Tasks)

Thường những task này sẽ cần bạn dành khoảng vài giờ tới cả ngày để hiểu công nghệ mà bạn sẽ định sử dụng để hoàn thành task.

Việc xây dựng phần mềm hiếm khi là việc xây dựng những thứ bạn đã biết cách nó hoạt động như thế nào. Thông thường bạn sẽ cần phải tìm những công cụ, nền tảng API khác khau để giải quyết các bài toán. Do vậy, thời gian dành cho việc tìm hiểu hay nghiên cứu là yếu tố quan trọng cần phải được tính vào estimate.

Sau khi phân loại task, bạn cần cố gắng đặt mục tiêu tìm hiểu thêm về project để cố gắng chuyển task Partially Known Tasks Unknown Tasks về loại Known Tasks

Bước 4. Estimate lại

Tới bước này, tất cả các task của bạn đã được chuyển thành Known Task, bạn đã có thêm nhiều thông tin cụ thể hơn cho công đoạn implement. Do vậy, kéo theo là kết quả estimate sẽ chính xác hơn.

Hãy quan sát biểu đồ sau để thấy được sự liên hệ giữa thời gian estimate và mức độ rõ ràng của các yêu cầu cũng như các giải pháp để thực hiện các yêu cầu.

The Cone Of Uncertainty. Nguồn: InformIT

Một ưu điểm của bước này là bạn có cơ hội xem lại các yêu cầu, có cái nhìn tổng quan hơn. Và sẽ có thể phát hiện ra những vấn đề mà ở các bước trước bạn chưa kịp nhìn ra. Một điểm chú ý ở đây là, mỗi khi bạn có thêm thông tin gì mới về project, bạn nên estimate lại để có con số chính xác nhất.

Hãy chú ý 4 thứ sau trong khi bạn đang estimate project

Điều 1. Lưu ý những câu có từ "Chỉ" - "Just"

Có một lệ bất thành văn là thường những task có nhiệm vụ "Chỉ" làm một tính năng nào đó:

  • Task này chỉ nhỏ như con muỗi ấy mà!
  • Chắc chỉ mất 5 phút để fix lỗi thôi
  • Chắc task này không chiếm quá 15 phút đâu.

Những task này ban đầu nhìn có vẻ tốn ít thời gian, nhưng té ra lại thường là loại task tốn kém nhất. Những loại task như thế này hay là nguyên nhân khiến team trễ deadline.

Nguyên nhân chính khiến những loại task này chiếm nhiều thời gian hơn mong đợi là chúng thường xuất hiện từ các cuộc họp standup hàng ngày hoặc qua những cuộc trò chuyện giữa mọi người. Khi dev không có đủ thời gian để xem xét độ phức tạp của task, họ sẽ đánh giá thấp độ phức tạp và dẫn đến estimate sai.

Điều 2. Người nào làm, người đó estimate

Người được giao nhiệm vụ làm task thường là người hiểu rõ hoặc có động lực để hiểu rõ nhất công việc phải làm. Người này sẽ có khả năng nhìn thấy những chi tiết lặt vặt mà cũng không kém phần quan trọng của công việc. Đây là những yếu tố quan trọng để có được estimate chính xác nhất.

Điều 3. Đừng bỏ qua những task lặt vặt

Thường trong quá trình thực hiện project, bạn sẽ nhận được mộ lô những task lặt vặt kiểu như:

  • Checkbug
  • Fixbug
  • Review code
  • Build App
  • Deploy App

Nhìn qua thì những việc này không tốn thời gian lắm. Tuy nhiên luôn có vấn đề nào đó xảy ra. Và bạn sẽ khó mà lường trước được độ phức tạp. Hơn nữa, ngay cả khi không có vấn đề, khi bạn cộng gộp thời gian lại, bạn sẽ có được con số không hề nhỏ.

Điều 4. Xem xét tới một vài khả năng gây ra việc delay bất thình lình

Một thành viên nào đó đột nhiên bị ốm, hoặc có kỳ nghỉ mát, hoặc có một vài ngày nghỉ bắt buộc, hoặc một vài bug khủng xuất hiện vào những lúc không ngờ tới. Bạn cố gắng dựa vào kinh nghiệm đã làm của mình, để xem xét đưa những yếu tố này vào kết quả estimate của mình.

Chú ý ở đây là trong quá trình làm project, bạn cố gắng để ý tới các sự kiện không mong đợi, khả năng xuất hiện của bug theo thời gian để có thể có những chú ý cho những lần estimate tiếp theo

Kết luận

Đối với việc estimate, tìm ra các kết quả chính xác thường rất khó.

Một số người có quan điểm vì nó khó vậy và gần như bất khả thi, nên cũng không quá cần thiết phải cố gắng. Một số lại có quan điểm estimate nên càng sát với thực tế càng tốt, dẫu có không thể tìm được kết quả chính xác, nhưng phải luôn cố gắng nỗ lực để làm được điều đó.

Có một kinh nghiệm về estimate như này:

Vấn đề ở việc estimate lại không có liên quan gì tới estimate. Nó liên quan tới việc bạn cần phải có một hiểu biết rõ-ràng và nắm được chính-xác các bước để giải quyết các vấn đề.

Mỗi lần cố gắng estimate, cả dev cũng như quản lý đều nắm được một vài những thông tin khác nhau, và tất cả các thông tin đó đều liên quan tới kết quả estimate, do vậy việc các thành viên đảm nhiệm estimate nắm được đầy đủ thông tin việc phải làm là vô cùng quan trọng.

Cuối cùng, chúc dự án của các bạn hoàn thành đúng hạn!

HungTUT.com via dev.to

Công thức Estimate cho mọi thể loại project
Share this

Subscribe to HungTUT.com