Đang IT audit, 8 năm kn, có CISA và CISSP, đang tính nhảy qua data analytics. Có bác nào từng nhảy tương tự cho mình lời khuyên đc không
Có mạnh chứ, tuỳ từng cty mà scope của vận hành sẽ to hay nhỏ. Nhưng chủ yếu có 2 cái - vận hành nghiệp vụ (dùng app, nhập liệu, kéo thả) - vận hành it
DE = data engineer? Bọn này build pipeline để lấy data theo chỉ đạo của data scientist, xài tool nhiều hơn code nhưng ko biết ko đc.
Đi làm thấy nhiều cái lạ lắm Lead là những niềm đau * Thực tế: mấy ông thuần tech thì không thích làm lead. Nhưng khi bầu lead thì mấy ông tech thường chọn mấy thằng tech khác làm lead chứ không phải mấy ông thiên về quản lý. Cuối cùng không ai hạnh phúc. * Trải nghiệm cá nhân: từng làm trong 1 team có lead chuẩn hard carry, ae ai cũng khoái. Sau 1 năm hơn, bà con vẫn dậm chân tại chỗ, lương thưởng lèo tèo vì đơn giản là không có đóng góp gì nổi bật. Carry ăn thưởng thì to, nhưng mà kiệt sức đến độ đang lái xe lăn ra ngủ. Lead sau thì thuộc dạng cần team gánh, bù lại là thấy team nó giỏi lên rõ ràng. * Ngoài ra, senior cũng nên làm bắt đầu tập 1:1 với đàn em, và lead sẽ 1:1 với senior. Không phải 1:1 theo kiểu đánh giá năng lực, lương lậu mà là giúp đỡ, định hướng, lời khuyên. Sau này lựa chọn lead cũng dễ, hoặc có bị ép cũng đỡ sợ. Product Mindset nó như woke culture * Lý thuyết: coi sản phẩm như con đẻ. * Kỳ vọng: ai cũng đóng góp ý kiến để phát triển sản phẩm. Cống hiến > 40h/tuần. Làm cái gì cũng kĩ càng, gọn gàng, sạch sẽ. * Thực tế: dev đôi co với BA/PO/PM về cái tính năng xàm lông nào đó. Front-end chỉ designer như nào là UI\UX. PO chỉ dev đặt cái callback ở file nào. Chưa kể over engineer. Không làm được, không ý kiến thì ko có product mindset. * Ý kiến cá nhân: về phía dev, mindset product chỉ đơn giản là lựa chọn các trade off. Tech-debt vs trễ vài ngày làm cho nó ổn, thực dụng chỗ này hay vs over-engineer cái nhẹ future proof, rồi nhiều tech decision khác. PO - làm gì, Team - làm sao, SM - bôi trơn, vậy đi cho phẻ. Ý kiến, đóng góp là tốt, nhưng người chịu trách nhiệm mới là người ra quyết định cuối cùng. Deadline sinh ra là để bị trượt * Lý thuyết: ra mắt tính năng quan trọng sớm hơn * Kỳ vọng: release nhanh hơn, ít bị sai deadline. * Thực tế: senior/lead estimate high-level complexity, stakeholder cho impact, PO/BA dựa vào đó tính độ ưu tiên. Sau đó trượt deadline -> gõ thằng lead -> restrospective tự kiểm điểm. Vì sinh tồn, lead sẽ buffer cái estimation rồi PO hỏi sao số to thế, hoặc dành cả ngày chả làm gì ngoài việc tưởng tượng nếu nó làm cái này thì ntn, hoặc họp cả team rồi chia nhỏ cái eta ra, rồi nó không còn là high-level nữa. * Ý kiến cá nhân: deadline sinh ra là để bị trượt, bộ ba resource-time-scope luôn đi chung. Nếu cố định time (ví dụ phải ẻ dc cái tính năng này trong Q1/2023), thì 2 cái còn lại nên gia giảm cho phù hợp. Khi thực thi thì nếu có dấu hiệu chệch hướng (trễ deadline, đổi scope...) thì họp xem scope/time/resource gia giảm như nào, chỉnh lại cái kế hoạch. Ngoài ra cũng nên triệu hồi mấy team liên quan mkt, sales, customer support... BA + PO hay là PO + PO * Lý thuyết: PO/Team/SM * Thực tế: PO làm nhiều dự án, tuyển không được PO (do khó tuyển ?? không đáp ứng ưu cầu ?? không muốn tuyển??) và tuyển BA (cho rẻ ??) * Ý kiến cá nhân: thiếu PO thì tuyển PO, mỗi thằng ôm 1-2 dự án project. PO không phải là lead của team (PO, team, SM là ngang hàng và ko phải ai là lead của ai) nên có junior dev thì cũng có junior PO, junior SM. quan trọng là thằng PM nó dìu dắt như PO nào. BA nó là path riêng, có chứng chỉ xịn xò riêng và tồn tại từ lâu rồi. PO chỉ có cái cert của srum.org, học bao đậu đầy trên udemy, cũng không có trường lớp gì về cái PO này cả. PO biết tech ở mức cơ bản thôi, nên đừng đòi tech PO rồi tuyển không ra hoặc lương cao rồi làm cũng ko hơn ai. PO nó cần giỏi min-max + giao tiếp. Còn nhiều lắm, mà ghi dài quá nên quên hết còn gì rồi. Ai đọc tới đây thì rất trân quý. Nếu có tinh anh nào thấy hợp lý và áp dụng được thì càng trân quý, chứ cái ngành này nó lạ lắm.
Team mình đang đọc cái này, 2 tuần 1 lần cùng nhau thảo luận. Nhiều topic cũng khá hay. https://book.debuggingteams.com/
Giờ ở VN có những cty nào trả trên 5k/mo net cho individual contributor nhỉ? Hoặc là engineering manager
Thường tới ngưỡng này hay chơi trick cắt ra trả lương chứ ít chỗ trả đủ 1 cục gross đóng đủ thuế/bảo hiểm mà ra 5k net thì phải.
Tình hình em đang học bằng 2 của KHTN, mà sắp tới workload job đang làm có thể tăng đột biến thì theo các bác nên ưu tiên cho cái nào hơn? Em học để có tấm bằng lận lưng để nhiều khi sau này chuyển job hoặc apply master, nếu workload tăng vầy sợ GPA ko cao đc do ít tgian học. Đang xì trét quá
Ngành nào chứ ngành này để làm việc thì bằng cấp với GPA cũng chả cần cao lắm. Trừ khi bạn định hướng đi du học với lấy học bổng thì mấy cái đấy mới cần. Như ông CTO chỗ mình đang làm cũng chỉ có cái bằng cấp 3,
ngon phết gồi, SM, PQA về, xây quy trình xong ốp cả sếp lẫn nhân viên theo trước khi có SM, PQA các thứ, ae Dev cứ cắm đầu mà làm theo yêu cầu từ dự án, cong đít chạy deadline. Dự án này lấy người dự án kia, ae quay cuồng, sếp thì giục. giờ các cuộc họp đều có SM, PQA nhảy vào. Bọn nó reject hết tất cả các yêu cầu vô lý, tập trung ae vào sprint goal. VIệc ngoài nhảy vào là bọn nó can thiệp, reject đẩy ra ngoài, yêu cầu sếp phải giảm scope :v Giờ lại thấy dễ thở trước ae thấy vất vì việc đã nhiều, lại còn phải họp hành lắm. Giờ cứ ốp quy trình, cái đếu j cũng có estimate từ trước, việc bất thình lình đưa vào là reject hết. Nếu mà bắt buộc phải làm thì bớt những việc đã estimate khác, cuối sprint đếu đạt được sprint goal thì đếu phải là tại dev mà là tại sếp Sếp mặt hơi bị buồn
sao không bị nói là không có tư duy product, không coi sp như con nữa à b dự án mình cũng bị nhồi nhét việc nên OT triền miên, BrSE thì toàn bảo ae phải có tư duy làm product chứ, mình cãi là làm phải có quy trình chứ k thể bắt ae OT tối ngày được, mà giờ cũng lết qua được đến maintainance rồi nên mình cũng kệ mẹ chẳng thèm nói nữa cty bác chịu để ôp quy trình vầy là đỡ cho dev r
OKR và Tribe Squad hàng phake nữa , Scrum master mới vào nghề IT đc 2 tháng, lúc nào cũng bảo Agile /scrum kêu làm thế, ae lật kinh thánh ra bật thì dỗi p/s: cty cũ phốt thuyết SM éo biết cc j lương 49, may mà éo pass probation , senior dev trong team lương trên 30 đếm éo quá 2 mạng
Apply cái gì cũng phải "with control". Google hay tài liệu xịn gì mà áp dụng máy móc, ko hợp lý cũng tạch.
giờ các dự án đều phải giãn deadline ra, scope giảm bớt đi để ae có thể vận hành công việc đúng quy trình . Dm nó lại là ez vê lù đối với ae đã quen làm áp lực 2,3 dự án cùng lúc
