ปัญหา, ปัญหาเบื้องหลังปัญหาและปัญหาที่ไม่ใช่ปัญหา – ความต้องการ, ความต้องการเบื้องหลังความต้องการ และความต้องการที่ไม่ใช่ความต้องการ
- stakeholder หรือ domain expert แต่ละรายอาจมีความรู้ ประสบการณ์ บทบาทหน้าที่ ที่ต่างกัน ทำให้ความเข้าใจในปัญหาเดียวกันอาจแตกต่างกันได้
- เมื่อพบปัญหาแล้วต้องค้นหาแก่นของปัญหา (core problem/domain problem) บริบทของปัญหา (problem context) และ สาเหตุ (cause)
- หนึ่งปัญหาอาจเกิดจากหลายสาเหตุ และน้ำหนักหรือความเกี่ยวข้องต่อปัญหาของแต่ละสาเหตุอาจไม่เท่ากัน จึงส่งผลต่อความอ่อนไหวของปัญหาได้
- เมื่อพบปัญหาแล้วต้องวิเคราะห์ต่อไป เพื่อพิสูจน์ว่าใช่ปัญหาที่แท้จริงหรือไม่ หรือเป็นเพียงสมมติฐานหรือการคิดไปเอง และมีปัญหาอื่นซ่อนอยู่หรือไม่
หลายครั้งที่มักเกิดคำถามขึ้นว่า “อะไรคือปัญหาที่แท้จริง?” บางทีอาจต้องถามกลับไปว่า “แล้วทำไมจึงคิดว่ามีปัญหา?” นี่คือการนำไปสู่การค้นหาว่าแท้จริงแล้ว ‘ปัญหา’ คืออะไร?
ผู้ที่ทำหน้าที่เกี่ยวกับ requirement ควรมีทักษะด้านการให้คำปรึกษา (consulting) หรือเป็นที่ปรึกษาที่ดี เพื่อค้นหาความต้องการที่แท้จริง (requirement discovering) ที่ stakeholder อาจไม่ได้บอก หรือบอกไม่หมด เพราะธรรมชาติคนเราถ้าไม่สนิทกันจริงๆ ก็จะไม่กล้าพูดความในใจทั้งหมด หรือบางคนอาจมีความคิดความต้องการเต็มหัว แต่พูดไม่เก่ง อธิบายไม่เก่ง การเก็บรวบรวมปัญหาและความต้องการแล้วพิสูจน์ว่าใช่จริงๆ จึงเป็นขั้นตอนที่สำคัญมาก เนื่องจากอาจทำให้เก็บรวบรวมความต้องการไม่ครอบคลุมหรือคลาดเคลื่อนได้
อุปสรรคใด ๆ ที่ทำให้การมุ่งสู่เป้าหมายในชีวิตหรือการดำเนินงานไม่สะดวกราบรื่นจึงนิยามว่า ‘ปัญหา’ และหลายครั้งอีกเช่นกันที่เรามักสร้างอุปสรรคหรือปัญหาขึ้นมาเองในใจ ซึ่งแท้จริงแล้วอาจไม่ใช่ปัญหาก็ได้ ดังนั้นเมื่อมีความสงสัยว่าจะใช่ปัญหาจริง ๆ หรือไม่ จึงสมควรตั้งเป็นสมมติฐานไว้ก่อน แล้วนึกถึงหลักทางวิทยาศาสตร์ ที่ต้องพิสูจน์ให้ได้ หนึ่งสมมติฐานอาจมีแนวทางการทดลองได้มากมาย และในหนึ่งการทดลองอาจมีวิธีปฏิบัติหรือมีปัจจัยที่เกี่ยวข้องได้มากมาย การทดสอบก็มีได้มากมาย เสมือนเพียงหนึ่งปัญหาก็ทำให้เกิดประเด็นที่ต้องขบคิดมากมายเพิ่มขึ้นเป็นรูปลักษณะต้นไม้หัวกลับ
การทำความเข้าใจกับปัญหาสิ่งแรกจำเป็นต้องมองให้เห็นแก่นและบริบทของปัญหาเสียก่อน
ตัวอย่างที่ 1
เมื่อมีชายคนหนึ่งเดินมาถามคุณด้วยประโยค
“ไม่ทราบตอนนี้เวลาเท่าไรครับ?”
ในประโยคนี้แสดงให้เห็นว่าปัญหาของชายคนนี้คือไม่ทราบเวลา และแก่นของปัญหานี้คือสิ่งที่ช่วยบอกเวลาได้ จากนั้นคุณสังเกตว่าเขาไม่ได้สวมนาฬิกา คุณจึงถามเขากลับไปว่า
“คุณมีโทรศัพท์มือถือไหมครับ?”
ชายคนนั้นพยักหน้า คุณจึงเสริมต่อว่า
“โทรศัพท์มือถือมีเวลาบอกครับ”
สิ่งที่คุณตอบไปคือโซลูชั่น หรือแนวทางแก้ไขปัญหา เพราะคนเราหลายครั้งเมื่อมีปัญหาก็ไม่วิเคราะห์ให้เห็นแก่นแท้เสียก่อนก็พยายามค้นหาโซลูชั่นให้ได้ เมื่อไม่เข้าใจแก่นและสาเหตุของปัญหาแท้จริงการค้นหาโซลูชั่นที่เหมาะสมก็เป็นไปได้ยาก
องค์ประกอบหลักสำหรับการกำหนดปัญหาคือ
- ชื่อปัญหา
- แก่นของปัญหา
- สาเหตุของปัญหา
- บริบทของปัญหา
จากตัวอย่างของชายที่ไม่ทราบเวลา ปัญหาของเขาคือไม่ทราบเวลา ปัญหาเบื้องหลังปัญหาคือเขาลืมไปว่าโทรศัพท์มือถือมีฟังก์ชั่นนาฬิกา และปัญหาที่ไม่ใช่ปัญหาคือเขาไม่จำเป็นต้องพึ่งคนอื่นเลย โดยสามารถแก้ไขปัญหาได้ด้วยตนเองด้วยซ้ำ
ตัวอย่างที่ 2
ทีมดาวน์โหลด web application framework มาตัวหนึ่ง แล้วทางทีมต้องการสร้างส่วนการเข้ารหัสและถอดรหัสข้อมูลในระหว่างการรับ-ส่งข้อมูลขึ้นมาเอง โดยไม่วิเคราะห์และศึกษาเฟรมเวิร์กตัวนั้นให้ละเอียด เพราะหากดูให้ดีแล้ว อาจมีฟีจเจอร์ที่ต้องการนี้อยู่แล้วก็ได้ โดยไม่ต้องเสียเวลาพัฒนาขึ้นมาใหม่เลย ดังนั้นนี่จึงเป็นปัญหาที่ไม่ใช่ปัญหาแท้จริง
ตัวอย่างที่เคยพบมากับตัว
- ผู้บริหารท่านหนึ่งถามผมว่าอยากซื้อระบบ SAP คิดว่าน่าจะช่วยบริษัทได้ดี เอาเข้าจริงพอวิเคราะห์แล้ว พบว่าแค่ซื้อระบบ ERP (Enterprise Resource Planning) ธรรมดาก็ใช้ได้แล้ว อีกรายหนึ่งอยากได้ SAP เหมือนกัน อยากซื้อทุกโมดูล เอาเข้าจริง ซื้อแค่โมดูลบัญชีกับการเงิน ก็ช่วยงานได้ดีแล้ว
- เคยพบผู้บริหารหลายราย ท่าทางไปฟังสัมมนาหรือโดนพวกเวนเดอร์หรือนักวิชาการฝันหวานเป่าหูมา กลับมาบริษัทเลยอยากทำ SOA (Service-Oriented Architecture) เอาเข้าจริง แค่ปรับปรุง system integration ของระบบต่างๆ ให้ดีขึ้นเขาก็ปลื้มแล้ว บางรายอยากได้ซอฟต์แวร์ BI (Business Intelligence) เอาเข้าจริง แค่ report tool เจ๋งๆ สักตัวก็ช่วยได้เยอะแล้ว ถูกกว่าสิบเท่า
- ผู้ใช้กลุ่มหนึ่งอยากให้ระบบมีเวอร์ชั่น mobile application เพราะจะได้สะดวกและดูทันสมัย พอวิเคราะห์ก็พบว่าแทบไม่มีโอกาสได้ใช้เลย เพราะปกติผู้ใช้ต้องทงานำในออฟฟิศใช้พีซีอยู่แล้ว หากพัฒนา mobile application ไหนจะเปลืองเวลาและงบฯ ขึ้น และยังเปลืองแรงในการดูแลรักษาเวลา interface เปลี่ยนอีก
- เคยพบ software architect ของแบงก์ชาติคนหนึ่ง เล่าให้ผมฟังว่ามีผู้ใช้คนหนึ่งอยากให้ระบบออกรายงานตัวหนึ่งให้เสร็จและแสดงผลบนหน้าจอภายในระยะเวลาที่สั้นมาก ทั้งที่เป็นรายงานขนาดใหญ่ มากๆ architect คนนั้นอธิบายอย่างไรผู้ใช้ก็ไม่ยอม เขาบอกว่า “คงต้องใช้ดาวเทียมล่ะมั้ง จึงจะส่งข้อมูลได้เร็วอย่างที่ผู้ใช้ต้องการได้…” และพอเขาวิเคราะห์ process งานแล้วก็พบว่าจริงๆ ผู้ใช้สามารถรอได้นานกว่าที่บอกโดยไม่จำเป็นต้องรีบใช้ข้อมูลเร็วขนาดที่ร้องขอเลย
ตัวอย่างสุดท้ายสุดคลาสสิกที่แพร่หลายในอินเทอร์เน็ต
การจะเข้าใจปัญหาและความต้องการแท้จริง ไม่ต่างจากการจะทำความเข้าใจใครสักคน หากเข้าไม่ถึงตัวตนของเขา ยากนักที่จะเข้าใจเขา ลองศึกษาเกี่ยวกับ ‘นพลักษณ์’ (Enneagram) อาจช่วยได้ หรือฝึกด้านการอ่านคน เช่น อ่านจากสีหน้า น้ำเสียง บุคลิก ดวง โหงวเฮ้ง ทัศนคติ มุมมอง ฯลฯ อย่าหัวเราะนะครับ ผมเองก็ศึกษาเรื่องพวกนี้มาหมดแล้ว ยกเว้นเรื่องดวงกับโหงวเฮ้งที่แค่พอศึกษาคร่าวๆ ไม่ได้จริงจัง มันช่วยได้จริงๆ เรื่องบางเรื่องไม่ต้องถามไม่ต้องคุยกันมากให้เสียเวลา ก็ล้วงตับไตไส้พุงทั้งปัญหาและความต้องการที่แท้จริงกันออกมาจนหมดเปลือก และเป็นเทคนิคที่ผมใช้บ่อยมากกว่าพวกเทคนิค requirement gathering ในทางทฤษฏีทั้งหลายอีก เนื่องจากผมเป็นที่ปรึกษาด้วย เลยมีโอกาสได้ศึกษาเรื่องพวกนี้ เพราะต้องใช้ในงาน จึงได้ประโยชน์จากหลักการเหล่านี้ และผมชอบศึกษาด้าน soft skill อยู่แล้ว และที่สำคัญ… ผมชอบวิธีทางอ้อมมากกว่าทางตรง เพราะหลายครั้ง…มันเข้าถึงประเด็นได้เร็วและชัดเจนกว่า
อีกแนวทางที่ ‘เวิร์ก’ เพื่อวิเคราะห์ว่าสมมติฐานนั้น ๆ เป็นปัญหาหรือความต้องการที่แท้จริงหรือไม่ ต้องใช้หลักการวิเคราะห์ตนเอง คือต้องวิเคราะห์ตัวเองก่อน ชำนาญอะไร ถนัดอะไร มีอะไรอยู่ในมือบ้าง มีข้อบกพร่องตรงไหน มีจุดอ่อนตรงไหนบ้าง เพราะหากตัวเรายังไม่เข้าใจตัวเอง หรือในทีมเดียวกันเองยังไม่เข้าใจกันเอง หรือเอาเฟรมเวิร์กอะไรมาใช้ก็ยังไม่เข้าใจหลักการและฟีจเจอร์ที่แท้จริง หรือยังไม่ทันเข้าใจ requirements ขององค์กร (ลูกค้า) ให้ดีก่อนก็จะรีบพัฒนาระบบฯ แล้ว หากเป็นอย่างนี้ก็จะมีการจินตนาการสร้างปัญหา ‘เทียม’ หรือ ความต้องการ ‘เทียน’ ขึ้นมาเป็นกำแพงสูงขัดขวางการทำงานของตัวเองหรือทีมไปโดยไม่รู้ตัว กลายเป็นไป develop ในสิ่งที่เขาไม่ได้ต้องการแท้จริง เสียเวลา เสียงบฯ เสีย (แรง) คน
เทคนิคการพิสูจน์ปัญหามีหลายวิธี เพื่อให้เข้ากับแนวทางใน blog ของผม ซึ่งเน้นในแนว requirement engineering จึงขอแนะนำสั้นๆ (สำหรับรายละเอียดอ่านได้ในหัวข้อ Non-Functional Req. & Architectural Req.) นั่นคือ
- ระบุ constraint (ข้อจำกัด หรือ อุปสรรค หรือ แรงกดดัน) ทั้งด้าน business และ เทคนิค ทั้งภายในและภายนอกองค์กร
- ระบุ stakeholder (ผู้มีส่วนเกี่ยวข้องในงานหรือโครงการ)
- ระบุ concern (ข้อกังวล) จาก stakeholder ซึ่งต้องระบุว่าแต่ละ concern สัมพันธ์กับ constraint ใด
- ระบุ business goal (เป้าหมายธุรกิจ หรือ เป้าหมายงานหรือโครงการ) ซึ่งต้องระบุว่าสัมพันธ์กับ concern ใด
จากนั้นแล้วค่อยเริ่มหาพวก system feature, functional requirement, non-functional requirement ฯลฯ
จำง่ายๆ ไว้ว่า… ไม่มีความปัญหาและความต้องการใด ที่อยู่ๆ ก็เกิดขึ้นเองเฉยๆ มันต้องมีที่มาที่ไป หากอยากเข้าใจอย่างลึกซึ้ง ลองศึกษาเรื่อง ‘ปฏิจจสมุปบาท’ และ ‘อิทัปปัจจยตา’ ดูครับ 🙂
requirement ที่จะเก็บรวบรวม ต้องเป็นความต้องการที่ ‘แท้จริง’ ดังนั้นบางครั้งเมื่อเก็บรวบรวมมาแล้ว อาจต้องนำมาวิเคราะห์ต่อในช่วง requirement analysis ดังนั้นการพิสูจน์ปัญหาและความต้องการอาจไม่สามารถทำได้สมบูรณ์ในช่วงการเก็บรวบรวมความต้องการ (requirement gathering) ก็ได้ ฉะนั้นช่วง requirement gather, requirement analysis, requirement management ควรออกแบบ process การทำงานให้เป็นแบบ iterative development อย่าทำเป็นแบบ waterfall หรือ step-by-step เพราะอาจพลาดได้หากไม่ชำนาญพอ… โครงการไอทีจำนวนมากจบไม่สวยเพราะสาเหตุนี้นี่ล่ะครับ
ในทางพุทธ…ปัญหาเกิดจากภายในตัว และ วิธีแก้ก็เกิดจากภายในตัว
ตัวเรามักสร้างปัญหาจาก ความกลัว ความไม่รู้ ความไม่ชำนาญ ส่วนความต้องการ (อยากมี อยากได้) ก็ไม่ต่างกัน… นี่ก็อีกเทคนิคที่ผมชอบใช้ ศึกษาธรรมะ หลักปรัชญา เซน สมาธิ จิต ฯ ช่วยให้เข้าใจตัวเรา สิ่งรอบตัว และ คนอื่น ได้ง่ายขึ้น… จริงๆ นะไม่ได้โม้ 🙂
