Khi doanh nghiệp nhỏ thuê một công ty bên ngoài làm phần mềm, có ba thứ bảo vệ mình hơn mọi thứ khác: bản mô tả yêu cầu viết bằng những việc làm thật, thanh toán gắn với từng phần giao mà chính mình đã kiểm thử, và hợp đồng ghi rõ mình nhận mã nguồn, tài khoản quản trị, dữ liệu và tài liệu khi bàn giao. Phần lớn tranh chấp đau đầu đến từ việc để mơ hồ một trong ba điều này, chứ không phải do bên nào có ý xấu.
Có thật sự cần phần mềm viết riêng không?
Trước khi gặp bất kỳ công ty phần mềm nào, nên tự hỏi mình có thật cần viết riêng không. Phần mềm làm sẵn, thuê theo tháng, đã lo được gần hết nhu cầu thông thường của doanh nghiệp nhỏ: bán hàng, kho, kế toán, đặt lịch, hồ sơ khách. Nó rẻ hơn, dùng được ngay, và có người khác lo bảo trì.
Viết riêng chỉ hợp trong những trường hợp hẹp hơn. Quy trình của mình khác thường và là chìa khoá để giành khách. Mình cần nối mấy hệ thống đang có theo cách mà không kết nối chuẩn nào hỗ trợ. Hoặc mình đang làm một sản phẩm để bán, tức phần mềm chính là việc kinh doanh.
Còn một đường giữa mà nhiều công ty nhỏ bỏ qua: dùng hệ thống làm sẵn, viết thêm vài phần nhỏ như một báo cáo đặc biệt, một công cụ nhập dữ liệu hay một kết nối với đối tác. Những dự án này nhỏ hơn, dễ mô tả hơn và ít rủi ro hơn nhiều so với làm từ con số không.
Nếu đã chắc viết riêng là đáng, phần còn lại của bài này dành cho mình. Nếu còn phân vân, một giờ ngồi với người tư vấn độc lập, không bán dịch vụ lập trình, thường là khoản tiền đáng bỏ.
Một ví dụ: cái app đặt lịch suýt hỏng
Thử hình dung một trung tâm ngoại ngữ ba cơ sở muốn có app riêng để đặt lịch học và buổi học thử. Chủ trung tâm tìm được một công ty qua người quen, kể ý tưởng trong một buổi gặp, nhận báo giá một trang với đúng một con số, rồi ký. Một nửa số tiền trả trước.
Ba tháng sau bản đầu tiên ra lò. Trông đẹp, nhưng không xử lý được điều quan trọng nhất: giáo viên dạy ở nhiều cơ sở với thời khoá biểu thay đổi liên tục. Bên làm bảo đó là "yêu cầu mới". Chủ trung tâm bảo chuyện đó hiển nhiên. Không ai chứng minh được mình đúng, vì ngoài trang báo giá ra chẳng có gì được viết lại.
Dự án được cứu, nhưng tốn thêm tiền. Hai bên ngồi lại viết ra cái lẽ ra phải có từ đầu: danh sách vai trò người dùng, việc chính của từng vai, ví dụ các ca khó như giáo viên chuyển cơ sở giữa tuần, và bài kiểm thử nghiệm thu cho từng việc. Lịch thanh toán được sắp lại theo từng phần đã nghiệm thu.
Bài học không phải bên làm gian hay chủ trung tâm cẩu thả. Một ý tưởng nói miệng đơn giản là mỗi người hiểu một kiểu. Viết ra giấy, kèm ví dụ, là khoản bảo hiểm rẻ nhất trong mọi dự án phần mềm.
Viết bản mô tả yêu cầu để bên làm báo giá cho đúng
Bản mô tả tốt viết bằng ngôn ngữ kinh doanh, không phải ngôn ngữ kỹ thuật. Nó tốn vài ngày, không phải vài tháng.
- Nêu vấn đề và mục tiêu. Hiện giờ cái gì đang trục trặc, ai khổ vì nó, và khi phần mềm chạy được thì điều gì sẽ khác.
- Kê ra người dùng và việc của từng người. Ví dụ: khách đặt buổi học thử, lễ tân xác nhận, giáo viên xem lịch dạy, quản lý xem điểm danh.
- Viết ra các ca khó. Ngoại lệ là chỗ giấu chi phí và tranh cãi: huỷ lịch, hoàn tiền, một người kiêm hai vai, lúc mất mạng.
- Ghi rõ những gì đang có. Phần mềm hiện dùng, dữ liệu phải nhập sang, hệ thống mà cái mới phải nối vào.
- Tách cái bắt buộc khỏi cái có thì tốt. Đánh dấu rõ bản đầu tiên không thể thiếu gì, và cái gì để sau được.
- Nêu các ràng buộc. Nhân viên dùng thiết bị gì, cần ngôn ngữ nào, khoảng bao nhiêu người dùng, hạn chót nào gắn với lịch kinh doanh.
- Đề nghị các bên trả lời theo đúng khung đó. Như vậy báo giá mới so được với nhau, và lộ ra bên nào thật sự đọc bản mô tả.
Các kiểu tính giá phổ biến và khi nào hợp
Không kiểu nào luôn tốt nhất. Mấu chốt là chọn kiểu khớp với mức độ mình mô tả được công việc ở thời điểm hiện tại.
| Kiểu | Cách tính | Hợp khi | Rủi ro chính |
|---|---|---|---|
| Trọn gói | Một tổng tiền cho một phạm vi đã thống nhất | Phạm vi nhỏ, rõ, ít khả năng đổi | Đổi gì cũng thành cãi nhau hoặc phát sinh; bên làm có thể làm ẩu để giữ lãi |
| Theo thời gian thực làm | Trả theo giờ, ngày công thực tế với đơn giá đã thống nhất | Phạm vi sẽ thay đổi và mình theo sát được tiến độ | Chi phí phình nếu không ai giữ thứ tự ưu tiên |
| Trọn gói từng giai đoạn | Chia nhỏ giai đoạn trọn gói, xong giai đoạn trước mới chốt giai đoạn sau | Dự án vừa, còn chút chưa chắc chắn | Cần kỷ luật để mô tả kỹ từng giai đoạn |
| Phí duy trì hằng tháng | Một khối lượng công việc cố định mỗi tháng | Bảo trì và cải tiến nhỏ sau khi chạy | Trả cho phần không dùng tới; đầu ra mơ hồ |
| Chia doanh thu hoặc cổ phần thay phí | Bên làm được trả từ thu nhập tương lai hoặc phần sở hữu | Hiếm khi hợp với hệ thống của doanh nghiệp nhỏ | Quyền sở hữu rắc rối, bất đồng về hướng đi |
Với phần lớn doanh nghiệp nhỏ, chia giai đoạn nhỏ trọn gói hoặc tính theo thời gian có kiểm soát chặt thường ổn hơn một cục trọn gói lớn cho một phạm vi mơ hồ.
Những điều khoản hợp đồng nên đọc chậm
Quyền sở hữu mã nguồn. Trả tiền xong thì mã nguồn của ai? Có bên giữ quyền sở hữu và chỉ cấp phép cho mình dùng; điều đó có thể chấp nhận được, nhưng phải biết rõ.
Thành phần của bên thứ ba. Phần mềm thường kèm thư viện hoặc dịch vụ trả phí. Hỏi giấy phép nào áp dụng, sau này ai trả.
Tài khoản và hạ tầng. Máy chủ, tên miền, tài khoản trên kho ứng dụng, tài khoản đám mây phải đứng tên công ty mình, bên làm được cấp quyền vào, chứ không phải ngược lại.
Quyền sở hữu dữ liệu. Mọi dữ liệu kinh doanh và dữ liệu khách nhập vào hệ thống thuộc về mình và phải xuất ra được bất cứ lúc nào.
Tiêu chí nghiệm thu. Thế nào thì coi một phần giao là xong, ai kiểm, mình có bao nhiêu ngày để báo lỗi.
Lịch thanh toán. Thanh toán gắn với phần đã nghiệm thu, khoản trả trước ở mức vừa phải.
Thời gian bảo hành. Sau khi chạy, bên làm sửa lỗi miễn phí trong bao lâu, và thế nào là lỗi, thế nào là yêu cầu thay đổi.
Chấm dứt hợp đồng và bàn giao. Nếu một bên dừng sớm thì mình nhận được gì, trong bao lâu.
Bảo mật và thuê lại. Bên làm có được giao việc cho công ty khác không, và nếu có thì dữ liệu của mình được bảo vệ thế nào.
Nghiệm thu: kiểm trước rồi mới trả tiền
Nghiệm thu đơn giản là phía mình tự kiểm xem phần giao có làm đúng điều đã thống nhất không. Không cần biết kỹ thuật, chỉ cần kiên nhẫn và ví dụ thật.
- Viết kịch bản kiểm từ bản mô tả. Mỗi việc của người dùng thành một kịch bản ngắn: "lễ tân đặt buổi học thử cho khách mới trên điện thoại".
- Đưa cả ca khó vào. Thử huỷ lịch, nhập sai, hai người cùng sửa một lúc, mạng chậm.
- Thử trên đúng thiết bị nhân viên dùng. Cái điện thoại rẻ nhất và cái máy tính văn phòng cũ nhất, không chỉ cái laptop của bên làm.
- Dùng dữ liệu gần thật. Một bản sao dữ liệu thật, ẩn bớt thông tin nếu cần, lộ ra những lỗi mà dữ liệu mẫu che mất.
- Ghi lỗi cho rõ. Đã làm gì, mong đợi gì, thực tế ra sao, kèm ảnh chụp màn hình.
- Phân loại lỗi. Lỗi chặn việc phải sửa xong mới nghiệm thu; lỗi nhỏ đưa vào danh sách kèm hạn sửa đã thống nhất.
- Ký nghiệm thu bằng văn bản. Nghiệm thu chính thức từng phần, để hai bên cùng biết cái gì đã xong và khoản thanh toán nào tới hạn.
Nếu hạn chót cứ lùi và chẳng có gì dùng được tới được khâu nghiệm thu, những dấu hiệu nêu trong bài dự án công nghệ đang đốt tiền đã xuất hiện, và đã tới lúc tạm dừng thay vì trả đợt tiền tiếp theo.
Danh sách bàn giao: cuối cùng mình phải cầm những gì
Mã nguồn đầy đủ. Nằm trong kho mã nguồn do công ty mình quản lý, chứ không phải mỗi một file nén gửi qua email.
Quyền quản trị mọi thứ. Máy chủ, cơ sở dữ liệu, tài khoản đám mây, tên miền, tài khoản kho ứng dụng, dịch vụ gửi email.
Tài liệu kỹ thuật. Hệ thống được dựng thế nào, cài lên máy chủ mới ra sao, sao lưu và khôi phục thế nào.
Hướng dẫn sử dụng. Hướng dẫn ngắn cho từng vai trò, dùng được để đào tạo nhân viên mới.
Danh sách dịch vụ bên thứ ba và chi phí. Mọi dịch vụ trả phí mà hệ thống phụ thuộc, kèm ngày gia hạn.
Một bản sao lưu đầy đủ gần nhất. Cả mã nguồn lẫn dữ liệu, đã thử khôi phục ít nhất một lần.
Danh sách lỗi đã biết. Những lỗi bên làm biết mà chưa sửa, để sau này khỏi bị bất ngờ.
Một buổi bàn giao. Buổi hướng dẫn có quay lại, bên làm giải thích hệ thống cho người sẽ bảo trì tiếp.
Sau khi chạy: bảo trì, máy chủ và ai giữ chìa khoá
Ngày chạy chính thức là lúc hệ thống bắt đầu sống, không phải lúc dự án kết thúc. Bản vá bảo mật, sửa lặt vặt, thay đổi từ phía hệ thống đối tác và nhu cầu kinh doanh mới sẽ còn đến đều đều. Quyết từ trước ai lo những việc đó: chính bên làm theo hợp đồng bảo trì, một công ty khác, hay một người đủ sức trong công ty mình.
Chỗ đặt máy chủ cũng phải chọn có chủ đích. Nhiều hệ thống viết riêng chạy trên máy chủ đám mây. Những nguyên tắc chung khi đưa doanh nghiệp lên đám mây áp dụng y như vậy, đã viết trong bài đưa doanh nghiệp nhỏ lên đám mây: tài khoản đứng tên mình, xác thực hai lớp, bản sao lưu mình tự giữ, phân rõ trách nhiệm.
Giữ một bản ghi đơn giản ai có quyền vào đâu, vài tháng rà lại một lần. Lập trình viên đến rồi đi, quyền truy cập của họ không được ở lại.
Cuối cùng, tính ngân sách bảo trì ngay từ đầu. Một hệ thống viết riêng không ai bảo trì sẽ dần lỗ hổng và không chạy được trên thiết bị mới. Một khoản bảo trì hằng năm vừa phải là một phần của chi phí thật khi làm phần mềm.
Những sai lầm hay gặp khi thuê bên làm
Chọn chỉ vì giá. Báo giá rẻ nhất thường phản ánh sự hiểu việc ít nhất, và phần chênh sẽ quay lại dưới dạng phát sinh.
Trả phần lớn tiền trước. Mình mất đòn bẩy chính khi chất lượng hay tiến độ trượt.
Để bên làm đứng tên mọi thứ. Tên miền và máy chủ đứng tên bên làm có thể biến một bất đồng thành cảnh bị nắm thóp.
Không tự kiểm thử. Nghiệm thu vì demo trông ổn thì lỗi sẽ để nhân viên mình tự phát hiện.
Không có một người cầm quyết định. Mấy quản lý cùng dặn bên làm mỗi người một kiểu thì dự án trôi và chi phí tăng.
Ý tưởng nào cũng gấp. Thêm yêu cầu giữa chừng mà không có danh sách ưu tiên là cách nhanh nhất để ngân sách gấp đôi.
Quên tính chuyện kết thúc. Không có điều khoản bàn giao thì chấm dứt hợp tác có thể đồng nghĩa mất quyền vào chính hệ thống của mình.
Nhờ người quen làm mà không có hợp đồng. Làm miệng thấy dễ, nhưng khi kỳ vọng hai bên lệch nhau thì cả hai đều không có gì để dựa.
Khi nào nên mời luật sư hoặc người thẩm định độc lập
Nên nhờ luật sư trước khi ký bất kỳ hợp đồng nào có giá trị lớn so với quy mô công ty, có điều khoản cho bên làm giữ quyền sở hữu mã nguồn, hoặc có phần chấm dứt hợp đồng và dữ liệu viết mơ hồ. Các câu hỏi ở trên là điểm khởi đầu tốt cho luật sư, nhưng không phải tư vấn pháp lý; luật hợp đồng và sở hữu trí tuệ cần đối chiếu với quy định hiện hành.
Một người thẩm định kỹ thuật độc lập, tức người có kinh nghiệm lập trình nhưng không thuộc bên làm, rất đáng giá ở ba thời điểm: khi so các báo giá, khi dự án lớn đi được nửa chặng, và khi bàn giao. Họ cho mình biết mã nguồn có được tổ chức tử tế không, tài liệu có dùng được không, hệ thống có dựa vào thành phần mong manh hay đắt đỏ nào không.
Kế toán nên xem cách ghi nhận các khoản thanh toán, hoá đơn và việc hạch toán phần mềm, cũng như hệ thống có xuất ra được các chứng từ cần cho việc kê khai thuế hay không.
Nếu lỡ có tranh chấp, hãy gom bản mô tả yêu cầu, email, biên bản kiểm thử, biên bản nghiệm thu trước khi ngồi lại nói chuyện. Tranh chấp dễ giải quyết hơn hẳn khi hai bên cùng nhìn vào một bộ giấy tờ thay vì vào trí nhớ về một buổi họp.
Câu hỏi thường gặp
Nên thuê công ty phần mềm trong nước hay nước ngoài?
Công ty trong nước dễ gặp mặt, hiểu cách làm ăn trong nước và thường hỗ trợ người dùng Việt tốt hơn. Đội nước ngoài có thể mạnh ở kỹ năng riêng nhưng thêm vướng múi giờ và ngôn ngữ. Với hệ thống của doanh nghiệp nhỏ, độ rõ ràng của bản mô tả quan trọng hơn vị trí địa lý.
Nên trả trước bao nhiêu?
Đủ để thể hiện cam kết và trang trải phần việc đầu, nhưng đủ nhỏ để mình còn giữ đòn bẩy. Phần lớn tiền nên trả theo các phần đã nghiệm thu. Cơ cấu cụ thể thì bàn với bên làm và, với hợp đồng lớn, hỏi thêm luật sư.
Bên làm không chịu giao mã nguồn thì sao?
Trước hết xem hợp đồng nói gì về quyền sở hữu và bàn giao. Nếu hợp đồng không nhắc hoặc viết mơ hồ, hỏi luật sư trước khi làm căng. Đây chính là lý do phải chốt quyền sở hữu và bàn giao trước khi ký.
Chủ doanh nghiệp không rành kỹ thuật có quản lý được dự án phần mềm không?
Được, nếu tập trung vào thứ mình rành nhất: các việc kinh doanh, các ca khó, và kiểm thử cùng nhân viên thật. Phần đánh giá kỹ thuật có thể mượn của người thẩm định độc lập ở những thời điểm then chốt.
Có thời gian bảo hành rồi thì khỏi cần hợp đồng bảo trì?
Không. Bảo hành chỉ lo lỗi của phần đã giao trong một thời hạn. Bảo trì lo bản vá bảo mật, thay đổi từ các hệ thống khác và cải tiến nhỏ suốt vòng đời phần mềm.
So sánh các báo giá trông khác hẳn nhau thế nào?
Đề nghị bên nào cũng trả lời theo bản mô tả của mình, từng việc một, ghi rõ giả định và phần không bao gồm. Khác biệt ở phần không bao gồm thường giải thích chênh lệch giá rõ hơn là đơn giá theo giờ.
