Ưu điểm
Có các khóa học đào tạo tốt
Cập nhật thông tin công nghệ
Bảo hiểm 100%, phép năm 14 ngày
Nhược điểm
Quy 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ó lỗi hay mâu thuẫn với quản lý dự án 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ả quản lý dự án "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ừ quản lý dự án. 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 quản lý 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
- Quản lý dự án: 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 phản hồi về hành vi và thái độ của quản lý dự án với DEV và dự án từ DEV va team leader, TA : 1 bạn DEV tồi có thể tạo 1 đống lỗi cho dự án nhưng dự án vẫn tiếp tục nhưng 1 bạn quản lý dự án 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í đóng dự án. Nếu thành công được quy cho tài lãnh đạo của quản lý dự án 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 quản lý dự án trẻ khi hệ thống có lỗi
+ Quản lý dự án 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
+ Lập kế hoạch Sprint thiếu chỗ ở hay điều tra tìm hiểu công việc trong sprint trước đó. Định thời gian ước lượng hay điền ngày đáo hạn không có cơ sở. Hoạch định tăng tốc quá hời hợt, qua loa, không nghiêm túc
+ Việc thay đổi lời yêu cầu từ phía khách hàng trong tăng tốc không được tạo thành nhiệm vụ phụ. Thời gian xử lý yêu cầu dẫn tới bị quá hạn
+ Việc thay đổi thiết kế hệ thống ảnh hưởng tới thời gian giải phóng cuối cùng nhưng không được hoạch định hay tính lại thời gian giải phóng. Điều này dẫn tới anh em phải OT không cần thiết vì sai sót trong hoạch định
+ Đá lộn sân : Quản lý dự án vốn không giỏi về kỹ thuật 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
+ Không có hoạt động 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
Tweet
Facebook
Copy Link
