Topic 45 หลุมพรางของ Requirements

ความสมบูรณ์แบบไม่ได้เกิดขึ้นเมื่อไม่มีอะไรให้เพิ่มเข้าไปอีกแล้ว แต่เกิดขึ้นเมื่อไม่มีอะไรให้ตัดออกไปได้อีกแล้ว...

Antoine de St. Exupery, Wind, Sand, and Stars, 1939

หนังสือและ Tutorial หลายเล่มมักจะพูดถึงการทำ requirements gathering ว่าเป็นเฟสแรก ๆ ของโปรเจกต์ คำว่า “gathering” มันฟังดูเหมือนกลุ่มนักวิเคราะห์ที่กำลังเดินเก็บเศษเสี้ยวของความรู้ที่วางเกลื่อนกลาดอยู่บนพื้น โดยมีเพลง Pastoral Symphony เปิดคลอเบา ๆ อยู่เบื้องหลัง คำว่า “gathering” มันสื่อว่า requirements มีรออยู่ตรงนั้นแล้ว—คุณแค่ต้องไปหาให้เจอ เก็บมันใส่ตะกร้า แล้วก็เดินจากไปอย่างสบายใจ

แต่มันไม่ได้ง่ายขนาดนั้น เพราะ requirements แทบจะไม่เคยวางอยู่บนพื้นผิวให้เราเห็นเลย ปกติแล้วมันมักจะถูกฝังอยู่ลึกภายใต้ชั้นของ assumptions, ความเข้าใจผิด และเรื่องของการเมืองในองค์กร และที่แย่ไปกว่านั้นคือ บ่อยครั้งที่มันไม่ได้มีอยู่จริงเลยด้วยซ้ำ

Tip 75 ไม่มีใครรู้จริง ๆ ว่าตัวเองต้องการอะไร

ตำนานของ Requirements

ในยุคแรก ๆ ของการพัฒนาซอฟต์แวร์ คอมพิวเตอร์มีค่ามากกว่าคนทำงาน (คิดจากต้นทุนเฉลี่ยต่อชั่วโมง) เราประหยัดเงินได้โดยพยายามทำทุกอย่างให้ถูกต้องตั้งแต่ครั้งแรก ส่วนหนึ่งของกระบวนการนั้นคือการระบุให้ชัดเจนว่าเราจะให้เครื่องคอมพิวเตอร์ทำอะไร เราจะเริ่มด้วยการทำ specification ของ requirements จากนั้นจึงแปลงไปเป็น design document แล้วจึงไปสู่ flowcharts และ pseudo code และสุดท้ายจึงเปลี่ยนไปเป็น code แต่ก่อนที่จะป้อนเข้าไปในคอมพิวเตอร์ เราต้องเสียเวลาทำ desk checking มันเสียก่อน

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

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

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

Tip 76 Programmers ช่วยให้ผู้คนเข้าใจสิ่งที่เขาต้องการ

Programming เปรียบเสมือนการบำบัด

เรามาเรียกคนที่ขอให้เราเขียนซอฟต์แวร์ว่า ลูกค้า (clients) กันเถอะ

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

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

จากประสบการณ์ของเรา คำบอกเล่าถึงความต้องการในตอนแรกนั้นไม่ใช่ requirement ที่แน่นอนเสมอไป ลูกค้าอาจจะไม่รู้ตัว แต่จริง ๆ แล้วมันคือคำเชิญชวนให้เราเข้าไปสำรวจร่วมกับเขา

มาดูตัวอย่างง่าย ๆ กัน

สมมติว่าคุณทำงานให้กับสำนักพิมพ์หนังสือทั้งแบบเล่มและแบบอิเล็กทรอนิกส์ คุณได้รับ requirement ใหม่ว่า:

ฟรีค่าจัดส่ง สำหรับทุกออร์เดอร์ที่มีราคาตั้งแต่ 0 ขึ้นไป

หยุดสักครู่แล้วลองจินตนาการดูว่าคุณอยู่ในสถานการณ์นั้น อะไรคือสิ่งแรกที่แวบเข้ามาในหัวของคุณ?

มีความเป็นไปได้สูงที่คุณจะมีคำถาม:

  • 0 นั้นรวมภาษีหรือยัง?
  • 0 นั้นรวมค่าส่งปัจจุบันเข้าไปด้วยไหม?
  • 0 นั้นต้องเป็นหนังสือแบบเล่มอย่างเดียว หรือรวม ebooks เข้าไปด้วยได้?
  • ใช้การจัดส่งแบบไหน? Priority? หรือส่งธรรมดา?
  • แล้วออร์เดอร์ต่างประเทศล่ะ?
  • ในอนาคตราคาขั้นต่ำ 0 นี้จะเปลี่ยนบ่อยแค่ไหน?

นั่นแหละคือสิ่งที่พวกเราทำกัน เมื่อเจออะไรที่ดูเหมือนจะง่าย เราก็จะทำให้คนอื่นรำคาญใจโดยการมองหา edge cases แล้วก็ถามจู้จี้เกี่ยวกับพวกมัน

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

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

คุณ:

เรากำลังสงสัยเรื่องยอดรวม 0 ครับ ว่ามันรวมค่าจัดส่งที่เราคิดตามปกติเข้าไปด้วยหรือเปล่า?

ลูกค้า:

แน่นอนสิ มันคือยอดรวมทั้งหมดที่เขาต้องจ่ายเราไง

คุณ:

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

ลูกค้า:

ตุกติกยังไงล่ะ?

คุณ:

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

(ถึงจุดนี้ developer ที่มีประสบการณ์จะหยุดพูด บอกแค่ข้อเท็จจริง และปล่อยให้ลูกค้าเป็นคนตัดสินใจเอง)

ลูกค้า:

เจ็บเลยแฮะ นั่นไม่ใช่สิ่งที่ผมตั้งใจไว้เลย เราคงขาดทุนแย่กับออร์เดอร์พวกนั้น แล้วมีทางเลือกอื่นไหมล่ะ?

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

Requirements คือกระบวนการอย่างหนึ่ง

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

Tip 77 Requirements นั้นเรียนรู้ได้จาก Feedback Loop

งานของคุณคือการช่วยให้ลูกค้าเข้าใจผลกระทบของ requirements ที่เขาระบุมา คุณทำอย่างนั้นได้โดยการสร้าง feedback และปล่อยให้เขาใช้ feedback นั้นมาขัดเกลาความคิดของเขาเอง

ในตัวอย่างข้างบน feedback สามารถสื่อสารออกมาเป็นคำพูดได้ง่าย แต่บางครั้งมันก็ไม่เป็นอย่างนั้น และบางครั้งคุณเองก็อาจจะไม่มีความรู้ในเรื่องนั้น (domain) มากพอที่จะให้รายละเอียดได้เจาะจงขนาดนั้น

ในกรณีเหล่านั้น Pragmatic Programmers จะพึ่งพา feedback ในรูปแบบ "แบบนี้ใช่ไหมที่คุณต้องการ?" เราจะสร้าง mockups และ prototypes ขึ้นมา แล้วให้ลูกค้าได้ลองเล่นกับมัน และทางที่ดีคือสิ่งที่เราสร้างขึ้นมาควรจะยืดหยุ่นพอที่เราจะเปลี่ยนมันได้ระหว่างที่กำลังคุยกับลูกค้า ทำให้เราตอบโต้กับสิ่งที่ลูกค้าบอกว่า "นั่นไม่ใช่สิ่งที่ผมต้องการเลย" ด้วยคำว่า "งั้นต้องเป็นแบบนี้ใช่ไหมครับ?"

บางครั้ง mockups เหล่านี้อาจจะสร้างเสร็จได้ภายในเวลาเพียงชั่วโมงเดียวเท่านั้น เพราะมันเป็นเพียงแค่ของที่เรา hack ขึ้นมาคร่าว ๆ เพื่อสื่อสารไอเดียเฉย ๆ

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

ดังนั้น Pragmatic Programmer จึงมองว่าทั้งโปรเจกต์คือแบบฝึกหัดในการทำ requirements gathering นั่นจึงเป็นเหตุผลที่เราชอบการทำสั้น ๆ (short iterations) ที่จบด้วย feedback จากลูกค้าโดยตรง สิ่งนี้จะช่วยให้เราไม่หลุดโฟกัส และมั่นใจได้ว่าหากเราเดินผิดทาง เราจะเสียเวลาน้อยที่สุด

ลองไปสวมวิญญาณเป็นลูกค้าดูบ้าง

มันมีเทคนิคง่าย ๆ ในการเข้าไปดูในหัวของลูกค้าที่ไม่ค่อยจะมีใครใช้กันบ่อยนัก นั่นก็คือ: การไปเป็นลูกค้าเสียเองเลย คุณกำลังเขียนระบบสำหรับ help desk อยู่ใช่ไหม? ลองใช้เวลาสักสองสามวันเพื่อเฝ้าฟังโทรศัพท์ไปพร้อมกับเจ้าหน้าที่ support ที่มีประสบการณ์ดูสิ คุณกำลังทำระบบจัดการสต็อกสินค้าอัตโนมัติอยู่หรือเปล่า? ลองไปทำงานในโกดังสักอาทิตย์ดูสิ[70]

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

Tip 78 ทำงานร่วมกับ User เพื่อให้คิดแบบ User

การเก็บ feedback ยังเป็นเวลาที่ดีในการสร้างความสัมพันธ์กับฐานลูกค้าของคุณ เรียนรู้ความคาดหวังและความหวังของพวกเขาที่มีต่อระบบที่คุณกำลังสร้างขึ้น ดูรายละเอียดเพิ่มเติมได้ใน Topic 52, ​_Delight Your Users_​

Requirements vs. Policy

ลองจินตนาการว่าระหว่างที่กำลังคุยเรื่องระบบทรัพยากรบุคคล (HR) ลูกค้าบอกว่า "เฉพาะหัวหน้างานของพนักงานและฝ่ายบุคคลเท่านั้นที่สามารถดูประวัติพนักงานคนนั้นได้" คำกล่าวนี้เป็น requirement จริง ๆ หรือเปล่า? บางทีมันอาจจะเป็นแค่วันนี้ แต่มันได้เอา business policy ไปฝังอยู่ในคำกล่าวที่ฟังดูเหมือนเป็นกฎเหล็กไปเสียแล้ว

มันเป็น Business policy? หรือมันเป็น Requirement? มันเป็นความแตกต่างที่ค่อนข้างจะเล็กน้อยแต่มันมีผลอย่างมากต่อ developers ถ้า requirement ระบุมาว่า "เฉพาะหัวหน้างานและฝ่ายบุคคลเท่านั้นที่ดูประวัติพนักงานได้" developer ก็อาจจะจบลงด้วยการเขียน code เช็คเงื่อนไขนั้นทุกครั้งที่แอปฯ เข้าถึงข้อมูล แต่ถ้าประโยคบอกว่า "เฉพาะผู้ที่มีสิทธิ์เท่านั้นที่เข้าถึงประวัติพนักงานได้" developer ก็น่าจะออกแบบและ implement ระบบ access control อะไรสักอย่างขึ้นมา และเมื่อ policy เปลี่ยนแปลงไป (ซึ่งมันเปลี่ยนแน่นอน) สิ่งที่จะต้องอัปเดตก็มีเพียงแค่ metadata ของระบบนั้นเท่านั้น ความจริงแล้วการเก็บ requirements ในรูปแบบนี้จะพาคุณไปสู่ระบบที่ถูกออกแบบมาอย่างดีเพื่อรองรับ metadata โดยธรรมชาติ

ซึ่งความจริงแล้ว มันมีกฎทั่วไปอยู่ข้อหนึ่ง:

Tip 79 Policy คือ Metadata

จง implement สำหรับกรณีทั่วไป (general case) โดยใช้ข้อมูล policy เป็นตัวอย่างของสิ่งที่ระบบควรจะรองรับได้

Requirements vs. Reality

ในบทความของนิตยสาร Wired เมื่อเดือนมกราคมปี 1999​_71_​ Brian Eno โปรดิวเซอร์และนักดนตรี ได้อธิบายถึงเทคโนโลยีที่น่าทึ่งชิ้นหนึ่ง—นั่นคือ mixing board ขั้นสุดยอด มันสามารถปรับแต่งเสียงได้ทุกอย่างที่ทำได้ แต่แทนที่จะให้นักดนตรีสร้างสรรค์เพลงที่ดีกว่าเดิม หรือทำงานให้เสร็จได้เร็วขึ้นและถูกลง แต่มันกลับมาขัดขวางกระบวนการสร้างสรรค์เสียเอง

เหตุผลก็คือเราต้องย้อนกลับไปดูวิธีการทำงานของ recording engineers ปกติแล้วพวกเขาจะปรับจูนเสียงโดยใช้สัญชาตญาณ กว่าหลายปีที่พวกเขาพัฒนา feedback loop ที่เกิดขึ้นโดยอัตโนมัติระหว่างหูกับปลายนิ้ว—เลื่อน fader หมุนปุ่ม และอื่น ๆ อย่างไรก็ตาม หน้าตาการใช้งานของ mixer ตัวใหม่ไม่ได้ดึงเอาความสามารถเหล่านั้นมาใช้เลย แต่มันกลับบังคับให้ผู้ใช้งานต้องพิมพ์บนคีย์บอร์ดหรือคลิกเมาส์แทน ฟังก์ชันต่าง ๆ ที่มันมีให้นั้นครอบคลุมทุกอย่าง แต่มันถูกออกแบบมาในรูปแบบที่ไม่คุ้นเคยและดูแปลกประหลาด ฟังก์ชันที่วิศวกรต้องการนั้นบางครั้งก็ถูกซ่อนอยู่หลังชื่อที่เข้าใจยาก หรือทำได้ยากจากส่วนผสมของฟังก์ชันพื้นฐานที่ไม่สอดคล้องกับสัญชาตญาณการทำงานของพวกเขา

ตัวอย่างนี้แสดงให้เห็นถึงความเชื่อของเราว่า เครื่องมือที่ประสบความสำเร็จนั้นต้องปรับตัวเข้าหากับมือของผู้ใช้งาน การทำ requirements gathering ที่ประสบความสำเร็จก็ต้องคำนึงถึงเรื่องนี้ด้วย และนั่นเป็นสาเหตุว่าทำไม feedback ในตอนแรกจาก prototypes หรือ tracer bullets จะช่วยให้ลูกค้าพูดออกมาได้ว่า "ใช่ มันทำในสิ่งที่ผมต้องการเป๊ะเลย แต่มันไม่ได้ทำในแบบที่ผมต้องการนะ"

การทำ Documenting Requirements

เราเชื่อว่า requirements documentation ที่ดีที่สุด และอาจจะเป็นเพียงอย่างเดียวที่ควรมี นั่นคือ code ที่ทำงานได้จริง

แต่นั่นไม่ได้หมายความว่าคุณจะไม่ต้องทำเอกสารอะไรเลยเกี่ยวกับความเข้าใจในสิ่งที่ลูกค้าต้องการ แต่มันหมายความว่าเอกสารเหล่านั้นไม่ได้เป็นสิ่งที่เราต้องส่งมอบ (deliverable) มันไม่ใช่สิ่งที่คุณจะเอาไปให้ลูกค้าเซ็นรับรอง แต่มันเป็นเพียงเหมือนป้ายบอกทางที่จะช่วยนำทางกระบวนการ implementation ของคุณต่างหาก

Requirements Documents ไม่ได้มีไว้สำหรับลูกค้า

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

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

คุณอาจจะแย้งว่า "แต่เราก็เอาเอกสารไปให้ลูกค้าดูและเซ็นรับรองแล้วนี่นา แบบนี้ก็ถือว่าได้ feedback แล้วไม่ใช่เหรอ?" และนั่นก็นำไปสู่ปัญหาข้อที่สองของ specification ของ requirement เหล่านั้น นั่นคือ ลูกค้าไม่เคยอ่านมันเลย

ลูกค้าเลือกใช้งาน programmers ก็เพราะว่าในขณะที่ลูกค้ามีแรงจูงใจในการแก้ปัญหาในระดับสูง (high-level) ที่ค่อนข้างคลุมเครือ แต่ programmers กลับมีความสนใจในรายละเอียดและจุดเล็กจุดน้อยที่ซ่อนอยู่ ดังนั้นเอกสาร requirements จึงถูกเขียนขึ้นมาเพื่อ developers และมันก็ประกอบไปด้วยข้อมูลและความซับซ้อนที่บางครั้งลูกค้าก็ไม่เข้าใจ และบ่อยครั้งมันก็น่าเบื่อสำหรับพวกเขา

เมื่อคุณยื่นเอกสาร requirements ยาว 200 หน้า ลูกค้าก็น่าจะกะน้ำหนักมันดูว่ามันหนักพอจะถือว่าสำคัญไหม พวกเขาอาจจะอ่านแค่สองสามย่อหน้าแรก (ซึ่งนั่นเป็นสาเหตุที่ย่อหน้าแรก ๆ มักจะถูกเขียนชื่อว่า Management Summary) และพวกเขาอาจจะแค่พลิกอ่านผ่าน ๆ ไปเรื่อย ๆ แล้วหยุดดูบ้างเวลาเจอไดอะแกรมที่ดูดี

นี่ไม่ใช่การดูถูกลูกค้านะครับ แต่การส่งมอบเอกสารเทคนิคที่หนาเตอะให้พวกเขาก็เปรียบเหมือนกับการเอาสำเนาหนังสือมหากาพย์ Iliad ในภาษาภาษากรีกแบบโฮเมอร์ (Homeric Greek) ไปให้ developer ทั่วไป แล้วบอกให้พวกเขาเขียนโปรแกรมวิดีโอเกมจากหนังสือเล่มนั้นนั่นแหละ

Requirements Documents มีไว้สำหรับการวางแผน

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

แล้วมันควรจะอยู่ในรูปแบบไหนล่ะ? เราชอบแบบที่สามารถจดลงใน index card (ทั้งแบบจริงหรือแบบ virtual) ได้สั้น ๆ ซึ่งเรามักจะเรียกคำอธิบายสั้น ๆ เหล่านี้ว่า user stories มันจะอธิบายสิ่งที่ส่วนเล็ก ๆ ส่วนหนึ่งของแอปพลิเคชันควรจะทำในมุมมองของผู้ใช้งานส่วนนั้น

เมื่อถูกเขียนขึ้นมาในรูปแบบนี้ เราสามารถนำเอา requirements เหล่านั้นไปวางไว้บนบอร์ดและเคลื่อนย้ายมันไปมาเพื่อแสดงให้เห็นถึงทั้งสถานะและความสำคัญ

คุณอาจจะคิดว่า index card เพียงใบเดียวไม่น่าจะมีข้อมูลเพียงพอที่จะเอาไป implement ส่วนประกอบของแอปฯ ได้ ซึ่งคุณคิดถูกแล้ว! และนั่นแหละคือประเด็นสำคัญ การทำข้อกำหนดของ requirements ให้สั้นลง จะช่วยกระตุ้นให้เหล่านักพัฒนาต้องถามคำถามเพื่อความชัดเจน มันคือการเสริมสร้างกระบวนการ feedback ระหว่างลูกค้าและผู้เขียนโค้ดก่อนและระหว่างการสร้างโค้ดแต่ละชิ้นขึ้นมา

การทำ Overspecification

อันตรายที่ใหญ่อีกอย่างหนึ่งในการทำเอกสาร requirements คือการระบุรายละเอียดที่เจาะจงเกินไป requirements ที่ดีควรจะมีความเป็นนามธรรม (abstract) ในเรื่องของ requirements ข้อความที่เรียบง่ายที่สุดที่สะท้อนถึงความต้องการทางธุรกิจได้อย่างแม่นยำคือสิ่งที่ดีที่สุด แต่นั่นไม่ได้หมายความว่าคุณจะสามารถคลุมเครือได้นะ—คุณต้องระบุหัวใจสำคัญของกฎเกณฑ์ต่าง ๆ (underlying semantic invariants) ไว้ในรูปแบบของ requirements และบันทึกวิธีการทำงานเฉพาะเจาะจงในปัจจุบันเอาไว้เป็น policy

Requirements ไม่ใช่ architecture ไม่ใช่ design และไม่ใช่ user interface แต่มันคือ "ความต้องการ" (need)

ขอเพิ่มอีกนิดเดียว... (Just One More Wafer-Thin Mint…)

ความล้มเหลวของโปรเจกต์หลาย ๆ ครั้งมักถูกโยนความผิดไปให้กับการขยายขอบเขตของงาน—ที่เรียกกันว่า feature bloat, creeping featurism หรือ requirements creep นี่คือแง่มุมหนึ่งของทฤษฎีกบต้ม (boiled-frog syndrome) จาก Topic 4, ​_Stone Soup and Boiled Frogs_​ เราจะทำอย่างไรดีเพื่อป้องกันไม่ให้ requirements ค่อย ๆ คืบคลานเข้ามาจัดการเรา?

คำตอบ (อีกครั้งหนึ่ง) ก็คือ feedback นั่นเอง ถ้าคุณทำงานกับลูกค้าแบบเป็นรอบ ๆ (iterations) และมีการให้ feedback กันตลอดเวลา ลูกค้าก็จะได้รับรู้ถึงผลกระทบของการ "ขอเพิ่มอีกฟีเจอร์เดียว" ด้วยตัวเอง พวกเขาจะได้เห็นว่ามี story card ใบใหม่ถูกแปะลงบนบอร์ด และพวกเขาก็จะได้ช่วยกันตัดสินใจเลือก card ใบอื่นย้ายออกไปในรอบหน้าเพื่อหลีกทางให้ card ใบนี้แทน feedback นั้นให้ผลดีทั้งสองทาง

สร้างและรักษา Glossary ไว้ให้ดี

ทันทีที่คุณเริ่มคุยกันเรื่อง requirements ผู้ใช้งานและผู้เชี่ยวชาญ (domain experts) จะเริ่มใช้คำบางคำที่มีความหมายเฉพาะสำหรับพวกเขา เช่น พวกเขาอาจจะแบ่งแยกความแตกต่างระหว่างคำว่า "ลูกข่าย" (client) กับ "ลูกค้า" (customer) ดังนั้นมันจึงไม่เหมาะสมที่จะเอาคำใดคำหนึ่งมาใช้เรียกแทนกันมั่ว ๆ ในระบบ

จงสร้างและรักษา project glossary เอาไว้—คือที่แห่งหนึ่งที่ใช้รวบรวมและนิยามคำศัพท์และคำเฉพาะต่าง ๆ ที่ใช้ในโปรเจกต์ ทุกคนที่มีส่วนร่วมในโปรเจกต์ ตั้งแต่ผู้ใช้งานปลายทางไปจนถึงพนักงานฝ่าย support ควรจะใช้ glossary เล่มนี้เพื่อให้ข้อมูลเป็นไปในทิศทางเดียวกัน ซึ่งนั่นหมายความว่า glossary จะต้องเข้าถึงได้ง่ายจากทุกที่—ซึ่งการทำเป็น online documentation เป็นทางเลือกที่ดีมาก

Tip 80 ใช้ Project Glossary

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

ส่วนที่เกี่ยวข้องอื่น ๆ รวมถึง

  • Topic 5, ​_Good-Enough Software_​
  • Topic 7, ​_Communicate!_​
  • Topic 11, ​_Reversibility_​
  • Topic 13, ​_Prototypes and Post-it Notes_​
  • Topic 23, ​_Design by Contract_​
  • Topic 43, ​_Stay Safe Out There_​
  • Topic 44, ​_Naming Things_​
  • Topic 46, ​_Solving Impossible Puzzles_​
  • Topic 52, ​_Delight Your Users_​

แบบฝึกหัด

Exercise 33 (possible answer)

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

  1. The response time must be less than ~500ms.
  2. Modal windows will have a gray background.
  3. The application will be organized as a number of front-end processes and a back-end server.
  4. If a user enters non-numeric characters in a numeric field, the system will flash the field background and not accept them.
  5. The code and data for this embedded application must fit within 32Mb.

ความท้าทาย

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

  • เลือกปัญหาที่คุณกำลังหาทางแก้ไขอยู่ซึ่งไม่เกี่ยวข้องกับคอมพิวเตอร์ แล้วลองสร้าง requirements สำหรับวิธีการแก้ปัญหาที่ไม่ต้องพึ่งพาคอมพิวเตอร์ดูสิ