Đội ngũ từng tự vận hành sản phẩm sẽ làm dự án thuê ngoài khác ở chỗ nào

Làm cho mình và làm cho người khác khác nhau ở đâu

Khi chọn đối tác phát triển phần mềm, chỉ nhìn vào danh mục dự án thì sẽ bỏ sót một điều: đội ngũ đó đã từng tự vận hành thứ họ làm ra hay chưa. Một dự án kết thúc ở khâu nghiệm thu và một sản phẩm được chăm sóc nhiều năm sau khi phát hành để lại kinh nghiệm rất khác nhau. Thứ thay đổi không phải là tay nghề viết mã, mà là cách đội ngũ nhận diện rủi ro. Điều này hiếm khi hiện ra trong báo giá, nên bên đặt hàng phải chủ động hỏi.

Tiêu chí thành công của một dự án giao nhận rất rõ ràng. Bàn giao đúng phạm vi đã thống nhất, đúng hạn, qua được nghiệm thu là xong. Bản thân tiêu chí đó không có gì sai. Chỉ có điều, khi con dấu nghiệm thu được đóng thì quan hệ cũng khép lại, và mọi chi phí phát sinh sau đó không quay về thành bài học của đội làm. Họ không trải qua chuyện hóa đơn máy chủ tự nhiên tăng gấp đôi trong một tháng, không thấy người dùng dừng lại ở màn hình nào rồi nhấc điện thoại lên gọi, không biết nửa năm sau một thư viện ngừng hỗ trợ thì kéo theo những gì sụp đổ.

Sản phẩm của chính mình thì ngược lại. Phát hành không phải là điểm kết thúc mà là điểm bắt đầu. Ngay hôm sau khi đưa phiên bản đầu lên, đội ngũ chờ kết quả duyệt của cửa hàng ứng dụng. Tuần sau, họ vật lộn để tái hiện một lỗi chỉ xảy ra trên vài dòng máy. Tháng sau nữa, họ phát hiện mình đang trả tiền cho một tính năng gần như không ai dùng. Quá trình này không dễ chịu nhưng rất trung thực. Những quyết định trì hoãn cho tiện ở giai đoạn thiết kế sẽ quay lại thành hóa đơn sau vài tháng, và đội ngũ trả bằng tiền của chính mình.

Yeowubie Interaction làm dự án cho khách hàng song song với việc vận hành sản phẩm riêng. onSpots là dịch vụ quản lý chấm công, hỗ trợ đa ngôn ngữ và không giới hạn ở một quốc gia cụ thể. Langtori là dịch vụ kết nối và định vị giữa người học tiếng Hàn và người dạy, hỗ trợ các ngôn ngữ Hàn, Việt và Anh. Chủ thể giảng dạy là các giáo viên cá nhân và tổ chức tham gia nền tảng, còn chúng tôi làm phần kết nối. Job Connect VN là dịch vụ tuyển dụng và tìm việc dành riêng cho thị trường Việt Nam. Ngoài ra còn có Winnie, nền tảng hỗ trợ hộ kinh doanh nhỏ vận hành cửa hàng.

Chúng tôi không ghi ở đây số người dùng hay tỷ lệ quay lại của những sản phẩm này. Hệ đo lường chưa được gắn đầy đủ nên những con số đó chưa nằm trong tay chúng tôi. Nếu bịa ra một con số nghe hợp lý thì chính bài viết bàn về tiêu chí kiểm chứng này sẽ tự đổ. Vì vậy chỉ giữ lại những gì có thể xác minh: chúng tôi đã làm, đã đưa lên cửa hàng ứng dụng và lên web, và hiện vẫn tự chăm sóc chúng.

Cần nói thêm một câu để tránh hiểu nhầm. Chúng tôi không khẳng định đội có sản phẩm riêng thì giỏi hơn đội không có. Nhiều công ty chỉ làm dự án gia công vẫn thiết kế và bàn giao rất tốt. Kinh nghiệm vận hành không phải là thứ hơn kém, nó giống một nhóm cơ khác, và có những dự án cần đúng nhóm cơ đó. Với một trang chiến dịch chỉ chạy vài tuần thì điều này không mấy quan trọng. Ngược lại, với một hệ thống mà công việc hằng ngày của doanh nghiệp sẽ chạy trên đó, việc người làm có hiểu sức nặng của vận hành hay không sẽ quyết định chi phí của ba năm tiếp theo.

Chi phí chỉ lộ ra khi tự vận hành: phát hành, sự cố, hỗ trợ người dùng

Báo giá ghi số màn hình và số tính năng. Nhưng chi phí thực sự phát sinh hằng tháng sau khi dịch vụ chạy lại nằm ở chỗ khác: phát hành và duyệt ứng dụng, xử lý sự cố, trả lời người dùng. Ba khoản này không quy đổi được thành công sức lập trình nên rất dễ biến mất khỏi giai đoạn đề xuất. Đội ngũ từng vận hành sẽ nói về chúng trước.

Bắt đầu từ phát hành. Nếu dự án có ứng dụng di động thì thời gian duyệt phải nằm trong lịch. Có lần được duyệt, có lần bị từ chối, và lý do từ chối nhiều khi không phải tính năng mà là mô tả, ảnh chụp màn hình hay phần giải thích quyền truy cập. Với ứng dụng đa ngôn ngữ, toàn bộ tài liệu này phải chuẩn bị lại theo từng ngôn ngữ. Tất cả những việc đó diễn ra sau khi lập trình đã xong. Một trong những thứ chúng tôi thu được khi vận hành các sản phẩm đã lên cửa hàng là thói quen đưa sẵn thời gian duyệt đi duyệt lại vào lịch ngay từ đầu.

Phát hành cũng không chỉ diễn ra một lần. Web sửa hôm nay thì hôm nay có hiệu lực, còn ứng dụng vẫn nằm trên máy người dùng. Luôn có người ở lại với phiên bản cũ, và máy chủ phải tiếp cả bản cũ lẫn bản mới trong một khoảng thời gian. Khi nào bắt buộc cập nhật, giữ tương thích với bản cũ đến bao giờ, đó không phải sở thích kỹ thuật mà là quyết định kinh doanh. Đội ngũ từng trải qua chuyện này sẽ đặt vấn đề trước khi ký hợp đồng.

Xử lý sự cố là mảng chỉ cần vài câu hỏi là lộ ra mức độ chuẩn bị của đối tác. Nếu dịch vụ chết lúc rạng sáng thì ai biết đầu tiên. Cảnh báo gửi về đâu. Có điểm nào để quay lui không. Có nhật ký để sau đó truy ra chuyện gì đã xảy ra không. Một đề xuất không trả lời cụ thể được những câu này thường có nghĩa là đội ngũ chưa từng hình dung giai đoạn sau phát hành. Ngược lại, đề xuất liệt kê rõ công cụ giám sát, đường đi của cảnh báo và quy trình khôi phục là dấu hiệu cho thấy họ đã ít nhất một lần bị đánh thức lúc ba giờ sáng.

Hỗ trợ người dùng là khoản bị đánh giá thấp nhất. Phần lớn câu hỏi gửi đến không phải lỗi kỹ thuật. Người ta hỏi vì không biết bấm vào đâu, vì dòng hướng dẫn mập mờ, vì không rõ kết quả sẽ được cập nhật lúc nào. Khi tự vận hành, những câu hỏi đó đọc lên giống như biên bản chỉ ra khuyết điểm của chính đội phát triển. Nếu cùng một câu hỏi lặp lại mười lần thì màn hình đó đã được làm sai. Cảm giác này chỉ hình thành ở đội trực tiếp nhận kênh hỗ trợ, khó nảy sinh trong mô hình mà khách hàng nhận hết còn công ty phát triển chỉ nhận phiếu lỗi.

Với dịch vụ phục vụ đồng thời Việt Nam và Hàn Quốc, mảng hỗ trợ còn cộng thêm ngôn ngữ và lệch múi giờ. Cùng một tính năng nhưng cách người phụ trách phía Hàn Quốc đặt câu hỏi khác với cách người dùng Việt Nam đặt câu hỏi, và câu trả lời phải chuẩn bị bằng cả hai thứ tiếng. Đây là một trong những lý do chúng tôi duy trì cách làm việc ở cả hai địa bàn. Thêm một lớp phiên dịch là thêm độ trễ, và độ trễ trong hỗ trợ thường chuyển hóa thành sự khó chịu.

Việc bên đặt hàng có thể làm ngay khá đơn giản: đưa vận hành vào yêu cầu đề xuất một cách rõ ràng. Hãy yêu cầu ghi rõ lịch phát hành và duyệt, kênh liên lạc cùng thời gian phản hồi khi có sự cố, ai tiếp nhận câu hỏi đầu tiên và đường leo thang xử lý. Đội trả lời nghiêm túc phần này và đội chỉ ghi công sức lập trình sẽ tách nhau ngay ở trang đầu tiên.

Vì sao cuộc trò chuyện cắt bớt yêu cầu lại trở nên khả thi

Một tín hiệu phân biệt đối tác tốt xuất hiện ngay trong buổi gặp đầu tiên: họ đề nghị thêm tính năng hay đề nghị bớt đi. Đội ngũ từng vận hành hiểu bằng trải nghiệm rằng mỗi tính năng không phải khoản chi một lần mà là chi phí cố định đi theo suốt vòng đời dịch vụ. Vì vậy họ chủ động nói chuyện cắt giảm trước.

Thêm một tính năng không chỉ làm tăng thời gian lập trình. Số trường hợp phải kiểm thử tăng, số câu chữ phải dịch tăng, số điểm có thể phát sinh câu hỏi tăng, và phạm vi phải kiểm tra lại mỗi lần sửa thứ khác cũng tăng. Với dịch vụ đa ngôn ngữ, một dòng chữ nhân lên thành ba. Phần tăng thêm này không nằm trong hóa đơn đầu tiên mà được chia nhỏ và tính dần trong hai năm.

Nhưng ở bàn đàm phán, nói câu bỏ bớt đi không hề dễ. Trả lời rằng chúng tôi làm được hết bao giờ cũng tiện hơn. Nhận nguyên danh sách yêu cầu rồi nâng báo giá thì xác suất trúng thầu và giá trị hợp đồng cùng tăng. Vấn đề là ai sẽ gánh thứ được tạo ra từ hợp đồng đó về sau. Đội đã tự vận hành sản phẩm của mình từng phải gánh phần đó, nên khi nhìn danh sách yêu cầu họ đếm tổng khối lượng trước.

Với Langtori, chúng tôi đã lặp lại quyết định này nhiều lần. Lĩnh vực học tiếng Hàn có biên độ rất rộng: giáo trình, quản lý tiến độ, sản xuất nội dung, thanh toán và đối soát, muốn vươn tới đâu cũng được. Chúng tôi thu hẹp phạm vi về đúng phần kết nối và định vị giữa người học và người dạy. Việc giảng dạy do các giáo viên cá nhân và tổ chức tham gia nền tảng đảm nhận. Lý do vạch ra ranh giới không phải sự khiêm tốn mà là tính toán vận hành. Ôm càng rộng thì bề mặt phải duy trì càng lớn, và bề mặt càng lớn thì càng khó chăm sóc tử tế bất cứ phần nào.

Cách bên đặt hàng kiểm chứng thái độ này không khó. Hãy đưa danh sách yêu cầu và hỏi trong đó có mục nào nên bỏ khỏi phạm vi giai đoạn một, nếu có thì vì sao. Câu trả lời sẽ rẽ thành ba nhánh: đội nói mọi thứ đều cần, đội đề nghị bỏ bừa mà không có căn cứ, và đội giải thích tính năng nào sinh ra chi phí về sau nào rồi đề nghị sắp lại thứ tự. Nếu nhận được nhánh thứ ba thì ít nhất đội đó đã từng hình dung giai đoạn sau phát hành.

Một điểm nữa cần kiểm tra là kế hoạch đưa những thứ đã cắt quay trở lại. Nếu cắt giảm chỉ đồng nghĩa với việc không làm thì rất phiền. Một đề xuất chỉ đứng vững khi nêu được giai đoạn một ra cái gì, sẽ nhìn dữ liệu sử dụng thực tế để đánh giá điều gì, rồi giai đoạn hai bổ sung cái gì. Lý do phát hành bản đầu tiên thật nhỏ không phải để tiết kiệm tiền, mà để phân biệt tính năng làm theo phỏng đoán với tính năng người dùng thật sự cần.

Để cuộc trò chuyện này diễn ra được, phía đặt hàng cũng cần chuẩn bị. Nếu đưa trước bài toán cần giải thay vì danh sách tính năng, đối tác mới có chỗ để đề xuất phương án khác. Chỉ định hai mươi màn hình rồi xin báo giá thì thứ nhận lại chỉ là bảng giá của hai mươi màn hình. Còn nếu giải thích nút thắt của quy trình nằm ở đâu, mỗi ngày bao nhiêu người xử lý theo trình tự nào, thì có thể xuất hiện phương án làm được đúng việc đó với mười hai màn hình.

Thói quen thiết kế với giả định phải bảo trì lâu dài

Thiết kế có tính đến bảo trì không có nghĩa là mã nguồn đẹp. Nó là câu hỏi liệu người khác sau này có thể tiếp quản và sửa được hệ thống này hay không, và câu hỏi đó có nằm trong giai đoạn thiết kế hay không. Phạm vi gồm tách môi trường, đưa cấu hình ra ngoài, lưu lịch sử thay đổi, nhật ký, tài liệu, và cả quyền sở hữu tài khoản. Đây là những mục bên đặt hàng kiểm tra được ngay trong hợp đồng.

Thứ cần xem trước tiên là môi trường. Hãy hỏi môi trường phát triển và môi trường vận hành có tách nhau không, có lấy dữ liệu thật ra kiểm thử không, việc phát hành là tự động hay là tay người tải tệp lên. Không cần đòi hỏi cấu hình phức tạp quá mức cho một dịch vụ giai đoạn đầu. Nhưng tối thiểu phải có sự tách bạch giữa phát triển và vận hành, cùng một quy trình phát hành có thể quay lui được.

Cấu hình có bị gắn cứng trong mã nguồn hay không cũng là điểm cần kiểm tra. Nếu thông tin kết nối, khóa dịch vụ bên ngoài, giá trị bật tắt tính năng đều nằm cứng trong mã thì mỗi lần đổi một giá trị lại cần lập trình viên và một lần phát hành. Câu chữ cũng vậy. Nếu câu hiển thị trên màn hình được viết thẳng vào mã thì mỗi lần thêm một ngôn ngữ là phải động vào toàn bộ. Khi vận hành onSpots ở dạng đa ngôn ngữ, đây là nguyên tắc chúng tôi giữ từ đầu: câu chữ phải nằm ngoài mã nguồn, và việc thêm một ngôn ngữ mới không được phép trở thành một dự án phát triển.

Với dịch vụ trải trên nhiều địa bàn thì còn vài thứ nữa. Thời gian lưu theo giờ chuẩn rồi mới đổi sang giờ địa phương khi hiển thị hay không, định dạng ngày tháng và thứ tự tên người có thay đổi theo vùng hay không, tiền tệ và thuế được xử lý riêng theo từng nước hay không. Trong hệ thống phục vụ cả Hàn Quốc lẫn Việt Nam, phần này về sau gây đau nhất. Một sản phẩm xác định ngay từ đầu chỉ nhắm thị trường Việt Nam như Job Connect VN và một sản phẩm giả định nhiều địa bàn như onSpots sẽ rẽ hướng thiết kế ở đúng điểm này. Không phải bên nào đúng bên nào sai, quan trọng là có quyết định rõ mình thuộc bên nào trước khi bắt đầu.

Hồ sơ ghi chép cũng cần xem. Hãy kiểm tra lịch sử thay đổi cấu trúc cơ sở dữ liệu có được lưu thành tệp không, có giải thích vì sao đổi như vậy không, và người mới vào có tài liệu để dựng được môi trường trong nửa ngày không. Câu trả lời rằng tài liệu bàn giao sẽ viết dồn vào lúc kết thúc dự án là một tín hiệu không tốt. Tài liệu viết ở thời điểm đó thường chỉ có mục lục.

Điểm cuối cùng thực chất là quan trọng nhất: quyền sở hữu. Kho mã nguồn, tên miền, tài khoản nhà phát triển trên cửa hàng ứng dụng, tài khoản đám mây, tài khoản các dịch vụ bên ngoài đứng tên ai, tất cả phải được xác định bằng văn bản trước khi ký. Bất kể chất lượng phát triển thế nào, nếu tài khoản đứng tên công ty phát triển thì việc đổi đối tác về sau không còn là vấn đề kỹ thuật mà thành vấn đề đàm phán. Đây không phải lời khuyên nghi ngờ đối tác mà là quy trình bảo vệ cả hai phía. Ngay cả khi làm việc theo mô hình hợp tác, chúng tôi cũng thống nhất bằng văn bản chủ thể hợp đồng và chủ thể tài khoản trước rồi mới bắt đầu.

Tóm lại, việc có thiết kế với giả định bảo trì hay không không phải chuyện tin tưởng trừu tượng mà là một danh sách kiểm tra được: tách môi trường, tách cấu hình, tách câu chữ, lịch sử thay đổi, nhật ký và giám sát, tài liệu bàn giao, quyền sở hữu tài khoản. Bảy mục đó có thể đối chiếu ngay trong đề xuất và hợp đồng.

Những tín hiệu khách hàng có thể tự kiểm chứng từ bên ngoài

Các tiêu chí phía trên đều dựa vào lời đối tác nói. Phần cuối này là những thứ kiểm chứng được mà không cần nghe ai nói: sản phẩm đã công khai, lịch sử trên cửa hàng ứng dụng, tài liệu, và việc đề xuất có dám nói cắt bớt hay không. Quy trình này không dành riêng cho một công ty nào, nên hãy áp dụng như nhau cho toàn bộ danh sách ứng viên.

Thứ nhất, nếu một đội nói rằng họ có sản phẩm riêng thì hãy tự mở sản phẩm đó lên. Kiểm tra đường dẫn còn sống không, đăng ký tài khoản có chạy không, có qua được màn hình đầu tiên mà không gặp lỗi không. Nếu chỉ có video giới thiệu mà không có chỗ nào để truy cập thì sản phẩm đó chưa phải thứ đang được vận hành. Hãy soi chúng tôi theo đúng cách đó: onspots.app, www.langtori.com và www.jobconnectvn.com đều đang công khai.

Thứ hai, nếu là ứng dụng thì hãy xem lịch sử cập nhật trên trang cửa hàng. Lần cập nhật gần nhất là khi nào, các phiên bản có nối tiếp nhau không, phần ghi chú thay đổi có ghi nội dung thật hay không. Ứng dụng đưa lên một lần rồi bỏ đó và ứng dụng vẫn đang được chỉnh sửa phân biệt được chỉ bằng lịch sử. Đây là dữ liệu khó tô vẽ bằng câu chữ quảng cáo.

Thứ ba, nếu sản phẩm ghi hỗ trợ đa ngôn ngữ thì hãy thật sự đổi ngôn ngữ. Xem sau khi đổi còn màn hình nào chưa dịch không, định dạng ngày tháng và số có đúng với ngôn ngữ đó không, có chỗ nào câu chữ bị cắt cụt không. Đa ngôn ngữ dễ tuyên bố nhưng phiền phức để duy trì, nên nó phản ánh khá rõ mức độ chỉn chu của một đội.

Thứ tư, hãy kiểm tra chính sách bảo mật thông tin và kênh liên hệ có thật sự tồn tại. Không phải xem có gắn đường dẫn hay không, mà xem đường dẫn có mở được không, và gửi thư vào địa chỉ liên hệ thì có nhận được hồi âm không. Gửi một câu hỏi vào kênh hỗ trợ sản phẩm của ứng viên là cách kiểm chứng gần như không tốn chi phí. Cách một đội đối xử với người dùng của họ chính là bản xem trước cho cách họ sẽ đối xử với người dùng của bạn.

Thứ năm, hãy xem đề xuất có câu nào nói nên cắt bớt không. Đúng như phần trước đã bàn. So với đề xuất chép nguyên danh sách yêu cầu, đề xuất sắp lại thứ tự và kèm lý do thường đến từ đội đã trải qua vận hành.

Thứ sáu, hãy tìm điều khoản bàn giao và quyền sở hữu tài khoản trong hồ sơ hợp đồng. Nếu chưa có thì đề nghị bổ sung, rồi quan sát phản ứng. Bản thân phản ứng đó đã là thông tin. Đội không ngại đưa điều khoản vào là đội làm việc với giả định rằng sau này sẽ phải bàn giao.

Cuối cùng xin nói thêm một điều. Đề xuất nào càng phô trương những con số hào nhoáng thì càng nên hỏi nguồn của con số đó. Đây chính là lý do trong toàn bộ bài viết này chúng tôi không dùng một chỉ số sử dụng nào của sản phẩm mình. Hệ đo lường chưa gắn xong nên chúng tôi chưa có những con số ấy, và nếu dùng số không có thật thì chính chúng tôi vi phạm tiêu chí vừa nêu. Thói quen tách bạch cái kiểm chứng được với cái không kiểm chứng được, hình thành ngay ở bàn chọn đối tác, sẽ còn dùng được rất lâu sau khi dự án kết thúc.

Yeowubie Interaction làm việc ở cả Hàn Quốc và Việt Nam, vừa phát triển dự án cho khách hàng vừa vận hành sản phẩm của chính mình. Bài này không được viết ra để trở thành lý do chọn chúng tôi. Hãy áp dụng sáu điểm trên như nhau cho toàn bộ ứng viên, và nếu sau vòng đó chúng tôi vẫn còn lại thì chúng ta tiếp tục câu chuyện.