- Trong môi trường kinh doanh giai đoạn đầu thay đổi liên tục, cách khôn ngoan là giải quyết vấn đề thật nhanh bằng giải pháp dễ nhất, rồi khi thấy giới hạn thì đánh giá lại yêu cầu để thay thế hoặc bổ sung
- Google Sheets là một công cụ giải quyết vấn đề hiệu quả trong môi trường biến động nhanh, có lợi hơn cho tính hữu dụng thực tế và giảm lãng phí so với việc phát triển công cụ phức tạp
- Tác giả nhìn lại rằng trong thực tế công việc, mình đã vội vàng xây dựng các hệ thống chuyên dụng thay vì dùng công cụ phổ thông, và bỏ qua sự bất định của phạm vi nên đã lãng phí thời gian
- Phương pháp cốt lõi là chiến lược bắt đầu nhỏ và lặp lại: khởi đầu với giải pháp nhỏ nhất, dễ nhất → nắm phạm vi qua công việc thực tế → cải tiến dần nếu cần
- Tuy vậy, không phải mọi vấn đề đều có thể giải quyết bằng bảng tính; việc dùng nó tạm thời cho đến khi phạm vi bài toán lộ rõ là phù hợp, và điều quan trọng là chọn lọc một cách khôn ngoan theo bối cảnh tổ chức
Lựa chọn dễ nhất để giải quyết vấn đề
- Với bất kỳ vấn đề nào, điều quan trọng là trước tiên chọn giải pháp dễ áp dụng nhất
- Khi cách đó không còn phù hợp với hoạt động kinh doanh, cần cải thiện giải pháp hiện có hoặc tìm phương án thay thế theo các yêu cầu mới
- Trong môi trường mà tác giả từng trải qua, trong đa số trường hợp, tạo một Google Sheet mới là phương án tối ưu
Môi trường startup thay đổi nhanh và tính hữu dụng của công cụ
- Sau khi vào công ty khoảng 9 tháng trước, sự kỳ vọng về việc tạo ra các công cụ và dịch vụ mới cho một công ty nhỏ ở giai đoạn đầu đã dần biến mất
- Trong môi trường mà định hướng kinh doanh thay đổi mỗi 2 tháng, nhiều dự án được bắt đầu rồi lại bị dừng
- Trong khá nhiều trường hợp, lẽ ra có thể giải quyết dễ dàng bằng Google Sheet, nhưng lại đầu tư thời gian và công sức vào những dự án phức tạp không cần thiết
Những trường hợp lãng phí thời gian
-
Bảng điều khiển admin quản lý hàng hóa
- Mất 2 tháng để thiết kế và xây dựng bảng điều khiển admin dùng để quản lý và theo dõi hàng nhập cho doanh nghiệp
- Mục đích là giúp phân loại dữ liệu kiện hàng và khách hàng để quản lý tốt hơn
- Bảng điều khiển này được dùng hai lần rồi không bao giờ dùng lại
- Hoàn toàn có thể thay thế dễ dàng bằng Google Sheet, và hiện công việc này đang được thực hiện bằng nó
-
MVP tự động tính thuế quan
- Mất 3 tuần để tạo MVP cho hệ thống báo giá tự động tính thuế quan và thuế khi đặt một số mặt hàng nhất định
- Thuế và thuế quan ở Zimbabwe rất phức tạp, nên nếu khách hàng biết chính xác số tiền phải trả thì có thể mang lại hành trình khách hàng tốt hơn, đồng thời tăng tốc quy trình vì không cần chờ công ty xử lý thuế quan bên thứ ba trả lời mọi câu hỏi của khách hàng
- Kết quả là chỉ cần xem bảng phân loại thuế và thuế quan của đối thủ rồi sao chép vào Google Sheet để dùng
-
Quá trình chọn CRM
- Mất 2 tháng cho việc nghiên cứu, họp hành (hơn 1 giờ) và tìm kiếm để chọn một CRM tốt cho doanh nghiệp
- Đã ngồi phân tích, so sánh và đối chiếu tính năng cùng giá cả của nhiều CRM khác nhau
- Cuối cùng quyết định dùng phiên bản miễn phí của Oddo nhưng nó không được sử dụng nhiều trong doanh nghiệp
- Điều đáng ngạc nhiên là vài tuần trước mới phát hiện Google Sheets có sẵn mẫu CRM tích hợp
Nguyên tắc của cách tiếp cận Google Sheets
- Việc tạo Google Sheet không phải là giải pháp tốt nhất cho mọi vấn đề, nhưng trong hoàn cảnh của tác giả thì nó thường là như vậy
- Tác giả thường rơi vào tình huống không bao giờ có thể biết toàn bộ phạm vi của vấn đề cho đến khi bắt đầu công việc thực tế
- Điều đó không có nghĩa là không nên lập kế hoạch cho dự án
- Cả nhóm vẫn cần thảo luận về quy trình làm việc và thông tin cần thiết, nhưng trước khi bắt đầu công việc thực tế thì không thể biết toàn bộ phạm vi của vấn đề
- Khi đã nắm được toàn bộ phạm vi của vấn đề, lúc đó có thể bắt đầu xây dựng hoặc cải tiến giải pháp đang có
- Cách làm này giúp tránh gánh nặng công việc phát sinh do thêm vào mọi tính năng không cần thiết trong trường hợp tốt nhất, và trong trường hợp xấu nhất là không tiêu tốn thời gian cho những dự án sẽ thất bại
- Cách tốt nhất từ trước đến nay để nắm phạm vi đầy đủ của vấn đề là thực hiện giải pháp cơ bản nhỏ nhất và dễ nhất, rồi lặp lại sau đó nếu cần
Giới hạn và những điểm cần cẩn trọng
- Cách làm này cũng có nhược điểm; ví dụ ở một số tổ chức, mọi giao dịch và thông tin đều được ghi vào những bảng tính có tới hàng nghìn dòng
- Google Sheets chỉ hữu ích trước khi xác định được toàn bộ phạm vi của vấn đề
- Cần có kinh nghiệm và khả năng phán đoán để biết vấn đề nào có thể giải quyết bằng Google Sheet
- Điều quan trọng là ưu tiên phát triển những công cụ thực sự sẽ được sử dụng mà không lãng phí thời gian
- Tuy nhiên, đây không phải lời khuyên áp dụng cho tất cả mọi người, nên mỗi người cần thận trọng cân nhắc theo tình huống của mình
Kết luận
- Bắt đầu từ nỗ lực nhỏ nhất và giải pháp đơn giản nhất, rồi chỉ mở rộng hoặc nâng cấp khi cần, là chiến lược rất phù hợp với startup hoặc môi trường nhiều biến động
- Bạn vẫn có thể tự do thử nghiệm phát triển cá nhân, nhưng trong kinh doanh, điều quan trọng là chỉ xây thứ thật sự cần thiết và không đổ thời gian, năng lượng vào những việc không cần
3 bình luận
Tôi cũng cơ bản đồng ý, nhưng hiện tại so với Google Sheets thì tôi thích dùng Notion Database làm baseline ban đầu hơn. Cũng khá tương tự, nhưng dù sao việc thiết lập template chỉ do 1 người làm. Nếu những người khác quản lý dữ liệu trên nền tảng đó thì có thể tránh được tình trạng lộn xộn. Dù không bằng Apps Script, nhưng việc triển khai tự động hóa cũng dễ hơn một chút. Độ khó của thiết lập ban đầu nếu có cao hơn thì cũng chỉ nhỉnh hơn một chút chứ không đáng kể, và về độ linh hoạt thì tôi thấy cũng tương đương. Hơn nữa, gần đây còn hỗ trợ quản lý quyền theo từng row nữa nên Good.
Notion có vẻ tốt vì đường cong học tập thấp.
Ý kiến trên Hacker News
Đây luôn là một điểm thường bị bỏ qua. Bảng tính gom vào một chỗ cơ sở dữ liệu, UI có thể tùy biến nhanh và dễ, cùng một môi trường xử lý dữ liệu lặp đi lặp lại và dễ debug. Đây là công cụ mà hầu như mọi người đi làm trên toàn thế giới đều đã hiểu và sử dụng, đồng thời cũng cho người tạo ra mức độ tự do để triển khai theo đúng ý mình. Tính cơ động cũng rất tốt. Tôi tin rằng đây là một công cụ đặc biệt sáng tạo và mạnh mẽ với những người không biết lập trình. Tất nhiên kiểu tự do này cũng đi kèm nhược điểm, nhưng bất chấp tranh luận về việc có nên online hóa hay nhà cung cấp nào tốt hơn, tình yêu sâu đậm dành cho bảng tính của tôi vẫn không hề giảm. Tôi nghĩ đây là công cụ sáng tác tốt nhất mà chúng ta từng tạo ra. Mô hình tương tự bảng tính mà tôi muốn nhắc tới là HyperCard. Nó từng là một bàn làm việc linh hoạt có thể kết nối nhiều ứng dụng, dữ liệu, UX khác nhau. Tôi mong HyperCard sẽ được nhớ mãi
Đúng vậy, bảng tính có rào cản gia nhập cực thấp. Tôi thậm chí còn nhập nhật ký tăng trưởng cây trồng vào Google Sheets bằng điện thoại ngay giữa nông trại. Dù sóng yếu, tôi vẫn ghi lại bằng chế độ ngoại tuyến rồi về nhà đồng bộ. Dữ liệu có lộn xộn một chút vẫn còn tốt hơn là không có gì. Nông nghiệp cần rất nhiều dữ liệu nhưng lại là môi trường thiếu dữ liệu một cách đáng ngạc nhiên. Chu kỳ học hỏi dài tới mức tính theo năm, mà mỗi năm lại khác nhau
Với người biết lập trình, Apps Script gần như biến bảng tính thành siêu năng lực. Nói thêm cho ai chưa biết, bạn không nhất thiết chỉ viết JS trong web IDE tích hợp sẵn của Google Sheets đâu (thực ra cái đó cũng khá dùng được). Nếu dùng
clasp, bạn có thể phát triển bằng Typescript trong IDE cục bộ, rồi trong quá trình build biên dịch sang JS và triển khai thẳng vào bảng tính. Nếu đã thiết lập sẵn toolchain thì trải nghiệm phát triển (DX) cũng khá ổnHoàn toàn đồng ý. Giá trị của một bàn làm việc tích hợp database + UX + logic trong một thể thống nhất chính là cốt lõi của kiểu ứng dụng mà chúng ta cứ liên tục tạo ra. Đó cũng là lý do Visual Basic vẫn còn được dùng. Dĩ nhiên khi hướng đi đã được xác định rõ thì đó không còn là cách tốt nhất nữa, nhưng để lặp thật nhanh và tìm ra yêu cầu thực sự thì không gì phù hợp hơn
Tôi nghĩ sẽ rất hay nếu có cách tốt hơn để dùng bảng tính làm backend cơ sở dữ liệu. Phần lớn những việc mà đa số mọi người làm bằng bảng tính sẽ được xử lý tốt hơn trong cơ sở dữ liệu. Nhưng cơ sở dữ liệu cần nhiều đào tạo hơn, và nếu thiếu đào tạo thì kết quả còn có thể tệ hơn cả bảng tính
Tôi luôn thắc mắc tại sao lại không có một lộ trình chuyển đổi thực tế để dần dần đi từ bảng tính sang một cơ sở dữ liệu hoàn chỉnh có UI tùy biến. Bảng tính gần như là bước ngay trước vai trò đó rồi; chỉ cần có thêm vài tính năng thiết yếu thôi (dữ liệu có cấu trúc, SQL gốc, thành phần UI tùy biến, tích hợp IDE, v.v.) là có vẻ đủ khả thi
Điều này làm tôi nhớ tới bài viết "Ask HN: Is the world run by badly updated Excel sheets?". Muốn thực sự cảm nhận giới hạn của bảng tính thì cần có trải nghiệm trực tiếp. Không có quản lý phiên bản, cũng không có kiểm thử. Nó phù hợp cho những công việc ngắn hạn, ít thay đổi, nhưng sẽ thành vấn đề nếu phải liên tục tiến hóa. Tham khảo https://news.ycombinator.com/item?id=33611431. Trong chủ đề đó có một bình luận như sau: rốt cuộc trong công ty thì mọi người đều phải thích nghi theo cách làm của người sở hữu file Excel. Nếu không thích thì chỉ việc tự tạo một file Excel mới rồi copy-paste, nên ai cũng tự quản lấy phần của mình. Một quản lý dự án mà tôi biết coi việc liên tục điều phối các phiên bản bảng tính do nhiều tác giả tạo ra là chuyện thường ngày
Khi mới bắt đầu làm coder ở Mỹ vào những năm 2000, tôi nghĩ công việc của mình là biến các bảng tính trên ổ đĩa mạng Windows — những thứ lúc nào cũng cần ai đó chăm chút giữ gìn — thành web app. Nhưng đúng là vẫn có nhiều công ty vận hành ổn với bảng tính. Cuối cùng sẽ đến lúc vấn đề mở rộng bùng nổ, và khi đó phải chuyển sang ứng dụng, nhưng thay vì cố làm cho hoàn hảo rồi chẳng làm được gì, điều quan trọng là trước hết phải làm cho xong
Bạn nói "không có quản lý phiên bản", nhưng thực ra Excel cũng có tính năng kiểu đó. Nếu dùng “Track Changes”, bạn có thể chấp nhận hoặc từ chối thay đổi của người khác. Chỉ là những người dùng tự động hóa bảng tính kiểu Rube Goldberg để làm việc hầu như không dùng tính năng này. Nếu cần thì vẫn có thể dùng được
Tôi đã thấy rất nhiều vấn đề phát sinh khi thông tin bị phân tán trên nhiều bảng tính khác nhau. Người tham gia thường không biết thông tin nào nằm ở bảng nào, và đâu mới là nguồn chuẩn. Vì vậy rất hay xảy ra va chạm kiểu một người không biết ai đó chỉ cập nhật file A, còn người khác lại chỉ động vào file B. Vấn đề không nằm ở chương trình hay dữ liệu, mà nằm ở cách quản lý file trong dự án. Nó trở thành một mê cung quản trị với thư mục dùng chung phức tạp, file bị bỏ mặc đâu đó trên mạng nội bộ, v.v.
Tôi đồng ý với lời khuyên rằng “hãy luôn dùng cách dễ nhất để giải quyết vấn đề, và khi cách đó không còn phù hợp với doanh nghiệp nữa thì hãy cải tiến hoặc tìm giải pháp thay thế theo yêu cầu mới”. Cần tập trung vào việc giải quyết vấn đề hiện có, chứ khó mà đoán trúng những vấn đề tương lai có thể hoặc mong muốn sẽ xuất hiện. Giải pháp hiện tại có thể trở nên không phù hợp trong tương lai, nhưng rất khó dự đoán nó sẽ không phù hợp theo cách nào
Dù khó dự đoán giải pháp sẽ trở nên không phù hợp theo hướng nào trong tương lai, ta vẫn có thể chọn giải pháp hiện tại theo cách không chặn hoặc không cản trở các giải pháp tương lai. Nên để mở các lựa chọn và tránh rơi vào tình huống bị khóa chặt vào một nhà cung cấp mà không thể thoát ra
Một trường hợp không phù hợp khá dễ dự đoán là bạn phụ thuộc hoàn toàn vào một nhà cung cấp nào đó, rồi bị buộc rời khỏi dịch vụ hoặc phải chấp nhận mức giá ngày càng đắt. Đây là vấn đề hoàn toàn có thể thấy trước
Nếu giải quyết vấn đề theo cách bao phủ được toàn bộ miền vấn đề mà không cần làm nhiều việc hơn, thì bạn có thể hấp thụ những thay đổi về yêu cầu chỉ với điều chỉnh nhỏ, nhờ đó tăng độ bền vững của giải pháp. Làm vậy thì tự nhiên cũng sẽ bao phủ được cả các vấn đề tương lai
Tôi làm ở một tập đoàn lớn nổi tiếng tại Mỹ. Bộ phận của chúng tôi phụ thuộc rất nhiều vào hai bảng tính. Chúng đã sống sót qua ba lần M&A liên quan đến nhà máy của tôi. Khi tôi vào công ty cách đây 7 năm thì đó đã là những biểu mẫu cũ kỹ từ lâu rồi. Hai năm trước, một quản lý mới đã cố chuyển chúng sang hệ thống toàn công ty nhưng thất bại, và chẳng bao lâu nữa bản thân hệ thống đó cũng sẽ bị thay bằng một hệ thống khác. Nhưng có lẽ đến năm 2027 chúng tôi vẫn sẽ còn dùng bảng tính
Tôi là cựu nhân viên Google. Trong 5 năm, tôi xử lý mọi thứ chỉ bằng Sheets (nội bộ gọi là Trix): quản lý dự án, CRM, lập kế hoạch theo quý, báo cáo, phỏng vấn, tài chính, v.v. Không phải chỉ vì đó là sản phẩm của Google mà dùng như vậy đâu (chúng tôi cũng dùng sản phẩm đối thủ khá nhiều). Điều tiện áp đảo là bảng tính có thể được tạo ra đủ nhanh để phục vụ mục tiêu, nhờ đó môi trường làm việc cho phép tập trung vào bản chất của công việc
Với ý kiến của ai đó rằng “mới vào công ty được 9 tháng”, tôi nghĩ dù đúng hay sai thì việc đưa ra nhận định dứt khoát như vậy khi kinh nghiệm còn chưa đầy 1 năm cũng khá táo bạo. Điều OP bỏ sót là chân lý “không có gì lâu dài bằng giải pháp tạm thời”. Chọn một cách giải quyết nhanh và ứng biến lúc đầu chỉ ổn khi bạn kiểm soát trọn vẹn vòng đời của giải pháp đó. Nếu ai đó yêu cầu bạn làm gấp để bàn giao, rồi sau đó lại định tiếp tục chồng thêm các mục đích sử dụng mới lên trên nó… thì tôi sẽ rất mạnh mẽ đề xuất dùng một công cụ có chi phí ban đầu cao hơn một chút
Tôi gần như bật cười ở đoạn “cứ vài tháng một lần...”. Tác giả nói đúng ở nguyên tắc lớn là nên xử lý công việc bằng công cụ đơn giản. Nếu có thể dùng ngay công cụ sẵn có và nó đáp ứng ổn nhu cầu thì đó là tốt nhất. Ngoài thực tế, yêu cầu kinh doanh thay đổi vài tháng một lần nên đôi khi bạn có thể tránh được hiện tượng “giải pháp tạm thời trở thành giải pháp vĩnh viễn”. Nhưng với đa số người, sau vài năm họ vẫn phải dọn hậu quả, và kịch bản “khi cần thì viết lại” gần như không vận hành. Tác giả vẫn chưa trực tiếp trải qua mốc 1 năm, chứ chưa nói lâu hơn
Riêng tôi đặc biệt ấn tượng với đoạn “cứ vài tháng...”. Tôi tự hỏi không biết đây có phải là nhận xét được rút ra sau khi đã trải qua chừng 4 lần hay chưa
Với những ai đã chán ngấy các bảng tính cỡ lớn, MS Access từng là một giải pháp khá hữu dụng. Nó bổ sung tính cấu trúc và khả năng bảo trì cho bảng tính mà vẫn giữ được tính dễ tiếp cận và độ khó phát triển thấp. Bạn có thể tạo UI rất tốt mà không cần nhiều kiến thức lập trình. Sau 20 năm, đến giờ tôi vẫn không rõ giải pháp nào thay thế được Access
Tôi hoàn toàn đồng ý với OP. Thêm một ý là khi yêu cầu trở nên quá phức tạp để xử lý trong Google Sheets, thì Google Colab (hoặc Jupyter notebook) là lựa chọn cao hơn một bậc. Trước khi bắt tay xây ứng dụng thật sự, tôi luôn tự hỏi: 1. Cái này làm bằng bảng tính thôi có được không? 2. Nếu không thì làm bằng Jupyter notebook có được không? Nhân tiện, khả năng tích hợp giữa Sheets và Colab cũng rất tuyệt
Theo tôi thì jupyter notebook còn phức tạp hơn rất nhiều so với việc chỉ viết python script. Với python script bạn cũng có thể viết chú thích, chứ kiểu “phải dựng một local webserver lên, rồi chạy từng block code để xem chú thích” thì tôi không thích lắm
Tôi tò mò không biết nếu muốn nâng cấp thứ đang có sẵn trong google sheet lên thành colab notebook thì làm thế nào. Dùng gspread package của Python thì có thể đọc raw data của sheet, nhưng có vẻ khó mà mang nguyên cả các biểu đồ và thành phần tương tác sẵn có sang thẳng jupyter notebook. Cuối cùng chắc vẫn phải làm lại
Google Apps Script cũng là một lựa chọn thay thế tốt. Chỉ với những script đơn giản như lấy dữ liệu về thôi cũng làm được khá nhiều thứ
Một trong những vấn đề lớn nhất của tự động hóa nghiệp vụ là khoảng trống tồn tại giữa cái gọi là IT “bóng tối” (
shadowIT), các nền tảng low-code, và những dự án “chính quy” hoàn chỉnh. Giữa “vá tạm bằng Google Form” và “dựng một app React có đủ CI/CD, test, CDN” đang thiếu hẳn một lộ trình migration phù hợp. Toàn là những lựa chọn kiểu khu vườn đóng kín, không tương thích với nhauTôi dùng Google Sheets để quản lý toàn bộ tài chính cá nhân. Tôi còn tự làm cả UI Expense Tracker và đã tích lũy hơn 5.000 bản ghi chi tiêu trong nhiều năm. Gần đây tôi còn dùng vibe coding để làm một công cụ web UI sử dụng Google Service Account, rồi biến nó thành PWA để dùng cả trên điện thoại. Với các nhu cầu đơn giản (đặc biệt là ứng dụng cho một người dùng), Google Sheets là quá đủ thay cho DB