...Requirement เนี่ย ไม่มีที่สิ้นสุดหรอกครับ...จะมีมาเรื่อยๆ และ จะพีคมากสุดตอนจะ Hand over งาน หรือ ส่งงาน ถึงตอนนั้นแหละ ทั้ง กูรู กูไม่รู จะมากันเพียบ เพื่อบอกว่า งานเราควรจะเป็นอย่างนั้น เป็นอย่างนี้ เผลอๆ งานที่เสร็จแล้วอาจจะกลายเป็นงานที่ยังไม่เสร็จ เนื่องจากต้องทำในส่วนของงานเพิ่มให้เสร็จก่อน...

คุณเคยไปเดินเลือกซื้อ TV มั๊ยครับ?

สมมุติว่าเราต้องการซื้อ TV สี จอใหญ่ๆ สักเครื่อง เอาสัก 32 นิ้วละกัน

หลังจากนับเงินในกระเป๋าได้แล้ว ก็ไปห้างใกล้บ้าน และ แวะไปแผนกเครื่องใช้ไฟฟ้ามุ่งหน้าปรู๊ดไปที่แผนก TV

TV เครื่องแรกที่เราเห็นก็ดีสวยงาม และ เป็นที่พอใจอยู่แล้ว พอล้วงกระเป๋ากำลังจะจ่ายตังส์ เซลล์เจ้ากรรมก็ปราดเข้ามาทักและแนะนำอีกยี่ห้อ และบอกว่าน่าจะซื้อยี่ห้อนั้นดีกว่า เพราะอยู่ในช่วงจัดรายการ(Promotion) มีแถมเครื่องเล่น DVD แถม พัดลม หม้อหุงข้าว แถมเผลอๆ จะราคาใกล้ TV เข้าไปแล้ว

ตบท้ายด้วยผ่อนสิบเดือน ดอกเบี้ย “ศูนย์” เปอร์เซ็นต์

ผมว่าคนใจแข็งยังไง ก็คงโลเลใจอ่อน บ้างล่ะครับ ยิ่งไปเห็นว่าไอ้เจ้าตัวใหม่มี สมรรถนะดีกว่าเช่น บอกว่า 100 Hz Full HD อะไรประมาณนั้น แถมพอเอามาเปิดดูคู่กัน ไอ้เจ้าตัวเก่านี่ดูเป็นไม่ชัดไปเลย

ความตั้งใจเดิมที่ตั้งใจจะซื้อเอาไปดูข่าวเป็นหลักด้วยซ้ำเจออาการอย่างว่า Requirement เดิมก็อาจเปลี่ยนได้…. <p style="margin: 0in 0in 10pt" class="MsoNormal">ที่เล่ามาเพราะคราวที่แล้วผมพูดเรื่อง Requirement และ หลักของการ “หา” Requirement ไปแล้วว่าต้องทำยังไง</p><p style="margin: 0in 0in 10pt" class="MsoNormal">แต่เชื่อเถอะครับว่า “ความต้องการ” หรือ Requirement เนี่ย ไม่มีที่สิ้นสุดหรอกครับ…</p><p style="margin: 0in 0in 10pt" class="MsoNormal">จะมีมาเรื่อยๆ และ จะพีคมากสุดตอนจะ Hand over งาน หรือ ส่งงาน </p><p style="margin: 0in 0in 10pt" class="MsoNormal">ถึงตอนนั้นแหละ ทั้ง กูรู กูไม่รู จะมากันเพียบ เพื่อบอกว่า งานเราควรจะเป็นอย่างนั้น เป็นอย่างนี้ เผลอๆ งานที่เสร็จแล้วอาจจะกลายเป็นงานที่ยังไม่เสร็จ เนื่องจากต้องทำในส่วนของงานเพิ่มให้เสร็จก่อน</p><p style="margin: 0in 0in 10pt" class="MsoNormal">อย่างนี้เรียก”ปัญหา” ครับ ดังนั้นเรื่องอย่างนี้ต้องมีวิธีการจัดการครับ</p><p style="margin: 0in 0in 10pt" class="MsoNormal">……………………………………………………………..</p><p style="margin: 0in 0in 10pt" class="MsoNormal">อันแรก คาถาที่ต้องท่องเอาไว้ในงานโปรเจคเลยก็คือ “หลักฐานการเห็นชอบร่วมกัน” คือไม่ว่า จะทำอะไร ใครพูดกับใคร ถ้ามีผลต่อการเปลี่ยนแปลงของ project แล้ว ต้องมี Memo เก็บไว้ครับ</p>Memo ที่ว่าต้องมีลายเซ็น “รับรู้” จากทั้งสองฝ่ายครับ คือทั้งเจ้าของโครงการคนที่ให้ Requirement และ คนที่ประสานงานโครงการ <p style="margin: 0in 0in 10pt" class="MsoNormal">Requirement ที่เราไปรีดออกมาจาก ลูกค้า (แบบอย่างดีที่เราสามารถเอาไปทำ Check list สำหรับส่งงานได้) เมื่อสรุปแล้ว จะต้องนำมาเรียบเรียง และ นำกลับไปให้ลูกค้าดู อันนี้เรียก revise and review ครับ</p><p style="margin: 0in 0in 10pt" class="MsoNormal">พอลูกค้า OK แล้วก็ เซ็นต์รับกันไว้ก่อนครับ แถมท้ายด้วยการย้ำบอกลูกค้าว่า</p>“งานที่ผมรับไปทำการออกแบบ จะถือตาม requirement นี้เป็นหลักนะครับ ถ้ามีการเปลียนแปลงกรุณาแจ้งให้ทราบก่อนล่วงหน้านะครับ” <p style="margin: 0in 0in 10pt" class="MsoNormal">…</p><p style="margin: 0in 0in 10pt" class="MsoNormal">ที่ให้ทำอย่างนั้นไม่ได้ป้องกันการเพิ่ม  Requirement  หรอกนะครับ แต่เป็นการทำ Agreement ว่างานที่เราทำจะออกมาแค่ไหน</p><p>สำหรับ Requirement ที่เพิ่มเติมภายหลัง ผมจะมี check point ให้สองอย่างครับ คือ </p><p>1.       Requirement นั้นมี “เงิน” หรือที่เราเรียกว่า “Budget. หรือ ไม่ ถ้ามี ก็ไปดูข้อสอง</p><p>2.       มีเวลาทำหรือไม่ (หมายถึงว่า ทำแล้ว จะเสร็จทันตามกำหนดเดิมหรือไม่) ถ้าเสร็จทัน ก็ทำให้เลยอันนี้เป็นวิธีการจัดการกับ Requirement ครับ ซึ่งส่วนปกติผมจะให้ทีม “ยับยั้งชั่งใจ”ซะก่อน </p><p style="margin: 0in 0in 10pt" class="MsoNormal">นั่นคืออยากให้ Focus กับ requirement ดั้งเดิม และ ทำให้เสร็จเรียบร้อยก่อนครับ แล้วค่อยจัดการกับ Requirement ที่เพิ่มเข้ามา</p><p style="margin: 0in 0in 10pt" class="MsoNormal">กลัวได้หน้าจะลืมหลังครับ</p><p>ยกเว้นว่างานนั้นถ้าทำภายหลังจะยุ่งยาก หรือ มีผลต่อความสำเร็จงานในครั้งนี้…ก็จะรับทำให้ครับ</p><p>To be continue…</p>