- Kết quả khảo sát hơn 100 công ty Big Tech
- Nếu tóm tắt cách Big Tech quản lý dự án thì ⇨ "tùy tình huống (It Depends)"
- Phần lớn không có phương pháp luận hay cách làm việc cố định, mà mỗi nhóm tự chọn thứ phù hợp với mình
- Các công ty niêm yết hoặc đã nhận đầu tư có mức độ hài lòng thấp với việc có PM chuyên trách, trong khi các công ty chưa nhận đầu tư lại có mức độ hài lòng cao
- Mức độ tự chủ của nhóm và mức độ hài lòng có tương quan cao
- Ngay cả với các nhóm gặp vấn đề, nguyên nhân thường không nằm ở phương pháp luận mà là do không thể hiện được tầm nhìn rõ ràng, thiếu minh bạch hoặc thiếu công cụ
- JIRA nhận về chủ yếu là phản hồi tiêu cực
- Những cách quản lý dự án không vận hành tốt
- Kỹ sư không tham gia vào việc ước tính thời gian dự án
- Yêu cầu vẫn thay đổi dù có PM chuyên trách
- Những nhóm không có quyền tự chủ để thay đổi phương pháp quản lý dự án đã thất bại thì ghi nhận mức độ hài lòng thấp
- Cách Big Tech triển khai dự án
- Kỹ sư dẫn dắt phần lớn dự án
- Không có phương pháp luận cố định, nhóm có thể tự do lựa chọn
- Với dự án ở cấp độ nhóm thì không có Project Manager chuyên trách. Với các dự án lớn có nhiều nhóm hoặc toàn công ty cùng tham gia thì sẽ có Technical Program Manager. Ở Uber, tỷ lệ khoảng 1:50
- Có sẵn các công cụ dành cho nhà phát triển ở mức first-class, và điều này ảnh hưởng lớn đến chu kỳ lặp ngắn
Cấu trúc tổ chức của Big Tech ảnh hưởng đến dự án như thế nào
- Môi trường cơ bản
- Kỹ sư và nhóm có quyền tự chủ
- Không phải là nguồn lực vô thức (lao động nhà máy) mà là những người giải quyết vấn đề đầy tò mò
- Dữ liệu, mã nguồn và tài liệu nội bộ được công khai minh bạch
- Kỹ sư cũng được tiếp xúc với hoạt động kinh doanh và các chỉ số kinh doanh
- Giao tiếp kỹ sư-với-kỹ sư diễn ra nhanh hơn thay vì giao tiếp theo tầng nấc phân cấp
- Đầu tư vào trải nghiệm nhà phát triển ít gây thất vọng hơn
- Mức lương cao hơn được biện minh bằng đòn bẩy cao hơn
- Có thể tuyển được nhân tài tốt hơn
- Những nhóm được trao quyền và có tính tự chủ
- Những nhóm có quyền sở hữu rõ ràng
Product Manager thì Có, còn Project Manager thì Không
- Vai trò của Product Manager là nắm được "What game we're playing" và "How we're going to play it"
- Trong nhiều trường hợp, Product Manager ở các công ty Big Tech không làm Project Management
- Nhóm chịu trách nhiệm thực thi, và trong đa số trường hợp quản lý kỹ thuật (team lead) chịu trách nhiệm thực hiện quản lý dự án
- Trong các nhóm được trao quyền và có tính tự chủ, việc quản lý dự án hiếm khi diễn ra theo kiểu từ trên xuống ⇨ mọi người cùng làm
- Những điểm dễ thắc mắc khi không có Project Manager chuyên trách
- Dự án ở cấp độ nhóm: đơn giản hóa quy trình và củng cố quan hệ giữa các cá nhân
- Dự án phức tạp: Big Tech sử dụng Technical Program Manager (TPM)
- Vẫn có Program Manager / Project Manager chuyên trách. Thông thường vai trò này gắn với bên ngoài, khách hàng và kế hoạch thực thi dài hạn
- Vì sao môi trường tập trung vào sản phẩm lại không làm scrum
- Scrum vận hành theo sprint không phù hợp lắm với bối cảnh phải phát hành nhanh
- Hạ tầng và công cụ cho nhà phát triển thay thế được nhiều hoạt động trong scrum
- Các công ty Big Tech đã nhận ra rằng đầu tư vào hạ tầng và công cụ cho nhà phát triển giúp tăng năng suất
- Facebook, Google, Netflix... không dùng scrum. Vì sao?
- Những người giỏi và có tính tự chủ ít cần kiểu cấu trúc này hơn
- Khi cho một nhóm giỏi quyền tự do quyết định cách vận hành, có thể tận dụng đòn bẩy của họ tốt hơn
- Mở rộng tổ chức kỹ thuật là chuyện vượt xa quy trình ở cấp độ nhóm
- Tuy vậy, việc ai cũng bắt chước Big Tech và không làm scrum là một sai lầm
→ Có những tình huống mà dùng scrum là phù hợp và thậm chí có thể đem lại năng suất cao hơn
- Kitchen sink team: khi một nhóm phải tự giải quyết mọi thứ (startup giai đoạn đầu)
- Khi đang hình thành một nhóm mới
- Khi chỉ phát hành vài tuần một lần
- Khi bắt buộc phải có báo cáo tiến độ dự án theo một định dạng thống nhất
Nên vận hành nhóm như thế nào?
- Những thay đổi lặp lại luôn tốt hơn thay đổi kiểu 'big bang'
- Dạy cách câu cá khó hơn là đưa cá cho họ
- Chỉ đạo, cố vấn và coaching đều có công dụng riêng
- Chỉ đạo là hình thức micromanaging mang tính hỗ trợ, chỉ dùng khi họ đáng ra có thể tự làm nhưng lúc đó lại không làm được
- Càng ít người cần thiết để ra quyết định thì quyết định càng được đưa ra nhanh hơn
- Tối ưu cho việc báo cáo cũng là tối ưu cho một môi trường có mức độ tin cậy thấp hơn
- Các consultant có xu hướng thiên về việc đưa ra những kết quả dễ đo lường, vì đó là cách dễ nhất để chứng minh giá trị của họ
- Việc học hỏi từ các đối thủ cạnh tranh trực tiếp đang bị đánh giá thấp
- Một số kỹ sư giỏi nhất thà nghỉ việc còn hơn bị micromanage
8 bình luận
"JIRA nhận về phần lớn phản hồi tiêu cực"
Tôi nghĩ việc quản lý issue dưới bất kỳ hình thức nào cũng là cần thiết, và bản thân tôi cũng từng có ác cảm với JIRA nên đã cố tình thử các công cụ khác (
github issues,trello,asanav.v.).Nhưng rồi đúng là đồ cũ vẫn tốt, cuối cùng tôi lại quay về với JIRA...
Dù vậy, tôi vẫn luôn suy nghĩ xem liệu có cách nào tốt hơn không.
Vì sao bạn lại cho rằng kinh nghiệm lâu năm là điều đáng quý hơn?
Tôi khá thích YouTrack. Đây là một công cụ PM do JetBrains tạo ra, và nó cho phép tôi quản lý dự án ở mức tôi cần.
Nhóm chúng tôi đã chuyển sang dùng Linear, và nhìn chung mức độ hài lòng đã tăng lên rất nhiều. Tôi khuyên bạn nên thử xem qua một lần.
Có vẻ là sản phẩm này, https://linear.app/. Trông khá thú vị.
Mình thấy các ưu điểm là
Đó là mức độ mình cảm nhận.
Các công cụ dành cho lập trình viên hạng nhất thực sự làm gì?
Tôi đã giữ nguyên cảm giác của bản gốc và mang sang nguyên văn.
Ở thời điểm hiện tại, có lẽ đây có thể xem là bộ công cụ phát triển tốt nhất mà tổ chức có thể cung cấp.