- หลายบริษัทมักพัฒนาช้าเพราะติดอยู่กับกระบวนการที่ซับซ้อนหรือข้อกำหนดที่ยืดยาว แต่สิ่งที่สำคัญจริง ๆ คือการสร้าง ‘ผลิตภัณฑ์ที่ถูกต้อง’ ให้ได้อย่างรวดเร็ว
- หากตัดสิ่งที่ไม่จำเป็นออกจากกระบวนการพัฒนาผลิตภัณฑ์ ความเร็วในการพัฒนาจะเพิ่มขึ้นอย่างมาก การสร้างผลิตภัณฑ์ที่ถูกต้องนั้นโดยเนื้อแท้แล้วเป็นกระบวนการที่รวดเร็ว
- สิ่งที่ทำให้ทีมผลิตภัณฑ์ช้าลงคือองค์ประกอบที่ไม่จำเป็น เช่น กระบวนการ ระยะห่างระหว่างผู้ตัดสินใจกับผู้ลงมือทำ และเอกสารสเปกที่มากเกินไป
[หลักการเพื่อ Product Velocity]
1. ต้อง ‘ทำน้อยลง’
- โดยทั่วไปจะมี trade-off ระหว่างความเร็วกับคุณภาพ
- บริษัทส่วนใหญ่มักกำหนดข้อกำหนดและเส้นตาย แล้วถือว่าคุณภาพเป็นผลลัพธ์ แต่เราทำตรงกันข้าม โดยกำหนดมาตรฐานคุณภาพก่อน แล้วค่อยคิดว่าใน 60 วันจะปล่อยอะไรออกมาได้บ้าง
- สิ่งสำคัญไม่ใช่การพยายามทำตามทุกข้อกำหนดให้ครบ แต่คือการทำเฉพาะสิ่งสำคัญให้เสร็จอย่างรวดเร็ว
- หากตัดข้อกำหนดออกและทำเฉพาะงานที่จำเป็น ก็สามารถเพิ่มได้ทั้งความเร็วและคุณภาพ
- Elon Musk ก็เสนอแนวทางคล้ายกัน โดยบอกว่า “อย่างแรกคือทำให้ข้อกำหนดโง่น้อยลงก่อน”
2. ‘โหมดคนโง่’ มักได้ผล
- หากยกตัวอย่าง ‘midwit meme’ คนฉลาดมากกับคนโง่มักเห็นตรงกันกับวิธีแก้ที่เรียบง่าย ในขณะที่คนระดับกลางมักสร้างปัญหาที่ซับซ้อนโดยไม่จำเป็น
- เรามักเข้าหาปัญหาใน ‘โหมดคนโง่’ คือแทนที่จะคิดให้ซับซ้อน ก็พยายามหาวิธีแก้ที่เรียบง่าย
- เวลาที่ทำพลาด ส่วนใหญ่มักเป็นเพราะคิดมากเกินไป วิธีที่เรียบง่ายมักใช้ได้ผลบ่อยกว่า
- การถามตัวเองว่า “ถ้าฉันเป็นคนโง่ ฉันจะทำยังไง?” มักพาไปสู่ทางแก้ที่ลงมือทำได้จริง
3. ไม่ใช่ทุกปัญหาจะสำคัญ
- มีเพียงปัญหาไม่กี่อย่างที่สำคัญมาก ปัญหาสำคัญอย่างเรื่องความปลอดภัยต้องแก้แน่นอน แต่ไม่จำเป็นต้องแก้ทุกปัญหา
- ตัวอย่างเช่น UI บนมือถืออาจยังไม่ดีนัก แต่เราไม่ปรับปรุงเพราะลูกค้าแทบไม่ได้ใช้งานบนมือถือ
- ปัญหาแบบนี้ที่ลูกค้าไม่ได้ใส่ใจมาก ก็สามารถมองข้ามได้
4. แค่ลงมือสร้าง
- เราไม่มีกระบวนการสำหรับการพัฒนาผลิตภัณฑ์ เราไม่ทำ Figma mockup, PRD, design system, agile, OKR, product roadmap ที่ชัดเจน, A/B testing หรือ growth hacking
- เพราะลูกค้าของเราเป็นวิศวกร เราจึงคาดหวังว่าวิศวกรของเราจะจัดการทั้งผลิตภัณฑ์ ดีไซน์ และอื่น ๆ ได้ทั้งหมด
- เราชอบวิธีสร้างผลิตภัณฑ์ออกมาอย่างรวดเร็ว แล้วดูปฏิกิริยาของลูกค้า
5. เขียนใหม่เมื่อจำเป็น
- บริษัทต่าง ๆ มักคิดว่ายิ่งเลื่อน technical debt ออกไปได้นานเท่าไร ก็จะยิ่งเคลื่อนที่ได้เร็วขึ้น แต่เราไม่ได้รู้สึกอึดอัดกับการรีไรต์ครั้งใหญ่เมื่อถึงเวลาที่จำเป็น
- บางครั้งทางที่เร็วที่สุดในการสร้างสิ่งที่ถูกต้อง คือการสร้างสิ่งที่ผิดก่อน ตระหนักว่ามันผิด แล้วแทนที่มันด้วยสิ่งที่ถูกต้อง
- หากการกำจัด technical debt ดูมีประโยชน์ เราก็จะทำ
6. ใช้การจ้างภายนอกเมื่อทำได้
- ถ้าเป็นไปได้ เราจะซื้อโซลูชันจาก vendor ภายนอกแทนที่จะทำเองในบริษัท ตัวอย่างเช่น เราใช้ผู้ให้บริการชื่อ Fern ในการสร้าง SDK
- แน่นอนว่าการใช้ผู้ให้บริการมีต้นทุนเริ่มต้นค่อนข้างสูงและจำกัดอิสระบางส่วน แต่โดยทั่วไปแล้วเป็นตัวเลือกที่ถูกต้อง
- ทรัพยากรวิศวกรรมของเรามีจำกัดและมีราคาแพงมาก เวลา 1 สัปดาห์ของวิศวกรมีต้นทุนราว 5,000 ดอลลาร์ และเมื่อคิดถึงค่าเสียโอกาส มูลค่านั้นยิ่งสูงกว่านั้นมาก
- สิ่งที่คุ้มค่าพอจะลงมือสร้างเองจริง ๆ มีไม่มากนัก
7. ไม่จ้างเพิ่ม
- เราไม่ได้คาดหวังว่าการเพิ่มคนจะทำให้ผลผลิตของทีมเพิ่มขึ้น การจ้างงานนั้นช้าและยาก และการ onboarding กับการบริหารคนก็กินเวลา
- โดยเฉพาะอย่างยิ่ง การหาคนเก่งที่สามารถสร้างผลงานได้โดยแทบไม่ต้องมีคนช่วยนั้นเป็นเรื่องยาก
- ดังนั้น แม้เราจะมีทรัพยากรพอจะสร้างทีมวิศวกรรมขนาดใหญ่ เราก็พยายามอย่างเต็มที่ที่จะรักษาทีมให้เล็กไว้ เพราะทำให้ชีวิตง่ายขึ้นมาก
ข้อคิดส่งท้าย
- เราตระหนักว่าการพัฒนาผลิตภัณฑ์ไม่ควรใช้เวลานานขนาดนั้น มากกว่าที่เราเคยเข้าใจไว้ก่อนหน้านี้
- หากคุณรู้ว่าลูกค้าต้องการอะไร มีทีมที่แข็งแกร่ง และตัดสิ่งรบกวนที่ไม่จำเป็นออกไป คุณก็สามารถพัฒนาผลิตภัณฑ์ได้ด้วยความเร็วสูง
10 ความคิดเห็น
ฉันก็กลับมาดูอีกแล้ว แล้วพบกันใหม่คราวหน้า
อ่านกี่ครั้งก็ดีเสมอ
?? ฟังดูอุดมคติมากเลยนะ
ต้นทุนในการดูแลการจ้างภายนอกและทรัพยากรที่ต้องใส่ลงไปก็คงไม่น้อยเหมือนกัน... แต่โดยรวมแล้วก็เป็นคำแนะนำที่ยอดเยี่ยมครับ
ชอบมีคนบอกให้ใช้การจ้างภายนอกอยู่เสมอ แต่แทบไม่ค่อยเห็นเลยว่าควรทำอย่างไรเมื่อต้องใช้การจ้างภายนอก
ถ้าส่งต่อไปแค่โครงร่างคร่าว ๆ โดยไม่มีภาพของบริการที่ชัดเจน ก็เหมือนจะไม่ตระหนักว่าอาจได้รับสิ่งที่แย่กว่าที่คิดไว้เสียอีก....
???: ช่วยทำให้มันเร็ว แต่ไม่ต้องเป็นแบบ Agile นะครับ/คะ
ผมคิดว่าสิ่งนี้เป็นไปได้เมื่อผลิตภัณฑ์มีความชัดเจน
เมื่อสิ่งที่ต้องทำชัดเจน การออกแบบที่มากไปกว่านั้นก็ไม่จำเป็น ประมาณนั้น
"ทำให้ข้อกำหนดความต้องการโง่น้อยลงก่อน"
ถ้าวันหนึ่งบริษัทรับจ้างภายนอกหายไป... โทรก็ไม่รับ ฮือฮือ
ถึงจะเป็นการพัฒนาภายใน แต่ถ้าวันหนึ่งทุกคนพากันลาออกหมด สถานการณ์ก็คงไม่ต่างกันใช่ไหม..?