Buộc mọi kỹ sư tham gia cuộc gọi bán hàng, và chỉ sau 2 tuần nền tảng đã được viết lại hoàn toàn

• Một startup đã để các kỹ sư trực tiếp tham gia các cuộc gọi bán hàng, từ đó làm thay đổi tận gốc cách họ phát triển sản phẩm
• Trong các cuộc gọi bán hàng, họ nhận ra sản phẩm của đối thủ quá phức tạp với người dùng không chuyên kỹ thuật, và khách hàng không cần log hay chỉ số mà chỉ muốn một dấu xác nhận (check xanh) cho biết hệ thống giám sát đang hoạt động, thậm chí chỉ hỏi “không thể có ai làm giúp luôn sao?”
• Nhờ vậy, đội ngũ vốn tập trung vào backend đã hiểu được góc nhìn người dùng và bắt đầu tự hình dung một kiến trúc mới mà không cần PM can thiệp
• Chỉ trong 2 tuần, họ đã cắt giảm 60% tính năng của nền tảng, thêm thanh tiến trình, xây dựng tích hợp Slack và quy trình làm thay, kết quả là ticket hỗ trợ giảm 70%
• Bài học rút ra từ trải nghiệm này là người dùng chỉ muốn vấn đề được giải quyết chứ không quan tâm tới code thanh lịch, và tính năng không chỉ tạo ra lượng code mà còn tạo ra chi phí dưới dạng sự bối rối của người dùng

---

Bối cảnh và thử nghiệm

• Một kỹ sư DevOps cấp cao từng phản đối việc tham gia cuộc gọi bán hàng, nhưng đã đồng ý với điều kiện chỉ thử tối thiểu 5 cuộc gọi
• Nhà sáng lập cho rằng chỉ khi kỹ sư trực tiếp nghe ngôn ngữ và vấn đề của khách hàng thì cách thiết kế sản phẩm mới thực sự thay đổi

Insight thu được từ các cuộc gọi bán hàng

• Họ nghe rằng sản phẩm của đối thủ quá phức tạp với người dùng không chuyên kỹ thuật
• Khách hàng muốn một xác nhận trực quan đơn giản như dấu check màu xanh hơn là các chỉ số phức tạp
• Nhiều khách hàng yêu cầu “dịch vụ làm thay”, tức là họ muốn thuê ngoài luôn việc giải quyết vấn đề chứ không chỉ đơn thuần là sử dụng công cụ

Kết quả của việc viết lại sản phẩm

• Nhóm đã loại bỏ 60% tính năng hiện có để tập trung vào những gì cốt lõi
• Họ thêm một thanh tiến trình đơn giản để cải thiện trải nghiệm sử dụng
• Tích hợp Slack giúp đơn giản hóa luồng trao đổi và hỗ trợ
• Họ cung cấp quy trình Done-for-you để phản ánh trực tiếp nhu cầu khách hàng
• Cuối cùng, ticket hỗ trợ giảm 70%, đồng thời tính dễ dùng và mức độ hài lòng với sản phẩm tăng rõ rệt

Bài học cốt lõi

• Người dùng không muốn một lời giải kỹ thuật thanh lịch, họ muốn vấn đề được giải quyết
• Hiểu người dùng quan trọng hơn độ chính xác kỹ thuật
• Mọi tính năng đều đi kèm một chi phí không phải là code mà là sự bối rối của người dùng

Thay đổi trong văn hóa đội ngũ

• Sau đó, công ty quy định mọi kỹ sư phải tham gia 5 cuộc gọi bán hàng mỗi quý
• Việc kỹ sư trực tiếp nghe sự mệt mỏi của khách hàng và tiếp xúc với yêu cầu kiểu “chỉ cần nó hoạt động ổn là được” đã trở thành một phần văn hóa để bồi đắp trực giác sản phẩm

---

Tóm tắt chính từ bình luận Reddit

• Tranh luận về vai trò PM
  • Một số người chỉ ra vấn đề là thiếu một Product Manager giỏi, và cho rằng để kỹ sư còn phải làm cả cuộc gọi với khách hàng là không hiệu quả
  • Ngược lại, cũng có ý kiến phản biện rằng “PM rốt cuộc chỉ đóng vai trò người phiên dịch, còn kết quả tốt nhất xuất hiện khi kỹ sư trực tiếp sở hữu vấn đề của khách hàng”
• Giá trị của điểm chạm với khách hàng
  • Nhiều bình luận nhấn mạnh rằng trải nghiệm để kỹ sư trực tiếp nghe tiếng nói người dùng mang lại insight rất mạnh
  • Cũng có ý kiến cho rằng ở startup giai đoạn đầu hoặc đội ngũ nhỏ, việc kỹ sư đồng thời đảm nhiệm một phần vai trò PM là điều khá phổ biến
• Góc nhìn phê phán
  • Có ý kiến chỉ trích rằng “đây đơn giản là việc đổ thất bại về lãnh đạo/văn hóa sang cho kỹ sư”
  • Cũng có phản bác rằng “cắt bớt tính năng và đơn giản hóa có thật sự là cải tiến không”, đồng thời cảnh báo nguy cơ dài hạn là phớt lờ power user và nhu cầu tính năng nâng cao
• Chia sẻ các trường hợp tích cực
  • Nhiều người kể lại trải nghiệm ở các ngành như ngân hàng, thiết bị y tế..., nơi cũng từng có cơ chế để mọi nhân viên đều trải nghiệm hỗ trợ khách hàng hoặc bán hàng
  • Cũng có sự đồng tình rằng “Dogfooding” hay “trực tiếp đứng trước khách hàng” giúp ích cho chất lượng sản phẩm và văn hóa đội ngũ
• Hàm ý tổng hợp
  • Việc khiến mọi người trực tiếp cảm nhận vấn đề của khách hàng là một công cụ học tập rất mạnh, nhưng
  • Đồng thời, điểm cốt lõi của tranh luận là về lâu dài cần kết hợp điều đó với năng lực PM, UX và thiết kế chuyên nghiệp để xây dựng một chiến lược sản phẩm cân bằng hơn

[meteorizer]

Rốt cuộc thì đây là vấn đề về hiệu suất thôi.
Việc trao đổi trực tiếp với khách hàng thực sự có rất nhiều điểm tốt, nhưng
do các cuộc họp, cuộc gọi và những trao đổi thường xuyên, tính liên tục của công việc hay bị gián đoạn và thời gian có thể đầu tư cho phát triển cũng giảm đi.
Nếu vậy, công ty sẽ phải lập kế hoạch tuyển dụng để ứng phó với năng suất bị giảm.
Vấn đề là đa phần họ lại không có ý định làm vậy.
Cuối cùng, vì thiếu thời gian, càng về sau khả năng chất lượng suy giảm sẽ càng cao.
Tôi nghĩ cần cân nhắc kỹ cả mặt lợi lẫn mặt hại.

[laeyoung]

Mình không rõ vì sao trên Hacker News lại để liên kết old reddit, nhưng đường dẫn tới giao diện reddit hiện tại nằm ở đây.

[xguru]

Có vẻ trên Hacker News, khi đăng URL Reddit thì đa số mọi người dùng old reddit. Chắc là vì nó nhẹ hơn.

[cnaa97]

Nếu là một tổ chức đặt mục tiêu nâng cao mặt bằng tối thiểu, thì tôi thừa nhận rằng mô hình tổ chức theo vai trò như một đội chỉ gồm lập trình viên web front-end hay một đội phát triển ứng dụng là phù hợp.

Nhưng với những đội nhóm hoặc tổ chức nhắm tới mức trần cao hơn, việc tổ chức theo vai trò chắc chắn sẽ có giới hạn.
Cũng như nội dung bài viết, câu hỏi đặt ra là: có nhất thiết phải để planner, designer, PM và engineer mỗi người chỉ đảm nhận phần việc riêng của mình rồi làm việc như băng chuyền trong nhà máy hay không? Thay vì kiểu công việc "người phụ trách" điển hình, chỉ đảm nhận một vài phần việc được giao, thì lý tưởng hơn là các thành viên có chuyên môn ở từng lĩnh vực cùng tập hợp lại, cùng thiết lập mục tiêu chung và toàn bộ thành viên cùng hỗ trợ lẫn nhau.

Nhiều công ty tổ chức bộ máy theo dạng task force như tách công ty con, lập nhóm mới, nhưng vì cách này cũng chỉ là gom người lại theo con người (vai trò), nên dễ phát sinh sự củng cố tiêu cực (những kiểu như "mình đang cố làm gì đó mà công ty chẳng hỗ trợ, thôi cứ bỏ cuộc vậy"), và cuối cùng có thể chỉ đánh mất những nhân sự chủ chốt như key member. Vì vậy, tổ chức theo mục tiêu cũng nhất thiết cần có sự hỗ trợ tích cực từ tổ chức theo vai trò.

[GN⁺]

Ý kiến trên Hacker News

• Cuối cùng, họ đã tự hình dung ra một kiến trúc hoàn toàn mới mà không cần tôi “PMing”. Lý do là vì cuối cùng họ cũng hiểu đúng ai mới là người thực sự dùng sản phẩm của chúng tôi. Nhìn tổng thể trải nghiệm này, kết luận là: “Khi giao các cuộc gọi bán hàng cho kỹ sư, hóa ra vấn đề là PM đã không truyền đạt tốt giữa khách hàng và đội kỹ thuật, còn kỹ sư DevOps lại là người chuyển nhu cầu khách hàng thành giải pháp chạy được nhanh nhất.”
  • Có những lúc kỹ sư quá tự tin nên cho rằng người dùng đang dùng sản phẩm sai. Theo logic đó, vấn đề xảy ra là vì “người dùng ngốc nghếch”, chứ không phải do thiết kế phức tạp mà tôi tạo ra có vấn đề. Chỉ riêng phe Desktop Linux thôi cũng có thể viết cả một cuốn sách về chuyện phớt lờ phàn nàn của người dùng. Nếu một kỹ sư cứng đầu tin rằng mình giỏi hơn cả PM lẫn người dùng thì sẽ chẳng có gì tiến triển. Nhưng nếu ném chính kỹ sư đó ra đối diện trực tiếp với người dùng, thay vì PM thân thiện thường ngày, họ sẽ gặp những user đang bực bội và chê bai “kiệt tác tuyệt vời này” như thể nó là một con hamster đầy rắc rối. Quá trình đó vừa đáng sợ vừa làm tan vỡ cái tôi của kỹ sư. Theo góc nhìn của tôi, việc này không phải để chứng minh PM ngu ngốc, mà để khiến kỹ sư biết khiêm tốn hơn. Rồi theo thời gian, sự tự mãn của kỹ sư lại quay về, nên quá trình này cần được lặp lại định kỳ
  • Tôi là người duy nhất trong nhóm cơ khí của một tập đoàn lớn biết viết code. Đội IT nội bộ tự làm nhiều phần mềm khác nhau, nhưng phần lớn đều bị các thành viên trong nhóm tôi chê dở. Vì vậy tôi trực tiếp nghĩ ra công cụ để làm lại chúng, hoặc bổ sung cho những chương trình “tệ” mà không thể thay thế hoàn toàn, để công việc dễ hơn. Không hẳn là tôi lập trình giỏi hơn đội IT in-house, mà tôi nghĩ mình hiểu rõ hơn cái gì thực sự cần cho chính nhóm mình vì tôi có góc nhìn của người dùng thực tế. Và vì tôi chính là người dùng phần mềm này nên động lực của tôi dĩ nhiên cũng cao hơn. Vì vậy tiêu đề bài viết này khiến tôi rất đồng cảm. Dù vậy, tôi cũng nghĩ điều bài viết mô tả hoàn toàn có thể xảy ra ngoài đời. Chỉ là tôi không quen với các quy trình phát triển phần mềm/quản lý dự án chính thức
  • Tôi điều hành một startup công nghệ nhỏ có doanh thu 2 triệu USD mỗi năm. Thỉnh thoảng khi thiếu nhân sự hỗ trợ, tôi tự mình phụ trách customer support trong vài ngày. Mỗi lần như vậy, tôi lại ngạc nhiên khi phát hiện ra rất nhiều phàn nàn của khách hàng mà bình thường chẳng bao giờ được chuyển đến đội kỹ sư. Nhân viên support có xu hướng tập trung vào việc tự “giải quyết” vấn đề nên các cải tiến gốc rễ thường không đi tiếp được đến engineering
  • Điều đáng chú ý là chẳng ai hỏi vì sao phần mềm ban đầu lại tệ đến vậy. Theo tôi, không thể đổ toàn bộ trách nhiệm cho một PM. Thực ra đây là vấn đề hệ thống: những mô hình như Agile/Scrum làm trách nhiệm bị làm mờ đi, còn lập trình viên thì cứ phải xử lý các ticket được viết sơ sài theo chu kỳ quá gấp, cuối cùng sinh ra phần mềm nửa vời như thế này. Đây là sản phẩm thường thấy khi các tổ chức phần mềm “hiện đại” phình to ra
  • Điều đầu tiên tôi nghĩ khi đọc bài này là: “Trước khi PM can thiệp hết vào mọi thứ, phần mềm vốn từng được làm theo kiểu này.” Nếu để kỹ sư ngồi cạnh người thật sự vận hành công việc, rất nhiều lần tôi thấy PM thực ra không cần thiết và mọi người đều hạnh phúc hơn nhiều. Dĩ nhiên vẫn có những PM xuất sắc, nhưng theo kinh nghiệm của tôi thì PM thường có xu hướng ám ảnh với chuyện tranh giành địa bàn, và đáng ngạc nhiên là nhiều người cũng không hiểu rõ cả phía engineering lẫn phía khách hàng
• Tôi đã nhiều lần trải qua chuyện kỹ sư lệch pha với sản phẩm ở nhiều nơi. Có khi ai đó âm thầm thêm thứ gì đó mà không ai khác biết, khiến UI trở nên khó hiểu, hoặc nội dung trên website không khớp với sản phẩm thực tế. Rồi vòng lặp dài kiểu [sản phẩm -> PM -> hệ thống theo dõi bug -> kỹ sư -> sửa -> QA -> sản phẩm] khiến những thứ quan trọng thì được sửa, còn những bất tiện nhỏ thì rất lâu vẫn không được xử lý. Nếu chỉ còn [sản phẩm <-> kỹ sư] thì năng suất có thể tăng lên đáng kinh ngạc. Nhiều kỹ sư thậm chí chưa từng trực tiếp trải nghiệm toàn bộ sản phẩm, và cũng không biết nó khác gì so với năm ngoái
  • Tôi cũng có trải nghiệm tương tự, và lạ là hiện tượng này xảy ra thường xuyên hơn ở những nơi có nhiều PM. Trải nghiệm tệ nhất tôi từng gặp là một công ty cố áp tỷ lệ bắt buộc giữa PM và “Product Designer” theo đúng số lượng kỹ sư. Gộp designer, product, project, program manager lại thì còn đông hơn cả kỹ sư. Kết quả là mọi thứ chỉ trở nên tệ hơn. Việc phải né tránh bộ máy quan liêu của PM và nỗi lo họ xâm lấn vai trò của tôi cũng đã là cả một công việc. PM giỏi thật sự rất quý, nhưng tôi có cảm giác ngày nay danh xưng Product Management đang thu hút quá nhiều người quan liêu và ám ảnh quy trình. Các influencer về Product Management cũng đang làm vấn đề trầm trọng thêm
  • Nhưng tôi cũng không nghĩ ép kỹ sư phải tham gia sales call là đáp án đúng. Để xử lý tốt một cuộc gọi như vậy cần rất nhiều soft skill, trong khi kỹ sư không được đào tạo cho việc đó, và lúc tuyển dụng cũng không xem đây là tiêu chí. (“Sales call” ở đây là các cuộc gọi tư vấn ban đầu trước demo hoặc PoC. Với các buổi demo presales phức tạp, kỹ sư có thể tham gia cùng, nhưng vai trò đó về nguyên tắc nên do phía sản phẩm đảm nhiệm)
  • Có vô số cách mọi thứ có thể đi sai, và tôi đã tận mắt thấy đủ kiểu. Ví dụ như PM hoặc PO độc chiếm toàn bộ giao tiếp với khách hàng, hoặc khách hàng tránh nói chuyện trực tiếp với developer và chỉ diễn giải yêu cầu thông qua user manager, hoặc bản thân developer chỉ muốn viết code, hoặc mọi giao tiếp đều bị ép phải đi qua PM và bug tracker. Khi dùng các nền tảng phần mềm thương mại, giới hạn kỹ thuật cũng có thể khiến workflow trở nên rất tệ. Lúc nào cũng có một yếu tố nào đó chặn luồng giao tiếp, và người chặn có thể là khách hàng, quản lý trung gian hoặc developer. Thậm chí không hiếm trường hợp một giải pháp sai đã được chốt sẵn từ đầu, còn developer và người dùng thì bắt đầu mà không hề biết rõ chi tiết. Có rất nhiều con đường dẫn đến việc không thể tạo ra một hệ thống thực sự tốt cho người dùng
  • Tôi nghĩ việc kỹ sư hiểu sâu về chính sản phẩm là cực kỳ quan trọng. So với kỹ thuật thuần túy, việc làm cho khía cạnh sản phẩm khớp đúng còn khó hơn. Phần lớn sản phẩm tôi từng trải qua cuối cùng đều thất bại vì lý do sản phẩm, nên về mặt logic, việc dồn sức mạnh của cả đội vào hướng này hợp lý hơn
• Ở chiều ngược lại, cũng có trường hợp kỹ sư rốt cuộc bị biến thành đội hỗ trợ kỹ thuật. Nếu phải trực tiếp hỗ trợ từng khách hàng, bạn sẽ chỉ tích lũy hotfix và các giải pháp tùy biến riêng lẻ, mà tất cả lại không được test tử tế, nên technical debt cứ chồng chất. Đến khi một đối thủ lớn hơn, được đầu tư bài bản hơn làm ra sản phẩm đẹp hơn thì bạn sẽ nhanh chóng bị bỏ lại. Theo tôi đây là thất bại điển hình của product management. Tức là PM không truyền đạt đúng nhu cầu khách hàng cho kỹ sư, hoặc cũng không đủ sức push theo chiều ngược lại. Việc đưa kỹ sư vào sales call là cách không thể scale khi tệp khách hàng đã đủ lớn và trưởng thành. Nếu một product manager thực sự muốn kỹ sư đi sales call, thì kỹ sư đó cũng nên được chia một phần commission của từng account cho công bằng. Tôi thì sẽ không bao giờ làm sales call nếu không có commission
• Đây là chiến lược rất hiệu quả trong môi trường như startup, nơi mọi thành viên cần đồng cảm sâu với nhu cầu khách hàng. Khi tôi được tham gia trực tiếp vào việc xác định yêu cầu sản phẩm và nắm rõ thực tế công việc, tỷ lệ thành công của dự án cao hơn rất nhiều. So với việc chỉ “nhận” yêu cầu rồi triển khai nguyên xi, kết quả đầu ra tốt hơn hẳn
  • Ý bạn là vì chính bạn đã viết ra guideline nên dễ làm theo hơn, hay là vì việc tham gia trực tiếp đã tạo ra UX tốt hơn?
• “Hoàn thành rewrite trong 2 tuần, cắt 60% tính năng, thêm progress bar đơn giản, xây tích hợp Slack, cung cấp workflow ‘done-for-you’ -> ticket hỗ trợ giảm 70%” Nếu chuyện này là thật thì rõ ràng đã có điều gì đó sai nghiêm trọng
  • Reddit nổi tiếng là nơi bùng nổ các bài bịa đặt, và câu chuyện này, dù lấy cảm hứng từ chuyện thật hay hoàn toàn hư cấu, cũng đầy các yếu tố viết lách kiểu Reddit cộng với màu sắc business storytelling kiểu LinkedIn
  • Tôi nghĩ đây là trường hợp một B2B SaaS đã pivot nhiều lần nhưng tài liệu hướng dẫn về sản phẩm lại rất yếu. Dĩ nhiên những nút thắt kiểu này trên thực tế xảy ra thường xuyên hơn người ta tưởng rất nhiều
  • Nhìn giọng văn lặp đi lặp lại với các câu ngắn kiểu LinkedIn rồi chốt bằng một kết thúc kịch tính, có thể dễ dàng nhận ra đây là hư cấu
  • Là Reddit mà, dĩ nhiên là bịa. Tôi không hiểu vì sao những bài kiểu này thỉnh thoảng lại thành chủ đề nóng
• Nếu đúng là ra kết quả như vậy thì nên sa thải ngay PM, PO và cả đội marketing. Có hai điều rất rõ: thứ nhất, những người đó либо không hiểu khách hàng thực sự muốn gì, либо không truyền đạt được nhu cầu đó cho đội phát triển, hoặc là cả hai. Thứ hai, đầu óc của họ vận hành quá máy móc theo hệ thống, đến mức có khi tốt hơn là bỏ hết mọi tầng trung gian giữa khách hàng và đội phát triển
• Ở công ty cũ của tôi, kỹ sư cũng thường xuyên tham gia các cuộc gọi bán hàng. Trải nghiệm xem khách hàng nào muốn gì và sản phẩm của mình được bán ra sao thì khá thú vị, nhưng không đến mức mang tính đột phá. Những tính năng khách hàng yêu cầu vốn đã có trong roadmap, và cũng có một tính năng gây khó hiểu, nhưng đó là vì nó được thiết kế như vậy để đáp ứng yêu cầu đặc thù của khách hàng lớn nhất. Đội phát triển muốn làm nó đơn giản hơn, nhưng như vậy thì sẽ không đáp ứng được yêu cầu của khách hàng lớn. Cuối cùng họ tạo riêng một phiên bản “light” dễ dùng hơn, và tất cả khách hàng trừ khách hàng lớn đều có thể dùng nó. Nhưng thay đổi này cũng không phải vì kỹ sư đi cùng sales call, mà vì ngay từ đầu ai cũng đã biết nó khó dùng, chỉ là không thể sửa cho đến khi roadmap cho phép
• Tôi rất đồng cảm với đoạn “cuối cùng họ cũng hiểu đúng ai là người dùng thực sự”. Người ta thường nói “vấn đề lớn nhất của đa số kỹ sư là over-engineering”, nhưng thực tế nhiều trường hợp over-engineering lại phát sinh vì không hiểu đúng use case của khách hàng. Đây mới là vấn đề cốt lõi hơn. Là một kỹ sư, điều khiến tôi bức bối nhất thường xuyên là nhiều kỹ sư khác không hề cố tìm hiểu xem sản phẩm nào mới thực sự bán được. Lý do có thể là product-market fit, có thể là cái tôi, nhưng phần lớn là do văn hóa tổ chức hoặc cấu trúc incentive
• Trước đây tôi từng làm ở một công ty tạo giải pháp robocall cho CRM, và trong một buổi offsite họ bắt mọi người phải tự thực hiện cold call và làm theo đúng script. Họ chẳng hiểu cũng chẳng quan tâm điều đó gây bất an thế nào cho những người không làm sales. Chính từ sau chuyện đó mà tôi bắt đầu nghĩ đến việc chuyển việc
• Tôi từng trực tiếp chứng kiến một tình huống tương tự. Đội monitoring khăng khăng rằng “mọi cảnh báo đều phải do kỹ sư tuyến đầu tự tạo ticket”. Nhưng số cảnh báo lên đến hơn 10.000 mỗi giờ. Vì các vấn đề quan trọng đều bị chìm trong “nhiễu”, cấp quản lý cũng kiệt sức, và có lần người ta buộc phải nói: “Đội monitoring, chính các anh hãy tự mở ticket và xử lý hết đi.” Ngay ngày hôm sau, sau khi loại bỏ các cảnh báo mức độ thấp, số alert riêng biệt giảm xuống chỉ còn hơn chục mỗi giờ, và phần còn lại cũng lần lượt được đóng hết. Chỉ đến lúc đó “bảng điều khiển toàn màu xanh” mới là thật (trước đó chỉ là tô xanh cưỡng ép để đưa cho truyền thông và Gartner Group xem)