Đã 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.
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é 🙂
13/07/2021 at 7:00 chiều
Không có sự khác biệt nào gọi là software thông thường hay “product”. Mọi sản phẩm đều phải có người dùng mới có ý nghĩa. Chỉ có sự khác biệt giữa công ty out-source & công ty product bởi quy trình phát triển sản phẩm khác nhau.
22/09/2022 at 3:59 chiều
Trong công nghệ thì đúng là ko có sự khác biệt rõ ràng, vì SW là Product nếu công ty đó sở hữu SW đó. giống như người ta hỏi Product cúa cty bạn là gì, thì trả lời ngày đó là phần mềm A,B,C….
27/07/2021 at 8:51 chiều
Thỉnh thoảng buồn buồn, em cũng hay vào Momo lướt và chăm heo anh ạ 😀
31/08/2021 at 8:28 sáng
Anh cho em hỏi về định nghĩa “Chuẩn” ở đây với, 1 function của products được xem là phân tích chuẩn là ntn ah. vd: so sánh với sản phẩm đối thủ để làm giống với nó, làm theo kết quả phân tích mà mình đã phân tích ra, làm servey khảo sát user về tính năng sản phẩm … Những cách này có được xem là các bước giúp phân tích tính năng trở nên “Chuẩn” hơn hông ạ. Em cám ơn anh
31/08/2021 at 10:47 chiều
Cảm ơn câu hỏi của em. Thật ra CHUẨN hay không thì mình lại quay về “definition of done” (DoD) của feature, hay user story đó. Rõ ràng mỗi người có một góc nhìn “chuẩn” riêng, nhưng nếu quy về DoD thì cả team đều “on the same page” và mỗi người đều biết được mình cần phải deliver feature đó ra hình ra dáng như thế nào.
Các cách em nói là các phương pháp mình có thể dùng để moi móc thông tin >> từ đó định nghĩa được thứ mình cần deliver cho khách hàng. Ví dụ: Benchmarking như em nói cũng hay được dùng để định nghĩa những tính năng mới cần làm, mà đối thủ người ta đã làm trước đó rồi.
Và dĩ nhiên “chuẩn” có thể được nâng dần lên hoặc giảm dần theo thời gian. Ví dụ như trước chuẩn load dữ liệu là như này (là ABC), nhưng về sau network ngày càng phát triển, thì ngta lại có một số các “chuẩn” cho tốc độ load dữ liệu khác (như XYZ)…
Đó là “chuẩn” theo task công việc. Còn “chuẩn” trong bài thì anh nói đến thái độ làm việc nhiều hơn. Tức anh em cần đặt mình vào tâm thế của người dùng feature đó. Xem thử trong bối cảnh sử dụng thực tế, thì cái mình deliver có “chấp nhận được” hay không. Ở một góc độ nào đó, thì “có thể chấp nhận được” cũng được xem như chuẩn. Từ đó, tùy thuộc vào nhiều yếu tố để mình có thể tiếp tục lắng nghe người dùng và enhance các features lên dần to get it better 🙂
31/08/2021 at 10:56 sáng
Đã 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”. -> Hay :)) đúng là nếu không có market thì khỏi phải có product :))
07/09/2021 at 7:44 chiều
Chào mừng a trở lại, lâu lắm r mới thấy 1 note của a. Hiện e cũng đang làm product, từ những bước sơ khai nên cũng gặp khá nhiều khó khăn trong câu chuyện đi gặp và phỏng vấn khách hàng.
07/09/2021 at 6:54 chiều
Cảm ơn Linh, good luck em nhé
07/09/2021 at 9:25 chiều
tôi hình dung đơn giản ntn nhé:
– software là khi nói đến project team, nói đến nội bộ đội nhóm làm phần mềm; hoặc người bên ngoài/khách hàng cũng có thể nó là chúng tôi đang thuê bên A phát triển một ứng dụng/software như này như kia.
– product: và khi ứng dụng/software đó được hoàn thiện phục vụ nhu cầu bên khách hàng; mà software đó có thể nhân rộng, nâng cấp để thích nghi với các lĩnh vực khác nhau; software đó được chạy trên các nền tảng lớp giữa; phần cứng khác nhau > và phục vụ vào việc kinh doanh > làm tăng doanh thu cho khách hàng = khách hàng bán được software đó > thì lúc đó có thể được gọi là sản phầm phần mềm.
Mọi người cho ý kiến nhé.
22/09/2022 at 3:55 chiều
Em thấy, việc để có một sp hay sw gọi là có quality thì phải cả team đặt mình vào tâm thế của enduser. nhưng thực tế em thấy BA có thể làm nhưng dev thì tỷ lệ hơi ít. vì dev mà đặt tâm thế nào người dùng thì sẽ làm nhiều việc, do đó họ ko muốn. vậy là BA nếu rơi vào tình trạng đó thì xử lý sao anh nhỉ?
23/10/2022 at 5:02 chiều
Good question em, nên mình mới có QC để đảm bảo quality của software đó em. Tất cả cũng sẽ quay ngược lại BA, như thế nào là “good quality”? Good quality trong ngữ cảnh này là như thế nào.
Tính năng “lướt tin tức” của software A vào thời điểm X nó sẽ có 1 cái “tiêu chuẩn good”, khác với cái “tiêu chuẩn good” nếu so với cùng tính năng “lướt tin tức” nhưng của software B vào 1 thời điểm Y khác nữa.
Nghĩa là việc good như thế nào nó rất muôn hình vạn trạng, tùy vào effort của team lúc đó, mức độ urgent cần release như thế nào, hay quality của team lúc đó đáp ứng được ở mức nào,… mọi thứ đều phải được canh chỉnh theo đúng thực tế và CẦN ĐƯỢC DEFINE RÕ BỞI BA hoặc người làm Product.
Nên ở câu chuyện này nói thì dễ, nhưng để set một cái expectation bar chuẩn cho cả team là cả 1 quá trình em nhé. Và hoàn toàn linh hoạt ở mỗi thời điểm, mỗi tính năng, mỗi dự án, mỗi sản phẩm khác nhau.
Nếu mọi thứ được define rõ, và có thể đo lường thì dev team cứ thế mà chạy thôi. Không còn những cái mơ hồ như “thế này mới đẹp, mới ổn, mà trong khi mỗi ông lại có định nghĩa cái đẹp khác nhau” nữa. Cứ release rồi QC verify, mọi thứ minh bạch hoàn toàn.