Khách chậm cấp dữ liệu và quyền truy cập: cách FDE giữ dự án không đứng im

Tuần thứ hai của dự án, bạn đã có laptop, có badge, có một phòng họp mượn tạm. Thứ duy nhất chưa có là account vào hệ thống của khách. Request đã gửi ba lần, ticket vẫn ghi “đang chờ security”, còn lịch demo cho ban điều hành thì không ai dời.

Cảnh này dễ dẫn tới hai phản xạ: nhắn thêm một tin nhắc lịch sự, hoặc ngồi bực và chờ. Cả hai đều để thời gian dự án trôi mà không ai phải quyết định gì. Thoát khỏi cảnh đó là một kỹ năng phải luyện như debug.

Cẩm nang nghề tư vấn của Umbrex khuyên coi những lần khách chậm lặp lại là rủi ro phụ thuộc của dự án, không phải nỗi bực cá nhân, và chuyển từ chờ thụ động sang chủ động quản lý phụ thuộc. Muốn làm được điều đó, bạn cần ba thứ: một bảng theo dõi, một phép trừ và một tin nhắn có các phương án.

Chậm trễ là thứ nên có trong kế hoạch

Hãy tua lại buổi kickoff, trước khi mọi chuyện ở đoạn mở đầu xảy ra. Trên màn hình là timeline, trong phòng có sponsor, người bên security và người bên IT, và chưa ai chậm việc gì. Đây là lúc dễ nói chuyện chậm trễ nhất, vì chưa có ai để trách.

Hãy chỉ vào đúng một ô trên timeline: security review cho cách tích hợp, một trở ngại điển hình có thể khiến dự án mất hàng tuần chỉ vì một phòng ban, như Rocketlane cảnh báo. Rồi hỏi: “Bên anh chị ai sẽ theo việc này, và thường mất bao lâu?”

Câu trả lời là một cái tên và một số ngày, và cả hai đi thẳng vào timeline. Đó cũng là lời khuyên của Baton: đưa những trở ngại quen thuộc phía khách vào kế hoạch ngay từ đầu. Một lời cảnh báo không có người nhận thì chẳng ai phải làm gì.

Khách sẽ coi những gì bạn nói ở kickoff nghiêm túc hơn nếu hợp đồng cũng ghi như vậy, nên trước buổi đó hãy đọc SOW trước khi đọc schema. SOW của Alloy.ai là một mẫu rõ ràng: mọi timeline phụ thuộc vào việc được truy cập dữ liệu đúng hạn, và chậm trễ có thể dẫn tới change order để kéo dài dự án.

Khi khách không phản hồi, văn bản đó còn cho bên triển khai quyền tạm dừng tích hợp và điều người đi nơi khác. Bạn cần biết hợp đồng của mình có cơ chế tương tự hay không, rồi mới bàn được chuyện leo thang.

Một dự án giả định, tính từng ngày

Thử hình dung dự án ấy là một agent phân loại hồ sơ bồi thường cho một công ty bảo hiểm. Kickoff là N1, demo chốt vào ngày làm việc thứ 20, gọi là N20. Sau khi có quyền đọc hệ thống thật, bạn ước tính cần 10 ngày để xây và 3 ngày để nhóm nghiệp vụ duyệt kết quả.

Phép tính chỉ có một dòng: 20 trừ 13 bằng 7. Quyền truy cập phải đến muộn nhất vào N7, và nếu account mất 2 ngày để cấp sau khi review xong, security phải duyệt muộn nhất vào N5. Đây là thứ một tin nhắc lịch sự không bao giờ cho bạn biết: hạn thật của từng phụ thuộc.

Umbrex khuyên theo dõi mỗi phụ thuộc cùng owner, hạn, deliverable bị ảnh hưởng và điểm leo thang. Áp vào dự án giả định, với tên người cũng là giả định, register trông như sau:

Phụ thuộc	Owner phía khách	Hạn	Deliverable bị ảnh hưởng	Leo thang tới
Security review cách tích hợp	Lan, trưởng nhóm security	N5	Mọi việc trên dữ liệu thật	Sponsor
Account read-only	Minh, IT admin	N7	Bản build đầu tiên	Trưởng phòng IT
Export 12 tháng hồ sơ để đánh giá	Hà, data engineer	N12	Bộ eval cho demo	Trưởng nhóm data

Cột quan trọng nhất của bảng là Owner: mỗi ô ghi tên một người, không ghi “phía khách” hay một chức danh chung. Nếu không điền được tên người vào ô đó, bạn đã tìm ra rủi ro đầu tiên của dự án.

Đến N6, review vẫn chưa xong

Giờ là N6, hạn N5 đã qua. Trước khi viết cho sponsor, bạn hỏi Lan: “Review đang kẹt ở bước nào, bên mình còn thiếu gì không?” Umbrex coi câu hỏi này là bước đi trước leo thang, vì sự tò mò làm người ta bớt phòng thủ và để lộ thứ thật sự đang chặn dự án.

Lan trả lời: hồ sơ đã đủ, nhưng hội đồng review họp vào N10. Vậy nguyên nhân là lịch họp, không phải request mơ hồ, nên nhắc thêm hay viết lại request đều vô ích. Account sớm nhất đến N12, trễ 5 ngày so với hạn; lấy 12 cộng 13, demo đầy đủ rơi vào N25.

Umbrex nhấn mạnh rằng leo thang hiệu quả giúp khách chọn hướng đi, chứ không chỉ báo rằng bạn đang bực. Tin nhắn gửi sponsor vì thế nên viết như sau:

Demo N20 có rủi ro: account đến N12, trễ 5 ngày, vì hội đồng security họp N10.

Đã hỏi Lan: hồ sơ đủ, chỉ kẹt lịch họp.

A. Giữ N20, thu hẹp phạm vi: demo trên export ẩn danh, nếu security đồng ý và export đến muộn nhất N7.

B. Giữ đủ phạm vi, dời demo sang N25.

C. Anh/chị xin security họp riêng N7: account N9, demo đủ phạm vi N22.

Xin chọn trước cuối ngày N6.

Hạn chọn là N6 vì hướng A và hướng C đều phụ thuộc vào N7. Với hướng A, 13 ngày việc chỉ vừa kịp N20 nếu export đến trong N7; hướng C cần phiên review đúng ngày đó. Để sang ngày sau, chỉ còn lại hướng B.

Tin nhắn không trách ai và không có tính từ. Hướng dẫn leo thang của OpenProject gọi đây là một mẫu để ra quyết định: viết thành văn bản, gửi sớm, nêu nguyên nhân và các lựa chọn.

Sponsor có thể không biết security đang giữ dự án, nhưng họ có thể gọi một cuộc điện thoại mà bạn thì không.

Với mọi hướng, hãy ghi lại quyết định vào register và email xác nhận. Nếu SOW có điều khoản như của Alloy.ai và lịch thực sự kéo dài, người phụ trách hợp đồng phía bạn cần biết sớm để xử lý, thay vì phát hiện khi đã trễ.

Sáu bước áp dụng cho dự án của bạn

Bước một là kickoff: nói rõ những chỗ thường chậm và xin một người chịu trách nhiệm cho từng phụ thuộc.

Bước hai là lập register. Một bảng tính được rà lại đều đặn là đủ để bắt đầu.

Bước ba là đếm ngược từ deliverable để có hạn thật thay vì hạn cảm tính.

Bước bốn là hỏi vì sao chậm trước khi leo thang. Request mơ hồ cần được viết lại, kèm đúng bảng, đúng quyền và lý do; người phụ trách quá tải thì cần sponsor đổi ưu tiên. Hai nguyên nhân này cần hai cách xử lý khác nhau, nên một tin nhắc chung sẽ không giải quyết được cái nào.

Bước năm dành cho lúc hạn thật không còn giữ được: leo thang bằng tin nhắn nhiều hướng như trên, mỗi hướng có ngày và phạm vi.

Bước sáu là tiếp tục làm những gì không cần quyền trong lúc chờ: viết test, dựng pipeline trên dữ liệu giả, và hỏi xem ai đang có bản sao dữ liệu đã được phép dùng.

Những lỗi khiến dự án vẫn đứng im

Đừng đợi đến khi hạn đã qua lâu mới leo thang, vì lúc đó bạn không còn lựa chọn nào rẻ để đưa cho sponsor. Cũng đừng leo thang sai cách: chuyển tiếp chuỗi email cho sếp của người ta, không kèm hệ quả hay lựa chọn. Làm vậy, bạn mất một đồng minh mà sponsor vẫn chưa biết phải làm gì.

Một lỗi khác nguy hiểm hơn là tự tìm đường vòng, như mượn account của một nhân viên thân thiện hoặc xin file qua kênh cá nhân. Bạn tiết kiệm được vài ngày nhưng đặt cược cả niềm tin với đội security đang review mình. Lỗi cuối cùng là âm thầm làm thêm giờ để bù, khiến khách không bao giờ thấy cái giá thật của sự chậm trễ.

Cách kể kỹ năng này khi đi xin việc

Đừng chỉ ghi “kỹ năng giao tiếp tốt” trong CV, vì câu đó không cho người đọc thấy bạn đã làm gì. Hãy mô tả bạn đã phát hiện phụ thuộc nào, tính ra rủi ro bao nhiêu ngày, đưa những lựa chọn gì và kết quả ra sao, với số liệu thật của bạn.

Đến vòng phỏng vấn, hãy hỏi liệu FDE có được đọc SOW không và ai là người mở change order. Câu trả lời cho bạn biết công ty có trao quyền cho kỹ sư ở hiện trường, hay chỉ đẩy họ ra chờ một mình.

Bài tập cho tuần này

Chọn một thứ bạn đang chờ từ khách hoặc từ một nhóm khác trong công ty. Đếm ngược từ deliverable để ra hạn thật, hỏi owner xem việc đang kẹt ở đâu, rồi viết tin nhắn ba hướng theo mẫu trên, mỗi hướng có một ngày và một phạm vi. Nếu chưa viết được hướng thứ hai, bạn vẫn chưa hiểu đủ về dự án của mình.

Lần tới khi ticket vẫn ghi “đang chờ security”, việc của bạn không còn là chờ nữa mà là tính xem còn lại bao nhiêu ngày, và ai cần biết con số đó.