Hôm nay chúng ta sẽ cùng đàm đạo về một chủ đề khó nhằn đòi hỏi kinh nghiệm nhiều năm trong nghề đó là Estimate – 見積もり. Nó thực sự khó và phần việc này “không dành cho tay mơ” vì liên quan vấn đề tiền bạc. Tại sao BrSE phải biết cái này. Sẽ có nhiều bạn thắc mắc : việc Estimate là của người khác chứ sao BrSE lại làm ? vậy “người khác” đây là ai. Sẽ có 1 ngày bạn sẽ là cái “người khác” đó nên từ bây giờ hãy chuẩn bị những kiến thức cần biết, sau này sẽ dùng. Và một điều mình muốn tiết lộ : không phải Sale, không phải PM, Sếp càng không … mà chính là các bạn – những BrSE cứng là người hiểu hệ thống sâu nhất và chính là người estimate với sai số thấp nhất.

Về định nghĩa mình sẽ không nói ở đây, vì nếu bạn chưa biết estimate là gì thì không nên đọc bài này chi cho đau đầu. Những nội dung mình muốn truyền tải gồm 3 phần :

• Tầm quan trọng
• Những con số
• Phân loại dự án và cách ước tính

Tầm quan trọng của Estimate

Kể chuyện xưa… Cách đây 8 năm mình có join vào 1 dự án phải nói là đình đám nhất lúc đó, vì thời điểm 2010 mà lấy được Project hơn 1 triệu đô là quá kinh khủng (bây giờ thì bình thường). Sau biết bao tháng ngày vật vã chiến đấu, có những tuần liền ăn ở tại công ty và chỉ chợp mắt vài tiếng mỗi ngày. Kết quả cuối cùng là … dự án fail. Quá đắng. Khi tĩnh tâm lại để mọi người cùng phân tích thì có nhiều nguyên do : chất lượng resource chưa cao với tuổi đời khá trẻ và non kinh nghiệm (BrSE 26, PTL 27 tuổi, TL toàn 25, PM 30 còn coder toàn 23-24), Plan không khớp với lượng công việc, chọn sai phương pháp triển khai phải rework nhiều … và 1 đống hầm bà lằng khác. Nhưng nguyên nhân sâu xa nhất và quyết định đến thành bại chính là bản Estimate quá hời hợt ngay từ đầu. Dự tính, ước lượng tất nhiên là có sai số nhưng sai tới 400% là có vần đề nghiêm trọng.

Nói dong dài vậy để các bạn có thể thấy được việc “sai một li đi một dặm” của Estimate. Không những công ty bị thiệt hại nặng, khách cũng đánh giá thấp khả năng ước lượng khối lượng công việc bên mình mà còn vấn đề to tát hơn là đập bể nồi cơm của anh em ở nhà. Vậy nên trước khi trưng ra phải coi cho thật kỹ tất cả khía cạnh, đánh giá mọi rủi ro có thể. Có đôi lúc mặc dù khó cũng phải gửi lời từ chối nếu bị khách ép quá đáng.

Những con số trong Estimate

• 20 – số ngày trong 1 tháng (đã trừ thứ 7 chủ nhật và lễ)
• 5 – số tiếng trong 1 ngày (= 8 tiếng * 62%)
• 10% – task management (Task quản lý của PM – TL)
• 10% – buffer risk (Sai số nếu xảy ra risk)

Nếu 1 anh dev code (+UT) được 20 line Java trong 1 tiếng liên tục thì 1 tháng sẽ code được : 20 * 5 * 20 = 2000 => KLOC = 2000. 1 ngày có 8 tiếng, trong đó sẽ bao gồm nhiều task khác như mail, họp, nghỉ ngơi … khi estimate chỉ nên tính 5, cao lắm thì 6, còn nếu tính 8 chắc chắn phải OT mới keep được deadline.

Còn gì nữa thì sẽ bổ sung sau, mới nhớ ra chừng này.

Phân loại dự án và cách ước tính

Có nhiều phương pháp estimate mà các bạn đã từng nghe như Delphi, COCOMO… nhưng trong các dự án phần mềm thì mình thấy dùng WBS (Work Breakdown Structure) vẫn là chuẩn nhất. Nó có điểm lợi là phân chia rạch ròi công việc ra từ đầu cho tới cuối dự án dựa theo scope mà khách yêu cầu, có thể base để lên Plan-Schedule cho team luôn. Ngoài ra còn 1 yếu tố nữa, nếu các bạn làm với Nhật thì sẽ biết được mức độ kỹ lưỡng của họ. Nếu mình break được công việc ra thành nhiều khối nhỏ họ sẽ dễ đánh giá và approve cho bản estimate mà mình đưa.

Maintenance

Đối với dòng dự án này chúng ta cần tỉnh táo phân tích rõ phạm vi maintain và mức độ ảnh hưởng của các module tới phần còn lại của hệ thống. Đối với những Framework và source được tổ chức tốt cộng với tính độc lập cao của function – method ta sẽ đỡ mất công hơn. Vậy nên trước khi estimate ta cần phải đọc và hiểu cấu trúc source, đặc biệt là phần common thì mới đưa ra được phương án tốt nhất. Về productivity maintain project có hệ số 1.2 đến 1.5 so với code mới. Ví dụ code java có productivity là 2.5 KLOC (2500 line code/1tháng) thì maintain thường rơi vào khoảng 3k đến 3.5k. Cách tính LOC thì không phải chỉ những dòng thêm mới mà cả những dòng chỉnh sửa – xoá cũng phải được liệt kê vào.

Các đầu mục cần list ra :

• Chuẩn bị môi trường – tài liệu
• Phân tích source
• Phần update : cần phân tích độ khó của yêu cầu để đưa ra productivity hợp lý và ước lượng số LOC cần update.
• Phần delete : cần xem xét mức độ ảnh hưởng tới các module khác để thêm bớt thời gian test lại hệ thống.
• Phần add new : nếu có phần tương tự đã có sẵn thì set produtivity cao hơn còn nếu không phải theo qui chuẩn (của công ty bạn qui định đối với năng suất dev trên các ngôn ngữ – FW)
• Test UAT : nếu khách yêu cần thêm cả CT hay IT cũng cần phải đưa vào Estimate.
• Tổng tất cả lại tính ra số MM bước đầu, sau đó cộng với buffer risk (10%) và task quản lý (10%) sẽ ra được con số cuối cùng.

Migration

Có rất nhiều loại : Migration Platform, Migration Language, Migration Version, Migarion database. Đối với dòng dự án này thông thường có tool hỗ trợ, nếu không phải tự tay code ra để dùng. Thời gian code tool cũng sẽ được tính vào trong estimate nhưng đổi lại phải nâng Productivity cho phần update code sau khi converted. Hoặc cũng có nhiều trường hợp estimate dựa trên hình thức làm thủ công nhưng khi triển khai thực tế mình tự code tool để nâng cao năng suất. Cái này không cần cho khách biết vì chuyện nội bộ, mình code tool mà tool không chạy được mình chịu nên nếu làm được tool ngon thì là của mình – không phải của khách.

• Về Platform cái này mình sẽ tiếp tục thu thập kinh nghiệm rồi bổ sung sau, hiện tại vẫn chưa đủ để viết nên các bạn thông cảm dùm.
• Language : ta thường gặp nhất là Lotus Node => Sharepoint, Cobol => Java, Orther => Java, Other => C#, VB => VB.Net …
  Cách làm tối ưu nhất vẫn là lấy mẫu thử (sampling) theo 3 cấp độ : Khó + trung bình + dễ, sau đó cho dev thử (hoặc tự xử nếu code tốt) rồi đưa ra con số. Bước tiếp theo là phân tích module đánh trọng số, sau đó kết hợp với con số productivity ở bước đầu ta sẽ có được con số cuối cùng.
• Verion : Hay gặp nhất là Java old => Java new version, .Net old => .Net new, C => GCC … cách làm cũng là lấy mẫu thử rồi tính toán.
• Database : DB2 => SQL, Oracle => SQL, Other => Oracle, Other => SQL, etx => etc … Cần xác định rõ môi trường 2 DB có kết nối được với nhau không, nếu có thì tool migration data có hỗ trợ tốt không. Ví dụ Oracle => SQL thì có tool SSMA (SQL Server Migration Assistant) của Microsoft hỗ trợ rất tốt nhưng điều kiện 2 server phải thông nhau. Trường hợp không thông thì cần phải get DB cũ lưu ra file từng table riêng => convert DDL => convert Data => Create Data/table/index/sequence… => Import => Test. Các thông số mình cần khách cung cấp : Số lượng table – view – procedure, record, độ phức tạp của dữ liệu …

Development

Đầu tiên là xác định scope : Design => UAT, thì khách cần mình làm công đoạn nào. Sau đó cũng WBS nó ra từng phần nhỏ, ứng mỗi phần lấy mẫu thử rồi tổng hợp lại. Thông số quan trọng nhất mà các bạn cần phải nắm đó là Productivity của ngôn ngữ. Từng công ty sẽ có các thông số khác nhau, ví dụ Java thông thường là 2k5 KLOC nhưng cũng có nơi 2k có nơi 2k7. Riêng dev Nhật thì tầm 3k5 (và lương họ cũng gấp đôi gấp ba lương dev Việt 😀 ).

Tỉ lệ % giữ các công đoạn – tương ứng độ khó : Design – code – test

Giải thích : giả sử tất cả các module đều có độ khó trung bình, sau khi phân tích module và chức năng hệ thống ta tính được con số 15MM dành cho design thì tương ứng sẽ là 10MM code và 5MM test. Trong đó basic design 35% ~ 5MM, detail design 45% ~ 7MM, program design (detail of detail design) 20% ~ 3MM.

Ở mỗi công ty đều có 1 bộ tài liệu với cách tính riêng có chênh lệch đôi chút dựa theo project history (lấy kết quả các dự án quá khứ để đưa ra con số trung bình). Vậy nên các bạn chỉ cần nắm được lõi vấn đề, kết hợp với các thông tin trong các tài liệu tổng hợp đó thì chắc chắn sẽ làm được, không có gì quá khó cả. Dần dần kỹ năng, kinh nghiệm tăng lên và sai số sẽ giảm dần.

Kết

Với những gì mình viết trong bài này chưa đủ để các bạn cho ra một bản 見積 hoàn chỉnh nhưng hy vọng nó sẽ giúp ích phần nào. Ngoài ra khi làm cũng cần phải tham khảo các project tương tự trước đây, task list hay những con số rất có giá trị, đặc biệt là Productivity. Và cuối cùng, hãy cùng thảo luận cởi mở với khách nếu bạn là người trực tiếp thương thảo, còn nếu không hãy đưa ra các bằng chứng chứng minh cho các con số – các item để người chịu trách nhiệm hiểu cặn kẽ, tránh bị khách bắt bẻ. Còn đối với khách nào mà miệng lưỡi o ép kiểu “cái này dễ mà” – “có nhiêu đây làm gì mất nhiều thời gian vậy” – “tôi thấy mấy chỗ khác làm rẻ lắm” … thì để họ tự làm luôn đi. Giỡn chứ lựa lời mà nói cho họ hiểu. Hẹn gặp các bạn ở phần tiếp, mình sẽ nói sơ sơ về Proposal (提案書).