Tản mạn về Software và Product: Một vài suy nghĩ vu vơ

Bài viết được sự cho phép của tác giả Nguyễn Hoàng Phú Thịnh

Đã bao giờ anh em thắc mắc: Product trong ngành công nghệ là gì? Nó khác gì với các “software” thông thường? Và ranh giới giữa một thứ được xem là “product” và một thứ “chỉ-được-xem-là-software” là gì 🙂 ?

Chả hiểu bằng một ma lực nào đó mà thời gian qua, các câu hỏi này cứ liên tục trôi nổi trong đầu mình. Nay mình note ra vài thứ (có thể xem là) trải nghiệm cá nhân về 2 khái niệm: product và software này.

Hi vọng có dịp cùng anh em chém gió, đàm đạo sôi nổi về topic này 😎

Product vs Software

Nói theo ngôn ngữ marketing thì “Product is anything that can be offered to the market that satisfied a want or need“.

Anything ở đây có thể là vô hình hoặc hữu hình. Hữu hình như cái chén, cái muỗng, cái dĩa. Đến những thứ vô hình như: tour du lịch, excel, bữa ăn tối tại nhà hàng, hay dịch vụ sửa xe…

Bài note này mình chỉ nói đến các “digital products”, tức những thứ như: Excel, Mương14, Facebook, hay các game như PUBG mà anh em vẫn đang chơi hằng ngày.

Với định nghĩa này thì product và software có vẻ không khác gì nhau. Nhưng thực tế nếu nhìn theo khía cạnh “quality of service“ thì sự khác biệt ở đây là cả… 1 bầu trời nghệ thuật.

Mình lấy Momo ra làm ví dụ.

Mình dùng app này cũng khá lâu rồi. Nhưng Momo chưa từng làm một người dùng cuối như mình thấy thất vọng. Có vẻ hơi dễ dãi nhưng sự thật là mình chưa-từng-một-lần phàn nàn khi sử dụng sản phẩm này.

Với trải nghiệm cá nhân, quả không gì bằng một công cụ tiện lợi, mượt mà. Và luôn là một cái gì đó, có thể khiến người dùng “wow” mỗi khi sử dụng.

Momo không còn đơn thuần chỉ là một “tool dùng để thanh toán” khi cần. Mà hơn hết nó đã trở thành 1 “sản phẩm” cho nhu cầu tài chính cá nhân mọi lúc, mọi nơi và tại mọi thời điểm (câu này nghe giống quảng cáo vãi ae :)) ).

Thường khi rảnh tay anh xem sẽ có thói quen mở Facebook lên lướt lướt đúng không. Có tin được không khi thi thoảng rảnh rỗi mình lại có thói quen mở… Momo để lướt xem các chương trình khuyến mãi. Thay vì mở Facebook để lướt?!?!

Cả 2 hành vi này đều đem lại “phần thưởng” cho mình là được cập nhật thông tin ngay tức thời.

Nhưng để một người dùng bình thường như mình làm điều này một cách rất tự nhiên và mang lại được một cảm xúc tích cực, thì anh em có thể thấy team Momo đã làm quality of service cho sản phẩm của mình tốt như thế nào.

Khác biệt

Quay lại các software mà anh em đang làm, những sản phẩm này thường “sống tốt” được ở những môi trường nào?

Software

Thường khi outsource hoặc làm phần mềm cho một khách hàng nào đó, end-user sẽ được gói gọn trong một tệp người khá rõ ràng.

Có nhiều yếu tố, nhưng mình chỉ muốn nói đến 2 yếu tố khác biệt rõ nhất giữa 1 software và 1 product đó là:

• Số lượng người dùng
•  Và môi trường sử dụng

Tại một thời điểm nhất định, số lượng người dùng sẽ được giới hạn ở một con số nào đó. Thường khách hàng có thể có 20, 50, hoặc cả trăm người dùng. Con số có thể nhiều hơn, nhưng chắc chắn vẫn trong tầm ước lượng và kiểm soát của anh em.

Còn các yếu tố liên quan đến môi trường sử dụng của end-users có thể như:

• Thiết bị họ dùng: nào là yêu cầu phần cứng, hệ điều hành, màn hình các kiểu…
• Hoặc đơn giản như việc end-users phải được training đầy đủ, bài bản, quành tráng thì mới có thể sử dụng được phần mềm của anh em.

Khi đã rõ 2 điều trên, anh em sẽ đỡ vả hơn rất rất nhiều trong việc maintain khi đưa phần mềm vào sử dụng thực tế. Mặc dù sự thật khá phũ là “làm xong” phần mềm đã là 1 câu chuyện đau đớn, đưa vào sử dụng còn đớn đau hơn gấp bội.

Đó là câu chuyện của việc cho ra đời một software thông thường. Còn với product thì sao?

Product

Hoàn toàn khác. Chắc chắn nó là một câu chuyện hoàn toàn khác.

Làm product, mọi thứ sẽ vô định hơn nhiều so với việc anh em làm một software có scope rõ ràng.

Số lượng end-users? Anh em sẽ phải luôn trong thế chuẩn bị cho các trường hợp khẩn cấp: lượng users sử dụng tăng cao, tăng đột biến..., bất kể lễ lộc hay weekend.

Còn nói về môi trường sử dụng thì là một câu chuyện dài, rất dài.

Đã là Product thì anh em sẽ phải quăng sản phẩm của mình vào scope đúng nghĩa của chữ “market”.

Tức sản phẩm của anh em phải sẵn sàng để sống tốt trong một thứ gọi là “the real world”. Nơi mọi thứ oái ăm, lạ đời nhất hoàn toàn đều có thể diễn ra.

Sự thật 169% là anh em sẽ không tài nào lường trước được end-users họ sẽ làm gì với cái apps của mình.

Sẽ có một nghìn lẻ một trường hợp người dùng không thao tác theo luồng mình nghĩ đến từ đầu. Mà sẽ theo một cái luồng oái ăm nào đó. Mặc dù nghe vô lý nhưng lại rất thuyết phục.

…

Hồi đó mình có làm một sản phẩm giúp các bạn Đại lý đi tuyển nhân viên bán hàng.

Toàn bộ quy trình đầu đến cuối đều được làm online hết. Trong đó có đoạn: bạn ứng viên phải làm 1 bài đánh giá tính cách, xem thử bạn có thật sự phù hợp với công việc này hay không.

Bài trắc nghiệm đơn giản chỉ là một web page, ứng viên sẽ nhận link bài đánh giá qua email >> mở ra >> làm.

Thực tế là bài đánh giá khá dài. Vừa trả lời trắc nghiệm, lẫn trả lời tự do. Và vì được code khá lâu, trên một nền tảng cũ nên bài trắc nghiệm này không responsive trên trình duyệt web được. Tức người dùng phải mở bằng laptop để có được “trải-nghiệm-đúng-nhất”.

Nhưng cái mắc cười là: hầu như 90% ứng viên (những người dùng rất bình thường trong cái gọi là “the real world” kia) lại làm bài trắc nghiệm trên… điện thoại.

Và anh em thử tưởng tượng một web page không responsive, nhập liệu cả chục cái free text, và chỉ có 1 nút Submit lẻ loi chật vật hiển thị giữa một rừng cả mấy chục fields, trên cái màn hình điện thoại vỏn vẹn chỉ tầm 4-5 inch!?!?! Chưa kể còn không submit kết quả được trên trình duyệt Safari 9 trở về trước…

Rõ ràng những thứ “ngó bộ hiển nhiên” nhưng lại bị bỏ qua một cách “rất tự nhiên” như vầy thì quality of service là một con số 0 tròn trĩnh.

Một sai lầm rất đáng trách của người làm câu chuyện phân tích & thiết kế như mình. Hoặc các anh em đang play role BA/ PO cho sản phẩm của mình.

Và sự thật là sản phẩm của anh em cần phải được quăng vào thế giới thực tế. Và PHẢI được dùng bởi người dùng thực tế ngoài kia, thì “khả năng hoàn thiện sản phẩm” mới tốt dần lên được.

Cùng đồng ý một điều là sẽ không có bất cứ sản phẩm công nghệ nào đạt được mức độ hoàn thiện ngay từ NHỮNG lần build đầu tiên cả. Cái gì cũng vậy, cần thời gian để cải thiện và nâng cấp dần dần.

Nhưng mấu chốt là anh em cần có FEEDBACK từ người dùng thì mới có thể làm được sự “cải thiện, và nâng cấp dần dần” đó. Và xuyên suốt quá trình lấy feedback từ người dùng, cái khó nhất vẫn luôn là: làm sao để họ chịu dùng sản phẩm của mình.

Nhưng…

Một thực trạng là anh em sẽ rất hay bị dí deadline trong môi trường các công ty outsource. Nào là khách hàng ép, dự án rush, nhu cầu gấp. Nói chung đụng đâu cũng thấy… nước sôi đổ tới háng hết. Dẫn tới timeline của anh em bị bóp nghẹt không thương tiếc.

Thử hỏi “làm xong” còn chưa kịp huống chi nói đến chuyện “làm đẹp”. Nó giống kiểu: anh em đang làm bài kiểm tra mà mắc ị vậy.

Và cứ vậy, project này qua project khác, software này qua software khác, nó cứ như một nùi tả pí lù. Cứ “xong” theo kiểu bị dí, bị ép. Shit của ông này cứ chồng lên shit của ông khác, and so on, you know….

Chưa kể những dự án enhancement hay migration. Tức làm trên cái có sẵn, rồi cải tiến lên phù hợp với new biz hoặc technology nào đó.

Ver1 đã tệ, thì với cách làm cũ dù có làm thêm thì cũng chỉ là một cục tệ ver2 khác. Tức là trước chỉ có 1 cục, giờ ghép vào thành 2 cục tệ, what da fuck???

Ngoài ra, làm product là gắn liền với sự cải tiến liên tục.

Sẽ có chặn bắt đầu, nhưng thường không có chặn kết thúc như khi anh em làm các project outsource thông thường. 500 anh em sẽ phải liên tục theo dõi quá trình sử dụng của người dùng. Đưa ra những cải tiến kịp thời và phù hợp với thị trường hay chiến lược của sản phẩm.

Và thị trường hay nhu cầu của biz thì luôn thay đổi, thậm chí thay đổi từng giờ, từng ngày. Nên sẽ không bao giờ có chuyện “làm xong dự án” khi anh em làm product.

Nói gì nói anh em sẽ phải luôn gắn liền cuộc sống của mình với sản phẩm mình làm.

Nghĩa là, sản phẩm mà có shit, thì anh em vẫn là người hốt. Dù có lấp liếm được đến đâu đi chăng nữa, thì sau cùng vẫn chính là mình. Chính mình là người đi dọn những đống shit đó.

Cho nên?

Do it one time, do it right

Vì không có thời gian nên anh em phải hết sức cố gắng làm chuẩn ngay từ đầu. Bất kể anh em có làm một product triệu đô, hay đơn thuần đang outsource một software thông thường đi chăng nữa.

Khái niệm “chuẩn” của mỗi người là khác nhau. Nhưng chắc chắn, quality của “chuẩn” nó sẽ HƠN NHIỀU so với “tàm tạm để test”, hay “vầy là ổn rồi”, hay “kệ m* nó đi vầy là được rồi!!!”

Nếu làm đúng ngay từ đầu, anh em sẽ đỡ tốn thời gian quay lại chỉnh sửa. Đó là nguyên lý.

Một function dù khó cỡ nào, nếu cố gắng phân tích đúng ngay từ đầu, thì nỗ lực sửa, fix bugs là rất ít.

Đặc biệt, công việc của người làm phân tích & thiết kế như BA mà sai ngay từ đầu, thì rất dễ đẩy công sức của 500 anh em xuống biển. Đã không có thời gian, nay còn tự bóp mình. Kịch bản rất dễ đẩy các anh em vào con đường phạm pháp, quynh đệ tương tàn…

Làm việc có tâm, sâu sắc hơn một chút

Thêm một ý nữa là dù ít hay nhiều, hãy để tâm hơn một xíu ngay trong quá trình làm sản phẩm của mình. Dù cho anh em có đang outsource “theo đơn đặt hàng” cho một software nào đó.

Chúng ta, Biz Analyst, hay Dev, hay thậm chí cả QC khi design, build hay test một tính năng nào đó, HÃY LUÔN cố gắng đặt mình vào thế của người dùng cuối.

Dù biết thế giới này đã có rất nhiều yếu tố thọt vào đít anh em mỗi sớm thức dậy: deadline, sếp chửi, khách hàng dí, thằng chung team làm ẩu xém toang tám chục lần, vâng vâng và mây mây.
Nhưng hãy cố quan tâm đến góc nhìn của người dùng được chừng nào, hay chừng đấy.

Nếu vẫn thấy app mình ổn, quay sang dòm mấy cái app đang nổi, rồi quay lại dòm app mình lần nữa, thấy sao anh em :)))

Đầu bếp nấu một món theo công thức có sẵn mà không quan tâm đến thực khách là ai, khẩu vị ra sao thì chắc chắn: món đó chỉ dừng ở mức “có thể ăn” của thực khách. Hoàn toàn không để lại ấn tượng hay feelings tốt đẹp gì về món đó cả. Thậm chí vài ngày sau là quên bà nó mất mình đã từng ăn món đó ở chỗ này.

Tạm kết

Trên là vài dòng suy nghĩ vu vơ về một software thông thường và một product. Nó như kiểu giữa một chiếc xe chạy được, và phiên bản hoàn chỉnh của chiếc xe đó vậy.

Theo đó là ranh giới vô cùng mong manh, nhưng cũng là cả một bầu trời khác biệt nếu nhìn theo góc độ quality of service.

Với một software làm ra mà mình vô cùng tâm huyết, mình hay nói vui với anh em là “nâng tầm product” cho software đó 🙂 Nói trắng ra là hoàn chỉnh sản phẩm hơn mỗi ngày. Để sản phẩm ngày càng tiệm cận đến mức độ hoàn thiện cao nhất mà nó có thể.

Một lần nữa, nói vậy nhưng thực tế sẽ luôn gặp trở ngại để làm được như vậy. Cái THÚ ở đây là nằm ở khả năng luồng lách vượt trở ngại của anh em, để hoàn thiện sản phẩm được đến mức nào mà thôi.

Chúc anh em may mắn, mình đi lấp liếm fix bugs tiếp đây, baiiii.

Bài viết gốc được đăng tải tại thinhnotes.com

Xem thêm:

• Những mẹo hay để trở thành một Product Manager giỏi nhất
• Software Engineer là gì? Mô tả công việc và những kỹ năng quan trọng
• Biến Git và GitHub trở thành công cụ đắc lực cho Software Engineer

Tuyển dụng lập trình viên đãi ngộ tốt trên toàn quốc, ứng tuyển ngay!