• Jobs
  • Phát triển nghề nghiệp
    • Remote work
    • Kỹ năng làm việc IT
    • Developer
    • Data Science – Machine Learning – AI
    • IT gurus
    • Business Analyst
    • Project Manager
    • Thiết kế UIUX
    • IT trong công ty non-tech
  • Kỹ năng tìm việc
    • Tìm việc IT cần biết
    • Phỏng vấn IT
    • Câu hỏi phỏng vấn
    • CV xin việc
    • Đàm phán lương
    • Mô tả công việc
  • Công nghệ
    • Công nghệ ứng dụng IT
    • Ngôn ngữ lập trình
    • Kiến thức công nghệ
  • Lương-Xu hướng
    • Lương bổng phúc lợi
No Result
View All Result
  • Jobs
  • Phát triển nghề nghiệp
    • Remote work
    • Kỹ năng làm việc IT
    • Developer
    • Data Science – Machine Learning – AI
    • IT gurus
    • Business Analyst
    • Project Manager
    • Thiết kế UIUX
    • IT trong công ty non-tech
  • Kỹ năng tìm việc
    • Tìm việc IT cần biết
    • Phỏng vấn IT
    • Câu hỏi phỏng vấn
    • CV xin việc
    • Đàm phán lương
    • Mô tả công việc
  • Công nghệ
    • Công nghệ ứng dụng IT
    • Ngôn ngữ lập trình
    • Kiến thức công nghệ
  • Lương-Xu hướng
    • Lương bổng phúc lợi
No Result
View All Result
No Result
View All Result
  • Jobs
  • Phát triển nghề nghiệp
  • Kỹ năng tìm việc
  • Công nghệ
  • Lương-Xu hướng

Làm sao để biết bạn là một Giám đốc Sản Phẩm tệ hại ?

Minh Vu by Minh Vu
January 11, 2021
in Phát triển nghề nghiệp IT
0
0
giam-doc-san-pham-te-hai
0
SHARES
111
VIEWS
Share on FacebookShare on Twitter

Trách nhiệm của Product Owner trong Scrum thường bị hiểu nhầm và hiểu sai. Do đó, hàng nghìn “Product Owners” trên khắp thế giới làm ảnh hưởng đến hiệu suất của nhóm nhiều hơn những gì họ giúp ích. Dưới đây là một số biểu hiện cho biết liệu bạn có đang đi chệch hướng với tư cách là một Giám Đốc Sản Phẩm hay không.

Bạn quản lý mọi người thay vì sản phẩm

Một sự hiểu lầm rất phổ biến khi cho rằng Product Owner là một trưởng nhóm hoặc người quản lý dự án. Do đó, bạn có thể cảm thấy mình phải chịu trách nhiệm cuối cùng về những gì nhóm thực hiện và do đó, bạn thấy mình có trách nhiệm quản lý nhóm. Ngay cả khi điều này xảy ra với mục đích tốt thì đó cũng là một ý kiến ​​tồi!

Product Owner sở hữu sản phẩm, không phải đội ngũ. Và không chịu trách nhiệm nhiều hơn hay ít hơn đối với mọi thứ mà nhóm làm so với những người khác trong nhóm. 

Có thể bạn muốn tìm hiểu thêm:

  • 17 câu hỏi phỏng vấn thường gặp và cách trả lời cho vị trí Product Manager
  • Lộ trình phát triển nghề nghiệp trong lĩnh vực Product Management

Bạn đứng trên team mình

Nếu bạn đảm nhận trách  về product owner, bạn rất có thể có thứ hạng cao trong hệ thống phân cấp của công ty – và điều đó thường dẫn đến các vấn đề! Product Owner KHÔNG phải là người ở vị trí cao trong team trong hệ thống phân cấp! Có những trường hợp phải tăng lương để một đồng nghiệp từ cấp thấp hơn đảm nhận nhiệm vụ Product Owner.

Có thể, trước đây bạn là trưởng nhóm hoặc quản lý dự án. Bây giờ bạn tiếp tục đóng vai trò “Product Owner”. Nhưng Product Owner không phải là trưởng nhóm hoặc quản lý dự án – 2 vị trí này hoàn toàn khác nhau.

Product Owner ở cùng cấp độ phân cấp với các lập trình viên! Bạn chỉ đóng các vai trò khác nhau dựa trên chuyên môn của bạn. Trong khi bạn là Product Owner biết rất nhiều về doanh nghiệp và khách hàng, thì các nhà phát triển biết rất nhiều về chất lượng sản phẩm và quá trình phát triển. Vì vậy, thay vì một bên nói với bên kia cách thực hiện công việc của họ, bạn kết hợp chuyên môn của mình và cộng tác.

Nếu bạn đã từng là trưởng nhóm hoặc quản lý dự án trước đây, vui lòng cố gắng quên đi vị trí thứ bậc của mình và chấp nhận rằng nhóm hiện có trách nhiệm về chất lượng sản phẩm và quy trình phát triển (bao gồm cả việc kiểm soát tốc độ họ có thể xây dựng mọi thứ).

Không truyền đạt mục tiêu sản phẩm

Một Giám đốc sản phẩm không có tầm nhìn về sản phẩm sẽ gặp rất nhiều khó khăn. Một số giám đốc sản phẩm chỉ liệt kê các yêu cầu mà không có tầm nhìn rõ ràng. Nhưng ngay cả những người có tầm nhìn thường không truyền đạt tầm nhìn đó cho những người còn lại trong nhóm!

Một phần quan trọng trong trách nhiệm của giám đốc sản phẩm là truyền đạt tầm nhìn hoặc mục tiêu sản phẩm. Để các developer khác có thể tự quản lý, họ cần biết “lý do” và hướng đi. Vì vậy, hãy chia sẻ tầm nhìn thường xuyên với cả nhóm. Việc liên kết câu chuyện của người dùng mà bạn đang thảo luận với mục tiêu sản phẩm thường dễ dàng bằng cách nêu rõ lý do tại sao câu chuyện này lại quan trọng.

Mục tiêu sản phẩm có thể phát triển theo thời gian. Vì vậy, chỉ đơn giản viết nó ra ban đầu sẽ không giúp ích gì. Bạn phải giao tiếp thường xuyên.

Bạn tập trung vào mục tiêu ngắn hạn

Đừng bị cuốn vào những suy nghĩ ngắn hạn. Quá dễ dàng khi nhìn vào thời hạn tiếp theo hãy cố gắng sắp xếp mọi thứ để thực hiện. Bạn phải cân nhắc giữa các mục tiêu ngắn hạn như sửa lỗi so với các mục tiêu dài hạn như hiệu suất hoặc các tính năng mới.

Và nếu bạn cố gắng thúc đẩy các developer giải quyết các công việc tồn đọng để hoàn thành tất cả các tính năng cho bản phát hành tiếp theo, điều này thật tệ, vì nó sẽ gây ảnh hưởng tới tốc độ và chất lượng sản phẩm trong bản phát hành tiếp theo , dễ dàng kết thúc trong một vòng luẩn quẩn. 

Đặt thời hạn tùy ý

Đặt ra thời hạn dường như là một môn thể thao được yêu thích bởi những người cố gắng thăng tiến trong hệ thống phân cấp công ty. Nếu bạn đặt ra thời hạn chỉ để “tạo động lực cho các developer” hoặc “tạo một chút áp lực” cho các lập trình viên, hãy ngừng làm việc đó đi!

Đặt ra thời hạn tùy ý là một công cụ từ thời kỳ đồ đá của việc quản lý. Và đây là lý do tại sao nó không hoạt động ngày hôm nay: Thời hạn của bạn sẽ được các developer xem xét một cách nghiêm túc, ngay cả khi nó không khả thi. Các developer có kinh nghiệm sẽ đẩy lùi và nói thẳng với bạn rằng thời hạn này sẽ ảnh hưởng đến chất lượng sản phẩm và tốc độ phát triển (cả hai đều là trách nhiệm của các lập trình viên). Một nhóm ít kinh nghiệm hơn có thể nhượng bộ, làm đúng thời hạn và để lại cho bạn mớ hỗn độn sau đó: khách hàng giận dữ, sản phẩm lỗi và tốc độ phát triển ngày càng giảm. Vì vậy, xin vui lòng, không đặt thời hạn tùy tiện vì bất kỳ lý do gì!

Tất nhiên có những deadline ở những công ty bên ngoài (ví dụ: hội chợ thương mại hoặc luật), có thể đưa ra deadline một cách thích hợp. Quy tắc chung là: nếu bạn (với tư cách là một công ty) có quyền thay đổi thời hạn, hãy bỏ qua việc đặt thời hạn.

Hiểu rằng các developer chịu trách nhiệm về chất lượng sản phẩm và tốc độ phát triển, đồng thời họ sẽ đặt ra thời hạn của riêng mình (ví dụ: bằng cách dự báo sprint hoặc dự kiến ngày phát hành dựa trên hiệu suất trong dự án trước đây (tốc độ)). Nếu bạn vẫn lo sợ rằng các developer thiết lập thời hạn của riêng họ sẽ lười biếng, hãy thay đổi suy nghĩ của bạn trước khi sẵn sàng cho các agile frameworks như Scrum.

Hãy làm tốt hơn

Như bạn đã có thể đoán ở thời điểm này, trách nhiệm của giám đốc sản phẩm rất khác với trách nhiệm của trưởng nhóm hoặc quản lý dự án. Công việc của bạn với tư cách là giám đốc sản phẩm cung cấp danh sách các yêu cầu trong đơn đặt hàng để giá trị kinh doanh được tối đa hóa. Mặc dù điều này nghe có vẻ buồn tẻ, nhưng đây là một công việc rất thách thức và quan trọng. Do đó, để hoàn thành công việc này, trách nhiệm của giám đốc sản phẩm bao gồm:

  • Tìm hiểu những gì khách hàng cần
  • Biết và cập nhật mô hình kinh doanh
  • Giao tiếp với các bên liên quan khác (nhóm, phòng ban, người dùng,…)
  • Giữ product backlog theo thứ tự
  • Trả lời câu hỏi của các thành viên trong nhóm

Luôn nhớ rằng bạn là thành viên của một đội. Bạn không cần phải biết tất cả và bạn không phải tự chịu trách nhiệm về mọi thứ. Hãy thư giãn và trở thành một thành viên hòa đồng. Tập trung vào trách nhiệm với tư cách là giám đốc sản phẩm và một team năng động, một sản phẩm tuyệt vời và khách hàng hài lòng.

Xem thêm bài viết gốc tại đây !

Bạn có biết?


tham gia cộng đồng ITguru trên Linkedin, Facebook và các kênh mạng xã hội khác có thể giúp bạn nhanh chóng tìm được những chủ đề phát triển nghề nghiệp và cập nhật thông tin về việc làm IT mới nhất

Linkedin Page:
Facebook Group:
cơ hội việc làm IT : ITguru.vn

Bạn đánh giá bài viết thế nào?

Average rating 5 / 5. Vote count: 1

No votes so far! Be the first to rate this post.

Tags: giám đốc sản phẩmproduct ownerproduct team
Previous Post

4 sai lầm cần tránh trong phỏng vấn Data Science

Next Post

Thế nào là lập trình viên giỏi, lập trình viên tệ ?

Minh Vu

Minh Vu

Related Posts

Tương Lai Nghề Lập Trình Với AI

Tương Lai Của Lập Trình Viên Khi Công Cụ AI Ngày Càng Phổ Biến

February 28, 2025
Top 5 Công Việc AI Đáng Chú Ý Năm 2025

Top 5 Công Việc AI Đáng Chú Ý Năm 2025

February 27, 2025
great resignation và các nhà phát triển phần mềm

Làn sóng nghỉ việc ồ ạt và những tác động đối với các nhà phát triển phần mềm

April 4, 2022
serverless developer

Serverless là gì và học gì để làm việc với serverless?

June 2, 2022
đánh giá hiệu suất công việc - performance appraisal - performance review

Cách viết đánh giá hiệu suất công việc (performance appraisal) hiệu quả dành cho kỹ sư phần mềm

April 25, 2022
quản trị dự án phần mềm

Làm thế nào để kỹ sư phần mềm có thể quản trị dự án một cách hiệu quả

January 16, 2022
Next Post
Good-Programmer-Bad-programmer

Thế nào là lập trình viên giỏi, lập trình viên tệ ?

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

About ITGuru.vn

  • Trang Chủ ITguru.vn
  • Về chúng tôi
  • Thỏa thuận sử dụng
  • Quy định bảo mật
  • Quy chế hoạt động
  • Liên hệ ITguru

Nhà tuyển dụng

  • Đăng tuyển

Người tìm việc

  • Việc làm IT
  • About ITguru Blog
  • Viết bài cùng ITguru

© 2022 ITguru.vn - Web site tuyển dụng và phát triển nghề nghiệp IT

Welcome Back!

Login to your account below

Forgotten Password?

Retrieve your password

Please enter your username or email address to reset your password.

Log In
No Result
View All Result
  • About ITguru Blog
  • Viết bài cùng ITguru

© 2022 ITguru.vn - Web site tuyển dụng và phát triển nghề nghiệp IT