Đã 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.

“Chúc mừng em đã làm xong, giờ vô maintain cho nó chạy ổn nhé”
Đó 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.
Hế lô anh em, mình là Thịnh, và mình đang làm BA tại Bosch. Thinhnotes là nơi mình tập viết và góp nhặt những trải nghiệm THÚ vị trong cuộc sống hằng ngày. Hi vọng những bài notes cu te này sẽ giúp ích được anh em 🙂
17/09/2020 at 5:44 chiều
Bài này anh Thịnh viết dễ hiểu quá. Cảm ơn anh.
18/09/2020 at 7:51 sáng
Cảm ơn em. Chúc em một ngày vui vẻ <3
05/10/2020 at 10:48 sáng
Chào mừng anh trở lại, chờ lâu quá bruh ơi!!!
05/10/2020 at 10:04 chiều
Cảm ơn em. Anh biến mất tiếp đây :)))
05/10/2020 at 9:18 chiều
Cám ơn anh đã viết ra bài này, em học hỏi được nhiều lắm.
Qua đây cho em – đang làm công ty product, hỏi kinh nghiệm của anh khi làm việc với team Dev ạ. Vì khi em nhận require từ user -> analyst xong -> qua nói chuyện với Dev thì Dev bảo không làm được hoặc khó làm, em lại phải back lại user. Cứ thế nó cứ xoay vòng vòng. Mong a cho em ít kinh nghiệm xử lý tình huống này ạ
12/10/2020 at 8:57 chiều
Hi Vũ, chính vì vậy nên role em đang làm cần phải hiểu về technical đó 🙂 Hiểu vấn đề mình đang giải quyết là một chuyện. Hiểu xem tech ở đây có thể giải quyết được bao nhiêu % vấn đề lại là chuyện hoàn toàn khác. Nên áp lực này là rất tốt để em chịu khó tìm hiểu sâu hơn về kỹ thuật khi đề xuất giải pháp với Users.
Ráng cố gắng tận dụng mấy điểm trên vào dự án thực tế thì mới ra được 2 chữ “kinh nghiệm” lận. No pain no gain. Tự tin lên em nhé!
08/11/2020 at 7:20 chiều
Qua một thời gian làm BA, em thấy ngập mặt quá. Rất cần lời khuyên của 500 anh em.
Công ty chỉ có 2 thanh niên làm BA, công ty về products. Em cảm thấy ko handle được công việc on time được, lúc nào cũng cần OT. Lí do một là em chưa có kinh nghiệm nhiều ( em mới đi làm đc 7 tháng và em thấy em vẫn ngu si ), hai là khối lượng công việc lớn.
Lấy ví dụ cụ thể là sếp giao cho em task A, em đi ngồi research, rồi ngồi nghĩ, tiếp theo vẽ mockup để sếp duyệt, sau đó mới đi viết document. Nhưng em tốn rất nhiều thời gian để làm những việc trên, đặc biệt là công việc rồi research và nghĩ. Trong lúc làm việc thì có cả đống thứ phát sinh với dự án đang làm ( bên em dự án về liên tục, luôn phải làm những function mới, còn to nữa ). Em thường hay bị miss các chức năng bị ảnh hưởng, em nhận ra điều đó và luôn có gắng theo flow, nhưng em yếu, overview không tốt nên em vẫn luôn cố gắng cải thiện. Em tự nhận em không giỏi nên mọi thứ em cần thời gian cải thiện dần, điều này chẳng phù hợp với công việc cần sự thích ứng nhanh như thế này. Và em bị miss như thế sẽ ảnh hưởng đến scope của project, nếu thêm thì mọi người làm rất mệt mỏi. Em thấy em cải thiện nhưng tốc độ không được như mọi người expect, em cảm thấy rất stress và mệt mỏi.
Mọi người giúp em với, em cảm thấy không được encourage, ko có năng lượng làm việc, làm công việc này khiến em có suy nghĩ tiêu cực dù học được rất nhiều
28/11/2020 at 10:18 sáng
Hi Phương, sorry em anh bị miss cmt này mất.
Cảm ơn những chia sẻ của em.
Một điều đáng mừng là em tự nhận ra là mình chưa đủ giỏi, chưa đủ tốt để handle khối công việc được giao 😀 đó là điều quan trọng nhất, như vậy thôi là em đã hơn được nhiều người rồi. Có nhìn nhận >> có thấy yếu kém >> thì mơi tự nâng cấp mình lên được em à.
Còn việc em không handle nổi workload hiện tại anh nghĩ cũng bình thường thôi. Công việc BA bản chất khó cũng do mình, mà dễ cũng do mình. Mọi thứ ko tự nhiên nó đến mà cần mình làm >> chiêm nghiệm >> rồi rút kinh nghiệm >> để cải thiện ngày qua ngày thôi.
Hiện tại anh nghĩ em nên nhờ sếp trực tiếp của em tư vấn và cho em một số giải pháp (hãy cố gắng trao đổi và đề xuất giải pháp trước rồi hẵn xin ý kiến). Như vậy sẽ thực tiễn hơn cho bối cảnh công việc mà em đang gặp.
Rõ ràng em thấy, BA/ PO ko phải là công việc dễ dàng, sau này em sẽ còn phải deal với rất nhiều thứ. Mấu chốt là mình có balance được những thứ đó để deliver được sản phẩm như mình mong đợi hay không. Nên càng sớm bước ra khỏi comfort zone, sẽ càng tốt hơn cho mình sau này.
Kiếm 1 cuối tuần nào đó, relax hoàn toàn vào 2 ngày này rồi làm những thứ mình thích. Sau khi cố gắng hết sức mình thì đâu cũng vào đấy mà. Yên tâm và cố gắng lên nhé! Keep trying! Chúc em may mắn!
10/11/2020 at 10:12 chiều
Hi anh Thịnh. Đọc bài viết của anh mà ngồi cười xả láng, vì thấm kha khá các case anh đề cập
Em là IT BA. Em từng làm outsourcing, và bây giờ đang làm tại 1 cty product. Đối với riêng em, như từ vực sâu đc tiên nữ dìu lên thiên đàng, chủ yếu là vì ko còn bị dí “làm xong” ở 3-4 dự án cùng lúc (chưa kể bị dí phải “làm đẹp” cái mã 1 chút để đi pitching)
Cái điều làm em bất ngờ nhất, là điều em đã biết từ trước, cũng chính là yếu tố khiến em muốn nhảy sang làm product là có thời gian quan tâm chi tiết tới nhiều scenario, và đi sâu được nhiều non-functional. Cảm giác làm lẹ lẹ cho kịp deadline với cảm giác phân tích 1 function nó sướng khủng khiếp.
Còn nhiều điểm khác muốn thảo luận với anh em lắm mà làm biếng type quá, hi vọng anh Thịnh có thể tổ chức 1 buổi nói chuyện nào đó, hay tạo 1 group nào đó để anh em BA/PO có thể tương tác dễ hơn, manh động hơn 😀
Anw, thank anh Thịnh vì những bài viết đi vào tâm can của BA 😀
28/11/2020 at 10:24 sáng
Hi Vũ, sr em anh bị miss cmt này mất. Cảm ơn em đã chia sẻ 🙂
Thật sự cái cảm giác phân tích & thiết kế các scenario nó đã sướng, mà còn sướng hơn là khi thấy nó được áp dụng và vận hành thực tế bên ngoài đúng ko em 😀
Chúc em ngày càng sẽ nghiên cứu thêm được nhiều thứ hay ho để phục vụ cho công việc nhé. Tìm đúng công việc mình phù hợp là bàn đạp lớn để mình tò mò và học hỏi thêm mà 🙂 Chúc em may mắn nhé!
12/01/2021 at 7:00 chiều
Quất cảm ơn anh Thịnh rất nhiều,
Em đã đọc rất nhiều bài viết ở các nguồn khác nhau nhưng em đặc biệt thích đọc các bài viết ở page thinhnotes vì văn phong vừa thô vừa thực nhưng không kém phần ‘tấu hài’ của anh.
Khi đọc các note của anh em thấy được bản thân mình trong đó, nhờ đó em cũng biết mình nên và phải làm gì để bước tiếp trên con đường này.
Chốt lại là page đã cho em trải nghiệm rất tuyệt vời về mọi mặt, em quyết định mình cũng sẽ làm một personal blog tương tự để viết nên câu chuyện của mình và truyền cảm hứng cho những bạn khác.
Chúc anh Thịnh đủ nhé <3
16/01/2021 at 10:14 sáng
Mới đọc sơ tưởng e nói văn phong vừa thô vừa tục :))) Cảm ơn Quất nhiều nhé, ủng hộ ý tưởng làm blog của em, take action ngay em nhé 🙂