Cập nhật 13:47, 24/01/2024
1353 lượt xem
Admin
NHƯ THẾ NÀO LÀ CÁCH TẠO SẢN PHẨM CỘNG NGHỆ ĐƯỢC YÊU THÍCH NHẤT?
PART I. Lessons from Top Tech Companies
In the mid-1980s, I was a young software engineer working for Hewlett Packard on a high-profile product. It was a time (the first time) when artificial intelligence was all the rage, and I was fortunate enough to be working at what was then one of the industry’s best technology companies, as part of a very strong software engineering team (several members of that team went on to substantial success in companies across the industry).
Our assignment was a difficult one: to deliver AI-enabling tech- nology on a low-cost, general-purpose workstation that, until then,required a special-purpose hardware/software combination that cost more than $100,000 per user—a price few could afford.
We worked long and hard for well over a year, sacrificing count- less nights and weekends. Along the way, we added several patents to HP’s portfolio. We developed the software to meet HP’s exacting quality standards. We internationalized the product and localized it for several languages. We trained the sales force. We previewed our technology with the press and received excellent reviews. We were ready. We released. We celebrated the release.
Just one problem: No one bought it.
The product was a complete failure in the marketplace. Yes, it was technically impressive, and the reviewers loved it, but it wasn’t something people wanted or needed.
The team was of course extremely frustrated with this outcome. But soon we began to ask ourselves some very important questions: Who decides what products we should build? How do they decide? How do they know that what we build will be useful?
Our young team learned something very profound—something many teams have discovered the hard way: It doesn’t matter how good your engineering team is if they are not given something worthwhile to build.
When trying to track down the root cause of our failure, I learned that the decisions about what to build came from a product manager—someone who generally resided in the marketing organiza-tion and who was responsible for defining the products we built. But I also learned that product management wasn’t something HP was particularly good at. I later learned that most companies weren’t good at this either, and, in fact, most still aren’t.
Cùng True Skill tìm hiểu qua link dưới đây nhé 👇👇!
Link tải full E-Book: https://bit.ly/3Stxlom
Trong quá trình phát triển phần mềm, việc nắm bắt và quản lý yêu cầu của hệ thống là một bước vô cùng quan trọng. Một trong những phương pháp phổ biến và hiệu quả để mô tả yêu cầu là Use Case. Vậy Use Case là gì? Vì sao IT Business Analyst (BA) và Product Owner (PO) cần hiểu rõ Use Case? Hãy cùng tìm hiểu chi tiết trong bài viết này.
Nếu Sprint Planning được tổ chức hiệu quả, nhóm sẽ có một Sprint backlog rõ ràng, tinh thần đồng thuận và định hướng công việc xuyên suốt. Ngược lại, một buổi lập kế hoạch kém chất lượng dễ dẫn đến sự mơ hồ, kỳ vọng sai lệch và giảm năng suất.
Một Product Owner giỏi chính là người “cầm lái” đưa sản phẩm từ ý tưởng ban đầu đến khi triển khai thành công ra thị trường. Nếu thiếu kỹ năng, PO dễ khiến dự án chậm tiến độ, backlog rối loạn và sản phẩm không đáp ứng đúng nhu cầu.
Bạn đã bao giờ rơi vào cảnh Sprint Planning kéo dài hàng giờ chỉ vì backlog quá lộn xộn, user story mơ hồ, hoặc cả đội nhóm tranh cãi mãi không đi đến kết luận?
Hãy nhập ngay email của bạn vào form bên dưới để được nhận tư vấn trực tiếp từ trung tâm.