Tôi bắt đầu nghề PM mon men những task liên quan đến PM 2007, đúng 10 năm làm qua nhiều vị trí khác nhau nhưng cơ bản công việc và nghề chính vẫn dính đến skill PM. Dưới đây chia sẻ một số trigger trong chặng đường làm PM cũng như đánh giá chủ quan của bản thân quá trình thay đổi cách nghĩ, cách làm của một PM.
Duyên:
Trong đời làm PM của tôi có hai cái duyên mà từ đó ảnh hưởng nhiều đến cách hành xử của một PM trong tôi, duyên thứ nhất là “Làm việc trực tiếp với KH”, duyên thứ hai là luôn đảm nhiệm trận đánh “multi-site”, “multi BU”
Cú vấp đầu đời:
Từ 2007-2011 về cơ bản các dự án tôi làm PM có trận thuận lợi, có trận vất vả nhưng luôn cán đích và keep các cam kết với KH, có thành quả nhất định, nhưng đến với dự án SOM 2011 là dự án mất nhiều máu nhất, và cũng là dự án giúp tôi “ngộ” ra PM phải làm gì
Dự án này anh em đặt là SOM và thường gọi nó là “SỚM” mà cuối cùng không hề sớm thế nào, vậy nguyên nhân chính của nó là gì mà nó kéo dài 5 tháng so với plan đặt ra
Nguyên nhân nghe đơn giản nhưng là bài toán muôn thuở “Customer Expectation” & “Acceptance Criteria”
Dự án migration và chuyển đổi hệ thống billing cho KH Telecom, trên nền tảng PHP, Java và Oracle, để chuẩn hóa và đưa ra những yêu cầu căn bản cho hệ thống mới có hai yêu cầu căn bản mà KH yêu cầu chúng tôi phải đưa ra được phương án làm cho KH confirm OK rồi mới start các công đoạn tiếp theo, “Design Phương châm” “Quan điểm test IT”
“Design Phương Châm” Nôm na là tài liệu chỉ ra các quy tắc quy chuẩn về UI/UX, cách thức Output Log, Cách thức Xử lý Exception… mà hệ thống mới phải tuân thủ,
“Quan điểm test IT” làm sao chứng minh được ngoài functional test thì hệ thống đáp ứng được performance, tích hợp giữa các module, và làm sao đảm bảo test như thế là đủ.
Khi nhận yêu cầu nghe tưởng chừng như không có gì khó khăn, nhưng khi thực tế vào làm chúng tôi release 6 version của “Design Phương Châm” và viết đi viết lại “Quan điểm test IT” đâu đó 3-4 lần, tổng cộng để kết thúc các tài liệu cơ bản này đã kéo dài duration dự án thêm 4 tháng. Gốc rễ có lẽ là do một ông KH thuê từ Hitachi về, đảm nhiệm nghiệm thu các sản phẩm này cho FPT và confirm GO tiếp or not, FPT thực sự là rất nỗ lực để đáp ứng yêu cầu của đồng chí bác, năm lần bảy lượt call để hiểu bác muốn gì, PM NenLT và PTL ThanhDQ (Cũng thuộc dạng có số má về Java technical và đồng thời là người kỹ tính trong mọi vấn đề đưa ra và suy nghĩ) gần như 3 tháng liền thứ 7, CN nào cũng thâu đêm để cùng nhau chỉnh sửa update tài liệu ra đúng, ngoài ra còn chị Kumaki là người Nhật rất giỏi VN join cùng để đảm bảo nhưng cứ CN thức release thì thứ 2 là lên họp nghe chuyện ko phải sản phẩm mà bác cần, ko đúng ý. Bên cạnh đó vụ “Quan điểm test IT” cũng tương tự, em Hạnh, Vân cũng tìm đủ thuốc để trị, chị Lan Hương hình như cũng có join tư vấn… nhưng mãi vẫn không ra đúng ý.
Bài học sau vụ SOM:
- Không cố chứng minh cái mình làm ra là cái tốt, cần từng bước từng bước tìm ra khách muốn mình làm gì.
- Mong muốn của KH mỗi ngày một khác, phải tìm mọi cách fix và baseline được mong muốn đúng của KH rồi mới start tạo ra sản phẩm hàng loạt.
- Cho dù mong muốn của KH là clear rồi thì để KH accept sản phẩm mình làm ra phải bỏ công “Engage” KH trong cả quả trình làm, mỗi hôm đưa một ít ra trao đổi hỏi han để clear là cái KH muốn.
- Thành phần tham gia dự án phía KH Nhật luôn luôn phức tạp, cần tiếp cận đúng ai là owner quyết định sản phẩm mình làm ra, đồng thời phải có các điều kiện chặn việc review sản phẩm bị kéo dài.
Trải nghiệm Process cải tiến:
Hai người thầy ảnh hưởng đến cách quản lý của tôi nhất đến từ KH là bác Na của KH P và bác Go của KH S,
Hai bác có hai cách tiếp cận khác nhau, bác Na mềm dẻo bác Go là kỷ luật tuân thủ
Nhưng cả hai đều hướng tới tạo ra process, cách làm việc trong dự án sao cho “Làm đúng từ người làm”
Qua bác Na tôi học được việc Sản phẩm cải tiến, skill của member cải tiến khi mình thực sự phân tích được các bug/comment gặp phải ở dự án trước, và tìm ra được điểm yếu và nguyên nhân gốc gây ra bởi công đoạn nào (Design, Coding, Requirement Understanding, UT, IT…) từ đó sửa cái gốc này bằng training, bằng các điều sai phạm thường gặp cho lần tiếp theo, và việc này lặp lại 2-3 lần liên tục (mỗi lần 3-6 tháng) để cho hệ thống có ảnh hưởng tốt đến cách làm của team, của từng member.
Qua bác Go tôi học được tối ưu hóa từng động tác hàng ngày của member, làm sao đó không có động tác thừa, và sai sót của sản phẩm detect từ sai sót của những hành động nhỏ daily của member, nếu phát hiện và sửa từng sai sót trong động tác member làm, cách member suy nghĩ và làm, cách member hỏi các câu hỏi requirement… sẽ tìm ra lỗ hổng sửa sai và rồi chất lượng sản phẩm tốt lên, rủi ro về tiến độ được tìm ra và có phương án recover, hơn nữa bác Go đã cho tôi cảm hứng thế nào là quản lý định lượng, thế nào là cách đọc sức khỏe của một dự án lớn bằng n parameter để ra quyết định…
Từ những bài học đó, tôi chính thức triển khai rất nhiều tích tụ của 8 năm làm PM vào trận đánh “Mèo Đen” cuối 2015, đầu 2016 và những bài học rút ra từ thành công của dự án tôi có đúc kết lại, nhưng cuối cùng rút ra một điểm rất đơn giản nhưng không dễ thực hiện một cách nghiêm túc, tôi vẫn nghĩ nó đúng cho một PM, “Tuân thủ những điều căn bản” sẽ giúp tạo ra sức mạnh của team, vượt qua thách thức và tránh những sai lầm ko đáng có.
Project management Tips from "Mèo Đen" project
Bản lĩnh của một PM trưởng thành thể hiện ở đâu?
(Chia sẻ từ kinh nghiệm và suy nghĩ của bản thân)
- Baseline và engage được KH đi đúng scope cam kết giữa hai bên.
- Khi có bất cứ yêu cầu nào khác, tuân thủ nguyên tắc ưu tiên cam kết gốc rồi mới xử lý các cam kết mới.
- Luôn đặt tôn chỉ Thành công của dự án = “Hài lòng của Project Team”+”Hài lòng của KH” để focus giải quyết các vấn đề cân bằng lợi ích hai bên.
- Tạo được FW quản lý dễ dùng, dễ triển khai hiệu quả trong team
- Luôn hướng team, member tuân theo những điều cơ bản để làm ra sản phẩm tốt, giảm thiểu vấn đề lặp lại ở member.
- Làm rõ goal có thể đạt được: Goal của dự án luôn được bóc tách và truyền đạt hàng ngày, hàng giờ, tìm mọi phương án đốc thúc mọi công việc của từng member, từng team ngày càng tiến sát đạt được goal này.
- FW quản lý luôn tập trung vào mấy điều:
o Vai trò trách nhiệm của các vị trí trọng yếu trong dự án rõ ràng
o Thông tin liên lạc báo cáo giữa nội bộ team, giữa team với KH luôn được thông suốt, realtime, giảm thiểu thời gian tạo các loại báo cáo trung gian.
o Sức khỏe của dự án luôn được định lượng và hành xử ra quyết định bằng định lượng.
o TL nhiệm vụ chính là giải quyết dependencies daily, các issue gặp phải của member, lo việc ngày mai, ngày kia của team, PM nhiệm vụ chính là giải quyết vấn đề scope và phân tích phán đoán rủi ro để định hướng đi tiếp theo của team. Lo các việc của 1-2 tuần tiếp theo của team.
- Trong mọi hoàn cảnh phải hướng team đến suy nghĩ tích cực, hành động tích cực, tìm ra sớm các yếu tố “Black Swan” gây chết cho dự án để hạn chế hoặc triệt tiêu.
#”Black Swan” có thể là vấn đề công nghệ, giải pháp, có thể là dependencies từ KH, từ các phòng ban liên quan, có thể là member năng lực yếu, member không hợp tác…
Ngoài ra nghề PM thì ngoài kiến thức nền là rất cần thiết, thì trải nghiệm thực tế lại cho bạn những cách hành xử mà ko ai dạy được bạn, vì vậy bạn phải luôn tuân thủ những điều cơ bản một cách linh động, mà tôi gọi nó là “Xoay”
Nghề PM là trưởng thành trong khổ hạnh, hi vọng các bạn tìm được niềm hứng thú thay đổi bản thân, trau dồi nghề để có những trải nghiệm thú vị đúng nghĩa của một PM trưởng thành.
@Le Tec Nen
No comments:
Post a Comment