Công việc đầu tuần của BA
Công việc đầu tuần của BA
Hello anh em. Hôm nay là thứ ba và anh em đang đọc blog thinhnotes.com. Ở bài này mình sẽ kể lại một tuần làm việc của mình dưới vai trò một người làm BA cho anh em cùng nghe.
Một mặt là để “khoe khoang” hằng ngày đến công ty mình làm những gì 
. Mặt khác quan trọng hơn là giúp anh em hình dung rõ được công việc hằng ngày của một người BA là như thế nào. Okay let’s gooo!!!
Nội dung [Hide]
- Ngày làm mấy tiếng?
- Thứ Hai
- 1. Check mail
- 2. Viết các task lên bảng
- 3. Daily Standup Meeting
- 4. Chuẩn bị cho meeting
- 5. Làm tài liệu SRS
- 6. Học nghiệp vụ mới
Ngày làm mấy tiếng?
Một ngày làm việc của mình bắt đầu từ 8g30 sáng đến 6g00 chiều. Nghỉ trưa khoảng 1 tiếng, từ 12g00 trưa đến 1g00 chiều. Tính ra một ngày làm khoảng 8 tiếng đến 8 tiếng rưỡi. Nhưng thời gian thì luôn linh động theo dự án, theo khách hàng và theo work load. Nên nói 8 tiếng vậy thôi chứ cũng linh hoạt tùy mỗi người.
Ngoài ra BA sẽ làm theo dự án. Mà dự án thì có nhiều giai đoạn. Do đó, công việc theo mỗi giai đoạn sẽ khác nhau. Lúc rảnh, lúc siêu rảnh, à nhầm…, lúc bận sấp mặt.
Nên những gì mình chia sẻ dưới đây sẽ đi theo 1 tuần, để anh em có cái nhìn rộng nhất, thay vì 1 ngày nó sẽ hơi cục bộ.
Thứ Hai
Thứ Hai là ngày đầu tuần, bé hứa cố gắng chăm ngoan.
1. Check mail
Đây là công việc hằng ngày mà ai cũng sẽ làm. Thường thì mình dành 3-5 phút để check mail. Ngày check 2 lần: đầu giờ vô làm và tầm 5g00 chiều cuối ngày.
Check để xem có thông tin gì mới không, có gì biến động không. Và quan trọng nhất là check để xem có task gì mới hay phát sinh không.
Sau khi check xong, nếu không có gì đặc biệt thì thôi, tắt Outlook. Nếu có task mới thì note vào để nhớ mà làm. Nhưng note vào đâu?
2. Viết các task lên bảng
Chỗ mình ngồi có 1 cái bảng nhỏ. Thường thì mình sẽ viết lên đó từ 3-4 tasks hoặc công việc sẽ làm trong ngày hôm đó.
Task là những việc cụ thể: như làm test case, vẽ Business Process, làm tài liệu SRS, học nghiệp vụ mới, vâng vâng mây mây.
Còn “công việc” là những thứ khá chung chung, trừu tượng như: dự án ABC, training XYZ. Các task mà mình không rõ là trong ngày hôm đó sẽ làm được bao nhiêu thì thường mình ghi vậy cho dễ hình dung.
Thực sự thì có 1 vài tuần, à nhầm, 1 vài ngày lười quá nên mình cũng không note thế này.
3. Daily Standup Meeting
Daily là hằng ngày, standup là đứng, meeting thì là meeting. Gom lại nôm na là đứng họp mỗi ngày.
Sáng thì mấy anh em sẽ hẹn nhau khoảng 9g00 hoặc 9g30 ra chỗ nào đứng họp. Họp rất nhanh thôi, tầm 5 phút, maximum là 10 phút.
Mục đích là để nói cho nhau nghe ngày hôm đó sẽ làm gì. À hôm nay tui làm cái này, rồi tới cái này. Để cả team cùng biết công việc, tiến độ của nhau. Nếu có trục trặc gì thì còn biết đang ở đâu để mà support. Người này mà nghỉ thì có người khác đúp vô liền.
Tại sao không phải “ngồi họp” mà là “đứng họp”. Vì đứng sẽ làm cho tâm lý mình chủ động, thoải mái và trình bày được nhanh hơn. Không dễ bị ù lì như ngồi.
Vì meeting daily nên gap công việc giữa các anh em trong team không nhiều. Nên cũng dễ thay thế nhau làm. Vì ai cũng hiểu công việc của nhau hết. Đỡ mắc công phải transfer lại nhiều. Mà Daily Standup Meeting thì vô dự án mới làm, chứ bình thường không có dự án mình cũng không làm cái này.
Stand Up Meeting (nguồn ảnh: agileconnection.com)
*Note: Check mail, viết lên bảng các task cần làm và Daily Standup Meeting là những việc làm hằng ngày. Nên các ngày còn lại là auto làm, mình sẽ không đề cập nhé.
Sau khi làm 3 task nhỏ xíu này xong là khoảng 9g30, tiếp theo mình sẽ.
4. Chuẩn bị cho meeting
2g00 chiều thứ 3 tuần sau mình có meeting nên hôm nay mình sẽ chuẩn bị cho buổi này. Cụ thể buổi meeting này sẽ review lại tiến độ dự án đang làm tới đâu rồi.
Về chi tiết thì mình sẽ chuẩn bị slide review lại những gì team đã làm, cho PM với anh em Dev cùng nghe. List ra những requirement đã thống nhất với khách hàng hoặc những open-points.
Những function nào mình đã deliver cho họ, feedback của họ ra sao. Những points nào mình bị trễ với khách hàng. Những points nào bản thân mình bị trễ deadline. List ra hết để anh em có cái nhìn tổng quan, cùng nhau bàn kế sách tiếp theo.
Tuy nhiên quan trọng nhất là mình phải list được ra những khó khăn. Đầu tiên là những khó khăn mà cá nhân mình đang gặp phải.
Điểm nào chưa rõ, điểm nào chưa làm được thì raise lên để mọi người cùng giải quyết. Nếu được thì gom luôn những khó khăn của Dev lúc làm việc chung, để trình bày cho nhau cùng hiểu luôn.
Ở phần này có 2 điều quan trọng mình muốn lưu ý với anh em.
Một là mình phải để ý được mục đích của buổi này là gì, để biết ngõ chuẩn bị cho hợp lý.
Hai là mình dùng Power Point, Excel với Word rất nhiều để chuẩn bị cho task này. Nên để làm việc hiệu quả thì anh em cố gắng dùng 3 tool này cho quen tay. Hotkey nhớ nằm lòng, bấm cho nó nguy hiểm
Task này chiếm khoảng 30 đến 45 phút gì đấy (do vừa làm vừa rong chơi là cà nên cũng khá tốn thời gian). Làm xong là đến khoảng 10g30. Còn 1 tiếng rưỡi nữa là đến 12g nghỉ trưa. Mình sẽ viết tiếp tài liệu SRS cho dự án Loyalty trong 1 tiếng rưỡi này.
5. Làm tài liệu SRS
SRS là viết tắt của Software Requirements Specification. Mặc dù mình làm triển khai và dùng tài liệu FRD (Funtional Requirement Document) là chủ yếu. Nhưng tài liệu nào đáp ứng được nhu cầu sử dụng thì quất thôi.
Mình đã từng làm 1 dự án triển khai mà đặc tả requirement không dùng FRD, FDD hay SRS gì hết. Mà đơn thuần chỉ là những bản vẽ BPMN, gom lại hết bỏ vô file pdf, gọi là Solution Design. Đơn giản vậy thôi nhưng lại hiệu quả vô cùng
Task này thì mình dùng Microsoft Visio và Word là nhiều. Visio thì để vẽ quy trình. Đây là một trong những task khó nhằn nhưng mình thích nhất.
Vì mục đích của công việc này là thể hiện những yêu cầu của khách hàng thông qua hình ảnh và văn bản, để anh em trong team cùng hiểu. Nên nó đòi hỏi mình phải hiểu đúng requirement (mà mình với khách hàng đã thống nhất). Và thể hiện nó một cách rõ ràng và dễ hiểu nhất.
Còn để có được requirement, mình và team sẽ phải tư vấn và guide khách hàng trong những buổi workshop lấy yêu cầu. Để từ đó tối ưu hóa quy trình làm việc của họ. Để requirement được tối ưu và hiệu quả nhất.
Nhìn chung, điều quan trọng nhất của task này là phải thể hiện rõ yêu cầu. Để anh em Dev nhìn vô là có thể hiểu và làm tiếp được. Ngoài Dev ra thì còn nhiều Stakeholders khác cũng cần xem tài liệu này, như PM, QA, QC. Chưa kể phải gửi cho khách hàng ký nữa. Nên rất quan trọng.
Có một số điểm mình thấy cần thiết bao gồm: thành thục kỹ năng vẽ trên Visio (hoặc bất kỳ tool nào). Nắm rõ các loại Model, mục đích sử dụng và các quy ước của nó. Bên cạnh đó là kỹ năng Mai-rô-sốp Quợt cứng cứng xíu. Dùng các thẻ Heading, Theme, Reference, căn Layout, Page, Review này nọ thứ dữ vô để tiết kiệm thời gian. Nhớ Ctrl+S liền tay để tránh mất dữ liệu.
Ngoài ra anh em cũng cần chú ý đến convention name (ký hiệu đặt tên) cho các tệp tài liệu, để dễ quản lý. Bên cạnh đó là nhớ đánh dấu version đàng quàng, cẩn thận. Cái nào baseline rồi thì lên version liền. Sau này cần thì dễ dàng trace lại.
Vẽ process với làm tài liệu tới 12g00 rồi đi ăn cơm. Cơm nước xong xuôi, mình ngủ trưa tới 1g00 chiều dậy làm tiếp. Và nguyên một buổi chiều này mình sẽ dành để học nghiệp vụ mới, kaka.
6. Học nghiệp vụ mới
Mình đang học nghiệp vụ Customer Service. Cái này là self-task nên quan trọng nhất vẫn là mình plan sao để học cho hiệu quả thôi. Mình sẽ lên Microsoft Dynamics Learning Portal (DLP) để tìm hiểu về các nghiệp vụ mới này.
Sau khi xem trên DLP tầm 30 phút thì mình lên mạng kiếm một số case study thực tế có liên quan về đọc. Rồi bắt chước “làm theo” trên một system trial nào đó.
Làm theo có nghĩa là sẽ phải configure theo yêu cầu của case study. Tự input dữ liệu vào để hiểu các yêu cầu cơ bản, vâng vâng. Mục đích là phải tìm hiểu được hệ thống Customer Service có những phần gì quan trọng, hoạt động ra sao và tại sao nó lại hoạt động như vậy.
Công việc này cứ lặp đi lặp lại tới chiều rồi về thôi 
Trước khi về mình sẽ check mail thêm phát nữa để không bỏ sót tin hót nào trong ngày.
Anh em đọc tiếp 4 ngày còn lại trong tuần ở 2 phần dưới đây nhé.
- Giữa tuần lấy requirement và các task quan trọng
- Cuối tuần Happy Hours
Bái baiii.
Nguồn: thinhnotes.com
