- Nino คือเวิร์กสเปซแบบโมดูลาร์สำหรับมืออาชีพที่รวมเอกสาร ชีต สไลด์ ฟอร์ม ไดรฟ์ ปฏิทิน เว็บไซต์ บล็อก แชต มีตติ้ง และอื่น ๆ ไว้ในอินเทอร์เฟซเดียว
- ข้อมูลถูกนำกลับมาใช้ซ้ำในระดับ หน้าและบล็อก โดยเชื่อมเนื้อหาเดียวกันเข้ากับหลายโฟลว์ผ่าน page sourcing, page embed, block embed และ block mirror
- รองรับการดูและแก้ไขแบบออฟไลน์, การเปิดอย่างรวดเร็วด้วยการจัดเก็บบนเครื่อง, และ การค้นหาแบบรวมศูนย์ ครอบคลุมทุกโมดูล ช่วยให้เข้าถึงข้อมูลได้ง่ายแม้มีแอปจำนวนมาก
- แม้ในแพลนฟรีก็รองรับ สมาชิกและแขกไม่จำกัด พร้อมการแสดงผู้เข้าร่วมแบบเรียลไทม์, live cursor, channel, chat, พื้นที่แชร์ภายนอก และวิดีโอคอลไม่จำกัด
- รวมทั้งเครื่องมือทำงานและความสามารถในการเผยแพร่ไว้ในที่เดียว ทั้งการเผยแพร่เว็บไซต์และบล็อก, custom domain, ย้อนกลับได้ใน 1 คลิก, SEO ด้วย meta tag, CDN ในกว่า 200 เมือง และการวิเคราะห์เมตริกฝั่งเซิร์ฟเวอร์
เวิร์กสเปซแบบโมดูลาร์และวิธีเริ่มต้น
- Nino รวมแอปงานหลายตัวไว้ในอินเทอร์เฟซที่สม่ำเสมอ และรองรับการทำงานร่วมกันได้ในระดับบล็อก
- โมดูลที่มีให้ประกอบด้วย Doc, Sheet, Slide, Form, Drive, Calendar, List, Site, Blog, Chat, Meet, Collab และอื่น ๆ
- ตัวเลือกการเริ่มต้นแบ่งเป็น Download Nino for Linux และ Use the web app
- การใช้งานพื้นฐานเน้นที่การค้นหาและเปิดข้อมูลการทำงานที่กระจายอยู่ในหลายโมดูลได้อย่างรวดเร็ว
- โหมดออฟไลน์: ดูและแก้ไขได้โดยไม่ต้องใช้อินเทอร์เน็ต
- เปิดอย่างรวดเร็ว: เข้าถึงได้ทันทีด้วยการจัดเก็บบนเครื่อง
- การค้นหาแบบรวมศูนย์: ค้นหาทุกโมดูลได้ในครั้งเดียว
โครงสร้างการนำหน้าและบล็อกกลับมาใช้ซ้ำ
- โครงสร้างหลักคือการนำหน้าและบล็อกไปใช้ซ้ำจากตำแหน่งอื่น
- Page sourcing: ดูหน้าเดียวกันในรูปแบบอื่น
- Page embed: ซิงก์หน้าไปยังอีกหน้าหนึ่ง
- Block embed: ซิงก์บล็อกไปยังอีกหน้าหนึ่ง
- Block mirror: ซิงก์บล็อกภายในหน้าเดียวกัน
- ตัวอย่างเวิร์กโฟลว์แบ่งเป็นการจัดการโปรเจกต์ การจัดการความรู้ และการจัดการฐานข้อมูล
- การจัดการโปรเจกต์ใช้ Collection, Board, Todo, Grid, Channel ร่วมกันเพื่อสร้างงาน กรองตามผู้รับผิดชอบ สร้างแดชบอร์ด และจัดการการสนทนา
- การจัดการความรู้ฝังหน้า บล็อก แผนภูมิ และบล็อกไฟล์จาก Notebook, Slide, Doc, Drive
- การจัดการฐานข้อมูลเชื่อมข้อมูลแบบสอบถาม ฟอร์ม เว็บไซต์แคมเปญ และปฏิทินแคมเปญด้วย Sheet, Form, Site, Calendar
- เวิร์กโฟลว์แบบกำหนดเองใช้ได้กับข้อความ โค้ด สมการ ไฟล์ รูปภาพ วิดีโอ เสียง ตาราง ความคิดเห็น การฝังลิงก์ การฝังหน้า การฝังบล็อก block mirror การฝังแผนที่ ปุ่ม แผนภูมิ และอื่น ๆ
ฟีเจอร์การทำงานร่วมกันและการเผยแพร่
- ฟีเจอร์ด้านการทำงานร่วมกันออกแบบมาทั้งสำหรับทีมภายในและพื้นที่ทำงานร่วมกับคนนอก
- แม้ในแพลนฟรีก็รองรับ สมาชิกและแขกไม่จำกัด
- ตรวจสอบผู้ใช้ที่อยู่บนหน้าเดียวกันได้แบบเรียลไทม์ และแก้ไขร่วมกันได้ด้วย live cursor
- Channel รองรับขนาดกลุ่มไม่จำกัด, Chat รองรับการคุยแบบ 1:1 หรือกลุ่ม, Collab คือพื้นที่แชร์ภายนอก, และ Meet รองรับวิดีโอคอลไม่จำกัด
- ฟีเจอร์การเผยแพร่ให้ โฟลว์แบบ no-code สำหรับเปิดเผยหน้าเป็นเว็บไซต์หรือบล็อก
- ใช้ Version control เพื่อย้อนกลับได้ใน 1 คลิก
- ใช้ custom domain หรือซับโดเมน nino.page ได้
- รองรับ SEO ด้วย custom meta tag และ CDN ในกว่า 200 เมือง
- รองรับหน้าแบบรวมที่มี snapshot ของบล็อกที่ฝังอยู่
- ระบบวิเคราะห์เก็บเฉพาะเมตริกฝั่งเซิร์ฟเวอร์ เพื่อป้องกันการสูญหายของข้อมูลจาก browser extension
หลักการด้านความเป็นส่วนตัว ความปลอดภัย และแผนระยะยาว
- หลักการด้านความเป็นส่วนตัวและความปลอดภัยมุ่งเน้นการไม่ติดตามการใช้งานแอป และใช้เพียง functional cookie กับการรายงานข้อผิดพลาด
- การปรับปรุงผลิตภัณฑ์อาศัยฟีดแบ็กจากผู้ใช้โดยตรง
- ทำงานบนโดเมน
.appจึงใช้เฉพาะการเชื่อมต่อ HTTPS
- แผนระยะยาวคือการสร้าง โมดูลหลายร้อยตัว สำหรับงานสายความรู้
- มีการระบุ Doc, Sheet, Slide, Form, Drive, Calendar, Collection, Notebook, Channel, Gallery, Canvas, Board, Todo, Grid, List, Site, Blog, Chat, Meet, Collab
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
การวาง โมเดลข้อมูล ให้ถูกต้องตั้งแต่แรกคือความท้าทายทางเทคนิคที่ใหญ่ที่สุด พอระบบโตแล้วจะแก้ยากอย่างยิ่ง และถ้าไม่ระวังก็อาจลงเอยด้วยคอลัมน์ JSONB กระจัดกระจาย ข้อมูลซ้ำซ้อน แถวกำพร้า และประสิทธิภาพที่ย่ำแย่
ลูกค้าน่าจะอยากเก็บรายการที่ใหญ่กว่าที่คิดไว้ใน Docs และตอนนั้นอาจอยากใส่แบบอินไลน์แทนที่จะย้ายไปเก็บในสตอเรจภายนอกอย่าง S3
Chat แทบจะต้องมีฐานข้อมูลแยกต่างหาก Discord ใช้ Scylla ส่วน Slack ใช้ Vitess บน MySQL แต่รูปแบบการเข้าถึงของแชตมีข้อกำหนดแตกต่างจากที่เก็บข้อมูลอื่นอย่างสิ้นเชิง
ถ้าทำคอนฟิกแบบ active-active ก็ควรวางแผนไว้ด้วยว่าวันหนึ่งจะเลิกใช้มันอย่างไร เพราะมันขยายไม่ได้ถ้าไม่มีฮาร์ดแวร์ราคาแพงจนหายใจไม่ออก
เรื่องนี้มาจากประสบการณ์ที่เคยทำงานเป็น DBRE ให้กับคู่แข่ง
การรองรับการเก็บข้อมูลออฟไลน์นั้นเจ๋งดี แต่ก็ให้ความรู้สึกเหมือนอาจใช้ของอย่าง Ditto [0] ถ้าจำไม่ผิด เข้าใจว่าภายในใช้ MyRocksDB และแม้จะไม่เคยมีประสบการณ์ตรง แต่รู้จักคนเก่งมาก ๆ หลายคนที่ทำงานที่ Ditto
[0]: https://ditto.live
การรวมทุกอย่างเข้าด้วยกันและความเป็นโมดูลอาจเป็นคำตอบได้ แต่ผู้คนไม่ได้ออกไปเลือกซื้อคำตอบโดยที่ยังไม่มีปัญหา “ความสับสนจากแอปจำนวนมาก” เป็นปัญหาที่นามธรรมเกินไปสำหรับคนส่วนใหญ่
ต้องทำให้ชัดก่อนว่า การแชร์ Google Docs ไปยัง Slack มีความยากลำบากหรือไม่ บริษัทต่าง ๆ ลำบากเพราะการผสาน SharePoint กับ Teams ยังไม่ดีพอหรือไม่ เครื่องมือนี้ทำได้ดีกว่าไหม คล้ายกันแต่ถูกกว่าไหม หรือเสถียรกว่าไหม
ถ้าไม่กำหนดให้ชัดตั้งแต่ต้นว่าปัญหาเฉพาะที่ผู้คนเจอจริงคืออะไร และโซลูชันแบบรวมนี้แก้มันอย่างไร ก็จะไม่มีใครสนใจ
ปัญหาใหญ่ข้อที่สองคือ ต้องมี ทีมออกแบบอินเทอร์เฟซ ที่สอดคล้องกันมากพอจะทำให้แอปต่าง ๆ เหล่านี้ใช้งานได้ดีกว่าโซลูชันเฉพาะทางแต่ละตัว ข้อเท็จจริงที่ว่าแอปสำหรับผู้ใช้ทั่วไปที่ได้รับความนิยมแทบไม่ค่อยเกิดจาก FOSS ที่ขับเคลื่อนโดยนักพัฒนา ยกเว้นโปรเจกต์ที่ดูแลโดยองค์กรซึ่งจ้างนักออกแบบมืออาชีพอย่าง Firefox, Blender, Signal แสดงให้เห็นข้อจำกัดของ UI/UX ที่มีนักพัฒนาเป็นศูนย์กลาง
พูดในฐานะคนที่ทำงานเป็นนักพัฒนาเต็มเวลามาหลายปี มีส่วนร่วมกับ FOSS หลายพันชั่วโมง แล้วจึงย้ายมาทำด้านดีไซน์
ดูเป็นตัวอย่างคลาสสิกของคำว่า “วิศวกรไม่ใช่คนดูแลผลิตภัณฑ์”
ถ้าสร้างซอฟต์แวร์ในแบบที่เปลี่ยนโมเดลข้อมูลได้ง่ายก็คงดี
เพื่อทำแบบนั้นต้องสามารถติดตาม dependency ของข้อมูลทั้งหมดในระบบได้ แต่ตอนนี้ยังไม่มีเครื่องมือที่ทำเรื่องนั้น ทุกคนเลือกฐานข้อมูลสำเร็จรูปกันทั้งนั้น แต่ไม่มีตัวไหนมีประโยชน์จริง ๆ สำหรับจุดประสงค์นี้
ตัวแอปเองเมื่อมองเผิน ๆ แล้วน่าประทับใจมาก แต่ถ้าต้องการฟีดแบ็ก จากมุมมองผลิตภัณฑ์แล้ว มันคืออะไรและสำคัญอย่างไร ยังชวนสับสนเกินไป
จากมุมมองผู้ใช้ธุรกิจ ยังไม่ชัดเจนว่าควรใช้มันอย่างไร และทำไมถึงควรสนใจ
ข้อความหน้าแรกเริ่มด้วยการไล่บรรยายฟีเจอร์อย่าง “Nino คือชุดแอปที่ทำงานร่วมกันได้ในระดับบล็อกบนอินเทอร์เฟซที่สม่ำเสมอ…” แต่เมื่อเทียบกับบริการอย่าง monday.com หรือ Asana ที่เริ่มจากกรณีการใช้งานและการนำไปใช้จริง ความต่างค่อนข้างมาก
Monday เริ่มด้วย “คุณอยากจัดการอะไร?” แล้วแสดงหมวดอย่าง Work Management, Sales CRM, Dev และเมื่อกดแต่ละรายการก็อธิบายอย่างเป็นรูปธรรมว่าจะช่วยได้อย่างไร
ผมลองใช้ระหว่างเดินเล่นประมาณ 5 นาที และลองเว็บแอป แต่ iOS Safari ไม่รองรับ พอดาวน์โหลดแอป iOS แล้วสมัครใช้งาน กลับได้แอปเปล่า ๆ โดยไม่มี onboarding, เทมเพลต/ตัวอย่าง หรือวิธีนำเข้า Google Sheets เดิมเพื่อดูว่ารองรับขนาดได้แค่ไหน
ผมลองเพิ่มแหล่งข้อมูลและฟิลด์ไม่กี่รายการ แต่ก็ยังสับสน และระหว่างนั้นก็เดินเล่นจบพอดี
https://www.youtube.com/watch?v=u4ZoJKF_VuA
แนะนำให้อ่านหนังสือด้วย
ตามทฤษฎีนี้ ลำดับการสื่อสารควรเป็น Why, How, What แต่ตอนนี้กำลังเริ่มจาก What
ผมยังไม่ได้เข้าใจแก่นของผลิตภัณฑ์ทั้งหมด แต่คิดว่าน่าจะปรับข้อความได้ประมาณว่า “อย่าเสียเวลาไปกับการค้นหาเอกสาร อีเมล และแชทในหลายระบบ อย่าจ่ายเงินให้บริการเฉพาะทาง 20 ตัวเพียงเพื่อบริหารบริษัท”
การรวมข้อมูลทั้งหมดไว้ในที่เดียวทำให้ค้นหาและแชร์ข้ามบริษัทได้ง่ายขึ้น และช่วยให้คุณสร้างเครื่องมือที่รองรับกระบวนการและวิธีคิดของตัวเองได้ โดยผสานเอกสาร แชท สเปรดชีต ฟอร์ม ฯลฯ แทนที่จะต้องปรับตัวตามแนวคิดของแอปเดิม ๆ
อาจพูดได้ว่า Nino ช่วยให้สร้างโฟลว์แบบกำหนดเองได้อย่างรวดเร็วด้วยบล็อกประกอบแบบโมดูลาร์ และทำให้มีเครื่องมือที่จำเป็นกับข้อมูลทั้งหมดอยู่ในที่เดียว
ยังให้ความรู้สึกเหมือน OLE / OpenDoc บนเดสก์ท็อป เช่น ฝังชีต Excel และฟอร์ม Access ไว้ในเอกสาร Word ถ้าทำได้จริงก็น่าจะเป็นเดโมที่น่าประทับใจมาก
อย่างไรก็ตาม การยอมรับวิสัยทัศน์แบบองค์รวมเช่นนี้ตั้งแต่แรก อาจต่างจากการเริ่มอย่างโฟกัสแล้วภายหลังถูกผลักให้ขยายขอบเขตก็ได้
หลายคนบอกว่าถ้าไม่ทำธุรกิจให้เฉพาะทางก็จะตาย แต่กลับดูเหมือนมีโอกาสดีในการจับพื้นที่ที่ยังไม่มีใครทำได้ดี เช่น ระบบจัดการเอกสารแบบบูรณาการแนวดิ่งสำหรับกรณีการใช้งานอย่าง ISO 9001
กรณีการใช้งานที่ 1 คือการจัดการเอกสาร ต้องสามารถ “เผยแพร่” เวอร์ชันเอกสาร ทำให้ดูเวอร์ชันนั้นได้ถาวร สร้างตัวระบุเอกสารโดยอัตโนมัติตามกฎการตั้งชื่อของบริษัท และแทรกลงในเอกสารโดยอัตโนมัติได้ ID เอกสารอาจมีรูปแบบอย่าง SOP-2401001
เมื่อเผยแพร่เอกสารแล้วควรเป็นแบบอ่านอย่างเดียว และควรวางผลลัพธ์อย่างสำเนา PDF ที่ส่งออกหรือสำเนาที่ลงนามแล้วไว้คู่กับเอกสารที่เผยแพร่ได้
กรณีการใช้งานที่ 2 คือ การแยกเอกสารเป็นไซโล หนึ่งในส่วนที่ยากที่สุดของการจัดการเอกสารคือการสร้างแบบฟอร์มสำหรับขั้นตอนปฏิบัติ และสอนให้คนไม่ทำให้การจัดการเอกสารของแบบฟอร์มนั้นพังหลังจากกรอกแล้ว
ผมอยากได้ไซโลที่เมื่อเริ่มกรอกแบบฟอร์มแล้ว จะสร้างสำเนาโดยอัตโนมัติ กำหนด ID เอกสารใหม่ จากนั้นรวบรวมไว้กับแบบฟอร์มชนิดเดียวกันเสมอ
ถ้าบูรณาการกับแพลตฟอร์ม automation ได้ เมื่อกรอกแบบฟอร์มก็อาจส่งอีเมลถึงใครสักคน หรือถ้าซับซ้อนกว่านั้น ก็อาจกำหนด workflow รายเอกสารและแสดงกระบวนการธุรกิจแบบภาพข้าง ๆ เอกสารได้
ความประทับใจแรกหลังลองใช้ไม่กี่นาทีคือ มันอาจมีฟังก์ชันทรงพลังจำนวนมาก แต่ในแอปและเว็บไซต์แทบไม่มี คู่มือและ onboarding เลย จึงไม่รู้ว่าควรทำอะไรและควรเรียนรู้อย่างไร
ผมติดตั้งบน Mac แล้วอยากเพิ่มชุดเรคอร์ดรายชื่อผู้ติดต่อที่มีฟิลด์พื้นฐานอย่างชื่อ เบอร์โทรศัพท์ วันเกิด และอยาก query เรคอร์ดนั้นจากโมดูลอื่น
แต่แอปไม่ได้แนะนำเลยว่าต้องทำอย่างไร เปิดขึ้นมาก็เห็นเพียงแท็บว่าง ๆ และต้องลองกดคอนโทรลต่าง ๆ เพื่อหาวิธีเพิ่มโมดูล
ผมไม่รู้ว่าถ้าจะเพิ่มเรคอร์ดที่ query ได้ควรใช้โมดูลไหน จึงลองใช้ Board
หลังเพิ่ม Board แล้ว ผมเพิ่มเรคอร์ดแรกได้ แต่ดูเหมือนไม่มีวิธีเพิ่มเรคอร์ดที่สอง มีคอลัมน์ชื่อ “None” และ “Unnamed” และรายชื่อผู้ติดต่อแรกอยู่ใน “None” ปุ่ม “+” ที่มุมใช้เพิ่มคอลัมน์ใหม่
สุดท้ายเมื่อลากเรคอร์ดจาก “None” ไปที่ “Unnamed” แล้ว “None” ก็หายไป เหลือแต่ “Unnamed” และจากนั้นจึงเพิ่มเรคอร์ดอื่นได้
ผมจะลองเล่นต่ออีกหน่อย แต่การคาดหวังให้ผู้ใช้ค้นหาโมเดลการใช้งานที่ออกแบบไว้ด้วยตัวเองมีขีดจำกัด โมดูลมีมาก แต่ไม่รู้ว่าเชื่อมโยงกันอย่างไร และตัวอย่างการตั้งค่าสำหรับทีมสมมติน่าจะช่วยได้มาก
ดูเจ๋งมากจริง ๆ
อยากลองใช้ แต่ถ้าจะทำอย่างนั้นก็ต้องแทนที่เครื่องมือและเวิร์กโฟลว์เดิม จากมุมมองผู้ใช้ ถ้าไม่สามารถมั่นใจได้ทั้งเรื่อง ความเป็นเจ้าของข้อมูล และการโฮสต์แอปพลิเคชัน ก็คงไม่อยากทำแบบนั้น
ถ้า Nino ไปได้ไม่ดีแล้วผลิตภัณฑ์ถูกยุติ ผมสงสัยว่าจะยังเข้าถึงข้อมูลแบบกรรมสิทธิ์ที่ผูกกันแน่นเหล่านี้ต่อไปได้อย่างไร อยากรู้ว่าสามารถโฮสต์เองได้ไหม ซอร์สโค้ดจะเปิดเผยหรือไม่ รูปแบบเอกสารเปิดหรือเปล่า และมีวิธีหลีกเลี่ยงความเสียหายไหมหากนำไปใช้อย่างกระตือรือร้นแล้วสุดท้ายล้มเหลว
อีกเรื่องที่สำคัญคือ ถ้าใส่ข้อมูลเข้าไปแล้วผลิตภัณฑ์ไม่เหมาะ จะเอาข้อมูลออกมาได้อย่างไร
แม้อาจเสียข้อดีเฉพาะของเครื่องมือ เช่น การผสานรวมระหว่างเอกสารในโครงสร้างแบบกราฟ แต่งานที่ทำไว้ก็ยังถูกเก็บรักษาในรูปแบบทั่วไปที่ใคร ๆ ก็นำไปใช้ได้
องค์ประกอบส่วนใหญ่ของ Nino ดูเหมือนจะมีมาตรฐานที่เป็นที่ยอมรับกันกว้างขวางและน่าจะผสานรวมได้ง่าย ดังนั้นการรับประกันแบบนั้นก็ดูเป็นไปได้
การโฮสต์เองอาจตั้งค่ายุ่งยากเกินไป แต่สงสัยว่าการให้บริการแบบ single-tenant จะช่วยได้ไหม ไม่แน่ใจเหมือนกันว่าจะสมเหตุสมผลสำหรับผู้ใช้รายบุคคลหรือเปล่า
นอกจาก HTML และ CSV แล้ว ยังมีตัวเลือกส่งออกเป็น JSON และรองรับรูปแบบอื่น ๆ เพิ่มเติมด้วย ในแง่หนึ่งมันเป็นรูปแบบเปิด (.json) แต่ต้องเพิ่มเอกสารประกอบที่เกี่ยวข้องด้วย การรองรับ PDF ก็น่าจะเข้ามาในสักวันหนึ่ง
แน่นอนว่าเป็นผลงานที่น่าประทับใจมาก อาจใกล้เคียงกับงานของนักพัฒนาคนเดียว และคงใช้ความพยายามมหาศาล
ถ้าจะให้ฟีดแบ็ก ควรเริ่มจากทำให้ชัดก่อนว่า ลูกค้าคือใคร ต้องอธิบายได้ว่าวันหนึ่ง ๆ ของพวกเขาเป็นอย่างไร และ Nino ช่วยให้ทำงานได้ดีขึ้น เร็วขึ้น หรือถูกลงอย่างไร
ต้องระบุให้ได้ว่าปัญหา 5 อันดับแรกที่พวกเขาเจอคืออะไร และแสดงให้เห็นอย่างเป็นรูปธรรมว่า Nino ดีกว่าคู่แข่งตรงไหนอย่างชัดเจน การแสดงเวิร์กโฟลว์เป็นเรื่องสำคัญ
พวกเขาทำงานที่ไหน ร่วมงานกับใคร และร่วมกันทำอะไร ก็ควรเปรียบเทียบเคียงข้างกับเครื่องมือเดิมในลักษณะเดียวกัน เพื่อแสดงว่าเหตุใด Nino จึงดีกว่า
สุดท้าย อย่าประเมินต่ำไปเด็ดขาดว่าการทำให้ผู้คนเปลี่ยนจากวิธีที่ใช้อยู่ตอนนี้นั้นยากแค่ไหน ตอนนี้ไม่ใช่ปี 1990 แล้ว ผู้คนใช้เครื่องมือแก้ปัญหาของคนทำงานสายความรู้มาหลายสิบปีแล้ว ต้องมีเหตุผลว่าทำไมพวกเขาควรย้ายมาใช้
ไม่แน่ใจว่า “ปัญหาแอปสับสนวุ่นวาย” มีอยู่จริงหรือไม่ ในบริษัทหรือเวิร์กโฟลว์งานที่ผมเจอมา ก็มีชุดแอปที่แก้แต่ละกรณีใช้งานอยู่แล้ว
เช่น ตอนทำงานเป็นหัวหน้าฝ่าย developer relations ที่บริษัทก่อน ใช้ผลิตภัณฑ์ของ Atlassian สำหรับเอกสารภายในและการติดตามงาน ใช้ Google Docs และ Sheets สำหรับการเขียนร่วมกับทีมภายนอก และใช้ GitHub กับ Markdown สำหรับสร้างเอกสารภายนอก
ทั้งหมดเป็นข้อความก็จริง แต่เวิร์กโฟลว์ต่างกัน และข้อกำหนดอย่างสิทธิ์การเข้าถึงก็ต่างกัน สุดท้ายเราก็หาเครื่องมือที่เหมาะกับแต่ละงานได้
ขอเอาใจช่วยความพยายามนี้ แต่หวังว่ากำลังมองหาปัญหาที่เฉพาะเจาะจงกว่า ไม่ใช่ “แอปสับสนวุ่นวาย”
ยินดีกับการเปิดตัวครับ ดูดีมากจริง ๆ และผมคิดว่า ปัญหาแอปสับสนวุ่นวาย ของคนทำงานสายผลิตภาพเป็นปัญหาจริง และเป็นปัญหาที่แก้ได้
ผมเองก็กำลังสร้างสิ่งที่คล้ายกันอยู่ เริ่มทำหลังจากทำงานออฟฟิศแบบ “เดิมพันสูง” ที่ต้องใช้หลายแอปทุกวันมานานกว่า 10 ปี
ยังอยู่ช่วงต้น และมุมที่เข้าหาก็ต่างกันเล็กน้อย แต่มีส่วนที่ทับซ้อนกันระหว่างสองวิสัยทัศน์ ผมเน้นชุดแอปที่น้อยกว่าแต่ทำให้ฟีเจอร์แน่นขึ้น และพยายามทำให้ฟีเจอร์เทียบเท่ากับเจ้าตลาดเดิมพร้อมเพิ่มฟีเจอร์ของตัวเองเข้าไปด้วย เลยใช้เวลาพอสมควรกว่าจะทำออกมาให้ดี
อยากรู้ว่า Nino จะพัฒนาไปอย่างไร และถ้าภายหลังผมมีอะไรที่พอจะโชว์ได้ ก็อยากติดต่อกัน
เคยสร้างสิ่งที่คล้ายกันมาก่อน ของผมเป็นแบบเว็บ: https://github.com/GWBasic/ObjectCloud
ถ้าจะบอกตัวเองในวัยหนุ่ม ผมคงบอกให้อ่าน แหล่งข้อมูลของ YC เกี่ยวกับการเริ่มธุรกิจให้มากขึ้น ผมสร้างสิ่งที่คิดว่ามีความจำเป็น แต่ควรทำซ้ำและปรับปรุงจากความต้องการของลูกค้าจริงให้มากกว่านั้นมาก
กล่าวคือ ควรหาลูกค้าสักสองสามรายที่ต้องการการผสานรวมอย่างแนบแน่นระหว่างกรณีใช้งานเหล่านี้ แล้วให้ความต้องการของพวกเขาเป็นตัวขับเคลื่อนการพัฒนา
เหตุผลคือมีแอปพลิเคชันจำนวนมากที่ทำหน้าที่เดียวกันอยู่แล้ว MS Office, Google Drive ฯลฯ มีความสมบูรณ์แล้ว และตลาดโดยรวมก็เข้าใจดี
แนะนำให้หาลูกค้าสักสองสามรายที่ติดขัดเพราะการทำงานร่วมกันระหว่างแอปพลิเคชันหรือกรณีใช้งานตั้งแต่ 3 อย่างขึ้นไปยังทำได้ไม่ดี แล้วโฟกัสที่กรณีใช้งานของพวกเขา
กว่าจะเติบโตเต็มที่เท่า MS Office หรือ Google Drive อาจต้องใช้เวลา 15 ปีขึ้นไป แต่ถ้าแก้ความต้องการที่เฉพาะเจาะจงและเร่งด่วนของนิชหนึ่งได้ ลูกค้าจะไม่สนใจเรื่องนั้น เพราะพวกเขาดำเนินธุรกิจไม่ได้หากไม่มีคุณ
ความปลอดภัยและความเป็นส่วนตัว เป็นจุดขายที่ขายยาก มีคนสนใจสองเรื่องนี้น้อยกว่าที่คิด และแพลตฟอร์มเดิม ๆ ก็มีฟีเจอร์มากกว่าที่คนที่สนใจอยากยอมรับอยู่มาก
อีกอย่าง พิทช์แนว “มีเครื่องมือมากเกินไป” ฟังดูเหมือนการบ่นยืดยาวที่ไม่มั่นคงนัก การอ้างว่าแค่ข้อเท็จจริงที่ว่ามีเครื่องมือหลากหลายอยู่นั้นเป็นเรื่องไม่สะดวก ทนต่อคำโต้แย้งว่า “งั้นก็ไม่ต้องใช้ทั้งหมดสิ” ได้ยาก จึงน่าจะต้องจับถ้อยคำให้ดีกว่านี้
แทนที่จะทำแบบนั้น ควรโฟกัสที่ความสะดวกและการผสานรวมภายในแพลตฟอร์มจะดีกว่า นั่นคือส่วนที่เพิ่มคุณค่าจริง ๆ
ขอให้โชคดี
ส่วนข้อที่สองพูดถูก การสื่อสารของผมไม่ดีเอง ขอบคุณสำหรับฟีดแบ็ก