Share
Explore

icon picker
iLotusland - Our product

​
BH
Bug Hunter

Thách thức hiện tại của chúng ta


Về quy trình


1. Từ vấn đề nhức nhối mà khách hàng đang gặp phải đến những giải pháp kì diệu nảy ra trong tâm trí của đội ngũ phát triển.
Các tính năng phần mềm cuối cùng mà chúng ta phát triển cho khách hàng có xuất phát điểm từ vấn đề cốt lõi mà họ gặp phải hằng ngày trong công việc. Các vấn đề này có lúc thì rõ như ban ngày, có lúc thì mập mờ ngay cả chính bản thân khách hàng cũng không thể diễn tả rõ họ đang gặp vấn đề gì.
Đội ngũ bán hàng, phân tích sản phẩm của chúng ta tiếp cận khách hàng để bán cho họ các giải pháp, ghi nhận các yêu cầu của khách hàng. Tuy nhiên, có nhiều trường hợp khách hàng cũng không biết họ muốn cái gì, dẫn đến đưa ra các yêu cầu sai lệch cho đội phân tích.
Chưa hết, sau khi gặp gỡ khách hàng, đội phân tích sẽ tiếp tục tổng hợp lại các yêu cầu, chuyển thể các yêu cầu từ thế giới bên ngoài thành các tính năng của phần mềm. Sau khi đã hoàn thiện phân tích, vẽ được giao diện cuối cùng cho tính năng, đội phân tích chuyển giao cho đội lập trình để thực hiện đưa các tính năng từ bản vẽ lên phần mềm.
Có thể thấy, xuất phát từ vấn đề của khách hàng, rồi đến suy nghĩ trong đầu họ → thứ họ nói ra → thứ mà đội phân tích hiểu → sản phẩm làm ra là một quy trình khép kín. Trong quy trình này, trải qua nhiều lớp “Filter”, bản chất ban đầu của vấn đề đã bị gạn lọc, thay đổi ít nhiều.
Do đó, sản phẩm cuối cùng làm ra rất có thể sẽ giải quyết không triệt để nhu cầu của khách hàng hoặc thậm chí tệ hơn là không giải quyết được.
2. Tần suất release sản phẩm
Chúng ta đã làm rất tốt khâu phát triển sản phẩm theo sprint (2 tuần). Tuy nhiên, sau 2 tuần đó, người dùng cuối vẫn không thể tiếp cận được với thứ mà chúng ta đã cất công làm trong suốt 2 tuần.
Hiện nay, chúng ta cập nhật version mới cho khách hàng 3 tháng / lần vì phụ thuộc rất nhiều yếu tố khác nhau (hợp đồng, hạ tầng, quy trình triển khai nâng cấp)

Về con người

1. Mindset lợi nhuận - giá trị
Ta cần đổi mindset “Kiếm được bao nhiêu từ khách hàng” thành “Chúng ta giúp khách hàng giải quyết được bao nhiêu vấn đề, mang lại bao nhiêu giá trị cho họ”
Lúc này, cách chúng ta nhìn nhận vấn đề sẽ cùng hướng với khách hàng, giúp họ giải quyết vấn đề cốt lõi, không chỉ dừng lại ở quan hệ “Mua - bán”. Chúng ta có thể biến khách hàng thành những cộng sự của mình, thậm chí khiến họ “làm việc” cho mình. Chính những khách hàng của chúng ta là những người bán hàng mang lại nhiều doanh thu nhất thông qua việc giới thiệu sản phẩm cho các mối quan hệ chất lượng của họ. Khách hàng cũng chính là những chuyên viên phân tích nghiệp vụ giỏi nhất, những người làm product đỉnh nhất vì họ là người hiểu rõ hơn ai hết công việc hàng ngày, tìm ra nhu cầu của mình - điều mà đội ngũ phát triển product của chúng ta ngồi ở văn phòng và cố suy đoán.
Để có được những khách hàng trung thành, những người bán hàng, những người làm product ngay ở tiền tuyến như vậy thì trước hết chúng ta phải học cách cho đi trước. Ta cho họ sự tận tâm, sự say mê và nhiệt huyết giúp họ giải quyết các vấn đề nhức nhối mà họ gặp phải
2. Mindset “Tìm vấn đề cốt lõi”
Ví dụ một công ty bán xẻng dùng để đào đất. Thứ mà khách hàng thực sự muốn có không phải là “cái cán gỗ có gắn miếng sắt” mà là “những cái lỗ trên mặt đất” để họ có thể trồng cây, làm xanh khu vườn của mình. Nếu một ngày nọ người ta có thể búng tay để tạo những cái lỗ đó, thì sẽ chẳng ai thèm mua xẻng của công ty nữa.
Phía trên là 1 ví dụ vui về “tìm vấn đề cốt lõi”. Trong quá trình phân tích yêu cầu từ khách hàng, ta hãy khoan vội nghe theo răm rắm các tính năng mà họ yêu cầu mà hãy thực sự tỉnh táo để tìm ra vấn đề cốt lõi trước khi gõ bất cứ một dòng document nào về tính năng hay vẽ bất kì một UI nào.
3. Khả năng tiếp nhận, trừu tượng hoá, tổng quát hoá thông tin từ lời nói của khách hàng
Khi nhận yêu cầu thô ban đầu của khách hàng, ta cần xem xét thử yêu cầu đó có vẻ “Giống giống” với module nào hiện có của mình chưa. Nếu có thì module hiện tại đáp ứng được bao nhiêu %, có cách nào để “Kế thừa” hết mức có thể thay vì đi xây lại từ đầu không (vì ta không thể đủ nguồn lực để liên tục xây mới theo yêu cầu của nhiều khách hàng được - mỗi người mỗi ý)
4. Văn hoá chia sẻ kiến thức
Kiến thức là biển đông, hiểu biết của ta chỉ như giọt nước. Mỗi cá nhân chúng ta không thể có đủ thời gian và sức lực để tự mình học và giỏi mọi thứ. Thay vì một người đọc 1 cuốn sách, học 1 khoá học hết 1 tuần thì ta có thể tận dụng sức mạnh tập thể. Mỗi người đọc một cuốn khác nhau, tìm hiểu các kiến thức khác nhau rồi chia sẻ lại cho nhau. Thông qua đó, ta có thể rút ngắn được quá trình tìm hiểu kiến thức một cách đáng kể thông qua việc chia sẻ những gì mình học được. Ngoài ra, việc chia sẻ cũng giúp ta nhớ lâu hơn các kiến thức mình học được. Sau khi học xong, nếu mình diễn đạt được cho người khác cùng hiểu được thì lúc đó mình mới thực sự hiểu vấn đề và có thể ngộ ra thêm một vài điều thiếu xót của mình.

Tóm lại: 3 bài toán mà em sẽ cố gắng để giải đến cuối năm


Các giải pháp để chúng ta xây dựng được sản phẩm giải quyết đúng vấn đề của khách hàng


Định nghĩa các chỉ số cần đo lường, thực hiện tích hợp tracking tools vào phần mềm để đo các chỉ số “Thực” từ người dùng
Xây dựng được văn hoá phản hồi cho khách hàng, chúng ta phải lấy được cái phản hồi thật sự trong lúc họ dùng sản phẩm, không phải phản hồi gượng gạo, chính trị (cộng đồng, kênh, cuộc thi ý tưởng cho KH, phải trả lời được câu hỏi “Phản hồi rồi tôi được lợi gì ko của KH”)
Story của các PO cần một câu chuyện đi kèm. Tuy nhiên không phải lúc nào cũng cần câu chuyện → Cần define khi nào thì cần câu chuyện, khi nào ko cần → Mục đích để cả team phát triển cùng hình dung vấn đề thực sự của khách hàng, không phải chỉ dừng lại ở việc thực thi các tính năng PO đã define sẵn (cần làm cho team happy khi tiến hành theo giải pháp này, tránh công nghiệp và gượng gạo)
Xây dựng được văn hoá chia sẻ kiến thức trong team (Cần tự nhiên nhất, mọi người cần hiểu ý nghĩa thật sự thông qua việc chia sẻ kiến thức, tuyệt đối ko gây áp lực)

Tiếp nhận, cải tiến nhưng không lạc lối


Define template, các bước để team dễ dàng “Tổng quát hoá” tính năng từ yêu cầu gốc của khách hàng, nhằm xây dựng một product đúng nghĩa, tránh chạy theo yêu cầu mà đánh mất đi bản chất thực sự của mình

Đẩy nhanh tốc độ vòng xoay phản hồi -> học hỏi -> cải tiến


Xây dựng môi trường Beta dành cho các early adoper để họ trải nghiệm các tính năng mới nhất từ đội ngũ phát triển ngay khi ý tưởng về tính năng còn nằm trong trứng nước để nếu tính năng đó thất bại → nên thất bại sớm để tránh lãng phí nguồn lực
Xây dựng các content liên tục để đẩy đến người dùng thông qua kênh push notification của app. Qua đó chúng ta có thể lấy được nhiều insight từ hành vi họ tương tác với thông báo đó (có bấm vào ko, có nhập form khảo sát ko, thời gian họ mở app, cũng là cách để ta verify user còn active)
⁠
#ilotusland
⁠
⁠
Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.