Deliver value, not feature (Tạo ra giá trị, không phải tạo ra tính năng)

Đây chính là thứ đầu tiên mình muốn nói. Kết quả của sản phẩm không phải là những tính năng cho người dùng, cho hệ thống, mà là giá trị đem lại. Người dùng không cần những tính năng, họ cần những thứ giải quyết được vấn đề của họ. Để hiểu được điều này chúng ta cần thực sự hiểu được giá trị thực sự mà những thứ mà chúng ta làm ra mang lại cho người dùng. Hiểu được việc này thì team sẽ thực sự hiểu tại sao ta cần phải làm nó và thực sự làm sản phẩm CÓ ÍCH.

Để làm được điều này thì team cần biết được VẤN ĐỀ LÀ GÌ, chứ không chỉ GIẢI PHÁP LÀ GÌ. Business Analyst (PO/PM) phải hiểu được giá trị mà việc cần làm mang lại từ đó mô tả cho team Developer cách thức để giải quyết vấn đề (ko phải chỉ là tính năng là gì). Developer cũng phải hiểu được VẤN ĐỀ LÀ GÌ để có thể đưa ra được cách lập trình, tính năng phù hợp và có thể góp ý ngược lại với BA. Nếu developer chỉ hiểu tính năng thì chắc chắn sản phẩm họ deliver sẽ bị phụ thuộc vào BA rất nhiều. Nếu phương án của BA không hoàn toàn hợp lý thì có thể tính năng đưa ra chưa chắc đã giải quyết được vấn đề. Ngoài ra nếu không hiểu được câu hỏi TẠI SAO PHẢI LÀM mà chỉ biết LÀM THẾ NÀO (HOW) thì thông thường Developer yêu cầu BA mô tả phải thật sự rõ ràng.

Đối với các team khác, nếu các bạn chỉ mô tả cho team Product tính năng thì có thể thứ bạn nhận được không hoàn toàn phù hợp. Nếu tính năng đó bắt nguồn từ đối tác thì chúng ta có thể mất 3 lần trao đổi để đến được người trực tiếp giải quyết vấn đề: Đối tác => Sale => BA => Developer. Với việc mô tả qua 3 cầu như vậy rất dễ có sự sai lệch thông tin, chưa kể góc nhìn của Sale không phải góc nhìn sản phẩm nên mô tả không triệt để. Do vậy thông thường BA (thậm chí Developer) cần phải được ra ngoài để nói chuyện với đối tác để có thể hiểu được phần nào những thứ đối tác THỰC SỰ mong muốn.

Ngoài ra một vấn đề nữa khiến cho sản phẩm không được như mong muốn là việc không có sự đồng nhất về cách đánh giá thế nào là hoàn thành tính năng / vấn đề (Define of DONE). Nếu không có được mô tả về Define Of DONE và có sự đánh giá bằng con số thì rất dễ có sự tranh cãi giữa các team sau khi vấn đề được giải quyết.

Đối với các team khác, nếu các bạn chỉ mô tả cho team Product tính năng thì có thể thứ bạn nhận được không hoàn toàn phù hợp. Nếu tính năng đó bắt nguồn từ đối tác thì chúng ta có thể mất 3 lần trao đổi để đến được người trực tiếp giải quyết vấn đề: Đối tác ➤ Sale ➤ BA ➤ Developer. Với việc mô tả qua 3 cầu như vậy rất dễ có sự sai lệch thông tin, chưa kể góc nhìn của Sale không phải góc nhìn sản phẩm nên mô tả không triệt để. Do vậy thông thường BA (thậm chí Developer) cần phải được ra ngoài để nói chuyện với đối tác để có thể hiểu được phần nào những thứ đối tác THỰC SỰ mong muốn.

Ngoài ra một vấn đề nữa khiến cho sản phẩm không được như mong muốn là việc không có sự đồng nhất về cách đánh giá thế nào là hoàn thành tính năng / vấn đề (Define of DONE). Nếu không có được mô tả về Define Of DONE và có sự đánh giá bằng con số thì rất dễ có sự tranh cãi giữa các team sau khi vấn đề được giải quyết.

Data-Driven Development (Phát triển phải xoay quanh dữ liệu)

Một vấn đề nữa mình muốn rất rất muốn nói đến là vai trò của dữ liệu trong việc đưa ra quyết định. Data-Driven là thứ bắt buộc phải làm theo để có thể xây dựng sản phẩm thành công. Mọi thứ cần được đo đạc ở tất cả các khâu. Việc đo đạc nên được thực hiện trong hầu hết các bước và nó phải là nền tảng của việc ra quyết định.

Ví dụ ở bước đánh giá một lỗi phát sinh, một tính năng vừa hoàn thành… thì dữ liệu là thứ bắt buộc phải có để đưa ra quyết định. Ví dụ nếu ta chỉ nhìn vào thể hiện bên ngoài của lỗi thì rất khó đánh giá giá trị mà mình có thể mang lại sau khi sửa lỗi hoặc đánh giá hậu quả. Ví dụ cùng một thể hiện bên ngoài nếu ta đo được lỗi ảnh hưởng khiến cho doanh thu công ty sai lệch để cả trăm triệu đồng sẽ rất khác lỗi chỉ ảnh hưởng một vài ngàn đồng, lỗi ảnh hưởng đến toàn bộ đối tác sẽ rất khác lỗi chỉ ảnh hưởng rất ít đến đối tác nhỏ. Như vậy data sẽ rất cần để đánh giá giá trị của việc ta làm là gì. Từ đó đưa ra được quyết định lệu ta sẽ làm gì tiếp theo.

Tương tự như vậy việc đánh giá một tính năng, một yêu cầu được hoàn thành cũng cần phải có các con số. Nếu ta biết được việc ta làm ảnh hưởng thế nào thì ta mới có cơ sở để đưa ra quyết định ta có tiếp tục làm hoặc nếu có một tình huống tương tự nếu ta chưa có dữ liệu thì cũng có thể phỏng đoán được kết quả. Túm lại nếu ta không đánh giá được kết quả ta tạo ra bằng một con số cụ thể thì việc ta có làm hay không làm cũng chả khác gì nhau, từ đó khiến cho ta có thể thấy việc ta đã làm là hoàn toàn vô ích.

Một việc cần phải xem xét là thang đo để đánh giá, từ đó ra quyết định. Việc lựa chọn thang đo quyết định đến hơn 50% giá trị của việc đo lường. Nếu ta chọn sai thang đo thì giá trị của dữ liệu rất thấp. Thang đo phải được đánh giá rất cẩn thận để có được dữ liệu có giá trị. Một điều cần ghi nhớ, không phải mọi dữ liệu đều có ý nghĩa như nhau. Thông thường ta không thể đo đạc mọi thứ thế nên câu hỏi luôn phải đặt ra là dữ liệu là dữ liệu quan trọng nhất trong tình huống này. Và bạn phải luôn ghi nhớ: không phải cái gì tăng cũng tốt, không phải cái gì giảm cũng xấu, không phải số to đã là to, không phải số nhỏ đã là nhỏ. Dữ liệu luôn phải đặt vào context cụ thể mới có ý nghĩa.

Focus on the Product, Not the Code (Tập trung vào cái gọi là "sản phẩm", không phải code của bạn)

Một điều nữa ta cần ghi nhớ, chúng ta không phải là những công nhân lập trình, không phải là thợ xây. Do đo đó Team làm sản phẩm không nên chỉ chú trọng vào kỹ thuật. Một lần nữa mình nhắc lại cái mà khách hàng, đối tác, các team khác cần là giá trị chứ không phải là công nghệ, không phải công sức ta bỏ ra. Tất nhiên khi ta lựa chọn một công nghệ mà nó giúp tạo ra giá trị lớn (và phù hợp) thì luôn được hoan nghênh. Nhưng công nghệ có tốt đến mức nào mà không giải quyết được vấn đề thì cũng vô nghĩa. Thông thường Developer hay bị chú tâm quá nhiều vào công nghệ, họ có thể điên cuồng với một công nghệ mới nhưng thực sự đó không phải là thứ ta nên quan tâm đầu tiên.

Đôi khi chúng ta cần đánh đổi giữa công nghệ, những thức “tốt” để tập trung vào giải quyết bài toán sản phẩm. Một số thang đo cần được đưa vào để đánh giá ngoài chuyện nó có “tốt” không như: công nghệ này đã thực sự ổn định chưa? Cộng đồng có lớn không? Người có dễ tìm không? Nó có dễ phát triển không, vận hành hay không? Đôi khi ta phải đánh đổi giữa những thứ về kỹ thuật để tập trung tạo ra sản phẩm tốt hơn. Quan điểm của mình là luôn lựa chọn những công nghệ đơn giản để giải quyết vấn đề, theo nguyên tắc 80/20.

Tuy nhiên thực sự thì sản phẩm không chỉ gồm những yêu cầu tính năng. Sản phẩm còn bao gồm cả những yêu cầu phi chức năng (Non-Functional Requirements). Những yêu cầu chỉ những người thực sự hiểu về kiến trúc hệ thống mới đưa ra được. Thông thường sản phẩm ngắn hạn thì Non-Functional Requirements ít được đặt ra, nhưng sản phẩm dài hạn thì điều này cần đánh giá. Những yêu cầu như Coding Convention, Coding Style, System Architect cần được viết/vẽ ra một cách rõ ràng. Nếu ta không đưa ra và làm tốt thì rất dễ đưa đến những sản phẩm có nhiều món nợ kỹ thuật (Technical Debt)

UX

Trong quan điểm của mình đối với team Product thì User ko chỉ gồm những đối tượng mà sản phẩm thực sự hướng tới (End-User, Đối tác). Mà user bao gồm cả những thành phần tham gia phát triển sản phẩm (Developer Team, BA), Các team nội bộ và đối tác. Khi đặt vấn đề như thế thì trải nghiệm người dùng bao gồm cả những trải nghiệm cho team phát triển. Với góc nhìn như thì ta để ý đến trải nghiệm của cả những “user” phát triển sản phẩm. Trong thực tế thì ta có thể thấy: BA viết Requirements phục vụ Developer & Tester, Developer có user là Tester & DevOps, Tester lại có user là Developer… Như vậy thực tế khi xây dựng sản phẩm chúng ta cần hình dung ra toàn bộ quá trình để xây dựng sản phẩm, hình dung việc team tham gia vào vận hành sản phẩm khác như team sale, team marketing, team vận hành…

 

Tiếp để hiểu được UX cho user bên ngoài thì đầu tiên ta cần biết: user là ai? User có tính chất gì? User biết gì? User sử dụng tính năng X trong tình huống gì? Những sai sót, hiểu nhầm hay gặp phải? Thông thường khi Developer xây dựng một tính năng, chúng ta chỉ nhìn vào tính năng chúng ta cần xây dựng là gì, bỏ quên mất người sử dụng. Nếu chúng ta không tự đặt mình vào tình huống của người sử dụng, tinh thần, khả năng của người sử dụng thì chúng ta có thể xây dựng tính năng cho chính chúng ta. Bạn phải luôn ghi nhớ rằng người dùng của chúng ta hoàn toàn không giống chính chúng ta, họ thường không có được suy nghĩ và nền tảng để hiểu hết những gì chúng ta hiểu. Từ đó ta phải xây dựng tính năng mà người ta không cần phải “động não” (Mình hay nói vui là chỉ cần IQ kém cũng dùng được, hay như trong quyển sách gối đầu giường về UX “Don’t Make Me Think”). Các tính năng phải bản thân nói giải thích chính nó, chúng không nên cần có một hướng dẫn sử dụng để có thể sử dụng. Nếu tính năng cần có hướng dẫn sử dụng thì coi như tính năng vô ích.

Minimum Viable Product

Đầu tiên ta cần hiểu MVP là gì? Tại sao cần có MVP? MVP là cách thức xây dựng sản phẩm đơn giản nhất có thể nhưng vẫn đảm bảo những tính năng cơ bản cần thiết và có thể giúp ta đánh giá được kết quả, từ đó đưa ra phương án tiếp theo là gì. Tại sao việc này lại quan trọng? Thực tế thị trường thường biến đổi rất nhanh, nếu ta chọn cách làm phân tích, thiết kế, triển khai theo mô hình thông thường thì sau khi sản phẩm được đưa ra thị trường nó đã lỗi thời. Ngoài ra cũng có thể những gì ta nghĩ chưa chắc đã đúng, điều này đôi khi rất khó để có thể đoán biết được. Do vậy cần một phương án có thể nhanh chóng kiểm chứng được những gì ta nghĩ và MVP là một trong những cách thức kiểm chứng như vậy.

 

Theo như trong cuốn sách “Lean Startup” (Khởi nghiệp tinh gọn), ta có thể triển khai MVP theo 3 bước đơn giản và xoay vòng: Xây dựng — Đo Lường — Rút ra bài học. Việc này được thực hiện lặp đi lặp lại, qua mỗi vòng lặp sản phẩm sẽ được thay đổi và sẽ có một diện mạo khác. Để triển khai MVP thì bạn luôn nhớ đến 3 bước trên. Vậy mọi thứ phải bắt đầu từ đâu: Để lựa chọn được phương thức để triển khai MVP bạn phải quay lại đọc các phần 1–2–3–4 trước sẽ hình dung ra được những gì mình phải làm: Bắt đầu từ câu hỏi điều gì tạo ra giá trị, từ đó hiểu được điều quan trọng nhất là gì (keypoint là gì), từ đó có thể chỉ lựa chọn một mục tiêu quan trọng nhất chứ ko đưa ra quá nhiều mục tiêu. Tiếp theo mình cần đo lường những chỉ số quan trọng từ đó đưa ra được đánh giá tốt nhất. Tiếp theo là trong lúc triển khai, với suy nghĩ rằng lập trình không phải là thứ quan trọng nhất ta nên lựa chọn những phương án đơn giản, dễ đánh giá thay cho những giải pháp “tốt” khác. Tương tự khi tìm hiểu về UX chúng ta có thể hình dung đối tượng chúng ta cung cấp là ai, chỉ cần tập trung UX cho user thực sự “tiềm năng”, những user phục vụ việc mình nhanh chóng đưa ra được đánh giá và quyết định tiếp theo.