❖ Trong nhiều trường hợp Developer sẽ là người nhận ủy thác công việc và được yêu cầu phải đưa ra Estimate (ở công ty mình thì dev leader sẽ là người thực hiện EST). 
❖ Khi thực hiện Estimate hẳn các bạn đã quá quen với cụm từ Man-month, Man-day rồi (với đứa comtor với vào nghề như tuôi thì tuôi chả biết nó là cái gì sấc - à mà giờ tuôi cũng hiểu được đại khái rồi nha). 
❖ Tiện đây mình sẽ share về cách phân bổ Estimate của các developer trong cách viết Estimate document để giao cho khách hàng. 

 

①Ngày công của Developer và đơn vị Man-month:

- Thuật ngữ ngày công hay còn gọi là công số bên mình sẽ dùng từ Effort/工数. 
- Trong tài liệu Estimate cần tính toán số nhân công để đưa ra Budget/dự toán cần thiết. Nhân công nghĩa là số lượng công việc tính trên 1 người, được tính bằng đơn vị Man-month hoặc Man-day. 
- Formula/Công thức: Man-day X chi phí ngày công. 
- Đối với các dự án Outsource, chi phí được trả theo giờ (Billable Hour). Tức là thù lao/Wage sẽ được trả ứng với số giờ lao động, chứ không phải ứng với sản phẩm hoàn thành. 
- Có rất nhiều cách tính toán Man-month, Man-day. Giá 1 Man-month sẽ phụ thuộc vào kinh nghiệm cũng như kỹ thuật. Chi phí Man-month ở các nước như Mỹ, Tây Ây sẽ khá cao, nhưng ở Châu Á thì thấp hơn. Ở Nhật Bản, 1 Man-month sẽ tầm 50 man yên (96 triệu VNĐ) đến 150 man yên (288 triệu VNĐ) 

 

②Tính toán số tiền dự toán/Budget/予算:

- Khi đưa ra số tiền dự toán, trước tiên cần tìm số nhân công từ quy mô của dự án. 
Budget = số nhân công X giá của man-month/man-day
- Tuy nhiên, sẽ có trường hợp cần cộng thêm các chi phí khác như nhân công quản lý (cost for PM), chi phí làm document, chi phí cho communicator,....  rồi mới ra được Budget. 

 

③Hợp đồng khoán sản phẩm/請負契約  

- Có nhiều trường hợp developer sẽ nhận dự án với cách tính toán nhân công như phía trên, nhưng cũng có trường hợp làm theo hợp đồng khoán/thầu sản phẩm, phía khách hàng sẽ quyết định giá của sản phẩm. 
Ví dụ:  Khách đưa ra budget khoảng 500 man yên và bảo mày làm cho tao 1 cái Web chạy batch tính toán doanh thu theo ngày, theo tháng và theo năm... thì trường hợp này khách sẽ quyết định số nhân công dự tính. 
⇒Trong trường hợp dự án làm theo dạng hợp đồng khoán sản phẩm thì bên team phát triển cũng cần estimate/confirm lại để xem có phát sinh sự chênh lệch, sai khác/差異 giữa budget team dự đoán và số tiền khách đưa ra. (cái này mà ko xem xét/検討 kỹ thì có mà lỗ sấp mặt) 

 

④Pre-condition/Điều kiện tiền đề của việc Estimate

- Khi thực hiện est không chỉ viết dự toán mà còn cân nhắc cả quyết định về điều kiện tiền đề để tránh những phiền toái, vấn đề về sau. Quyết định điều kiện tiền đề được thống nhất giữa khách và team develop. 

 

⑤Phạm vi Estimate và ngoài phạm vi estimate

- Cần tạo một check-list liệt kê những phần Function và cả Non-function mà team sẽ đối ứng. Nếu khách yêu cầu làm thêm những chức năng hoặc khách yêu cầu thay đổi/chỉnh sửa mà khác biệt nhiều so với nội dung yêu cầu ban đầu thì sẽ tính đó là ngoài phạm vi estimate và charge fee (nếu cần). 

 

⑥Kỳ hạn của dự án

- Thông thường nếu thời gian hoàn thành và giao nộp sản phẩm ngắn thì số tiền dự án cao, còn nếu thời gian dài thì có thể thương lượng để giảm giá xuống. 

 

⑦Phân bổ tỉ lệ chi phí dự toán phần mềm

- Ví dụ bảng phân bổ tỉ lệ chi phí dự toán ở công ty mình: 

  • Requirement specification 10%
  • Design 15% 
  • Programming 30%
  • Communicator 5%
  • Testing 35% 
  • Deployment 5% 
  • Total 100% 

- Tùy thuộc vào đặc điểm dự án và các điều kiện tiền đề mà tỉ lệ có thể khác nhau. Ví dụ dự án mình đang phụ trách thì phần Requirement specification  và Design là bên khách làm nên chỉ có rate là 0 nhưng bù lại rate bên Comtor sẽ rất là cao. 
- Dự án theo kiểu upgrage thì Deploy cũng có rate = 0% 
Nên tùy mỗi dự án khác nhau sẽ có rate khác nhau chứ không có cai nào là tiêu chuẩn cả. 

 

⑧ Cách viết estimate document

Cách viết estimate document có thể chia làm 2 loại lớn.

Cách viết nêu các mục theo công đoạn

Estimate document sẽ được chia thành các mục theo từng công đoạn. Viết số nhân công cho từng công đoạn rồi nhân với giá tiền là đã có thể tạo thành estimate document. Những mục như dưới đây thường được sử dụng trong nhiều trường hợp.

  1. Chi phí thiết kế hệ thống
  2. Chi phí cho data base
  3. Chi phí cho internal program
  4. Chi phí cho việc kiểm tra lỗi hệ thống Vì việc này không tốn quá nhiều công sức nên giá tiền thường được định ở mức thấp.
  5. Chi phí cho việc họp bàn, thảo luận

     Dưới đây là ví dụ: 

Cách viết khi hệ thống sử dụng phương thức khoán

Trong trường hợp các công đoạn chi tiết được viết ở 1 văn bản khác thì estimate document có thể viết bằng cách coi chi phí dự toán là chi phí thiết lập hệ thống và được khoán trả 1 lần.

Dưới đây là ví dụ

⑧Kết luận/Summary

- Man và Month (con người và thời gian) không để hoán đổi, cẩm thận trong việc dùng Man-moth khi làm độ đo để ước tính và lập kế hoạch
- Với kinh nghiệm non chẻ trong role Comtor thì những nội dung trên suy cho cùng chỉ là chia dưới dạng lý thuyết suông mn đọc cho biết nhé (chỉ với mục đích là để cho mình hiểu thôi và đỡ trúc trắc trong quá trình dịch tài liệu)