Qui trình quản lý cũ kỹ:
+ Công ty công nghệ mà thiếu quá nhiều phản quản lý bằng ứng dụng (sử dụng giấy văn bản quá nhiều)
+ Công ty có quá nhiều thứ mang tính hình thức mà không chú trọng chất lượng và thực tiễn
+ Quản lý chất lượng: Đề cao nhiều tiêu chí chất lương ISO muốn tất cả mọi người theo nhưng không để tâm nghiên cứu giải pháp ứng dụng phù hợp với thực tiễn của dự án. Điều chúng ta muốn và điều chúng ta đang thực hiện giống như giữa giấc mộng và khi choàng tỉnh dậy.
- KPI xây dựng sơ sài. Việc đánh KPI có quá nhiều bất cập và nặng cảm tính khi tiêu chí đánh giá được xây dựng từ cảm nhận PM. Cả năm có cày bừa chăm chỉ và gánh vác cho cả team nhưng chỉ cần có issue hay conflict với PM thì xác định "Đốn củi cả năm mà cháy trong 1 giờ". Chuyện đời : 1 ông sếp tốt tính mà trong mắt nhân viên còn bị phàn nàn thì 1 năm với nhiều dự án như vậy bạn có bao nhiêu tự tin rằng bạn sẽ nhận được đánh giá tốt trong con mắt của tất cả PM "thượng vàng hạ cám" ?
+ KPI phải được đánh già team leader nếu có cùng với tiêu chí đánh giá được nhập và chọn từ 3-4 bạn DEV trong team và cuối cùng là đánh giá từ PM. Tổng cộng từ nhiều nguồn mới cho ra kết quả khách quan. Nếu không 1 nhận định cá nhân của PM có thể khiến 1 bạn DEV giỏi ra đi.
+ Không có Star-Performer cuối năm tạo động lực phấn đấu so kè giữa các anh em trong dự án
+ Không có tiền Key nóng cho DEV có biểu hiện xuất sắc trong các dự án rủi ro
- PM: có quá nhiều vấn đề bất cập trong điều hành do trình độ, năng lực và tính cách.
+ Không có kênh đánh giá, điều tra feedback về hành vi và thái độ của PM với DEV và dự án từ DEV va team leader, TA : 1 bạn DEV tồi có thể tạo 1 đống issue cho dự án nhưng dự án vẫn tiếp tục nhưng 1 bạn PM tồi có thể khiến anh em rời khỏi công ty, dự án rời vào rủi ro thậm chí close dự án. Nếu thành công được quy cho tài lãnh đạo của PM thì khi dự án rủi ro và có nhiều vấn đề thì lại quy tội DEV ?
+ Thái độ bộp chộp, lúng túng của nhiều PM trẻ khi hệ thống có issue
+ PM trẻ : cố chấp, không lắng nghe đóng góp, giải pháp của các anh em có kinh nghiệm - SSE hay PSP trong team. Không có tinh thần team-work
+ Nói rành rọt về Agile/Scrum nhưng thái độ hời hợt, tùy tiện thay đổi không tôn trọng tinh thần Agile/Scrum. Nặng về mặt hình thức nhưng chất thì chỉ đạt được 40-50%. Không khác gì con cọp giấy
+ Sprint Planning thiếu Rooming hay điều tra tìm hiểu công việc trong sprint trước đó. Định thời gian estimation hay điền due-date không có cơ sở. Hoạch định sprint quá hời hợt, qua loa, không nghiêm túc
+ Việc thay đổi request từ phía khách hàng trong sprint không được tạo thành sub-task. Thời gian xử lý change request dẫn tới bị over-due-date
+ Việc thay đổi thiết kế hệ thống ảnh hưởng tới thời gian release cuối cùng nhưng không được hoạch định hay tính lại thời gian release. Điều này dẫn tới anh em phải OT ko cần thiết vì sai sót trong hoạch định
+ Đá lộn sân : PM vốn ko giỏi về technical nhưng tích review code, thích đưa ra giải pháp trong khi team có TA.
- Line Manager: mờ nhạt trong kênh phản hồi từ phía các DEV trong line.
+ Thiếu sự kết nối giữa Line Manager va QA: Nhận phản hồi từ DEV nhưng không liên kết được với các anh chi QA quản lý chất lượng dự án để giải quyết bức xúc, xử lý thiếu tinh tế hay sai sót từ PM, hay rủi ro của dự án
+ Ko có action sau khi nhận được phản ánh từ DEV
Chờ quá lâu để nhận được tiền OT
Thời gian OT nhiều hơn nhưng vẫn chỉ nhận được theo định mức
