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

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

ในเรื่องการทำงานก็ไม่ต่างกัน


วันก่อนประชุมกับคุณหัวหน้า
ในสายตา Business Analyst กับ Manager เห็นตรงกันว่า
การที่งานส่งต่อให้ทีมนักพัฒนา
แล้วทีมก็นำไปพัฒนาขึ้น โดยไม่เคยมีคำถามกลับมายังผู้ออกแบบ
หรือกลับมาที่ Manager เลย
หรือถ้ามี ก็น้อยมากๆ
นั่นมักจะเป็นสัญญาณว่า งานนั้นเกิดปัญหาเข้าแล้ว
ถึงแม้ว่า ฝ่ายออกแบบจะทำ spec ไปให้อย่างละเอียดก็เถอะ

ปัญหาหลักจากความ “โนพลอมแพลม” ของทีมนักพัฒนาก็คือ
สิ่งที่สร้าง กับสิ่งที่ควรจะเป็น ไม่ตรงกัน
ทีมนักพัฒนามักจะมี motto ประจำการทำงานว่า “Get Things Done”
Spec มาแบบไหน ก็ทำตรงๆตามเสป็กไปอย่างซื่อตรง
บางทีก็ไม่ซื่อตรง แต่ถือว่าใช้งานได้ก็น่าจะเสร็จแล้ว
ในขณะที่นักออกแบบ หรือเจ้าของงาน ต้องการให้ “Get Things Right” ด้วย

ทั้งนี้ ปัญหานี้ไม่ได้เกิดจากการที่นักพัฒนาไม่มีฝีมือ
แต่มักจะเกิดจากทั้งสองฝ่าย
ทั้งจากการที่นักพัฒนายังรู้จักงานนั้นและธุรกิจที่เกี่ยวข้องไม่มากพอ
(และหลายๆคนก็ทำหน้าสงสัยว่า แล้วมันจำเป็นด้วยเหรอ โยน spec มาให้ก็จบแล้ว)
และถึงให้ spec ละเอียดขนาดไหน
(ละเอียดมากไปก็มักจะไม่อ่านอีก เจอมาแล้ว)
ก็อาจจะยังมีเงื่อนไขที่ไม่ได้บอกไว้ หลุดรอดไปเป็นธรรมดา
โดยเฉพาะ Non-Functional Requirement ที่ว่าด้วยเงื่อนไขการทำงาน
และทั้งจากการที่ผู้ออกแบบไม่ได้คิดวางแผนให้ถี่ถ้วนมากพอ
รวมไปถึงการที่เข้าใจธุรกิจที่จะถูกรองรับด้วยระบบที่สร้างนั้น ไม่พอด้วย

ยกตัวอย่างเช่น
ใน wireframe mock up
ระบุช่อง register ให้ใส่อีเมล์ได้
ผู้ออกแบบระบบที่มีความใส่ใจมากพอ
ต้องคิดเข้าไปถึงเงื่อนไขของ element แต่ละอย่างในระบบด้วย
และถ่ายทอดลง spec ระบุรายละเอียดลงไปเลย เช่น
อีเมล์ที่ใช้ register ซ้ำได้
แต่ username ซ้ำไม่ได้

ถ้านักพัฒนาเกิดไม่อ่าน spec ขึ้นมา
ดูแต่ Mock-up
แล้วก็ทำอย่างที่เคยทำมา
ก็อาจจะไม่ตรงกับความต้องการของระบบนี้จริงๆก็ได้
อาจจะทำให้สรุปเอาเองว่า
การ register ห้ามใส่ข้อมูลซ้ำกับที่มีอยู่
จะได้ไม่สร้าง identity ซ้ำในระบบ
อาจจะดีและตรงกับความต้องการในระบบอื่นๆ
แต่ระบบนี้ มี requirement ไปอีกแบบ
จึงนับได้ว่า นักพัฒนามีความหวังดี แต่ไม่อ่าน spec ให้ถี่ถ้วน

หรือแค่ dropdown อันเดียวในหน้าๆหนึ่ง ที่แสดงใน mock up
มันอาจจะดูไม่มีอะไร
นักพัฒนาก็เพียงแค่ใส่ dropdown เข้าไปหนึ่งอันตามค่าที่ให้ก็จบ
นั่นคือการ Get Things Done
แต่ค่า default ของ dropdown นั้นควรจะเป็นอะไร
ค่าที่เลือก option ใน dropdown ระบบต้องจำเอาไว้ไหม
ถ้าต้องจำ จำ per session หรือ per login
นั่นคือเรื่องการ Get Things Right
ที่ผู้ออกแบบอาจจะหลงลืม หรืออาจจะใส่เอาไว้ในเอกสารเป็นอย่างดีแล้วก็ได้

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

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

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

สิ่งหนึ่งที่จะช่วยป้องกันให้ปัญหาบรรเทาลง
และเสียเวลาน้อยที่สุดก็คือ
การประชุม Walk-through ก่อนส่งมอบงาน
ผู้ออกแบบพบประชาชน เอ้ย ทีมนักพัฒนา
แล้วก็เล่าว่า งานนี้เกี่ยวกับอะไร ทำอะไรได้บ้าง
และมี flow อย่างไร ซึ่งอาจจะนำเอา Use Case
หรือ Scenario + Persona ที่ออกแบบไว้ มาอธิบายให้ได้ชัดเจนขึ้นด้วย
ซึ่งการประชุมกัน
ช่วยทำให้ฝั่งนักพัฒนา ได้เข้าใจในความเป็นไปของงานมากขึ้น
และได้ตรรกะในการทำงานของระบบให้สอดคล้องกับธุรกิจนั้นๆมากขึ้น
ในขณะเดียวกัน ก็ทำให้ฝั่งผู้ออกแบบ ผู้จัดการโครงการ
ได้เห็นว่า นักพัฒนามีความเข้าใจในเนื้องานมากขนาดไหนด้วย
รวมไปถึงรีวิวข้อผิดพลาดในการออกแบบที่อาจจะเกิดขึ้นด้วย

เอาเข้าจริงๆ ผู้ออกแบบกับทีมพัฒนา ก็ควรจะได้ทำงานใกล้ชิดกัน
และมีการสื่อสารกันตลอดโครงการ
ยุคนี้หมดสมัยต่างคนต่างทำ
ดีไซเนอร์ทำงานเสร็จก็ส่งอีเมล์ต่อให้นักพัฒนาโดยที่ไม่ต้องพูดกัน
ไม่ว่าจะมีหน้าที่งานแบบไหน
การที่ได้รู้พื้นฐานของธุรกิจ และเข้าใจในเอกสารกลาง
อย่างเช่น Spec, Mock up อย่างดี
เพราะงานๆหนึ่งจะสำเร็จได้ด้วยดี
ก็จากการที่ทุกฝ่ายมีความเข้าใจที่ดีเกี่ยวกับงานนั้นๆ
และเอาใจใส่รายละเอียดในแบบที่ต่างกันไปตามหน้าที่ของตน

การพัฒนาระบบนั้น ถึงจะมองว่าเป็นระบบโรงงาน
อย่างที่เราเห็นในบังกาลอว์ หรือในจีน หรือในบริษัทซอฟต์แวร์ใหญ่ๆในบ้านเรา
แต่โดยส่วนตัว เราก็ยังเห็นว่า มันเป็น Craftmanship on top อยู่นั่นเอง
มันคืองานฝีมือล้วนๆก่อน แล้วค่อยแบ่งจัดการงานฝีมือนั้นอย่างเป็นระบบระเบียบ

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

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

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