Các phóng viên công nghệ, hãy thôi "chém gió"!

Phóng viên công nghệ chỉ là người "truyền đạt" lại thông tin từ nhân viên PR của hãng?

Nếu bạn không tin, hãy thử hỏi một phóng viên công nghệ về “những tính năng tuyệt vời nhất” của Google Maps hay mẫu iPhone mới, họ sẽ nói vanh vách, thậm chí họ còn có thể dự đoán được những tính năng này sẽ giúp cho sản phẩm đó thành công hay không. Nhưng hãy hỏi họ, ứng dụng Foursquare danh tiếng được lập trình bằng ngôn ngữ lập trình C hay Java... chắc chắn họ sẽ chẳng biết gì cả.

Điều này là dễ hiểu bởi hầu hết các phóng viên công nghệ chỉ biết chăm chăm chú ý vào những đặc tính của sản phẩm bằng con mắt của người tiêu dùng: Màn hình có gì, hiển thị ra sao, sản phẩm có các tính năng gì và người dùng sẽ được trải nghiệm cái gì… thay vì điều gì đã làm nên những tính năng, trải nghiệm đó. Nói một cách hình tượng, họ chỉ đang “chém gió” mà chẳng hiểu gì về sản phẩm và thực chất họ cũng chỉ là “người dùng” sớm hơn những người khác mà thôi.

“Tôi cho rằng khoảng cách giữa các nhà phát triển và các phóng viên công nghệ đang ở mức quá lớn, khó chấp nhận được. Điều này về lâu dài sẽ gây hại đến khả năng thấu hiểu ngành công nghiệp CNTT hay lĩnh vực công nghệ cao”, Sam Petulla, một biên tập viên của Contently – một dịch vụ kết nối các thương hiệu lớn với giới truyền thông, “Thông thường, khi mọi người hỏi một nhà phát triển một câu hỏi nào đó, cái họ muốn nhận là lời giải thích về kỹ thuật nhưng thường họ cũng nhận thức được sự hiểu biết về cách thức mà công nghệ được triển khai. Điều này có ý nghĩa lớn hơn nhiều. Nếu bạn dành thời gian để đào sâu vào những gì họ đang tư duy về mặt kĩ thuật bạn sẽ biết làm thế nào để nó kết nối được với một lượng độc giả rộng lớn hơn”.

Tất nhiên, chẳng cần phải biết lập trình bằng một thứ ngôn ngữ nào đó mới có thể làm phóng viên công nghệ nhưng có một điều chắc chắn rằng các phóng viên sẽ làm công việc của mình xuất sắc hơn nếu họ biết được rằng vì sao nhà phát triển lại dùng Ruby on Rails chứ không dùng Python.

“Các sản phẩm công nghệ không phải là thứ ảo thuật nào đó”, Manoush Zomorodi của chương trình phát thanh New Tech City bình luận, “Chỉ cần hiể một chút ít về việc các dòng mã lệnh làm việc như thế nào, các bạn sẽ giúp người dùng lựa chọn một cách chính xác hơn sản phẩm nào bởi các nhà phát triển luôn nhắm đến một cái đích cụ thể”.

Có điều, “vật cản” lớn nhất khiến các phóng viên công nghệ khó có thể tiếp cận được với những kỹ sư phát triển sản phẩm chính là các nhân viên PR của hãng. Họ được yêu cầu “nhại” lại lời của nhân viên PR rằng sản phẩm đó “tuyệt vời” thế nào mà thôi chứ không cần biết để làm ra “sự tuyệt vời” đó, các kỹ sư đã phải làm gì.

Theo nhà báo Ben Fischer của Thời báo kinh doanh New York (NBJ) thì một lý do nữa khiến các phóng viên công nghệ “mù tịt” về mặt kỹ thuật là vì họ luôn tin rằng người tiêu dùng sẽ không muốn tìm hiểu sâu hơn về sản phẩm. Hầu hết các phóng viên và cả nhà sản xuất chỉ chú ý đến khía cạnh kinh doanh mà không biết rằng sự minh bạch về mặt kỹ thuật sẽ giúp cho sản phẩm của họ trở nên cạnh tranh hơn. Đó cũng chính là lý do vì sao rất ít phóng viên công nghệ “biết đôi chút” về ngôn ngữ lập trình nên họ chỉ còn cách là phát ngôn lại theo hướng dẫn của phòng PR.

Để thay đổi điều này không hề khó như các phóng viên tưởng. Thay vì hỏi những câu hỏi chung chung về sản phẩm, họ hãy nên mạnh dạn chất vấn nhà sản xuất những câu hỏi kiểu như: Nhóm của ông/bà đã dùng công cụ gì để phát triển (thử nghiệm, mô phỏng, kiểm tra lỗi hay quản lý tác vụ…) sản phẩm này? Nguyên tắc tạo ra trải nghiệm người dùng của công ty là gì? Sản phẩm này đã sử dụng bao nhiêu mã nguồn mở? Chúng có đóng góp như thế nào đối với sản phẩm? Sau một đợt cập nhật lớn, bao nhiêu dòng mã lệnh (code) đã được thay đổi?....

Cale Weissman, một phóng viên của tờ Business Insider lại gợi ý rằng, các phóng viên công nghệ nên hỏi về quá trình lập kế hoạch trước khi nhà phát triển lập trình và họ đã gặp những lỗi (bug) gì trong quá trình đó..

“Tất nhiên, bạn có nhận được câu trả lời không và câu trả lời có thỏa đáng không lại là một vấn đề hoàn toàn khác”, Cale Weissman nói.

Ben Fischer lại nêu ý kiến, các phóng viên nên hỏi nhà sản xuất về “sự khác biệt về mặt kỹ thuật” của sản phẩm này so với các đối thủ cạnh tranh và hãng đặt ra những yêu cầu gì khi tìm kiếm một giám đốc công nghệ (CTO) cho dự án này.

Nếu các phóng viên có thể giải thích toàn bộ những sự “tuyệt vời” hay “khác biệt” của sản phẩm bằng một thứ ngôn ngữ đậm tính kỹ thuật những dễ hiểu đối với người dùng, chắc chắn họ sẽ nhận được sự tin tưởng cao hơn rất nhiều so với vô số những bài báo “ca tụng” khác.

Francis Tseng, một nhà phát triển đang làm việc cho Quỹ Knight Foundation Prototype, cho rằng có rất ít các phóng viên công nghệ có thể làm tốt việc này, “Chẳng có bài báo nào lọt vào mắt tôi được cả. Tất cả bọn họ chỉ biết nhại theo và nói đến khía cạnh kinh doanh. Các phóng viên luôn tin rằng rất khó để có được những thông tin kỹ thuật kiểu đó nhưng thực sự là hầu hết các kỹ sư phát triển sản phẩm đều có blog chính thức của mình. Tất nhiên, điều đó đòi hỏi phóng viên phải biết về ngôn ngữ lập trình”.

Có lẽ, theo ý của Francis Tseng thì muốn trở thành một phóng viên công nghệ thực thụ thì nhiều người phải bắt đầu đi học… lập trình.