วิธีบรีฟนักพัฒนาซอฟต์แวร์ เมื่อคุณไม่ได้มีพื้นฐานด้านเทคนิค

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

ทำไมไม่ต้องใช้ศัพท์เทคนิคในการเริ่มต้น

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

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

กระบวนการค้นหาความต้องการที่ดีควรดึงข้อมูลอะไรจากคุณ

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

คำถามเกี่ยวกับกระบวนการ

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

คำถามเกี่ยวกับผู้คน

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

คำถามเกี่ยวกับเป้าหมาย

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

คำถามเหล่านี้ไม่ต้องใช้ความรู้เรื่องฐานข้อมูล แพลตฟอร์ม หรือโค้ด แต่ต้องใช้ความเข้าใจธุรกิจของคุณ ซึ่งคุณย่อมรู้ดีกว่านักพัฒนาจากภายนอกเสมอ

สิ่งที่ควรนำมาในการพูดคุย

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

สิ่งที่ไม่ต้องกังวล

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

สัญญาณเตือนจากผู้ให้บริการที่ทำให้คุณรู้สึกด้อยเพราะไม่รู้ศัพท์เทคนิค

นักพัฒนาหรือเอเจนซีไม่ได้มีกระบวนการค้นหาความต้องการที่ดีทุกราย ควรสังเกตสัญญาณเหล่านี้ก่อนตัดสินใจ:

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

ข้อสรุป

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

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