Bạn vẫn xem được các bài đã đăng mà không cần đăng nhập.
Bốn kiểu BA làm dev muốn tự code cho xong, thứ QC cần mà không nói ra, và cách bàn giao yêu cầu để bạn là chỗ dựa của team chứ không phải cái rào chắn ở giữa.
Người ta hay dạy BA là cầu nối giữa bên nghiệp vụ và team kỹ thuật. Nghe thì hay.
Nhưng đi làm một thời gian bạn sẽ gặp một kiểu cầu nối rất tệ: người đứng giữa mà cái gì cũng phải qua tay. Dev muốn hỏi một câu phải chờ BA. QC muốn xác nhận một chi tiết cũng phải chờ BA. Rồi cả team chậm lại vì mình, trong khi mình thì bận tối mắt và tưởng như vậy nghĩa là đang làm việc chăm chỉ.
Bài này nói về phần ít ai dạy: đứng giữa dev và QC thế nào để bạn là chỗ dựa của họ chứ không phải cái rào chắn.
Bài này không dạy lại Scrum, không dạy viết User Story hay Acceptance Criteria, cũng không dạy test — những phần đó có bài riêng trong khoá. Ở đây mình chỉ nói chuyện phối hợp hằng ngày: hỏi ai, hỏi lúc nào, bàn giao ra sao, bị vặn thì trả lời thế nào.
Hầu hết bài viết về chủ đề này đều bắt đầu bằng "BA nên làm gì". Mình muốn đi ngược lại, vì nếu bạn chưa hình dung được phía bên kia đang khó chịu ở đâu thì mọi lời khuyên đều trôi tuột.
Có một điều mình nhận ra khá muộn: dev không sợ việc khó. Họ sợ việc mơ hồ phải làm đi làm lại. Một tính năng phức tạp nhưng rõ ràng thì họ ngồi làm ba ngày cũng vui. Một tính năng đơn giản nhưng mỗi ngày hiểu một kiểu thì họ nản từ hôm đầu.
Từ chỗ đó sinh ra bốn kiểu BA làm dev muốn tự code luôn cho xong.
Kiểu thứ nhất là BA lảng tránh. Dev nhắn hỏi một trường hợp chưa có trong tài liệu, BA trả lời "để em xem lại nhé" rồi im. Hai hôm sau dev vẫn không thấy gì, tự đoán một hướng rồi code tiếp. Với dev, câu "để em xem lại" không chứa thông tin nào — nó chỉ nói rằng bạn không biết và cũng không hứa khi nào sẽ biết.
Kiểu thứ hai là BA giả vờ biết. Bị hỏi giữa buổi họp, sợ quê nên trả lời đại một hướng nghe hợp lý. Dev code theo, tuần sau lòi ra là ngược với luồng cũ của hệ thống, phải sửa lại từ đầu. Cái này hại hơn kiểu thứ nhất nhiều, vì lần sau dev sẽ tự kiểm chứng lại mọi câu bạn nói thay vì tin.
Kiểu thứ ba là BA sửa yêu cầu mà không báo ai. Khách đổi ý, BA vào sửa tài liệu cho đúng, xong. Trong đầu bạn thì mọi thứ đã cập nhật. Còn dev thì vẫn đang làm theo bản đọc từ hôm thứ Hai.
Kiểu thứ tư, và theo mình là tệ nhất: BA hứa thay dev. Đang họp với khách, khách hỏi có làm được cái này không, BA gật luôn: "Vâng cái này bên em làm được." Câu đó nghe rất chuyên nghiệp trong phòng họp. Nhưng lúc về tới team, nó đã thành một lời cam kết mà người phải thực hiện thì chưa hề được hỏi.
Điều làm dev khó chịu ở đây thường không phải bản thân tính năng. Nhiều khi làm được thật, và làm cũng không lâu. Cái làm họ nản là bị quyết thay: bạn vừa tiêu mất thời gian của họ trong một cuộc họp họ không có mặt. Lần sau khi bạn nói "cái này chắc nhanh thôi", họ sẽ không tin nữa — mà chuyện bạn ước lượng thay dev cũng là một kiểu lấn sân, vì thời gian làm là con số của người làm, không phải của người viết yêu cầu.
Cách nói an toàn mà vẫn giữ được mặt trước khách chỉ khác một chút: "Về mặt nghiệp vụ thì hợp lý, em ghi nhận. Em check với team về mặt kỹ thuật rồi chốt lại với anh chị trong hôm nay." Bạn không mất gì cả — khách vẫn thấy bạn nắm việc — mà dev thì vẫn còn quyền nói về phần của họ. Nếu hoá ra làm được thật, bạn quay lại xác nhận, và lần này lời hứa đó có người đứng sau.
Bốn kiểu trên, không kiểu nào là chuyện thiếu kiến thức nghiệp vụ. Ba kiểu đầu là chuyện xử lý thông tin, kiểu cuối là chuyện đứng đúng chỗ của mình — và cả hai thứ đó đều là nghề của BA.
QC ít khi nói ra, nhưng phần lớn khó chịu của họ với BA gom lại thành một câu: họ không biết thế nào mới là đúng.
Công việc của QC là so sánh cái đang chạy với cái đáng lẽ phải chạy. Nếu vế thứ hai mơ hồ, họ không có gì để so. Lúc đó chỉ còn hai lựa chọn: hoặc đoán theo cảm giác rồi log một cái bug ghi "không đúng mong đợi" — nghe rất chung chung và dev đọc xong cũng chẳng biết sửa gì; hoặc bỏ qua, để lỗi chạy thẳng lên production.
Có bốn thứ của BA làm hỏng việc của QC nhanh nhất. Tài liệu không nói rõ trường hợp biên, nên QC test đại rồi cãi nhau với dev chuyện đó có phải lỗi hay không. Yêu cầu đổi mà không báo, làm kịch bản test họ chuẩn bị cả buổi thành vô nghĩa. Câu trả lời "đúng như spec mà" — với QC, câu đó nghĩa là bạn không thèm đọc cái bug họ vừa mô tả. Và cuối cùng là không có dữ liệu hay tài khoản mẫu để test, thứ nghe rất nhỏ nhưng đủ làm họ đứng hình nửa ngày.
Có một cách nhìn mình muốn bạn giữ từ đây tới hết bài: khi QC hỏi vặn, đó không phải họ bắt bẻ bạn. Đó là tài liệu của bạn đang được đọc lại bởi một người quen đi tìm chỗ hở. Ai làm BA cũng cần một người như vậy trong team.
Cả bài mình sẽ dùng một tính năng duy nhất để kể: quên mật khẩu. Ai cũng từng bấm cái nút đó, mà bên trong nó lại có đủ mọi thứ dễ sai.
Giả sử bên nghiệp vụ ném cho bạn một câu: "Tháng này làm thêm chức năng khách quên mật khẩu thì tự đặt lại được."
Sai lầm phổ biến nhất của bạn mới vào nghề không nằm ở chỗ viết tài liệu dở. Nó nằm ở chỗ gật đầu quá sớm. Câu đó nghe đủ rõ để bắt tay vào viết, nhưng thật ra nó chưa trả lời được câu nào trong đám sau:
Bốn câu này, câu nào bạn không hỏi thì lát nữa dev sẽ tự trả lời thay bạn. Và họ sẽ trả lời theo cái hợp lý nhất trong đầu họ, chứ không phải theo cái đúng với nghiệp vụ.
Chuyện thứ hai là cách bàn giao. Viết xong tài liệu, gửi link vào nhóm chat rồi kéo ticket sang cột "In Dev" — với bạn thì việc đã xong, còn với dev thì đó mới là một đường link nữa trong ngày. Thực tế dev đọc lướt, QC thì thường chỉ mở tài liệu ra lúc cần log bug.
Nên hãy dành 15 phút ngồi lại với dev và QC cùng lúc — cho hai bên nghe một lần, hiểu giống nhau ngay từ đầu, bạn đỡ được một vòng dịch qua dịch lại. Bạn kể lại tính năng trong ba phút, chỉ thẳng vào chỗ mình biết là dễ hiểu sai, rồi để họ hỏi. Mình hay mở bằng câu đơn giản kiểu "anh đọc qua chưa, để em tóm tắt ba phút rồi mình bắn câu hỏi nhé". Lúc nói thì ưu tiên hình và ít chữ, đi từ luồng tổng quan rồi mới chui vào chi tiết — một sơ đồ nguệch ngoạc trên bảng nhiều khi hiệu quả hơn ba trang mô tả.
Một lưu ý về chỗ đặt 15 phút đó: đừng gọi họp tuỳ hứng. Team nào cũng đã có sẵn buổi để làm rõ hạng mục sắp làm, tên gọi tuỳ chỗ. Ghé vào buổi có sẵn thì không ai mất mạch code; còn cứ thích là gọi mọi người ra khỏi việc thì vài lần là bạn thành phiền.
Trong tài liệu quên mật khẩu ở trên, có một dòng nhìn rất vô lý: nhập email không tồn tại thì vẫn hiện thông báo "đã gửi email khôi phục".
Đọc lần đầu ai cũng thấy sai. Người dùng gõ nhầm email thì phải báo cho họ biết chứ, sao lại nói dối là đã gửi?
Giả sử bạn chỉ kéo ticket, không giải thích gì. Dev đọc tới dòng đó, thấy bất hợp lý, và sửa thành báo lỗi thẳng: "Email không tồn tại trong hệ thống". Hoàn toàn thiện chí, thậm chí còn nghĩ mình đang làm sản phẩm tốt hơn cho người dùng. Vấn đề là cái màn hình vừa được "sửa cho hợp lý" đó biến thành một cái máy dò tài khoản — kẻ xấu chỉ cần gõ thử một danh sách email là biết email nào có tài khoản thật trong hệ thống của bạn. Đó là lý do các hệ thống nghiêm túc cố ý trả lời chung chung ở đây: mơ hồ có chủ đích, không phải viết ẩu.
Nhìn lại thì dev sai chỗ nào không? Không hề. Người sai là BA, vì đã bỏ đi phần vì sao rồi mong người khác đoán ra được.
Dev không gặp được người dùng cuối, không ngồi họp với bên nghiệp vụ. Bạn là mắt và tai của họ. Chỗ nào bạn không nói vì sao, chỗ đó họ sẽ tự lấp bằng phán đoán của mình. Mà phán đoán của một người thông minh, thiện chí, nhưng thiếu bối cảnh thì vẫn cứ là phán đoán.
Nói vì sao cũng không tốn công như bạn tưởng. Một dòng ngắn cạnh mỗi quy tắc lạ là đủ: "báo chung chung để người ngoài không dò được email nào đang có tài khoản". Chỉ vậy thôi, mà nó cứu bạn khỏi một cuộc sửa tới sửa lui.
Có một chuyện mình mất khá lâu mới nhận ra: câu trả lời tệ nhất không phải câu trả lời sai, mà là câu "để em xem lại" rồi không hẹn ngày.
Lý do rất thực tế. Dev sắp xếp công việc dựa trên thời điểm họ có câu trả lời. Nếu bạn nói "mai mười giờ em báo anh", họ làm phần khác trước, mười giờ mai quay lại. Nếu bạn nói "để em xem lại", họ không sắp xếp được gì cả — nên họ sẽ tự đoán, hoặc đi hỏi người khác. Một câu trả lời hơi lệch mà đúng hẹn còn dùng được hơn một câu trả lời chuẩn nhưng hai ngày sau mới tới.
Vài câu bạn mới hay buột miệng, kèm nghĩa thật bên tai người nghe:
Bạn nói | Dev / QC nghe thành |
|---|---|
"Để em xem lại nhé" | Tôi không biết, và cũng không hứa khi nào biết |
"Đúng như spec mà anh" | Tôi không thèm đọc cái bug bạn vừa mô tả |
"Cái đó hồi trước chưa nghĩ tới" | Tài liệu tôi viết không bao quát |
"Chắc là..." | Tôi đang đoán nhưng nói bằng giọng chắc chắn |
Thay vào đó, mọi câu trả lời nên có ba phần: trả lời thẳng vào câu hỏi → một hai câu bối cảnh → cam kết kèm mốc giờ nếu chưa chốt được. Ví dụ: "Chỗ này em chưa chốt được vì bên nghiệp vụ chưa xác nhận. Trước mắt anh cứ làm theo hướng A, nếu đổi thì em báo ngay. Chậm nhất mai 10 giờ em có câu trả lời chính thức."
Đi kèm với nó là một thói quen ít ai dạy: phân biệt rõ ba mức chắc chắn trong lời mình nói. Cái này đã chốt rồi. Cái này đang tạm giả định để đi tiếp. Cái này chưa được làm cho tới khi có quyết định. Ba mức đó phải nói ra bằng lời, đừng để người nghe tự phân loại. Một câu "đúng rồi" nói bừa nguy hiểm hơn nhiều so với một câu "cái này mình chưa chắc".
Còn một thói quen nhỏ nữa: trả lời trong nhóm chat chung thay vì nhắn riêng, trừ chuyện tế nhị. Cùng một câu trả lời, nhắn riêng thì một người biết, để trong nhóm thì QC cũng đọc được và tự cập nhật kịch bản test mà bạn khỏi phải nói lại lần hai.
Tuần đầu, thứ đáng làm nhất không phải chứng minh mình giỏi. Là mở cho được cái kênh để sau này người ta chịu hỏi mình.
Vài việc rất cụ thể cho mấy ngày đầu:
Điểm chung của mấy việc trên là bạn đến với một câu hỏi rõ ràng. Người ta rất sẵn lòng giúp một người biết mình cần gì, và rất ngại một người ngồi im chờ được phân việc.
Về lâu dài thì có một thứ nên để ý. Mỗi lần bạn trả lời đúng hẹn, nhận lỗi nhanh, báo sớm khi có thay đổi, người ta tin bạn thêm một chút. Mỗi lần bạn lảng tránh, nói bừa, sửa tài liệu mà không ai biết, chỗ tin đó hụt đi. Chuyện là không ai đến nói với bạn "tôi không tin BA" cả. Người ta chỉ lặng lẽ ngừng hỏi bạn, tự quyết theo ý mình, hoặc vòng qua bạn để hỏi người khác. Đến lúc bạn nhận ra thì thường đã hụt khá sâu rồi.
Không có thang điểm nào cho phần việc này, nên mình dùng mấy dấu hiệu sau để tự kiểm:
Dev tìm bạn trước khi họ bí, chứ không phải sau khi đã làm sai. Nghĩa là họ tin hỏi bạn thì nhanh hơn tự đoán.
QC báo cho bạn biết trước khi kịch bản test của họ sắp hỏng, thay vì để tới cuối đợt rồi log một loạt bug. Nghĩa là họ coi bạn là người cùng phe.
Dev và bên nghiệp vụ nói chuyện được với nhau mà không phải chờ bạn dịch từng câu — bạn vẫn ngồi đó nghe và ghi lại, nhưng không còn là cái nút thắt nữa. Đây chính là câu trả lời cho cái mở bài: cầu nối tốt là cầu nối làm cho hai bờ đi lại được với nhau, chứ không phải chỗ bắt ai qua cũng phải dừng.
Nếu ba dấu hiệu đó chưa có, cũng đừng vội lo. Phần lớn chúng không đến từ một kỹ năng lớn nào cả, mà đến từ mấy việc rất nhỏ lặp lại đủ lâu: hẹn giờ thì trả lời đúng giờ, sai thì nhận trước khi bị chỉ ra, đổi gì thì nói ngay chứ đừng để người khác phát hiện.
Cả bài này nói về chuyện làm sao để mọi thứ trôi. Nhưng có những ngày nó không trôi: dev bảo tính năng không làm được, khách đổi ý lúc code dở, QC với dev cãi nhau về một cái bug mà bên nào cũng thấy mình đúng. Bài tiếp theo nói riêng về mấy tình huống đó.
Thảo luận (0)
Bạn cần đăng nhập để thảo luận