Bạn vẫn xem được các bài đã đăng mà không cần đăng nhập.
Một tuần của BA ERP không cố định. Cùng một người, tuần khảo sát, tuần viết tài liệu và tuần trước go-live là ba cái lịch khác hẳn nhau.
Ba người cùng chức danh BA ERP, cùng một công ty triển khai, cùng thâm niên, mở lịch tuần của họ ra cạnh nhau thì bạn sẽ tưởng đó là ba nghề khác nhau.
Lịch của người thứ nhất kín đặc những buổi hai tiếng mang tên phòng ban, xen giữa là các khoảng trống ba mươi phút không đủ để bắt đầu việc gì cần tập trung. Lịch của người thứ hai gần như trắng, chỉ có một buổi mười lăm phút mỗi sáng và một buổi dài vào chiều cuối tuần, phần còn lại là những khối thời gian không đặt tên. Còn người thứ ba thì lịch không do anh ta đặt, các buổi rơi vào những khung giờ do ca làm việc bên khách quyết định, vì đó mới là lúc người dùng bên khách rảnh.
Cả ba đều đang làm đúng phần việc của mình. Khác biệt không nằm ở con người mà nằm ở chỗ dự án của họ đang đứng ở đoạn nào.
Do đó, câu hỏi một tuần của BA ERP trông như thế nào gần như không trả lời được nếu không nói rõ tuần đó rơi vào giai đoạn nào, bởi danh sách đầu việc trong một tin tuyển dụng thì trải đều toàn bộ vòng đời triển khai, trong khi thực tế chúng dồn thành cục và chỗ chúng dồn lại quyết định tuần của bạn dễ chịu hay mệt. Cách đọc ra vai thật đằng sau một cái tên là chủ đề của một bài riêng.
Cần nói thẳng một giới hạn ngay từ đầu, rằng ba lát cắt dưới đây dựng lại từ quy trình triển khai tôi vẫn dùng cùng cách tổ chức công việc theo sprint mà một quản lý dự án lâu năm ở công ty triển khai kể lại, chứ không phải nhật ký một tuần cụ thể, và tôi không có số liệu bấm giờ nên mọi tỷ trọng trong bài đều là định tính.
Một dự án ERP đi qua các giai đoạn theo trình tự khá cố định, từ chuẩn bị và kick-off sang khảo sát, sang cấu hình và lập trình, rồi tới kiểm thử, go-live và bảo hành; bản đồ đầy đủ của các bước đó là chủ đề của một bài riêng.
Thứ đáng nhìn là ba đại lượng đổi theo từng giai đoạn: ai đặt lịch cho bạn; bạn lấy gì làm dấu hiệu hôm nay đã xong việc; và câu hỏi đổ về bạn đến từ phía nào. Đầu dự án, người đặt lịch là khách hàng, dấu hiệu xong việc là một quy trình được xác nhận, và câu hỏi đến từ khách. Giữa dự án, bạn tự đặt lịch, dấu hiệu xong việc là một hạng mục rời khỏi danh sách chờ, và câu hỏi đến từ đội phát triển. Cuối dự án thì chính hệ thống đặt lịch, dấu hiệu xong việc là số vướng mắc còn mở giảm xuống, và câu hỏi đến từ mọi hướng.
Tuần này là tuần bạn ít được chọn giờ nhất, vì không thể gom toàn bộ nhân sự của khách vào một buổi khi họ vẫn phải làm việc chính, nên lịch buộc phải xé nhỏ theo phòng ban, và điều mà người mới hay tính sai chính là chi phí thật của một buổi khảo sát bị xé nhỏ như vậy. Trước buổi họp, bạn phải xem sơ đồ tổ chức để biết mời ai, đọc trước những quy trình khách đã có sẵn để chỉ hỏi xác nhận thay vì hỏi lại từ đầu, và gửi bộ câu hỏi đi sớm để họ kịp chuẩn bị biểu mẫu. Sau buổi họp, bạn còn phải dựng lưu đồ, viết biên bản, gửi email cho cả hai phía và đặt hạn cho từng thứ khách hứa gửi lại. Cộng cả phần trước và phần sau vào thì một buổi hai tiếng ăn hết khoảng nửa ngày công, nên bốn buổi khảo sát là một tuần đã đầy, trần hai buổi một ngày chỉ là trần của một ngày, còn trần của cả tuần thấp hơn nhiều vì phần hậu kỳ cộng dồn, còn ai xếp năm buổi thì phần hậu kỳ sẽ dồn sang tuần sau thành nợ.
Trong tuần này bạn hầu như không đụng vào hệ thống, trừ lúc cần kiểm chứng nhanh một tính năng để trả lời tại chỗ, và việc viết cũng chưa phải viết đặc tả mà là viết lại lời người khác cho đúng ý họ, một loại việc mệt theo kiểu khác vì nó đòi chính xác chứ không đòi sáng tạo.
Ngoại lệ đáng chú ý nằm ở kho và sản xuất. Hai mảng này phải xuống tận nơi quan sát cách họ bố trí kệ và cách hàng đi trong xưởng, nên một buổi khảo sát kho ăn nguyên ngày kể cả di chuyển, và tuần đó bạn chỉ còn chỗ cho hai buổi khác. Cách điều phối bên trong một buổi như vậy là chủ đề của một bài riêng về workshop khảo sát.
Sang giai đoạn cấu hình và lập trình thì lịch đảo chiều, và đây là quãng duy nhất trong dự án bạn sở hữu phần lớn thời gian của mình, nên nhịp chung của tuần thường chỉ còn gồm một buổi ngắn mỗi sáng để cả đội đồng bộ, một buổi làm rõ giải pháp trước khi một nhóm hạng mục được đưa vào phát triển, và một buổi review nội bộ trước khi đem bản final ra trình cho khách. Phần còn lại là những khối thời gian dài, và bạn cần giữ chúng liền mạch, bởi viết đặc tả là loại việc bạn cần tập trung.
Điểm khác biệt lớn nhất so với tuần khảo sát là xuất hiện một loại việc hoàn toàn mới, đó là trả lời câu hỏi của team. Tài liệu dù viết kỹ tới đâu cũng không phủ hết mọi tình huống, nên dev sẽ hỏi lại, và nếu bạn không trả lời trong ngày thì họ tự suy đoán business rule theo cách hợp lý nhất với họ, đến vòng kiểm thử mới lộ ra là hai bên hiểu khác nhau, lúc đó sửa đắt hơn nhiều so với việc bạn dừng năm phút. Đây là lý do một tuần viết tài liệu thuần túy chỉ tồn tại trên kế hoạch.
Tuần này cũng là lúc bạn thật sự ngồi trên hệ thống: bật tắt tính năng theo phương án đã chốt, dựng dữ liệu mẫu đủ để chạy thử một luồng trọn vẹn, chụp lại màn hình để đưa vào tài liệu; tài liệu nào phải ra ở giai đoạn nào thì đã có một bài riêng liệt kê đầy đủ.
Chính vì vậy mà bộ kế hoạch mẫu tôi đang dùng tách hẳn hai bản, một cho dự án chỉ cấu hình và một cho dự án có lập trình. Nếu dự án của bạn thuộc nhóm đầu thì giai đoạn này ngắn hơn hẳn và tuần của bạn trượt rất nhanh sang lát cắt thứ ba, còn thuộc nhóm sau thì bạn sống ở đây vài tháng.
Tới giai đoạn này thì quyền kiểm soát lịch rời khỏi tay bạn và tuần của bạn chuyển từ thời gian sản xuất sang thời gian phản ứng, bởi người dùng bên khách vào hệ thống theo ca làm việc của họ chứ không theo giờ hành chính bên bạn, nên vướng mắc không đến đều mà đến thành đợt; mỗi đợt như vậy bạn phải đọc, phân loại xem là do dữ liệu, do cấu hình, do bug hay do người dùng chưa biết thao tác, rồi mới chuyển cho đúng người. Phân loại sai một lần là mất vài ngày chờ cho một việc tự bạn xử lý trong mươi phút.
Có một quy tắc lịch rất nhỏ nhưng đáng ghi vào kế hoạch: ngày có buổi kiểm thử hoặc buổi đào tạo thì tuyệt đối không release tính năng mới, hoặc nếu có, cần có 2 môi trường riêng biệt. Lý do là bạn sẽ không phân biệt được vướng mắc do người dùng thao tác hay do bản vừa lên, và mất cả buổi tìm thứ vốn không cần tìm.
Nửa cuối của tuần trước go-live thì lịch bị chiếm bởi những việc không thể lùi: chuyển dữ liệu lên bản chạy thật, đối soát lại, xác nhận trạng thái sẵn sàng của cả hai phía. Hai lớp kiểm thử trước go-live đã có bài riêng, cũng như nhịp làm việc của hai tuần đầu sau go-live, nên ở đây bạn chỉ cần biết đó là quãng mà mọi khối thời gian dài trong lịch đều biến mất.
Có một nhóm việc chiếm thời gian thật nhưng không xuất hiện trong bất kỳ tin tuyển dụng nào, và người mới thường bị vỡ kế hoạch vì không chừa chỗ cho chúng.
Nhóm thứ nhất là theo đuổi những thứ khách đã hứa gửi. Sau mỗi buổi khảo sát luôn còn lại một danh sách biểu mẫu, mẫu báo cáo và quy tắc mà nội bộ họ phải thống nhất lại, và nếu bạn không đặt hạn rồi nhắc đúng hạn thì tới lúc viết tài liệu bạn sẽ thiếu đúng những mảnh ghép này. Nhóm thứ hai là giữ cho môi trường dùng để trình bày luôn sạch và chạy được, việc không ai giao nhưng hỏng thì bạn là người đứng trước khách. Nhóm thứ ba là viết lại vướng mắc của người dùng thành mô tả có ngữ cảnh, tức là bổ sung ai gặp, ở màn hình nào, thao tác gì và kỳ vọng ra sao, vì thiếu bốn thông tin đó thì không ai xử lý được. Nhóm thứ tư là cập nhật tài liệu mỗi lần có gì đó được chốt khác đi, việc nhàm chán nhưng chính nó là căn cứ khi hai bên nhớ khác nhau về một quyết định cũ.
Trong trường hợp bạn chạy hai dự án ở hai giai đoạn khác nhau, hoặc dự án chia phase mà phase trước đã go-live trong khi phase sau mới khảo sát, thì tuần của bạn là bản trộn của cả ba lát cắt, và đây là kiểu tuần khó nhất chứ không phải kiểu tuần bận nhất.
Lý do là ba lát cắt đòi ba chế độ làm việc trái nhau: khảo sát cần bạn mở, nghe và chưa vội kết luận; viết tài liệu cần bạn đóng và liền mạch; trực kiểm thử cần bạn phản ứng nhanh và cắt ngang được bất cứ lúc nào. Chuyển qua lại giữa ba chế độ đó trong cùng một ngày thì cái mất không phải là số giờ mà là chất lượng của phần cần tập trung nhất, nên cách xử lý thực tế là gom, chẳng hạn dồn toàn bộ buổi họp vào hai ngày để ba ngày còn lại đủ dài mà viết.
Nếu bạn vừa nhận dự án đầu tiên, hãy làm bốn việc sau trước khi tuần mới bắt đầu:
Bốn việc này không làm tuần của bạn nhẹ đi, nhưng chúng làm cho phần thời gian trôi mất trở nên nhìn thấy được, và một tuần hỏng vì lý do nhìn thấy được thì lần sau sửa được. Nên nhớ rằng thứ khiến người mới đuối trong dự án ERP hiếm khi là độ khó của nghiệp vụ, mà là việc không lường trước tuần này mình sẽ bị kéo về hướng nào.
Phần còn lại của câu chuyện không nằm trong lịch, mà nằm ở chỗ trong tất cả những việc trên, thị trường thật sự trả tiền cho phần nào.
Thảo luận (0)
Bạn cần đăng nhập để thảo luận