Review Company NashTech (Vietnam)

nay đi year end party tiki tự nhiên lại nhớ nashtech :v event YEP tiki tổ chức dở kinh khủng :v :v

rì viu công ti nhe nhẹ

Sao có reCaptcha rồi mà bot nó vẫn vào comment được thế này hả mấy ông admin :))

Bên đây làm cho khách hàng bên nào vậy vậy hả các bác?

– Benefit : Tốt
– Salary : Khá tốt
– HR : Deal lương khá tốt nên anh em cần vững lòng nếu trình độ cao
– RMO : Ko nên dễ dãi chấp nhận dự án nào cũng làm từ RMO nếu ko muốn bị tụt hậu hay làm ở thời gian biểu theo ca ko bình thường
– Project Process : Tiến trình quản lý dự án cũ kỹ, hình thức ko thích nghi với thực tiễn.
– IT System :
+ CPU con nhà nghèo : RAM cho 1 CPU hiện tai la 8GB. DEV hiện tại vẫn chỉ có 1 màn hình. Muốn có màn hình thỉ phải xin và tùy PM có đồng ý hay ko
+ Quá chậm nâng cấp. Hệ thống quản lý tạo ticket bằng mail là ko thể chấp nhận với số lượng nhân viên hơn 600 người
+ Hệ thống quản lý không tập trung, xử lý chậm chạp
– Line Manager : hay còn gọi là anh chàng họ “hứa”
+ Phỏng vấn đòi hỏi công nghệ này nọ nhưng khi vô thì công nghệ cũ thậm chí co từ thời 2010
+ Hứa sẽ đưa bạn vào dự án ngon, công nghệ cao nếu bạn làm dự án cùi tạm thời nhưng khi bạn xin ra khỏi dự án thì vui lòng chờ 1 năm hay 1 năm rưỡi sau
Và nế u bạn vẫn kiên quyết ra khỏi dự án thì bạn hãy nhận thức 1 rủi ro lớn hơn là PM đó sẽ rêu rao và phàn nàn với PM của dự án sắp tới sẽ chọn bạn
=> Điều đó có nghĩ là họ muốn bạn nghỉ luôn đi chứ ko có cơ hội sang dự án khác đâu. Trong trường hợp Line Manager sẽ đứng về phía cty va PM để đảm bảo rằng sự ổn định và lợi ích của dự án là cao nhất.
+ Hứa làm Pet/Demo project để nâng KPI nhưng khi PM đá*h giá thấp hay ko cao thì mọi sự quyết định đều ko ở nơi anh ấy (10% có ý nghĩa gì trên 100%). Hát mãi bài “Cuộc tình dù có dù ko thì người mang thai vẫn là người con gái”
+ RMO hay Line Manage la người giới thiệu bạn vô dự án nhưng PM hay team leader là người quyết định (PM ko có khả năng đá*h giá được Level của bạn chỉ có thể đá*h giá bạn có phải là nhân tuyển phù hợp với dự án (Nếu anh ấy mà nghe review xấu từ PM trước của bạn thì khả năng bạn fail la 70%-80%))
– PM:
Quá dựa dẫm trên tiến trình quản lý hệ thống cũ kỹ, các PM trở nên thụ động, máy móc. Ngoại trừ các PM có thực lực được đào tạo từ nước ngoài trở về, các PM hầu như luôn có thái độ tiêu cực trong quản lý :
01. Bộp chộp nóng vội ko tìm hiểu rõ sự việc, task của DEV trước khi phán định – Thích chứng tỏ mình là người nắm quyền quyết định mà không tham vấn anh em trong team
+ “Trạng chết thì Trẫm cũng băng hà” – Có những thứ mà ai cũng hiểu mà chỉ có 1 người ko chịu hiểu
02. Không có tinh thần Win – Win
+ Luôn đeo 2 thanh gươm sau lưng sẵn sàng/đề phòng chứng cứ chặt ch*m với khách hàng
+ Thích đá banh/đẩy lỗi sang khách hàng nhưng rồi thì người xử lý cuối cùng vẫn là DEV
03. E ngại gánh trách nhiệm
+ Đổ lỗi cho dự án nghiệp vụ phức tạp nhiều vấn đề rủi ro
+ Nhân sự không đủ
+ Đổ lỗi cho DEV thiếu kinh nghiệp, level thấp gay bugs/issues
04. Làm PM nhưng lại hay đá lộn sân sang TA
+ Làm PM nhưng thích review code dù trình độ thì có hạng nhưng phán bậy thì ko care
+ Dự án có TA nhưng TA ko duoc tự chủ. Code Review xong vẫn phải chờ approve từ PM trong khi PM thì kém về technical nhưng lại thích chứng tỏ
+ Không hiểu về dự án bằng TA nhưng lại thích là người quyết định. (PM mà cứ nhận mình là PO)
05. PM nắm vững kiến thức Agile/Scrum nhưng làm việc rất tùy tiện, ko tôn trọng tin thần làm việc của Agile/Scrum
+ Với requirement là 1 User Story nhưng ko chia nhỏ thành task : Chấp nhận 1 User Story 48 hrs. Quản lý hời hợt, tắc trách
+ Sprint Plannning được thực hiện mà ko có thời gian cho investigate tasks. Estimation ko có cơ sở.
+ Due date được set up 1 hour ngay sau khi sprint planning
+ Request change nhưng task ko duoc cập nhật thêm time hay tạo sub-task
+ Làm Agile nhưng việc fix bugs, issues phát sinh ko được tính thành task
=> Tiến trình quản lý đúng, PM đều biết nhưng tinh thần chèn ép công việc, ép due-date
=> Ko sắp xếp tốt thời gian release : Khi request changes, sprint planning thay đổi dẫn tới thời gian release cuối cùng thay đổi
Điều này lẻ ra phải notify cho khách hàng nhưng nhiều PM ko ý thức dẫn tới DEV phải OT để release đúng thời gian trước đó.
Lỗi này ko chỉ ở PM trẻ mà PM già vẫn bị.
– Quản lý :
+ Có hệ thống đá*h giá DEV từ PM va Line nhưng ko có hệ thống feedback đá*h giá PM
+ Việc đá*h giá KPI còn bất cập: 01 năm làm nhiều project : Vi du 1 năm làm 2 projects: 1 khen 1 che thi ket quả là bình thường : Khỏi tăng lương
+ Viec đanh gia DEV chỉ từ PM là cảm tính dựa trên số lượng issue ma DEV gánh mà đá*h giá:
++ PM chỉ note được issue từ DEV nhưng DEV làm nhiều thì sẽ gánh issue nhiều. Chỉ có DEV ko gánh task lớn thì mới ko co issue
++ Thiếu đá*h giá từ Team Leader:
++ Ko đá*h giá được đóng góp, giá trị và sự trưởng thành của DEV xuyên suốt cả dự án vì mẫu template chỉ có 1 cột value theo tỉ từ 1->4
=> Neu nhu cach danh gia 1-4 thì chỉ cần trong 12 thang bạn mắc 1 issue nhỏ thì co nghi la ban chi co 3 va neu nhu ban mac 2 issues thi ban chi con 2
=> Đóng góp tích cực cả năng của bạn sẽ được đá*h giá vô cùng hời hợt vì nó ko dựa trên tổng thời gian va giá trị bạn đóng góp trên dự án.
Nó dự trên số issues mà PM đá*h giá bạn. Nếu PM ko hài lòng về bạn thì đó là issues kể cả đó có thực là issue đến từ bạn hay dự án hay request change hay ko.

,

Nát tét review lương tăng thế nào nhĩ

Hi all, cho em hỏi là dev .net 1 exp thì lương min là bao nhiêu vậy ?