หลังจากทำงานมาสักพัก ไม่ว่างานจะใหญ่หรือจะเล็ก ก็จะเจอปัญหาว่า "โปรเจคใช้เวลามากเกินไป" ทั้งๆที่งานที่สามารถ Deliver ได้ก็เสร็จตั้งนานแล้ว แต่ทำไมสุดท้ายไม่ได้ Deliver สักที

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

ไม่ได้เป็นแบบนี้แค่งานเดียว เจอเคสแบบนี้ราวๆ 60% ของงานทั้งหมดเลย และไม่ได้เกิดกับแค่คนคนเดียว โปรเจคก็เปลี่ยนคน เปลี่ยนกลุ่ม เปลี่ยนแนวทางการพัฒนาก็แล้ว แต่ก็ยังเกิดอยู่ สงสัยเหลือเกินว่าทำไมเคสแบบนี้ถึงยังเกิดได้เรื่อยๆ

จึงตั้งธง เกิดความสงสัย มันต้องมีเหตุผล ไม่งั้น Reproduce Rate ไม่สูงขนาดนี้หรอก

Disclaimer: ข้อมูลนี้เป็นแค่ความเชื่อส่วนบุคคล ไม่ได้มีหลักการจากงานวิจัยอะไร แต่เป็นสิ่งที่ได้จากการสังเกต อาจจะไม่ได้จริงแท้ 100% กับทุกกรณี บ้างคนอาจจะอ่านแล้วไม่เห็นด้วย บางคนอาจจะเห็นด้วย ดังนั้นโปรดอ่านโดยใช้วิจารณญาณ แค่หวังว่ามันอาจจะมีประโยชน์ในการเอาไปปรับใช้กับองค์กรของท่านได้ครับ =)

เฝ้าสังเกตการณ์

เจอโจรตัวแรก เกิดจาก Project Management ที่ไม่ดี Waterfall ตัวร้าย ทำให้ใช้เวลาเยอะเกินไปจากการที่ Scope Creep แบบ Surprise

ปัญหาพื้นฐานของ Software Development สินะ สินะ

แต่ประเด็นนี้ไม่ใช่เรื่องที่จะพูดใน Blog นี้ เพราะเมื่อมองละเอียดแล้ว ก็พบว่า แม้แต่โปรเจคที่ใช้ Agile ในรอบของ Sprint ก็เจอปัญหาใช้เวลาสูงกว่าที่ควรอยู่เช่นกัน อันนี้เป็นเรื่องของคนๆไปละ

ซึ่งก็ดี ศึกษาโฟกัสลงไปที่คนโลด

หลังจากใช้เวลาศึกษาพฤติกรรม ด้วยการสังเกตและการพูดคุย พบว่าได้สัจธรรมมาข้อนึงที่เกิดกับสิ่งมีชีวิตสายโปรแกรมเมอร์ว่า

Programmer at average quality will look for the perfection.

โปรแกรมเมอร์ที่เก่งระดับเฉลี่ย จะโหยหาความสมบูรณ์แบบ

โดยเท่าที่สังเกต คนที่เก่งระดับหนึ่งแล้ว จะมีความเป็น Perfectionist ในตัว

แต่คนที่เก่งจนเลยจุดนั้นไปสักพัก จะโยนความ Perfectionist ทิ้งไป แล้วมองเห็นความจริงมากขึ้น

ค้นพบสิ่งที่น่าสนใจ

ความจริงของงานโปรแกรมมิ่ง(และงานโปรดักชั่นอื่นๆ เช่น วีดีโอ ดนตรี ฯลฯ) มันไม่ได้มีแค่เสร็จหรือไม่เสร็จ แต่มันมีสเกลตั้งแต่ ไม่เสร็จ เสร็จแบบดีและเสร็จแบบสมบูรณ์แบบ

โปรแกรมเมอร์จำนวนมาก เมื่อเขียนเสร็จแล้ว งานใช้ได้แล้วในระดับที่เรียกว่า "ดี (Good Enough)" แต่ก็จะยังอึดอัด รู้สึกว่ามันดีกว่านี้ได้ จึงขอใช้เวลาเพิ่มในการทำให้มัน "สมบูรณ์แบบ (Perfect)"

ยกตัวอย่างเช่น สมมติทำแอพฯที่ใส่ฟิลเตอร์ให้รูปถ่าย การทำให้มันใช้ฟิลเตอร์ได้โดยใช้เวลาใส่ประมาณ 1 วิ ถือว่าอยู่ในระดับ "ดี" เอาไปใช้งานได้แล้ว แต่ถ้าอยาก "สมบูรณ์แบบ" ก็ต้องทำให้มันเหลือ 100ms ให้ได้

บางทีก็แค่ Optimize เป็นส่วนๆ บางทีก็ทำใหม่เลยแต่ต้นโดยใช้ประสบการณ์จากการเขียนครั้งที่ผ่านมา

และจากที่มานั่งบวกเวลาเฉลี่ยเล่นดู จากจำนวนเคสที่มากพอ (มากกว่า 20 ครั้ง) ก็พบว่า

เวลาที่ใช้ในการทำให้มันสมบูรณ์แบบ จะเท่ากับเวลาที่ใช้ในการสร้างขึ้นมาให้มันใช้ได้ "ดี"

จึงเกิดเป็นตัวเลขที่จำใส่ใจไว้ตลอดคือ 90:10, 50:50 ที่มีความหมายว่า

การจะทำให้มันผลงานดีได้ 90% ใช้เวลาเท่ากับการจะทำให้เพิ่มจาก 90% เป็น 100%

การเพิ่มจาก 90% (Good Enough) ไป 100% (Perfect) มันไม่ใช่ LInear ไม่ได้ใช้เวลาเพิ่ม 10% แต่เป็น 100% เลย

แนวทางการปฏิบัติ

ต้อง Balance ให้ดีว่างานนั้นซีเรียสแค่ไหน ต้องคุณภาพระดับดีหรือสมบูรณ์แบบ และเวลาที่เสียไปคุ้มมั้ย? ต้นทุนที่มองไว้ได้มองรึเปล่าว่า 90% กับ 100% มันต่างกันสองเท่า?

ไม่ว่าคุณจะยังจมและตรอมตรมอยู่ในวังวน Waterfall หรือคุณจะใช้ Agile แล้ว เรื่องนี้ก็จะฝังอยู่ในทุก Iteration อยู่ดี เพราะปัญหามันอยู่ที่ความพอใจของตัวคน ไม่ใช่ที่กระบวนการ

ทั้งหมดทั้งมวลก็สามารถแก้ได้ด้วยทั้งจากตัวเอง ด้วยการเข้าใจว่ามันมีเรื่องนี้อยู่ ต้องทำใจและรู้จักบริหารเวลา Balance ต้นทุนกับคุณภาพ และยังสามารถช่วยจากคนในทีมได้ด้วยการ Pair อาจจะช่วยลดเวลาการทำจาก 90% เป็น 100% ลงได้ (แต่ก็เพิ่มคน)

ทั้งนี้ขอให้อย่าเข้าใจผิดว่าทำกากๆไปก็ได้ ย้ำอีกทีว่ามันคือ "ดี (Good Enough)" และ "สมบูรณ์แบบ (Perfect)" ไม่ใช่ "กาก (WTF)" และ "สมบูรณ์แบบ (Perfect)" น้ออออ

ตั้งแต่ที่เราตระหนักเรื่องนี้ได้ ก็ทำให้คุมเวลาของการทำงานได้ดีขึ้น ด้วยคุณภาพที่ยอมรับได้ เพราะเอาจริงๆ User ไม่ได้ต้องการ Perfect Solution หรอก ใน Most of the case แค่ Good Enough ก็พอแล้ว

หมั่นฝึกฝนตัวเองเข้าไว้กั๊บ ^_^

Blog สั้นที่สุดในรอบปี เย้ ! จบ 555