Vì sao họ không xài Software Framework của tôi?

Hiệu ứng ban đầu rất tuyệt: Bạn nhận được hàng trăm sao bầu chọn trên GitHub và 50 lượt ủng hộ trên Reddit. Nhưng sau đó tăng trưởng bắt đầu bão hoà và rồi giảm xuống. Tại sao họ không xài software framework của bạn?

– Ba tháng trước –

“… và AI ngày nay hoàn toàn là về engineering. Bây giờ, chúng ta hãy kết thúc bài học tại đây. Nếu bạn thích kênh của chúng tôi, đừng quên…”

Bạn thở hổn hển, nhấn nút ‘tạm dừng’ trên Airpods của mình và dừng lại. Một khái niệm tuyệt vời vừa nảy nở trong tâm trí bạn:

“Mình cần xây dựng một AI framework!”, bạn thốt lên với chính mình, tràn đầy hứng thú và năng lượng đột ngột bùng nổ. Bạn tự hỏi sao mình chưa từng nghĩ về nó trước đây!

Tâm trí của bạn đang chạy đua, đặt ra các bước và chuyển các bộ phận cần thiết để đưa sản phẩm này thành hiện thực. Với đôi tay run rẩy, bạn vội vàng cởi giày chạy bộ, phớt lờ những giọt mồ hôi nhỏ đọng lại sau tai.

Thế giới xung quanh bạn đột ngột dừng lại: những chú chim ngừng hót líu lo; các xe ngừng bóp còi; những người chạy bộ khác biến mất. Nó giống như bạn đã được đưa ra khỏi sự hối hả và nhộn nhịp của thành phố, và bước vào một thế giới của khả năng và thành công.

Các ngón tay của bạn di chuyển dữ dội, vuốt và gõ vào điện thoại khi bạn gõ các ghi chú, ý tưởng và suy nghĩ ngẫu nhiên. Bạn mơ về các nhà đầu tư tiềm năng, các ứng dụng mới và tường thuật về lần ra mắt đầu tiên của bạn trên Hacker News và Product Hunt. Tim bạn đập thình thịch khi bạn viết, gần giống như bạn có thể thể hiện thành công với mỗi lần nhấn phím. Tâm trí bạn quay cuồng vì phấn khích, và không có gì, KHÔNG CÓ GÌ, có thể ngăn cản bạn lúc này. Airpods của bạn rơi xuống đất khi bạn cất cánh, hướng tới tương lai tươi sáng và thành công mới đạt được của bạn.

– Đây không phải là ngày của bạn –

Hiệu ứng ban đầu là tuyệt vời. Trong vài ngày đầu tiên kể từ khi ra mắt, hàng nghìn người dùng đã dùng thử framework của bạn và chia sẻ trải nghiệm của họ. Bạn đã nhận được hàng trăm sao GitHub và 50 lượt upvote trên r/machinelearning. Không tệ. Không tệ chút nào.

Nhưng rồi… cái gì đó xảy ra. Điều gì đó không mong đợi – tốc độ tăng trưởng người dùng bắt đầu chững lại và sau đó giảm xuống. Nhiều tuần qua đi nhưng bạn không thấy bất kỳ sự tăng trưởng nào nữa. Bạn bắt đầu lo lắng rằng phần mềm mà bạn đã dồn hết tâm huyết vào không bền vững.

Điều này không thể như vậy được. Phải có vấn đề với Google Analytics hoặc phương thức đo lường mà bạn thiết lập. Có thể giờ đang là thời điểm vui vẻ trong năm – nhiều người đang trong kỳ nghỉ và không sử dụng phần mềm của bạn khi làm việc. Bạn đã làm mọi thứ theo cuốn sách. Không có cách nào mà điều này có thể đi ra khỏi cuộc chơi sớm như vậy.

Nhưng trong sâu thẳm, trái tim bạn thắt lại. Bạn biết đây chỉ là những cái cớ mỏng manh.

Bây giờ bạn đi lang thang trên phố, đầu cúi xuống và hai tay đút túi, tâm trạng của bạn xám xịt như bầu trời nhiều mây. Bạn nghĩ lại ngày ra mắt phần mềm của mình và cảm giác phấn khích, mong đợi vào ngày hôm đó, giống như bạn sẽ ra đời một cậu bé bụ bẫm. Bạn đã tạo ra thứ gì đó mà bạn đam mê, thứ gì đó mà bạn tin tưởng, nhưng bất chấp tiếng vang và sự hiệu ứng ban đầu, nó đã thất bại. Nhưng bạn vẫn tiếp tục, quyết tâm tìm hiểu tận cùng những gì đã sai.

“Tại sao họ không sử dụng nó?” Bạn nhìn lên bầu trời và cầu xin, cố gắng hiểu chuyện gì đã xảy ra. Chúa biết bạn đã nỗ lực – có thể (chắc chắn là vậy) rất nhiều. Bạn chỉ ước mình có thể làm điều gì đó, bất cứ điều gì khác đi, để làm cho phần mềm của bạn thành công.

Cuối cùng, bạn thấy mình đang ngồi trên một chiếc ghế dài trong công viên. Mặt trời bắt đầu ló dạng sau những đám mây, gần như thể nó biết được tâm trạng của bạn và đang cố gắng thắp sáng một ngày của bạn. Bạn thở dài thườn thượt mà bạn không biết là mình đã nín thở, và nhắm mắt lại, cảm nhận ánh nắng ấm áp trên khuôn mặt và làn gió mát trên da.

Bạn ngồi trong im lặng, cân nhắc hành động tiếp theo của mình.

Biến mất.

– Kết thúc? –

3 Sai lầm phổ biến

Những câu chuyện thành công thường giống nhau; còn thất bại, ngược lại, thường là duy nhất.

Khi nói đến phần mềm như AI framework ít được phổ biến, có 3 lỗi thường thấy trong giai đoạn đầu: tập trung kém, onboarding kém và thiếu tính năng. Trong bài viết này, tôi sẽ giải thích chúng từng bước bằng hình ảnh minh họa và quan trọng nhất là chỉ cho bạn cách khắc phục chúng.

Không gian giải pháp AI

Mọi vấn đề thực đều cần một giải pháp.

Có rất nhiều vấn đề về AI, dù lớn hay nhỏ, dễ hay phức tạp; miễn là chúng có thật, tất cả chúng đều cần giải pháp.

Hãy dùng dấu chấm để đại diện cho một giải pháp. Bạn có thể hình dung không gian giải pháp AI như bên dưới:

Trên thực tế, các giải pháp không được phân bổ đồng đều. Chúng được nhóm lại. Điều này là do các vấn đề khác nhau có thể dẫn đến các giải pháp tương tự.

Ví dụ: cả phân tích tình cảm và phân loại văn bản đều có thể được giải quyết bằng một mô hình ngôn ngữ với các nhãn đào tạo khác nhau. Phân đoạn hình ảnh và phát hiện đối tượng có thể được giải quyết bằng cách đào tạo ResNet. Do đó, không gian giải pháp AI thực sự trông như thế này:

Bản chất nhóm của không gian giải pháp AI chứng minh sự tồn tại của các framework phần mềm, phần trừu tượng cung cấp chức năng chung được chia sẻ bởi một nhóm giải pháp và có thể được thay đổi có chọn lọc bằng mã bổ sung do người dùng viết, cung cấp cách thức tiêu chuẩn để xây dựng và triển khai các giải pháp.

Nếu các giải pháp được phân bổ đồng đều trong không gian giải pháp AI, thì không có mô hình chung nào có thể được trừu tượng hóa, không cần đến các framework.

Hãy tóm tắt mối quan hệ giữa vấn đề, giải pháp và khuôn khổ trong hình minh họa dưới đây:

Việc có những khái niệm minh họa rõ ràng đó giúp chúng ta nhận ra sai lầm đầu tiên khi xây framework phần mềm.

Sai lầm 1: Không tập trung vào một ngách nhỏ

Trong hình bên dưới, các bong bóng A, B, C và D đại diện cho bốn framework.

Về mật độ, dễ dàng nhận thấy rằng A > B > C > D, vì A cho phép nhiều giải pháp nhất và đáp ứng nhu cầu của hầu hết các vấn đề trong thế giới thực. D là tồi tệ nhất vì nó có những yêu cầu hư cấu không phù hợp với vấn đề thực tế.

Do đó, A sẽ có tỷ lệ chấp nhận cao nhất trong thời gian dài, trong khi D sẽ có tỷ lệ chấp nhận thấp/không có bất kể bạn gửi bao nhiêu bài đăng cho Hacker News và bạn nhận được bao nhiêu sao trên GitHub.

“Ai lại khờ đến mức chọn C hay D?” bạn có thể hỏi.

Sự thật đáng lo ngại là nếu bạn nảy ra một ý tưởng lung linh trong lúc chạy bộ, hoặc nếu bạn đang xây dựng một framework mới khi đọc bài viết này, thì rất có thể bạn đang ở C hoặc D. Đây là lý do:

• Bạn không thể nhìn thấy bức tranh toàn cảnh về không gian giải pháp AI. Không gian quan sát của bạn bị giới hạn bởi kiến ​​thức và chuyên môn của bạn về AI và ngành.
• Các thị trường đằng sau A và B là những đại dương đầy cá lớn (và đói khát). Bạn không có tài nguyên để bơi nhanh như vậy hoặc cắn mạnh như vậy.
• Kinh nghiệm và kiến ​​thức của bạn khiến bạn đánh giá quá cao số lượng giải pháp và yêu cầu trong C và D.
• Là một kỹ sư, bạn dễ dàng bị ám ảnh bởi chính ý tưởng về framework, quên rằng nó không có bất kỳ ứng dụng thực tế nào trong thế giới thực.

Trong bất kỳ trường hợp nào, đừng ở D. Đừng buồn nếu bạn ở C. Không gian giải pháp rất lớn và năng động; nó liên tục thay đổi theo thời gian. Các vấn đề và yêu cầu mới xuất hiện; yêu cầu cũ sẽ không cần thiết.

Một ví dụ điển hình là thị trường AI sáng tạo vào năm 2021 so với năm 2022.

Chúng tôi hiếm khi thấy bất kỳ tìm kiếm nào về AI sáng tạo/sáng tạo trở lại vào năm 2021 và hiện tại nó đang bùng nổ.

Giả sử bạn có một focus tốt và framework của bạn về mặt khái niệm đáp ứng một số nhu cầu thực tế. Xin chúc mừng! Hãy tiếp tục với 2 cái bẫy phổ biến khác mà bạn có thể rơi vào.

Sai lầm 2: Trải nghiệm onboarding và tài nguyên giáo dục nghèo nàn

Hãy phóng to một “bong bóng” framework:

Điều đầu tiên cần nhấn mạnh là khoảng cách kiến ​​thức giữa bạn và người dùng của bạn. Framework của bạn có thể bao gồm tất cả các chức năng mà người dùng cần. Tuy nhiên, do thiếu tài liệu và trải nghiệm onboarding kém, người dùng không biết framework của bạn có thể giải quyết vấn đề của họ. Hậu quả? Khả năng đón nhận thấp.

Không giống như bạn (với tư cách là người biết tất cả về framework của mình), người dùng quan sát framework từ một góc độ hoàn toàn khác: họ chỉ có thể tìm hiểu nó từ các tài liệu, hướng dẫn, tài liệu tham khảo, video và code mà bạn cho họ xem. Trên thực tế, những người dùng thiếu kiên nhẫn chỉ học được từ các tài nguyên được viết tốt. Nếu họ cảm thấy việc onboarding khó khăn, họ sẽ ngay lập tức từ bỏ và tìm kiếm các giải pháp thay thế. Họ không quyết tâm và đam mê như bạn đâu.

Một sai lầm phổ biến mà các nhà phát triển mắc phải là bỏ qua tầm quan trọng của tài nguyên giáo dục và DocOps khi xây dựng framework. Họ ngây thơ tin rằng miễn là họ commit một function cho nhánh chính, thì người dùng sẽ sử dụng nó; miễn là bạn viết một vài từ khóa mơ hồ về một tính năng trong tin commit, người dùng sẽ hiểu tính năng đó; miễn là bạn thực hiện các thay đổi đột phá, người dùng sẽ điều chỉnh mã của họ cho phù hợp.

Họ không vậy đâu.

• Họ sẽ không mất thời gian đào sâu vào các bài kiểm thử đơn vị để hiểu cách thức hoạt động của một chức năng.
• Họ sẽ không đọc câu đố về tin commit của bạn và tiêu đề của pull request để đoán tính năng mới.
• Người dùng sẽ không kiểm tra các bộ lọc thư rác để đọc bản tin mà bạn thông báo về các thay đổi.
• Người dùng sẽ không đọc các tài liệu được viết kém với các đoạn mã không thể thực thi được và báo cáo lỗi cho bạn.

Người dùng sẽ không lãng phí thời gian của họ vào phần mềm của bạn nếu bạn không “lãng phí” thời gian của mình vào việc giáo dục họ.

Vì vậy, bạn đã tìm mọi cách để thu nhỏ lỗ hổng kiến ​​thức: tài liệu hay, hướng dẫn chi tiết, video hướng dẫn, gặp gỡ offline/online, thuyết trình hội nghị, tweet hàng ngày và bản tin hàng tuần.

Đó là điều xử lý. Và bạn đã sửa focus của mình (từ sai lầm thứ nhất). Nhưng bạn vẫn thấy việc khả năng đón nhận thấp. Bây giờ là mấy giờ?

Sai lầm 3: Các tính năng lỗi thời và thiếu sót

AI đang phát triển nhanh chóng và thị trường có tính cạnh tranh cao. Mặt khác, bạn đã lỗi thời. Bị đào thải. Một di vật.

Mỗi ngày, hàng trăm bài báo mới được xuất bản trên ArXiv; bảng xếp hạng điểm chuẩn được làm mới; xu hướng kho lưu trữ mới trên GitHub. Nếu bạn không thể cập nhật kiến thức của mình, framework của bạn sẽ nhanh chóng trở nên lỗi thời. Nó sẽ không thu hút sự chú ý của người dùng nữa.

So với sai lầm thứ hai, nơi người dùng không biết họ có thể làm điều đó với framework của bạn, thì trong trường hợp này, người dùng biết họ không thể làm gì với framework của bạn. Game over.

Mệt mỏi vì phải cạnh tranh? Vâng, nhưng bạn đã chọn nó, phải không? Đó là thị trường nóng hổi tràn ngập cơ hội và tiền. Bạn sẽ đối phó với sức nóng đó hay bị cóng và bỏ chạy? Còn giấc mơ insert_country_name của bạn thì sao?

Cách khắc phục những sai lầm đó

Lịch sử đầy sai lầm; đó là cách chúng ta học.

Đừng sợ những sai lầm đó. Đối đầu với chúng chỉ là một phần trong cuộc sống của bạn.

Bạn không nên e sợ những sai lầm đó, nhưng nếu quản lý nói thế này với bạn, có lẽ bạn nên xem xét lại sự nghiệp của mình.

Bước đầu tiên là nhận ra bạn đã phạm sai lầm nào. Nghe có vẻ dễ dàng, nhưng dưới áp lực rất lớn của khả năng đón nhận thấp, rất có thể bạn sẽ đi đến kết luận rằng mình đã phạm phải tất cả sai lầm.

Việc thú nhận rằng bạn đã mắc phải tất cả những sai lầm cũng dễ như việc bảo rằng “nó không hiệu quả”. Không phá vỡ nó, lời thú nhận này dẫn đến không có điểm hành động. Tùy thuộc vào bạn để ưu tiên và giải quyết từng vấn đề một, với nguồn lực hạn chế của bạn.

Nhắm mục tiêu vì nhu cầu lớn hơn

Nếu bạn tập trung không tốt, bạn cần phải nhắm lại mục tiêu. Tìm hiểu về những gì mọi người cần và từ bỏ nỗi ám ảnh về việc tạo ra một framework. Xây dựng thêm các giải pháp đặc biệt và nhận ra các kết nối của chúng trước khi động đến framework. Làm thêm nghiên cứu người dùng và phân tích thị trường, tìm ra miếng bánh đủ lớn và thú vị.

Cũng có thể sự tập trung có chủ ý của bạn là đủ tốt, nhưng cách kể chuyện và thương hiệu của bạn quá tệ, điều này khiến người dùng nghĩ rằng framework không phù hợp với nhu cầu của họ. Trong trường hợp này, hãy xem xét lại câu chuyện, quảng cáo các tính năng thực sự quan trọng và che giấu những điểm phức tạp mà không ai (ngoài bạn) quan tâm.

Sửa đổi tài liệu để cải thiện trải nghiệm onboarding

Nếu trải nghiệm onboarding của bạn kém, bạn phải sửa đổi tài liệu và tổ chức các tài nguyên giáo dục. Một framework phần mềm cần tài nguyên giáo dục ở nhiều cấp độ – tham chiếu API, hướng dẫn, đoạn mã, các ứng dụng cấp cao và các đối sánh ngành. Nếu chỉ có một tham chiếu API được tạo tự động từ các chuỗi tài liệu là không đủ.

Hãy nghĩ lại cách bạn học ngôn ngữ thứ hai: Bạn sử dụng từ điển để tra cứu từ vựng (tức là tham chiếu API). Cuốn sách dành cho năm đầu tiên của bạn chứa đầy những cuộc trò chuyện cơ bản hàng ngày (tức là các đoạn mã) để dạy bạn cách chào hỏi và mua đồ. Cuốn sách năm thứ hai của bạn có những câu chuyện dài hơn (tức là các ứng dụng cấp cao) để giúp bạn nắm vững ngữ pháp và viết mô tả. Để nâng cao kỹ năng của mình, bạn xem phim hoặc đọc sách của các nhà văn nổi tiếng (tức là tiêu chuẩn ngành).

Người dùng của bạn cũng vậy. Vào ngày đầu tiên, họ chỉ là người mới. Nhưng theo thời gian, họ tiến bộ bằng cách sử dụng kiến ​​thức bạn cung cấp. Nhiệm vụ của bạn là giúp người dùng phát triển nhanh nhất có thể bằng cách cung cấp tất cả các cấp tài nguyên mà họ cần. Khi họ đạt đến trình độ bậc thầy, bạn có thể thư giãn một chút, vì lúc này họ có thể bênh vực người khác; họ có thể sản xuất nội dung giáo dục chất lượng cao mà không cần bạn.

Đừng chỉ dính vào văn bản; đi đa phương thức! Hãy thử podcast, video, buổi gặp mặt và thuyết trình tại hội nghị nếu bạn có tài nguyên.

Tiến nhanh với học tập suốt đời

Nếu các tính năng của bạn đã lỗi thời, bạn cần tìm hiểu thêm về tính năng hiện đại nhất và cập nhật framework của mình. Tìm hiểu API, mẫu thiết kế và thuật toán từ các framework mã nguồn mở phổ biến. Theo dõi các pull request mới của họ và các tính năng mới trong ghi chú phát hành và suy nghĩ xem có hợp lý không khi thêm chúng vào framework. Luôn cập nhật kiến thức và cơ sở mã của bạn. Thỉnh thoảng, hãy thực hiện một số hồi tưởng về lộ trình tính năng: bạn có đang đi đúng hướng không? Bạn có thêm tính năng này vì mọi người thực sự cần nó không?

Trong thế giới mã nguồn mở, không có lợi thế tuyệt đối. Bạn luôn có thể học hỏi từ các phần mềm khác và tất cả nằm ở tốc độ. Nếu bạn tụt lại phía sau nhưng di chuyển nhanh hơn cả, cuối cùng bạn có thể đuổi kịp. Nếu bạn đang dẫn đầu nhưng lại ngừng cập nhật, một kẻ săn mồi sẽ biến bạn thành bữa trưa. Tốc độ là huyết mạch của phần mềm mã nguồn mở.

Nguồn: jina.ai