Requirement

👱🏼‍♂️ เปลี่ยนบ่อยเกินไป

ผลลัพธ์ของการที่เราไม่ได้ให้ความสำคัญกับเรื่องการคิดการวิเคราะห์และการออกแบบระบบในเชิงลึกเพียงพอ 🫱🏽

รีไควเม้นท์ใครก็เขียนได้ แค่เราถามว่า “อยากได้อะไรครับ?” การเก็บรวบรวมรีไควเม้นท์ก็แค่ฟังสิ่งที่พวกเขาพูด 🌼

การหมุนงาน “บ่อย”เกินไปไม่ใช่เรื่องดี ตรงข้ามเลยเพราะมันคือตัวการที่ขัดขวางการเดินไปข้างหน้าของเรา 🪐

เมื่อเราต้องเผชิญทางแยกว่าควรทำอะไรก่อนอะไรหลัง … ลองพิจารณาดูสักหน่อยว่าทางเลือกที่มีตอนนี้มันมีอะไรที่เหมือนกันและใช้ร่วมกันได้บ้างมั้ย 👢

กับเวอร์ชั่นแรกที่เรายังไม่มีข้อมูลเรื่องลูกค้า เรื่องผู้ใช้มากนัก เราควรเตรียมการและใช้กระบวนการแบบไหนในการเลือกทำและไม่ทำอะไร 🙋🏻‍♂️

ตราบใดที่เรารู้ว่าเราต้องอดทนทำ “สิ่งหนึ่ง” เพื่อได้ผลลัพธ์จาก “อีกสิ่งหนึ่ง” เราจะยังไม่เสียศูนย์ ✌🏼

คำถามที่ควรถามเพื่อเก็บข้อมูลก่อนตัดสินใจว่าจะรับหรือไม่รับ Requirement Changes เหล่านั้นมาฝากให้คิดกันดู 😵

“นี่ไง เราทำตามสเปคแล้ว แค่นี้พอแล้ว” - แนวคิดเบื้องหลังในสมองของทุกคนเป็นแบบนี้ งานที่ทำแล้วรู้สึกภูมิใจจึงไม่ค่อยเกิดจากสเปค 😏

หลายครั้งเราทำตามข้อกำหนด หลายครั้งเราเรียกร้องหาสเปค หลายครั้งเราไม่เห็นด้วยกับสิ่งที่เราเห็นอยู่ตรงหน้า แล้ว …? 🤲🏼

เออ ก็จริง ถ้ากำหนดมาชัดเจน ความผิดพลาดก็จะน้อยลง … มันเป็นอะไรที่ง่ายมากแต่ทำไมไม่ทำ? 👎