Một bản RFP phần mềm, tức yêu cầu chào giải pháp, lẽ ra phải làm cho các nhà cung cấp trở nên so sánh được với nhau. Phần lớn lại đạt kết quả ngược lại, vì chúng mô tả một giải pháp đủ chi tiết để trói buộc câu trả lời, trong khi bỏ sót đúng những thông tin mà bất kỳ ai cũng cần để tính ra con số. Kết quả là năm bản báo giá cách nhau cả một bậc độ lớn, tất cả đều hợp lệ về hình thức, và không bản nào đo cùng một thứ.

Chẩn đoán quen thuộc là nhà cung cấp đang né tránh. Thỉnh thoảng đúng như vậy. Nhưng thường xuyên hơn nhiều, tài liệu đã hỏi một con số mà chính nội dung của nó không cho phép tính ra, và mỗi nhà cung cấp lấp chỗ trống bằng một bộ giả định khác nhau.

Phép thử xem RFP của bạn có hiệu quả hay không: hai nhà cung cấp khác nhau đọc nó có cùng đi tới một phạm vi công việc gần như giống nhau không? Nếu tài liệu chỉ ghi “quản lý người dùng” mà không nói có bao nhiêu vai trò, quyền có thay đổi theo từng bản ghi hay không, hay có phải nối vào một thư mục người dùng sẵn có hay không, thì bên này báo một tuần còn bên kia báo hai tháng. Cả hai đều trả lời trung thực. Còn bạn thì không thể so sánh.

Vì sao danh sách tính năng là điểm khởi đầu sai

Một danh sách tính năng cho nhà cung cấp biết bạn đã quyết định gì, chứ không phải bạn cần gì. Điều đó quan trọng, vì quyết định ấy có thể sai, và người nhìn ra cái sai lại không có chỗ nào để nói trong cấu trúc mà bạn áp đặt.

Nó còn che mất chính những thông tin quyết định chi phí. Công sức làm phần mềm nằm ở các phần khó chịu: phải nối vào bao nhiêu hệ thống bên ngoài, phải chuyển bao nhiêu dữ liệu cũ và dữ liệu đó sạch đến đâu, có bao nhiêu loại người dùng khác nhau với quyền khác nhau, và nghĩa vụ tuân thủ là gì. Một danh sách tính năng có thể rất dài mà không chứa điều nào trong số đó.

Phương án thay thế không phải là nói mơ hồ. Hãy mô tả vấn đề thật chính xác, nêu rõ những ràng buộc thực sự cố định, và để bản đề xuất tự giải thích cách tiếp cận. Bạn sẽ nhận về các câu trả lời khác nhau, và khác biệt đó mang thông tin thay vì chỉ là nhiễu.

Một bản RFP phần mềm thực sự nên có gì

Vấn đề kinh doanh và định nghĩa thành công. Hiện nay điều gì đang xảy ra, thay vào đó điều gì nên xảy ra, và bạn dựa vào đâu để biết là đã thành công. Nhà cung cấp dùng phần này để phản biện phạm vi, việc giá trị nhất họ làm được lúc này.

Sản lượng và quy mô, kèm con số. Người dùng, giao dịch, bản ghi, mức tăng trưởng dự kiến. Riêng điều này đã xóa bỏ phần lớn độ chênh giữa các báo giá.

Các hệ thống phải kết nối, nêu đích danh, kèm ghi chú hệ thống nào có API tài liệu hóa. Chỉ một tích hợp với hệ thống cũ không tài liệu cũng có thể tốn hơn toàn bộ phần còn lại.

Dữ liệu bạn đang có. Bao nhiêu, nằm ở đâu và sạch đến mức nào. Chuyển đổi dữ liệu luôn là hạng mục bị đánh giá thấp nhất trong mọi dự án.

Những ràng buộc thực sự cố định. Nghĩa vụ pháp lý, nơi đặt máy chủ bắt buộc, hệ định danh sẵn có, mốc thời gian không dời được. Hãy nói rõ cái nào cứng, cái nào chỉ là mong muốn, vì ràng buộc cứng luôn bị báo giá phòng thủ.

Những gì bạn không yêu cầu. Loại trừ rõ ràng là cách rẻ nhất để thu hẹp độ chênh giữa các báo giá.

Khoảng ngân sách của bạn. Giấu nó đi không làm giá thấp xuống. Nó chỉ tạo ra các đề xuất cắt theo một ngân sách không ai biết, rồi phải làm lại. Một khoảng công bố cho phép nhà cung cấp nói cái gì khả thi bên trong đó. Hướng dẫn chi phí phát triển phần mềm tùy chỉnh nói rõ từng mức mua được gì.

Những câu hỏi tách bạch các nhà cung cấp

Hãy hỏi ít hơn nhưng hỏi hay hơn. Mấy câu này lộ ra nhiều hơn một ma trận tuân thủ cả trăm dòng.

Anh sẽ xây phần nào trước, và vì sao? Thứ tự triển khai cho thấy họ hiểu vấn đề hay chỉ hiểu tài liệu.

Phần rủi ro nhất là gì và anh sẽ giảm rủi ro bằng cách nào? Nhà cung cấp gọi tên được một rủi ro thật thì đáng tin hơn nhà cung cấp báo rằng không có rủi ro nào.

Cụ thể ai sẽ làm việc này? Tên người, mức kinh nghiệm, và bao nhiêu phần thời gian của họ. Một đề xuất do những người sẽ không xây nó viết ra là nỗi thất vọng rất quen thuộc.

Khi phạm vi thay đổi thì sao? Nó sẽ thay đổi. Câu trả lời cho bạn biết mối quan hệ vận hành thế nào lúc căng thẳng, và điều đó quan trọng hơn đơn giá ngày công.

Anh cần gì từ phía chúng tôi? Dự án đổ vỡ vì phía khách hàng không bố trí được người ít nhất cũng thường xuyên như vì năng lực nhà cung cấp, và ai nói ra điều đó là đang mô tả thực tế chứ không phải đang bán hàng.

Kết thúc dự án chúng tôi sở hữu những gì? Mã nguồn, hạ tầng, tài khoản, dữ liệu. Hãy chốt bằng văn bản trước khi chọn thầu chứ đừng sau đó.

Đọc các bản hồi đáp

Báo giá rẻ nhất thường phản ánh cách hiểu hẹp nhất về phạm vi, chứ không phải hiệu suất cao nhất, và khoảng hụt đó sẽ lộ ra dưới dạng các yêu cầu thay đổi ngay khi công việc bắt đầu.

Hãy nhìn xem mỗi nhà cung cấp dồn công sức vào đâu. Bản đề xuất dành phần lớn dung lượng cho tích hợp và chuyển đổi dữ liệu là bản đã hiểu chỗ khó nằm ở đâu. Bản dành dung lượng cho phương pháp luận và ảnh chụp đội ngũ là bản chưa hề chạm vào vấn đề.

Hãy coi những phản biện không được yêu cầu là tín hiệu tốt. Nhà cung cấp nói rằng một phần phạm vi của bạn là thừa, hoặc một ràng buộc bạn nêu ra sẽ tốn hơn giá trị nó mang lại, chính là đang làm đúng việc bạn muốn. Nhà cung cấp đồng ý với mọi thứ thì dễ đọc hơn nhưng làm việc cùng lại tệ hơn.

Và hãy kiểm tra xem mọi báo giá có đang trả lời cùng một câu hỏi hay không. Chỗ nào hai bản chênh nhau gấp ba lần, chỗ đó một bản đã giả định điều mà tài liệu không hề nói, và tìm ra bản nào hữu ích hơn mọi bảng chấm điểm.

Khi nào không nên làm RFP

Nếu công việc nhỏ, hoặc mang tính thăm dò, hoặc bạn chưa biết mình cần gì, thì RFP là công cụ sai. Nó lấy đi vài tuần của cả hai bên và tạo ra một cảm giác chính xác giả tạo.

Với những trường hợp đó, một giai đoạn khảo sát có trả phí thường tốt hơn: một phần việc ngắn tạo ra bản đặc tả để bạn mang ra thị trường, hoặc kết luận rằng thứ này không đáng xây. Kết quả nào cũng hơn việc đấu thầu trên một phạm vi không ai định nghĩa nổi. Kỷ luật khoanh vùng phạm vi trong hướng dẫn phát triển MVP của chúng tôi áp dụng được ngay ở đây.

Mecanik vừa trả lời RFP vừa giúp các tổ chức viết ra chúng, như một phần công việc phát triển phần mềm của chúng tôi. Những tài liệu tạo ra báo giá tốt luôn là những tài liệu ngắn hơn và có con số thật ở trong.

Câu hỏi thường gặp

Một bản RFP phần mềm nên có những gì? Vấn đề kinh doanh và định nghĩa thành công, sản lượng và quy mô kèm con số thật, tên cụ thể các hệ thống phải tích hợp và việc mỗi hệ thống có API tài liệu hóa hay không, tình trạng dữ liệu cần chuyển đổi, những ràng buộc thực sự cố định, những gì rõ ràng nằm ngoài phạm vi, và một khoảng ngân sách.

Tôi có nên ghi ngân sách vào RFP không? Có. Giấu ngân sách không làm giá thấp xuống, nó tạo ra các đề xuất cắt theo một ngân sách không ai biết rồi sau đó phải làm lại. Một khoảng được công bố cho phép nhà cung cấp nói cho bạn biết cái gì thực sự khả thi bên trong đó và làm cho các bản hồi đáp so sánh được với nhau.

Vì sao báo giá cho cùng một phần mềm lại chênh nhau nhiều đến vậy? Thường là vì tài liệu để lại chỗ trống và mỗi nhà cung cấp lấp chúng bằng giả định khác nhau. Một dòng như “quản lý người dùng”, không nói rõ số vai trò, quyền theo từng bản ghi hay việc nối vào thư mục người dùng, hoàn toàn có thể được báo giá trung thực ở mức một tuần hoặc hai tháng. Độ chênh là thuộc tính của bản RFP, không phải của nhà cung cấp.

Những câu hỏi nào lộ ra một nhà cung cấp phần mềm tốt? Họ sẽ xây phần nào trước và vì sao, họ coi phần nào rủi ro nhất và giảm rủi ro ra sao, cụ thể ai làm việc và dành bao nhiêu phần thời gian, thay đổi phạm vi được xử lý thế nào, họ cần gì từ bạn, và bạn sở hữu những gì khi kết thúc.

Khi nào tôi không nên dùng RFP? Khi công việc nhỏ, mang tính thăm dò, hoặc bạn chưa định nghĩa được mình cần gì. Đấu thầu trên một phạm vi chưa xác định lấy đi vài tuần của cả hai bên và tạo ra sự chính xác giả tạo. Một giai đoạn khảo sát có trả phí, tạo ra bản đặc tả hoặc kết luận rằng dự án không đáng làm, mới là công cụ đúng.