slblame
คำถามที่มักจะได้ยินจาก manager คือ
ทำไมเมื่อสัปดาห์ที่แล้ว เราถึงไม่สามารถส่งมอบงานได้นะ ?

คุณคิดว่า คำตอบคืออะไรล่ะ ?
คุณคิดว่า developer ทำงานช้า เพราะว่าอะไรล่ะ ?

มาดูกันสักหน่อยนะ ก่อนจะตัดสินใจ หรือ โยนความผิดมาให้

1. Requirement ไม่ชัดเจน

เป็นสิ่งที่สำคัญมากๆ นะครับ
Developer จะเริ่มทำงานได้อย่างไร ถ้าไม่เข้าใจว่างานนั้นๆ คืออะไร และ ทำงานอย่างไร ?

… แต่แปลกนะที่ developer สามารถทำงานได้ ทั้งๆ ที่ requirement ไม่ชัดเจน
… แต่แปลกนะอะไรที่ไม่เสร็จ มักจะถูกบอกว่า requirement ไม่ชัดเจน
… แต่แปลกนะอะไรที่ไม่ชัดเจน แต่สามารถทำให้เสร็จได้ มักจะไม่ถูกพูดถึง

ดังนั้นลองกลับไปดูสิว่า requirement ในแต่ละข้อมันชัดเจนไหม
หรือทำๆ ไปก่อน เดี๋ยวค่อยถาม … สุดท้ายมันลงเอยด้วยสิ่งที่แย่ๆ ใช่ไหม
แล้วยังจะทำกันอีกหรือ …

… แต่แปลกนะ มันมักจะเกิดเหตุการณ์แบบนี้ ซ้ำแล้วซ้ำอีก
… แต่แปลกนะ ที่เจ็บแล้วไม่รู้จักจำ

บ่อยครั้งพบว่าสาเหตุที่ requirement ไม่ชัด เพราะว่า
เจ้าของ requirement ไม่เข้าใจว่าตัวเองต้องการอะไรบ้าง
ทีมพัฒนาบังคับให้เจ้าของ requirement บอกความต้องการทั้งหมดที่ต้องการภายในครั้งเดียว

สิ่งที่ developer ต้องการจาก requirement คืออะไรบ้างล่ะ

  • ต้องทำให้เข้าใจว่า ทำไมถึงต้องการความสามารถนี้
  • ความสามารถนี้ทำอะไรบ้าง
  • จะใช้มันอย่างไร

ซึ่งในการสร้าง requriement ในแต่ละข้อ
จำเป็นจะต้องมีรายละเอียดพวกนี้เสมอ
โดยต้องมาจากเจ้าของ requirement และ ทีมพัฒนาช่วยกันสร้างขึ้นมา

2. การเปลี่ยนแปลง requirement

สิ่งที่มักจะได้ยินจาก developer อยู่เสมอๆ ก็คือ
Requirement เปลี่ยนอีกแล้วววววว

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

ให้เชื่อก่อนว่า การพัฒนา software นั้นการเปลี่ยนแปลงเกิดขึ้นได้เสมอ
แต่สิ่งที่สำคัญกว่า ก็คือ คุณจะรับมือกับการเปลี่ยนแปลง นั้นได้อย่างไร

3. เรื่อง Context Switching

จะพบว่าเรื่องของ context switching นั้น มันก่อให้เกิดปัญหาได้เช่นกัน
เช่น
นาย ก กำลังทำงานที่ 1 อยู่ แล้วนาย ข เดินเข้าไปถาม เกี่ยวกับงาน 2
ดังนั้น นาย ก จะต้องสลับไปคิดงานที่ 2
เมื่อจบแล้วนาย ก จะต้องสลับกลับมาที่งาน 1

ลองคิดดูว่า ถ้าเกิดขึ้นบ่อยๆ หรือ งานที่ทำมันใหญ่
แล้วผลที่ตามมาคืออะไรล่ะ ?

ยิ่งบรรดาพวก Lead Developer ทั้งหลายนะ
จะมีหน้าที่รับผิดชอบเยอะกว่าคนปกติ เช่น

  • เขียน code
  • Review code
  • Pair programming
  • เข้าประชุมต่างๆ
  • ไปช่วยดับไฟ

คำถามก็คือ มันจะรอดหรือครับ ?
ตัวน่าจะเป็นเกลียว ส่วนหัวน่าจะเป็นน๊อตกันเลยทีเดียว

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

สิ่งที่ manager ต้องคิดอยู่เสมอก็คือ
หน้าที่คือช่วยขจัดปัญหา อุปสรรค ที่จะทำให้งานไม่เสร็จออกไป
แต่เมื่อมีงานเร่ง หรือ ฉุกเฉินเข้ามา
สิ่งแรกที่คุณต้องพยายามทำก็คือ การจัดการด้วยตัวเองก่อน
ไม่ใช่จะ delegate งานมาที่ developer กันท่าเดียว

เรื่องเล่าขำๆ ว่า ทำไมถึงอย่าไปขัดจังหวะการทำงานของ developer

Screen Shot 2557-11-22 at 4.59.21 PM

ดังนั้น ทำอย่างไรดีล่ะ ที่ไม่ให้การส่งงาน หรือ พัฒนามันล่าช้า ?

เริ่มง่ายๆ ด้วยการสร้างสิ่งแวดล้อมที่เหมาะสมต่อการพัฒนา
เมื่อเกิดปัญหา ก่อนที่จะ blame ว่าเป็นความผิดของใคร
ให้พิจารณาตัวเราเองก่อนว่าเป็นอย่างไร

สิ่งที่อาจจะช่วยให้เรามั่นใจว่าจะส่งงานไม่ช้าอีก ประกอบไปด้วย

  • ต้องทำให้ทีมพัฒนาเข้าใจของสิ่งที่กำลังทำ ว่ามันคืออะไร สร้างไปเพื่ออะไร เพื่อให้มีเป้าหมายร่วมกัน
  • ถ้าคุณสามารถทำให้ทีมพัฒนา เชื่อในสิ่งที่กำลังจะทำแล้ว งานมันจะออกมาแบบคนอาจจะตกใจกันเลย
  • พยายามแบ่ง requirement ออกเป็นตัวเล็กๆ อ่านเข้าใจง่าย มีรายละเอียดชัดเจน
  • ลดการสลับคนไปทำงานไปๆ มาๆ นั่นคือลดค่าใช้จ่ายที่เกิดจาก context switching

ดังนั้น การที่จะมา blame ว่าทีมพัฒนา  หรือ developer ว่าทำงานช้า
แต่เพียงอย่างเดียวมันไม่น่าจะใช่แนวทางที่ถูกต้องสักเท่าไรนะ
ใช่หรือเปล่านะ …. หรือว่า ….