QC, Tech Lead, DevOps và những vai còn lại trong team

Bài này nối tiếp bài Các vị trí trong team phát triển, dùng lại đúng cách đọc và đúng ví dụ ở đó. Vẫn không dạy cách viết test case hay chạy UAT, không dạy chuỗi môi trường Dev/Test/Staging/Production, cũng không phân tích Product Owner hay Project Manager — mấy phần đó có bài riêng.

Nhắc lại hai thứ để bạn khỏi phải mở bài cũ.

Cách đọc một vai gồm ba câu: họ quyết được gì, họ chặn được gì, mình phải hỏi họ trước khi làm gì. Và tính năng dùng làm ví dụ vẫn là đặt lịch khám — chọn bác sĩ, chọn khung giờ còn trống, bấm xác nhận, hôm trước ngày khám thì nhận tin nhắn nhắc.

Người đi tìm chỗ hở: tester, QC, QA

Ba chữ này ở Việt Nam dùng khá lẫn nhau, và đó là chuyện tên gọi tuỳ công ty chứ không phải chuyện ai đúng ai sai. Nói cho gọn: tester là người trực tiếp ngồi kiểm thử; QC thường được hiểu là kiểm tra chất lượng của thứ đã làm ra; QA thiên về việc làm sao cho quy trình tạo ra được chất lượng. Nhưng một người mang title QA vẫn có thể ngồi test cả ngày, và bạn không cần chỉnh ai cả — chỉ cần hỏi một câu là biết họ thực sự làm gì.

Điều đáng nói hơn là cái mô tả "QC là chốt chặn cuối cùng đảm bảo chất lượng". Đây là câu người làm QC ghét nhất, vì nó đẩy toàn bộ trách nhiệm chất lượng sang họ — để rồi khi lỗi lọt ra ngoài, người bị hỏi đầu tiên là họ, kể cả khi gốc rễ là một dòng yêu cầu viết thiếu.

Giá trị lớn nhất của họ nằm ở chỗ ngược lại với mô tả đó: họ giỏi nghĩ ra những thứ không có trong tài liệu của bạn. Với tính năng đặt lịch, một tester quen việc sẽ hỏi ngay những câu bạn chưa nghĩ tới. Đặt xong rồi huỷ rồi đặt lại khung giờ đó thì có được không? Đặt cho một ngày đã qua thì hệ thống chặn ở đâu? Bấm nút xác nhận hai lần thật nhanh thì thành hai lịch hẹn hay một? Tin nhắn nhắc gửi lúc mấy giờ, và nếu người ta đổi lịch sau khi tin nhắn đã gửi rồi thì sao?

Mỗi câu như vậy hỏi lúc bạn còn đang viết yêu cầu thì mất năm phút. Hỏi lúc đã code xong thì thành một cái ticket sửa. Đó cũng là lý do nên kéo họ vào từ lúc bạn còn đang soạn tài liệu, chứ đừng đợi có bản chạy được mới gọi.

Còn automation tester là người viết chương trình để máy tự chạy lại các kịch bản kiểm thử. Với bạn, điều cần biết gọn thôi: mỗi lần yêu cầu đổi, phần họ đã viết cũng phải sửa theo. Nên một thay đổi bạn thấy nhỏ vẫn có thể kéo theo một khoản công việc mà bạn không nhìn thấy.

Ai chốt được hướng kỹ thuật: Tech Lead và Solution Architect

Tech Lead hay bị mô tả là người giỏi nhất team. Mô tả này vừa rỗng vừa hay sai — nhiều tech lead là người ở lâu nhất và hiểu hệ thống cũ nhất, chứ không phải người code hay nhất. Thứ đáng để bạn nhớ là phạm vi: họ chốt cách làm về mặt kỹ thuật cho team, và họ nói được câu "làm kiểu này sẽ phá thứ đang chạy" — câu đó không huỷ được một yêu cầu nghiệp vụ, nhưng nó đủ sức làm yêu cầu đó dừng lại cho tới khi có người quyết lại.

Có một chuyện nên biết sớm: tech lead ít khi nói thẳng "không làm được". Câu hay gặp nghe như một con số — "cái này muốn làm tử tế thì phải sửa lại phần lõi, mất khoảng ba tháng." Con số đó có thể là ước lượng thật, mà cũng có thể là một cách từ chối nói cho nhẹ. Người mới thường nghe xong là đi báo lại với khách "team bảo ba tháng", và cuộc trao đổi dừng ở đó.

Cách xử lý không phải là cãi, mà là hỏi thêm một vòng bằng giọng trung tính: phần nào tốn thời gian nhất, giả định nào nằm sau con số ấy, bỏ bớt một phần yêu cầu thì con số đổi thế nào. Đôi khi lộ ra một phương án rẻ hơn; đôi khi không, và bạn về báo khách kèm đủ lý do thay vì mỗi con số trần trụi.

Solution Architect hoặc Technical Architect nhìn ở phạm vi rộng hơn một team: hệ thống này nối với hệ thống kia thế nào, dữ liệu chảy từ đâu sang đâu, ràng buộc chung là gì. Bạn sẽ gặp họ khi tính năng của bạn chạm sang một hệ thống khác — ví dụ lịch hẹn phải đồng bộ sang phần mềm quản lý bệnh viện đang chạy sẵn.

Nhưng nói cho thật: phần lớn team năm tới tám người ở Việt Nam không có vai này. Một bạn BE lâu năm hoặc chính tech lead ôm luôn. Nếu bạn đọc một bài viết mô tả team nào cũng có Solution Architect riêng, bài đó đang tả một công ty rất lớn.

DevOps, BrSE, comtor, helpdesk

DevOps trước hết là một cách làm việc: đưa người xây phần mềm và người vận hành nó lại gần nhau, tự động hoá các khâu lặp lại. Nhiều công ty lấy luôn chữ đó làm chức danh cho người lo hạ tầng và vận hành. Cả hai cách dùng đều phổ biến, nên đừng ngạc nhiên khi thấy người ta nói về DevOps theo hai nghĩa khác nhau trong cùng một buổi họp.

Gọi họ là "người bấm nút deploy" thì hụt mất phần quan trọng nhất: họ chặn được deadline vì lý do hạ tầng, và bạn thường chỉ biết lúc đã bị chặn.

Ở tính năng đặt lịch, cái tin nhắn nhắc trước một ngày là chỗ dễ lẫn vai nhất. Gửi lúc mấy giờ, nội dung ra sao, có gửi cho lịch đã huỷ không — đó là quyết định nghiệp vụ, phần của bạn và của người phụ trách sản phẩm. Còn gửi bằng đường nào cho tin thật sự tới nơi, hệ thống có chịu nổi khi cả nghìn tin cùng ra một lúc không, và ai biết khi nó hỏng — đó là chỗ phải có DevOps ngồi cùng. Hỏi thiếu vế thứ hai thì tính năng vẫn được duyệt trên tài liệu, rồi chết lặng lẽ ở ngoài đời.

BrSE và comtor xuất hiện ở các dự án với khách Nhật, và hai vai này không phải một. Comtor thiên về phiên dịch và điều phối giao tiếp, tài liệu. Còn BrSE thường vừa giao tiếp song ngữ vừa phải hiểu phần kỹ thuật, và ở nhiều dự án họ là người ngồi trực tiếp với khách để làm rõ yêu cầu. Người chốt chính thức vẫn là khách, nhưng thứ khách nghe được và thứ khách hiểu đều đi qua họ — nên tiếng nói của họ thường nặng hơn BA phía Việt Nam. Viết BrSE thành "người phiên dịch" là hiểu hụt chỗ đó, và người mới vào sẽ ngơ ngác khi thấy ý kiến của mình phải đi vòng.

Helpdesk và support thì gần như bài tiếng Việt nào cũng bỏ, dù họ ngồi gần người dùng hơn bạn nhiều. Họ là nơi lỗi thật xuất hiện đầu tiên, và là nơi những yêu cầu chưa ai viết thành tài liệu được nghe thấy đầu tiên. Khi tính năng đặt lịch lên thật, người gọi điện nói "tôi đặt rồi mà không thấy lịch đâu" sẽ gọi cho họ chứ không gọi cho bạn. Bỏ ra mỗi tuần một lúc đọc qua các ticket họ nhận được là cách rẻ nhất để biết sản phẩm của mình thực sự đang chạy ra sao.

Chức danh nói một đằng, việc làm một nẻo

Đọc tới đây thì bạn đã có một danh sách khá dài. Giờ tới phần làm danh sách đó lung lay.

Ranh giới giữa các vai ở Việt Nam đang nhoè đi rất nhanh. Có bạn trong một group cộng đồng BA nói thẳng: "giờ làm gì còn chuyên biệt nữa, ranh giới bây giờ mờ nhạt lắm rồi, nhiều cty giờ tuyển BA cum QC PO PM, làm luôn các role đó chứ k phải chỉ hỗ trợ nữa đâu." Một bạn khác kể team mình "ko có designer riêng, mình phải UI luôn, UX thì chịu, khách có feedback xài khó thì sửa."

Chuyện đó không hiếm, và cũng không hẳn là xấu. Nhưng nó có hai mặt, và mặt thứ hai cũng được nói ra trong chính group ấy. Hiểu được góc nhìn của vai khác thì rất tốt — "BA có thể hiểu về góc nhìn của QC để viết được AC chất lượng hơn, hiểu góc nhìn UX UI để mô tả yêu cầu hợp lý hơn." Ôm luôn việc của họ lại là chuyện khác hẳn: "bảo BA làm cả QC với UX kiểu gì cũng gãy."

Đôi khi chức danh còn là một lựa chọn có chủ đích. Một bạn kể công ty giao cho mình phần việc rõ ràng là của quản lý dự án, nhưng sếp nói đó "là trách nhiệm của BA phải làm nên không được gọi là PM hay PO" — và vì thế cũng không trả lương theo mức PM. Người trong group đọc xong đáp gọn: "đây là PM rất rõ ràng luôn."

Nên đọc việc thật, đừng đọc title. Ngay cả những người trong nghề với nhau, khi gặp hai chữ "PM" vẫn phải ghi chú lại là không biết PM ở đây là Product Manager hay Project Manager.

Kèm theo đó là một danh sách những câu nghe như luật mà thật ra chỉ là thông lệ. Mỗi dòng dưới đây đều có team ở Việt Nam làm ngược lại:

Muốn biết team mình thật sự chạy thế nào thì có cách rẻ hơn đọc bất kỳ bài nào: hỏi thẳng. "Việc này ai là người quyết ạ?", "Em cần hỏi thêm ai trước khi chốt?", "Quyết định rồi thì ghi ở đâu?" — ba câu đó không có gì phải ngại, và người mới hỏi thì ai cũng trả lời. Quan sát cũng có ích, nhưng chỉ để biết mình nên hỏi ai chứ đừng dùng để suy ra quyền hạn của người ta.

Còn một chuyện về hình vẽ. Rất nhiều bài minh hoạ chủ đề này bằng một cái vòng tròn có BA ở giữa và các vai khác xoay quanh. Hình đó sai ngay từ bố cục — bạn là một người trong team, ngồi ở chỗ có nhiều thông tin đi qua, thế thôi.

Khi một người ôm ba vai

Đây là câu hỏi mình hẹn ở cuối bài trước. Team năm người, một bạn vừa làm BE vừa lo hạ tầng vừa kiêm luôn phần kiểm thử — thì ba câu hỏi ở đầu bài kia còn dùng được không?

Còn, và thậm chí còn cần hơn. Chỉ khác ở chỗ bạn không hỏi một người, bạn hỏi một phần việc. Cùng một bạn đó, khi đang đội mũ BE thì họ quyết cách lưu dữ liệu; khi đang đội mũ kiểm thử thì họ là người bạn cần đưa các trường hợp biên; khi đang lo hạ tầng thì họ là người biết tin nhắn nhắc có gửi nổi không. Ba mũ, ba loại câu hỏi, ba thời điểm khác nhau.

Cái bẫy của team nhỏ không phải là thiếu người. Nó là bạn tưởng đã hỏi rồi, vì đã nói chuyện với người đó rồi — trong khi thực ra mới chạm đúng một trong ba mũ.

Thử vẽ lại sơ đồ team của chính bạn

Nếu đọc xong hai bài này mà bạn làm được một việc thôi, mình mong đó là việc này: mở một tờ giấy ra, viết tên từng người trong team thật của bạn, và cạnh mỗi tên ghi ba thứ — họ quyết được gì, họ chặn được gì, mình phải hỏi họ trước khi làm gì. Ai đội nhiều mũ thì ghi thành nhiều dòng.

Sơ đồ đó sẽ không giống hình nào trong hai bài. Có thể ba người ôm mười vai, có thể không có ai tên là designer. Sơ đồ đúng là sơ đồ của team bạn, không phải sơ đồ trong sách.

Còn những chức danh nghe gần với BA mà mình cố tình không bàn ở đây — Product Owner, Product Manager, Project Manager, Business Owner — thì mỗi cái có một bài riêng ở phần sau của khoá. Từ bài kế tiếp, khoá chuyển sang phần kỹ năng và kỹ thuật: những thứ bạn thật sự phải làm được, bắt đầu từ các nhóm kiến thức mà nghề này gom lại.