Hãy hình dung hai mô tả cho cùng một công việc.
Mô tả A:
"Tôi cần một trang web mới. Vui lòng gửi giá và thời gian thực hiện."
Mô tả B:
"Chúng tôi cần một trang web cho công ty cung cấp dịch vụ B2B. Mục tiêu là tăng số lượng yêu cầu có chất lượng. Hiện chúng tôi có 14 trang, nội dung sẵn có và bộ nhận diện hình ảnh. Chúng tôi cần thiết kế và triển khai phiên bản mới, giữ nguyên các địa chỉ hiện tại, hỗ trợ đầy đủ trên thiết bị di động và có tài liệu bàn giao cơ bản. Hệ thống đặt lịch sẽ giữ nguyên và nằm ngoài phạm vi. Chúng tôi muốn bắt đầu vào tháng 10 và đưa trang web vào hoạt động trước cuối tháng 11."
Mô tả thứ hai vẫn chưa trả lời mọi câu hỏi. Nó cũng không áp đặt công nghệ hay cách làm việc.
Nhưng nó tạo cho các chuyên gia một điểm tham chiếu thống nhất hơn nhiều.
Nếu mỗi người đang định giá một phạm vi khác nhau, bạn không so sánh các đề xuất. Bạn đang so sánh những dự án khác nhau có tên gần giống nhau.
Yêu cầu rõ ràng là điều kiện để định giá và so sánh đề xuất có ý nghĩa
Sourcing Playbook hiện hành của Vương quốc Anh nêu rằng một yêu cầu rõ ràng phải cung cấp đủ thông tin để bên dự thầu có thể đưa ra quyết định có hiểu biết về việc có tham gia hay không. Tài liệu cũng chỉ ra rằng khi không có cách hiểu chung về yêu cầu, rất khó liên hệ mức giá được đề xuất với cách người mua hiểu chi phí và kết quả mong muốn. [1]
Government Commercial Function diễn đạt trực tiếp hơn: một yêu cầu tốt cần chứa đủ thông tin để nhà cung cấp tính đúng chi phí hàng hóa hoặc dịch vụ, nhờ đó người mua có thể so sánh các đề xuất trên cơ sở tương đương. [2]
Đồng thời, Digital, Data and Technology Playbook của Anh cảnh báo về việc quy định giải pháp quá chi tiết. Tài liệu khuyến nghị tập trung vào người dùng, vấn đề và kết quả mong muốn, đồng thời để nhà cung cấp có không gian đề xuất cách thực hiện hiệu quả. [3]
Vì vậy, kết luận không phải là "hãy mô tả mọi thứ càng chi tiết càng tốt". Quy tắc tốt hơn là:
mô tả chính xác những gì phải giống nhau trong mọi đề xuất, chứ không phải những gì một chuyên gia có năng lực có thể hợp lý tự thiết kế.
Cần thống nhất điều gì để các đề xuất thực sự có thể so sánh?
Hai đề xuất chuyên nghiệp sẽ không bao giờ hoàn toàn giống nhau và đó cũng không nên là mục tiêu.
Khả năng so sánh nghĩa là các chuyên gia đang trả lời cùng một vấn đề trong những giả định nhìn chung tương tự.
Vì vậy họ nên có hiểu biết gần giống nhau về:
- mục tiêu,
- phạm vi,
- điểm bắt đầu,
- kết quả mong đợi,
- giới hạn quan trọng,
- thời gian,
- trách nhiệm của khách hàng,
- cách trình bày giá,
- tiêu chí dùng để đánh giá đề xuất.
Họ vẫn có thể khác nhau ở:
- cách tiếp cận,
- thứ tự công việc,
- phương pháp,
- cơ cấu nhóm,
- công cụ,
- cách chia giai đoạn,
- cách giảm rủi ro.
Những khác biệt này thường có giá trị và nên được giữ lại để nhìn thấy.
12 thông tin nên có trong mô tả công việc
1. Vấn đề bạn muốn giải quyết
Hãy bắt đầu từ vấn đề, không phải danh sách tính năng.
Thay vì:
"Tôi cần một ứng dụng có bảng tổng quan, thông báo và báo cáo."
hãy thử:
"Hiện năm người đang quản lý quy trình bằng bảng tính và thư điện tử. Rất khó biết trạng thái hiện tại của một vụ việc, ai phụ trách và bước tiếp theo là gì. Chúng tôi muốn giảm theo dõi thủ công và có một nơi duy nhất hiển thị trạng thái cập nhật."
Mô tả thứ hai chưa quyết định ứng dụng nào cần được xây dựng.
Nhưng nó giúp chuyên gia hiểu vì sao dự án tồn tại ngay từ đầu.
2. Kết quả mong đợi
Federal Acquisition Regulation đối với dịch vụ dựa trên kết quả khuyến nghị mô tả công việc chủ yếu bằng kết quả cần đạt thay vì cách thực hiện hoặc số giờ cung cấp. Nội dung tối thiểu của bản mô tả mục tiêu bao gồm những yếu tố như mục đích, phạm vi, bối cảnh, kết quả cần đạt và giới hạn vận hành. [4]
Vì vậy hãy viết điều gì phải trở nên khả thi khi công việc hoàn tất.
Ví dụ:
- người dùng có thể tự hoàn thành một quy trình xác định,
- nhóm có thể xem trạng thái hiện tại của mọi vụ việc,
- khách hàng nhận được phân tích kèm thứ tự ưu tiên,
- hệ thống được chuyển sang môi trường mới và hoạt động theo tiêu chí đã thống nhất,
- tài liệu đã chuẩn bị sẵn sàng để xuất bản trên kênh xác định.
Kết quả phải đủ cụ thể để hai bên hiểu hướng công việc.
Nhưng không nhất thiết phải là bảo đảm một kết quả kinh doanh phụ thuộc vào thị trường, hành vi người dùng hoặc yếu tố khác ngoài khả năng kiểm soát của nhà cung cấp.
3. Tình trạng hiện tại và điểm bắt đầu
Cùng một nhu cầu cuối cùng có thể đòi hỏi lượng công việc rất khác tùy điểm bắt đầu.
Nên nêu:
- hiện đã có gì,
- phần nào đang hoạt động và cần giữ lại,
- phần nào không hoạt động,
- có tệp nguồn hay không,
- có tài liệu hay không,
- có dữ liệu cần chuyển hay không,
- có phải làm trên hệ thống hiện tại hay không,
- tài liệu nào đã sẵn sàng.
"Trang web mới" có thể là xây từ đầu hoặc xây lại trang hiện có trong khi giữ nội dung, địa chỉ, hệ thống đo lường, tích hợp và dữ liệu.
Đó là hai công việc khác nhau ngay cả khi hình thức cuối cùng có thể giống nhau.
4. Phạm vi bắt buộc và ranh giới dự án
Phạm vi không nên buộc chuyên gia phải đoán phần nào của vấn đề họ cần định giá.
Ví dụ:
Trong phạm vi:
- phân tích giải pháp hiện tại,
- thiết kế giao diện mới,
- triển khai,
- chuyển một phần dữ liệu đã xác định.
Ngoài phạm vi:
- tạo nội dung mới,
- mua giấy phép,
- bảo trì sau tháng đầu,
- xây lại hệ thống thanh toán.
Mẫu Terms of Reference của Ngân hàng Thế giới nhấn mạnh rằng yêu cầu và kỳ vọng đối với dịch vụ tư vấn cần được trình bày rõ ràng và điều chỉnh theo dự án cụ thể. [5]
Ranh giới đặc biệt quan trọng khi hai công việc có liên quan tự nhiên và dễ khiến người ta giả định một việc đã bao gồm việc kia.
5. Những thứ cụ thể cần được bàn giao
Nếu bạn mong đợi tài liệu hoặc kết quả cụ thể, hãy gọi tên chúng.
Có thể gồm:
- giải pháp hoạt động,
- tệp nguồn,
- báo cáo,
- tài liệu hướng dẫn,
- thiết kế hình ảnh,
- bộ tài liệu,
- cấu hình môi trường,
- đào tạo,
- bản ghi,
- bàn giao mã và quyền truy cập.
Các từ như "thiết kế", "phân tích" hoặc "triển khai" có thể được hiểu khác nhau.
Danh sách chung về các hạng mục bàn giao chính giúp tránh tình huống một đề xuất bao gồm nhiều hơn hẳn đề xuất khác nhưng khác biệt bị che dưới tên dịch vụ tương tự.
6. Những giới hạn và điều kiện không thể bỏ qua
Không phải giới hạn nào cũng là chi tiết kỹ thuật.
Ví dụ quan trọng có thể gồm:
- hệ thống hoặc môi trường bắt buộc,
- tích hợp bắt buộc với một dịch vụ xác định,
- yêu cầu về khả năng tiếp cận,
- quy định ngành,
- hạn chế về lưu trữ dữ liệu,
- yêu cầu giữ cơ sở hạ tầng hiện có,
- thiết bị hoặc trình duyệt cụ thể,
- làm việc trong giờ xác định,
- hạn chế quyền truy cập dữ liệu.
FAR đưa rõ các giới hạn vận hành vào bản mô tả mục tiêu, trong khi Digital, Data and Technology Playbook của Anh cho thấy không nên áp đặt giải pháp từ trước nếu thực tế không có giới hạn như vậy. [4] [3]
Một quy tắc hữu ích:
hãy nêu điều chuyên gia không thể thay đổi, nhưng đừng biến thói quen dùng một giải pháp thành một giới hạn giả tạo.
7. Tài liệu, quyền truy cập và trách nhiệm của khách hàng
Chuyên gia cần biết mức độ hợp tác nào có thể được dùng làm cơ sở cho đề xuất.
Hãy nêu bạn có cung cấp:
- người ra quyết định,
- quyền truy cập hệ thống,
- tài liệu sẵn có,
- dữ liệu,
- tài khoản thử nghiệm,
- thông tin từ nhóm,
- quyền tiếp cận người dùng,
- nội dung,
- cuộc họp định kỳ,
- phản hồi trong thời gian xác định.
Nếu bạn chưa biết mình có thể cung cấp gì, nói điều đó vẫn hữu ích.
Thiếu quyền truy cập dữ liệu, tài liệu hoặc con người có thể làm thay đổi phương pháp, chi phí và thời gian. Đây không phải chi tiết hành chính nhỏ, mà là một phần điều kiện để xây dựng đề xuất.
8. Thời gian, ngày quan trọng và mức độ linh hoạt
Không phải mọi ngày đều có cùng ý nghĩa.
Hãy phân biệt:
- ngày bắt đầu mong muốn,
- hạn cuối không thể thay đổi,
- ngày gắn với một sự kiện bên ngoài,
- ngày ước tính,
- các giai đoạn phải diễn ra theo một thứ tự nhất định.
Nếu hạn cuối thực sự không thể dịch chuyển, hãy nói lý do.
Nếu linh hoạt, hãy nói rõ điều đó.
Nhờ vậy chuyên gia có thể đề xuất phạm vi, thứ tự hoặc cách chia giai đoạn khác thay vì coi mọi ngày là yêu cầu tuyệt đối.
9. Ngân sách, hoặc ít nhất cách bạn muốn so sánh giá
Không có một quy tắc duy nhất nói rằng khách hàng luôn phải công khai toàn bộ ngân sách.
Tùy tình huống, bạn có thể cung cấp:
- ngân sách tối đa,
- khoảng ngân sách,
- ngân sách cho giai đoạn đầu,
- thông tin rằng bạn muốn đề xuất phạm vi trước rồi mới nhận giá,
- cấu trúc mong muốn khi tách giá.
Để so sánh, quan trọng nhất là các chuyên gia trình bày chi phí theo cấu trúc tương tự.
Ví dụ:
"Hãy tách riêng giá cho phân tích, thiết kế, triển khai và bảo trì hàng tháng. Đồng thời nêu các chi phí dịch vụ bên ngoài chưa bao gồm."
Dạng này dễ so sánh hơn nhiều so với bốn tổng giá trong đó mỗi tổng bao gồm những thứ khác nhau.
10. Những điều chưa biết, giả định và rủi ro quan trọng nhất
Sự không chắc chắn không biến mất chỉ vì không được viết ra.
Nếu bạn chưa biết:
- phải chuyển bao nhiêu dữ liệu,
- giao diện bên ngoài có hỗ trợ thao tác cần thiết hay không,
- toàn bộ nội dung có sẵn sàng hay không,
- mã hiện tại có thể tiếp tục phát triển hợp lý hay không,
- phê duyệt cần thiết có đến đúng hạn hay không,
hãy nói rõ.
Hướng dẫn của GAO về ước tính chi phí đáng tin cậy nhấn mạnh tầm quan trọng của các giả định được nêu rõ và phân tích rủi ro, bất định. [6]
Một chuyên gia tốt sau đó có thể:
- thêm phần dự phòng,
- đề xuất giai đoạn khảo sát ban đầu,
- định giá các phương án,
- chỉ ra điều kiện sẽ làm thay đổi giá,
- từ chối giả vờ đưa ra mức chính xác chưa thể đạt được một cách trung thực.
Điều chưa biết được nêu rõ tốt hơn một giả định bị che giấu.
11. Tiêu chí lựa chọn, không chỉ giá
Nếu bạn đã biết điều gì quan trọng khi quyết định, hãy nói trước khi các đề xuất được chuẩn bị.
Bạn có thể đánh giá:
- mức phù hợp của cách tiếp cận,
- kinh nghiệm với vấn đề tương tự,
- chất lượng bằng chứng từ công việc trước,
- tính thực tế của lịch,
- khả năng sẵn sàng,
- cách quản lý rủi ro,
- năng lực của người thực sự làm dự án,
- giá,
- chi phí bảo trì,
- chất lượng giao tiếp.
Tài liệu hiện hành của Ngân hàng Thế giới về Rated Criteria nêu rằng tiêu chí ngoài giá có thể gồm chất lượng phương pháp và kế hoạch làm việc, quản lý rủi ro, năng lực thực hiện và nhân sự chủ chốt. Tiêu chí được điều chỉnh cho từng hoạt động mua sắm và có trọng số theo mức quan trọng tương đối. [7]
Điều đó không có nghĩa công việc nhỏ cần chấm điểm chính thức.
Chỉ cần trả lời trước khi gửi yêu cầu:
"Ngoài giá, điều gì sẽ khiến một đề xuất tốt hơn đề xuất khác đối với tôi?"
12. Một định dạng trả lời chung
Nếu thực sự muốn so sánh các đề xuất, hãy yêu cầu mọi người trả lời cùng một nhóm câu hỏi cơ bản.
Ví dụ:
1. Bạn hiểu vấn đề và kết quả mong đợi như thế nào?
2. Bạn đề xuất cách tiếp cận nào?
3. Đề xuất của bạn chính xác bao gồm gì?
4. Điều gì bị loại trừ?
5. Bạn đang dựa trên những giả định nào?
6. Lịch thực hiện là gì?
7. Bạn cần gì từ khách hàng?
8. Rủi ro chính là gì?
9. Giá là bao nhiêu và chính xác bao gồm gì?
10. Kinh nghiệm tương tự hoặc bằng chứng công việc nào liên quan đến nhiệm vụ này?
Trong mua sắm công, việc chuẩn hóa câu trả lời, tiêu chí và cách trình bày giá được dùng để có thể đánh giá đề xuất trên cùng cơ sở. Government Commercial Function nhấn mạnh cần cung cấp đủ thông tin cho việc tính chi phí chính xác và so sánh tương đương. [2]
Định dạng chung không nên xóa khác biệt giữa các chuyên gia. Nó chỉ nên làm cho các khác biệt đó xuất hiện ở cùng những vị trí.
Có nên nêu ngân sách không?
Điều này tùy mục đích của yêu cầu.
Chia sẻ ngân sách có thể hữu ích khi:
- phạm vi có thể điều chỉnh theo nguồn lực hiện có,
- bạn muốn được đề xuất phương án tốt nhất trong một giới hạn xác định,
- bạn muốn nhanh chóng loại các đề xuất không phù hợp thực tế tài chính.
Không chia sẻ toàn bộ ngân sách có thể hợp lý khi:
- trước tiên bạn muốn có góc nhìn độc lập về phạm vi phù hợp,
- chưa biết chi phí thực tế,
- đang so sánh các mô hình giải pháp khác nhau,
- quy trình cần cách thu thập giá khác.
Tình huống xấu nhất không nhất thiết là không có ngân sách, mà là không nói rõ bạn mong nhận kiểu câu trả lời về giá nào.
Chuyên gia nên biết cần đưa một tổng giá, một khoảng, các phương án, giá theo giai đoạn hay các giả định cần thiết để ước tính chính xác hơn.
Đừng che giấu điều chưa biết chỉ để mô tả trông chuyên nghiệp hơn
Mô tả công việc tốt không cần trả lời mọi câu hỏi.
Có thể thành thật viết:
- "Chúng tôi chưa biết hệ thống hiện tại có thể mở rộng an toàn hay không.",
- "Chúng tôi chưa biết số lượng chính xác bản ghi cần chuyển.",
- "Chúng tôi chưa quyết định phiên bản ngôn ngữ thứ hai có nằm trong giai đoạn đầu hay không.",
- "Chúng tôi cần hỗ trợ để chọn phương án tốt nhất."
Đó là thông tin có giá trị.
Sự không chắc chắn nên ảnh hưởng cách chuẩn bị đề xuất, chứ không nên biến mất khỏi tài liệu.
Trong một số trường hợp, dịch vụ đầu tiên tốt nhất không phải triển khai toàn bộ mà là giai đoạn khảo sát ngắn kết thúc bằng quyết định, phạm vi chính xác hơn hoặc ước tính đáng tin cậy hơn.
Ví dụ: mô tả ngắn hơn nhưng tạo ra đề xuất tốt hơn
7 lỗi khiến đề xuất khó so sánh
1. Gửi cho mỗi chuyên gia một bộ thông tin khác nhau.
2. Liệt kê tính năng mà không giải thích vấn đề và mục tiêu.
3. Không nói rõ những gì đã tồn tại.
4. Che giấu giới hạn mà sau đó làm thay đổi cách thực hiện.
5. Yêu cầu một giá cuối cùng mà không nói giá đó phải bao gồm gì.
6. Đánh giá đề xuất bằng những tiêu chí mà chính bạn chưa xác định trước.
7. Nhầm mô tả vấn đề chi tiết với việc áp đặt giải pháp chi tiết.
14 câu hỏi trước khi gửi mô tả công việc
1. Tôi đã mô tả rõ vấn đề, không chỉ giải pháp mình tưởng tượng chưa?
2. Kết quả tôi muốn đạt đã rõ chưa?
3. Chuyên gia có hiểu tình trạng hiện tại không?
4. Có rõ những gì cần được giữ lại không?
5. Ranh giới phạm vi đầu tiên đã rõ chưa?
6. Tôi đã nêu các hạng mục bàn giao quan trọng nhất chưa?
7. Tôi đã nêu các giới hạn thực tế chưa?
8. Có rõ tôi sẽ cung cấp gì từ phía mình không?
9. Lịch đã được mô tả cùng mức linh hoạt chưa?
10. Cách trình bày giá có cho phép so sánh đề xuất không?
11. Tôi đã công khai những điều chưa biết quan trọng nhất chưa?
12. Tôi có biết sẽ đánh giá gì ngoài giá không?
13. Tất cả chuyên gia có trả lời nhóm câu hỏi tương tự không?
14. Tôi có để chỗ cho một giải pháp tốt hơn giải pháp mình nghĩ ra không?
Mô tả tốt nhất không nói với chuyên gia mọi thứ. Nó nói mọi thứ họ cần biết
Mô tả công việc tốt có hai mục tiêu tưởng như đối lập.
Nó phải đủ cụ thể để nhiều chuyên gia định giá cùng một vấn đề.
Đồng thời phải đủ mở để mỗi người có thể đề xuất cách riêng, có thể tốt hơn.
Một thứ tự hữu ích là:
vấn đề -> kết quả -> tình trạng hiện tại -> phạm vi -> hạng mục bàn giao -> giới hạn -> trách nhiệm khách hàng -> lịch -> cách trình bày giá -> điều chưa biết và rủi ro -> tiêu chí lựa chọn -> định dạng trả lời chung.
Nếu sau khi nhận đề xuất, bạn phát hiện một người định giá toàn bộ dự án, người khác chỉ định giá phân tích, còn người thứ ba giả định thêm tích hợp, vấn đề có thể không nằm ở mức giá.
Có thể mỗi người đã nhận một nhiệm vụ khác nhau, dù tất cả đều được gửi cùng một đoạn văn.
Nguồn và tài liệu đọc thêm
[1] UK Government - The Sourcing Playbook
Mở nguồn
[2] Government Commercial Function - How to write a procurement specification
Mở nguồn
[3] UK Government - The Digital, Data and Technology Playbook
Mở nguồn
[4] U.S. Federal Acquisition Regulation - Subpart 37.6, Performance-Based Acquisition
Mở nguồn
[5] World Bank - Sample Consultants Terms of Reference
Mở nguồn
[6] U.S. Government Accountability Office - Cost Estimating and Assessment Guide, GAO-20-195G
Mở nguồn
[7] World Bank - Rated Criteria
Mở nguồn
Ghi chú phương pháp: các nguồn chủ yếu đến từ bối cảnh mua sắm công và quản lý chi phí. Chúng không được trình bày như quy tắc trực tiếp cho thị trường chuyên gia tư nhân. Bài viết chỉ sử dụng các nguyên tắc được nguồn thực sự hỗ trợ: yêu cầu rõ ràng, tập trung vào kết quả, công khai giả định và rủi ro, thông tin giá có thể so sánh và đánh giá chất lượng bằng tiêu chí ngoài giá.
Tìm chuyên gia đã xác minh mà không phải đoán mò.
Kỹ năng, dịch vụ, giá và lịch trống có thể hiển thị ngay cả trước khi bạn mở hồ sơ.
