อ่านมาก็หลายครั้ง เห็นมาก็หลายหนกับคำแนะนำที่ว่า “เราควรใช้ข้อมูลและตัวเลขเก่าๆมาช่วยในการทำ Software Estimation” ก็ฟังดูดีนะครับแต่หลังจากได้ลองผิดลองถูกมากขึ้น ประสบการณ์บอกให้ผมรู้ว่าหลักการแบบนี้อันตรายทีเดียว … ทำไมถึงเป็นแบบนั้น? ก็กฎง่ายๆที่ว่า “Bad In – Bad Out” คุณภาพของข้อมูลห่วย ผลลัพธ์ก็ห่วยตามเป็นธรรมดา ขอขยายความแบบนี้ครับ

Requirement Characteristic กับ Software Estimation

การได้มาของข้อมูลเป็นเรื่องสำคัญมากครับ ลองถามตัวเองว่าเราทำ Software Estimation กันอย่างไร? ถ้าเป็นแบบนี้อาจมีปัญหาได้นะ

1. ได้ Requirement มาก็อาศัยความที่เป็นผู้อาวุโสรวบหัวรวบหางเริ่มต้นการ Estimate ทันที
2. อ่าน Requirement แล้วเริ่มวิเคราะห์ว่า เอ่อ มันต้องทำอะไรมั่งวะเนี่ยะ … Analyze ต่ออีกหน่อยพร้อมๆกับ Design อืม ต้องแก้ Code เยอะเหมือนกันนะเนี่ยะ ทั้ง Server แล้วก็ UI แต่ยังโชคดีที่ Test ไม่ยากเท่าไร
3. คิดได้ดังนั้นแล้วก็ … 15 วันคงเสร็จมั้ง

จบกระบวนการทำ Estimation อย่างรวดเร็ว ปัญหาที่จะตามมาจากกระบวนการนี้มีเยอะแยะ เช่น 1. คิดคนเดียวแน่ใจหรอว่าถูก 2. นี่คุณเป็น Developer นะ ไปคิดแทน QA เค้าได้ยังไงว่ามันจะ Test ง่าย 3. เออ คุณเก่งแล้วนี่ทำงานมานาน ถ้าให้น้องใหม่ที่เพิ่งเข้ามาทำงานได้ 2 เดือนมันจะทำได้เร็วแบบคุณมั้ยเนี่ยะ? และอื่นๆ อีกมาก

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

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

ปัจจัย	คำอธิบาย
Requirement Stability	ความแน่นอนของ Requirement นี้มีมากน้อยแค่ไหน ถ้าน้อยเราคงต้องเผื่อเวลาไว้สำหรับ Change บ้าง
Data Migration	Requirement ตัวนี้ต้องมีการทำ Data Migration ด้วยมั้ย ถ้ามีเราก็ต้องเผื่อเวลาเพิ่มเข้าไปอีก
Application Experience	คนที่จะมาทำ Requirement นี้มีประสบการณ์ในงานมากน้อยแค่ไหน ถ้าน้อยเราก็ต้องเผื่อเวลาเข้าไปอีก
Technology Experience	คนที่จะมาทำ Requirement นี้มีประสบการณ์ใน Technology ที่จะใช้มากน้อยแค่ไหน ถ้าน้อยเราก็ต้องเผื่อเวลาเข้าไปอีก
Maturity of Technology	Technology ที่เราเลือกใช้มันเป็นที่ยอมรับและได้รับการพิสูจน์ว่าดีจริงมาแล้วรึยัง ถ้ายังเราต้องเผื่อเวลาไว้สำหรับปัญหาที่จะเกิดขึ้นด้วย
Reusable Components	เราสามารถจะเอาของที่มีอยู่แล้วมาใช้กับ Requirement นี้บ้างได้มั้ย เช่น Code หรือ Test Case ถ้ามีอยู่แล้วก็ดี เราจะได้ไม่ต้องเสียเวลาทำทุกอย่างใหม่หมด

สิ่งที่ผมพยายามจะสื่อให้เห็นคือ ถ้าเราอยากหวังจะพึ่งพิงตัวเลขเก่าๆมาช่วยในการทำ Software Estimation แล้วหละก็ นอกจากตัวเลขที่บอกว่างานนี้ใช้เวลาทำกี่วันแล้ว เราควรจะต้องเก็บ Requirement Characteristic นั่นก็คือสมมติฐานที่เราใช้เพื่อให้ได้มาซึ่งตัวเลขนี้ด้วยครับ งานยักษ์เลยหละ แล้วสุดท้ายก็จะลงเอยที่ไม่มีใครยอมทำและไม่มีเวลาทำ … ตัวเลขที่ได้มาจากการนั่งเทียนเลยเป็นตัวเลขที่อันตรายตามไปด้วย

Estimate กับ Actual มันคนละเรื่องกัน

ความสับสนในเรื่องตัวเลขและความหมายของมันมีส่วนสำคัญมากนะครับ เราต้องทำความเข้าใจก่อนว่าไม่ใช่แค่ Estimate แล้วจะจบเรื่องกันไป ความจริงแล้วตัวเลขที่ Estimate ออกมานั้นไร้ประโยชน์เลยด้วยซ้ำ เช่น ถ้าเรา Estimate ว่า Requirement นี้ต้องใช้เวลา Coding 10 วัน … แต่เอาเข้าจริงใช้เวลาไป 15 วัน เพื่อนๆคิดว่าตัวเลขไหนที่ควรจะเอามาพิจารณาตอนทำ Estimation ครั้งหน้าครับ? … มันก็ต้อง 15 วันเซ่ ก็ของจริงหรือ Actual มันใช้เท่านั้นนี่ เห็นมั้ยครับว่าเลข 10 ที่ได้จากการทำ Estimation มันไม่มีประโยชน์อะไรเลย แต่ปัญหาที่ตามมามันอยู่ตรงนี้แหละว่าเราจะเก็บค่า Actual ได้ให้กับทุกงานใน Project ได้อย่างครบถ้วนหรือไม่?

นี่เป็นหลักฐานแสดงให้เห็นถึงความเข้มแข็งของการทำ Project Tracking และความอุตสาหะอย่างยิ่งของ Project Manager กันเลยทีเดียวครับ ฮ่าๆ ก็เพราะมันไม่ใช่เรื่องง่ายนะที่ต้องเก็บข้อมูลทั้งหมดนี้ ยิ่งกับ Project ใหญ่ๆที่มี Task เยอะๆ … สำหรับใครที่ใช้ Microsoft Project เป็นตัวช่วยก็อาจจะง่ายหน่อย เราทำ Baseline Plan ไว้แล้วก็มากรอกข้อมูล Actual เข้าไปตอนทำ Tracking มันก็จะเห็นได้ว่า Estimate ไว้กี่วัน Actual กี่วัน (แล้วจะตกใจกับความแตกต่าง ฮ่าๆ) สำรหรับคนที่ใช้ Microsoft Excel ก็อาจจะยากหน่อยเพราะต้องเตรียม Template เองเป็นต้น

ความยากมันยังไม่หมดไปเพราะว่าเราต้องใช้ความพยายามสูงเลยหละที่จะไปตามเก็บข้อมูลพวกนี้มาใส่ Project Plan ของเราครับ ถ้ายิ่งมีงานเยอะมีสมาชิกเยอะก็ลำบากเข้าไปอีก บางครั้งงานบางงานต้องทำโดยคนที่อยู่ต่างประเทศก็ไปกันใหญ่ ถ้าไม่มั่นใจว่าเราได้ค่า Actual มา ผมว่าการเอา Historical Data ที่เป็นค่า Estimation มาใช้นั้นผิดอย่างมากเลยหละ

Actual Effort ที่ได้มาถูกต้องแล้วหรอ?

ถ้าเรามีเวลาและความพยายามตามเก็บค่า Actual Effort ของทุกงานที่อยู่ใน Project ได้ก็ยังมีปัญหาให้ปวดหัวต่อไปอีกว่า แล้วตัวเลขที่ได้มาเนี่ยะมันถูกต้องและเชื่อถือได้มากน้อยแค่ไหน? เรื่องนี้พูดยากมากเลย … เริ่มยังไงดี? …  มันเป็นเรื่อง Effort – Duration – Calendar Day ซึ่งเป็นตัวเลขสามตัวที่เกี่ยวข้องกันในมุมมอง Project Management ครับ ประเด็นคือการที่เราจะบอกว่างานนี้ใช้เวลาทำ 1 วันหมายความว่ายังไงครับ?

• ก็ต้องมาดูว่าวันนึงเราทำงานกี่ชั่วโมง ดังนั้นเราจะพูดได้เต็มปากว่างานนี้จะใช้เวลาทำหนึ่งวันนั้นคือเราทำงานนั้นต่อเนื่องเป็นเวลา 8 ชั่วโมง นี่คือ Effort ที่ต้องใช้
• แล้วถ้าเราทำงานนี้วันละ 4 ชั่วโมง 2 วันหละ แปลว่างานนี้ต้องใช้ 2 วันรึเปล่า? … ไม่ใช่ครับ Effort ที่เกิดขึ้นก็ยังเป็น 8 ชั่วโมงซึ่งแปลงกลับมาได้เป็นแค่ 1 วันทำงานอยู่ดี

ปัญหามันอยู่ตรงนี้แหละ เพราะว่าใน Project Plan ของเราจะมีวันเริ่ม-วันจบของงานอยู่ซึ่งวันจบงานนี้บอกเราไม่ได้ว่า Effort ที่เกิดขึ้นจริงเป็นเท่าไร เช่น ผมขี้เกียจอะ ทำงานนี้วันละ 1 ชั่วโมง กว่าจะเสร็จก็ 8 วัน … แปลว่างานนี้ต้องทำ 8 วันรึเปล่า? ไม่ใช่หรอกแต่ใน Project Plan จะบอกว่าเริ่มงานวันที่ 1 แล้วเสร็จวันที่ 8 อะครับ นี่แหละปัญหาที่ว่าการเก็บค่า Actual Effort มันไม่ง่าย

และต่อให้เราทุ่มเทมากขึ้นกว่าเดิมด้วยการมีระบบ Time Tracking ที่ขอความร่วมมือ (แกมบังคับ) ให้สมาชิกในทีมเข้ามากรอกข้อมูลว่าแต่ละวันทำงานอะไรไปบ้าง อย่างละกี่ชั่วโมง ตัวเลขที่ได้จะละเอียดขึ้นครับว่า Requirement นี้ใครมีส่วนร่วมทำบ้าง แล้วทำคนละกี่ชั่วโมงต่อวัน อะไรประมาณนี้ แต่ปัญหา (อีกแล้ว) คือรู้ได้ยังไงว่าตัวเลขที่สมาชิกในทีมกรอกมามันตรงกับความจริง … นั่งเทียนกันมาทั้งนั้นแหละครับ ใครจะมานั่งจำว่าวันๆนึงทำงานอะไรไปเท่าไรกันบ้าง เนอะ ฮ่าๆๆ

Lesson Learned in Software Estimation

เป้าหมายของบทความนี้คือห้ามไม่ให้เพื่อนเอาตัวเลขเก่าๆมาใช้ในการทำ Software Estimation เลยหรอ? ไม่ขนาดนั้นหรอก ผมแค่ต้องการจะชี้ให้เห็นถึงปัญหาที่เป็นอยู่กับการเอาตัวเลขที่อาจจะไม่มีความถูกต้องมากนักมาใช้เป็นหลักยึดในการทำ Software Estimation ครับ แต่ถ้าใครที่มองแล้วว่า Project ตัวเองมีการทำ Software Estimation ที่ถูกต้อง มีการเก็บข้อมูลที่ดีและครบถ้วน บวกกับไม่ลืมเรื่องการทำ Project Tracking เพื่อเก็บ Actual Effort แล้วหละก็ … ยินดีด้วยครับ (อิจฉาด้วยแหละ) ที่ตัวเลขที่เพื่อนๆมีในมือนั้นถือว่าเป็นขุมทรัพย์เลยหละ

ส่วนตัวผมเองก็ต้องบอกตามตรงว่าทำไม่ได้ขนาดนั้นหรอก ตัวเลขที่ได้มาแต่ละครั้งก็นั่งเทียนบ้างอะไรบ้าง การเก็บ Actual Effort ก็ขาดไปเยอะ ดังนั้นสิ่งที่ผมใช้แทนตัวเลขเหล่านี้ตอนทำ Estimation ก็คือ Lesson Learned ครับ บทเรียนที่ว่าคือ ถ้าทำอะไรดีเราก็ทำต่อ ถ้าอะไรทำแล้วไม่เข้าท่าเราก็พยายามปรับปรุงหรือไม่ก็เลิกใช้ไป … Lesson Learned สำหรับ Software Estimation ที่ผมมีก็ …

1. การใช้เวลาในการ Estimate มากไม่ได้เป็นการการันตีว่าจะได้ผลที่ถูกต้องมากขึ้น
2. ใช้ PERT ในการทำ Estimation แล้วถือว่าโอเคนะแต่ใช้เวลาพอสมควร
3. ใช้ Delphi ในการทำ Estimation ก็ดีเหมือนกันเพราะได้ความคิดเห็นจากคนมากกว่าหนึ่งคน มีการเปิดช่องให้พูดคุยเพื่อทำความเข้าใจในงานระหว่างกันด้วย แต่เสียเวลามากเลย
4. เคยเอาคนทั้งทีมมาช่วยกันทำ Estimation นะ นั่งรวมกันในห้องประชุมแล้วก็ Estimate ร่วมกัน เสียเวลา เสียแรง ผลที่ได้ก็ใช่จะตรงเป๊ะ ไม่คุ้มเท่าไร
   
5. ตอนหลังเลยเปลี่ยนเป็นจับคู่กัน Estimate ส่วนใหญ่จะเป็น Senior + Junior คู่กันช่วยกัน Estimate เฉพาะงานที่ได้รับมอบหมายให้ทำ ประหยัดเวลาได้มากขึ้น ผลลัพธ์ที่ได้ก็โอเค ถือว่าคุ้มค่าที่จะทำต่อ
   
6. สำคัญมากว่าควรจะให้คนทำได้มีสิทธิมีเสียงในการ Estimate ด้วย ไม่ใช่ว่าใครก็ไม่รู้จับงานมายัดใส่มือพร้อมกับเวลาที่น้อยเกินไป
7. หลังๆเริ่มมีการรวมกลุ่มระหว่าง Developer และ QA เข้ามาช่วยกัน Estimate เพื่อเปิดมุมมองของอีกฝั่งหนึ่ง ประโยชน์ที่ได้รับก็คือการทำ Requirement Analysis และ Design ไปในตัวเลย
8. เคยทำ Planning Game ของ Agile Development แล้วด้วย สนุกมาก เสียเวลามาก และด้วยความที่เป็น Project แรก ตัวเลขที่ได้ออกมาก็มั่วมากด้วย ฮ่าๆๆ
9. Story Point ที่ได้ออกมามันไม่ค่อยตรง และด้วยความคุ้นเคยทุกคนจะถามคำถามเดียวกันว่า “5 แต้มนี่มันใช้เวลาทำกี่วัน แล้วต้องเสร็จเมื่อไร?” สุดท้ายเลยต้องเปลี่ยนจาก Point มาเป็น Ideal Day แทน ทั้งที่พอรู้มาบ้างว่าเราไม่ควรไปยึดติดกับแนวคิดเดิมที่มองอะไรเป็นวัน แต่ต้านกระแสมหาชนไม่อยู่จริงๆ
   
10. ได้ด้วเลขมาแล้วก็อย่าลืมคิดเรื่องวันหยุดราชการ วันลาพักร้อนและวันลาป่วยเผื่อๆไว้ด้วย
11. ได้ตัวเลขมาแล้วก็อย่าลืมบวก Buffer ไปด้วยนะ ไม่งั้นเดี๋ยวมี Change เข้ามาแล้วจะยุ่ง
12. อย่ามองว่า Software Estimation คือกระบวนการที่ทำครั้งเดียวเสร็จ หมั่นตรวจสอบผลการ Estimate อยู่เรื่อยๆเพราะบ่อยครั้งตัวเลขที่ได้มามันไม่ตรงหรอก ถ้า Requirement แรกก็คลาดเคลื่อนไปมากกว่า 30% แล้วเราควรจะมานั่งพิจารณาหน่อยว่า เฮ้ย แล้วไอ้ Requirement ที่เหลือมันจะตรงมั้ยวะเนี่ยะ ฮ่าๆๆ กระบวนการนี้เรียกว่า Re-Estimation
    
13. ถ้า Requirement ไม่ค่อยชัดเจนหรือคาดการณ์แล้วว่าต้องมีการเปลี่ยนแปลงเกิดขึ้นเรื่อยๆ แนะนำให้ใช้ Iterative จะดีกว่า การทำ Estimation จะยืดหยุ่นมากขึ้นด้วย
14. ถ้าเป็นไปได้ก็พยายามแบ่ง Requirement ออกมาเป็นส่วนย่อยๆแล้วค่อย Estimate จากงานที่เล็กๆ ตัวเลขที่ได้จะแม่นยำกว่าเดิม
15. ถ้าไม่แน่ใจว่างานนี้ยากง่ายแค่ไหน ลองปรึกษาผู้เชี่ยวชาญดูก่อน จะทีมเดียวกันหรือต่างทีมก็ได้นะ

สรุปง่ายๆว่า Software Estimation เป็นเรื่องยากมากสำหรับผมนะ เพื่อนๆคิดว่าไงกันมั่งครับ?

Changes คือสัจธรรมของ Software Development Project มันเป็นปัญหาคลาสสิกที่วนเวียนอยู่กับเราทุกคนและทุก Project เอาเป็นว่าตั้งแต่ทำงานมา 8 ปีกว่า ทุก Project ที่ผมเกี่ยวข้องด้วยไม่ว่าจะตำแหน่งหน้าที่อะไรก็ต้องเจอเรื่องนี้ทุกครั้งไป ครั้งนี้ก็ไม่ต่างกัน แหะๆ

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

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

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

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

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

1. ตั้งกฎไว้เลยว่าเราจะไม่เริ่มทำงานถ้า Requirement ยังไม่เรียบร้อย
2. ทำ Requirement Analysis อย่างละเอียดตั้งแต่แรก
3. ใช้ Operational Concept มาช่วยในการทำ Requirement Analysis
4. กำหนดกฏเกณฑ์การรับ/ไม่รับ Change ที่แน่นอน ไม่ใช่ใครสั่งอะไรก็ต้องทำตาม
5. ให้ QA มาช่วยทำ Requirement Analysis แล้วเอา Dev มาเขียน UAT บ้างเพื่อแลกเปลี่ยนมุมมอง Requirement Analysis จะได้สมบูรณ์ขึ้น
6. Dev และ QA และ Product Manager ต้องช่วยกันกำหนดหัวข้อสำคัญที่ต้องพิจารณาเวลาคุยถึง Requirement หรือ Design เช่น เรื่อง data format, exception, condition, state diagram และ data flow
7. ทำ Pair Implementation ซะเลย เอา Dev และ QA มานั่งทำงานไปพร้อมกัน Dev เขียนโค๊ดไป QA เตรียม Test Case, Test Data เสร็จแล้วก็ลองเทสตรงนั้นเลย เจ๊งก็แก้ทันที ไม่ต้องเสียเวลารออะไรต่ออะไรกัน
8. แบ่งงานเป็นส่วนย่อยๆเพื่อสร้าง Focus ที่ชัดเจนขึ้น ไม่ต้องคิดมาก ไม่ต้องคิดไกล ไม่ต้องพูดนอกเรื่องเวลาทำ Requirement Analysis หรือ Design
9. มี Standup Meeting เพื่อลดเวลาในการสื่อสาร เวลาในการรอใครต่อใครตอบคำถามระหว่าง Dev, QA และ Product Manager
10. ดึง Product Manager เข้ามาช่วยยืนยันความถูกต้องของงานบ่อยๆ เพื่อลดการเกิด Change ขนาดใหญ่
11. ไม่ต้องเสียเวลารอคำตอบ ไม่ต้องเสียเวลาคุยอะไรมากหรอก ทำๆไปก่อนแหละ (แต่ทำงานเล็กๆนะ) ถ้าผิดค่อยมาแก้ทีหลัง
12. เผื่อ Buffer ไว้สำหรับ Change พวกนี้บ้าง
13. ทำ Code Review และ Test Review เพื่อยืนยันความถูกต้องและความเข้าใจที่ตรงกันก่อนทำงานขั้นต่อไป
14. ขอเวลาวันละ 10 นาทีมา Review พวก Design/Implementation/Test Case กันหน่อยว่าไม่มีอะไรเปลี่ยนแปลง
15. ไม่รับ Change ทันที เอาไปใส่ Product Backlog ไว้แล้วค่อยว่ากันวันหลัง
16. อยากให้มีมุมมองของลูกค้าเพิ่มเข้ามาบ้าง ขอให้ Support Engineer มาช่วยแล้วกัน
17. จัดลำดับความสำคัญของ Requirement หน่อยก็ดีนะ จะมี Change ทั้งทีจะได้คุ้มค่าที่จะเสียเวลาทำหน่อย
18. มีข้อมูล/หลักฐาน/ตัวเลขอะไรก็ได้ที่บอกเราได้ว่าถ้ารับ Change ตัวนี้แล้วจะส่งผลกระทบแค่ไหนกับงานโดยรวม Change Management จะได้มีหลักการมากขึ้น
19. เอาส่งเมล์แนบเอกสารที่อยากให้รีวิวมันไม่ได้ผล ก็เปลี่ยนเป็นเดินไปหาที่โต๊ะคนที่เราอยากให้รีวิวเอกสารให้ แล้วอธิบายให้เค้าฟังว่าอะไรเป็นอะไร ขอความเห็นเค้าตรงนั้นเลย
20. คุยๆๆ เรื่อง Requirement หรือ Design แล้วก็ปล่อยให้คำพูดและความคิดหายไปกับสายลม … อย่าให้เป็นแบบนั้น … อัดเสียงไว้บ้างหรืออัดวิดีโอก็ได้ (iPhone มีกันแทบทุกคน) จัดกลุ่มให้เป็นหมวดหมู่ เก็บไว้เป็น Requirement Analysis and Design document (รูปแบบใหม่)
21. ไม่รับ Change อะไรทั้งสิ้น (เบื่อ)

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

ป.ล. ผมใช้กระบวนการคิดที่เรียกว่า Productive Thinking เพื่อพยายามจะแก้ปัญหานี้ครับ คร่าวๆ Productive Thinking ประกอบด้วยสองส่วน หนึ่ง Creative Thinking คือการคิดและรวบรวมแนวคิด (Idea) ต่างๆให้ได้มากที่สุดโดยไม่พิจารณาและตัดสินว่ามันดีหรือไม่ดี กับสอง Critical Thinking คือการที่เรามาพิจารณาเจ้าแนวคิดทั้งหมดที่เรารวบรวมไว้ทีละอันเพื่อดูว่าจริงๆแล้วอะไรที่เหมาะกับสถานการณ์ที่เราเจออยู่มากที่สุดเพื่อนำมาซึ่งทางออก (Solution) ของปัญหา ซึ่งทั้งหมด 21 ข้อข้างบนนั้นมาจาก Creative Thinking ของผม … ส่วน Critical Thinking ผมยกให้เป็นหน้าที่ของเพื่อนๆครับ