บทความนี้จัดทำขึ้นจากการบรรยายของฉันในงานพบปะกลุ่มสถาปัตยกรรมพร้อมใช้งานสูง ตั้งแต่เด็กฉันเป็นคนพูดน้อย ทุกครั้งที่ต้องบรรยายต่อสาธารณะฉันรู้สึกประหม่า ไม่สามารถแสดงความคิดของฉันได้อย่างสมบูรณ์ ฉันอิจฉาคนที่สามารถพูดคุยได้อย่างคล่องแคล่วเมื่อบรรยาย ดังนั้นฉันจึงจัดระเบียบความคิดของฉันเป็นบทความเพื่อแสดงออก
ส่วนตัวฉันเป็นมือใหม่ในด้านโอเพนซอร์ส ต้นปี 2016 ฉันเปิดตัวโครงการโอเพนซอร์สหนึ่งชื่อ go-commons-pool เป็น object pool ทั่วไปของ golang ตอนนี้มีเกือบ 200 ดาว ในด้านการเริ่มต้นธุรกิจก็ถือเป็นมือใหม่เช่นกัน ต้นปี 2015 ฉันเริ่มเป็นหุ้นส่วนด้านเทคโนโลยีเพื่อเริ่มต้นธุรกิจเครื่องมือสื่อสารและทำงานร่วมกันในทีม ในหนึ่งปีฉันทำงานพัฒนาพร้อมกับทำงานด้านผลิตภัณฑ์บ้าง และทำงานด้านปฏิบัติการบ้าง รู้สึกว่าการเริ่มต้นธุรกิจและโอเพนซอร์สมีจุดร่วมกันมาก จึงอยากแบ่งปันความคิดเห็นกับทุกคน คนก่อนหน้าพูดเรื่องเนื้อหาเยอะ โครงการของฉันเทคโนโลยีค่อนข้างง่าย ดังนั้นฉันทำตามคำแนะนำของ Tim ใส่ซุปไก่เยอะขึ้น :)
ไม่ว่าจะเป็นการเริ่มต้นธุรกิจหรือโอเพนซอร์ส คำถามแรกที่ต้องเผชิญคือทำอะไร? ความคิดที่จะทำอะไรมาจากไหน? ไม่พ้นสองทางนี้:
- การสังเกต สังเกตคนรอบข้าง สังเกตชีวิตและงานของตัวเอง สังเกตนิสัยของทุกคน ดูว่ายังมีที่ต้องปรับปรุงที่ไหน ดูว่ามีจุดเจ็บที่ไหน เช่น ความคิดเรื่อง pool นี้มาจากมีคนถามในกลุ่ม ฉันค้นหาแล้วพบว่า golang ไม่มี object pool ทั่วไปที่ใช้งานได้ดี หรือเช่นมีคนพบว่าการเรียกแท็กซี่ยากขนาดนี้ ยืนข้างถนนนานก็ไม่มา จึงมี Uber มีคนอยากซิงค์ไฟล์ระหว่างอุปกรณ์หลายเครื่อง จึงมี Dropbox มีคนพบว่าทำงานซ้ำซากตลอด จึงมีเฟรมเวิร์กต่างๆ
- การยืมความคิด ดูพื้นที่หรือสาขาที่ก้าวหน้าว่ามีอะไรที่ยืมมาได้ไหม นำผลงานจากพื้นที่หรือสาขาที่ก้าวหน้าไปใช้ในพื้นที่หรือสาขาที่ล้าหลัง Copy To China ที่ค่อนข้างฮอตเป็นโมเดลแบบนี้ ใช้แนวโน้มการพัฒนาของพื้นที่ที่ก้าวหน้ามาทำนายแนวโน้มอนาคตของพื้นที่ที่ล้าหลัง วันนั้น indigo ในกลุ่มสถาปัตยกรรมพร้อมใช้งานสูงแชร์ว่า ใช้การพัฒนาทางเศรษฐกิจและสังคมของญี่ปุ่นมาทำนายแนวโน้มของจีนก็เป็นหลักการเดียวกัน ฉันทำ pool นี้ก็วิเคราะห์จากสถานการณ์ของชุมชน java คิดว่า golang จะมีบทบาทมากในฝั่งเซิร์ฟเวอร์ในอนาคต ต้องมี object pool ที่แข็งแกร่งไว้ใช้เป็น connection pool และอื่นๆ
คิดว่าจะทำอะไรแล้ว ขั้นต่อไปคือทำอย่างไร ขั้นตอนนี้ดูเหมือนการเริ่มต้นธุรกิจและโอเพนซอร์สจะต่างกันมาก แต่จริงๆ แล้วมีจุดร่วม ประเด็นสำคัญคือการประเมินและจัดสรรทรัพยากรสำหรับ ‘เรื่อง’ ทรัพยากรรวมถึงเงินและเวลา หากเรื่องที่คิดไว้ใหญ่เกินไป ไม่สอดคล้องกับทรัพยากรจริง ผลลัพธ์อาจเป็นธุรกิจล้มเหลว หรือโครงการโอเพนซอร์สสร้าง repo เขียน readme แล้วก็จบ
หลังจากทำโครงการเสร็จแล้ว ขั้นต่อไปคือทำอย่างไรให้กลุ่มผู้ใช้ของคุณรู้ หรือที่เรียกว่า ‘แนะนำ’ ในปัจจุบัน Huang Dongxu ของ PingCAP ก็พูดถึงวิธีการตลาดและช่องทางของพวกเขาเมื่อกี้ หัวใจของขั้นตอนนี้คือคุณต้องรู้ว่าความสนใจของกลุ่มผู้ใช้ของคุณอยู่ที่ไหน จะเข้าถึงผู้ใช้ของคุณด้วยต้นทุนต่ำสุดได้อย่างไร โครงการโอเพนซอร์สอาจผ่านชุมชนโอเพนซอร์สต่างๆ หรือชุมชนคนเทคโนโลยี เครือข่ายสังคมของตัวเอง การประชุมเทคโนโลยี และวิธีอื่นๆ
หลังจากเข้าถึงผู้ใช้เบื้องต้นเสร็จแล้ว ผู้ใช้รู้จักโครงการของคุณแล้ว บางคนอาจกดดาว คนเหล่านี้เป็นผู้ใช้ที่มีศักยภาพ อีกส่วนหนึ่ง fork ไปแล้ว น่าจะเตรียมใช้งานหรือพัฒนาต่อ แล้วจะรักษาผู้ใช้ปัจจุบันและดึงดูดผู้ใช้ใหม่ได้อย่างไร? นี่คือสิ่งที่ต้องพิจารณาในขั้นตอนนี้ รวมถึงแต่ไม่จำกัด:
- ปรับปรุงเอกสาร สอนผู้ใช้วิธีใช้ อย่ารำคาญที่ผู้ใช้ ‘โง่’
- ตอบสนองข้อเสนอแนะของผู้ใช้ จัดการ issue สำหรับผลิตภัณฑ์ธุรกิจต้องมีระบบบริการลูกค้า
ค่อยๆ มีผู้ใช้มากขึ้น แล้วก่อตั้งชุมชน มีแบรนด์ของตัวเอง ขั้นตอนนี้ เครื่องมือเล็กๆ อย่างที่ฉันทำไม่ถึง แต่เช่น TiDB ของ PingCAP เฟรมเวิร์ก beego ของ Xie Mengjun ได้ก่อตั้งชุมชนและแบรนด์ของตัวเองแล้ว
สรุปจุดสำคัญในกระบวนการนี้:
- ไอเดียไม่ได้ถูกนามธรรมไว้ดีพอ จริงๆ แล้วเครื่องมือและผลิตภัณฑ์ทั้งหมดทำการนามธรรมหนึ่งอย่าง นามธรรมความต้องการของผู้ใช้ เช่นตัวอย่างคลาสสิก ถามผู้ใช้ว่าต้องการอะไร ผู้ใช้ตอบว่าต้องการม้าที่เร็วกว่า ไม่ใช่รถยนต์ รถยนต์คือการนามธรรมความต้องการการเดินทางของผู้ใช้ แต่จะทำนามธรรมนี้อย่างไร? ฉันสรุปว่ามีสามระดับ
- หลักการ DRY อย่าทำซ้ำตัวเอง พบได้บ่อยในมาตรฐานโค้ด แนะนำว่าอย่าคัดลอกวางตามใจชอบ แต่ต้องทำนามธรรมบ้าง แต่จริงๆ แล้วฟีเจอร์ขั้นสูงทุกอย่างของภาษา ออบเจกต์โอเรียนเต็ด โมดูลาร์ เครื่องมือสร้างโค้ด เฟรมเวิร์กต่างๆ ล้วนแก้ปัญหานี้ กล่าวคือ หากคุณพบว่าคุณทำงานซ้ำซากมาก แสดงว่าอาจมีโอกาสนามธรรมออกมาเป็นเครื่องมือได้
- อย่าประดิษฐ์ล้อใหม่ หลักการนี้ดูเหมือนจะมีข้อโต้แย้ง แต่ฉันคิดว่าข้อโต้แย้งเกิดจากไม่เข้าใจความแตกต่างระหว่าง ‘ประดิษฐ์’ และ ‘สร้าง’ อย่าประดิษฐ์ล้อใหม่ แต่คุณสามารถสร้างล้อใหม่ หรือปรับปรุงล้อที่มีอยู่ หลักการนี้บอกว่าอย่าทำซ้ำงานที่คนอื่นทำเสร็จแล้ว อย่าทำงานโดยไม่ศึกษา ต้องปรับปรุงจากงานของคนก่อน ฉันคิดว่าคนที่ประดิษฐ์ล้อเป็นคนยิ่งใหญ่มาก และยากมาก มีสถานะทางประวัติศาสตร์เทียบได้กับคนที่ประดิษฐ์การจุดไฟ หลังจากมีล้อแล้ว เครื่องมือที่มนุษย์ใช้และเครื่องมือที่สัตว์ใช้จึงแตกต่างกันโดยพื้นฐาน
- ข้างต้นเราทำได้ว่าอย่าทำซ้ำตัวเอง และอย่าทำซ้ำคนอื่น ระดับที่สามคือ ‘อย่าให้คนอื่นทำซ้ำคุณ’ แบ่งปันเครื่องมือ เฟรมเวิร์ก นามธรรมของคุณออกไป เป็นผลิตภัณฑ์โอเพนซอร์สหรือบริการ SaaS ให้คนอื่นไม่ต้องทำซ้ำงานที่คุณทำเสร็จแล้ว
- พัฒนาช้า คู่แข่งปรากฏ หรือฟีเจอร์อ่อนกว่าคู่แข่ง
- โปรโมทไม่ดี คนไม่รู้จัก ถูกคนที่มาทีหลังแซง
- ทำออกมาแล้วไม่มีความต้องการจริง เช่น pool มีคนคิดว่าใน go ใช้ channel จำลองก็ง่ายแล้ว ไม่จำเป็นต้องใช้ pool ที่ซับซ้อน เช่นโครงการ Copy To China หลายโครงการ พบว่าไม่เหมาะกับสภาพแวดล้อมในจีน
- หลังจากเปิดซอร์สแล้วไม่ดูแล หมดความกระตือรือร้น ไม่ตอบข้อเสนอแนะของผู้ใช้ สุดท้ายผู้ใช้ก็หายไปหมด โครงการโอเพนซอร์สซอมบี้หลายโครงการเป็นแบบนี้
ดังนั้น ฉันคิดว่าวิศวกรที่อยากเริ่มต้นธุรกิจ สามารถเริ่มจากโอเพนซอร์สก่อน ใช้โอเพนซอร์สเป็นการซ้อมเริ่มต้นธุรกิจหนึ่งครั้ง สัมผัสกระบวนการทั้งหมดตั้งแต่คิด พัฒนา โปรโมท จะได้ประสบการณ์กับจุดสำคัญในกระบวนการเริ่มต้นธุรกิจ สามารถประเมินจุดแข็งและจุดอ่อนของตัวเอง ในเมื่อเป็นวิศวกร เวลาพัฒนาควบคุมเองได้ ผู้ใช้ที่หันไปหาก็เป็นวิศวกร ปัญหาที่ต้องแก้ก็เป็นสาขาที่คุ้นเคย ชุมชนที่ต้องเผยแพร่ก็เป็นชุมชนที่คุ้นเคย ในสภาพที่มีความได้เปรียบทุกอย่างยังเจอปัญหา ลองนึกภาพว่าถ้าเปลี่ยนไปสาขาที่ไม่คุ้นเคย ผู้ใช้ที่ไม่คุ้นเคย ชุมชนที่ไม่คุ้นเคย ปัญหาจะใหญ่ขนาดไหน?
อีกเรื่องหนึ่งเกี่ยวกับมุมมองการเริ่มต้นธุรกิจของคนเทคโนโลยี ฉันคิดว่าบทกวีของ Wang Anshi ดีมาก ‘น้ำในแม่น้ำอุ่นเป็ดรู้ก่อน’ วิศวกรที่เขียนโค้ดอยู่แนวหน้าเป็นเป็ดในน้ำ น้ำในแม่น้ำเปลี่ยนแปลงเราจะรู้ก่อนแน่นอน ในด้านนี้มีความได้เปรียบ ถ้าคุณเลื่อนตำแหน่งสูงขึ้น ไม่เขียนโค้ดแล้ว วิ่งขึ้นไปบนฝั่งแล้ว ก็อาจจะรู้สึกการเปลี่ยนแปลงของน้ำในแม่น้ำไม่ได้
โปรดระบุแหล่งที่มา: ความสัมพันธ์นักพัฒนา »
