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

″การตั้งคำถามที่ถูก” ทำไมถึงสำคัญในยุค AI
ในยุคที่ AI เขียนโค้ดให้ได้ ปั้นไอเดีย design ให้ได้ และบางทีก็โยนคำตอบที่ ”ฟังดูเหมือนจะสมเหตุสมผล” มาให้แบบทันใจ ความสามารถที่เราต้องมีมากกว่าเดิมกลับไม่ใช่การหาคำตอบ แต่เป็น critical thinking ความสามารถในการตั้งคำถามที่ถูกต้อง การท้าทายสมมติฐาน และคิดด้วยตัวเองอย่
nutshell.workCharanchai Thongkham

Solution มาก่อน Problem

ในงานของ software engineer / developer ที่เราจะเจอในบริษัท ส่วนใหญ่จะมีตำแหน่ง PO/PM/BA มา brief งานให้กับ engineer ซึ่งปกติแล้ว พวกเขาจะมาพร้อม solution แล้ว

เช่น อยากได้ product อะไรสักอย่าง อยากได้ features หรือ อยากได้หน้าเว็บ landing page

ทีนี้ ถ้าเราตั้งต้นด้วย solution สิ่งที่เกิดขึ้นถ้าเราจะตั้งคำถามกับมัน คือ

  • ใครต้องการใช้ feature นี้
  • ใช้เพื่ออะไร
  • ระยะเวลาที่ต้องการ
  • เขามีปัญหาอะไร ทำไมถึงต้องมีสิ่งนี้

สิ่งเหล่านั้น เอาจริงๆ มันเป็นเหมือนการตั้งคำถามเพื่อให้รู้ว่า เราทำสิ่งนี้ไปเพื่ออะไร

แต่...

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

การทำแบบนี้ เราทำได้ ถ้าหากเราไม่ได้ต้องการความมีส่วนร่วมในการแก้ปัญหาหรือช่วยคิดไอเดียจาก engineer

แน่นอนว่าสิ่งที่จะหายไปจากทีมพัฒนา คือ การมองเป้าหมายร่วมกัน

การมองเป้าหมายร่วมกันที่เปลี่ยนไป

จะบอกว่าหายไปเลย ก็คงไม่ใช่ซะทีเดียว แต่การมองเป้าหมายร่วมกันมันจะเปลี่ยนไป แทนที่เราจะมองเป้าหมายใหญ่ของบริษัท/องค์กร ก็จะเปลี่ยนเป็นมองเป้าหมายที่การทำงานให้เสร็จแทน

นิยามการทำงานมันเลยเปลี่ยนไป แทนที่จะเป็น ทำให้สำเร็จ -> ทำให้เสร็จ

เช่น

แทนที่ทุกคนจะมองว่า การทำงานให้สำเร็จ คือ "การเพิ่มยอดผู้ใช้งานใหม่ 10%"

กลับมองว่า "ทีมพัฒนา ทำ feature นี้เสร็จแล้ว" แทน ซึ่งการทำ feature นี้แล้ว จะเพิ่มยอดผู้ใช้งานใหม่ได้หรือเปล่า มันกลายเป็นสิ่งที่ทีมพัฒนาไม่ได้สนใจ

เราเลยได้ทีมพัฒนาที่ สามารถออก feature ได้เยอะ แต่ valuation ของบริษัทไม่เพิ่ม

การมาด้วย Solution

ถ้าหากเราแบ่งการทำงานออกจากกัน แล้วยกหน้านี้คิดว่าต้องทำอะไรเพื่อให้ตอบเป้าหมายบริษัท

เช่น

PO/PM เป็นคนคิด feature แล้วเอามาให้ทีมพัฒนาทำ สิ่งที่ต้องเตรียมตัวให้พร้อมเลย คือ การตอบคำถามจากทีมพัฒนา

  • กลุ่มเป้าหมายคือใคร
  • ทำไมถึงต้องทำอันนี้
  • ทำแล้วจะได้อะไรเพิ่ม
  • แล้วถ้าไม่ทำอันนี้มีวิธีอื่นไหม

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

ถ้าเราเป็นอย่างนี้... ยินดีด้วย เรากำลังสร้างทีมพัฒนาที่เป็น worker ทำงานตามสั่ง โฟกัสที่งานของเขาหรือทีมเสร็จ และมองว่าเป้าหมายองค์กร ไม่ใช่เป้าหมายที่พวกเขาต้องสนใจ

ตั้งต้นที่ปัญหา

หากเราต้องการให้ทุกคนมีส่วนร่วมกับเป้าหมายของบริษัท/องค์กร โดยที่สิ่งที่ทำจะต้องสร้าง value ให้แก่บริษัทจริงๆ มันควรที่จะตั้งต้นที่ goal ของบริษัท แล้วย่อยออกมาเป็นปัญหา หรือโจทย์ที่จะต้องแก้

ซึ่งผมเคยเขียนบทความเรื่องนี้ไว้แล้ว

การเดินทางจาก Strategy สู่ Product Roadmap
ในแต่ละปี Product Owner จะต้องมีสิ่งที่เรียกว่า Product Roadmap ที่ถูกวางไว้ว่า แต่ละปี (เป็นอย่างต่ำ) จะต้องทำอะไรบ้าง ต้องทำฟีเจอร์ไหนบ้าง หรือต้องปรับปรุงส่วนไหน ตอนที่ผมทำงานอยู่กับบริษัท startup ผมจะต้องวางแผน product roadmap กั
nutshell.workCharanchai Thongkham

ทำไมการตั้งต้นที่ปัญหาหรือโจทย์ถึงดีกว่า...

เราลองนึกภาพดูว่า เวลาที่เราจะพัฒนาระบบอะไรขึ้นมาสักอย่าง มันล้วนเกิดมาจากความต้องการแก้ปัญหาอะไรสักอย่าง ซึ่งถ้าเราไล่เรียงสืบย้อนกลับไปเราก็จะพบว่า สิ่งนั้น คือ เป้าหมายบริษัท

ทีนี้ ถ้าหากเรา คิดแค่ว่า เราจะทำ feature นี้ เพราะระบบเรายังไม่มี แต่คู่แข่งมี สิ่งนี้มันก็ฟังดูเข้าท่าใช่ไหม

แต่ การสำสิ่งนี้ มันตอบ goal อะไรของบริษัท

เช่น

ถ้าบริษัทต้องการเพิ่มยอดการจ่ายเงินในระบบใน Q2 อีก 30% ... แต่เรากำลังจะทำ feature tags management มันจะช่วยเราเพิ่มยอดให้บริษัทได้จริงไหม?

ดังนั้น ถ้าเราต้องการเพิ่มยอดให้บริษัท แทนที่จะคิด feature เลย ลองคิดดูก่อนว่า เราจะเพิ่มมันจากส่วนไหนได้บ้าง ส่วนไหนที่ quick win ที่สุด ส่วนใหญ่ต้องใช้เวลา และส่วนไหนไม่จำเป็นต้องทำ

ดีไม่ดีอาจจบที่ไม่จำเป็นต้องพัฒนา feature อะไรเพิ่มเลยก็ได้ จะได้เอาเวลาของทีมพัฒนาไปพัฒนาส่วนอื่นต่อ

เช่น

  • Goal: บริษัทต้องการเพิ่มยอดการจ่ายเงินในระบบใน Q2 อีก 30%
  • Problem: จำนวนการใช้งานของผู้ใช้อยู่ที่ 200,000 ต่อวัน ต้องการเพิ่มเป็น 260,000 ต่อวัน (คิดเป็น 30%)
  • Solution: ทำ marketing campaign, เพิ่มกิจกรรมภายในระบบ, ขึ้นราคา, หรือเพิ่ม features ใหม่

สังเกตไหมว่า goal บางอย่าง ไม่จำเป็นต้องทำ feature ใหม่ขึ้นมาเลย ซึ่งสิ่งนี้ต้องเป็นการ discuss ร่วมกันถึงจะเกิด

ผมเคยเขียนเรื่องความคุ้มทุนไว้แล้ว

เเรงที่ลงคุ้มทุนหรือเปล่า?
หลายต่อหลายครั้งที่ทีมของเราจะต้องพัฒนาของออกมา หลายต่อหลายครั้งเราก็ทุ่มแรงไปกับของที่ไม่ได้สร้าง value ให้แก่ user หรือ stakeholder เท่าไหร่ ปัญหาในการเลือกหยิบเอาของไปพัฒนานั้นมีให้เห็นอยู่ทั่วไป ซึ่งเกิดได้ทั้งจาก Project Owner หรือ Project Manager ไม่มี
nutshell.workCharanchai Thongkham

เมื่อเรามา discuss รวมกันแล้ว จะทำให้ทุกคนเข้าใจถึงเป้าหมายของบริษัท/ฝ่าย/ทีม ที่จะไป แล้วถ้ามีอะไรที่ทำให้เราไปถึงเป้าหมายนั้นโดยที่ใช้แรงน้อยกว่าได้ ทุกคนก็จะเอามามาเสนอ

แก้ปัญหาต่อกันเป็นจนเป็น connection dot

ในการตั้งโจทย์ในการแก้ปัญหาใดปัญหาหนึ่งนั้น ปกติแล้วมันจะนำพาเราไปเจออีกปัญหาหนึ่งเสมอ

เช่น

ถ้าบอกว่า เราต้องการเพิ่มยอดการใช้จ่ายเงินเป็น 100% จากยอดที่ใช้จ่ายอยู่ในปัจจุบัน เราก็จะคิดอะไรบางอย่างเพื่อเพิ่มยอดการใช้จ่ายใช่ไหม

เราอาจเจอปัญหาใหม่ว่า ยอดใช้จ่ายเฉลี่ยของผู้ใช้อยู่ที่ระดับหนึ่ง แล้วเราไม่สามารถเพิ่มส่วนนี้ได้แล้ว

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

แล้วเราก็จะเจอปัญหาว่า ถ้าลูกค้าไม่ยอมผ่อนจ่าย (บิด) เราจะแก้ไขยังไง

การคิดไล่ไปอย่างนี้ แก้ปัญหาจากโจทย์ไปเรื่อยๆ จนจบ flow การทำงาน เราจะได้สิ่งที่ว่า Job to be Done ของการแก้ปัญหา/end-to-end นั้น

อีกทั้งเราจะได้คำตอบออกมาว่า solution นี้ควรทำไหม หรือ เราต้องคิด solution ใหม่

สิ่งนี้ คือ การออกแบบ solution

ซึ่ง ผมยังไม่เคยเขียนเรื่องนี้ไว้ 🫣

ไม่จำเป็นต้องจบที่ทำระบบเสมอไป

บ่อยครั้งที่เรามักจะพบว่า ทีมพัฒนาของเรา กระสันที่อยากจะทำงาน อยากพัฒนาระบบเร็วๆ จนไม่คิดจะตั้งคำถามถึงสิ่งที่ PO/PM เอามาให้ทีมทำ

แล้วเมื่อเราถามคำถามไม่ครอบคลุมพอ หรือ ละเลียการคิดให้รอบคอบ ผลก็มาตกกับงานที่ทำ เจอบางอย่างที่ไม่ make sense บ้าง ตกหล่น flow การทำงานบางอย่างบ้าง จนนำพาไปถึงจุดที่ว่า มีงานทำ แต่งานไม่ได้ทำประโยชน์อะไรให้แก่องค์กรเลยก็มี

ดังนั้นสำหรับ PO/PM และ ทีมพัฒนา สิ่งที่ควรตระหนักไว้ คือ การแก้ปัญหาบางอย่าง อาจไม่จำเป็นต้องจบที่การพัฒนาระบบก็ได้ หรือ ไม่จำเป็นต้องพัฒนาทั้งหมดตั้งแต่แรกก็ได้ด้วยเช่นกัน

ดังตัวอย่างด้านบนที่ การเพิ่มยอดการใช้จ่าย อาจจบที่การทำ marketing campaign หรือ อาจเป็น marketing + feature บางอย่าง เพื่อเพิ่มช่องทาง หรือ ความสดใหม่ของกิจกรรมก็ได้

สรุป

การตั้งคำถามนั้น เราควรตั้งคำถามร่วมกันตั้งแต่ต้น โดยเอา goal ของบริษัทเป็นที่ตั้ง และมา discuss กันว่า ถ้าต้องการที่จะไปให้ถึงเป้าหมายนั้น พวกเราทั้งองค์กรต้องทำอะไรบ้าง

สิ่งนี้จะง่ายกับองค์กรที่ไม่ใหญ่มาก ถ้าเป็นองค์กรที่มีจำนวนพนักงานเยอะ มีหลายแผนก เป็น SILO แล้วด้วย การมีส่วนร่วมจะเป็นระดับบนๆ ที่ต้องทำงานร่วมกัน เพื่อให้ได้ solution ของแต่ละฝ่ายออกมา

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