Eating your own dog food - Dùng sản phẩm của chính mình

Eating your own dog food - Dùng sản phẩm của chính mình

Những mẩu tin ngắn hàng ngày dành cho bạn
  • countless.dev là một trang web khá thú vị khi mà nó so sánh giá tiền sử dụng các mô hình LLMs của các nhà cung cấp khác nhau.

    Tại đây bạn có thể nhìn thấy tất cả các mô hình ngôn ngữ lớn phổ biến bởi các nhà cung cấp như OpenAI, Azure, Mistral... Bảng giá cho mỗi 1M tokens đầu vào/ra. Hoặc thậm chí có thể so sánh chúng với nhau để tìm ra nhà cung cấp hoặc mô hình rẻ nhất tuỳ theo mục đích sử dụng.

    » Xem thêm
  • 1,2 năm trước, Kubernetes (k8s) tự nhiên được nhắc đến như một hiện tượng, chắc vì nó bá quá nên ai cũng muốn học và sử dụng. Nó là một công cụ "Automating deployment, scaling, and management of containerized applications" - Vâng! nghe hay ho đấy chứ 🤤.

    Hồi đó thì mình đang đam mê với Docker, đặc biệt là Docker Swarm, cũng tương tự như k8s ý nhưng ở quy mô nhỏ hơn. Docker Swarm thì có vẻ ít phức tạp hơn nhiều so với k8s. Mà như thế cũng tốt vì nó đã và đang đáp ứng rất tốt nhu cầu sử dụng của mình lúc đó, lại còn bớt đi phần phức tạp, lằng nhằng.

    Ấy thế mà 1-2 tháng trở lại đây, các bài viết có tiêu đề "bạn có thực sự cần đến Kubernetes" lại đang nổi lên với tần suất dày hơn. Quả thật k8s rất mạnh nhưng cũng quá phức tạp. Tại sao phải cố dùng dao "mổ trâu để giết gà" cơ chứ? Trừ khi bạn lường trước được độ phức tạp khi muốn áp dụng một công nghệ. Một cái nữa k8s tiêu tốn tài nguyên và nguồn lực ghê ghớm, để vận hành được nó không đơn giản là dựng lên được là xong mà còn phải có rất nhiều nhiều kiến thức nữa 😨.

    À, chắc cũng một phần nữa là do các "ông lớn" đang tập trung đẩy mạnh vào Serverless, giảm bớt sự phức tạp trong khâu vận hành đi, thay vào đó là nên tập trung vào phát triển ứng dụng.

    Bên cạnh đó, thì cái tên WASM cũng đang được nhắc đến rất là nhiều 🤔

    Do you really need Kubernetes in your company/startup? | dev.to

    Do You Really Need Kubernetes?

    » Xem thêm
  • Trước mình cứ khen lấy khen để Serverless, rằng tối ưu chi phí xuống 0đ để duy trì blog các thứ. Đúng là như vậy thật! Nhưng bên cạnh đó serverless cũng có các mặt tối đáng để lưu tâm đấy!

    Hôm kia mình phải mất ngày trời để truy tìm và khắc phục sự cố chỉ vì gọi hàm build-in của Cloudflare KV. Cụ thể là hàm list với limit 1000 - tức là một lần gọi nó trả về 1000 keys của KV. Cơ mà đời không như là mơ. Con số 1000 chỉ là trên lý thuyết. Lúc thì trả về vài trăm, lúc thì vài chục, thậm chí lúc thì lẹt đẹt có vài cái. Thế là làm tắc nghẽn cả hệ thống. À mà cũng không phải là nghẽn mà là hệ thống "nhàn rỗi" quá không có việc gì để làm, trong khi thực tế đáng ra nó phải xử lý cả trăm ngàn cái keys cơ 🥲

    » Xem thêm

Vấn đề

Nhiều năm về trước khi mới bắt đầu đi thực tập, tôi làm ở một công ty chuyên làm sản phẩm rồi kinh doanh dựa trên những sản phẩm đó. Giờ đây người ta hay gọi là công ty Products. Sản phẩm chủ lực lúc đó dành cho cho khách hàng doanh nghiệp. Sau này thì mới biết đó là mô hình B2B - tức là bán cho khách hàng doanh nghiệp. Mặc dù tham gia trực tiếp vào khâu phát triển sản phẩm nhưng thành thật mà nói nhiều tính năng mình làm ra nhưng lại không hiểu tại sao nên làm ra chúng.

B2B là quá phức tạp với một đứa mới ra trường và còn non nớt kinh nghiệm. Tôi có thể thêm tính năng theo yêu cầu nhưng không thể nào lý giải tại sao nên làm tính năng đó. "Ôi dào! Có lẽ mình cũng không cần quá quan tâm lắm đâu" - Tôi tự nhủ. Miễn sao mình có khả năng lập trình là được. Trước mắt, thứ nên tập trung là cải thiện kỹ năng code ngày một tốt hơn. Các nhà lãnh đạo cứ thoải mái bàn luận rồi đưa tính năng xuống, chẳng mấy chốc sẽ "ngoáy" xong trong chớp mắt.

Cùng thời gian đó, tôi cực kỳ thắc mắc tại sao một người anh trong nhóm sẵn sàng "cãi" lại sếp chỉ vì lý do không nên đặt một nút ở chỗ này, mà nhất định nó phải nằm ở chỗ kia? Tại sao nhỉ? Chẳng phải sếp lúc nào cũng đúng? Hay ít nhất yêu cầu đó là của sếp thì chúng ta nên nghe theo! Chẳng phải sao? Chà!!!

Sau nhiều lần luân chuyển công ty, tôi vẫn luôn làm trong các công ty tự làm, tự bán sản phẩm của mình. Đó như một sở thích. Sản phẩm lần này vẫn phục vụ khách hàng chủ yếu là doanh nghiệp vừa và nhỏ, những người tự kinh doanh... Một lần nữa với tư cách là người phát triển, nhưng thứ mà tôi quan tâm đến nhiều hơn là kỹ thuật, làm thế nào để thiết kế hệ thống hoạt động, phục vụ được nhiều người dùng nhất có thể mới là quan trọng.

Nhưng lần này đã có thay đổi đáng kể về cách nghĩ của mình lâu nay. Một bước ngoặt lớn đối với tôi vì ở đây được học thêm rất nhiều về cách làm sản phẩm. Làm thế nào để tạo ra sản phẩm hữu dụng, có người dùng, và làm thế nào để bán được nó. Các thuật ngữ như MVP (Minimum Viable Product), KISS (Keep It Simple, Stupid), YAGNI (You Aren't Gonna Need It), Win-Win... lần lượt xuất hiện và nhảy vào trong đầu. Dần dần thay đổi được suy nghĩ về vai trò của kỹ thuật không còn là ưu tiên hàng đầu nữa, thay vào đó hãy thử đặt mình vào vị trí của người dùng để xem sản phẩm của mình tốt đến đâu, xem liệu có muốn dùng nó hay là không.

Sau đó một thời gian, tôi quay trở lại với một sản phẩm đầy hứa hẹn ở một công ty khác. Áp dụng những gì đã học được. Tạm bỏ qua những món nợ kỹ thuật "đắt tiền", thứ mà tôi quan tâm hơn cả là trải nghiệm của người dùng, về cách họ dùng sản phẩm như thế nào, từ đó đề xuất giải pháp tối ưu hơn. Cũng trong thời gian này, tôi gây dựng lại trang blog cá nhân của mình.

Như đã chia sẻ với bạn đọc trong nhiều bài viết về hành trình làm blog. Ban đầu tôi chỉ nghĩ đơn giản là tạo ra một nơi để viết, tập trung vào con chữ và tin rằng người dùng sẽ thích như vậy. Vì điều đó giúp họ tập trung hơn vào việc đọc thay vì nhìn vào những thứ có khả năng gây xao nhãng khác. Thế nên blog khi đó chẳng có gì ngoài chữ. Sau khi nghiêm túc đặt mình vào vị trí của người đọc, tôi dần dần hình dung ra được thứ mà họ thấy và thứ mà họ cần. Từ đó liên tục cải thiện trang web ngày qua ngày. Thú thật phiên bản mà bạn đang thấy đây đã là phiên bản thứ 4, thứ 5 của 2coffee.dev rồi đấy!

Những điều nói ở trên có thể tóm gọn lại là tôi đã học được nhiều điều về cách làm sản phẩm thông qua việc tự dùng sản phẩm của chính mình. Hôm nay, tự nhiên anh sếp có nhắc đến cụm từ "Eating your own dog food" và đố mọi người trong công ty biết nó ám chỉ điều gì. Ồ hoá ra có hẳn một cụm từ nói lên suy nghĩ lâu nay mà mình đang áp dụng.

"Eating your own dog food"

"Eating your own dog food" là một cách nói tượng hình, ám chỉ việc sử dụng chính sản phẩm hoặc dịch vụ mà mình tạo ra. Mục đích là để hiểu rõ hơn về chất lượng, tính hiệu quả và trải nghiệm mà sản phẩm đem lại cho người dùng.

Một cách dễ hiểu, bạn có thể hình dung thế này, nếu bạn tự ăn món ăn mình nấu, bạn sẽ biết nó có ngon không, mặn hay nhạt, hoặc có gì cần cải thiện. Trong phát triển phần mềm, khi các lập trình viên sử dụng chính sản phẩm của họ, sẽ phát hiện được lỗi, thấy những điểm chưa tốt, và có thể tìm cách nâng cao trải nghiệm cho người dùng.

Trên thực tế không phải ai cũng có điều kiện để dùng sản phẩm của mình làm ra. Ví dụ như đó là một sản phẩm đặc thù, dành cho một nhóm người dùng nhất định mà nằm ngoài nhu cầu sử dụng bình thường của chúng ta. Hoặc các bạn làm trong môi trường Outsourcing, gia công một phần hoặc một tính năng trong sản phẩm lớn. Vậy nên "Eating your own dog food" không hẳn là áp dụng được trong tất cả trường hợp mà phụ thuộc vào mỗi người, mỗi môi trường. Tuy vậy nếu có điều kiện hãy thử áp dụng vì điều đó giúp bạn rất nhiều trong quá trình làm sản phẩm.

Tại sao nên "Eating your own dog food"?

Tự dùng sản phẩm của chính mình để hiểu rõ sản phẩm hơn. Còn gì tuyệt vời hơn khi mới thay đổi môi trường làm việc và bắt đầu từ việc dùng sản phẩm để hiểu hơn về những gì đang có. Hoặc nếu bạn đã làm một thời gian rồi thì khi sử dụng sản phẩm cũng giúp cho việc phát triển tính năng sau này, lường trước được sự ảnh hưởng của tính năng mới... Tôi luôn tỏ ra thận trọng trước những thay đổi kể cả nhỏ nhất trong sản phẩm, không dám hoặc cần phải xem xét kỹ khi loại bỏ, sửa đổi một tính năng trước đó. Vì không chắc rằng liệu nó có ảnh hưởng đến tính năng khác? Thậm chí một số người quản lý cũng không nắm hết được sự liên quan vì sản phẩm đã qua nhiều người. Những lúc như thế cách tốt nhất vẫn là tự dùng sản phẩm để biết được mức độ ảnh hưởng của các tính năng với nhau.

Khi đặt trọng tâm vào vai người sử dụng sản phẩm, chúng ta sẽ có các hành vi tương tự như người dùng, sẽ thấy những điều hợp lý hoặc chưa phù hợp trong các thao tác thường ngày, từ đó đề xuất nhằm tăng chất lượng sản phẩm. Thi thoảng tôi vẫn đọc lại các bài viết trên blog như một người dùng, thực hiện các thao tác như tìm kiếm, bình luận, đánh giá bài viết... để tìm ra những thứ có thể cải thiện nhằm mang lại trải nghiệm tốt nhất cho người dùng.

Ngoài ra việc sử dụng hàng ngày còn giúp chúng ta phát hiện ra vấn đề từ sớm, trước cả người dùng cuối (end user). Trong nhiều ứng dụng có tích hợp một tính năng Báo cáo lỗi đến nhà phát triển để người dùng báo lỗi trong quá trình sử dụng. Thực tế khi áp dụng "dog food", tôi đã và đang báo rất nhiều lỗi đến cho đội phát triển sản phẩm cùng mình. Nhiều lúc còn mạnh dạn đề xuất hẳn một danh hiệu "Bug Hunters", hoặc một phần thưởng như "Bug Bounty" cho xứng đáng với những gì mình đã làm. Những lúc như thế, tất cả mọi người lại cười phá lên trong văn phòng.

Dùng sản phẩm của mình làm ra cũng gián tiếp nâng cao độ tin cậy và uy tín của sản phẩm. Sẽ rất khó để thuyết phục người khác sử dụng sản phẩm mà ngay cả chính mình còng không sử dụng. Trong trường hợp bạn vẫn có tiềm năng sử dụng bình thường. Và nếu muốn chia sẻ một ứng dụng hay cho người khác, bạn phải là người dùng thường xuyên để nhìn ra nhu cầu, đồng thời tư vấn những tính năng phù hợp với họ.

Tổng kết

"Eating your own dog food" là đặt mình vào vai người dùng để trải nghiệm sản phẩm của mình làm ra, từ đó cải thiện được nhiều điều từ thao tác sử dụng hàng ngày cho đến nâng cao độ tin cậy và uy tín của sản phẩm. Còn bạn thì sao? Đang làm sản phẩm gì và có sử dụng cũng như sẵn sàng chia sẻ đến người khác hay không? Hãy để lại ý kiến xuống phần bình luận nhé! Xin cảm ơn.

Cao cấp
Hello

5 bài học sâu sắc

Mỗi sản phẩm đi kèm với những câu chuyện. Thành công của người khác là nguồn cảm hứng cho nhiều người theo sau. 5 bài học rút ra được đã thay đổi con người tôi mãi mãi. Còn bạn? Hãy bấm vào ngay!

Mỗi sản phẩm đi kèm với những câu chuyện. Thành công của người khác là nguồn cảm hứng cho nhiều người theo sau. 5 bài học rút ra được đã thay đổi con người tôi mãi mãi. Còn bạn? Hãy bấm vào ngay!

Xem tất cả

Đăng ký nhận thông báo bài viết mới

hoặc
* Bản tin tổng hợp được gửi mỗi 1-2 tuần, huỷ bất cứ lúc nào.
Author

Xin chào, tôi tên là Hoài - một anh Dev kể chuyện bằng cách viết ✍️ và làm sản phẩm 🚀. Với nhiều năm kinh nghiệm lập trình, tôi đã đóng góp một phần công sức cho nhiều sản phẩm mang lại giá trị cho người dùng tại nơi đang làm việc, cũng như cho chính bản thân. Sở thích của tôi là đọc, viết, nghiên cứu... Tôi tạo ra trang Blog này với sứ mệnh mang đến những bài viết chất lượng cho độc giả của 2coffee.dev.Hãy theo dõi tôi qua các kênh LinkedIn, Facebook, Instagram, Telegram.

Bạn thấy bài viết này có ích?
Không

Bình luận (1)

Nội dung bình luận...
Avatar
Ẩn danh1 tháng trước
rất hay bạn
Trả lời
Avatar
Xuân Hoài Tống4 tuần trước
Cảm ơn bạn nha 🙏