Nửa kỹ thuật của việc tích hợp một supplier thì ai làm cũng hiểu: đọc tài liệu, viết module, map field, xử lý lỗi. Nửa còn lại mới là thứ quyết định bao giờ tích hợp đó lên được production, mà gần như không ai viết ra, vì nó không trông giống việc kỹ thuật.
Một supplier không phải một cái endpoint. Nó là một công ty, có bộ phận hỗ trợ, có lịch release, có một hàng đợi các bên tích hợp đứng trước mình, và có một engineer ở đầu bên kia — người đó cũng có sếp riêng và có quan điểm riêng về chuyện cái mình báo có phải bug hay không.
Certification là một cuộc trao đổi
Đưa một supplier mới lên sống kết thúc bằng certification: một bộ testcase riêng của từng provider chạy qua trọn luồng, mỗi case đều được ghi lại toàn bộ traffic. Phần đó là máy móc. Phần không máy móc là certification luôn diễn ra cùng với một người. Ai đó bên họ xem lại lượt chạy, quyết định các kịch bản đã được thực hiện đúng chưa, rồi ký duyệt — và lịch rảnh của người đó là một dependency thật sự của dự án bạn.
Nghĩa là cái lịch bị dùng chung. Đợt release của họ, kỳ freeze của họ, lịch nghỉ của team họ, cái tuần họ đang onboard một đối tác to hơn bạn — tất cả nằm trước ngày go-live của bạn, và không thứ nào xuất hiện trên bảng sprint của bạn. Việc kỹ thuật có thể xong vào thứ Ba mà tích hợp lên sống một tháng sau, không ai chậm cả.
Cái report phải chạy được mà không cần họp
Khi bạn tìm ra một lỗi trong hệ của supplier — mà làm tích hợp cỡ nào cũng sẽ gặp — thì họp là cách trao đổi đắt nhất, và thường cũng không có sẵn: khác công ty, khác múi giờ, đầu kia là một địa chỉ support chứ không phải một con người. Cái bug report phải tự làm việc được trong lúc bạn đang ngủ.
Cụ thể là nó phải chở cả vụ việc, chứ không phải bản tóm tắt của vụ việc:
- đúng cái request đã gửi, ở dạng họ tự chạy lại được
- đúng cái response đã nhận, nguyên văn, kể cả những phần trông không liên quan
- thời điểm, kèm múi giờ, để họ dò được cú gọi đó trong log của chính họ
- mình mong đợi cái gì thay vào đó, và vì sao — chỉ vào tài liệu của họ, schema của họ, hoặc hành vi trước đó của chính họ
- mình đã loại trừ được những gì ở phía mình
Hai gạch đầu dòng cuối là thứ quyết định có gì xảy ra hay không. "Cái endpoint này hỏng" là một lời phàn nàn, mà phàn nàn thì bị xếp hàng. "Tài liệu của anh ghi field này optional; bỏ nó ra thì response trả về một lỗi không nêu tên field nào; đây là cú gọi" là một báo lỗi có sẵn cách tái hiện đi kèm, và một người chưa từng nói chuyện với bạn vẫn triage được.
Viết cho người không biết hệ của mình
Lỗi mình thấy nhiều nhất trong bug report của engineer — kể cả mấy cái mình viết hồi trước — là viết từ bên trong kiến trúc của mình. Gọi tên service của mình. Nói là job fail, worker không ghi được gì đó, thiếu một mapping. Đúng hết, và vô nghĩa hết với người nhận, vì họ không biết mấy thứ đó là gì và không kiểm chứng được thứ nào.
Vốn từ chung duy nhất giữa hai công ty là luồng traffic giữa họ. Nên cái report được viết hoàn toàn bằng vốn từ đó: endpoint của họ, field của họ, response của họ, định danh của họ. Mọi thứ xảy ra bên trong hệ của mình thì hoặc không liên quan tới họ, hoặc phải dịch thành một phát biểu về cú gọi. Một kỷ luật nhỏ, và nó đổi tỉ lệ được trả lời theo cách mình chưa đo nhưng chắc chắn có thấy.
Bộ bằng chứng là một thông điệp
Bên mình dựng một bộ bằng chứng cho certification — request và response của từng testcase, kèm cú gọi lên supplier, được gom vào các folder có tên. Bên trong nội bộ thì đó là một hiện vật QA. Nhìn ra ngoài thì đó là một hiện vật giao tiếp, và khác biệt lộ ra ở cách dựng nó.
Một bộ dành cho mình thì đổ log ra là xong; một bộ dành cho họ phải đi lại được bởi người chưa từng thấy cách đặt tên của mình. Folder đặt theo kịch bản, không phải theo id case nội bộ. Một folder, một câu chuyện: hỏi gì, gửi gì, nhận về gì. Giá trị của nó là trả lời trước ba câu hỏi kế tiếp của đối tác, và mỗi câu họ không phải hỏi là một lượt qua lại bớt đi trong một cuộc trao đổi có khi mỗi ngày chỉ đi được một lượt.
Escalate mà không tiêu mất quan hệ
Có lúc chuyện đúng là đang chặn thật và kênh bình thường không nhúc nhích. Escalate là một công cụ thật và nó có giá thật, vì cũng chính đối tác đó là người bạn cần cho tích hợp sau, cho sự cố sau, và cho cuộc đàm phán thương mại mà công ty bạn đang chạy song song với cuộc trao đổi của bạn.
Mấy điều mình cố giữ khi escalate: dữ kiện vẫn đúng là dữ kiện mình gửi lần đầu, không tô vẽ thêm; yêu cầu phải cụ thể và nhỏ ("bọn mình cần một câu trả lời hành vi này có đúng thiết kế không, để hoặc đi đường vòng, hoặc chờ bản sửa") chứ không phải một lời bày tỏ bức xúc; và tác động thì nói bằng ngôn ngữ của họ — booking không hoàn tất được, chứ không phải sprint bị trễ. Escalate cái vấn đề, đừng bao giờ escalate con người, và đừng làm ở cái kênh mà engineer của họ đọc thành một lời buộc tội từ người lạ.
Ước lượng phải chứa hàng đợi của người khác
Đây là chỗ bất đối xứng định hình mọi cái kế hoạch. Sandbox của họ có chạy hay không, tài liệu của họ đúng tới đâu, giờ hỗ trợ của họ, lịch sửa lỗi của họ — không thứ nào bạn điều khiển được, mà thứ nào cũng nằm trên đường găng của bạn. Một kế hoạch giả định câu trả lời sẽ tới đúng lúc mình cần thì không phải ước lượng, đó là một điều ước.
Mình không có con số công bố nào về việc đối tác quay lại trong bao lâu. Bọn mình chưa từng đo theo cách mình dám viết ra, mà mình ngờ rằng con số trung bình cũng sẽ đánh lừa, vì cái làm mình đau là phần đuôi phân bố: phần lớn câu trả lời tới nhanh, còn đúng cái không nhanh thì rơi vào tuần mình đã hứa go-live. Nên con số mình không có không phải là điểm chính. Điểm chính là một ước lượng trung thực phải có hẳn một dòng cho hàng đợi của người khác, và dòng đó không bằng không.
Engineer, mình cũng vậy, thích mô hình hoá phần mình kiểm soát được. Còn cái lịch thì thật ra nằm ở phần mình không kiểm soát.