อยู่กับ Requirement Change อย่างมีความสุข

การเปลี่ยนแปลง (Change) คือสัจธรรมของงานพัฒนาซอฟต์แวร์ มันเป็นปัญหาคลาสสิกที่วนเวียนอยู่กับเราทุกคนและทุกโปรเจกต์ เอาเป็นว่าตั้งแต่ทำงานมา 10 กว่าปี ทุกโปรเจกต์ที่ผมเกี่ยวข้องด้วยไม่ว่าจะตำแหน่งหน้าที่อะไรก็ต้องเจอเรื่องนี้ทุกครั้งไป ครั้งนี้ก็ไม่ต่างกัน แหะๆ

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

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

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

• น่าจะดีนะถ้าไม่มี Change เกิดขึ้นเลย
• น่าจะดีนะถ้าเรามีกระบวนการจัดการ Change ที่ดีขึ้นกว่านี้
• น่าจะดีนะถ้าเราจะลดเวลาที่ใช้ในการสื่อสารกันระหว่าง Dev, QA และ Product Owner
• น่าจะดีนะถ้าเราจะมีวิธีการทำ Requirement Analysis แบบใหม่ที่ทุกคนมีส่วนร่วม
• น่าจะดีนะถ้าเราสามารถสร้างความรู้สึกเป็นเจ้าข้าวเจ้าของในโปรเจกต์นี้ให้กับทุกคนในทีม
• น่าจะดีนะถ้าเราสามารถลดความเข้าใจผิดเรื่องงานระหว่างกัน
• น่าจะดีนะถ้าเราทุกคนจะยิ้มได้เมื่อเกิด Change ขึ้น

เมื่อได้โจทย์แล้วก็ถึงเวลาคิดหาผลลัพธ์ซึ่งได้ออกมาแบบนี้ครับ …

คำเตือน: โปรดใช้วิจารณญาณในการอ่าน เชื่อ และนำไปปฏิบัติ

• ตั้งกฎไว้เลยว่าเราจะไม่เริ่มทำงานถ้า Requirement ยังไม่เรียบร้อย
• ทำ Requirement Analysis อย่างละเอียดตั้งแต่แรก
• ใช้ Operational Concept มาช่วยในการทำ Requirement Analysis
• กำหนดกฏเกณฑ์การรับ/ไม่รับ Change ที่แน่นอน ไม่ใช่ใครสั่งอะไรก็ต้องทำตาม
• ให้ QA มาช่วยทำ Requirement Analysis แล้วเอา Dev มาเขียน UAT บ้างเพื่อแลกเปลี่ยนมุมมอง Requirement Analysis จะได้สมบูรณ์ขึ้น
• Dev และ QA และ Product Owner ต้องช่วยกันกำหนดหัวข้อสำคัญที่ต้องพิจารณาเวลาคุยถึง Requirement หรือ Design เช่น เรื่อง Data Format, Exception, Condition, State Diagram และ Data Flow
• ทำ Pair Implementation ซะเลย เอา Dev และ QA มานั่งทำงานไปพร้อมกัน Dev เขียนโค๊ดไป QA เตรียม Test Case, Test Data เสร็จแล้วก็ลองเทสตรงนั้นเลย เจ๊งก็แก้ทันที ไม่ต้องเสียเวลารออะไรต่ออะไรกัน
• แบ่งงานเป็นส่วนย่อยๆเพื่อสร้างโฟกัสที่ชัดเจนขึ้น ไม่ต้องคิดมาก ไม่ต้องคิดไกล ไม่ต้องพูดนอกเรื่องเวลาทำ Requirement Analysis หรือ Design
• มี Standup Meeting เพื่อลดเวลาในการสื่อสาร เวลาในการรอใครต่อใครตอบคำถามระหว่าง Dev, QA และ Product Owner
• ดึง Product Manager หรือ Product Owner หรือถ้าได้ลูกค้ายิ่งดี เข้ามาช่วยยืนยันความถูกต้องของงานบ่อยๆ เพื่อลดการเกิด Change ขนาดใหญ่
• ไม่ต้องเสียเวลารอคำตอบ ไม่ต้องเสียเวลาคุยอะไรมากหรอก ทำๆไปก่อนแหละ (แต่ทำงานเล็กๆนะ) ถ้าผิดค่อยมาแก้ทีหลัง
• เผื่อ Buffer ไว้สำหรับ Change พวกนี้บ้าง
• ทำ Code Review และ Test Review เพื่อยืนยันความถูกต้องและความเข้าใจที่ตรงกันก่อนทำงานขั้นต่อไป
• ขอเวลาวันละ 10 นาทีมา Review พวก Design/Implementation/Test Case กันหน่อยว่าไม่มีอะไรเปลี่ยนแปลง
• ไม่รับ Change ทันที เอาไปใส่ Product Backlog ไว้แล้วค่อยว่ากันวันหลัง
• อยากให้มีมุมมองของลูกค้าเพิ่มเข้ามาบ้าง ขอให้ Support Engineer หรือ Customer Service Staff มาช่วยแล้วกัน
• จัดลำดับความสำคัญของ Requirement หน่อยก็ดีนะ จะมี Change ทั้งทีจะได้คุ้มค่าที่จะเสียเวลาทำหน่อย
• มีข้อมูล/หลักฐาน/ตัวเลขอะไรก็ได้ที่บอกเราได้ว่าถ้ารับ Change ตัวนี้แล้วจะส่งผลกระทบแค่ไหนกับงานโดยรวม Change Management จะได้มีหลักการมากขึ้น
• เอาส่งเมล์แนบเอกสารที่อยากให้รีวิวมันไม่ได้ผล ก็เปลี่ยนเป็นเดินไปหาที่โต๊ะคนที่เราอยากให้รีวิวเอกสารให้ แล้วอธิบายให้เค้าฟังว่าอะไรเป็นอะไร ขอความเห็นเค้าตรงนั้นเลย
• คุยๆๆ เรื่อง Requirement หรือ Design แล้วก็ปล่อยให้คำพูดและความคิดหายไปกับสายลม … อย่าให้เป็นแบบนั้น … อัดเสียงไว้บ้างหรืออัดวิดีโอก็ได้ (iPhone มีกันแทบทุกคน) จัดกลุ่มให้เป็นหมวดหมู่ เก็บไว้เป็น Requirement Analysis and Design document (รูปแบบใหม่) … สุดท้าย
• ไม่รับ Change อะไรทั้งสิ้น (เบื่อ)

ทั้งหมดนี้เป็นแค่แนวคิดของผมเอง อาจจะมีทั้งถูกและผิดหรืออาจจะผิดทั้งหมดเลย แล้วแต่มุมมองและสถานการณ์ที่แต่ละคนเจอ … “Ideas are not solutions.” แนวคิดไม่ใช่ทางออกนะครับ ที่เหลือที่ต้องทำคือเลือกแนวคิดที่เหมาะสมที่สุดไปประยุกต์ใช้กับงานของเอง จะหยิบไปใช้เดี่ยวๆ จะหยิบไปใช้หลายๆอัน จะเอาไปคิดต่อยอดเป็นแนวคิดใหม่ๆ หรือจะเอาหลายๆแนวคิดมารวมกัน ก็แล้วแต่จินตนาการเพื่อนๆจะสรรค์สร้าง

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

The Future Has Arrived — It’s Just Not Evenly Distributed Yet, William Gibson

อนาคตอยู่ตรงนี้แล้ว เรามีหน้าที่ต้องถ่ายทอดมันออกไปให้คนอื่นได้สัมผัสสิ่งดีๆร่วมกันครับ