คุณเคยพบปัญหานี้หรือไม่
” ความต้องการแค่จิ๋มมด แต่ระบบไม่เสร็จซักที”
“ความต้องการไม่เคยหมด แต่กำหนดการเท่าเดิม”
มันคือปัญหาที่เกิดขึ้นบ่อยครั้งระหว่าง User (ผู้ใช้งาน) กับ Developer (คนพัฒนาโปรแกรม)
คำถามคือ “ทำไมหล่ะ ?”
หากย้อนกลับไป ส่วนใหญ่ความต้องการระบบใหม่ๆจะมาจากทาง User ว่าอยากได้อะไร ต้องการระบบไปใช้งานแบบใด ทาง Developer ก็รับโจทย์นั้นไป แล้วก็ทำมาให้ User ใช้งาน อย่างสุขสมอารมณ์หมาย ประหนึ่งเหมือนแม่การะเกด วาดเครื่องกรองน้ำ ให้จีนฮง แบบงงๆ แต่ก็ทำออกมาได้สำเร็จ
แต่หลายครั้งก็ขอหมูได้หมา “เพราะอะไร ?”
“User ไม่เข้าใจสิ่งที่ตนเองต้องการ” (อาจเข้าใจ แต่อธิบายออกมาไม่ได้)
“Developer ไม่เข้าใจว่า user ต้องการอะไร” (อาจเข้าใจ แต่ขาดประสบการณ์)
ซึ่งเป็นปัญหาคลาสสิกมาก เพราะต่างฝ่ายมีการรับและสื่อสารข้อมูลต่างกัน ว่าง่ายๆ คือคุยกันคนละภาษา และอยู่ในโซนความรู้ที่ต่างกัน อีกฝั่ง Business อีกฝั่ง Technical นี่แหละปัญหา
แก้ปัญหาไม่ยาก “ง่ายแสนง่าย”
Developer จะมีหน้าที่ในการไตร่สวน เพื่อตะล่อมหาความจริง ว่า user ต้องการคือแบบนี้นะ ทำหน้าจอตัวอย่างมาให้ดูก่อน เพื่อตรวจสอบว่าเข้าใจตรงกันไหม ก่อนลงมือจริง แล้วฟันธง ให้ user ยอมรับว่า “เอาแบบนี้นะ” ปัญหาขอหมูได้หมาก็หมดไป
ตัดภาพมาฝั่ง user บ้าง
User ต้องหาข้อมูลต่างๆมา เพื่อเป็นตัวอย่างให้ทาง developer ดูว่า หมูที่ต้องการหน้าตาแบบนี้นะ มีขากี่ขา ตัวอ้วนๆหน่อย แต่ตัวไม่ใหญ่นะ ตัวสีขาว มีหูเหมือนหมี อะไรก็ว่าไป เพื่อให้ทาง developer เห็นภาพง่ายๆ เพราะหมูของ developer อาจไม่ได้มีหน้าตาแบบนี้เหมือนกัน
ได้หมูมาแล้ว อย่าลืมว่า “หมูอาจบินได้”
กว่า Developer จะทำทุกอย่างมาให้พร้อมลองใช้งาน “กาลเวลาเปลี่ยน ความต้องการเปลี่ยน” แถม user เข้ามาร่วมวงปาร์ตี้มากขึ้น ทีนี้หล่ะ “ตรงนี้น่าจะเป็นแบบนี้” “ตรงนั้นเพิ่มอันนี้เข้าไปหน่อย” หมูธรรมดาๆตัวนึง จะเริ่มบินได้ละ และถ้าไม่เปลี่ยนแปลง ระบบนี้ก็ไม่ตอบโจทย์ทางธุรกิจ พร้อมกับคำถามว่า “กี่วันเสร็จ”
User กล่าว “ให้หมูมันเดินได้ก่อนเหอะ”
ทดสอบกี่ครั้ง ๆ ก็ยังทำงานไม่ได้ตามที่ขอไว้ กดนั่นก็ไม่ขึ้นข้อมูล กดนี่ก็แสดงอะไรก็ไม่รู้ จะเสร็จทันไหมเนี่ย ไม่เห็นยากเลย พี่ๆ ช่วยดูอันนี้หน่อยทำไงดี ใช่ที่พี่ต้องการไหม และแล้ว User ก็งอกเงยดั่งทุ่งข้าวสาลี
User ที่ใช่ “คือใครบ้าง”
User ที่มีอำนาจตัดสินใจ เหมือนเวลาไปเป็นเซลล์ขายของ เราก็ต้องเข้าหาคนที่มีอำนาจตัดสินใจ ซึ่งอาจไม่ใช่คนถือเงิน
User ที่ต้องใช้งานระบบโดยตรง ถ้าเป็นระบบเซลล์ ก็ต้องไปคุยเซลล์ด้วย คุยกับหัวหน้าเซลล์คงไม่พอ
User ที่ต้องให้ข้อมูลหรือรับผลลัพธ์จากระบบ หมายถึง ต้องดูข้อมูลมาจากใคร และต้องส่งไปให้ใคร (แต่บางระบบก็จะเป็น จากระบบสู่ระบบ)
User ที่ต้องตรวจสอบระบบ หมายถึง คนที่จะบอกว่าต้องทำอยู่ภายใต้เงื่อนไขอะไรบ้าง เช่นหน้าจอต้องเป็นสีชมพู หรือเงื่อนไขทาง IT เป็นต้น
ไม่ว่าจะ “User กาก หรือ Developer ห่วย
เกิดจากความไม่เข้าใจสิ่งที่ตนกำลังทำ ขาดประสบการณ์ ขาดองค์ความรู้ และขาดคนประสานตรงกลาง เพราะจริง ๆ แล้ว user กับ developer มีวิธีคิดและความรู้ ทับซ้อนกันน้อยมาก เพราะฉะนั้น developer ต้องแบ่งเวลามาศึกษาเชิง Business บ้าง และ User ก็ต้องเข้าใจเชิง Technical บ้างเช่นกัน
*จะเขียนเรื่อง SA ลงไปด้วย แต่กลัวจบไม่ลง
*ปกติถ้าเป็นการจ้างบริษัทภายนอกมาพัฒนาระบบให้ จะมีเงื่อนไขของสัญญาตีกรอบไว้ เพื่อปกป้องผลประโยชน์ของทั้งผู้จ้างและผู้ว่าจ้าง
User กาก หรือ Developer ห่วย
” ความต้องการแค่จิ๋มมด แต่ระบบไม่เสร็จซักที”
“ความต้องการไม่เคยหมด แต่กำหนดการเท่าเดิม”
มันคือปัญหาที่เกิดขึ้นบ่อยครั้งระหว่าง User (ผู้ใช้งาน) กับ Developer (คนพัฒนาโปรแกรม)
คำถามคือ “ทำไมหล่ะ ?”
หากย้อนกลับไป ส่วนใหญ่ความต้องการระบบใหม่ๆจะมาจากทาง User ว่าอยากได้อะไร ต้องการระบบไปใช้งานแบบใด ทาง Developer ก็รับโจทย์นั้นไป แล้วก็ทำมาให้ User ใช้งาน อย่างสุขสมอารมณ์หมาย ประหนึ่งเหมือนแม่การะเกด วาดเครื่องกรองน้ำ ให้จีนฮง แบบงงๆ แต่ก็ทำออกมาได้สำเร็จ
แต่หลายครั้งก็ขอหมูได้หมา “เพราะอะไร ?”
“User ไม่เข้าใจสิ่งที่ตนเองต้องการ” (อาจเข้าใจ แต่อธิบายออกมาไม่ได้)
“Developer ไม่เข้าใจว่า user ต้องการอะไร” (อาจเข้าใจ แต่ขาดประสบการณ์)
ซึ่งเป็นปัญหาคลาสสิกมาก เพราะต่างฝ่ายมีการรับและสื่อสารข้อมูลต่างกัน ว่าง่ายๆ คือคุยกันคนละภาษา และอยู่ในโซนความรู้ที่ต่างกัน อีกฝั่ง Business อีกฝั่ง Technical นี่แหละปัญหา
แก้ปัญหาไม่ยาก “ง่ายแสนง่าย”
Developer จะมีหน้าที่ในการไตร่สวน เพื่อตะล่อมหาความจริง ว่า user ต้องการคือแบบนี้นะ ทำหน้าจอตัวอย่างมาให้ดูก่อน เพื่อตรวจสอบว่าเข้าใจตรงกันไหม ก่อนลงมือจริง แล้วฟันธง ให้ user ยอมรับว่า “เอาแบบนี้นะ” ปัญหาขอหมูได้หมาก็หมดไป
ตัดภาพมาฝั่ง user บ้าง
User ต้องหาข้อมูลต่างๆมา เพื่อเป็นตัวอย่างให้ทาง developer ดูว่า หมูที่ต้องการหน้าตาแบบนี้นะ มีขากี่ขา ตัวอ้วนๆหน่อย แต่ตัวไม่ใหญ่นะ ตัวสีขาว มีหูเหมือนหมี อะไรก็ว่าไป เพื่อให้ทาง developer เห็นภาพง่ายๆ เพราะหมูของ developer อาจไม่ได้มีหน้าตาแบบนี้เหมือนกัน
ได้หมูมาแล้ว อย่าลืมว่า “หมูอาจบินได้”
กว่า Developer จะทำทุกอย่างมาให้พร้อมลองใช้งาน “กาลเวลาเปลี่ยน ความต้องการเปลี่ยน” แถม user เข้ามาร่วมวงปาร์ตี้มากขึ้น ทีนี้หล่ะ “ตรงนี้น่าจะเป็นแบบนี้” “ตรงนั้นเพิ่มอันนี้เข้าไปหน่อย” หมูธรรมดาๆตัวนึง จะเริ่มบินได้ละ และถ้าไม่เปลี่ยนแปลง ระบบนี้ก็ไม่ตอบโจทย์ทางธุรกิจ พร้อมกับคำถามว่า “กี่วันเสร็จ”
User กล่าว “ให้หมูมันเดินได้ก่อนเหอะ”
ทดสอบกี่ครั้ง ๆ ก็ยังทำงานไม่ได้ตามที่ขอไว้ กดนั่นก็ไม่ขึ้นข้อมูล กดนี่ก็แสดงอะไรก็ไม่รู้ จะเสร็จทันไหมเนี่ย ไม่เห็นยากเลย พี่ๆ ช่วยดูอันนี้หน่อยทำไงดี ใช่ที่พี่ต้องการไหม และแล้ว User ก็งอกเงยดั่งทุ่งข้าวสาลี
User ที่ใช่ “คือใครบ้าง”
User ที่มีอำนาจตัดสินใจ เหมือนเวลาไปเป็นเซลล์ขายของ เราก็ต้องเข้าหาคนที่มีอำนาจตัดสินใจ ซึ่งอาจไม่ใช่คนถือเงิน
User ที่ต้องใช้งานระบบโดยตรง ถ้าเป็นระบบเซลล์ ก็ต้องไปคุยเซลล์ด้วย คุยกับหัวหน้าเซลล์คงไม่พอ
User ที่ต้องให้ข้อมูลหรือรับผลลัพธ์จากระบบ หมายถึง ต้องดูข้อมูลมาจากใคร และต้องส่งไปให้ใคร (แต่บางระบบก็จะเป็น จากระบบสู่ระบบ)
User ที่ต้องตรวจสอบระบบ หมายถึง คนที่จะบอกว่าต้องทำอยู่ภายใต้เงื่อนไขอะไรบ้าง เช่นหน้าจอต้องเป็นสีชมพู หรือเงื่อนไขทาง IT เป็นต้น
ไม่ว่าจะ “User กาก หรือ Developer ห่วย
เกิดจากความไม่เข้าใจสิ่งที่ตนกำลังทำ ขาดประสบการณ์ ขาดองค์ความรู้ และขาดคนประสานตรงกลาง เพราะจริง ๆ แล้ว user กับ developer มีวิธีคิดและความรู้ ทับซ้อนกันน้อยมาก เพราะฉะนั้น developer ต้องแบ่งเวลามาศึกษาเชิง Business บ้าง และ User ก็ต้องเข้าใจเชิง Technical บ้างเช่นกัน
*จะเขียนเรื่อง SA ลงไปด้วย แต่กลัวจบไม่ลง
*ปกติถ้าเป็นการจ้างบริษัทภายนอกมาพัฒนาระบบให้ จะมีเงื่อนไขของสัญญาตีกรอบไว้ เพื่อปกป้องผลประโยชน์ของทั้งผู้จ้างและผู้ว่าจ้าง