Phần mềm linh hoạt: Khôi phục quyền tự chủ của người dùng trong kỷ nguyên ứng dụng bị khóa chặt

Động lực

Chúng ta muốn tùy biến môi trường của mình

Môi trường rất quan trọng. Để làm việc hiệu quả nhất và sống trọn vẹn nhất, chúng ta cần những không gian cho phép mỗi người thể hiện tiềm năng độc đáo của bản thân.

Một người làm đàn guitar thiết lập xưởng của họ với cưa, búa, đục và giũa được sắp xếp đúng vị trí. Họ cũng có thể tự chế tạo các công cụ mới khi cần để đạt được kết quả tốt nhất—một khối gỗ làm giá đỡ, hoặc một chiếc kìm được mài giũa thành hình dạng phù hợp.

Qua nhiều năm, một người nấu ăn tại gia dần dần tập hợp được bộ dao, thớt, nồi chảo ưng ý nhất cho mình. Họ có thể lắp thêm móc trên trần nhà và di chuyển các kệ để hỗ trợ quy trình làm việc—dù đó là nấu bữa tối trong tuần hay tổ chức những bữa tiệc ngoài trời cầu kỳ vào cuối tuần.

Đây là những tình huống thường ngày. Trong thế giới vật lý, việc tự tay tạo dựng môi trường sống diễn ra một cách tự nhiên, bởi vì thực tại vật lý có tính linh hoạt.

Nhiều thay đổi nhỏ—dán một tờ giấy ghi chú lên tường, sắp xếp lại ngăn kéo, di chuyển một món đồ nội thất—có thể được thực hiện ngay lập tức mà không cần xin phép ai. Chúng ta cũng có thể thực hiện những thay đổi lớn hơn đòi hỏi nhiều công sức và kỹ năng hơn, như xây dựng một xưởng làm việc hoặc cải tạo nhà bếp. Và nếu thiếu những kỹ năng đó, chúng ta có thể nhờ đến sự giúp đỡ của những người thợ lành nghề trong cộng đồng địa phương.

Khi làm việc và sinh sống trong một không gian vật lý mà chúng ta kiểm soát, chúng ta có xu hướng phát triển nó để phù hợp với nhu cầu của chính mình. Như Stewart Brand viết trong cuốn sách How Buildings Learn: “Thời gian cộng với khả năng thích ứng là điều khiến một tòa nhà trở nên đáng yêu. Tòa nhà học hỏi từ những người cư ngụ, và họ học hỏi từ chính nó.”

Phần mềm sản xuất hàng loạt quá cứng nhắc

Ngày nay, chúng ta dành ngày càng nhiều thời gian trong những môi trường được xây dựng từ mã nguồn, thay vì nguyên tử. Chúng ta đã đạt được nhiều khả năng trong sự chuyển dịch này—chúng ta có thể cộng tác tức thì xuyên lục địa và tìm kiếm hàng ngàn tệp tin trong chớp mắt. Nhưng chúng ta cũng đang mất đi một thứ quan trọng: khả năng tùy biến môi trường và biến chúng thành của riêng mình.

Đây là một ví dụ. Một trong những tác giả từng làm việc trong một nhóm phần mềm theo dõi công việc bằng các tấm thẻ chỉ mục dán trên tường. Nhóm liên tục cải tiến công cụ theo dõi đó—các đường băng dính được di chuyển; danh sách kiểm tra xuất hiện; các khu vực thẻ đặc biệt hình thành xung quanh lưới chính. Sự linh hoạt của công cụ đã khuyến khích sự linh hoạt trong quy trình.

Sau đó, nhóm chuyển sang sử dụng trình theo dõi vấn đề dựa trên web để hỗ trợ những người cộng tác từ xa. Giờ đây, không còn cách nào để mô hình hóa hoặc hiển thị một khu vực thẻ đặc biệt, vì vậy nhóm đã từ bỏ phần đó trong quy trình của mình. Những thay đổi quy trình tiếp theo cũng bị đình trệ. Trước đây, các ý tưởng mới chỉ mất vài phút để thử nghiệm; giờ đây chúng có thể mất hàng giờ để loay hoay với các cấu hình, nếu như việc đó khả thi. Việc tin học hóa công việc đã dẫn đến sự mất đi quyền chủ động.

Sự cứng nhắc của phần mềm không chỉ là một bất tiện nhỏ. Nó có thể cản trở nghiêm trọng những người đang thực hiện công việc quan trọng. Bác sĩ kiêm nhà văn Atul Gawande đã viết về việc tin học hóa trong ngành y đang dẫn đến mức độ kiệt sức kỷ lục. Ví dụ, các bác sĩ từng có thể bỏ qua các trường thông tin không liên quan khi điền vào biểu mẫu giấy; giờ đây phần mềm buộc họ phải điền vào các trường đó, và họ không có quyền chỉnh sửa các quy tắc phần mềm đó. Như Gawande nói về một bác sĩ: “Việc dành thêm thời gian không làm cô ấy tức giận. Sự vô nghĩa của nó mới là điều khiến cô ấy tức giận.”

Khi bạn đối mặt với tình huống phần mềm không đáp ứng được nhu cầu của mình, bạn có thể thử gửi phản hồi cho các nhà phát triển—nhưng điều đó thường không dẫn đến hành động ngay lập tức. Khi những người dùng khác nhau có nhu cầu khác nhau, một đội ngũ phát triển tập trung không thể nào giải quyết hết vấn đề của mọi người. Và hơn nữa, khi một nhà phát triển cố gắng nhồi nhét quá nhiều giải pháp vào một sản phẩm duy nhất, kết quả là một mớ hỗn độn cồng kềnh. Để tránh cái bẫy này, các đội ngũ sản phẩm tốt học cách từ chối hầu hết các yêu cầu của người dùng, để lại một danh sách dài các nhu cầu ngách không được đáp ứng.

Có vẻ như việc các yêu cầu cụ thể của chúng ta không được phần mềm đáp ứng là điều không thể tránh khỏi—nhưng đó chỉ là vì chúng ta đã mặc định rằng phần mềm được kiểm soát bởi các đội ngũ phát triển tập trung. Sẽ ra sao nếu chúng ta chuyển giao nhiều quyền kiểm soát hơn vào tay những người dùng hiểu rõ nhu cầu của chính họ?

Gawande kể câu chuyện về một bác sĩ phẫu thuật thần kinh đã làm việc với một chuyên gia phân tích CNTT để tùy biến hệ thống hồ sơ y tế của khoa mình. “Chẳng bao lâu sau, họ đã xây dựng được một giao diện nhanh hơn, trực quan hơn, được thiết kế dành riêng cho các buổi khám tại văn phòng phẫu thuật thần kinh.” Các yêu cầu được thúc đẩy bởi nhu cầu của chính khoa đó, chứ không phải nhu cầu của mọi bác sĩ trên cả nước. Ngoài lợi ích trực tiếp về năng suất, các bác sĩ cảm thấy kiểm soát tốt hơn các công cụ của mình—một liều thuốc giải cho sự kiệt sức.

Dù câu chuyện này đầy cảm hứng, nó vẫn là ngoại lệ hơn là quy luật, bởi vì các công cụ và cơ sở hạ tầng chúng ta sử dụng để triển khai phần mềm coi người dùng là những người tiếp nhận thụ động thay vì những người đồng sáng tạo tích cực. Phần mềm được tổ chức thành các ứng dụng nguyên khối thay vì các bộ công cụ linh hoạt có thể tùy biến. Việc tùy chỉnh đòi hỏi kỹ năng lập trình mà hầu hết mọi người không có—và hơn nữa, hầu hết phần mềm đều là mã nguồn đóng. Phần mềm không được cung cấp kèm theo các công cụ để chỉnh sửa chính nó. Các cửa hàng ứng dụng được thiết kế cho các công ty phân phối phần mềm đến người tiêu dùng, không phải cho những người nghiệp dư chia sẻ công cụ với bạn bè. Đây là một hệ thống sản xuất hàng loạt công nghiệp, không phải là thủ công quy mô nhỏ.

Công bằng mà nói, phần mềm sản xuất hàng loạt đã mang lại nhiều lợi ích. Chúng ta có thể truy cập vào vô số ứng dụng được trau chuốt kỹ lưỡng với mức giá hợp lý. Phần mềm đã đạt được những tiến bộ về độ tin cậy, khả năng tiếp cận và bảo mật. Các nhà phát triển đã tạo ra những mô hình kinh doanh có thể chi trả bền vững cho các đội ngũ để cung cấp phần mềm cải tiến liên tục.

Nhưng như những câu chuyện này và vô số ví dụ khác cho thấy, phần mềm sản xuất hàng loạt thiếu linh hoạt cũng gây cản trở. Bạn càng khác biệt so với người dùng trung bình, thì lợi ích của việc tùy chỉnh càng vượt xa lợi ích của sự trau chuốt chuyên nghiệp. Mỗi người đều độc đáo theo một cách nào đó—có lẽ bạn có những quan điểm mạnh mẽ về các công cụ để viết lách, làm nhạc, thảo luận hoặc lập kế hoạch dự án. Khi bạn có những nhu cầu cụ thể, quyền chủ động là rất quan trọng.

Mục tiêu của chúng tôi: phần mềm linh hoạt (malleable software)

Chúng tôi hình dung về một loại hệ sinh thái máy tính mới trao quyền chủ động cho người dùng với tư cách là những người đồng sáng tạo. Chúng tôi gọi ý tưởng này là phần mềm linh hoạt—một hệ sinh thái phần mềm nơi bất kỳ ai cũng có thể tùy biến công cụ của mình theo nhu cầu với sự ma sát tối thiểu.

• Bằng “hệ sinh thái phần mềm”, chúng tôi muốn nói đến môi trường kỹ thuật và văn hóa rộng lớn bao quanh phần mềm và người dùng của nó. Tính linh hoạt không phải là một vấn đề kỹ thuật hẹp hòi.
• Bằng “bất kỳ ai”, chúng tôi muốn nói rằng khả năng tiếp cận rộng rãi là mục tiêu. Và trong khi sự tự cung tự cấp của cá nhân rất hữu ích để trau dồi, thì việc hợp tác với cộng đồng địa phương cũng rất có giá trị.
• Khi chúng tôi nói “tùy biến công cụ”, chúng tôi bao gồm một loạt các tùy chỉnh, từ việc thực hiện những thay đổi nhỏ cho phần mềm hiện có, đến cải tạo sâu rộng, cho đến việc tạo ra các công cụ mới hoạt động hiệu quả khi phối hợp với những công cụ sẵn có. Tùy biến không có nghĩa là bắt đầu lại từ đầu.
• Cuối cùng, “ma sát tối thiểu” là chìa khóa. Việc chỉnh sửa công cụ của chúng ta phải nhanh chóng. Nó phải mang lại cảm giác nhẹ nhàng. Tốt nhất, đó nên là việc chúng ta có thể làm ngay tại thời điểm nảy sinh nhu cầu, để chúng ta có thể quay lại với công việc đang làm.

Các phương pháp hiện có

Bạn có thể đang tự hỏi: còn về cài đặt (settings) hay plugin thì sao? Quả thực có rất nhiều kỹ thuật tùy chỉnh phần mềm đáng được ghi nhận. Tuy nhiên, chúng cũng có những hạn chế ngăn cản việc đạt được hoàn toàn các mục tiêu mà chúng tôi đã đề ra ở trên.

Cài đặt (Settings)

Cài đặt là một cách phổ biến để thay đổi cách thức hoạt động của một ứng dụng. Nếu có sẵn cài đặt phù hợp, bạn chỉ cần bật/tắt một ô kiểm và tiếp tục công việc của mình.

Nhưng cài đặt chỉ cung cấp các quyền kiểm soát mà nhà phát triển ứng dụng đã nghĩ đến việc công khai, khiến bạn bế tắc nếu không có cài đặt nào thực hiện đúng ý muốn của bạn. Cài đặt cũng có xu hướng trở thành những danh sách dài các ô kiểm rời rạc mà không có một mô hình tư duy mạch lạc nào liên kết chúng lại với nhau.

Plugin

Một cách để mở rộng quy mô vượt ra ngoài khả năng của một nhà phát triển trung tâm là cho phép các plugin của bên thứ ba mở rộng hành vi của ứng dụng. Một hệ thống plugin tốt giúp người dùng dễ dàng bắt đầu tùy chỉnh với nỗ lực tối thiểu, vì họ có thể cài đặt các plugin do người khác tạo ra. API plugin cũng có lợi ích chính là ổn định hợp đồng giữa ứng dụng nền tảng và các phần mở rộng khác nhau, giúp ích cho việc bảo trì liên tục.

Tuy nhiên, các hệ thống plugin vẫn chỉ có thể chỉnh sửa hành vi của ứng dụng theo những cách cụ thể được cho phép. Nếu không có bề mặt (surface) plugin nào khả dụng cho một tùy chỉnh nhất định, người dùng sẽ không thể thực hiện được. (Trên thực tế, hầu hết các ứng dụng không có API plugin nào cả, vì việc thiết kế một API tốt là một công việc khó khăn!)

Ngoài ra còn có những vấn đề khác. Việc chuyển từ cài đặt plugin sang tự tạo một plugin là một khoảng cách khó vượt qua. Và mỗi ứng dụng lại có hệ thống plugin riêng biệt, khiến việc chia sẻ plugin giữa các ứng dụng khác nhau thường là không thể.

Modding

Khi cài đặt và các API mở rộng chính thức không đáp ứng đủ (hoặc ngay từ đầu đã không được cung cấp), người dùng đôi khi có thể giành quyền kiểm soát thông qua modding không cần cấp phép (permissionless modding). Ví dụ, các tiện ích mở rộng trình duyệt có thể can thiệp vào giao diện người dùng của trang web và chèn các hành vi phía máy khách (client-side) mới mà không cần bất kỳ hook nào được nhà phát triển ứng dụng gốc công khai.

Các bản mod không cần cấp phép áp dụng trong phạm vi rộng hơn nhiều so với các API plugin được hỗ trợ chính thức. Trên thực tế, chúng thậm chí có thể được sử dụng ngay cả khi nhà phát triển gốc phản đối một loại tiện ích mở rộng nhất định—các trình chặn quảng cáo (ad blockers) ưu tiên lợi ích của người dùng hơn lợi ích của các trang web.

Bài gốc còn tiếp — xem tiếp tại bài gốc ↗