พิสูจน์ปัญหาและความต้องการ

ปัญหา, ปัญหาเบื้องหลังปัญหาและปัญหาที่ไม่ใช่ปัญหา – ความต้องการ, ความต้องการเบื้องหลังความต้องการ และความต้องการที่ไม่ใช่ความต้องการ

  • 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 งานแล้วก็พบว่าจริงๆ ผู้ใช้สามารถรอได้นานกว่าที่บอกโดยไม่จำเป็นต้องรีบใช้ข้อมูลเร็วขนาดที่ร้องขอเลย

ตัวอย่างสุดท้ายสุดคลาสสิกที่แพร่หลายในอินเทอร์เน็ต

เรื่องตลกแต่จริง ของการ transform requirement สู่ product ในวงการไอที

การจะเข้าใจปัญหาและความต้องการแท้จริง ไม่ต่างจากการจะทำความเข้าใจใครสักคน หากเข้าไม่ถึงตัวตนของเขา ยากนักที่จะเข้าใจเขา ลองศึกษาเกี่ยวกับ ‘นพลักษณ์’ (Enneagram) อาจช่วยได้ หรือฝึกด้านการอ่านคน เช่น อ่านจากสีหน้า น้ำเสียง บุคลิก ดวง โหงวเฮ้ง ทัศนคติ มุมมอง ฯลฯ อย่าหัวเราะนะครับ ผมเองก็ศึกษาเรื่องพวกนี้มาหมดแล้ว ยกเว้นเรื่องดวงกับโหงวเฮ้งที่แค่พอศึกษาคร่าวๆ ไม่ได้จริงจัง มันช่วยได้จริงๆ เรื่องบางเรื่องไม่ต้องถามไม่ต้องคุยกันมากให้เสียเวลา ก็ล้วงตับไตไส้พุงทั้งปัญหาและความต้องการที่แท้จริงกันออกมาจนหมดเปลือก และเป็นเทคนิคที่ผมใช้บ่อยมากกว่าพวกเทคนิค requirement gathering ในทางทฤษฏีทั้งหลายอีก เนื่องจากผมเป็นที่ปรึกษาด้วย เลยมีโอกาสได้ศึกษาเรื่องพวกนี้ เพราะต้องใช้ในงาน จึงได้ประโยชน์จากหลักการเหล่านี้ และผมชอบศึกษาด้าน soft skill อยู่แล้ว และที่สำคัญ… ผมชอบวิธีทางอ้อมมากกว่าทางตรง เพราะหลายครั้ง…มันเข้าถึงประเด็นได้เร็วและชัดเจนกว่า

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

เทคนิคการพิสูจน์ปัญหามีหลายวิธี เพื่อให้เข้ากับแนวทางใน blog ของผม ซึ่งเน้นในแนว requirement engineering จึงขอแนะนำสั้นๆ (สำหรับรายละเอียดอ่านได้ในหัวข้อ Non-Functional Req. & Architectural Req.) นั่นคือ

  1. ระบุ constraint (ข้อจำกัด หรือ อุปสรรค หรือ แรงกดดัน) ทั้งด้าน business และ เทคนิค ทั้งภายในและภายนอกองค์กร
  2. ระบุ stakeholder (ผู้มีส่วนเกี่ยวข้องในงานหรือโครงการ)
  3. ระบุ concern (ข้อกังวล) จาก stakeholder ซึ่งต้องระบุว่าแต่ละ concern สัมพันธ์กับ constraint ใด
  4. ระบุ 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 เพราะอาจพลาดได้หากไม่ชำนาญพอ… โครงการไอทีจำนวนมากจบไม่สวยเพราะสาเหตุนี้นี่ล่ะครับ

 

ในทางพุทธ…ปัญหาเกิดจากภายในตัว และ วิธีแก้ก็เกิดจากภายในตัว

ตัวเรามักสร้างปัญหาจาก ความกลัว ความไม่รู้ ความไม่ชำนาญ ส่วนความต้องการ (อยากมี อยากได้) ก็ไม่ต่างกัน… นี่ก็อีกเทคนิคที่ผมชอบใช้ ศึกษาธรรมะ หลักปรัชญา เซน สมาธิ จิต ฯ ช่วยให้เข้าใจตัวเรา สิ่งรอบตัว และ คนอื่น ได้ง่ายขึ้น… จริงๆ นะไม่ได้โม้ 🙂

Advertisements

ใส่ความเห็น

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / เปลี่ยนแปลง )

Twitter picture

You are commenting using your Twitter account. Log Out / เปลี่ยนแปลง )

Facebook photo

You are commenting using your Facebook account. Log Out / เปลี่ยนแปลง )

Google+ photo

You are commenting using your Google+ account. Log Out / เปลี่ยนแปลง )

Connecting to %s