Chúng ta đều nhận thấy s� cứng nhắc của th� giới công ngh� khi mà các tiêu chuẩn và giao thức cơ bản vẫn được s� dụng một cách “bảo th�” trong những thập k� qua, mặc dù đây được coi là một lĩnh vực khoa học có s� phát triển nhanh chóng và mạnh m�. Trong đám “bảo th�” này, email có th� coi là s� tồn tại vinh quang nhất khi b� rất nhiều đối th� lăm le thay th�. Câu hỏi đặt ra là nếu có chương trình nào thực hiện được đầy đ� các tính năng của email song lại tốt hơn, an toàn hơn, đ� rắc rối hơn thì liệu có đáng đ� đầu tư hay không?
Suốt những năm qua, đã có c� tá công ty/ t� chức n� lực nghiên cứu phát triển ra những giải pháp nhằm thay th� cho giao thức tiêu chuẩn SMTP/POP3/IMAP. Rất ít trong s� đó tìm ra hướng đi riêng cho mình, s� còn lại biến mất không sủi tăm. Điểm chung là hầu hết các công ty dạng này thường c� gắng thay đổi email theo 3 cách: Phát minh lại email và xây mới một giao thức riêng cho nó; Trực quan và đơn giản hơn; Cuối cùng là tìm cách chuyển công việc truyền thống của email sang ứng dụng khác…
Vậy phải làm th� nào đ� có th� lật đ� được v� trí thâm căn c� đ� của email? Hãy xem chia s� của các chuyên gia dưới đây.
Nhất thiết phải tạo ra được giao thức mới
Việc nghĩ ra một giao thức mới cho thư điện t� là cách hiệu qu� nhất đ� có th� thay th� e-mail truyền thống. Song đây lại là cách khó khăn nhất. Các vấn đ� mà người dùng hay than phiền nhất v� thư điện t� là vấn nạn spam, bảo mật và thiết k� giao thức không hiệu qu� chính là cơ s� cho những k� lăm le thay th� phương tiện giao tiếp này có th� tận dụng. Trong th� giới công ngh�, có v� như thay th� một phương thức “già cỗi” có tuổi đời vài thập k� là việc d� dàng. Không ch� người dùng, nhiều chuyên gia công ngh� cũng khấp khởi hy vọng v� việc có th� cải tiến phương thức giao tiếp điện t� truyền thống. Có điều, việc “phát minh lại” công c� giao tiếp qua môi trường mạng này lại dường như bất kh� thi vì các lý do sau.
Đầu tiên, việc đưa ra được một giao thức mới mà mọi người đều đồng ý s� dụng là rất khó. Việc này thường phải có những ông lớn công ngh� đứng đằng sau ủng h� và thúc đẩy mới mong phát triển được trên diện rộng. Nhưng điều đó cũng không th� đảm bảo chắc chắn. Có th� lấy Google làm ví d�, hãng này đã đưa ra các chuẩn mới của mình đ� thay th� cho chuẩn IMAP “c� l� sĩ” có t� năm 1986 nhưng ch� áp dụng cho Gmail mà thôi. Và tất nhiên điều đó ch� giải quyết được một góc nh� của vấn đ� mà thôi. Thêm nữa, giao thức mới phải được h� tr� trên c� máy trạm và máy ch� vốn dĩ đã tr� nên d� dàng hơn vào thời điểm này nh� vào các ứng dụng mail nền web. Song các thiết b� di động và máy tính truyền thống cũng cần phải giao tiếp trơn tru với nhau.
Vấn đ� th� hai gai góc hơn là s� xáo trộn một thói quen thâm căn c� đ� mà những người dùng chuẩn SMTP/POP/IMAP đã thuộc làu t� bao năm nay. Đã có một giải pháp kh� dĩ do một công ty khởi nghiệp giới thiệu là Inbox (không phải là Google Inbox). Đơn v� này muốn gói ghém các h� thống email có sẵn vào một giao thức mới cùng với các hàm API. Nếu thực s� có đ� s� người dùng ủng h� nó, thì các giao thức cũ có th� s� dụng như IETF RFC. Ý tưởng của Inbox t� ra khá đúng đắn khi s� dụng các API mã nguồn m� do GNU Affero GPL cấp phép và d� án này thu hút được rất nhiều s� quan tâm của các các nhà lập trình ứng dụng email trên nền tảng di động. Một d� án khác tương đồng với Inbox c� v� cách tiếp cận cũng như thiết k� là JMAP của FastMail. JMAP dùng JSON đ� hoàn thiện và gói gọn các yêu cầu cũng như các x� lý mà email vẫn làm như gửi và nhận thư, sắp xếp lịch làm việc, lưu tr� danh b� hay những việc tương t� khác.
Một hộp Inbox tốt hơn
Thay th� được email � mức đ� giao thức chắc chắn là vô cùng khó khăn nhưng lại thu hút nhiều người tham gia và không mấy ai quan tâm đến việc th� thay đổi trải nghiệm người dùng. Suy cho cùng thì người dùng hiện đau đầu nhiều hơn với việc quản lý email ch� ít chú ý đến vấn đ� giao thức
Những ý tưởng ch� đạo hiện nay thực ra không tồi chút nào khi c� gắng mang tới một chương trình đẹp đ� hoặc thích hợp hơn với người dùng di động. H� s� dụng các phân tích thống kê đ� có th� t� động phân loại hành vi x� lý thích hợp với từng thư điện t� với mong muốn giảm thiểu s� can thiệp th� công của người dùng đối với email. Các chương trình này s� xác định email nào cần loại b�, email nào cần tr� lời ngay tức thì hoặc tr� lời sau. Đây chính là “mục đích của th� h� chương trình email k� tiếp – email 2.0”, theo lời của Dave Bagget, CEO của Inky Mail. Ông này cho rằng các nhà phát triển “cần làm cho chương trình email phải có tính năng tương t� như các chương trình h� tr� cá nhân thay vì ch� gửi, nhận và quản lý email.”
Google t� ra rất quyết tâm với hướng tiếp cận này khi nâng cấp tính năng t� động phân loại thư mới nhận lên một tầm cao mới trong một sản phẩm với chính tên gọi Inbox. Tại đây, thư được phân loại và nhóm một cách t� động theo từng lĩnh vực khác nhau. Các thư được coi là quan trọng hơn như cập nhật thông tin v� tình trạng đơn hàng hay các chuyến đi đã được lên lịch s� được nhấn mạnh và lưu ý người dùng dưới dạng thông báo như chính các ghi chú nhắc việc mà người dùng tạo ra.
IBM cũng đang theo đuổi một d� án tương t� với mục đích phục v� tốt hơn cho các khách hàng s� dụng Lotus Notes. Chương trình Verse s� giúp biến một Lotus Note nặng n� sang dùng các tùy chọn nền web nh� nhàng hơn, tập trung hơn vào người dùng cũng như chuỗi thông tin trao đổi thay vì từng email cá biệt. Và chương trình này s� dụng tính năng phỏng đoán Watson do IBM phát minh đ� phân loại thư. Sau cùng, IBM muốn triển khai dịch v� này dành cho người dùng cuối trước rồi mới cân nhắc xem có áp dụng cho khối doanh nghiệp hay không.
Vấn đ� đặt ra cho các giải pháp tiếp cận theo hướng nhắm vào hộp thư là chúng cần t� ra ít nhất không t� hơn so với việc sắp xếp th� công của người dùng cũng như các chi tiết cá nhân hóa mà h� muốn có. Các giải pháp này cần làm cho người dùng không cảm thấy xa l� với những gì h� đã quen dùng trong bao năm qua mà lại có được các tính năng tiên tiến hiện đại hơn như đã nói � trên.
Tách email ra khỏi công việc công ty
Như vậy chúng ta đều thấy rằng các n� lực tiếp cận đ� có th� đưa ra được những chương trình thay th� email truyền thống không hẳn nằm � chương trình khách (client) hay giao thức mà nó liên quan mật thiết đến các hành x� công việc liên quan đến email. Nó có th� là chuỗi tranh luận v� một ch� đ� nào đó với đồng nghiệp, hoặc là trao đổi tài liệu qua lại… Nói chung là các hành động s� quyết định việc email đó nên phân loại như th� nào cho đúng.
Một trong s� các giải pháp t� ra hữu hiệu trong lĩnh vực này là Slack do Tiny Speck phát triển với khẩu hiệu “đ� bận rộn hơn”. Giải pháp này nằm trong s� 25 giải pháp điện toán đám mây, bảo mật và khởi nghiệp di động được đánh giá cao. Slack đưa ra cách thức phân loại các h� thống chat với nhiều “phòng” và “kênh” khác nhau, trong đó mọi đoạn đối thoại đều có th� tìm kiếm được và đồng b� t� động với nhiều ứng dụng máy khách khác nhau. Giải pháp này còn thiết k� c� việc tạo các nhóm riêng hay gửi thông điệp trực tiếp. Đây cũng là cách mà nhiều đơn v� như Dropbox, GitHub, JIRA… triển khai: tích hợp sâu với h� thống sẵn có, cung cấp các công c� và API đ� người dùng tùy biến thuận tiện cho công việc.
Một giải pháp khác là Huddle thì lại muốn đưa s� cộng tác giữa các đồng nghiệp ra xa khỏi cách thức truyền thống, s� dụng một bảng điều khiển trung tâm hiển th� dưới dạng d� án mà các thành viên trong nhóm đang làm việc chung. Các d� án có th� được khởi tạo và cùng nhau tương tác và các cá nhân có th� mời những người khác tham gia vào d� án nếu cần. Các tài liệu dùng cho d� án ch� được s� dụng nội b� và chống truy cập trái phép và giảm được s� phiền phức cũng như nguy cơ bảo mật của việc s� dụng file đính kèm (thay vào đó các thành viên trong d� án ch� cần gửi đường link cho nhau là được). Phần x� lý chuỗi hội thoại của Huddle có phần giống với các diễn đàn trực tuyến, bao gồm c� việc tranh luận theo ch� đ�.
Các giải pháp như vừa nói � trên không thực s� thay th� email mà ch� tạo ra một cấu trúc th� cấp mà thôi. Hầu hết người dùng vẫn cần email đ� giao tiếp và các tác gi� của những giải pháp này đều ý thức được việc đó. Song vấn đ� quan trọng nhất mà h� cần giải quyết là s� hữu dụng của việc đưa các tiến trình liên quan đến công việc rời xa email. Nhà phân tích Phillip Karcher của Forrester cho rằng các nhà phát triển nên theo quan điểm tiếp cận nhắm tới “doanh nghiệp xã hội” với việc xây dựng các ứng dụng “b� sung cho email ch� không phải thay th� chúng”. Ông phát biểu sau khi xem xét các s� liệu nghiên cứu rằng những người lao động không s� dụng tới khía cạnh “doanh nghiệp xã hội” thường mất nhiều thời gian tìm kiếm thông tin hơn và do vậy s� có hiệu qu� làm việc giảm sút.
Email vẫn tồn tại bất chấp tất c�
B� qua cuộc chiến âm thầm song không kém phần khốc liệt này, có th� thấy rằng email vẫn chiếm v� trí trung tâm trong công việc. Các giải pháp khác có th� tiến hóa song song nhưng v� th� mặc định của email trong hoạt động doanh nghiệp hầu như không suy chuyển.
Galen Gruman của t� InfoWorld đã m� x� khá k� những điểm mà email b� cáo buộc như công ngh� cũ, thông tin thừa mứa và duy trì rất tốn công. Nhưng đối với mỗi cáo buộc này, Gruman cũng cho biết là các quan điểm phản biện cũng rất mạnh m�. Việc quá tải email thường có nguyên nhân đến t� thói quen s� dụng của người dùng nhiều hơn là công ngh�. Mặt khác thì việc duy trì h� tầng CNTT của doanh nghiệp là không h� đơn giản do vậy quay lưng với email đ� tìm đến một giải pháp mới cùng những công c� h� tr� chưa được th� nghiệm k� càng là quá phiêu lưu. Điều quan trọng hơn hết là công ngh� mới chưa chắc đã tốt hơn, trong khi email thì được chấp nhận rộng rãi � khắp nơi trên th� giới và người dùng đã quá quen với nó, b� phận k� thuật thì đã quá am hiểu nó.
Nh� lại thời điểm năm 2010, các nhà phân tích của Gartner đã d� đoán khoảng 20% s� lượng email doanh nghiệp s� được thay th� hay nói cách khác là không còn dùng tới do b� ảnh hưởng t� các mạng xã hội khác nhau. Có th� nói h� đã đúng một phần, các chương trình email đã tích hợp chéo sang mạng xã hội khá nhiều. Nhưng vai trò của email đối với doanh nghiệp vẫn còn quá lớn. Theo một cuộc khảo sát do Pew Research Internet Project tiến hành, có tới 61% nhân viên làm việc có kết nối internet đánh giá email là “vô cùng quan trọng” đối với công việc của h�, còn mạng xã hội ch� có t� l� 4% mà thôi.
Điều này không có nghĩa là email s� không có những cải tiến tốt hơn trong tương lai nhưng có điều quá trình này có th� s� kéo dài mất thời gian hơn và thận trọng hơn. Nếu giải pháp đưa ra giao thức mới “gói ghém” của Inbox được đón nhận rộng rãi và các th� nghiệm của IBM thành công cùng với việc các doanh nghiệp quyết định rằng công tác liên lạc nội b� của h� có th� chuyển dần không liên quan tới email nữa thì có th� việc trao đổi thông điệp qua mạng hàng ngày s� mang một diện mạo mới. Nhưng đ� điều đó xảy ra, cần lưu ý các yếu t� trên cần xảy ra song song ch� không th� diễn ra một cách đơn l� rời rạc.