เหตุผลที่ฉันใช้แต่ Google Sheets

• ในสภาพแวดล้อมทางธุรกิจระยะเริ่มต้นที่เปลี่ยนแปลงบ่อย การแก้ปัญหาอย่างรวดเร็วด้วย ทางออกที่ง่ายที่สุด ก่อน แล้วเมื่อเริ่มเห็นข้อจำกัดค่อย ประเมินความต้องการใหม่ เพื่อเปลี่ยนหรือเสริม จึงเป็นทางเลือกที่ฉลาด
• Google Sheets เป็นเครื่องมือแก้ปัญหาที่มีประสิทธิภาพในสภาพแวดล้อมที่เปลี่ยนเร็ว และได้เปรียบกว่าการพัฒนาเครื่องมือซับซ้อนในแง่การใช้งานจริงและ ลดความสูญเปล่า
• ผู้เขียนย้อนมองประสบการณ์การทำงานว่าตนเองรีบสร้างระบบเฉพาะทางแทนการใช้เครื่องมืออเนกประสงค์ และมองข้าม ความไม่แน่นอนของขอบเขตงาน จนทำให้เสียเวลา
• วิธีคิดหลักคือกลยุทธ์ เริ่มจากวิธีที่เล็กและง่ายที่สุด → ใช้งานจริงเพื่อดูขอบเขตงาน → ค่อยปรับปรุงแบบค่อยเป็นค่อยไปเมื่อจำเป็น ซึ่งเป็นแนวทางแบบ เริ่มเล็กและทำซ้ำ
• อย่างไรก็ตาม ไม่ใช่ทุกปัญหาจะแก้ได้ด้วยสเปรดชีต และควรใช้มันเป็นการชั่วคราวจนกว่าขอบเขตงานจะชัดเจน โดยการ คัดเลือกอย่างชาญฉลาด ให้เหมาะกับบริบทขององค์กรเป็นสิ่งสำคัญ

---

ทางเลือกที่ง่ายที่สุดในการแก้ปัญหา

• ไม่ว่าจะเป็นปัญหาใด การเลือก โซลูชันที่นำไปใช้ได้ง่ายที่สุด ก่อนเป็นสิ่งสำคัญ
• เมื่อวิธีนั้นไม่ตอบโจทย์ธุรกิจอีกต่อไป ก็จำเป็นต้อง ปรับปรุงโซลูชันเดิมหรือหาทางเลือกใหม่ ให้สอดคล้องกับความต้องการใหม่
• ในสภาพแวดล้อมที่ผู้เขียนเคยเจอ การสร้าง Google Sheet ใหม่มักเป็นวิธีที่เหมาะสมที่สุด

สภาพแวดล้อมสตาร์ตอัปที่เปลี่ยนเร็วและประโยชน์ของเครื่องมือ

• เมื่อประมาณ 9 เดือนก่อน ผู้เขียนเข้าทำงานที่บริษัท และความคาดหวังเรื่องการสร้าง เครื่องมือและบริการใหม่ สำหรับบริษัทขนาดเล็กในระยะเริ่มต้นก็เริ่มจางหายไป
• ในสภาพแวดล้อมที่ทิศทางธุรกิจเปลี่ยนทุก 2 เดือน หลายโปรเจกต์จึงเริ่มต้นขึ้นแล้วก็ต้องหยุดไป
• หลายกรณี ทั้งที่ Google Sheet สามารถแก้ปัญหาได้อย่างง่ายดาย กลับยังลงทุนเวลาและแรงไปกับโปรเจกต์ที่ซับซ้อนโดยไม่จำเป็น

ตัวอย่างการเสียเวลา

• แอดมินพาเนลจัดการขนส่งสินค้า

  • ใช้เวลา 2 เดือน ในการออกแบบและสร้างแอดมินพาเนลสำหรับจัดการและติดตามสินค้าที่รับเข้าเพื่อธุรกิจ
  • มีเป้าหมายเพื่อช่วยจัดหมวดหมู่แพ็กเกจและข้อมูลลูกค้าให้บริหารจัดการได้ดีขึ้น
  • แอดมินพาเนลนี้ ถูกใช้งานเพียงสองครั้งและไม่เคยถูกใช้อีกเลย
  • จริง ๆ แล้วสามารถแทนที่ได้ง่ายด้วย Google Sheet และปัจจุบันก็ใช้วิธีนี้อยู่

• MVP สำหรับคำนวณภาษีศุลกากรอัตโนมัติ

  • ใช้เวลา 3 สัปดาห์ ในการสร้าง MVP ของระบบประเมินราคาที่คำนวณภาษีศุลกากรและภาษีอัตโนมัติเมื่อสั่งซื้อสินค้าบางประเภท
  • ภาษีและอากรของซิมบับเวมีความซับซ้อนมาก หากลูกค้าทราบยอดที่ต้องจ่ายอย่างแม่นยำก็จะช่วยให้ประสบการณ์ลูกค้าดีขึ้น และทำให้ไม่ต้องรอคำตอบทุกครั้งจากบริษัทภายนอกที่รับจัดการพิธีการศุลกากร จึงช่วยให้กระบวนการเร็วขึ้น
  • สุดท้ายกลับไปดูตารางจัดหมวดหมู่ภาษีและอากรของคู่แข่งแล้ว คัดลอกมาใช้ใน Google Sheet

• กระบวนการเลือก CRM

  • ใช้เวลา 2 เดือน ไปกับการค้นคว้า ประชุม (ครั้งละมากกว่า 1 ชั่วโมง) และค้นหาข้อมูลเพื่อหา CRM ที่เหมาะกับธุรกิจ
  • นั่งเปรียบเทียบและวิเคราะห์ฟีเจอร์กับราคาของ CRM หลายตัว
  • สุดท้ายตัดสินใจใช้ Oddo เวอร์ชันฟรี แต่ก็ไม่ได้ถูกใช้งานมากนักภายในธุรกิจ
  • น่าแปลกที่เพิ่งมาพบเมื่อไม่กี่สัปดาห์ก่อนว่า Google Sheets มีเทมเพลต CRM ในตัว

หลักการของแนวทางแบบ Google Sheets

• การสร้าง Google Sheet ไม่ใช่ทางออกที่ดีที่สุดสำหรับทุกปัญหา แต่ในสถานการณ์ของผู้เขียนมักจะเป็นเช่นนั้น
• ผู้เขียนมักอยู่ในสถานการณ์ที่ ไม่มีทางรู้ขอบเขตทั้งหมดของปัญหาได้จริง จนกว่าจะเริ่มลงมือทำงาน
• นี่ไม่ได้หมายความว่าไม่ควรวางแผนโปรเจกต์
• ทีมควรพูดคุยเรื่องเวิร์กโฟลว์และข้อมูลที่จำเป็น แต่ ก่อนเริ่มทำงานจริง เราไม่อาจรู้ขอบเขตทั้งหมดของปัญหาได้
• เมื่อเข้าใจขอบเขตทั้งหมดของปัญหาแล้ว จึงค่อยเริ่มสร้างหรือปรับปรุงโซลูชันที่มีอยู่ได้
• วิธีนี้ช่วยหลีกเลี่ยงภาระงานส่วนเกินจากการเพิ่มฟีเจอร์ที่ไม่จำเป็นทั้งหมดในกรณีดีที่สุด และช่วยไม่ให้เสียเวลากับโปรเจกต์ที่อาจล้มเหลวในกรณีแย่ที่สุด
• วิธีที่ดีที่สุดเท่าที่ผู้เขียนพบในการทำความเข้าใจขอบเขตทั้งหมดของปัญหาคือการทำ โซลูชันพื้นฐานที่เล็กและง่ายที่สุด ก่อน แล้วค่อยทำซ้ำหรือปรับต่อเมื่อจำเป็น

ข้อจำกัดและสิ่งที่ต้องระวัง

• แนวทางนี้ก็มีข้อเสีย เช่น บางองค์กรใช้ สเปรดชีต ที่มีข้อมูลหลายพันแถวเพื่อบันทึกทุกธุรกรรมและข้อมูลทั้งหมด
• Google Sheets มีประโยชน์เฉพาะ ก่อนที่จะเข้าใจขอบเขตทั้งหมดของปัญหา
• จำเป็นต้องมีประสบการณ์และวิจารณญาณว่า ปัญหาแบบใดเหมาะจะใช้ Google Sheet แก้ได้
• ควรให้ความสำคัญกับการพัฒนาเครื่องมือที่ใช้งานได้จริงโดยไม่เสียเวลาเปล่า
• อย่างไรก็ตาม นี่ไม่ใช่คำแนะนำที่ใช้ได้กับทุกคน จึงจำเป็นต้องพิจารณาอย่างรอบคอบตามสถานการณ์ของแต่ละคน

บทสรุป

• การเริ่มจากความพยายามที่น้อยที่สุดและโซลูชันที่เรียบง่ายที่สุด แล้วค่อยขยายหรือพัฒนาเมื่อจำเป็น เป็นกลยุทธ์ที่เหมาะมากกับ สตาร์ตอัปหรือสภาพแวดล้อมที่เปลี่ยนแปลงบ่อย
• จะทดลองพัฒนาส่วนตัวอย่างอิสระก็ได้ แต่ในเชิงธุรกิจ สิ่งสำคัญคือ สร้างเฉพาะสิ่งที่จำเป็นจริง ๆ และไม่ทุ่มเวลาและพลังงานไปกับงานที่ไม่จำเป็น

[shalome7]

ผมก็เห็นด้วยเป็นพื้นฐานเหมือนกัน แต่ตอนนี้ผมชอบใช้ Notion Database เป็นเบสไลน์เริ่มต้นมากกว่า Google Sheets ครับ มันคล้ายกันอยู่ แต่ยังไงการตั้งค่าเทมเพลตก็มีแค่ 1 คน ส่วนคนอื่นก็จัดการข้อมูลต่อบนฐานนั้นได้ เลยช่วยป้องกันไม่ให้สถานการณ์ยุ่งเหยิงได้ ถึงจะทำอัตโนมัติได้ไม่เก่งเท่า App Script แต่ก็ทำได้ง่ายกว่าอีกหน่อย ความยากของการตั้งค่าเริ่มต้นอาจจะสูงกว่านิด~หน่อย แต่ก็ไม่ได้มาก และเรื่องความยืดหยุ่นก็ดูคล้าย ๆ กันครับ แถมช่วงหลังยังจัดการสิทธิ์แบบรายแถวได้แล้วด้วย เลย Good.

[shakespeares]

ฉันคิดว่า Notion ดีเพราะมีเส้นโค้งการเรียนรู้ที่ไม่สูงนัก

[GN⁺]

ความคิดเห็นบน Hacker News

• นี่เป็นจุดที่มักถูกมองข้ามเสมอ สเปรดชีตรวมเอาฐานข้อมูล, UI ที่ปรับแต่งได้รวดเร็วและง่าย, และสภาพแวดล้อมสำหรับประมวลผลข้อมูลแบบวนซ้ำที่ดีบักได้ง่ายไว้ในที่เดียว คนทำงานทั่วโลกต่างก็เข้าใจและใช้งานเครื่องมือนี้กันอยู่แล้ว และมันยังให้อิสระแก่ผู้สร้างในการทำสิ่งต่าง ๆ ได้ตามต้องการอีกด้วย เรื่องการพกพาก็ยอดเยี่ยมเช่นกัน ฉันเชื่อจริง ๆ ว่านี่เป็นเครื่องมือที่สร้างสรรค์และทรงพลังมาก โดยเฉพาะสำหรับคนที่เขียนโค้ดไม่เป็น แน่นอนว่าอิสรภาพแบบนี้ก็มีข้อเสียตามมาด้วย แต่ต่อให้จะถกเถียงกันเรื่องออนไลน์หรือไม่ออนไลน์ หรือผู้ให้บริการรายไหนดีกว่า ความรักลึก ๆ ที่มีต่อสเปรดชีตก็ไม่เคยลดลงเลย ฉันคิดว่านี่คือหนึ่งในเครื่องมือสำหรับการสร้างสรรค์ที่ดีที่สุดที่เราเคยทำขึ้นมา โมเดลที่คล้ายกับสเปรดชีตอีกอย่างหนึ่งคือ HyperCard มันเป็นโต๊ะทำงานที่ยืดหยุ่นซึ่งสามารถเชื่อมโยงแอป ข้อมูล UX และสิ่งต่าง ๆ เข้าด้วยกันได้ หวังว่า HyperCard จะถูกจดจำไปตลอดกาล

  • เห็นด้วยเลย สเปรดชีตมีอุปสรรคในการเริ่มต้นใช้งานต่ำมาก ถึงขั้นที่ฉันยังกรอกบันทึกการเติบโตของพืชผลลง Google Sheets จากมือถือกลางไร่ได้เลย ต่อให้สัญญาณอ่อนก็ยังบันทึกไว้ในโหมดออฟไลน์ แล้วค่อยซิงก์ตอนกลับถึงบ้าน ถึงข้อมูลที่บันทึกจะไม่เป็นระเบียบนัก มันก็ยังดีกว่าไม่มีอะไรเลย การเกษตรเป็นงานที่ต้องใช้ข้อมูลเยอะมาก แต่กลับอยู่ในสภาพแวดล้อมที่ข้อมูลขาดแคลนอย่างน่าประหลาด วงจรการเรียนรู้ก็ยาวเป็นปี และแต่ละปีก็ไม่เหมือนกันเลย

  • สำหรับคนที่เขียนโค้ดได้ Appscript ทำให้สเปรดชีตแทบจะกลายเป็นพลังพิเศษเลย สำหรับคนที่อาจยังไม่รู้ ไม่ได้แปลว่าคุณต้องเขียนแค่ JS ในเว็บ IDE ที่ฝังมากับ Google Sheets เท่านั้นนะ (ซึ่งจริง ๆ แบบนั้นก็ใช้ได้ดีพอตัวอยู่แล้ว) ถ้าใช้ clasp ก็พัฒนาใน local IDE ด้วย Typescript ได้ แล้วให้ขั้นตอน build คอมไพล์เป็น JS และ deploy เข้าไปยังสเปรดชีตได้ตรง ๆ ถ้าตั้งค่า toolchain ไว้เรียบร้อยแล้ว ประสบการณ์การพัฒนา (DX) ก็ถือว่าดีทีเดียว

  • เห็นด้วยอย่างยิ่ง คุณค่าของโต๊ะทำงานที่รวมฐานข้อมูล + UX + logic ไว้เป็นหนึ่งเดียว คือแก่นของแอปที่เราสร้างซ้ำแล้วซ้ำอีก นั่นจึงเป็นเหตุผลว่าทำไม Visual Basic ถึงยังถูกใช้อยู่ แน่นอนว่าเมื่อทิศทางชัดเจนแล้ว มันอาจไม่ใช่วิธีที่ดีที่สุด แต่สำหรับการทำซ้ำอย่างรวดเร็วเพื่อค้นหาความต้องการที่แท้จริงแล้ว แทบไม่มีอะไรจะดีไปกว่านี้

  • ฉันคิดว่าน่าจะดีถ้ามีวิธีที่ดีกว่านี้ในการใช้สเปรดชีตเป็นแบ็กเอนด์ฐานข้อมูล งานจำนวนมากที่คนส่วนใหญ่ทำในสเปรดชีต น่าจะจัดการได้ดีกว่าในฐานข้อมูล แต่ฐานข้อมูลต้องการการศึกษาเพิ่ม และถ้าความรู้ไม่พอ ผลลัพธ์อาจแย่กว่าสเปรดชีตเสียอีก

  • ฉันสงสัยมาตลอดว่าทำไมถึงไม่มีเส้นทางเปลี่ยนผ่านที่ใช้งานได้จริงจากสเปรดชีตไปสู่ฐานข้อมูลเต็มรูปแบบที่มี custom UI แบบค่อยเป็นค่อยไป สเปรดชีตเหมือนจะเป็นขั้นก่อนหน้านั้นพอดีเลย ถ้ามีฟีเจอร์สำคัญเพิ่มอีกไม่กี่อย่าง (ข้อมูลแบบมีโครงสร้าง, native SQL, องค์ประกอบ custom UI, การรวมกับ IDE ฯลฯ) ก็น่าจะทำได้แล้ว

• ทำให้นึกถึงโพสต์ "Ask HN: Is the world run by badly updated Excel sheets?" ถ้าจะเข้าใจข้อจำกัดของสเปรดชีตจริง ๆ ต้องเคยเจอด้วยตัวเองก่อน ไม่มี version control, ไม่มีการทดสอบ มันเหมาะกับงานที่ไม่เปลี่ยนแปลงและอายุสั้น แต่ถ้าต้องพัฒนาไปเรื่อย ๆ ก็จะมีปัญหา ดู https://news.ycombinator.com/item?id=33611431 ได้ ในเธรดนั้นมีคอมเมนต์หนึ่งว่า สุดท้ายแล้วในบริษัททุกคนก็ต้องปรับตัวเข้ากับวิธีของเจ้าของ Excel ถ้าไม่ชอบก็แค่สร้าง Excel ใหม่ของตัวเองแล้วคัดลอกวาง ทุกคนเลยจัดการกันเอง มีผู้จัดการโครงการคนหนึ่งที่ฉันรู้จัก ซึ่งชีวิตประจำวันคือการคอยประสานเวอร์ชันของสเปรดชีตที่มีผู้เขียนหลายคนตลอดเวลา

  • ตอนเริ่มทำงานเป็นโค้ดเดอร์ในสหรัฐช่วงยุค 2000 ฉันคิดว่างานของฉันคือการเปลี่ยนสเปรดชีตบน Windows network drive ที่ต้องมีใครสักคนคอยประคบประหงมอยู่เสมอให้เป็นเว็บแอป แต่ถึงอย่างนั้น หลายบริษัทก็ยังดำเนินงานด้วยสเปรดชีตได้ดีอยู่ดี สุดท้ายแล้วก็จะมีวันที่ปัญหาเรื่องการขยายระบบปะทุขึ้นมา และตอนนั้นค่อยย้ายไปเป็นแอปก็ได้ สำคัญคือทำให้มันใช้ได้จริงก่อน ดีกว่าจะมัวพยายามให้สมบูรณ์แบบจนไม่ได้ทำอะไรเลย

  • คุณบอกว่า "ไม่มี version control" แต่จริง ๆ แล้ว Excel ก็มีฟีเจอร์ลักษณะนั้นอยู่เหมือนกัน ถ้าใช้ "Track Changes" ก็สามารถอนุมัติหรือปฏิเสธการเปลี่ยนแปลงของคนอื่นได้ เพียงแต่คนที่ใช้สเปรดชีตอัตโนมัติแบบซับซ้อนสไตล์ Rube Goldberg เพื่อทำงานกัน มักแทบไม่เคยใช้ฟีเจอร์นี้ ถ้าจำเป็นก็ใช้ได้นะ

  • ฉันเห็นปัญหาบ่อยมากตอนที่ข้อมูลกระจัดกระจายอยู่ในหลายสเปรดชีต ผู้มีส่วนร่วมมักไม่รู้ว่าข้อมูลอะไรอยู่ในชีตไหน และอันไหนคือฉบับอ้างอิง เลยเกิดการชนกันบ่อย เช่น มีคนอัปเดตแต่ไฟล์ A โดยที่อีกคนไม่รู้ แล้วไปแก้แต่ไฟล์ B ปัญหาจริง ๆ ไม่ได้อยู่ที่โปรแกรมหรือข้อมูลเท่าไร แต่อยู่ที่วิธีจัดการไฟล์ภายในโครงการมากกว่า ทั้ง shared folder ที่ซับซ้อน หรือไฟล์ที่ถูกทิ้งไว้ที่ไหนสักแห่งบนเครือข่าย จนกลายเป็นเขาวงกตของการจัดการ

• ฉันเห็นด้วยกับคำแนะนำที่ว่า "แก้ปัญหาด้วยวิธีที่ง่ายที่สุดเสมอ และเมื่อวิธีนั้นไม่ตอบโจทย์ธุรกิจอีกต่อไป ก็ค่อยปรับปรุงตามความต้องการใหม่หรือหาทางเลือกอื่น" ควรโฟกัสกับการแก้ปัญหาที่มีอยู่ตอนนี้ มากกว่าจะไปกังวลล่วงหน้าเรื่องปัญหาที่อาจเกิดหรืออยากให้เกิดในอนาคต เพราะแม้โซลูชันปัจจุบันอาจไม่เหมาะกับอนาคต แต่ก็เดาได้ยากมากว่ามันจะไม่เหมาะในแบบไหน

  • แม้จะเดายากว่าโซลูชันจะไม่เหมาะกับอนาคตในทิศทางไหน แต่เราก็ยังเลือกโซลูชันปัจจุบันในแบบที่ไม่ปิดกั้นหรือขัดขวางโซลูชันในอนาคตได้ ควรเปิดทางเลือกไว้ และหลีกเลี่ยงการผูกติดกับผู้ให้บริการจนหนีออกมาไม่ได้

  • กรณีไม่เหมาะในอนาคตที่คาดเดาได้ชัดเจนอย่างหนึ่งคือ การพึ่งพาผู้ให้บริการรายใดรายหนึ่งอย่างสมบูรณ์ จนสุดท้ายถูกบีบให้ออกจากบริการ หรือจำใจต้องรับค่าบริการที่แพงขึ้นเรื่อย ๆ นี่เป็นปัญหาที่คาดการณ์ได้มากพอสมควร

  • ถ้าคุณแก้ปัญหาในลักษณะที่ครอบคลุมทั้งโดเมนปัญหาโดยไม่ต้องทำงานเพิ่มมากนัก คุณก็จะดูดซับความต้องการที่เปลี่ยนไปได้ด้วยการปรับเพียงเล็กน้อย ซึ่งช่วยให้โซลูชันมีความทนทานมากขึ้น และโดยธรรมชาติก็ครอบคลุมปัญหาในอนาคตไปด้วย

• ฉันทำงานอยู่ในบริษัทใหญ่ชื่อดังแห่งหนึ่งในสหรัฐ แผนกของเราพึ่งพาสเปรดชีตอยู่มากสองไฟล์ มันรอดผ่านการควบรวมกิจการของโรงงานฉันมาแล้วสามครั้ง ตอนฉันเข้าทำงานเมื่อ 7 ปีก่อน มันก็เป็นฟอร์มเก่ามากอยู่แล้ว เมื่อ 2 ปีก่อน ผู้จัดการคนใหม่พยายามย้ายมันเข้าไประบบทั้งองค์กรแต่ไม่สำเร็จ และอีกไม่นานระบบนั้นเองก็จะถูกแทนที่ด้วยระบบใหม่อีกที แต่ฉันคิดว่าในปี 2027 เราก็คงยังใช้สเปรดชีตกันอยู่ดี

• ฉันเคยเป็นพนักงาน Google ตลอด 5 ปี ฉันจัดการทุกอย่างด้วย Sheets เพียงอย่างเดียว (ภายในเรียกว่า Trix) ไม่ว่าจะเป็นการบริหารโครงการ CRM การวางแผนรายไตรมาส การทำรายงาน การสัมภาษณ์ หรือการเงิน ไม่ใช่แค่เพราะมันเป็นผลิตภัณฑ์ของ Google เท่านั้นนะ (ผลิตภัณฑ์คู่แข่งก็ใช้อยู่เหมือนกัน) แต่มันสะดวกอย่างท่วมท้นตรงที่สามารถทำสิ่งที่ใช้งานได้พอสำหรับบรรลุเป้าหมายขึ้นมาได้อย่างรวดเร็ว จึงเป็นสภาพแวดล้อมที่ทำให้โฟกัสกับเนื้องานได้จริง

  • ฉันเคยได้ยินมาว่าที่ Google การทำงานร่วมกันส่วนใหญ่เกิดขึ้นผ่านลิสต์ (สร้าง google groups), gsheets และแชตง่าย ๆ ที่ลบอัตโนมัติแบบเรียลไทม์ เลยสงสัยว่าสุดท้ายแล้วพวกเขาไม่ได้ใช้เครื่องมือที่ดูหรูอย่าง Slack หรือ Teams จริง ๆ เหรอ น่าสนใจดี

• พอเห็นความเห็นของใครบางคนที่บอกว่า "ทำงานมา 9 เดือน" ฉันก็รู้สึกว่าไม่ว่าจะถูกหรือผิด การมีความเห็นที่ฟันธงขนาดนี้ทั้งที่ประสบการณ์ยังไม่ถึงปี ก็ค่อนข้างใจกล้าอยู่เหมือนกัน สิ่งที่ OP พลาดไปคือความจริงที่ว่า "ไม่มีอะไรถาวรเท่ากับวิธีแก้ชั่วคราว" ต่อให้ตอนนี้จะเลือกวิธีที่เร็วและเฉพาะหน้าก็เถอะ แต่มันใช้ได้ก็ต่อเมื่อคุณควบคุมวงจรชีวิตของโซลูชันนั้นได้ทั้งหมดเท่านั้น ถ้ามีคนขอให้รีบทำให้ใช้ แล้วหลังจากนั้นก็ยังค่อย ๆ เติมการใช้งานใหม่เข้าไปเรื่อย ๆ ... ฉันก็จะผลักดันให้ใช้เครื่องมือที่มี upfront cost สูงขึ้นอีกนิดอย่างหนักแน่น

  • ฉันแทบหลุดหัวเราะกับคำว่า "ทุก ๆ ไม่กี่เดือน..." ในประเด็นนั้น ผู้เขียนพูดถูกว่าหลักการใหญ่คือจัดการงานด้วยเครื่องมือที่เรียบง่าย ใช้เครื่องมือเดิมได้ และถ้ามันตอบโจทย์ได้พอ ก็นั่นแหละดีที่สุด ในโลกจริง ความต้องการทางธุรกิจเปลี่ยนใหม่ทุกไม่กี่เดือนจริง ๆ จึงอาจไม่เจอปรากฏการณ์ "ทางแก้ชั่วคราวกลายเป็นทางแก้ถาวร" ก็ได้ แต่สำหรับคนส่วนใหญ่ พอผ่านไปหลายปีแล้วก็ยังต้องมาคอยเก็บกวาดอยู่ดี และสถานการณ์แบบ "เดี๋ยวค่อยเขียนใหม่ตอนจำเป็น" แทบไม่ค่อยได้ผล ผู้เขียนเองก็ยังไม่เคยผ่านเวลาอีก 1 ปีหรือมากกว่านั้นด้วยตัวเอง

  • สำหรับฉัน ส่วนที่พูดว่า "ทุก ๆ ไม่กี่เดือน..." นี่แหละที่สะดุดใจมาก เลยสงสัยว่าพูดแบบนี้เพราะเคยผ่านมาสัก 4 รอบแล้วหรือยัง

• สำหรับคนที่เบื่อสเปรดชีตขนาดใหญ่ MS Access เคยเป็นทางออกที่ใช้ได้ดีทีเดียว มันเพิ่มความเป็นโครงสร้างและการดูแลรักษาให้กับสเปรดชีต โดยยังคงความเข้าถึงง่ายและระดับความยากในการพัฒนาไว้ได้ คุณสามารถสร้าง UI ดี ๆ ได้โดยแทบไม่ต้องมีความรู้ด้านโค้ดมากนัก ผ่านมา 20 ปีแล้ว ตอนนี้ฉันเองก็ยังไม่ค่อยรู้ว่ามีโซลูชันอะไรมาแทน Access ได้บ้าง

• ฉันเห็นด้วยกับ OP ทุกอย่าง และขอเสริมอีกข้อว่า เมื่อความต้องการซับซ้อนเกินกว่าจะจัดการใน Google Sheets ได้แล้ว Google Colab (หรือ Jupyter notebook) คือทางเลือกที่สูงขึ้นไปอีกหนึ่งขั้น ก่อนจะเริ่มสร้างแอปจริงจัง ฉันจะถามตัวเองเสมอว่า 1. ทำด้วยสเปรดชีตธรรมดาได้ไหม? 2. ถ้าไม่ได้ ทำด้วย Jupyter notebook ได้ไหม? อนึ่ง การเชื่อมต่อระหว่าง Sheets กับ Colab ก็ทำได้ดีมาก

  • ในความเห็นฉัน jupyter notebook เป็นขั้นที่ซับซ้อนกว่าการเขียน python script ธรรมดามาก python script ก็ใส่คอมเมนต์ได้อยู่แล้ว วิธีแบบ "เปิด local webserver ทิ้งไว้ แล้วรันทีละบล็อกโค้ดเพื่ออ่านคอมเมนต์" ไม่ค่อยถูกจริตเท่าไร

  • ฉันสงสัยว่าถ้าจะอัปเกรดสิ่งที่มีอยู่ใน google sheet ไปเป็น colab notebook ต้องทำอย่างไร แม้จะอ่าน raw data ของชีตด้วยแพ็กเกจ python อย่าง gspread ได้ แต่ก็ดูยากที่จะยกกราฟหรือองค์ประกอบแบบโต้ตอบเดิมมาใส่ใน jupyter notebook ได้ตรง ๆ สุดท้ายก็น่าจะต้องทำใหม่อยู่ดี

  • Google Apps Script ก็เป็นอีกทางเลือกที่ดี แค่สคริปต์ง่าย ๆ สำหรับดึงข้อมูลเข้ามาก็ทำอะไรได้เยอะพอสมควรแล้ว

• หนึ่งในปัญหาใหญ่ที่สุดของระบบอัตโนมัติทางธุรกิจคือช่องว่างระหว่างสิ่งที่เรียกว่า shadow IT, แพลตฟอร์ม low-code และโปรเจกต์ "ทางการ" เต็มรูปแบบ เส้นทางย้ายจาก "ทำคร่าว ๆ ด้วย google form" ไปสู่ "แอป react ที่มี CI/CD, tests, CDN ครบ" ยังขาดช่วงกลางที่เหมาะสม มีแต่ทางเลือกที่เป็นเหมือนกำแพงล้อมสวนของตัวเองและเข้ากันไม่ได้ทั้งนั้น

  • ฉันคิดว่าขั้นกลางนั้นก็คือโซลูชัน SAAS อย่าง ERP หรือ CRM ซึ่งส่วนใหญ่ก็มีฟังก์ชันส่งออกข้อมูลที่สมเหตุสมผลอยู่แล้วด้วย

• ฉันใช้ Google Sheets จัดการการเงินทั้งหมดของตัวเอง ฉันยังทำ Expense Tracker UI ขึ้นมาเอง และสะสมรายการค่าใช้จ่ายมากกว่า 5,000 รายการตลอดหลายปีที่ผ่านมา ช่วงหลัง ๆ ยังใช้ vibe coding ทำเครื่องมือเว็บ UI ที่ใช้ Google Service Account แล้วทำเป็น PWA เพื่อใช้บนมือถือด้วย สำหรับงานง่าย ๆ (โดยเฉพาะแอปพลิเคชันสำหรับคนเดียว) Google Sheets ก็เพียงพอแทน DB ได้สบาย

  • ฉันก็ใช้วิธีนี้มาเป็นเวลานานเหมือนกัน ลองแอปเฉพาะทางที่เกี่ยวข้องมาเยอะแล้ว แต่สุดท้ายก็มักกลับมาหาวิธีที่ตัวเองทำไว้เองอยู่ดี (น่าขำตรงที่ Microsoft Money เมื่อ 20 ปีก่อน กลับใกล้เคียงกับสิ่งที่ฉันต้องการมากกว่าแอปสมัยนี้เสียอีก) ฉันอยากเพิ่มฟีเจอร์อยู่เหมือนกัน แต่พอจะลงมือทำเองทีไร ก็มักหมดแรงกับโค้ด boilerplate ที่ต้องทำซ้ำ ๆ แล้วล้มเลิกกลางทาง ก่อนจะกลับไปใช้โซลูชันที่คุ้นเคยของตัวเองอยู่เรื่อย ๆ (อันนี้เป็นเรื่องก่อนยุค vibe coding ดังนั้นตอนนี้อาจลองใหม่ได้อีกครั้ง)