เรื่องราว "Just Ship It" ที่เศร้าที่สุด (2020)

 (kitze.io)
1 คะแนน โดย GN⁺ 2024-07-05 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • โปรเจกต์ข้างที่เริ่มในปี 2018 มี MVP เสร็จภายในไม่กี่วัน แต่ระหว่างที่เลื่อนเวลาเปิดตัวออกไปเรื่อย ๆ ก็กลายเป็นโปรเจกต์ที่ไม่เคยปล่อยนาน 2 ปี
  • ใจกลางของความล่าช้าคือการตัดสินใจซ้ำ ๆ ว่า “ขออีกอย่างเดียว” และขอบเขตของผลิตภัณฑ์ก็ขยายขึ้นหลังจากไปเรียนรู้ React Native และ Expo
  • แอปคู่แข่งที่แก้ปัญหาเดียวกันนั้นช้าและมีบั๊กเหมือนกัน แต่เปิดตัวไปแล้ว ได้ผู้ใช้และชุมชนแล้ว และกำลังปรับปรุงทุกสัปดาห์
  • หลังจบช่วงทดลองใช้ 30 วัน ผู้เขียนก็จ่ายเงินให้แอปคู่แข่ง ขณะที่แอปของตัวเองซึ่งเหลืออยู่แค่ในฮาร์ดไดรฟ์ก็กลายเป็น ผลิตภัณฑ์ที่ตายไปแล้วโดยพฤตินัย
  • ในอัปเดตปี 2024 ผู้เขียนระบุว่าในที่สุดก็เปิดตัวแอปเพิ่มประสิทธิภาพ Benji ในปี 2022 และข้อสรุปก็คือ แม้จะฟังเชย แต่ก็เอนเอียงไปทางให้ปล่อยออกมาก่อน

ทำไม MVP ที่ทำเสร็จในไม่กี่วันถึงปล่อยไม่ได้อยู่ 2 ปี

  • เริ่มพัฒนาแอปเมื่อวันที่ 1 มกราคม 2018 และ MVP ก็พร้อมภายในไม่กี่วัน
  • แม้เวอร์ชันอัลฟา 0.0.1 จะอยู่ในสภาพที่ปล่อยได้ แต่ก็เลื่อนการเปิดตัวทุกครั้งด้วยเหตุผลว่า “ขอฟีเจอร์อีกอย่างเดียว”, “ขออีกหน้าจอเดียว”
  • เมื่อคิดว่า “ถ้าไม่มีแอปมือถือเนทีฟที่ดี คนก็คงไม่ใช้” จึงไปเรียน React Native และตัดสินใจใช้เวลาเพิ่มอีกหลายเดือน
  • หลังจากนั้นตลอด 2 ปี ก็วนเวียนอยู่กับแพลตฟอร์มเว็บ, React Native, Expo, GraphQL, การกังวลเรื่อง tech stack, การเปลี่ยนไปทำโปรเจกต์อื่น, การปล่อยแอปอื่นอย่าง Sizzy, การหมดไฟและกลับมามีไฟอีกครั้ง
  • สุดท้ายก็หยุดพัฒนา และเลิกคิดว่าจะปล่อยแอปนั้นด้วย

ช่วงเวลาที่เจอแอปซึ่งแก้ปัญหาเดียวกัน

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

แอปคู่แข่งที่ให้ความสำคัญกับการเปิดตัวก่อนความสมบูรณ์แบบ

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

บทเรียนที่เหลืออยู่หลังจากการจ่ายเงิน

  • หลังจบช่วงทดลองใช้ 30 วัน ผู้เขียนกรอกข้อมูลบัตรเครดิต และกลายเป็นไม่ใช่แค่สมาชิกแบบชำระเงิน แต่เป็นแฟนของผลิตภัณฑ์นั้น
  • การแจ้งเตือนการชำระเงินกลายเป็นประสบการณ์ที่คอยย้ำเตือนซ้ำ ๆ ว่าตัวเองไม่เคยเปิดตัวสิ่งที่ทำไว้
  • ผู้เขียนยอมรับว่า ณ จุดนั้น แอปของตัวเองได้ตายลงอย่างเป็นทางการแล้ว
  • คนส่วนใหญ่ที่อยู่ในสถานการณ์เดียวกันอาจเพิ่งเริ่มโปรเจกต์มาได้ไม่กี่สัปดาห์ จึงควรหลีกเลี่ยงความผิดพลาดแบบเดียวกัน
  • หาก “ขออีกอย่างเดียว” หมายถึงการกลับไปสร้างระบบยืนยันตัวตน, ระบบชำระเงิน, หรือ boilerplate ใหม่อีกครั้ง นั่นคือกับดัก และต่อมาเพื่อช่วยลดกับดักนี้ ผู้เขียนจึงสร้าง Zero To Shipped

อัปเดตปี 2024: ในที่สุดก็เปิดตัว Benji

  • ตามอัปเดตปี 2024 ในที่สุดผู้เขียนก็เปิดตัว Benji ในปี 2022
  • เหตุผลที่เปิดตัวก็เพราะไม่มีแอปคู่แข่งตัวไหนเข้าใกล้วิสัยทัศน์ของตัวเองได้มากพอ
  • แอปที่ต้องการคือรูปแบบที่รวม Todos, Habits, Planner, Goals, Pomodoros, Meal tracking, Fasting, Hydration, Packing, Trips และอื่น ๆ เข้าไว้ด้วยกัน
  • ใน Benji ยังมี ไทม์ไลน์สาธารณะ ที่ผู้คนแชร์ความสำเร็จและความก้าวหน้าในการปรับปรุงชีวิตของตัวเอง
  • ถึงจะฟังดูเชย ก็ขอให้ตั้งสติ แล้วก็ยังต้อง Just Ship It อยู่ดี

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-07-05
ความคิดเห็นบน Hacker News

  • เรื่องแบบ “จบลงเพราะตอนนั้นไม่ได้ปล่อยออกไปเลย” มีข้อสังเกตสำคัญอยู่: บางครั้ง คุณค่าของแอป ที่กำลังทำอยู่ก็อยู่ที่รายละเอียดทางเทคนิคซึ่งเร่งไม่ได้ และในกรณีแบบนั้น “ปล่อยไปเลย” ไม่ใช่คำตอบ
    งานของวิศวกร/สถาปนิกซอฟต์แวร์ส่วนหนึ่งก็คือการต้านแรงกดดันจากผู้บริหารที่บอกว่า “ปล่อยออกไปเถอะ” ให้ได้มากที่สุด ถ้าไม่ใช่ผลิตภัณฑ์ที่คุณเป็นเจ้าของเอง และไม่ใช่สถานการณ์ที่การปล่อยออกไปเป็นประโยชน์กับตัวคุณเอง ถ้าการใช้เวลาเพิ่มทำให้ได้ผลลัพธ์ที่เป็นมืออาชีพกว่า ก็ควรใช้เวลานั้น คุณไม่ใช่เครื่องจักรอัตโนมัติที่รับตั๋ว JIRA แล้วรีบพ่นโค้ดลวก ๆ ออกมาให้เร็วที่สุด และถ้าทำงานแบบนั้นต่อไปเรื่อย ๆ ก็จะถูกสูบพลังใจจนสุดท้ายเกิดภาวะหมดไฟ
    ถ้าคุณไม่มีหุ้นในบริษัท งานของคุณไม่ใช่การทำให้กำไรบริษัทสูงสุด แต่คือการสร้าง ซอฟต์แวร์ที่ดี ซึ่งเอาไปใส่เรซูเม่แล้วไม่อาย ความโล่งใจจากการทำเดดไลน์ตามอำเภอใจได้อีกครั้งเป็นเพียงแรงจูงใจเชิงลบระยะสั้นและอยู่ได้ไม่นาน ดังนั้นควรต้านแรงกดดันจากเบื้องบนและทำให้ถูกต้อง ต่อให้ถูกไล่ออก ทุกวันนี้การย้ายงานก็เป็นทางไต่ขึ้นอยู่แล้ว

    • แนวคิดว่า “ถ้าไม่มีหุ้นบริษัท ก็ไม่จำเป็นต้องสนใจความสามารถในการทำกำไร” ดูเป็นทัศนคติที่แย่ซึ่งเผยให้เห็นว่า ความเป็นซีเนียร์ ของนักพัฒนาซอฟต์แวร์ยังไม่พอ ถ้าไม่ใช่องค์กรไม่แสวงหากำไร สมาชิกทุกคนในบริษัทก็ควรมีส่วนช่วยเรื่องความสามารถในการทำกำไร
      อย่างไรก็ตาม ความสามารถในการทำกำไรไม่ได้มีความหมายเดียวกับ “ปล่อยไปเลย” ถ้าบริษัทสับสนสองเรื่องนี้บ่อย ๆ ก็เป็นสัญญาณว่าฝั่งผู้บริหารยังขาดความเป็นซีเนียร์
      งานของนักพัฒนาใกล้เคียงกับการสร้าง ผลิตภัณฑ์ที่ดี มากกว่าการสร้าง “ซอฟต์แวร์ที่ดี” ผลิตภัณฑ์ที่ดีมักต้องการซอฟต์แวร์ที่ดี แต่ก็ไม่เสมอไป และมีหลายกรณีที่เบื้องหลังผลิตภัณฑ์ยอดเยี่ยมคือซอฟต์แวร์ที่ย่ำแย่ ความตึงเครียดระหว่างผลิตภัณฑ์ ฝ่ายขาย และฝ่ายพัฒนาควรนำไปสู่การประนีประนอมที่ทำให้คุณค่าระยะสั้น ระยะกลาง และระยะยาวสูงสุด นักพัฒนาควรเข้าใจว่าอะไรทำแบบลวก ๆ ได้ บริษัทมีลำดับความสำคัญอย่างไร และเมื่อใดไม่ควรประนีประนอมแต่ต้องสร้างซอฟต์แวร์ที่ดี
      นักพัฒนาที่ไม่ยอมประนีประนอมเรื่องคุณภาพซอฟต์แวร์เลย จะเสียอำนาจต่อรองแม้ในช่วงเวลาที่ไม่ควรประนีประนอมจริง ๆ
    • ต้องดูตั้งแต่ต้นว่าพัฒนาไปเพื่ออะไร อาจเป็นงานอดิเรก ความสนุก หรือเพื่อความงามของโค้ดก็ได้ แต่ส่วนใหญ่แล้วคือการให้ซอฟต์แวร์ทำงานบางอย่างที่ใครสักคนต้องการ
      ดังนั้นสิ่งสำคัญอันดับแรกคือสร้างคุณค่าให้ผู้ใช้ และพัฒนาอย่างมีประสิทธิภาพเท่าที่ทำได้ ซอฟต์แวร์ที่ไม่มีใครใช้จะมีความหมายอะไร
      งานของนักพัฒนาไม่ใช่การสร้างซอฟต์แวร์ที่ดี แต่คือการส่งมอบ คุณค่าให้ผู้ใช้ จากที่เห็นในอาชีพ กลับพบว่านักพัฒนามักเมากับการออกแบบเกินจำเป็น ขยายโค้ดด้วยฟีเจอร์ที่ไม่มีใครต้องการ และเพิ่มโค้ดเพื่อเตรียมรับการพัฒนาในอนาคตที่ยังไม่มาถึงมากกว่า ดังนั้นโจทย์ยากคือการคงความมินิมัลไว้ และบทความต้นฉบับก็ดูเหมือนพูดเรื่องนั้น
    • คอมเมนต์ทั้งหมดนี้อ่านแล้วเหมือนคนที่มองความสัมพันธ์กับเพื่อนร่วมงานแบบเป็นศัตรูล้วน ๆ และแทบไม่มีความไว้วางใจเลย คงเหนื่อยน่าดู
    • ผมเคยเป็นหนึ่งในพนักงานยุคแรกของสตาร์ทอัพ ถ้าเราไม่ประนีประนอม บริษัทคงมีโอกาสสูงที่จะไม่มีอยู่ในวันนี้ แนวทางแบบนั้นใช้ได้กับบริษัทใหญ่ที่ตั้งตัวแล้ว ซึ่งอิทธิพลของทีมต่อผลลัพธ์มีจำกัดเท่านั้น
      ในบริษัทขนาดเล็กถึงกลาง จำเป็นต้องมีการประนีประนอมอย่างแน่นอน และการเลือกทางที่นำไปสู่ ผลลัพธ์ทางธุรกิจ ที่ดีที่สุดก็เป็นงานของมืออาชีพเช่นกัน
      นักพัฒนาจำนวนมากถูก “ปกป้อง” โดยผู้จัดการหลายชั้น PM และดีไซเนอร์ จึงเชื่อมโยงกับฝั่งธุรกิจค่อนข้างอ่อน การปล่อยผลิตภัณฑ์เร็วทำให้ได้ฟีดแบ็กเร็ว และมีโอกาสประเมินว่าการนำไปใช้จริงตรงกับสมมติฐานหรือไม่ มันเครียดน้อยกว่าการปล่อยโซลูชันที่ “สมบูรณ์แบบ” ภายใต้แรงกดดันแล้วต้องเขียนใหม่
      งานที่ผมทำในฐานะนักพัฒนาในที่ทำงานปัจจุบันคือการลดความซับซ้อน และทำให้ PM กับดีไซเนอร์เฉือนแผนตั้งต้นให้เหลือน้อยที่สุด แบบนั้นเดดไลน์ตามอำเภอใจก็เครียดน้อยลง และผลกระทบจากความล่าช้าก็น้อยลงด้วย
    • ฟังเหมือนการเสียดสี มีประโยคชวนสะดุดใจต่อเนื่องกันอย่าง “ถ้าไม่ใช่งานของตัวเองก็ทำสิ่งที่ผิด แต่ถ้าเป็นงานของตัวเองก็รีบปล่อย” และ “งานคือการได้ใส่ลงเรซูเม่แล้วรู้สึกดี”
      ส่วนที่มีคุณค่าก็คงแค่ไม่ควรยึดติดกับที่ทำงานใดที่หนึ่งมากเกินไป และไม่ต้องกังวลเรื่องถูกไล่ออกมากนัก แต่ผมว่าคำอธิบายเหตุผลก็ผิดอยู่ดี น่าประหลาดใจที่อาจมีคนทัศนคติเป็นศัตรูแบบนี้ทำงานอยู่ด้วยจริง ๆ
      บางคนดูเหมือนชอบใช้ชีวิตค้างอยู่ในช่องที่ผิดของทฤษฎีเกม

  • ตอนอ่านส่วนที่ว่า “ผมสงสัยว่าใครแชร์วิดีโอแอปของผมให้คนพวกนี้ เพราะพวกเขากำลังแก้ปัญหาเดียวกันแบบเป๊ะ ๆ” ก็ทำให้นึกถึงคนที่ผมเคยเจอซึ่งมี ไอเดียแอป ที่ใช้ได้คนหนึ่ง
    เขาขอให้ผมช่วยเขียนโค้ดแอปให้ฟรี แล้วจะแบ่งรายได้กัน พอถามว่าเขาจะมีส่วนร่วมอะไร เขาตอบว่าจะ “บริหาร” บริษัท และส่วนแบ่ง 50% เป็นของเขา “เพราะเป็นคนคิดไอเดีย” ผมเลยบอกว่าจะให้เวลาเขาได้เปรียบก่อน 6 เดือน และถ้าถึงตอนนั้นยังนำออกสู่ตลาดไม่ได้ ผมจะทำเอง

    • ครั้งหนึ่งผมเคยเข้าร่วมโปรเจกต์เกมอินดี้ ไอเดียธรรมดา ๆ ที่แทบจะเป็นเกมห่วย ๆ แต่พวกเราทั้งสามคนอยากได้ประสบการณ์พัฒนาซอฟต์แวร์ในสายนี้
      สองในสามคนก็นั่งลงแล้วเริ่มทำให้มันเป็นรูปเป็นร่าง แต่คนที่สามเอาโค้ดพัง ๆ ขึ้น SVN แล้วทำเอกสารออกแบบที่เขียนให้ไอเดียทั้งหมดเป็นผลงานของตัวเอง จากนั้นเรียกประชุมและบอกว่าเขาเป็นเกมดีไซเนอร์ และถ้าเราไปทำเกมที่อื่นเขาจะฟ้อง พวกเราสองคนที่ลงมือทำจริงมองหน้ากันแล้วพับโปรเจกต์ เขาเปิดไพ่หมดแล้ว และเราก็รู้ว่าเขาไม่มีอะไรน่าสนใจ
      ต่อมาผมเห็นเกมที่มีไอเดียคล้ายกันบน Steam ถ้าพวกเขาคิดขึ้นมาเองก็เยี่ยม หรือถ้าขโมยมาจากไอ้ขี้แพ้คนนั้นก็ยังดี และถ้าพวกเขาทนอยู่ใต้คนคนนั้นจนจบได้ ก็สมควรได้เงินแล้ว
    • ในฐานะคนที่เอนเอียงไปทางตรรกะและการเขียนโปรแกรมอย่างสุดโต่ง กลับรู้สึกว่าอยากเจอคนแบบนั้นดูเหมือนกัน ผมคงไม่ใช่คนสายไอเดีย
      ถ้าไอเดียนั้นดีจริงและน่าเชื่อถือ พูดตามตรงมันก็อาจเป็นข้อเสนอที่ค่อนข้างใช้ได้
    • การจัดการฝ่ายขาย การตลาด บัญชี และงานที่เหลือทั้งหมดที่จำเป็นต่อการบริหารบริษัท มีมูลค่า 50% หรืออาจมากกว่านั้นด้วยซ้ำ เพียงแต่คนที่จะเขียนโค้ดน่าจะมีความสามารถพอสมควร แต่โอกาสที่เขาจะมีความสามารถพอจะ “บริหาร” บริษัทดูต่ำ
    • ถ้าไม่รู้สภาพจิตใจของอีกฝ่ายเลย ผมไม่แน่ใจว่าการพูดแบบนั้นฉลาดหรือเปล่า
      ถ้าคุณคิดว่าพูดกับใครสักคนได้ว่า “อีก 6 เดือนฉันจะขโมยไอเดียเจ๋ง ๆ ของนาย” ก็ต้องหวังว่าคนนั้นจะไม่ใช่ประเภทที่ก่อปัญหา หรือในกรณีสุดโต่งอาจทำร้ายคนอื่นได้

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

    • นักพัฒนาเดี่ยวบางคนดูเหมือนอยากนำไอเดียใหม่ไปทำให้เป็นจริง ปั้นให้เป็นธุรกิจที่ประสบความสำเร็จระดับหนึ่งจนยึดตลาดได้แน่น แล้วขายให้บริษัทใหญ่กว่าเพื่อทำเงินก้อนโต
      คงมีไม่กี่คนที่อยากบริหารบริษัทระยะยาว แต่คนส่วนใหญ่ก็คงไม่รังเกียจถ้าอยู่ ๆ ได้เงินก้อนใหญ่เพียงเพราะเคยแก้หรือแตะปัญหาที่น่าสนใจ
    • ผู้เขียนต้นฉบับเอง: เหตุผลที่เรื่องนี้สำคัญกับผมคือแอปที่ผมใช้มาระยะหนึ่งหยุดนิ่งและไม่มีอัปเดตออกมาอีกแล้ว เมื่อผมเรียนรู้เรื่อง productivity มากขึ้น ก็ไปชนข้อจำกัดของแอปนั้น และอยากได้ฟีเจอร์มากขึ้น
      ผมมีไอเดียสำหรับใส่ในแอปของตัวเองผุดขึ้นมาเรื่อย ๆ แต่นักพัฒนาคนอื่น ๆ คงไม่ได้สนใจจะทำไอเดียเหล่านั้น ผมต้องการ สิทธิ์ควบคุม และสุดท้ายจึงปล่อย Benji ออกมา: https://benji.so

  • ผู้เขียนต้นฉบับเอง ผมควรอัปเดตบทความนี้ หลายปีให้หลัง ผมได้รับแรงบันดาลใจจริง ๆ จากคอมเมนต์ใน HN ที่โผล่มาทุกครั้งที่บทความนี้ถูกโพสต์
    ผู้คนมักถามว่า “ทำไมไม่แค่ปล่อยแอปออกมา” สุดท้ายผมก็เลยปล่อยแล้ว
    ดีใจที่ทำจนจบ และคิดว่ามันดีกว่าผลิตภัณฑ์คู่แข่งใด ๆ ในหมวดนี้มาก
    ดูได้ที่ https://benji.so ส่วน landing page ยังอยู่ระหว่างทำ

    • landing page ทำให้เบราว์เซอร์กระตุก มันเป็นแค่หน้าเริ่มต้นที่มีรูปไม่กี่รูป ไม่รู้ว่าเป็นไปได้อย่างไร หน้าเว็บนั้นกำลังทำอะไรกันแน่
    • ผมเคยผ่านวงจรพัฒนาแอปที่ไม่สามารถปล่อยออกมาได้ในลักษณะคล้ายกัน เริ่มจาก React แล้วย้ายไป React Native, Flutter และสุดท้ายก็ย้ายจาก GraphQL ไป SQLite ด้วย
      แอปของผมก็มีเป้าหมายคล้ายกัน คือเชื่อมแรงจูงใจด้านนิสัย การวัดการทำตามเป้าหมาย และการจัดตารางงานกับการปรับตารางใหม่ ผมทำมันมาหลายปี และความคิดที่จะทำให้มันเป็นบริษัท bootstrapped ในสักวันหนึ่งก็ผูกกับตัวตนของผมมาก
      การตัดสินใจวางโปรเจกต์ลงมาเป็นหลายขั้นตอน แต่หนึ่งในจุดปิดฉากสำคัญคือการตระหนักว่าระยะยาวแล้วผมไม่อยากใช้ชีวิตเป็น นักพัฒนาแอป การปล่อยมันไปเป็นเรื่องยาก แต่ตอนนี้ผมพอใจกับการตัดสินใจนั้น แม้อาจมองได้ว่า “ไม่มีอะไรหายไปอย่างสมบูรณ์” เหมือนที่ต้นฉบับอาจฟื้นคืนชีพในภายหลัง แต่ผมไม่น่าจะกลับไปทำโปรเจกต์นี้โดยเฉพาะ
      หนึ่งในไอเดียหลักเพื่อก้าวข้าม “ภาระทางความคิดสูง” ที่แอป productivity ส่วนใหญ่มี คือ มาร์เก็ตเพลสโมดูลชีวิต เช่น อินฟลูเอนเซอร์สายฟิตเนสขายชุดรวมรูทีนออกกำลังกาย แผนอาหาร และเทมเพลตจดบันทึก แล้วผู้ใช้ก็ “ติดตั้ง” สิ่งนั้นลงในชีวิตของตัวเอง
      โมเดลภาษาขนาดใหญ่จะทำให้การตรวจจับการเลิกใช้และคาดเดาสาเหตุ หรือการรับมือกับ “การกระทำที่ไม่ได้ทำ” เป็นไปได้มากขึ้นมาก ผมมองว่าสิ่งนี้สำคัญสำหรับคนที่ไม่ใช่บุคลิกแบบ Type A ซึ่งใช้แอป productivity อย่างสม่ำเสมอทุกวัน
    • เพิ่งลองใช้เมื่อกี้ ชื่อเขตเวลาที่ตรวจพบออกมาเป็น “Africa/Ceuta (Romance Standard Time) (UTC+01:00) Brussels, Copenhagen, Madrid, Paris”
      ส่วนต่างจาก GMT ถูกต้อง แต่ Brussels, Copenhagen, Madrid, Paris ไม่ได้อยู่ในแอฟริกา เลยสับสนมาก ควรลองตรวจสอบ ข้อมูลเขตเวลา ที่ใช้อยู่
      พอดูคอมเมนต์ด้านล่างแล้ว เรื่องนี้ไม่ใช่ปัญหา
    • ลิงก์เมนูสีขาวบนพื้นหลังสีขาวมองไม่เห็น ฝากไว้เผื่อมีประโยชน์: https://i.imgur.com/Yd1hniV.png
    • ดูดีนะ อาจลองใช้ดู ชื่อนี้มาจากเจ้านี่หรือเปล่า https://en.wikipedia.org/wiki/Benji ตอนอายุราว 6–8 ขวบผมชอบมาก
      แล้วก็ขอโทษที่เคยแสดงความหงุดหงิดและสงสัยเรื่องที่ไม่ได้บอกชื่อ “คู่แข่ง” ตอนนี้คุณปล่อยแอปของตัวเองแล้ว ต่อให้ผลิตภัณฑ์คู่แข่งนั้นยังอยู่ ก็ยิ่งไม่น่าจะบอกชื่อมันมากกว่าเดิม

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

    • เพราะอย่างนั้นผมจึงคิดว่า “ปล่อยออกมาแล้ว iterate ให้เร็ว” มักเป็นหนทางที่ดีที่สุด ซอฟต์แวร์โปรเจกต์ไหน ๆ ก็อาจมีบั๊กระดับร้ายแรงได้ ถ้าแพ็กเกจบัญชีทำบัญชีไม่ได้อย่างถูกต้อง ก็ไม่ควรปล่อยออกมาเฉย ๆ แต่ถ้าแค่รายงานหนึ่งแสดงซ้ำสองครั้งด้วยเหตุผลบางอย่าง ผู้ใช้ยังพอรับไหวจนกว่าจะถึงรอบ iterate ถัดไป ตราบใดที่รอบถัดไปไม่ใช่อีกหลายเดือนถึงหลายปีให้หลัง
      ในความเป็นจริง ก่อนเปิดให้ผู้ใช้จริง คุณมักหา “บั๊ก” ส่วนใหญ่ที่ผู้ใช้จะเจอไม่พบ ถ้าไม่ปล่อย ก็ไม่มีโอกาสแก้บั๊กที่ส่งผลกระทบต่อผู้ใช้จริง ๆ
    • แอปที่เพิ่งใช้มีเว็บเบราว์เซอร์ iOS ในตัวที่ทำงานไม่ถูกต้อง
      ผมก็แค่เปิดหน้าเว็บโดยตรงแล้วใช้ต่อ และแน่นอนว่าชื่อผู้ใช้กับรหัสผ่านซิงก์ผ่าน iCloud อยู่แล้ว ใช้เวลา 5 วินาทีในการกลับเข้าสู่ user flow ใน Safari และอีก 30 วินาทีก็ทำเสร็จ

  • ตัวอย่างนี้ไม่ใช่ตัวอย่างที่ดีที่สุดของ “แค่ปล่อยออกไปเลย” หมวดอย่างแอปเพิ่ม productivity, to-do, ติดตามนิสัย, ติดตามค่าใช้จ่าย, journaling, แผนออกกำลังกาย เป็นหมวดที่คนจำนวนมากคิดไอเดียเดียวกันขึ้นมาได้เอง
    ตอนที่ผมนึกไอเดียแอปที่ช่วยให้บันทึกค่าใช้จ่ายได้ ผมรู้สึกว่าตัวเองฉลาดแค่ไหนก็ไม่รู้ แล้วก็ไปเช็ก Play Store ดู KRAZAM ก็เคยล้อเรื่องนี้ไว้ในวิดีโอ “The Hustle” เมื่อ 5 ปีก่อนเหมือนกัน

    • นี่อาจเป็นหมวดที่ถูกทำซ้ำมากเกินไปที่สุดในประวัติศาสตร์ของหมวดแอปที่ถูกทำซ้ำมากเกินไปก็ได้
      ไม่ได้หมายความว่า variation ใหม่จะประสบความสำเร็จไม่ได้ เพราะของที่สำเร็จส่วนใหญ่ก็ไม่ได้ original แบบสมบูรณ์อยู่แล้ว แค่ถ้าคุณกังวลว่าจะมีใครปล่อยเวอร์ชันของตัวเองก่อนแล้วชนะ ลองมองไปรอบ ๆ ก่อนก็พอ
    • ส่วนที่ว่า “เช็ก Play Store ดูแล้ว” ดูเหมือนจะพลาดประเด็นหลักของบทความ ประเด็นคือให้เปิดตัวแม้จะมีคู่แข่งอยู่แล้วต่างหาก อันที่จริง คู่แข่ง เป็นสัญญาณที่ดีว่าช่วย validate ไอเดีย ไม่ใช่สัญญาณแย่

  • โดยส่วนตัว ผมทนสไตล์การเขียนแบบ “พยายามตลกสุดชีวิต” ไม่ค่อยได้

    • เห็นด้วย อ่านแล้วค่อนข้างเหนื่อย การจิกกัดสักครั้งสองครั้งที่จังหวะดี ๆ ก็โอเค แต่ถ้าเยอะไปก็ไม่ไหว
    • ไม่ใช่แค่คุณหรอก และรสนิยมคนเราแตกต่างกันก็เป็นเรื่องปกติ

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

  • เห็นด้วยอย่างยิ่งกับคำพูดนี้ ตอนเริ่ม Kviklet เรามีกัน 3 คน และหนึ่งในนั้นเป็น perfectionist มากกว่าอีกสองคนมาก พูดตรง ๆ แม้แต่การเอาเว็บไซต์เวอร์ชันแรกที่แย่มากขึ้นออนไลน์ก็ต้องกล่อมกันเยอะแล้ว ส่วนการเปิด repository ยิ่งยากกว่า
    “co-founder” คนนั้นออกไปตั้งแต่ช่วงแรก ๆ แต่ผมดีใจจริง ๆ ที่เราปล่อยออกไปเร็วและพยายามขายดู
    มันไม่ได้ไปได้สวย และเราก็หาลูกค้าไม่ได้ แต่ลองนึกภาพว่าถ้าเรายังทำผลิตภัณฑ์อยู่ในความมืด โดยไม่รู้เลยว่าจะมีใครยอมจ่ายเงินไหม และได้แต่เกาะความหวังไว้ มันคงแย่มาก
    ตอนนี้เราทำให้เป็นโอเพนซอร์สในฐานะแผนสำรอง และก็มีผู้ใช้เจ๋ง ๆ อยู่บ้าง อาจเรียกได้ว่าเป็นคอมมูนิตี้เล็ก ๆ: https://github.com/kviklet/kviklet
    มันไม่ใช่เรื่องราวความสำเร็จของสตาร์ทอัพแบบที่หวังไว้เมื่อ 1 ปีก่อน แต่ก็ดีกว่าการยังเอาแต่คาดหวังโดยไม่มองความเป็นจริงมาก โอเพนซอร์สไม่ได้หมายความว่าจะหาเงินเล็ก ๆ น้อย ๆ จากการขาย support หรือเวอร์ชัน premium ไม่ได้เสียหน่อย ตอนนี้มันก็เป็นแค่ side project ที่สนุกดี

    • คำอธิบายว่า “workflow ตรวจทาน/อนุมัติแบบ Pull Request สำหรับ database query” ไม่ค่อยดีนัก query ไม่ควรให้ความรู้สึกว่าต้องได้รับการอนุมัติ
      ควรใช้คำอย่าง mutation, edit, update, modification มากกว่า ต่อให้ query จะถูกต้องในเชิงเทคนิค แต่ในเชิงน้ำเสียงมันผิดและฟังดูสับสน

  • ถ้าผมกำลังทำอะไรสักอย่างเพื่อตัวเอง ผมคงไม่เศร้าที่มีคนทำก่อน นั่นเป็นแค่หลักฐานว่าไอเดียนั้นดี
    แน่นอนว่าโปรเจกต์ส่วนตัวจำนวนมากที่อยู่ในหัวและบนกระดาษ หรือแม้แต่บางอย่างที่เริ่มทำจริงไปนิดหน่อย ก็ไม่ได้ตั้งใจจะเปิดขาย มันเป็นสิ่งที่ผมอยากได้ หรือคิดว่าเพื่อน ครอบครัว หรือคนอื่น ๆ น่าจะใช้ประโยชน์ได้
    ถ้ามันมีคุณภาพระดับ alpha บ้าง ผมอาจเผยแพร่ออกไปโดยหวังว่าจะมีใครคิดว่า “ไอเดียนี้มีประโยชน์นะ แต่ implementation ไม่ค่อยดี เดี๋ยวฉันทำให้ดีกว่านี้เอง”

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