Ước Lượng & Báo Giá Dự Án Phần Mềm – Quy Trình & Thực Hành

Chương 2 · Bài 1

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học mở đầu Chương 2 bằng cách phân biệt hai môi trường làm phần mềm: gia công (outsourcing) và sản phẩm (product). Điểm mấu chốt: bạn phải biết mình đang ở môi trường nào, vì cách đối ứng, cách làm estimation và cách báo giá dự án đều đi theo đặc thù của môi trường đó. Nhầm môi trường là nhầm luôn cách tính tiền và cách quản lý rủi ro.

─── SAU BÀI HỌC, BẠN SẼ

• Phân biệt được đặc điểm cốt lõi của môi trường gia công và môi trường sản phẩm.
• Hiểu vì sao gia công có hợp đồng giới hạn và cần gia hạn theo năm.
• Biết môi trường nào ảnh hưởng thế nào tới lợi nhuận, rủi ro và cách bạn báo giá.

─── NỘI DUNG CHÍNH

▸ 1. Gia công (outsourcing) khác gì sản phẩm (product)

• Gia công: phát triển theo yêu cầu khách hàng, thu nhập chủ yếu đến từ hợp đồng, phụ thuộc vào từng dự án, tối ưu về quy trình.
• Sản phẩm: hướng đến người dùng cuối (end user), tiềm năng lợi nhuận rất cao nhưng đi kèm rủi ro thị trường lớn — đầu tư sản phẩm mà không đạt mục tiêu thị trường thì coi như "rớt". Sản phẩm đòi hỏi tối ưu về kinh doanh và chiến lược.

▸ 2. Tính giới hạn và mô hình dự án

Dự án gia công thường có giới hạn thời gian, ví dụ 3–6 tháng, dài hơn nếu có bảo trì; thông thường mỗi năm phải gia hạn hợp đồng một lần, và bước tiếp theo (next step) tùy tình hình hiện tại. Về mô hình: gia công rất đa dạng (theo project base), còn sản phẩm gần như chỉ một hướng (theo product base) — một bên theo dự án, một bên theo sản phẩm.

▸ 3. Sáng tạo và rủi ro trong gia công

Nhiều người nghĩ gia công không có chỗ cho sáng tạo, nhưng thực tế bạn vẫn sáng tạo ở cách giải quyết vấn đề và quy trình: khách đưa phương án A, B, C chưa tốt, bạn có thể đề xuất phương án D mà vẫn đạt đúng mục tiêu của họ. Về rủi ro, công ty gia công thường ít có sản phẩm riêng; có nơi nhận mọi việc, có nơi chuyên sâu một mảng như mobile, web hay application. Nắm được bức tranh tổng quan này là nền để đi vào từng mô hình cụ thể ở các bài sau.

Chương 2 · Bài 2

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học lý giải vì sao ngành gia công phần mềm (outsourcing) tồn tại và phát triển, đặc biệt ở thị trường Việt Nam. Điểm mấu chốt: khách hàng tìm đến gia công không chỉ vì chi phí, mà còn vì nguồn lực đa dạng, giảm rủi ro và để họ được rảnh tay tập trung vào core business của mình.

─── SAU BÀI HỌC, BẠN SẼ

• Nắm được các lý do khiến khách hàng chọn thuê ngoài thay vì tự xây đội.
• Hiểu lợi thế nhân lực của Việt Nam và áp lực cạnh tranh hiện nay.
• Nhìn ra 5 điểm nổi bật của mô hình gia công dưới góc nhìn của người trong nghề.

─── NỘI DUNG CHÍNH

▸ 1. Vì sao ngành gia công tồn tại

Ở các thị trường như Nhật, chi phí nhân công cao hơn Việt Nam, trong khi Việt Nam đào tạo nhân lực phần mềm rất nhiều, đáp ứng được nhiều giải pháp với hiệu quả kinh tế tốt. Tuy nhiên đó là lợi thế của trước đây; hiện nay Trung Quốc, Ấn Độ và nhiều nơi khác đã cạnh tranh mạnh, cộng thêm AI hỗ trợ ngày càng nhiều, nên ngành cũng khó khăn hơn chứ không còn dễ như trước.

▸ 2. Năm điểm nổi bật khiến khách hàng chọn gia công

1. Tiết kiệm chi phí nhân lực: tự tuyển lập trình viên Java, .NET, thiết kế… vừa tốn kém vừa khó quản lý; đi gia công thì chỉ cần ý tưởng và một khoản tiền.
2. Nguồn lực đa dạng, dồi dào: công ty gia công gom sẵn nhiều vị trí chuyên môn.
3. Chuyên sâu và nhanh: đơn vị gia công đã có kinh nghiệm triển khai, biết cách làm ngay.
4. Giảm rủi ro: công ty outsource lo phần bảo mật thông tin (ký hợp đồng bảo mật, không share ra ngoài), giảm rủi ro kỹ thuật và bị đánh cắp ý tưởng.
5. Khách hàng tập trung core business: họ chỉ nêu nhu cầu, phần phân tích và kỹ thuật để bên gia công tự xử lý.

▸ 3. Xu hướng AI

Giảng viên nhấn mạnh ngành gia công đã bắt đầu chịu ảnh hưởng của AI, và sẽ có nội dung riêng bàn sâu về AI ở phần sau. Trước mắt, hiểu đúng 5 điểm nổi bật trên giúp bạn biết mình đang tạo ra giá trị gì cho khách hàng.

Chương 2 · Bài 3

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học giới thiệu mô hình triển khai dự án phổ biến nhất: end user giao dự án cho một công ty IT đối tác (thường cùng ở thị trường Nhật), rồi công ty đó thuê lại công ty gia công phần mềm ở Việt Nam. Điểm mấu chốt: ở mô hình này bạn chỉ làm việc với công ty đối tác, không tiếp xúc trực tiếp với end user.

─── SAU BÀI HỌC, BẠN SẼ

• Vẽ được luồng: end user A → công ty IT đối tác A → công ty gia công (Việt Nam).
• Hiểu vì sao thiếu communication trực tiếp vừa là nhược điểm vừa có thể là lợi thế.
• Nhận ra mức độ an toàn của mô hình này so với việc làm thẳng với end user.

─── NỘI DUNG CHÍNH

▸ 1. Cách vận hành của mô hình

Người khách hàng có ý tưởng và có tiền (end user A) thuê một công ty IT đối tác A, thường cùng ở Nhật. Công ty IT đó không đủ nhân lực (resource) để tự làm nên giao lại cho công ty gia công phần mềm ở Việt Nam. Công ty gia công chỉ làm việc với công ty đối tác A, và thường không biết đến end user A.

▸ 2. Nhược điểm: không communication trực tiếp

Ý tưởng đi qua nhiều tầng chuyển giao nên dễ bị hiểu sai; bạn không giao tiếp trực tiếp với end user mà phải thông qua công ty đối tác. Đây là điểm bất lợi rõ nhất của mô hình.

▸ 3. Nhược điểm đó cũng có thể thành lợi thế

Giữa rào cản tiếng Nhật và tiếng Việt, việc lấy requirement cho chính xác là rất khó với bên gia công. Nhưng công ty đối tác lại ở ngay trong thị trường Nhật, hiểu khách hơn, nên họ chốt requirement chuẩn hơn. Nhờ vậy độ chắc chắn và khả năng thành công của dự án thường đỡ hơn so với khi bạn tự làm trực tiếp với end user. Các mô hình khác sẽ được so sánh tiếp ở những bài sau.

Chương 2 · Bài 4

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học giới thiệu mô hình thứ hai: công ty gia công phần mềm hợp tác cùng một công ty IT đối tác và được làm việc trực tiếp với end user. Điểm mấu chốt: khác với mô hình trước, ở đây bạn tiếp xúc thẳng với khách hàng cuối để lấy requirement, còn phần tiền bạc vẫn do công ty đối tác nắm.

─── SAU BÀI HỌC, BẠN SẼ

• Phân biệt được mô hình "cùng làm" với mô hình chỉ đi qua công ty đối tác.
• Hiểu vì sao communication trực tiếp giúp lấy requirement tốt hơn.
• Biết vị trí của mình khi được giới thiệu là offshore của công ty đối tác.

─── NỘI DUNG CHÍNH

▸ 1. Cách vận hành của mô hình

End user B (công ty có ý tưởng và tiền) order sản phẩm cho công ty IT đối tác B. Công ty B làm contract ràng buộc với công ty gia công phần mềm ở Việt Nam. Điểm khác biệt: công ty gia công được triển khai trực tiếp với end user B, đi hỏi và lấy review mọi thứ. Tuy nhiên, phần tiền bạc và nghiệm thu sản phẩm vẫn có sự tham gia của công ty B — bạn thường không biết giá thành giữa end user B và công ty B, cũng như phần chia cho mình là bao nhiêu.

▸ 2. Vị trí offshore

Trong thực tế, công ty đối tác B thường giới thiệu công ty gia công của bạn với end user như là offshore của họ — tức đơn vị chuyên gia công cho các dự án của công ty B.

▸ 3. Ưu điểm so với mô hình đi qua đối tác

Lợi thế lớn nhất là communication trực tiếp: giao tiếp giữa bạn và end user rõ ràng hơn, nhờ đó việc lấy requirement cũng chính xác và thuận lợi hơn nhiều so với mô hình chỉ làm việc gián tiếp qua công ty đối tác. Đây là mô hình "cùng thực hiện", và ở các bài sau giảng viên sẽ so sánh rõ hơn với những mô hình còn lại.

Chương 2 · Bài 5

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học giới thiệu mô hình dự án có nguồn gốc từ chính phủ (government project): chính phủ ra đề án kèm ngân sách, một công ty IT nhận đề án rồi chia việc cho nhiều công ty gia công phần mềm. Điểm mấu chốt: đây là mô hình ít gặp, các bên tham gia thường không nhìn thấy chi tiết đề án gốc lẫn dòng tiền từ chính phủ.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu luồng đi từ đề án chính phủ đến các công ty gia công phần mềm.
• Nhận ra vì sao thông tin và tiền bạc ở mô hình này thường không minh bạch với bên làm.
• Biết mô hình này ít gặp và đòi hỏi công ty đầu mối làm nhiều thứ để trúng đề án.

─── NỘI DUNG CHÍNH

▸ 1. Cách vận hành của mô hình

Chính phủ ra một đề án kèm số tiền nhất định. Công ty IT C nhận đề án và có ngân sách từ chính phủ, sau đó biến nó thành dự án và kêu các công ty gia công phần mềm (C1, C2, C3, C4…) cùng làm, có thể qua đấu thầu. Các công ty này hợp tác với nhau nhưng thường không biết chi tiết đề án gốc, cũng không biết dòng tiền giữa chính phủ và công ty C.

▸ 2. Cách chia giai đoạn và một biến thể ngược

Công ty C nhận một khoản tiền từ chính phủ, rồi triển khai theo giai đoạn 1, giai đoạn 2, xong giai đoạn nào thì chuyển giao giai đoạn đó. Với các công ty làm bên dưới, họ thường coi đây là sản phẩm của công ty C chứ không biết là của chính phủ. Có biến thể ngược lại: công ty chưa có đề án sẽ tự dựng đề án, đi đấu thầu, mượn các bên khác làm rồi lấy kết quả đó đi nộp.

▸ 3. Đặc điểm cần lưu ý

Đây là mô hình ít gặp vì không phải lúc nào cũng có dự án từ chính phủ, và công ty đầu mối phải làm rất nhiều việc mới lấy được đề án. Khi tham gia, bạn có thể hợp tác với các công ty gia công khác hoặc làm trực tiếp với công ty C.

Chương 2 · Bài 6

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học giới thiệu mô hình cuối: công ty gia công phần mềm làm trực tiếp với end user — người có ý tưởng và tiền, cần làm sản phẩm. Điểm mấu chốt: mô hình này cho lợi nhuận cao nhưng cũng rủi ro cao, vì rào cản ngôn ngữ và communication dễ khiến sản phẩm làm ra không đúng ý khách.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu ưu điểm về lợi nhuận và tiếp xúc trực tiếp của mô hình này.
• Nhận ra rủi ro communication khi end user khác ngôn ngữ (ví dụ người Nhật).
• Biết vì sao thiếu chuyên môn domain khiến việc lấy requirement kém chính xác.

─── NỘI DUNG CHÍNH

▸ 1. Cách vận hành và ưu điểm

End user D có tiền và ý tưởng, tự tìm đến công ty gia công phần mềm để thực hiện. Vì tiếp xúc trực tiếp, việc lấy requirement và hiểu khách hàng dễ hơn, đồng thời lợi nhuận cũng khá cao do không qua trung gian.

▸ 2. Rủi ro communication khi khác ngôn ngữ

Vấn đề lớn nhất xuất hiện khi end user khác ngôn ngữ với đội thực hiện — ví dụ khách là người Nhật. Khi đó khả năng hiểu sai ý tưởng rất cao, dẫn tới xác suất làm không đúng ý cũng cao. Đây là điểm yếu cốt lõi của mô hình trực tiếp.

▸ 3. Vì sao thiếu domain thì lấy requirement khó

Công ty gia công nếu không chuyên sâu vào một domain thì lấy requirement rất khó và không rõ. Dù cố gắng cách nào, bạn cũng khó lấy chuẩn bằng một công ty bản địa (như công ty Nhật) làm trực tiếp với end user. Vì vậy, dù lợi nhuận hấp dẫn, giảng viên đánh giá đây là mô hình khá rủi ro trong số các mô hình đã trình bày.

Chương 2 · Bài 7

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học đặt bốn mô hình đã học lên bàn cân, so sánh ưu và nhược điểm của từng mô hình. Điểm mấu chốt: không có mô hình nào tốt tuyệt đối — bạn phải xác định rõ mình đang ở mô hình nào và cả quy mô dự án để triển khai cho hợp lý, phát huy ưu điểm và khắc phục nhược điểm.

─── SAU BÀI HỌC, BẠN SẼ

• So sánh được ưu/nhược của bốn mô hình triển khai dự án.
• Biết chọn cách triển khai theo quy mô dự án (nhỏ làm trực tiếp, lớn chia nhiều đơn vị).
• Hiểu vì sao giảng viên đánh giá mô hình 1 và 2 là an toàn nhất.

─── NỘI DUNG CHÍNH

▸ 1. Qua công ty IT đối tác

Dễ tiếp cận hợp đồng tương đối lớn và là hướng an toàn nhất: ít rủi ro pháp lý vì hợp đồng do công ty đối tác đảm nhiệm; nếu tính tiền theo tháng thì rất ổn định. Nhược điểm: phụ thuộc vào công ty đối tác (không rõ yêu cầu, bị ép theo timeline/deadline) và biên lợi nhuận thấp hơn do phải chia phần trăm.

▸ 2. Cùng làm với công ty đối tác

Ưu điểm: hai bên cùng làm nên học hỏi kinh nghiệm và tận dụng chuyên môn riêng (ví dụ bên kia lo lấy requirement, mình lo làm). Nhược điểm: bên làm ít nhưng ăn nhiều là chuyện thường; và nếu không phân rõ vị trí, vai trò thì hai bên đùn đẩy nhau, tốn thời gian.

▸ 3. Dự án từ chính phủ và mô hình trực tiếp

• Dự án chính phủ (government project): tiền khá ổn và nhiều (thường cấp trước hoặc theo từng release), làm được thì uy tín cao, yêu cầu ràng buộc rõ ràng. Nhược điểm: tính bảo mật cao và thanh toán có thể chậm hơn tư nhân.
• Triển khai trực tiếp: ưu là giao tiếp tốt, chủ động về tiền và lợi nhuận cao hơn. Nhược: không có công ty đứng giữa để chặn khách khi họ thay đổi yêu cầu quá nhiều, và công ty bạn phải tự chịu trách nhiệm hoàn toàn về chất lượng lẫn tiến độ — khá rủi ro.

▸ Lưu ý khi chọn mô hình

Theo quan điểm giảng viên, đẹp nhất là mô hình 1 và 2. Dự án chính phủ mà được triển khai cùng đối tác thì cũng quy về mô hình 2. Mô hình trực tiếp tuy tiền nhiều nhưng rất khó, nên cân nhắc kỹ trước khi nhận.

Chương 2 · Bài 8

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài tổng kết Chương 2, hệ thống lại bốn mô hình triển khai dự án và chia sẻ kinh nghiệm thực chiến của giảng viên. Điểm mấu chốt: dù ở mô hình nào, bài toán khó nhất vẫn là hiểu khách hàng cần gì; và luôn phải chuẩn bị tinh thần cho việc khách hàng thay đổi yêu cầu (change).

─── SAU BÀI HỌC, BẠN SẼ

• Nhắc lại được bốn mô hình và mô hình nào nên ưu tiên áp dụng.
• Hiểu vì sao trong thời đại AI, "hiểu khách hàng" trở thành yếu tố quyết định.
• Biết cần một đội BA mạnh và một khoản buffer khi ước lượng dự án.

─── NỘI DUNG CHÍNH

▸ 1. Nhìn lại bốn mô hình

1. Triển khai thông qua công ty IT đối tác.
2. Triển khai cùng công ty IT đối tác (biết end user, hợp tác với đối tác).
3. Dự án của công ty có dự án từ chính phủ.
4. Triển khai trực tiếp với người cần làm sản phẩm.

Giảng viên khuyến khích ưu tiên mô hình 1 và 2; mô hình 3 nếu làm theo hướng "cùng triển khai" thì cũng khá ổn.

▸ 2. Hiểu khách hàng là bài toán cốt lõi

Với khách nước ngoài, việc hiểu rõ họ rất khó nên thường cần công ty trung gian. Trong thời đại có AI hỗ trợ lập trình, gánh nặng kỹ thuật đã nhẹ đi, nên mọi thứ quay về câu hỏi: khách cần gì. Nếu làm trực tiếp với end user (mô hình 4), bạn cần một đội BA rất mạnh để nắm nghiệp vụ; khi requirement đã rõ, dùng AI hỗ trợ development sẽ tiết kiệm cả chi phí lẫn thời gian.

▸ 3. Kinh nghiệm về hợp đồng và quản lý thay đổi

Một công ty IT đối tác "chống lưng" về hợp đồng và chuyện tiền bạc với khách sẽ hỗ trợ bạn rất nhiều — đừng nghĩ làm trực tiếp là ngon, thực tế nó khó khăn hơn mô hình 1, 2 rất nhiều. Giảng viên chuộng nhất mô hình 2: cùng làm với công ty IT, gặp và hiểu end user, đồng thời giữ nguyên tắc chỉ trao đổi công việc với khách còn tiền bạc để công ty đối tác lo.

▸ Lưu ý quan trọng: luôn dự phòng cho thay đổi

Hầu hết sản phẩm của khách đều phát sinh thay đổi (change), không nhiều thì ít. Người quản lý phải chấp nhận và quản lý được điều đó; khi ước lượng và báo giá, hãy cộng thêm một khoản buffer để dự phòng cho những thay đổi chắc chắn sẽ xảy ra.

Chương 3 · Bài 1

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học mở đầu chương về các loại hợp đồng trong ngành gia công phần mềm, bắt đầu với loại phổ biến nhất: hợp đồng labor, hay còn gọi là OSDC (Offshore Software Development Center). Điểm mấu chốt: đây là mô hình thuê đội phát triển dài hạn (thường 3-6 tháng, tối đa quanh một năm) và thanh toán theo tháng, nên mang lại nguồn tiền ổn định cho công ty gia công.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu bản chất hợp đồng labor/OSDC và vì sao nó được ưa chuộng.
• Biết các thành phần cốt lõi cần có trong một hợp đồng OSDC.
• Phân biệt hợp đồng chính (thỏa thuận nguyên tắc) và phụ lục ghi đơn giá.

─── NỘI DUNG CHÍNH

▸ 1. Hợp đồng labor/OSDC là gì

Đây là mô hình thuê một đội phát triển phần mềm dài hạn tại công ty gia công ở nước ngoài, thay vì thuê theo từng dự án riêng lẻ. Thời hạn thường 3-6 tháng, có khi cả năm nhưng ít khi kéo dài nhiều năm. Thường khách hàng đã có sẵn sản phẩm và cần người bảo trì, nhưng cũng có thể là sản phẩm mới hoặc dự án R&D (Research and Development) vẫn ký theo dạng này.

▸ 2. Vì sao loại hợp đồng này phổ biến

Hợp đồng chú trọng lý lịch từng người phát triển (skill, kinh nghiệm) mà bạn cung cấp cho khách hàng. Tính thanh khoản cao vì thanh toán theo tháng, giúp công ty gia công - đặc biệt các công ty startup - duy trì nguồn tiền ổn định.

▸ 3. Các thành phần trong hợp đồng

Một mẫu hợp đồng OSDC gồm: bên A - bên B; mô tả những gì bên B cung cấp; vị trí và số lượng nhân sự (có hợp đồng chỉ ghi số người, có hợp đồng ghi rõ tên, kinh nghiệm từng người). Phần quy định chủ yếu xoay quanh giờ làm việc: số giờ mỗi ngày, khung giờ, cách tính làm thêm giờ, ngày nghỉ lễ, thời hạn hợp đồng.

▸ 4. Mẹo quan trọng: tách hợp đồng chính và phụ lục đơn giá

Trong thực tế, đơn giá thường không nằm trong hợp đồng chính. Bạn ký một hợp đồng chính (thỏa thuận nguyên tắc làm việc giữa hai bên), rồi từ đó lập phụ lục ghi đơn giá từng vị trí và tổng giá trị hợp đồng. Ngoài ra hợp đồng còn kèm điều khoản bản quyền, bảo mật thông tin và giải quyết tranh chấp.

Chương 3 · Bài 2

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học giới thiệu loại hợp đồng thứ hai: fixed price - hợp đồng giá cố định, thanh toán theo dự án chứ không theo tháng. Điểm mấu chốt: fixed price giúp công ty gia công phát triển nhanh nhưng tiềm ẩn rủi ro lớn, vì trong thực tế phạm vi công việc thường không rõ ràng ngay từ đầu như lý thuyết.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu cơ chế thanh toán theo mốc của hợp đồng fixed price.
• Phân biệt fixed price với hợp đồng labor/OSDC (theo dự án vs. theo tháng).
• Nhận ra vì sao fixed price rủi ro và cần cân nhắc tỷ lệ trong công ty.

─── NỘI DUNG CHÍNH

▸ 1. Fixed price là gì và khác OSDC ra sao

Fixed price có giá cố định, phù hợp dự án có phạm vi rõ ràng ngay từ đầu. Khác với OSDC (trả theo tháng), fixed price trả theo dự án và thường chia mốc: khoảng 30% khi ký hợp đồng, 50% khi hoàn thành bàn giao sản phẩm, phần còn lại cho giai đoạn hỗ trợ.

▸ 2. Vì sao fixed price rủi ro

Mô hình này giúp công ty gia công phát triển nhanh, nhưng độ rủi ro khá bất ổn. Thực tế nhiều dự án fixed price chưa có phạm vi rõ ràng ngay từ đầu - nhiều khi chỉ là ý tưởng sơ khai. Khách hàng thường có một budget cố định (ví dụ 500 triệu), thả ra cho nhiều công ty đấu thầu, công ty nào thấy ổn thì họ order, chứ bản chất không cố định phạm vi.

▸ 3. Lưu ý khi nhận nhiều hợp đồng fixed price

Trong công ty gia công, loại này thường nên chiếm tỷ lệ ít hơn. Nếu ôm quá nhiều hợp đồng fixed price thì nguồn tiền dễ bất ổn, vì không phải cứ bàn giao là nhận ngay 50% - còn phải test, kiểm tra, và quá trình confirm qua lại với khách rất mất thời gian.

▸ 4. Các thành phần trong mẫu hợp đồng

Mẫu hợp đồng fixed price gồm: bên A - bên B, mô tả dự án và phạm vi công việc, lịch trình thanh toán theo mốc kèm điều kiện của từng mốc, thời gian bảo hành, thời gian phản hồi, điều khoản chấm dứt hợp đồng và giải quyết tranh chấp.

Chương 3 · Bài 3

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học giới thiệu loại hợp đồng body shopping - cho thuê người trực tiếp. Điểm mấu chốt: với mô hình này, công ty gia công chỉ cung cấp nhân sự để làm việc tại site khách hàng và chịu sự quản lý của khách hàng, chứ không chịu trách nhiệm về sản phẩm. Giảng viên cũng chỉ ra vì sao mô hình này ít bền với một công ty gia công thực thụ.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu bản chất hợp đồng body shopping và vai trò của công ty cung cấp.
• Phân biệt công ty cho thuê người với công ty gia công có build-up đội ngũ.
• Nắm các thành phần chính của một mẫu hợp đồng body shopping.

─── NỘI DUNG CHÍNH

▸ 1. Body shopping là gì

Đây là mô hình cho thuê nhân sự trực tiếp: nhân sự làm việc tại site của khách hàng, tương tác trực tiếp và chịu sự quản lý của khách hàng. Công ty gia công chỉ cung cấp người, không chịu trách nhiệm về sản phẩm hay việc quản lý nhân sự đó.

▸ 2. Vì sao mô hình này ít bền

Các công ty gia công phần mềm ít dùng loại này. Những đơn vị dùng nhiều thường là công ty chuyên cho thuê người: chỉ săn nguồn nhân sự rồi đem cho thuê chỗ khác, kiếm lời trên đầu người. Kiểu này không build-up nhân viên, không định hướng, không quản lý con người - nên theo giảng viên là không bền vững.

▸ 3. Các thành phần trong mẫu hợp đồng

Mẫu hợp đồng body shopping gồm: bên thuê - bên cung cấp; nội dung và trách nhiệm của mỗi bên; dịch vụ và phương thức thanh toán; thời hạn hợp đồng, chấm dứt hợp đồng, xử lý vi phạm, giải quyết tranh chấp. Kèm theo là phụ lục ghi rõ vị trí, mô tả, số lượng, yêu cầu, kỹ năng và kinh nghiệm của nhân sự được cung cấp.

Chương 3 · Bài 4

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học giới thiệu NDA (Non-Disclosure Agreement) - thỏa thuận bảo mật thông tin giữa các bên khi tham gia dự án gia công phần mềm. Điểm mấu chốt: NDA gần như luôn là hợp đồng ký đầu tiên, trước khi khách hàng bàn giao tài liệu hay source code, và mức phạt khi vi phạm không có giới hạn cận trên.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu NDA là gì và vai trò của nó trong dự án offshore.
• Biết vì sao NDA phải được ký trước khi nhận tài liệu, source code.
• Nắm cách tính mức phạt vi phạm và các điều khoản chính của NDA.

─── NỘI DUNG CHÍNH

▸ 1. NDA là gì và ký khi nào

NDA là thỏa thuận bảo mật giữa hai hoặc nhiều bên, đảm bảo thông tin quan trọng không bị tiết lộ cho bên thứ ba. Ví dụ một công ty Nhật tìm đối tác gia công ở Việt Nam: trước khi bàn giao thiết kế, phần việc dở dang hay thông tin dự án, hai bên phải ký NDA trước tiên. Đây là bước tạo sự tin tưởng và là điều kiện để nhận được dự án.

▸ 2. Lưu ý: mức phạt không có cận trên

Điểm cần đặc biệt ghi nhớ: vi phạm bảo mật thông tin bị phạt không giới hạn cận trên. Người ta tính tiền phạt trên mỗi record trong database, mỗi record ứng với một user. Ví dụ với phần mềm tài chính, nếu để lộ/mất thông tin khách hàng thì số record nhân với giá trị tiền phạt có thể rất lớn - nên đây là rủi ro phải cực kỳ nghiêm túc.

▸ 3. Các thành phần trong mẫu NDA

Một mẫu NDA gồm: định nghĩa thông tin bảo mật, bên nhận - bên cấp, thời gian hiệu lực, hậu quả khi vi phạm, phạm vi áp dụng và các điều khoản. Mẫu trong bài chỉ là sample viết gọn; thực tế hợp đồng có thể rất dài. Một số hợp đồng ghi đơn giản dạng cam kết: nếu bên gia công (bên B) vi phạm bảo mật thì phải bồi thường toàn bộ.

Chương 3 · Bài 5

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học phân tích ưu điểm và nhược điểm của ba loại hợp đồng đã học: labor/OSDC, fixed price và body shopping. Điểm mấu chốt: chọn đúng loại hợp đồng ảnh hưởng trực tiếp tới việc kiểm soát chi phí, chất lượng và tiến độ - nên PM cần nắm rõ điểm mạnh/yếu của từng loại để tư vấn cho khách theo từng dự án cụ thể.

─── SAU BÀI HỌC, BẠN SẼ

• So sánh được ưu - nhược điểm của labor, fixed price và body shopping.
• Biết chọn loại hợp đồng phù hợp để tư vấn cho khách theo từng dự án.
• Nhận diện các rủi ro tiềm ẩn của mỗi loại (quản lý offshore, ước lượng sai, chi phí thuê cao).

─── NỘI DUNG CHÍNH

▸ 1. Hợp đồng labor/OSDC

Ưu điểm: khả năng kiểm soát cao, khách hàng quản lý trực tiếp đội ngũ; chi phí dài hạn ổn định, tiết kiệm với dự án dài; đội ngũ gắn bó và hiểu sâu sản phẩm; dễ mở rộng hoặc thu hẹp nhân sự. Nhược điểm: cần người quản lý tại công ty gia công nên vận hành phức tạp; chi phí đào tạo và dựng cơ sở hạ tầng cao (có dự án khó phải mất từ một tới bảy tháng mới nắm được logic); chất lượng phụ thuộc vào năng lực offshore mà khách khó control.

▸ 2. Hợp đồng fixed price

Ưu điểm: chi phí cố định nên dễ dự trù, dễ hoạch toán ngân sách. Nhược điểm: yêu cầu thay đổi nhiều thì phải deal lại, nếu không sẽ lỗ. Loại này có hai góc nhìn - công ty gia công thích vì ổn định và dễ có tiền, nhưng lại ít rủi ro cho khách và dồn trách nhiệm lớn cho bên gia công, phụ thuộc vào scope. Rủi ro lớn nhất là ước lượng theo cả dự án dễ thiếu chính xác, cộng thêm việc phải đọc nhiều tài liệu và báo giá gấp - dẫn đến lỗ.

▸ 3. Hợp đồng body shopping

Ưu điểm: rất linh hoạt, điều chỉnh theo nhu cầu; khách hàng toàn quyền quản lý nguồn nhân lực nên bên cung cấp nhẹ việc. Nhược điểm: nhân sự dễ nghỉ việc, ít cam kết gắn bó lâu dài; phí thuê cao (một người giá 10 đồng qua công ty body shopping bị đội lên 12 đồng). Ngoài ra còn rủi ro nhân sự làm trực tiếp bên khách, biết được chênh lệch giá và mất gắn kết với công ty.

Chương 3 · Bài 6

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học tổng kết chương 3 về các loại hợp đồng (labor/OSDC, fixed price, body shopping, NDA) và chia sẻ kinh nghiệm thực chiến của giảng viên. Điểm mấu chốt: việc chọn loại hợp đồng phụ thuộc rất nhiều vào ngân sách và mục tiêu của khách hàng, và mỗi loại có một "bài học thực tế" mà lý thuyết không nói hết.

─── SAU BÀI HỌC, BẠN SẼ

• Hệ thống lại bốn loại hợp đồng đã học trong chương.
• Hiểu vì sao ngân sách khách hàng chi phối việc chọn loại hợp đồng.
• Rút ra kinh nghiệm thực tế về giới hạn của fixed price và body shopping.

─── NỘI DUNG CHÍNH

▸ 1. Chọn hợp đồng theo tiền của khách hàng

Thực tế, loại hợp đồng phụ thuộc rất nhiều vào tiền của khách. Khi khách đã có sản phẩm với nguồn thu lớn và một quỹ nhất định, muốn đảm bảo quỹ đó ra được sản phẩm, họ thường chọn fixed price (loại số 2).

▸ 2. Kinh nghiệm với fixed price

Theo giảng viên, sản phẩm làm theo fixed price ít khi hoàn thiện trọn vẹn. Tiền thì cố định nhưng ý tưởng của khách thường rất nhiều tính năng, nên sau một giai đoạn output, sản phẩm chạy được nhưng chưa hoàn thiện - thường phải nối tiếp bằng hợp đồng labor để làm mềm và hoàn thiện thêm, nhất là sau khi nhận feedback từ thị trường và user.

▸ 3. Kinh nghiệm với body shopping và NDA

Body shopping bị đánh giá là không bền: nhân sự làm trực tiếp bên khách dễ so sánh benefit, chênh lệch giá cao (công ty thu 10 đồng, trả nhân công 8 đồng, lời 2 đồng mà không làm gì), rồi mất người sau khi dự án xong. Còn NDA thì gần như luôn phải ký đầu tiên - không ký thì chắc chắn không nhận được dự án, nên cứ xem đó là bước bắt buộc.

▸ 4. Lời mời chia sẻ case study

Giảng viên khuyến khích học viên, nếu gặp case study khác với chia sẻ trong bài, hãy trao đổi lại để cùng sưu tầm và bổ sung kinh nghiệm thực tế cho lớp.

Chương 4 · Bài 1

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học mở đầu chương về các phương pháp ước lượng, làm rõ hai khái niệm dễ nhầm: proposal và estimation. Điểm mấu chốt: estimation (ước lượng) là một phần nằm trong proposal (giải pháp tổng thể); và ước lượng luôn mang tính dự đoán, không thể chính xác tuyệt đối.

─── SAU BÀI HỌC, BẠN SẼ

• Phân biệt được proposal và estimation trong dự án gia công phần mềm.
• Hiểu ước lượng dự án là quá trình xác định và dự đoán bốn yếu tố chính.
• Ý thức được vì sao phải ước lượng trước khi bắt tay vào làm bất kỳ công việc nào.

─── NỘI DUNG CHÍNH

▸ 1. Proposal và estimation khác nhau thế nào

Proposal là giải pháp, kế hoạch tổng thể để thực hiện dự án - bao gồm cả giải pháp, chi phí, điều kiện và nhiều thứ khác. Estimation là phần ước lượng, và nó nằm trong proposal. Khi khách mới có ý tưởng và cần công ty gia công làm một proposal, thì bên trong proposal đó luôn có phần estimation do bên gia công thực hiện.

▸ 2. Ước lượng dự án là gì

Ước lượng dự án là quá trình xác định và dự đoán các yếu tố chính của dự án. Hai từ khóa "xác định" và "dự đoán" cho thấy ước lượng không thể chính xác tuyệt đối. Bốn yếu tố cần ước lượng gồm: thời gian, chi phí, nguồn lực và phạm vi công việc. Đây là phần rất quan trọng khi lập kế hoạch, giúp dự án chạy hiệu quả, đúng tiến độ và trong phạm vi ngân sách.

▸ 3. Lưu ý: đừng nhảy vào làm ngay khi nhận việc

Một thói quen sai thường gặp là khi được giao việc thì lao vào làm liền. Điều đúng đắn là trước tiên ước lượng công việc đó mất bao lâu, có vấn đề gì, rồi trình bày hướng đi cho người quản lý dự án hoặc người giao việc. Khi họ hiểu và thống nhất rồi thì mới bắt đầu làm - đây là điểm cần ghi nhớ trước khi bước sang các phương pháp ước lượng cụ thể ở những bài sau.

Chương 4 · Bài 2

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học hướng dẫn phương pháp Bottom-up Estimating - ước lượng từ dưới lên: chia nhỏ công việc đến mức có thể, ước lượng từng phần rồi cộng lại thành tổng. Điểm mấu chốt: đây là phương pháp có độ chính xác cao nhất vì soi từng chi tiết, nhưng đổi lại rất tốn thời gian và công sức.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu nguyên lý chia nhỏ - ước lượng từng phần - cộng tổng của Bottom-up.
• Biết cách lập bảng estimate theo giờ và quy đổi số giờ ra chi phí (tiền công).
• Nhận ra vì sao việc chia nhỏ cần làm có hệ thống, theo nhóm.

─── NỘI DUNG CHÍNH

▸ 1. Nguyên lý Bottom-up Estimating

Chia nhỏ khối lượng công việc của dự án đến mức có thể, ước lượng từng phần nhỏ, rồi cộng lại để ra tổng chi phí, thời gian và nguồn lực cho toàn bộ dự án. Vì xem xét từng chi tiết nên độ chính xác cao nhất trong các phương pháp, nhưng cũng tốn công nhất.

▸ 2. Ví dụ: ước lượng một website bán hàng

Chia dự án thành các hạng mục như xây dựng database, thiết kế UI, coding frontend, coding backend, testing (create test case, execute test case). Với mỗi hạng mục, xác định ai làm và estimate theo giờ. Người ước lượng nên là doer - người trực tiếp làm và hiểu công việc. Bảng có thể trình bày theo dạng matrix, rồi dùng hàm sum để cộng ra tổng số giờ (ví dụ 14 ngày công).

▸ 3. Quy đổi số giờ ra tiền công

Từ số giờ, quy đổi ra chi phí theo từng role (ví dụ dev và designer). Cách tính đơn giá giờ: lấy lương tháng chia cho số ngày công trung bình (khoảng 20 ngày), rồi chia tiếp cho 8 giờ để ra tiền một giờ. Nhân số giờ với đơn giá giờ rồi sum lại sẽ ra tổng chi phí bằng Việt Nam đồng (ví dụ 15 triệu 375 ngàn).

▸ 4. Lưu ý: chia nhỏ phải có hệ thống

Phương pháp này khó nhất ở khâu chia nhỏ. Không phải muốn chia sao thì chia - cần họp team, tập hợp những người hiểu việc để cùng define và chia nhỏ một cách có hệ thống, hợp lý. Đây là công đoạn tốn công nhất của Bottom-up Estimating.

Chương 4 · Bài 3

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học giới thiệu Analogous Estimating — phương pháp ước lượng dựa trên một dự án đã làm trong quá khứ có tính năng và yêu cầu tương tự. Điểm mấu chốt: bạn lấy số liệu thực tế của dự án cũ làm cơ sở, rồi cộng thêm một hệ số buffer cho phần khác biệt để ra con số cho dự án mới. Đây là cách ước lượng nhanh nhất trong các phương pháp, phù hợp khi cần báo giá gấp.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu bản chất của ước lượng tương tự: dựa trên dữ liệu lịch sử của một dự án gần giống.
• Biết cách cộng hệ số buffer cho phần tính năng, rủi ro hoặc khác biệt so với dự án cũ.
• Biết phải làm gì khi không có dự án tương tự để tham chiếu.

─── NỘI DUNG CHÍNH

▸ 1. Lấy số liệu thực tế của dự án cũ làm cơ sở

Điều quan trọng cần phân biệt: con số bạn dùng làm gốc là thực tế đã bỏ ra, không phải con số ước lượng. Ví dụ trong bài, một dự án website đã hoàn thành tốn thực tế 128 giờ. Con số này có sẵn, đáng tin cậy vì nó phản ánh công sức thật đã bỏ ra.

▸ 2. Cộng hệ số buffer cho phần khác biệt

Dự án mới thường không giống hệt dự án cũ — có thể thêm một chức năng (ví dụ quản lý user), hoặc có rủi ro riêng. Với mỗi khác biệt đó, bạn gán một hệ số, ví dụ 10%, rồi lấy số cũ nhân hệ số và cộng lại. Với 128 giờ và buffer 10%, ước lượng dự án mới là khoảng 140,8 giờ. Hệ số buffer tùy bạn đánh giá theo tính năng thêm vào hay mức độ rủi ro.

▸ 3. Khi không có dự án tương tự

Ưu điểm lớn nhất của phương pháp này là ra số cực nhanh — ngược với bottom-up phải rã từng hạng mục rất lâu. Nhưng nếu bạn không có dự án cũ nào để đối chiếu, đừng phán bừa. Hãy nhờ người có kinh nghiệm hoặc tham khảo dự án tương tự của công ty khác, nơi khác, rồi mới ra con số. Cách này luôn đáng tin hơn việc đoán mò.

Chương 4 · Bài 4

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học giới thiệu Parametric Estimating — phương pháp ước lượng dựa trên tham số đã biết và mối quan hệ tỉ lệ giữa các biến số. Điểm mấu chốt: từ dữ liệu lịch sử của nhóm, bạn rút ra một đơn giá chuẩn (ví dụ trung bình bao nhiêu giờ cho một chức năng), rồi nhân với số lượng và với hệ số độ khó để ra con số. Nghe có vẻ "toán học" nhưng thực chất chỉ là phép nhân các hệ số.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu ước lượng tham số là nhân đơn giá chuẩn với số lượng và hệ số điều chỉnh.
• Biết cách xây một đơn giá chuẩn từ lịch sử của nhóm (ví dụ 15 giờ cho một chức năng).
• Biết dùng hệ số độ khó / dễ / bình thường để tinh chỉnh ước lượng cho sát thực tế.

─── NỘI DUNG CHÍNH

▸ 1. Đơn giá chuẩn từ dữ liệu lịch sử

Nền tảng của phương pháp là một tham số đã biết, rút ra từ lịch sử của nhóm. Ví dụ trong bài: quản lý một ứng dụng web ngân hàng, dựa trên các dự án trước, nhóm biết trung bình mỗi chức năng tốn khoảng 15 giờ để phát triển. Có con số này rồi, bạn chỉ cần lấy nó nhân với số lượng chức năng là ra tổng số giờ.

▸ 2. Điều chỉnh cho từng chức năng

Không phải chức năng nào cũng bằng nhau. Với một chức năng khó như quản lý người dùng, thay vì 15 giờ bạn có thể đặt 20 giờ. Con số tổng tự cập nhật theo. Đây là cách cộng dồn đơn giản, phù hợp khi mỗi chức năng có mức công riêng.

▸ 3. Hệ số độ khó / dễ / bình thường

Khi có quá nhiều tính năng và khó gán chính xác từng con số giờ, bạn dùng thêm một hệ số độ khó. Ví dụ trong bài: khó = 150%, bình thường = 100%, dễ = 75% của thời gian trung bình cho một chức năng. Bạn phân loại từng tính năng vào ba mức này, rồi nhân đơn giá chuẩn với hệ số phần trăm tương ứng. Nhờ vậy con số ra sát thực tế hơn mà vẫn giữ được sự nhanh gọn của phương pháp tham số.

Chương 4 · Bài 5

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học giới thiệu Three-Point Estimating — phương pháp tăng độ chính xác bằng cách xem xét mỗi công việc qua ba kịch bản thay vì phán một con số duy nhất. Điểm mấu chốt: thay vì đoán "làm 4–5 ngày", bạn đưa ra ba giá trị Lạc quan, Khả dĩ nhất, Bi quan rồi tính giá trị trung bình theo công thức PERT để giảm rủi ro sai số.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu ba kịch bản Optimistic / Most likely / Pessimistic đại diện cho điều gì.
• Áp dụng đúng công thức PERT để ra thời gian trung bình cho từng công việc.
• Biết dùng prototype để làm cho ba con số này sát thực tế hơn.

─── NỘI DUNG CHÍNH

▸ 1. Ba kịch bản: Lạc quan, Khả dĩ nhất, Bi quan

Với mỗi công việc, bạn đặt ba câu hỏi. Lạc quan (Optimistic): nếu mọi thứ suôn sẻ, không gặp vấn đề gì thì mất bao lâu? Bi quan (Pessimistic): nếu gặp nhiều vấn đề nhất thì mất bao lâu? Khả dĩ nhất (Most likely): ở mức bình thường, vừa có thuận lợi vừa có trục trặc, thì mất bao lâu? Ba con số này bao trọn khoảng dao động thực tế, thay vì một con số cảm tính.

▸ 2. Công thức PERT

Giá trị trung bình được tính bằng: (Lạc quan + 4 × Khả dĩ nhất + Bi quan) / 6. Trọng số 4 dồn vào kịch bản khả dĩ nhất, nên kết quả nghiêng về giá trị thực tế nhất nhưng vẫn có tính đến hai biên. Bạn áp công thức này cho từng chức năng (trang chủ, giỏ hàng, thanh toán, quản lý người dùng, quản lý đơn hàng...) rồi cộng lại để ra tổng thời gian dùng cho báo giá.

▸ 3. Mẹo: dùng prototype để có con số chính xác hơn

Ba con số ban đầu vẫn dựa nhiều vào phán đoán. Để chính xác hơn, hãy cho team làm prototype một, hai, ba chức năng và đo kết quả thật. Con số chạy thử thực tế giúp bạn điền lại ba giá trị sát hơn, đồng thời cho thấy người ở level nào làm nhanh chậm ra sao — từ đó bố trí nhân sự vào dự án hợp lý hơn.

Chương 4 · Bài 6

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học giới thiệu Planning Poker — kỹ thuật ước lượng theo nhóm, rất phổ biến trong Agile, đặc biệt là Scrum. Điểm mấu chốt: mỗi thành viên độc lập chọn một thẻ bài mang giá trị story point theo dãy Fibonacci, cùng lật lên một lúc; chỗ nào con số lệch nhau nhiều thì cả team thảo luận để hiểu thống nhất rồi chốt lại. Giá trị lớn nhất không nằm ở con số, mà ở việc cả nhóm cùng hiểu rõ tính năng.

─── SAU BÀI HỌC, BẠN SẼ

• Nắm cách chạy một buổi Planning Poker: trình bày, vote kín, lật thẻ, thảo luận, chốt số.
• Hiểu vì sao dùng dãy Fibonacci và vì sao mỗi người phải vote độc lập.
• Cân nhắc được ưu và nhược điểm của phương pháp để áp dụng đúng lúc.

─── NỘI DUNG CHÍNH

▸ 1. Bộ thẻ bài theo dãy Fibonacci

Mỗi thành viên có một bộ thẻ mang các con số theo dãy Fibonacci: 1, 2, 3, 5, 8, 13, 21. Đây là các story point. Người chơi chỉ được chọn số có trong dãy, không được chọn số khác — khoảng cách nới rộng dần giúp phản ánh sự bất định càng tăng khi công việc càng lớn.

▸ 2. Quy trình một vòng vote

Đầu tiên Product Owner trình bày tính năng gồm những gì để mọi người thống nhất quan điểm. Sau đó mỗi người úp thẻ estimate của mình xuống, không trao đổi với nhau. Hết khoảng 30 giây đến 1 phút, cả nhóm đồng loạt lật lên. Vote độc lập như vậy tránh việc người này bị ảnh hưởng bởi ý kiến người kia.

▸ 3. Thảo luận khi con số lệch nhau

Khi thấy chênh lệch lớn — ví dụ một người cho 1 còn người khác cho 8 — đó là tín hiệu cả team chưa hiểu giống nhau về tính năng. Mỗi người trình bày lý do con số của mình, sau đó nhóm đồng thuận và chốt lại một con số chung. Cứ lặp lại cho từng tính năng.

▸ Ưu và nhược điểm cần lưu ý

Ưu điểm: cả team hiểu rõ tính năng hơn, có góc nhìn tổng quan và thống nhất được với nhau. Nhược điểm: buổi ước lượng khá dài — thường 2 đến 4 tiếng, càng nhiều tính năng càng lâu, nên thường chốt quanh 2 tiếng để đỡ tốn thời gian.

Chương 4 · Bài 7

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học giới thiệu Padding Estimating — kỹ thuật thêm một khoảng dự phòng (buffer / bộ đệm) vào ước lượng ban đầu để giảm rủi ro trễ tiến độ và vỡ ngân sách. Điểm mấu chốt: Padding không phải là một phương pháp ước lượng độc lập, mà là bước cộng thêm trên kết quả của bottom-up, tham số hay ba điểm; và bộ đệm cho yêu cầu thay đổi nên được tách riêng, trình bày minh bạch với khách hàng.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu bản chất bộ đệm là khoản dự phòng cho rủi ro và thay đổi, không phải phần "ăn gian".
• Biết thêm buffer theo hai lớp: cho hạng mục nhiều rủi ro và cho toàn dự án.
• Biết cách tách riêng quỹ thay đổi để trình bày minh bạch với khách hàng.

─── NỘI DUNG CHÍNH

▸ 1. Bộ đệm là gì

Ví dụ dễ hiểu: mình đi từ nhà đến công ty ước lượng 30 phút, nhưng đường hay kẹt xe nên cộng thêm bộ đệm 15 phút, thành 45 phút. Trong dự án cũng vậy — một hạng mục dễ phát sinh (ví dụ xây dựng database) thì cộng thêm một tỉ lệ buffer, ví dụ 20%, vì nó thường tốn nhiều thời gian hơn dự kiến.

▸ 2. Hai lớp buffer

Padding thường áp dụng thành hai lớp. Lớp thứ nhất là buffer cho từng hạng mục rủi ro cao (như 20% cho database). Lớp thứ hai là buffer cho toàn dự án dành cho yêu cầu thay đổi, ví dụ 15% — một quỹ dự phòng để ứng phó khi khách đổi yêu cầu. Trong bài, sau khi cộng các buffer, dự án được báo giá khoảng 147 giờ, tương ứng khoảng 18.198.000.

▸ 3. Tách riêng quỹ thay đổi và trình bày minh bạch

Đây là điểm hay nhất của phương pháp. Bạn nên tách riêng phần bộ đệm cho yêu cầu thay đổi (trong ví dụ khoảng 2.373.000) ra khỏi con số lõi (khoảng 128 giờ, tương ứng khoảng 15 triệu). Khi báo giá, trình bày với khách: đây là kinh phí lõi, còn đây là quỹ dự phòng — có thể không dùng đến, chỉ dùng khi phát sinh thay đổi. Cách này giúp khách hiểu rõ tiền đi đâu, đồng thời để bạn chủ động optimize trong quá trình thực thi.

Chương 4 · Bài 8

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học đưa bạn đi qua 5 mẫu (template) ước lượng làm sẵn, mỗi mẫu ứng với một phương pháp đã học: bottom-up, tương tự, tham số, ba điểm và thêm bộ đệm. Điểm mấu chốt: các mẫu đều có chung một khung — sheet ước lượng chi tiết, sheet thống kê theo nhiều view, và cách quy đổi giờ ra man-day, man-month; công thức đã cài sẵn, bạn chỉ cần điều chỉnh hệ số.

─── SAU BÀI HỌC, BẠN SẼ

• Nắm cấu trúc chung của một mẫu ước lượng: sheet ước lượng, sheet thống kê, phần giá tiền.
• Biết quy đổi effort giữa giờ, man-day và man-month.
• Biết chọn và kết hợp các mẫu phù hợp cho dự án của mình.

─── NỘI DUNG CHÍNH

▸ 1. Khung chung của mọi mẫu

Mỗi mẫu đều có phần mô tả dự án, một sheet ước lượng liệt kê các activity (Coding Program, Coding Pattern, Review, Correct; phía test là create / review / execute / feedback test case) và một sheet thống kê tổng hợp theo danh mục hoặc theo tính năng. Muốn ra tiền thì chỉ cần thêm một đơn giá rồi nhân. Công thức đã có sẵn, bạn chỉ chỉnh hệ số là con số tự nhảy.

▸ 2. Quy đổi giờ sang man-day và man-month

Ở cuối sheet ước lượng, effort được tính theo ba đơn vị: tổng theo giờ; chia cho 8 ra man-day (số ngày công); chia cho 20 ra man-month (công theo tháng). Con số 20 là số ngày công/tháng mặc định của giảng viên — một số công ty dùng 21 tùy hợp đồng, nên bạn chỉnh lại cho khớp thực tế của mình.

▸ 3. Năm mẫu và cách kết hợp

Năm mẫu khác nhau chủ yếu ở sheet ước lượng. Bottom-up rã chi tiết từng function. Tương tự chỉ cần tính năng chính, lấy số lịch sử nhân một hệ số (ví dụ 1.1). Tham số phân loại khó / dễ / vừa, dùng VLOOKUP cộng với một số điều chỉnh bằng tay. Ba điểm trình bày ba cột lạc quan / khả dĩ nhất / bi quan rồi áp công thức (Lạc quan + 4 × Khả dĩ nhất + Bi quan) / 6. Thêm bộ đệm lấy một ước lượng lõi rồi cộng buffer (ví dụ 10–15%). Việc dùng nhiều phương pháp cùng lúc trong một dự án là bình thường — miễn là bạn luôn có một phương pháp làm gốc. Tải template về và chỉnh sửa theo dự án của mình.

Chương 4 · Bài 9

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học giới thiệu một mẫu báo giá (proposal) dùng cho thị trường Nhật, gồm 5 sheet đi từ bìa tài liệu đến chi tiết ước lượng. Điểm mấu chốt: quy trình dựng báo giá đi ngược từ sheet chi tiết ước lượng lên sheet tổng, và một báo giá kiểu Nhật đòi hỏi rất kỹ phần điều kiện tiền đề, điều kiện bàn giao — không chỉ có con số tiền. Lưu ý mẫu chỉ để tham khảo và khi gửi khách phải chuyển toàn bộ sang tiếng Nhật.

─── SAU BÀI HỌC, BẠN SẼ

• Nắm cấu trúc 5 sheet của một mẫu báo giá thị trường Nhật.
• Biết trình tự dựng báo giá: làm sheet ước lượng chi tiết trước, rồi tổng hợp lên sheet tổng.
• Biết những hạng mục Nhật đặc biệt coi trọng: effort quản lý, điều kiện tiền đề, điều kiện bàn giao.

─── NỘI DUNG CHÍNH

▸ 1. Cấu trúc 5 sheet

Mẫu gồm: sheet bìa tài liệu; sheet lịch sử thay đổi (record of change); sheet tổng quan hệ thống và điều kiện tiền đề; sheet tổng về giá tiền cùng số man-month, man-day; và sheet chi tiết file ước lượng. Trên sheet bìa bạn điền tên khách hàng, tên hệ thống, tên dự án, ngày tạo.

▸ 2. Dựng báo giá từ chi tiết lên tổng

Trình tự là làm sheet số 5 (chi tiết ước lượng) trước: dùng các phương pháp đã học để ra effort phần Coding và phần Test, ví dụ ra khoảng 6.5 man-month. Sau đó quay lại sheet số 4 (tổng): con số ở đây tham chiếu từ sheet 5, nhưng bạn thêm các hạng mục theo cách làm báo giá — xây dựng môi trường, xác nhận thông số kỹ thuật (ví dụ 10 ngày, 5 ngày), và đặc biệt là công quản lý tiến độ / quản lý dự án, vì sheet chi tiết chỉ tính công của các function chứ chưa tính phần quản lý. Cuối cùng là phần thanh toán theo từng đợt (lần 1, lần 2, ngày thanh toán) tùy loại hợp đồng.

▸ 3. Điều kiện tiền đề và điều kiện bàn giao

Đây là phần thị trường Nhật coi trọng. Bạn ghi rõ mô tả môi trường hệ thống, trách nhiệm của mỗi bên, và các điều kiện ràng buộc: phương thức hợp đồng, cách communication, cách khách giao thiết bị và cung cấp tài liệu. Phần deliverable liệt kê những gì bàn giao (tài liệu, mã nguồn). Phần điều kiện bàn giao nêu tiêu chí nghiệm thu — có dự án yêu cầu ghi cụ thể tỉ lệ bug, tỉ lệ lỗi và cách đạt acceptance criteria của khách. Nhớ: mẫu này chỉ tham khảo, khi gửi khách phải là tiếng Nhật.

Chương 4 · Bài 10

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học giới thiệu một mẫu báo giá dùng cho thị trường Việt Nam và so sánh nó với mẫu thị trường Nhật ở bài trước. Điểm mấu chốt: khách Việt thường nhìn vào tổng tiền trước, ít soi chi tiết man-month; nên báo giá gọn gàng, viết toàn tiếng Việt, nhưng vẫn phải giữ các phần bắt buộc như điều kiện tiên quyết, giả định và kế hoạch thanh toán.

─── SAU BÀI HỌC, BẠN SẼ

• Nắm cấu trúc cơ bản của một mẫu báo giá thị trường Việt Nam.
• Hiểu khác biệt về mối quan tâm của khách Việt so với khách Nhật khi đọc báo giá.
• Biết những phần bắt buộc phải có: điều kiện tiên quyết, giả định, kế hoạch thanh toán.

─── NỘI DUNG CHÍNH

▸ 1. Cấu trúc mẫu

Mẫu gồm các sheet cơ bản: record of change (lịch sử thay đổi), sheet bìa, project information, và sheet WBS để breakdown công việc. Phương pháp ước lượng thì đã học ở các bài trước — bạn dùng phương pháp nào cũng được, ra con số ngày rồi điền vào để tổng kết, tính tổng và ra giá tiền. Có những khoản tiền liên quan tới phần khác thì điền thêm vào.

▸ 2. Khác biệt giữa khách Việt và khách Nhật

Đây là chia sẻ đáng nhớ nhất. Khách Việt Nam thường không quan tâm nhiều tới chi tiết hay man-month, mà nhìn tổng số tiền trước tiên để đánh giá. Khách Nhật thì ngược lại — soi kỹ chi tiết và review từng mục nhỏ (như mẫu ở bài 9). Vì vậy báo giá cho thị trường Việt viết toàn bộ bằng tiếng Việt, trình bày gọn hướng tới tổng tiền; còn báo giá Nhật phải chi tiết và bằng tiếng Nhật.

▸ 3. Các phần bắt buộc phải có

Dù gọn, một mẫu báo giá vẫn cần đủ khung: sheet bìa, sheet lịch sử, sheet mô tả chi tiết ra bao nhiêu tiền, và một sheet tổng quan cho khách đọc. Trong sheet tổng quan, phải có điều kiện tiên quyết, giả định và môi trường — các phần này cùng kế hoạch thanh toán (đi bao nhiêu phần trăm hợp đồng ở mỗi đợt) là quan trọng nhất và phải làm cho hợp lý. Ở project information, ghi rõ ngôn ngữ phát triển, thiết kế, giả định, danh sách các giai đoạn và điều kiện chấp nhận sản phẩm. Tải template về rồi chỉnh sửa theo dự án của mình.

Chương 4 · Bài 11

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Đây là bài tổng kết Chương 4 về estimation (ước lượng dự án) trong ngành gia công phần mềm. Sau khi đã đi qua nhiều phương pháp ước lượng và các mẫu báo giá, giảng viên chia sẻ những kinh nghiệm "xương máu" khi ước lượng thực tế. Điểm mấu chốt: ước lượng hiếm khi tuyệt đối chính xác, thời gian lại rất gấp, nên bạn cần mẹo làm nhanh, biết ước lượng bám theo budget của khách và luôn để cả nhóm review lại effort trước khi gửi.

─── SAU BÀI HỌC, BẠN SẼ

• Nắm cách xử lý khi khách đưa khối lượng tài liệu lớn mà thời gian báo giá ngắn.
• Hiểu vì sao đôi khi phải ước lượng bám theo budget của khách để trúng thầu.
• Biết kết hợp nhiều phương pháp ước lượng và review chéo trước khi chốt.

─── NỘI DUNG CHÍNH

▸ 1. Thực tế của việc ước lượng gia công phần mềm

Ước lượng rất khó ra con số chính xác tuyệt đối, trong khi thời gian lại gấp — khách chỉ cho một hai tuần, có khi vài ngày, mà tài liệu thì rất nhiều. Đây là áp lực đặc thù của ngành, nên bạn phải có cách làm nhanh mà vẫn đủ tin cậy.

▸ 2. Mẹo ước lượng nhanh theo số trang tài liệu

Khi không kịp rã nhỏ (bottom-up) từng hạng mục, hãy đếm số lượng trang (page) của bộ tài liệu — khóa học có cung cấp tool đếm trang. Từ số trang, ước tính effort trung bình cho mỗi trang rồi nhân lên. Song song, hãy đối chiếu với budget khách đưa ra: nếu khách có ngân sách khoảng 5 triệu (5 million), con số ước lượng của bạn cần rơi về gần mức đó thì mới có cơ hội trúng thầu — báo giá quá cao thì gần như chắc chắn trượt.

▸ 3. Kết hợp phương pháp và luôn re-estimation

Đừng cứng nhắc một phương pháp; nên trộn nhiều phương pháp tùy tình huống. Sau khi có con số, thực hiện re-estimation — xem lại estimation đúng hay sai, có chạy được thực tế không, rồi điều chỉnh.

▸ Mẹo quan trọng: review chéo effort trước khi gửi

Trước khi gửi báo giá đi, hãy để tất cả mọi người cùng review lại ước lượng, đặc biệt là những người doer (người trực tiếp code, test). Chính họ nhìn lại effort mới giúp con số sát thực tế và tránh rủi ro cam kết sai.

Chương 5 · Bài 1

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài mở đầu Chương 5 giới thiệu toàn cảnh quy trình báo giá (quotation) cho các công ty Nhật trong mảng gia công phần mềm. Giảng viên gói quy trình thực tế thành 6 bước, đi từ lúc tiếp nhận yêu cầu đến khi ký hợp đồng. Điểm mấu chốt cần nhớ: một bản báo giá tự nó không đủ — bạn luôn phải có buổi meeting để giải thích và thương lượng, nếu không thì dù báo giá viết kỹ đến đâu cũng dễ thất bại.

─── SAU BÀI HỌC, BẠN SẼ

• Nắm được 6 bước của quy trình báo giá cho khách Nhật.
• Hiểu vai trò của NDA, phương án đối sách và estimation trong quy trình.
• Ý thức được tầm quan trọng của buổi meeting giải thích và thương lượng báo giá.

─── NỘI DUNG CHÍNH

▸ 1. Sáu bước của quy trình báo giá

1. Tiếp nhận yêu cầu — hai công ty meeting, giới thiệu và trao đổi công việc cần làm.
2. Ký NDA (hợp đồng bảo mật) trước khi nhận tài liệu, source code — bước gần như bắt buộc.
3. Phân tích, lập phương án và đối sách (counter-measure) cho dự án.
4. Tính toán chi phí (cost) — làm estimation và chuẩn bị tài liệu báo giá.
5. Gửi báo giá và thương lượng với khách hàng.
6. Xác nhận final và ký hợp đồng, rồi triển khai dự án.

▸ 2. Vì sao báo giá phải đi kèm buổi meeting

Báo giá gửi đi thường toàn chữ và số; khách khó tự đọc hiểu hết. Vì vậy sau khi gửi, bạn cần hẹn một buổi họp để trực tiếp giải thích. Thiếu bước này, dù tài liệu viết kỹ hay vẽ hình nhiều đến đâu vẫn dễ thất bại.

▸ 3. Thương lượng để điều chỉnh cho phù hợp

Trong lúc gửi báo giá và họp, bạn thu thập phản hồi để biết chỗ nào đã đúng, chỗ nào chưa phù hợp, rồi thương lượng điều chỉnh. Khi hai bên thống nhất, khách xác nhận bản final, tiến tới ký hợp đồng và triển khai. Các bài tiếp theo sẽ đi sâu vào từng bước.

Chương 5 · Bài 2

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học đi sâu vào bước 1 của quy trình báo giá: tiếp nhận yêu cầu. Bạn sẽ thấy một buổi meeting giới thiệu đầu tiên giữa công ty gia công phần mềm và khách hàng diễn ra như thế nào: từ lúc khách liên hệ, hai bên giới thiệu, đến khi chốt được phạm vi công việc sơ bộ. Điểm mấu chốt: kết thúc buổi này, phía gia công phải lập một team chuyên trách báo giá và gửi meeting minutes cho khách để có người chịu trách nhiệm và mọi thứ được ghi nhận rõ ràng.

─── SAU BÀI HỌC, BẠN SẼ

• Nắm trình tự một buổi meeting tiếp nhận yêu cầu với khách hàng.
• Biết những nội dung cần trao đổi: giới thiệu công ty, scope, requirement, thời gian.
• Hiểu vì sao phải lập team báo giá và lưu record, meeting minutes ngay sau buổi họp.

─── NỘI DUNG CHÍNH

▸ 1. Từ liên hệ đến buổi giới thiệu đầu tiên

Khách có nhu cầu thường tìm công ty gia công qua website hoặc trang giới thiệu, rồi liên hệ qua email/chat. Sau đó hai bên setup buổi meeting (chọn ngày, chọn công cụ). Vào buổi đầu, hai công ty giới thiệu lẫn nhau: quy mô, lịch sử, hiện trạng, thế mạnh. Phía gia công có thể nhấn thêm sell point — điểm mạnh của mình khi làm dự án.

▸ 2. Nhận yêu cầu và xác định phạm vi sơ bộ

Khách trình bày dự án sơ bộ qua slide hoặc gửi tài liệu cơ bản. Hai bên xác định scope (phạm vi công việc), requirement (yêu cầu kỹ thuật) và thời gian hoàn thành — ở mức tổng quan, chưa chi tiết. Nếu được, nên hỏi ngay những điểm chưa rõ để tránh hiểu lầm. Một đặc điểm với khách Nhật: họ thường hỏi thẳng chi phí dự kiến ngay trong buổi này.

▸ 3. Việc phải làm ngay sau buổi meeting

Kết thúc buổi họp, phía gia công cần lập một team chuyên trách báo giá cho dự án — nếu không sẽ không ai chịu trách nhiệm. Đồng thời phải có record và meeting minutes gửi lại khách hàng dưới dạng văn bản, làm cơ sở đi tiếp các bước sau.

Chương 5 · Bài 3

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học nhấn mạnh bước ký NDA (Non-Disclosure Agreement — hợp đồng bảo mật thông tin) trong quy trình báo giá cho khách Nhật, trước khi nhận tài liệu và source code của dự án. Điểm mấu chốt: NDA không chỉ là thủ tục — nó vừa thể hiện sự chuyên nghiệp với khách, vừa ràng buộc team báo giá phải cực kỳ cẩn thận khi cầm tài liệu của khách, vì đây là giai đoạn dễ rò rỉ thông tin nhất.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu vì sao phải ký NDA trước khi nhận tài liệu, source code của dự án.
• Biết bên nào có thể chủ động soạn và gửi NDA, và điều đó thể hiện sự chuyên nghiệp ra sao.
• Ý thức được rủi ro rò rỉ thông tin khi team báo giá không cố định.

─── NỘI DUNG CHÍNH

▸ 1. NDA — bên nào cũng có thể chủ động gửi

Với hợp đồng NDA, phía khách hàng có thể gửi cho bạn, hoặc bạn chủ động gửi cho khách. Không phải lúc nào khách cũng có sẵn NDA — nếu khách chưa chuyên nghiệp và không có mẫu, bạn nên soạn một hợp đồng bảo mật thông tin và đề nghị hai bên ký. Việc này khiến khách đánh giá bạn chuyên nghiệp, thay vì chỉ trao đổi vài câu rồi vội gửi/nhận source code, tài liệu.

▸ 2. Rủi ro đặc thù: team báo giá không cố định

Trong ngành gia công phần mềm, bước estimation / làm proposal thường không có team cố định. Để tối ưu nguồn lực, người ta luôn điền người vào các dự án đang chạy, nên khi có một báo giá mới, công ty mới tập hợp một team khoảng hai ba người. Những người này đồng thời đang làm việc khác, nên nguy cơ nhầm lẫn, rò rỉ tài liệu là rất thực tế.

▸ Lưu ý khi cầm tài liệu của khách

Sau khi đã ký NDA, team làm proposal / ước lượng / báo giá phải rất cẩn thận khi thu thập và lưu trữ tài liệu của khách. Rủi ro nguy hiểm nhất: khách hàng cũ vô tình thấy tài liệu của khách mới, hoặc thông tin khách mới bị lộ ra ngoài. Đã có hợp đồng bảo mật ràng buộc, nên chỉ một sơ suất cũng có thể gây hậu quả nghiêm trọng.

Chương 5 · Bài 4

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học đi vào bước phân tích yêu cầu, lập phương án và đối sách (counter-measure) — công việc của một đội báo giá chuyên sâu. Đặc thù của ngành outsourcing là thời gian báo giá rất gấp (thường dưới 2 tuần, có khi một tuần), trong khi đầu vào từ khách thì hoặc quá thiếu, hoặc quá nhiều. Điểm mấu chốt: bạn phải có cách xử lý nhanh (lấy mẫu, dùng AI, tận dụng người giỏi) và luôn ràng buộc bằng điều kiện tiền đề khi tài liệu chưa đầy đủ.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu vai trò và áp lực thời gian của đội phân tích, lập phương án báo giá.
• Biết cách xử lý ba tình huống điển hình về đầu vào tài liệu của khách.
• Biết dùng điều kiện tiền đề để ràng buộc phạm vi khi tài liệu chưa đủ.

─── NỘI DUNG CHÍNH

▸ 1. Đặc thù giai đoạn phân tích và lập phương án

Đội báo giá tìm hiểu yêu cầu qua Q&A với khách rồi đề xuất các phương án. Vì thị trường outsourcing rất cạnh tranh, thời gian thường gấp — báo giá chậm là mất cơ hội bỏ thầu. Để ra giá tốt và nhanh, đội cần người giỏi, biết áp dụng các kỹ thuật liên quan tới tiền như đưa padding / buffer vào, và tận dụng công cụ (AI code, tool develop) để tối ưu thời gian lẫn cost.

▸ 2. Ba vấn đề thường gặp và cách xử lý

1. Thời gian quá gấp: tìm người giỏi nhất trong lĩnh vực để pick up nhanh, tái sử dụng data mẫu, dùng AI tham khảo, và báo lãnh đạo để xin nguồn lực hỗ trợ.
2. Tài liệu quá nhiều (mấy trăm trang, chỉ có một hai ngày): không thể đọc hết nên phải lấy mẫu (sampling) một dạng tài liệu, rồi khái quát theo số lượng và tỷ lệ để suy ra báo giá.
3. Tài liệu không đầy đủ nhưng phải báo giá cả hệ thống: đưa giải pháp dựa trên tài liệu hiện có.

▸ Lưu ý khi tài liệu chưa đầy đủ

Khi khách chỉ đưa ý tưởng hoặc vài màn hình layout mà yêu cầu báo giá nguyên hệ thống, hãy ghi rõ điều kiện tiền đề: báo giá dựa trên giả định các màn hình tương tự nhau; nếu thực tế phức tạp hơn sẽ điều chỉnh. Ràng buộc bằng tiền đề giúp bạn không "đâm đầu" báo giá sai và có cơ sở re-estimation sau này.

Chương 5 · Bài 5

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học hướng dẫn bước tính chi phí (cost) và chuẩn bị tài liệu báo giá sau khi đã có phương án đối sách. Bạn sẽ thấy một báo giá mẫu (dạng fixed price) được dựng trên WBS như thế nào, gồm những đầu mục chi phí nào ngoài ngày công, và cách trình bày báo giá cho phù hợp với từng thị trường. Điểm mấu chốt: báo giá không chỉ là con số — nó phải kèm điều kiện tiền đề, giả định và được trình bày để khách dễ hiểu.

─── SAU BÀI HỌC, BẠN SẼ

• Biết quy đổi ước lượng (giờ/ngày/man-month) thành chi phí và tổng hợp các loại chi phí.
• Nắm cấu trúc một tài liệu báo giá dựa trên WBS: đầu việc, ngày công, giá tiền, điều kiện tiền đề.
• Biết điều chỉnh cách trình bày báo giá cho khách Nhật và khách Việt Nam.

─── NỘI DUNG CHÍNH

▸ 1. Từ estimation sang chi phí

Sau khi có phương án đối sách, bạn ước lượng số giờ / ngày / tháng công rồi quy đổi ra tiền. Ngoài ngày công, cần cộng thêm các chi phí khác liên quan tới dự án: thiết bị, máy móc, hosting, domain… Khoản nào chưa rõ thì để báo sau (offer), khoản nào đã biết thì đưa vào ngay.

▸ 2. Cấu trúc tài liệu báo giá (theo WBS)

Báo giá mẫu được dựng trên WBS (Work Breakdown Structure): liệt kê danh sách đầu việc, ngày công từng giai đoạn, giá tiền, rồi tính ra tổng ngày công và man-month. Kèm theo là điều kiện tiền đề, giả định, điều kiện chấp nhận sản phẩm, danh sách sản phẩm bàn giao và Payment Schedule (lịch thanh toán). Mẫu này là hợp đồng fixed price; với OSDC (thuê nhân sự dài hạn) thì cách báo giá sẽ khác.

▸ 3. Công cụ và cách trình bày theo từng thị trường

File báo giá có thể là Google Sheets, Excel, Word, PDF hay Google Docs — cái nào cũng được, quan trọng là khách dễ hiểu. Về kinh nghiệm trình bày: khách Nhật thích chi tiết, còn khách Việt Nam thích thấy tổng số tiền trước. Bạn có thể gộp nhiều sheet (org chart, solution, cách tiếp cận dự án) vào một file "all in one", nhưng mục tiêu cuối vẫn là có một buổi meeting để giải thích cho khách hiểu.

Chương 5 · Bài 6

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học chia sẻ những điểm lưu ý khi gửi báo giá cho khách hàng — nghe qua tưởng đơn giản nhưng lại quyết định thành bại. Bạn sẽ học cách bảo vệ thông tin nhạy cảm (công thức, effort, đơn giá) khi gửi file, chọn đúng kênh liên lạc, và trên hết là luôn hẹn một buổi meeting để giải thích và thương lượng. Điểm mấu chốt: bản báo giá gửi đi chỉ là điểm khởi đầu, cuộc thương lượng trực tiếp mới là nơi bạn chốt được deal.

─── SAU BÀI HỌC, BẠN SẼ

• Biết ẩn công thức, effort, đơn giá trước khi gửi báo giá ra ngoài.
• Nắm nguyên tắc chọn kênh gửi và trả lời theo đúng kênh khách hàng dùng.
• Hiểu vì sao buổi meeting thương lượng là bước không thể thiếu.

─── NỘI DUNG CHÍNH

▸ 1. Ẩn thông tin nhạy cảm trước khi gửi

File báo giá thường chứa công thức tính, effort, đơn giá — những con số "bí quyết" bạn có thể điều chỉnh. Trước khi gửi, hãy ẩn các công thức và con số nhạy cảm, chỉ để lại phần giá thể hiện ra ngoài, rồi export ra PDF để gửi. Lý do: người nhận có thể forward báo giá cho bên thứ ba, làm lộ đơn giá và cách tính của bạn. Tuy nhiên cần linh hoạt — nếu khách cần chi tiết mà bạn ẩn hết thì khách sẽ không hài lòng.

▸ 2. Chọn đúng kênh liên lạc

Gửi báo giá qua kênh mà khách có thể check và phản hồi được (email, Zalo, Skype…). Nguyên tắc đơn giản: ai liên lạc/feedback qua kênh nào thì trả lời qua kênh đó — khách email thì trả lời email, khách chat thì trả lời qua chat. Đừng gửi qua kênh lạ khiến khách không nhận được.

▸ Lưu ý quan trọng: luôn hẹn buổi meeting thương lượng

Điểm quan trọng nhất của bài: sau khi gửi báo giá, luôn hẹn một buổi meeting để giải thích, trình bày và thương lượng. Một file báo giá nhiều sheet, nhiều nội dung sẽ không tự nói lên ý đồ của bạn; nếu thiếu buổi họp, bạn không thể biết khách nghĩ gì để mà thương lượng và điều chỉnh cho phù hợp.

Chương 5 · Bài 7

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học khép lại quy trình báo giá bằng bước cuối: xác nhận báo giá và ký hợp đồng. Sau khi đã thương lượng và trúng thầu, bạn chốt lại báo giá với khách, tạo hợp đồng và tiến hành ký kết. Điểm mấu chốt: hợp đồng gắn với yếu tố pháp lý và ngôn ngữ — với khách Nhật, hợp đồng chính thức thường là song/tam ngữ (Nhật – Anh – Việt), và bạn nên nhờ bộ phận pháp lý rà soát trước khi ký.

─── SAU BÀI HỌC, BẠN SẼ

• Nắm trình tự từ xác nhận báo giá đến tạo và ký hợp đồng với khách.
• Hiểu yêu cầu về ngôn ngữ hợp đồng khi làm việc với khách Nhật và tại Việt Nam.
• Biết vai trò của phụ lục hợp đồng (với hợp đồng Labo) và quy trình ký giấy tờ thực tế.

─── NỘI DUNG CHÍNH

▸ 1. Chốt báo giá và tạo hợp đồng

Sau buổi thương lượng, nếu đấu thầu thành công và vào được vòng trong, bạn xác nhận lại báo giá với khách rồi tạo hợp đồng đưa khách ký. Tùy loại hợp đồng mà các điều kiện về hệ thống thanh toán và cách triển khai sẽ khác nhau.

▸ 2. Ngôn ngữ và tính pháp lý của hợp đồng

Với khách Nhật, họ dùng tiếng Nhật, không dùng tiếng Anh; trong khi hợp đồng tại Việt Nam bắt buộc phải có tiếng Việt mới ký được. Vì vậy hợp đồng chính thức giữa hai bên thường là ba thứ tiếng (Nhật – Anh – Việt) để hai bên cùng đọc và ký kết. Nếu công ty có bộ phận pháp lý, hãy nhờ kiểm tra hợp đồng trước khi ký.

▸ 3. Phụ lục hợp đồng và quy trình ký thực tế

Với hợp đồng Labo (labor), phần tiền mỗi tháng sẽ được thể hiện trong một phụ lục hợp đồng, và từ đó có thể phát sinh các hợp đồng khác. Về thao tác: hợp đồng được in ra, ký, đóng dấu, scan rồi gửi cho khách qua file PDF; phía Nhật có thể in ra ký và ship bản giấy về. Vì toàn bộ khâu này gắn với pháp lý, hãy tham vấn bộ phận pháp lý để làm cho chặt chẽ.

Chương 5 · Bài 8

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học tổng kết toàn bộ chương báo giá dự án và chia sẻ kinh nghiệm thực chiến của giảng viên. Điểm mấu chốt: báo giá không phải lúc nào cũng phản ánh đúng chi phí thật để làm dự án, mà là một bài toán cân bằng giữa việc trúng thầu (bám sát budget khách hàng) và giữ được lợi nhuận cho công ty.

─── SAU BÀI HỌC, BẠN SẼ

• Hệ thống lại các bước và điểm lưu ý khi làm báo giá đã học trong chương.
• Hiểu vì sao báo giá cần cân bằng giữa budget của khách hàng và chi phí thực tế.
• Biết cách ứng xử khi báo giá theo budget khách hàng dẫn tới thua lỗ.

─── NỘI DUNG CHÍNH

▸ 1. Lấy đủ thông tin và nắm budget của khách hàng

Khi làm báo giá, hãy cố gắng thu thập thật nhiều thông tin cần thiết trong quá trình thực hiện. Nếu biết được chi phí (budget) mà khách hàng dự kiến bỏ ra, bạn sẽ dễ đưa ra đối sách phù hợp — báo giá đủ hấp dẫn để trúng thầu mà vẫn nằm trong khả năng chi trả của khách.

▸ 2. Báo giá là bài toán cân bằng

Nhiều khi báo giá không đúng với chi phí thật để làm dự án, mà chỉ mang tính chất phù hợp với budget của khách hàng. Để đấu thầu thành công, bạn không thể lấy con số thực tế đầy đủ ra chào giá. Vì vậy cần cân bằng hai yếu tố: một mặt báo giá sát budget để lấy được dự án, mặt khác tối ưu chi phí bỏ ra trong quá trình làm để giữ lợi nhuận. Chính khoảng chênh này dẫn tới việc phải re-estimation ở phía sau (nội dung của chương tiếp theo).

▸ 3. Khi báo giá theo budget mà bị lỗ

Kinh nghiệm của giảng viên: muốn lấy dự án thì báo giá gần đúng nhất với budget khách hàng rồi nhận dự án về. Nhưng nếu trong quá trình báo giá bạn thấy chào theo budget sẽ thua lỗ, thì đừng cố. Lúc đó hãy báo giá đúng sự thật và cho khách hàng thấy rõ mức chênh lệch, để hai bên cùng nhìn nhận đúng vấn đề.

Chương 6 · Bài 1

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học giới thiệu re-estimation — bước kiểm tra lại xem báo giá trước đó có còn phù hợp hay không. Điểm mấu chốt: báo giá ban đầu thường làm gấp và chỉ bám budget khách hàng nên chưa có solution chính xác; re-estimation giúp bạn nhìn nhận lại một cách thực tế để có chiến thuật làm dự án tốt hơn và tối ưu lợi nhuận.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu re-estimation là gì và vì sao nó cần thiết sau khi đã báo giá.
• Nắm bốn yếu tố cần xem xét khi re-estimation: phương án, đội hình, chi phí, rủi ro.
• Ý thức được rằng phát hiện underestimate cần chiến lược recover, không đòi tiền khách hàng ngay.

─── NỘI DUNG CHÍNH

▸ 1. Re-estimation là gì và làm khi nào

Re-estimation là bước kiểm tra lại báo giá trước đó có phù hợp không. Do thời gian báo giá rất gấp, bản thân báo giá thường chỉ cố bám cho đúng budget của khách hàng chứ chưa có solution thật chính xác. Vì vậy giảng viên coi re-estimation là một bước bắt buộc trong quy trình, thường giao cho người quản lý dự án thực hiện.

▸ 2. Bốn yếu tố cần xem xét khi re-estimation

1. Phương án / cách làm: xem lại solution đã giả định lúc báo giá, giờ mới có thời gian verify đúng hay sai.
2. Đội hình thực hiện dự án: lúc chào thầu thường đưa người tốt nhất, nhưng khi làm phải điều chỉnh resource và con người cho phù hợp tình hình để giữ lợi nhuận (đặc biệt với dự án fixed price).
3. Chi phí bỏ ra: đối chiếu chi phí dự tính ban đầu với chi phí thực tế cần bỏ ra (ví dụ dự tính 300 triệu nhưng thực tế cần 400 triệu).
4. Rủi ro và vấn đề: những rủi ro không thể ghi trong báo giá (con người, nội bộ) được đánh giá lại ở bước này để lường trước và phòng ngừa.

▸ 3. Xử lý khi phát hiện underestimate

Đôi khi estimate ban đầu là 10 million nhưng re-estimation ra tới 20 million. Lúc đó cần chiến lược recover phần bị underestimate, chứ không quay ra đòi thêm tiền khách hàng ngay lập tức — vì họ đã trả theo con số cũ và sẽ không chấp nhận. Thay vào đó, dùng các cách xử lý khéo léo phía sau để khách hàng dần hiểu và chấp nhận vấn đề.

Chương 6 · Bài 2

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học giới thiệu bốn yếu tố cốt lõi của quản lý dự án — TIME, COST, SCOPE, QUALITY — và mối ràng buộc giữa chúng qua hình tam giác. Điểm mấu chốt: bạn gần như không thể đạt cả bốn yếu tố cùng lúc; chiến thuật đúng là ưu tiên đúng thứ khách hàng cần nhất thay vì cố làm hoàn hảo mọi mặt.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu quan hệ ràng buộc giữa TIME, COST, SCOPE, QUALITY (tam giác quản lý dự án).
• Biết cách chọn chiến thuật quản lý dựa trên tính chất dự án và mong đợi của khách hàng.
• Nắm định nghĩa thực tế về một dự án thành công.

─── NỘI DUNG CHÍNH

▸ 1. Bốn yếu tố cốt lõi và sự ràng buộc lẫn nhau

TIME, COST, SCOPE, QUALITY là những yếu tố cốt lõi, ảnh hưởng lớn tới nhau. Bạn thường chỉ đạt được khoảng 2 trên 4, đôi khi chỉ 1 trên 4. Ví dụ:

• Muốn cứu tiến độ (TIME) thì phải tăng chi phí (COST) để overtime, và thường phải giảm scope.
• Muốn nâng chất lượng (QUALITY) thì phải tăng chi phí cho nhiều process, quy trình và nhân sự giỏi hơn.
• Muốn giữ tiến độ thì phải hãm không cho scope phình ra.

Vì mọi yếu tố ràng buộc nhau nên chúng tạo thành hình tam giác quản lý dự án.

▸ 2. Chiến thuật: ưu tiên theo mong đợi của khách hàng

Chiến thuật quản lý tùy thuộc rất nhiều vào tính chất dự án và mong đợi (expected) của khách hàng:

• Dự án muốn tạo ấn tượng, "show up" với khách: tập trung vào QUALITY, chấp nhận chi phí đội lên một chút.
• Dự án cần release gấp, khách không quan tâm chi phí: đưa người giỏi vào, cho team overtime để đạt mục tiêu.

Điều cần nhấn mạnh: bạn không phải đảm bảo hết mọi yếu tố, mà phải hiểu khách hàng muốn gì rồi ưu tiên đạt yếu tố đó trước.

▸ 3. Thế nào là một dự án thành công?

Định nghĩa cốt lõi nhất: dự án thành công là dự án mà khách hàng hài lòng và muốn tiếp tục làm với mình ở hợp đồng sau. Một dự án có thể trễ tiến độ, đội chi phí hay bị đánh giá nội bộ chưa tốt, nhưng nếu khách hàng hài lòng với sản phẩm bàn giao thì vẫn là thành công. Ngoài ra còn có góc nhìn internal (đội ngũ sẵn sàng làm tiếp) so với external (kết quả với khách hàng) — hai mặt này không phải lúc nào cũng trùng nhau.

Chương 6 · Bài 3

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học tổng kết chương re-estimation và chia sẻ kinh nghiệm nhận biết khi nào cần re-estimation lại. Điểm mấu chốt: khi dự án đã chạy mà thấy đi sai hướng, đừng cắm đầu chạy tiếp — hãy dừng lại, đong đo đếm lại chi phí còn phải bỏ ra, và dựa vào hai dấu hiệu cảnh báo để biết bản ước lượng có vấn đề hay không.

─── SAU BÀI HỌC, BẠN SẼ

• Hệ thống lại kiến thức re-estimation và các yếu tố cốt lõi cần quản lý trong chương.
• Nhận biết hai dấu hiệu cho thấy re-estimation đang có vấn đề: workload OT liên tục và task chạy sai kế hoạch.
• Biết cách xử lý khi phát hiện dự án đi sai hướng giữa chừng.

─── NỘI DUNG CHÍNH

▸ 1. Dừng lại và re-estimation khi dự án đi sai hướng

Kinh nghiệm của giảng viên: có những dự án làm được 30-40% mới phát hiện đi sai. Lúc đó cần pause lại, đong đo đếm lại và nhìn nhận thực tế xem còn phải bỏ ra bao nhiêu chi phí để hoàn thành — thay vì cứ cắm đầu chạy theo kế hoạch cũ đã sai.

▸ 2. Hai dấu hiệu cho thấy re-estimation có vấn đề

1. Workload của team: nếu team cứ phải OT liên tục để cover dự án, đó là dấu hiệu bản ước lượng đã sai.
2. Task chạy không đúng kế hoạch: task lúc trễ, lúc sớm, không khớp với kế hoạch đề ra — nghĩa là việc lập kế hoạch chưa sát thực tế.

Nếu bạn đã re-estimation ngay giai đoạn đầu (sau khi kick-off) mà vẫn thấy hai dấu hiệu này, hãy thực hiện re-estimation thêm một lần nữa.

▸ 3. Các khóa học quản lý dự án để tham khảo

Giảng viên giới thiệu ba khóa học liên quan để học viên tham khảo:

1. Quản lý dự án trong công ty phần mềm (kiến thức nền, từ cơ bản).
2. Ứng dụng Excel để quản lý dự án.
3. Ứng dụng Google Sheets để quản lý dự án.

Danh sách khóa học có thể truy cập qua QR code / link đính kèm trong video.

Chương 7 · Bài 1

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học tổng kết lại toàn bộ hành trình của khóa học ước lượng và báo giá dự án phần mềm, điểm lại những nội dung chính đã học và nhắc cách nhận hỗ trợ từ giảng viên sau khóa học.

─── SAU BÀI HỌC, BẠN SẼ

• Hệ thống lại những kiến thức cốt lõi đã học qua các chương.
• Nhớ vai trò quan trọng của re-estimation trong việc nhìn nhận đúng effort của dự án.
• Biết cách tham gia group hỗ trợ để được giải đáp và tư vấn.

─── NỘI DUNG CHÍNH

▸ 1. Những nội dung đã học

Khóa học đã đi qua sáu phần chính:

1. Các mô hình dự án của công ty gia công phần mềm.
2. Các loại hợp đồng cơ bản trong ngành gia công phần mềm.
3. Các phương pháp ước lượng trong dự án gia công phần mềm.
4. Quy trình các bước báo giá cho công ty Nhật.
5. Cách thực hiện re-estimation cho một dự án — được nhấn mạnh nhiều lần vì giúp nhìn nhận đúng effort thực sự phải bỏ ra.
6. Kinh nghiệm thực tế được chia sẻ ở mỗi phần học.

▸ 2. Nhận hỗ trợ sau khóa học

Khi quên hoặc chưa nắm hết nội dung, bạn có thể vào group hỗ trợ học để hỏi. Trong quá trình làm thực tế, nếu gặp vấn đề cần tư vấn, giảng viên vẫn hỗ trợ qua group. Điều kiện là bạn join vào group học để giảng viên biết bạn là học viên của khóa này thì mới trả lời được.

Chương 7 · Bài 2

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học giới thiệu các khóa học và sản phẩm khác của giảng viên để bạn tham khảo và học thêm sau khi hoàn thành khóa này, cùng cách truy cập chúng qua các đường link đính kèm.

─── SAU BÀI HỌC, BẠN SẼ

• Biết nơi tìm các khóa học khác của giảng viên (Udemy, gói combo, website).
• Nắm được các nhóm chủ đề khóa học đang có để chọn hướng học tiếp phù hợp.
• Biết giảng viên còn có các công cụ hỗ trợ quản lý dự án để tham khảo.

─── NỘI DUNG CHÍNH

▸ 1. Ba kênh tham khảo khóa học

Giảng viên để sẵn ba đường link:

1. Link Udemy — dành cho bạn đang dùng tài khoản Udemy hoặc Udemy Business.
2. Link combo — các gói combo gộp nhiều khóa theo nhu cầu học viên.
3. Website của giảng viên — nơi tổng hợp thông tin.

▸ 2. Các nhóm khóa học đang có

Trên Udemy, giảng viên có nhiều khóa thuộc các chủ đề: quản trị dự án, ứng dụng Excel và Google Sheets trong quản lý dự án, và AI for Developer — tận dụng AI để làm việc hiệu quả hơn (ứng dụng được cả cho người non-tech).

▸ 3. Công cụ và sản phẩm sắp ra mắt

Giảng viên đang xây dựng thêm một số kit và sản phẩm, dự kiến ra mắt trong năm 2026 và sẽ chia sẻ cho học viên. Hiện đã có nhiều công cụ phục vụ quản lý dự án như công cụ khảo sát test case, công cụ lấy dữ liệu từ Redmine.

Chương 7 · Bài 3

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học giới thiệu chương trình coaching 1-1 dành cho học viên muốn được hướng dẫn trực tiếp để giải quyết bài toán thực tế của mình, kèm quà tặng cuối khóa và cách nhận hỗ trợ tiếp theo từ giảng viên.

─── SAU BÀI HỌC, BẠN SẼ

• Biết chương trình coaching 1-1 phù hợp với ai và diễn ra như thế nào.
• Nắm cách nhận quà tặng: tài khoản Redmine thực hành miễn phí.
• Biết cách tiếp tục nhận tư vấn từ giảng viên sau khóa học.

─── NỘI DUNG CHÍNH

▸ 1. Coaching 1-1 dành cho ai

Chương trình sinh ra từ nhu cầu của nhiều học viên muốn học trực tiếp để giải quyết bài toán thực tế đang gặp. Bạn có thể tham khảo chi tiết qua link hoặc QR code trong bài — khi quét vào sẽ mở file giới thiệu chương trình.

▸ 2. Cách chương trình diễn ra

Với coaching mùa 1: mỗi tuần trao đổi 2 buổi, mỗi buổi khoảng 1 đến 1,5 tiếng, thường khoảng 1 tháng rưỡi là hoàn thành. Nội dung tập trung giải quyết bài toán trực tiếp của bạn và bổ sung kiến thức còn thiếu; giảng viên hướng dẫn chi tiết và quay lại video. Lịch được sắp xếp linh hoạt, ưu tiên theo lịch của học viên.

▸ 3. Quà tặng và hỗ trợ sau khóa học

Đăng ký qua form sẽ được tặng tài khoản Redmine thực hành miễn phí do giảng viên tự dựng, cùng một số hệ thống khác để tham khảo. Sau khóa học, khi cần hỏi hay tư vấn, bạn vẫn có thể nhắn tin và giảng viên sẽ phản hồi (đôi lúc bận thì trả lời chậm hơn một chút).

Chương 7 · Bài 4

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học là lời cảm ơn khép lại khóa học, đồng thời giới thiệu các dịch vụ và kênh hỗ trợ miễn phí của giảng viên để bạn tiếp tục học tập, thực hành và cập nhật kiến thức sau khóa học.

─── SAU BÀI HỌC, BẠN SẼ

• Biết các kênh giảng viên dùng để hỗ trợ học viên sau khóa học.
• Biết nơi thực hành và tra cứu thêm kiến thức quản lý dự án miễn phí.
• Nắm cách nhận thêm tài liệu, công cụ và coupon được chia sẻ.

─── NỘI DUNG CHÍNH

▸ 1. Các dịch vụ miễn phí đang có

Hầu hết dịch vụ của giảng viên đang miễn phí (riêng hệ thống Learning Management System vẫn đang xây):

• Trang web học: đăng ký tài khoản để truy cập và học thêm những khóa được khuyến mãi.
• Forum: nơi giảng viên đăng lại các câu hỏi Q&A và chia sẻ tài liệu, phần mềm, công cụ hữu ích để học viên không bị "stuck".

▸ 2. Kênh cập nhật và thực hành

• Kênh YouTube và website / blog: chia sẻ tip về chứng chỉ, quản lý dự án, Excel, Google Sheets.
• Trang Redmine: đăng ký tài khoản miễn phí để thực hành quản lý dự án.
• Coupon miễn phí từ group giảng viên Udemy được chia sẻ lại cho học viên.

▸ 3. Sắp có: khu vực thành viên

Giảng viên đang xây dựng một khu vực thành viên tổng hợp nhiều thông tin, template và phần mềm sẵn có để giúp học viên rút ngắn công việc; sẽ được công bố khi hoàn thiện. Cảm ơn bạn đã đồng hành đến hết khóa học.