Câu hỏi phỏng vấn Thực tập sinh Product Owner

Các yếu tố được tôi xem xét trước khi thiết kế lại một sản phẩm cụ thể chính là khả năng tồn tại của nó trên thị trường, sự hài lòng của khách hàng, câu chuyện của người dùng, thương hiệu và khả năng cạnh tranh. Tôi tin rằng các sản phẩm luôn cần được nâng cấp về thiết kế và công nghệ nhưng không phải trả giá bằng việc làm tổn hại đến di sản của sản phẩm và doanh thu của công ty.

Đầu tiên, tôi sẽ làm việc với một tinh thần “khám phá sản phẩm”, lưu giữ tất cả các phản hồi trong tầm mắt. Sau đó, tôi sẽ tiến hành phỏng vấn các bên liên quan chính và tiến hành phân tích sản phẩm với nhóm phát triển trước khi bắt tay vào làm mới thiết kế sản phẩm. Tôi đã tuân theo quy trình này khi làm việc với một sản phẩm công nghệ cho một khách hàng cũ của mình và nhóm của tôi đã thành công trong việc chuyển đổi và làm mới thương hiệu.

Khi tôi làm việc với tư cách là Product Owner mảng kỹ thuật ở công việc trước đây, tôi đã phải đưa ra quyết định về việc liệu nên xử lý một tính năng không được người dùng đón nhận như thế nào. Tính năng được đề cập là một chatbot tự động mà chúng tôi đã triển khai trên trang web của mình. Sau lần ra mắt chatbot đầu tiên, phản hồi của người dùng cho thấy rằng nó không đáp ứng được kỳ vọng của họ và họ gặp khó khăn khi sử dụng nó.

Để giải quyết vấn đề này, tôi đã tiến hành nghiên cứu xem các công ty khác đã triển khai thành công các tính năng tương tự như thế nào và tham khảo ý kiến của nhóm phát triển của chúng tôi để hiểu những thay đổi nào có thể được thực hiện để cải thiện trải nghiệm người dùng. Dựa trên thông tin này, tôi quyết định xóa chatbot khỏi trang web và thay thế nó bằng một hệ thống dịch vụ khách hàng trực quan hơn. Điều này cho phép chúng tôi cung cấp hỗ trợ tốt hơn cho khách hàng của mình đồng thời cải thiện trải nghiệm người dùng tổng thể.

Nếu tôi có một ý tưởng tuyệt vời về một tính năng cho sản phẩm nhưng nó quá khó về mặt kỹ thuật đối với các nhà phát triển để họ có thể triển khai một cách hiệu quả thì bước đầu tiên của tôi sẽ là đánh giá tính khả thi của tính năng đó. Tôi sẽ thảo luận về các thách thức kỹ thuật với nhóm phát triển và cùng nhau tìm cách làm cho tính năng này trở nên khả thi hơn. Nếu không có cách nào để giảm độ phức tạp của tính năng, thì tôi sẽ xem xét các lựa chọn khác như thuê ngoài hoặc sử dụng một công nghệ thay thế có thể đạt được kết quả tương tự.

Tôi cũng tin vào cách tiếp cận hợp tác khi nghiên cứu các tính năng của sản phẩm. Tôi sẽ lôi kéo các bên liên quan từ các phòng ban khác nhau để cùng lên ý tưởng và đưa ra các giải pháp sáng tạo. Điều này giúp đảm bảo rằng tất cả các khía cạnh đều được tính đến và mọi rủi ro tiềm ẩn đều được xác định từ sớm. Cuối cùng, tôi sẽ theo dõi tiến độ và cung cấp thông tin cập nhật thường xuyên cho các bên liên quan để họ có thể được thông báo về tình trạng của dự án.

Tôi hiểu rằng việc quản lý kỳ vọng của các bên liên quan khác nhau là một phần quan trọng để trở thành Product Owner. Để làm được điều này, tôi tập trung vào việc xây dựng mối quan hệ bền chặt với tất cả các bên liên quan và hiểu nhu cầu cá nhân của họ. Tôi đảm bảo truyền đạt rõ ràng các mục đích và mục tiêu của mình cho dự án, cũng như bất kỳ rủi ro hoặc thách thức tiềm ẩn nào. Điều này giúp đảm bảo mọi người đều có những kỳ vọng thực tế về những gì có thể đạt được.

Tôi cũng ưu tiên giao tiếp thường xuyên và liên tục với họ trong suốt vòng đời của dự án. Tôi sẽ thông báo cho các bên liên quan về tiến độ, những thay đổi về phạm vi và bất kỳ thông tin liên quan nào khác. Việc cập nhật thường xuyên giúp tôi luôn hiểu được mọi vấn đề hoặc mối lo ngại có thể phát sinh để có thể giải quyết chúng một cách nhanh chóng và hiệu quả.

Cuối cùng, tôi sẽ cố gắng duy trì tính minh bạch bằng cách cung cấp thông tin cập nhật và phản hồi thường xuyên cho các bên liên quan. Điều này cho phép họ cảm thấy được tham gia và đóng góp vào quá trình này.

Vì họ thường giám sát toàn bộ quá trình phát triển sản phẩm nên nhiều nhân viên có thể báo cáo với Product Owner. Các thành viên nhóm trong nhóm phát triển sản phẩm và scrum thường sẽ báo cáo với Product Owner để biết bất kỳ hướng dẫn nào về các tính năng cần đưa vào, cập nhật về tùy chọn của khách hàng hoặc thay đổi do các bên liên quan yêu cầu. Product Owner cũng có thể cung cấp cho các nhóm này lời khuyên và hướng dẫn về cách cải thiện quy trình phát triển sản phẩm.

Product Owner thường đóng vai trò lãnh đạo, vì vậy họ có thể báo cáo cho các thành viên trong nhóm điều hành. Các công ty lớn hơn có thể yêu cầu Product Owner làm việc trực tiếp dưới quyền của Phó Chủ tịch phát triển sản phẩm (Vice President of Product Development), người sẽ thực hiện các nhiệm vụ cấp cao hơn như chiến lược định giá và vị trí sản phẩm. Họ sẽ đảm bảo rằng Product Owner  đang lãnh đạo hiệu quả các nhóm phát triển sản phẩm và scrum trong việc tung ra các sản phẩm thành công.

Product Owner thường báo cáo trực tiếp với các bên liên quan để trình bày ý tưởng và sản phẩm cuối cùng của họ. Họ sẽ chuyển tiếp phản hồi của các bên liên quan và các bản cập nhật cần thiết cho các nhóm phát triển sản phẩm và scrum.

Mặc dù cả hai đều làm việc chặt chẽ trong việc phát triển và tung ra các sản phẩm của công ty, nhưng có một số điểm khác biệt chính giữa nhiệm vụ và thâm niên của Product Owner và Product Manager.

Câu trả lời cho câu hỏi có xu hướng khác nhau tùy thuộc vào công ty hoặc sản phẩm. Thông thường, nếu ai đó nói rằng họ dành 50% thời gian cho nghiên cứu người dùng, thì đó là một dấu hiệu tích cực. Tuy nhiên, nếu họ nói rằng họ dành 20% thời gian hoặc ít hơn, thì họ vẫn chưa làm đủ. Họ có thể bỏ qua phản hồi của khách hàng và điều kiện thị trường.

Mọi người đều thất bại, và nhà tuyển dụng biết điều đó. Những câu trả lời hay nhất không chỉ nói về những thất bại của chính bạn mà còn về những bài học rút ra từ chúng. Các Product Owner chuyên nghiệp sẽ đưa ra phân tích chắc chắn về mọi thất bại mà họ gặp phải và vạch ra các bài học rõ ràng cho các dự án trong tương lai.

Quá trình phát triển sản phẩm có nhiều bên liên quan chính. Một số trong số họ là:

• Khách hàng
• Cơ quan quản lý
• Chuyên gia
• Nhà tài trợ
• Những người ra quyết định chính

Product Owner tiềm năng phải hiểu rằng mỗi bên liên quan đóng một vai trò quan trọng trong quy trình và tại sao mỗi bên liên quan đó lại quan trọng để tương tác. Hơn nữa, sẽ là một điểm cộng nếu họ có thể giải thích cách mỗi bên liên quan đóng góp vào quy trình.

Đây không phải là một câu hỏi phỏng vấn phổ biến. Tuy nhiên, với vai trò quan trọng như Product Owner, bạn ít nhiều sẽ bị cấp trên và các thành viên khác hỏi han, thúc giục. Nhà tuyển dụng muốn biết bạn mạnh mẽ và độc lập như thế nào trong công việc, và bạn có thực sự có khả năng hòa đồng trong nhóm không?

Nhà tuyển dụng muốn thấy rằng bạn có khả năng và can đảm để bảo vệ và thuyết phục lý tưởng của mình. Ngoài ra, nếu sếp của bạn có những quyết định mâu thuẫn, bạn cũng sẵn sàng cống hiến hết mình.

Tập trung vào điểm mà bạn và người quản lý của bạn không đồng ý, bạn đã sử dụng những lý lẽ nào để thuyết phục người quản lý của mình. Tại sao những lý lẽ đó không hiệu quả và làm thế nào bạn vẫn có thể làm tốt mà không cần được chấp thuận.

Một số công cụ phổ biến được sử dụng trong quản lý dự án là Rally Software, Version One, XPlanner, EasyBacklog Agilefant,...

Quy trình quản lý lỗi và sự cố do người dùng báo cáo của tôi tập trung vào việc sắp xếp thứ tự ưu tiên. Tôi bắt đầu bằng cách lắng nghe phản hồi của người dùng, hiểu nhu cầu và mong đợi của họ.

Sau đó phân loại sự cố thành một trong ba nhóm: Quan trọng, cao hoặc thấp. Đối với các vấn đề nghiêm trọng, tôi làm việc với nhóm phát triển để nhanh chóng xác định nguyên nhân gốc rễ và đưa ra giải pháp.

Tôi cũng đảm bảo kiểm tra kỹ lưỡng bất kỳ thay đổi nào trước khi phát hành. Đối với các vấn đề có mức độ ưu tiên cao, tôi ưu tiên chúng dựa trên tác động và mức độ khẩn cấp. Đồng thời phân công nhiệm vụ cho các nhóm thích hợp để giải quyết.

Cuối cùng, đối với các sự cố có mức độ ưu tiên thấp, tôi theo dõi chúng trong hệ thống theo dõi sự cố để có thể giải quyết khi có sẵn nguồn lực.

So với những người không có kế hoạch, nhà tuyển dụng muốn tìm những người có kế hoạch tạo ra giá trị cho công ty càng sớm càng tốt.

Hãy cho nhà tuyển dụng biết rằng bạn đã vạch ra các kế hoạch để:

30 ngày đầu tiên: Xây dựng mối quan hệ với đồng nghiệp, các phòng ban liên quan và khách hàng, tìm hiểu về sản phẩm, quy trình….

30 ngày tiếp theo: Đi sâu vào những thách thức, ưu tiên, khách hàng,... của công ty.

30 ngày sau đó: Thể hiện giá trị bạn có thể mang đến cho công ty. Quản lý dự án, phát hành bản demo, lập kế hoạch hoặc bất cứ điều gì bạn có thể nghĩ ra để hướng khách hàng đi đúng hướng.

Bạn nên lên mạng tìm những bài test tính cách. Thấy điểm nào đúng với bản thân thì lưu lại. Ví dụ:

Điểm mạnh:

• Nhanh trí và táo bạo
• Lôi cuốn
• Năng động

Điểm yếu:

• Cá nhân hóa mọi thứ
• Quá vị tha

Agile là một phương pháp quản lý dự án, được sử dụng rộng rãi trong lĩnh vực phần mềm và quản lý dự án hiện đại. Nó tập trung vào việc tạo ra giá trị cho khách hàng thông qua việc phân chia dự án thành các giai đoạn nhỏ hơn, được gọi là sprint, và thực hiện kiểm tra, phản hồi, điều chỉnh liên tục.

Tuyên ngôn Agile là một tài liệu định nghĩa các giá trị cốt lõi của Agile. Agile bao gồm 4 tuyên ngôn:

• Ưu tiên cao hơn cho sự tương tác giữa cá nhân và quá trình.
• Phần mềm hoạt động hơn là tài liệu hoàn chỉnh. Sự hợp tác với khách hàng hơn là thương thảo hợp đồng.
• Đáp ứng thay đổi hơn là tuân thủ kế hoạch.

12 nguyên tắc của Agile gồm:

• Đáp ứng toàn diện nhu cầu khách hàng thông qua việc giao hàng sớm và sản phẩm có giá trị.
• Thay đổi yêu cầu được chào đón, thậm chí là rất muộn trong quá trình phát triển.
• Giao phần mềm chạy được cho khách hàng một cách thường xuyên.
• Nhà kinh doanh và các kỹ sư phần mềm cần làm việc cùng nhau trong suốt dự án.
• Xây dựng dự án xung quanh các cá nhân có động lực.
• Cung cấp sự hỗ trợ cần thiết, môi trường làm việc và niềm tin để hoàn thành công việc.
• Trao đổi trực tiếp là cách truyền đạt thông tin hiệu quả nhất.
• Thước đo chính của tiến độ là phần mềm chạy tốt.
• Phát triển liên tục và bền vững.
• Cải tiến sự linh hoạt bằng cách quan tâm đến kỹ thuật và thiết kế.
• Nghệ thuật tối đa hóa lượng công việc chưa xong – Sự đơn giản là cần thiết.
• Nhóm tự tổ chức.
• Thích ứng thường xuyên với những thay đổi.
  

Người đại diện cho khách hàng và quản lý Product Backlog.

• Product Backlog: Là một danh sách các yêu cầu cho sản phẩm sắp xếp theo ưu tiên. Nó thường được duy trì và quản lý bởi Product Owner. Product Backlog chứa các mục tiêu, tính năng và yêu cầu của sản phẩm.
• Sprint Backlog: Là một tập hợp các công việc cụ thể mà nhóm phát triển cam kết hoàn thành trong một Sprint.
• Sprint Backlog được tạo ra từ Product Backlog và đại diện cho phạm vi công việc cho một Sprint cụ thể.