Câu chuyện "Just Ship It" buồn nhất (2020)
(kitze.io)- Dự án phụ bắt đầu từ năm 2018 đã có MVP chỉ sau vài ngày, nhưng vì cứ liên tục dời thời điểm công bố nên trở thành một dự án không ra mắt suốt 2 năm
- Trung tâm của sự trì hoãn là phán đoán lặp đi lặp lại “chỉ thêm một thứ nữa thôi”, và phạm vi sản phẩm cũng phình to khi học cả React Native lẫn Expo
- Ứng dụng cạnh tranh giải cùng một vấn đề thì chậm và cũng có lỗi, nhưng đã được phát hành, có người dùng và cộng đồng, đồng thời được cải thiện hằng tuần
- Sau bản dùng thử 30 ngày, khi trả tiền cho ứng dụng cạnh tranh, ứng dụng của chính mình chỉ còn nằm trên ổ cứng đã trở thành một sản phẩm thực chất đã chết
- Trong bản cập nhật năm 2024, tác giả cho biết cuối cùng đã phát hành ứng dụng năng suất Benji vào năm 2022, và kết luận, dù sáo mòn, vẫn nghiêng về việc hãy tung ra trước
Vì sao MVP làm trong vài ngày lại không thể ra mắt suốt 2 năm
- Bắt đầu phát triển ứng dụng vào ngày 1 tháng 1 năm 2018, và MVP đã sẵn sàng chỉ sau vài ngày
- Dù phiên bản alpha 0.0.1 cũng đã ở trạng thái có thể công khai, mỗi lần đều hoãn phát hành với lý do “chỉ thêm một tính năng nữa”, “chỉ thêm một màn hình nữa”
- Khi cho rằng “nếu không có một ứng dụng di động native tử tế thì mọi người sẽ không dùng”, tác giả học React Native và quyết định dành thêm vài tháng cho việc đó
- Sau đó trong 2 năm, việc lặp đi lặp lại giữa nền tảng web, React Native, Expo, GraphQL, cân nhắc tech stack, chuyển sang dự án khác, phát hành các ứng dụng khác như Sizzy, mất rồi lại lấy lại đam mê đã tiếp diễn
- Cuối cùng tác giả ngừng phát triển và cũng từ bỏ ý định sẽ phát hành ứng dụng đó
Khoảnh khắc phát hiện ra một ứng dụng giải cùng vấn đề
- Theo thời gian, khi chính mình tiếp tục dùng ứng dụng đó, tác giả nhận ra có nhiều tính năng cần thiết, và rơi vào tình huống phải phát triển lại hoặc tìm giải pháp thay thế
- Khi nhìn thấy landing page của một ứng dụng thay thế, cảm giác ai đó đã giải được đúng vấn đề mình định giải dâng lên rất mạnh
- Trước đó tác giả từng gửi video ứng dụng của mình cho vài người, nên còn nghi ngờ liệu video đó có bị chia sẻ hay không, vì tính năng và cách nhìn nhận vấn đề quá giống nhau
- Tuy vậy, sự tồn tại của ứng dụng cạnh tranh không phải lỗi của họ, mà được chấp nhận là do bản thân quá chậm và đã không phát hành đúng lúc
Ứng dụng cạnh tranh đặt việc phát hành lên trước độ hoàn thiện
- Khi tạo tài khoản và xem video trong trung tâm trợ giúp, mỗi lúc cảm thấy cách triển khai thật thông minh, tác giả lại tự ý thức rằng đó là đối thủ cạnh tranh của mình
- Suốt 2 năm, tác giả nghĩ ứng dụng của mình vụng về, nhiều lỗi và thiếu tính năng nên sẽ chẳng ai dùng, nhưng sau khi dùng thử ứng dụng cạnh tranh thì thấy phán đoán đó là sai
- Ứng dụng cạnh tranh cũng đã được phát triển vài năm nhưng vẫn chậm, có lỗi và chưa được trau chuốt nhiều
- Ứng dụng di động tệ đến mức đồng bộ mất 10 giây, nhưng đó đã là một sản phẩm được phát hành, và người dùng có thể chờ bản cập nhật tiếp theo
- Dù danh sách việc cần làm rất lớn, họ vẫn tiếp tục phát hành hằng tuần, để ứng dụng và cộng đồng cùng phát triển
Bài học còn lại sau khi thanh toán
- Sau khi bản dùng thử 30 ngày kết thúc, tác giả nhập thông tin thẻ tín dụng và trở thành không chỉ là người đăng ký mà còn là một fan
- Thông báo thanh toán trở thành một trải nghiệm liên tục nhắc tác giả rằng mình đã không thể phát hành sản phẩm
- Tác giả chấp nhận rằng ở khoảnh khắc này, ứng dụng của mình đã chính thức chết
- Phần lớn những người đang ở trong hoàn cảnh tương tự có lẽ mới chỉ bắt đầu dự án được vài tuần, nên cần tránh mắc cùng sai lầm
- Nếu “chỉ thêm một thứ nữa thôi” là việc làm lại xác thực, thanh toán, boilerplate, thì đó chính là cái bẫy; và sau đó tác giả đã tạo ra Zero To Shipped để giảm bớt cái bẫy ấy
Cập nhật 2024: Cuối cùng cũng phát hành Benji
- Theo bản cập nhật năm 2024, cuối cùng tác giả đã phát hành Benji vào năm 2022
- Lý do phát hành là vì không có ứng dụng cạnh tranh nào đủ gần với tầm nhìn của tác giả
- Ứng dụng tác giả mong muốn là dạng kết hợp Todos, Habits, Planner, Goals, Pomodoros, Meal tracking, Fasting, Hydration, Packing, Trips, v.v.
- Benji cũng có timeline công khai nơi mọi người cải thiện cuộc sống của mình và chia sẻ thành công cũng như thành tựu
- Dù nghe có vẻ sáo mòn, hãy hít một hơi, rồi vẫn phải Just Ship It
1 bình luận
Ý kiến trên Hacker News
Những câu chuyện kiểu “kết thúc vì lúc đó không cứ thế phát hành” có một gợi ý lớn: đôi khi giá trị của ứng dụng đang được xây dựng nằm ở các chi tiết kỹ thuật không thể vội vàng, và khi đó “cứ phát hành đi” không phải là câu trả lời
Công việc của kỹ sư/kiến trúc sư phần mềm cũng là chống đỡ áp lực “cứ đưa ra đi” từ ban lãnh đạo nhiều nhất có thể. Nếu đó không phải là sản phẩm bạn trực tiếp sở hữu và việc phát hành không mang lại lợi ích cho chính bạn, thì nếu dành thêm thời gian có thể cho ra kết quả chuyên nghiệp hơn, bạn nên dùng thời gian đó. Bạn không phải là một cái máy tự động nhận ticket JIRA rồi phun ra code cẩu thả nhanh nhất có thể; nếu cứ làm việc như vậy, bạn sẽ bị bào mòn tinh thần và cuối cùng burnout
Nếu không có cổ phần công ty, việc tối đa hóa lợi nhuận cho công ty không phải là việc của bạn; việc của bạn là tạo ra phần mềm tốt mà bạn có thể đưa vào CV mà không thấy xấu hổ. Cảm giác nhẹ nhõm vì lại kịp một deadline tùy tiện chỉ là động lực tiêu cực ngắn hạn và không kéo dài, nên bạn phải chịu được áp lực từ trên xuống và làm cho đúng. Dù có bị sa thải thì ngày nay chuyển việc dù sao cũng là con đường đi lên
Tuy nhiên, khả năng sinh lời không đồng nghĩa với “cứ phát hành đi”. Nếu một công ty thường xuyên nhầm lẫn hai điều này, đó là dấu hiệu ban lãnh đạo thiếu độ senior
Công việc của lập trình viên gần với việc tạo ra sản phẩm tốt hơn là “phần mềm tốt”. Sản phẩm tốt thường cần phần mềm tốt, nhưng không phải lúc nào cũng vậy; cũng có nhiều trường hợp phía sau một sản phẩm xuất sắc là phần mềm rất tệ. Sự căng kéo giữa sản phẩm, bán hàng và phát triển phải dẫn đến những thỏa hiệp nhằm tối đa hóa giá trị ngắn hạn, trung hạn và dài hạn; lập trình viên cần hiểu cái gì có thể làm qua loa, công ty có những ưu tiên nào, và khi nào không nên thỏa hiệp mà phải làm phần mềm tốt
Một lập trình viên tuyệt đối không chịu thỏa hiệp về chất lượng phần mềm sẽ mất sức nặng ngay cả trong những lúc thực sự không nên thỏa hiệp
Vì vậy ưu tiên số 1 là tạo ra giá trị cho người dùng và phát triển hiệu quả nhất có thể. Phần mềm không ai dùng thì có ý nghĩa gì
Công việc của lập trình viên không phải là tạo ra phần mềm tốt, mà là chuyển giao giá trị cho người dùng. Trong sự nghiệp, tôi còn thấy nhiều trường hợp lập trình viên say mê over-engineering, làm code phình to bằng những tính năng chẳng ai cần, và viết thêm code để chuẩn bị cho những phát triển tương lai chưa hề tới. Vì vậy thách thức khó là giữ được sự tối giản, và có vẻ bài gốc cũng đang nói về điều đó
Ở công ty nhỏ và vừa, chắc chắn cần thỏa hiệp, và việc đưa ra lựa chọn dẫn đến kết quả kinh doanh tốt nhất cũng là công việc của người chuyên nghiệp
Nhiều lập trình viên được “bảo vệ” bởi nhiều tầng quản lý, PM và designer nên kết nối với phía kinh doanh khá yếu. Đưa sản phẩm ra nhanh thì cũng nhận phản hồi nhanh, và có cơ hội đánh giá liệu phần triển khai có khớp với giả định hay không. Điều đó ít căng thẳng hơn so với việc triển khai một giải pháp “hoàn hảo” dưới áp lực rồi phải viết lại
Ở công việc hiện tại, việc tôi làm với tư cách lập trình viên là giảm độ phức tạp và khiến PM, designer cắt kế hoạch ban đầu xuống mức tối thiểu. Như vậy các deadline tùy tiện cũng bớt căng thẳng hơn và tác động của việc chậm trễ cũng nhỏ hơn
Phần có giá trị chỉ là đừng quá bám chấp vào một chỗ làm cụ thể và đừng quá lo bị sa thải, nhưng tôi cho rằng phần giải thích lý do cũng sai. Thật ngạc nhiên khi có thể thực sự đang phải làm việc cùng những người có thái độ đối địch như thế này
Có vẻ một số người thích sống mãi trong ô sai của lý thuyết trò chơi
Khi đọc đoạn “Tôi nghi ngờ ai đã chia sẻ video ứng dụng của tôi cho những người này. Vì theo đúng nghĩa đen, họ đang giải cùng một vấn đề”, tôi nhớ đến lần trước đây gặp một người có ý tưởng ứng dụng khá ổn
Anh ta muốn tôi code ứng dụng miễn phí và đề nghị chia lợi nhuận. Khi tôi hỏi bản thân anh ta sẽ đóng góp gì, anh ta đáp sẽ “vận hành” công ty, và phần 50% là “vì đã nghĩ ra ý tưởng”. Vì vậy tôi nói sẽ cho anh ta 6 tháng đi trước, và nếu đến lúc đó anh ta không đưa được ra thị trường thì tôi sẽ tự làm
Hai trong ba người chỉ ngồi xuống và bắt đầu tạo hình hài cho nó, nhưng người thứ ba thì đẩy code hỏng lên SVN, tạo một tài liệu thiết kế ghi toàn bộ ý tưởng là công của mình, rồi triệu tập họp và tuyên bố mình là game designer, rằng nếu chúng tôi làm game ở nơi khác thì anh ta sẽ kiện. Hai người thực sự đóng góp nhìn nhau rồi dẹp dự án. Anh ta đã lật hết bài, và chúng tôi biết anh ta chẳng đáng để bận tâm
Sau này tôi thấy trên Steam một game có ý tưởng tương tự. Nếu họ tự nghĩ ra độc lập thì tốt; nếu họ đánh cắp từ kẻ thua cuộc kia thì cũng tốt; còn nếu họ đã chịu đựng làm dưới trướng người đó đến cùng thì họ xứng đáng được nhận tiền
Nếu ý tưởng đó thật sự hay và đáng tin, thành thật mà nói đó có thể là một đề nghị khá ổn
Nếu bạn nghĩ rằng có thể nói với ai đó “6 tháng nữa tôi sẽ đánh cắp ý tưởng tuyệt vời của anh”, thì bạn nên hy vọng người đó không phải kiểu sẽ gây rắc rối, hoặc cực đoan hơn là gây hại
Giá mà có ai đó giải quyết vấn đề của tôi thay tôi. Lý do tôi đang bám lấy vấn đề đó lúc này đơn giản là vì không có giải pháp nào có thể mua về dùng ngay
Nếu ai đó đổ mồ hôi công sức để giải quyết vấn đề của tôi, rồi gánh luôn cả trực on-call và bảo trì, thì đó là chuyện đáng mừng
Vì sao nhất thiết bạn phải tự mình giải quyết vấn đề này? Vì sao nhất thiết giải pháp của bạn phải trở thành một doanh nghiệp? Kinh doanh là tạo ra giá trị cho bản thân và khách hàng. Nếu bạn ám ảnh với chính vấn đề, hãy biết ơn khi người khác bỏ nhiều công sức để giải nó; còn nếu bạn ám ảnh với khách hàng, lẽ ra bạn đã phải đưa thứ gì đó cho khách hàng từ lâu để lấy phản hồi
Có lẽ không nhiều người muốn vận hành công ty lâu dài, nhưng hầu hết cũng sẽ không ghét việc bỗng dưng nhận được một khoản tiền lớn vì đã giải quyết hoặc chạm tới một vấn đề thú vị
Tôi liên tục nảy ra ý tưởng muốn đưa vào ứng dụng của mình, nhưng các nhà phát triển khác có lẽ sẽ không quan tâm đến việc triển khai những ý tưởng đó. Tôi muốn có quyền kiểm soát, và cuối cùng đã phát hành Benji: https://benji.so
Tôi là tác giả bài gốc. Tôi cần cập nhật bài viết này. Vài năm sau, tôi thực sự được các bình luận trên HN mỗi lần bài này được đăng lại tiếp thêm động lực
Mọi người luôn hỏi “sao không cứ phát hành ứng dụng đi”, nên cuối cùng tôi đã phát hành
Tôi vui vì đã làm đến cùng, và nghĩ nó tốt hơn rất nhiều so với bất kỳ sản phẩm cạnh tranh nào trong hạng mục này
Có thể xem tại https://benji.so. Trang landing vẫn đang được hoàn thiện
Ứng dụng của tôi cũng có mục tiêu tương tự: nối giữa động lực thói quen, đo mức độ tuân thủ mục tiêu, lên lịch và sắp xếp lại công việc. Tôi đã làm nó trong nhiều năm, và ý nghĩ một ngày nào đó biến nó thành một công ty bootstrap gắn khá chặt với bản sắc của tôi
Quyết định buông dự án đến theo nhiều giai đoạn, nhưng một trong những cái kết lớn là nhận ra rằng về dài hạn tôi không muốn sống như một lập trình viên ứng dụng. Buông bỏ thì khó, nhưng hiện giờ tôi hài lòng với quyết định đó. Như bài gốc, nó cũng có thể hồi sinh về sau, theo kiểu “không có gì biến mất hoàn toàn”, nhưng tôi không nghĩ mình sẽ quay lại dự án cụ thể này
Một trong những ý tưởng cốt lõi để vượt qua “gánh nặng nhận thức cao” của hầu hết các ứng dụng năng suất là chợ mô-đun đời sống. Ví dụ, một influencer về fitness bán một gói gồm lịch tập, chế độ ăn và mẫu nhật ký, rồi người dùng “cài đặt” nó vào cuộc sống của mình
Các mô hình ngôn ngữ lớn sẽ khiến việc phát hiện churn và suy đoán nguyên nhân, hoặc phản ứng với “những hành động không được thực hiện”, trở nên khả thi hơn nhiều. Tôi nghĩ điều đó quan trọng với những người không thuộc kiểu tính cách loại A dùng ứng dụng năng suất đều đặn mỗi ngày
Độ lệch so với GMT thì đúng, nhưng Brussels, Copenhagen, Madrid, Paris không thuộc châu Phi nên rất gây rối. Bạn nên kiểm tra lại thông tin múi giờ đang dùng
Xem bình luận bên dưới thì hóa ra đây không phải vấn đề
Và xin lỗi vì trước đây đã bày tỏ sự bực bội và nghi ngờ về việc bạn không nói tên “đối thủ cạnh tranh”. Giờ bạn đã phát hành ứng dụng của mình, có lẽ khả năng bạn nói tên sản phẩm cạnh tranh đó, nếu nó vẫn còn tồn tại, lại càng nhỏ hơn
Khi trở thành người dùng thực sự của hệ thống do chính mình làm ra, góc nhìn thay đổi hoàn toàn. Tôi cũng từng có một thứ làm cho bản thân, và nghĩ nó chưa sẵn sàng, hoàn toàn không thể dùng được
Sau khi bỏ dự án, tôi quyết định dùng thử như một người dùng thật, và nhận ra rằng người dùng quen với vô số vấn đề nhỏ nhặt và tự động tìm cách đi đường vòng. Người tạo ra thứ gì đó thường quên rằng nhiều điểm cẩu thả không phải là lý do loại bỏ, và người dùng có thể tránh nhiều thiếu sót mà không tốn nhiều công sức. Đến điểm đó, việc theo đuổi sự hoàn hảo gần như trở thành lòng tự ái
Tạm thời phớt lờ chuyện mình là người tạo ra nó, cấm cả việc sửa trong một thời gian, rồi thực sự dùng thử có thể thay đổi mọi thứ
Thực tế là trước khi công khai cho người dùng thật, bạn sẽ không tìm ra phần lớn “bug” mà người dùng gặp phải. Nếu không phát hành, bạn cũng không có cơ hội sửa những bug thực sự ảnh hưởng đến người dùng
Tôi chỉ mở trực tiếp trang web để dùng, còn tên người dùng và mật khẩu thì đương nhiên đã được đồng bộ qua iCloud. Mất 5 giây để tiếp tục lại luồng người dùng trong Safari, và chỉ 30 giây để hoàn tất
Đây không phải ví dụ hay nhất cho “cứ ra mắt đi”. Các hạng mục như ứng dụng năng suất, việc cần làm, theo dõi thói quen, theo dõi chi tiêu, viết nhật ký, kế hoạch tập luyện là những thứ rất nhiều người độc lập nghĩ ra cùng một ý tưởng
Không biết tôi đã cảm thấy mình thông minh đến mức nào khi nghĩ ra ý tưởng về một ứng dụng giúp ghi lại chi tiêu. Rồi tôi kiểm tra Play Store. KRAZAM cũng đã đem chuyện này ra châm biếm trong video “The Hustle” từ 5 năm trước
Điều đó không có nghĩa là một biến thể mới không thể thành công. Vì phần lớn những thứ thành công cũng không hoàn toàn độc đáo. Chỉ là nếu bạn lo ai đó sẽ tung ra phiên bản của họ trước và thắng, hãy nhìn quanh một chút là được
Cá nhân tôi không chịu nổi kiểu viết “cố gắng hết sức để tỏ ra hài hước”
Tôi đọc rồi bỏ cuộc. Quá trẻ con và sến súa
Rốt cuộc họ chỉ tạo ra một proof of concept rồi hài lòng với nó. Đáng tiếc, nhưng đời là vậy. Họ đã làm việc và nhận được phần thưởng
Bài học rút ra là ý tưởng không thể được sở hữu
Tôi hoàn toàn đồng ý với điều này. Khi bắt đầu Kviklet, chúng tôi có 3 người, và một người trong số đó cầu toàn hơn hẳn hai người còn lại. Thành thật mà nói, chỉ riêng việc thuyết phục để đưa phiên bản website đầu tiên vốn rất tệ lên mạng đã cần rất nhiều công sức, còn công khai repository thì còn khó hơn
“Đồng sáng lập” đó đã rời đi từ sớm, nhưng thật sự may là chúng tôi đã cố ra mắt sớm và thử bán
Mọi chuyện không suôn sẻ và chúng tôi cũng không tìm được người mua, nhưng thật kinh khủng khi tưởng tượng rằng đến giờ chúng tôi vẫn đang xây sản phẩm trong bóng tối, chỉ bám víu vào hy vọng mà không hề biết liệu có ai chịu trả tiền hay không
Hiện tại chúng tôi đã chuyển nó thành mã nguồn mở như một phương án dự phòng, và cũng đã có vài người dùng khá thú vị. Có lẽ cũng có thể gọi là một cộng đồng nhỏ: https://github.com/kviklet/kviklet
Đây không phải câu chuyện startup thành công mà chúng tôi mong muốn một năm trước, nhưng vẫn tốt hơn rất nhiều so với việc vẫn chỉ kỳ vọng mà thiếu cảm giác thực tế. Mã nguồn mở đâu có nghĩa là không thể kiếm chút tiền bằng cách bán hỗ trợ hay phiên bản premium, đúng không. Giờ thì nó chỉ là một side project thú vị
Nên dùng những từ như mutation, edit, update, modification. Dù query có thể đúng về mặt kỹ thuật, nhưng về sắc thái thì sai và nghe dễ gây nhầm lẫn
Nếu tôi đang làm thứ gì đó cho chính mình, tôi sẽ không buồn nếu có ai đó làm trước. Điều đó chỉ chứng minh rằng ý tưởng này tốt
Tất nhiên, rất nhiều dự án cá nhân trong đầu và trên giấy của tôi, thậm chí cả những thứ đã thực sự bắt đầu làm một chút, không phải để phát hành bán. Chúng là những thứ tôi muốn có, hoặc bạn bè, gia đình, người khác có thể thấy hữu ích
Nếu đạt mức chất lượng alpha thôi, có khi tôi cũng muốn công khai để ai đó nghĩ “ý tưởng này hữu ích nhưng triển khai chưa tốt, để mình làm tốt hơn”
Hơn nữa, ngay cả khi là người đi đầu, chẳng bao lâu cũng sẽ có đối thủ xuất hiện và bào mòn lợi thế, và bạn cần nỗ lực để tiếp tục dẫn trước
Vì vậy, nếu dù sao cũng luôn có ai đó đi trước, và cạnh tranh chắc chắn sẽ xảy ra dù là bây giờ hay sau này, thì đừng lo chuyện bị chiếm trước; hãy tập trung vào lợi thế cạnh tranh. Có vẻ tác giả bài gốc cuối cùng cũng đã đi đến nhận thức đó, và tôi chúc họ thuận lợi