Bạn vẫn xem được toàn bộ bài học mà không cần đăng nhập.
Việc gì thuộc BA, việc gì làm hộ được nhưng phải nói rõ là làm hộ, việc gì tuyệt đối không nhận, và cách từ chối mà không hỏng quan hệ với khách.
Ngày thứ ba của giai đoạn pilot ở một chuỗi bán lẻ, bạn mở máy lúc tám giờ sáng với đúng một việc trong đầu: hoàn thiện tài liệu cấu hình phân hệ kho để kịp bàn giao cuối tuần.
Hai tuần sau, tài liệu bàn giao trễ, phần ràng buộc dữ liệu viết vội nên đội phát triển hiểu sai một quy tắc. Tới lúc lỗi nổ ra trong buổi nghiệm thu, câu hỏi đầu tiên của mọi người là tài liệu đã mô tả trường hợp này chưa.
Đó là cách một BA đánh mất ranh giới, không phải bằng một lần nhận việc lớn mà bằng ba mươi lần nhận việc nhỏ.
Bạn không thể từ chối thứ mà chính bạn cũng không chắc có phải việc của mình hay không, nên trước hết cần một bản đồ.
Cách tôi vẫn dùng là đi theo trình tự thời gian của dự án, và ở mỗi giai đoạn chỉ hỏi một câu: sản phẩm đầu ra của giai đoạn này là gì, và ai ký tên vào nó. Cái gì bạn tạo ra rồi người khác dùng lại thì là việc của bạn, còn cái gì bạn chỉ góp thông tin trong khi người khác chịu trách nhiệm thì chỉ là việc bạn hỗ trợ.
Nhóm này gọn hơn nhiều người tưởng: bạn vừa làm ra sản phẩm vừa chịu trách nhiệm về nội dung bên trong nó.
Cụ thể gồm:
Cần lưu ý rằng thuộc về bạn không có nghĩa là bạn tự quyết. Bạn sở hữu tính đúng đắn của nội dung, còn thẩm quyền phê duyệt vẫn nằm phía doanh nghiệp, nên một quy tắc do nhân viên nói ra mà chưa ai xác nhận thì chưa phải là yêu cầu.
Đây là nhóm quyết định bạn có bị cuốn đi hay không, vì phần lớn việc kéo BA ra khỏi ranh giới nằm ở đây chứ không nằm ở nhóm cấm. Thường gặp là:
Vấn đề nằm ở chỗ một việc làm hộ mà không ai gọi tên nó là việc làm hộ thì sau hai lần nó thành việc của bạn, sau năm lần nó biến mất khỏi kế hoạch của người khác, và tới lúc bạn không làm nữa thì mọi người thật lòng nghĩ rằng bạn đang bỏ việc.
Vì vậy tôi đặt ba điều kiện phải có cùng lúc.
Riêng việc nhập liệu hộ khách thì bạn nhận phần thao tác nhưng không nhận phần trách nhiệm, bởi dữ liệu vẫn phải do người của doanh nghiệp đối soát và xác nhận.
Mỗi mục trong nhóm này có chung một dấu hiệu: bạn đang được mời quyết định một chuyện mà mình không có thẩm quyền hoặc không gánh hậu quả.
Thứ nhất là quyết định thay doanh nghiệp về con người và chế tài. Tình huống kinh điển của tôi là kiểm kê kho: khách đếm thực tế xong, nhập số đếm vào màn hình Physical Inventory, trên Odoo 19 cột Difference hiện ra chênh lệch âm vài chục đơn vị so với tồn trên hệ thống, và câu hỏi bật ra ngay trong phòng là bây giờ ai đền.
Câu trả lời của tôi luôn cố định: tôi chỉ đưa ra số liệu và giải thích số liệu đó hình thành thế nào, còn dựa vào số liệu để xử lý ai thì đó là chế tài nội bộ của doanh nghiệp.
Trước đó thì có một việc thuộc về bạn thật, là nhắc khách khoan bấm Apply mà hãy rà lại các phiếu nhập xuất đã làm ngoài thực tế nhưng chưa validate trên hệ thống, bởi tồn trên hệ thống chỉ đổi khi phiếu được validate, và trong các dự án tôi tham gia thì phần lớn chênh lệch tuần đầu là do chứng từ chưa chạy hết.
Thứ hai là cam kết thời gian, giá và phạm vi. Bạn có dữ kiện để ước lượng nhưng không phải người ký, nên câu đúng là ghi nhận yêu cầu, nói rõ nó nằm trong hay ngoài phạm vi, rồi chuyển cho người quản lý dự án hoặc đội sale định giá. Ranh giới giữa một lỗi và một yêu cầu phát sinh đã có bài riêng; ở đây chỉ cần nhớ việc phân loại là của bạn còn việc định giá thì không.
Thứ ba là cam kết kỹ thuật thay đội phát triển. Tôi vẫn nói rằng chế độ nhà phát triển trong Odoo là công cụ của BA chứ không phải của developer, và cách dùng nó đã có bài riêng, nhưng ngay trong công cụ đó đã có một đường kẻ rõ.
Trên Odoo 19, khi rê chuột lên dấu chấm hỏi sau nhãn một trường, khối thông tin hiện ra nhãn, tên trường, model và kiểu dữ liệu, và đó là phần của bạn; cũng trong khối đó có thể có thêm dòng Domain hay Context, nhưng miền lọc và phần logic phía sau là của developer, nên bạn đọc được thì ghi lại để hỏi chứ không tự cam kết sửa.
Thứ tư là ký thay khách hàng: bạn chuẩn bị thứ để họ ký và giải thích cho họ hiểu, nhưng chữ ký phải là của họ.
Với người quản lý dự án, cách tôi phân biệt là hỏi xem thứ đang tranh chấp thuộc về nội dung hay thuộc về nguồn lực.
Khi họ ép một mốc mà bạn thấy nội dung chưa đủ chín thì bạn không có quyền đổi mốc, nhưng bạn có nghĩa vụ nói ra rủi ro bằng văn bản và nói cụ thể là thiếu cái gì. Trong trường hợp công ty không có người quản lý dự án và bạn kiêm luôn vai đó, ranh giới chỉ chuyển vào bên trong một người, nên bạn cần nói rõ mình đang trả lời với tư cách nào.
Người mới thường nghĩ từ chối là nói không, trong khi ở dự án ERP bạn gần như không bao giờ phải nói không với một việc, chỉ cần trả nó về đúng người.
Nguyên tắc đầu tiên là luôn nhận thông tin, không bao giờ nhận quyết định. Không yêu cầu nào bị bỏ ngoài sổ, kể cả yêu cầu ngoài phạm vi, bởi cái bị gạt đi ngay tại chỗ sẽ quay lại vào lúc bất tiện nhất.
Nguyên tắc thứ hai là đổi câu trả lời thành câu hỏi về người có thẩm quyền. Thay vì nói tôi không biết, bạn hỏi ngược rằng bên anh chị ai là người quyết chuyện này; như vậy bạn không trả lời sai mà vẫn giúp hai bên xác định ai phải có mặt trong buổi sau.
Nguyên tắc thứ ba là chuyển hướng có tên người. Nói rằng việc này thuộc bên khác thì chắc chắn làm khách khó chịu, còn nói rằng phần này anh bên đội kỹ thuật nắm rõ nhất và chiều nay em gửi mail để anh ấy trả lời, thì khách thấy vấn đề đang đi tiếp.
Nguyên tắc cuối cùng là viết lại. Mọi thứ nhận thêm, mọi lần chuyển hướng, mọi rủi ro đã cảnh báo đều phải nằm trong một email có ngày tháng, vì đó là thứ duy nhất còn lại khi mỗi người bắt đầu nhớ một câu chuyện khác nhau.
Khi cần cân nhắc nhanh một lời nhờ, hãy chạy qua bốn câu sau:
Ba hậu quả, và chúng đến theo thứ tự nặng dần.
Hậu quả đầu tiên là chất lượng tài liệu tụt xuống một cách âm thầm. Tài liệu là thứ duy nhất trong dự án không ai giục bạn theo giờ, do đó khi bạn quá tải thì nó bị cắt đầu tiên, và phần bị cắt trước nhất luôn là các luồng ngoại lệ chứ không phải luồng chính.
Một quản lý dự án lâu năm ở công ty triển khai nhận xét rằng lỗi hay được nêu trong các buổi nhìn lại cuối sprint là tài liệu chưa đủ quy tắc nghiệp vụ, dẫn tới lúc khách nghiệm thu thì thiếu trường hợp để thử. Theo tôi, nguyên nhân thật thường là người viết đã tiêu hết thời gian vào việc khác.
Hậu quả thứ hai là khách hàng quen coi bạn là đầu mối vạn năng. Chuyện này thoạt nhìn giống một lời khen, nhưng nó tạo ra một dự án chỉ chạy được khi bạn có mặt.
Hậu quả thứ ba nặng nhất, đó là khi vai bị nhòe thì lỗi không còn truy được là của ai. Nếu bạn vừa viết tài liệu, vừa cấu hình, vừa kiểm thử và vừa nhập dữ liệu, thì lúc một con số hiển thị sai trên báo cáo sẽ không ai tách được nguyên nhân là do mô tả sai, do cấu hình sai hay do dữ liệu sai.
Có hai tình huống mà bản đồ ở trên phải nới ra, và tôi nói thẳng để bạn không áp dụng nó cứng nhắc rồi bị coi là khó hợp tác.
Tình huống thứ nhất là hai tuần đầu sau khi hệ thống chạy thật, quãng mà tôi đã viết thành một bài riêng, khi mọi vai đều nhòe và ai rảnh thì làm. Cố giữ ranh giới lúc đó là hại dự án; thứ bạn cần làm là gắn thời hạn cho việc nới, và sau thời hạn đó thì mọi vướng mắc quay lại đi theo kênh chuẩn.
Tình huống thứ hai là công ty quá nhỏ và bạn là người duy nhất làm nghề này. Lúc đó ranh giới thực tế mỏng hơn nhiều so với những gì tôi vừa viết, và cái duy nhất bạn giữ được là phần ghi chép, tức là dù làm hết mọi việc thì vẫn phải tách bạch trong tài liệu rằng lúc này mình đứng ở vai nào. Cách chia ba nhóm việc ở trên cũng chỉ là cách tôi sắp xếp cho dễ nhớ, chứ không phải chuẩn của ngành.
Phần lớn những lần tôi thấy một người mới đánh mất ranh giới không phải vì họ dễ tính, mà vì họ chưa biết đó là một sai lầm, đứng cạnh những sai lầm hay gặp khác của BA ERP mới vào nghề mà tôi đã kể ở bài trước.
Và nếu phải gói cả loạt bài này vào một điều để mang theo vào dự án đầu tiên, thì đó là biết rõ mình đang đối chiếu cái gì, đang chịu trách nhiệm về cái gì, rồi để lại cho cả hai một dòng văn bản có ngày tháng.
Thảo luận (0)
Bạn cần đăng nhập để thảo luận