# CHIA SẺ KINH NGHIỆM - ĐÔI BẠN CÙNG TIẾN

## 1. Vai trò, trách nhiệm của PMO
### 1.1 PMO trên mạng viết
- Tham khảo bài viết: https://timviec365.vn/blog/pmo-la-gi-new8339.html
- PMO mang ý nghĩa rộng hơn 1 cá nhân, kiểu là phòng ban (trong đó bao gồm nhiều loại quản lý nhưng mục đích chính vẫn là giải quyết các vấn đề về nguồn lực, chi phí, tăng hiệu suất công việc, dẫn dắt project đi đến thành công)
### 1.2 PMO các dự án công ty mình
#### 1.2.1 Định nghĩa của sếp Aida về vai trò của PMO aka comtor tiến hóa
Người có vai trò liên quan đến các yếu tố dưới đây:

+ Requirement management: Là người hiểu rõ nhất những yêu cầu của khách hàng. Mình như một người đại diện cho khách hàng, hiểu khách muốn gì cần gì, sau đó truyền đạt lại cho engineer hiểu.
+ Quality management: quản lý danh sách bug phát sinh, gòi thêm testcase nếu có. Với mỗi 1 bug đều cần làm rõ cách tái hiện như nào, root cause là gì, đưa phương án fix bug, sau khi fix bug có bị conflict chỗ nào không, cách rút kinh nghiệm để sau này ko xảy ra bug tương tự nữa.
+ Schedule management: Nắm rõ việc cần làm của từng sprint, lên schedule cho các task trong 1 sprint, sau khi ok với plan đã lên, member bắt tay vào làm task thì mình bắt tay vào confirm tiến độ task trong sprint đó. Nói chung là làm sao cho nó chạy theo đúng lịch đề ra là best =))

Sau khi có 1 buổi one on one meeting với sếp, Mị hiểu thêm được các nhiệm vụ dưới đây nữa nè:

- Team building: Xây dựng team sau khi nhận được requirement của khách hàng (như kiểu xây cái móng nhà trước khi bắt tay dô xây nhà á). Khi dự án start thì take care các member trong team, training member các kiểu túm lại cho member phát triển bung lụa luôn thì càng tốt.
- Communication management: đưa ra quyết định hình thức commnunicate với khách hàng và với team member (dí dụ: đề xuất với khách là nên có weekly meeting, nên có daily report...từ rày về sau chat qua kênh nào, v.v cái này nên tùy dự án và nguyện vọng của cả khách lẫn member dí dụ như cái Chatwork tuy nó xấu nhưng khách Nhật thích lắm nên động viên member Diệt Nam hãy tập yêu Chatwork chẳng hạn), control mọi thứ liên quan đến commnunication.
- CI CD -> mấy cái cách release version các thứ, cái này chị cũng lơ tơ mơ
- Tham khảo thêm file này (slide thứ 2 nha còn cái slide 1 chị tự đánh giá nên em có thể ignore =)) ) https://docs.google.com/presentation/d/1cVUT5rKQxLATKjD1u4QLkHqN9ZqKUWbUL1t_cX-O-Tk/edit#slide=id.p
- Tham khảo thêm file này nữa cột G, H
https://docs.google.com/spreadsheets/d/1E-9pbP0dlcTcnHbufs7Edgoy_G1tuXl1tuHfoxwvcn8/edit#gid=442062760

#### 1.2.2 Cảm nhận của Mị (trong trường hợp mình ko hiểu sâu về kỹ thuật)
- Ờ thì nói chung tiến hóa rồi nên nhiêu đó vai trò cũng thấy ổn.
- Đó là lý thuyết thôi. =))
- Để làm được những vai trò đó yêu cầu comtor phải học rất nhiều các kỹ năng: đọc tài liệu, đọc hiểu requirement, ko ngại hỏi, research kiến thức mới đặng hiểu sương sương member nói về cái gì, confirm với member và viết QA 1 cách cụ thể nhất để khách trả lời nhanh gọn lẹ, team work tốt với leader. Và đặc biệt là...
- [x] có mindset của 1 khách hàng để hiểu những yêu cầu khó hiểu của họ
- [x] có mindset của 1 engineer để bình tĩnh trước những member ko chịu viết test code và những member không có khả năng diễn đạt :)
- [x] có mindset của 1 tester đặng tìm cho ra lỗi thà test nhầm còn hơn bỏ sót hoặc nếu ko test được thì phải làm sao cho có 1 ai đó make sure là đã test kĩ chứ ko có ai chịu test là mốt fix bug mệt mỏi á
- [x] có mindset của 1 end user để sửa lại mấy cái giao diện thấy ghê mà nguyên đám ở trển làm ra =)))))
## 2. Cách thức quản lý task trong dự án LRM
### 2.1 Đặc điểm sprint
- Sprint có độ dài 1 tuần. 1 sprint thường có 4-5 tasks.
- Mỗi 1 sprint ứng với 1 milestone trong Backlog để quản lý task dễ hơn (nó lọc task theo đúng milestone cho mình)
- Scrum mtg với khách hàng 1 lần vào chiều thứ 4
- Sau Scrum mtg với khách, tụi chị có 1 cuộc meeting nội bộ (Feedback meeting)
- Trong scrum, mình sẽ báo cáo 3 nội dung chính là task đã làm xong, task đang làm + issue hiện có, task sẽ làm cho sprint tiếp theo.
- Trong phần task đã làm xong, chị sẽ trực tiếp demo trên môi trường test của team Vietnam. Demo xong thì nghe feedback của khách, khách kêu sửa gì thì note dô rồi lát hồi Feedback meeting truyền đạt lại.
Sương sương dị hoi.
### 2.2 Tips quản lý task đi theo schedule hoặc ít nhất khi nó ko đi theo schedule, khách hàng vẫn không hốt hoảng
- Duy trì số lượng task trong 1 sprint same same nhau
- Trường hợp số lượng task nhiều hơn dự kiến (ví dụ khách yêu cầu làm nhiều hơn bình thường) thì hỏi lẹ độ ưu tiên của task. Task nào gấp, độ ưu tiên cao thì xếp lên đầu, nhờ member estimate thời gian thực hiện. Ví dụ có tổng cộng 8 tasks A B C D E F G H. Hỏi khách giờ muốn làm gì trước. Sau đó nhờ member estimate 8 tasks đó, lên plan phù hợp với độ ưu tiên và thời gian đã estimate, gởi khách duyệt. Khách ok -> quất
- Mỗi ngày nên có daily scrum nội bộ với member để hỏi coi có ai đang bị ăn hành không. Nếu ko thì gặp nhau cũng dui rồi, nếu có thì hỏi coi issue đang gặp là gì, mình có thể đưa ra lời khuyên tùy hoàn cảnh cụ thể =))
- Tạm thời chị nhớ có nhiêu đó hà xíu nhớ nữa thì quay lại note lại. Chúc em đọc vui và k bị hoa mắt :vvv