ในปัจจุบันเราจะเห็น software แย่ๆ ถูกสร้างขึ้นมาเยอะมากๆ
ทั้งไม่น่าเชื่อถือ ไม่ปลอดภัย ไม่น่าใช้งาน หรือ ใช้งานยาก
ทั้งๆ ที่ผู้พัฒนาก็มีความรู้ความสามารถสูง
มันมาจากสาเหตุอะไรกันนะ ?
หรือว่านักพัฒนามันห่วยแบบที่เขาพูดกันจริงๆ !!
เมื่อลองไปดูความเป็นจริง
จะพบว่าการตัดสินใจเรื่องต่างๆ ในการพัฒนา software นั้น
ทั้งแนวทางการพัฒนา ทั้งเครื่องคุณภาพต่างๆ
ถูกกำหนด และ ตัดสินใจโดยคนอื่นๆ ไม่ใช่ทีมพัฒนาเลย !!
อาจจะมีจากใครคนใดคนหนึ่งในองค์กร …
ซึ่งจะเป็นคนที่มีความสำคัญมากมาย …
เป็นคนที่ตัดสินใจว่า
- ใครควรจะทำอะไร
- จะรู้ว่าปัญหาคืออะไร แก้อย่างไร
- สิ่งที่สร้างมานั้นเสร็จ หรือ ไม่เสร็จ
- จะจ้างบริษัทอื่นๆ มาทำ หรือ outsource หรอ offshore หรือไม่ เพื่อประหยัดค่าใช้จ่าย !!
- จะจ้าง หรือ ไล่ ใครออก
- จะซื้อเครื่องมืออะไรบ้าง
- จะให้มีการ trainning อะไรบ้าง
- จะให้ทีมทำงานแบบไหน มีขั้นตอนการทำงานอย่างไร
และเขาเหล่านั้นมีเวลาลงมาดู มาทำ กันสักเท่าไร ?
ปัญหาที่มักพบเจอคือ
เรื่องคุณภาพของ software มันคือสิ่งที่สำคัญต่อองค์กร
แต่เรามักปล่อยปะละเลยมันไป
ทิ้งเรื่องคุณภาพไว้ที่ปลายน้ำของการพัฒนา software
ถูกกดดันด้วยคำว่า deadline
ซึ่งเราพบว่า deadline มันขยายได้เสมอ … มันยังไงๆ นะเออ
คนกำหนดเรื่องเวลา และ จัดเรียงความสำคัญของงาน
ก็มาจากฝ่าย marketing และ business
ซึ่งก็จะพยายามสรรหา feature ให้เยอะๆ เข้าไว้
เพื่อทำให้หัวหน้าของเขาเหล่านั้นดีใจ
บ่อยครั้งที่ทางทีมพัฒนา และ ทีมทดสอบ บอกว่า software มันยังไม่พร้อมนะ !!
เนื่องจากเวลามันน้อยไป ต้องการเวลาเพิ่มนะ
แต่ทาง business ก็จะบอกว่า ไม่ได้นะ เราเตรียมทุกอย่างไว้แล้ว
ไม่ว่าจะอย่างไรก็ต้องเอาขึ้นให้ได้
คำถาม
สิ่งที่เกิดขึ้นต่อจากนี้คืออะไรล่ะ ?
คำตอบ
มันคือการเผางาน แบบหามรุ่งหามค่ำ
ใส่ technical debt ต่างๆ เข้าไปมากมาย
เพื่อทำให้สามารถเอาขึ้น และ ส่งมอบได้
หรือบ่อยครั้งจะเอา software ที่มี bug ขึ้นไป
แล้วเราค่อยกลับมาแก้ไขในภายหลัง
และเรามักจะพบเจอปัญหาแบบนี้ซ้ำแล้วซ้ำเล่า มันยังไงกัน ?
ไหนเรามักจะมีคำพูดสวยหรูว่า “เรียนรู้จากความผิดพลาด“
คำถาม แล้วเราได้เรียนรู้ และ ปรับปรุงให้มันดีขึ้นไหมล่ะ ?
ตอบกันหน่อยสิ …
แล้วเราจะแก้ไข หรือ ลดปัญหาเหล่านี้ไปได้อย่างไรล่ะ ?
อย่างแรกเลย “หยุดผิดพลาดแบบเดิมๆ ซะที“
ดังนี้
1. ให้สนใจเรื่อง Time-to-market และค่าใช้จ่าย
ดังนั้น ลด ละ เลิก กับการทำงานทุกๆ อย่างให้ตาม dead line
แต่เปลี่ยนใหม่ให้ทำงานเป็นรอบการทำงานสั้นๆ
เพื่อให้ทุกรอบการทำงาน สามารถส่งมอบงานได้
ซึ่งรอบการทำงานสั้น ค่าใช้จ่ายก็น้อยลง
เราสามารถแก้ไข เปลี่ยนแปลงได้ในรอบสั้นๆ
ยิ่งถ้าเจอปัญหาเราก็สามารถแก้ไขได้อย่างรวดเร็ว
2. ทดสอบเสียแต่เนิ่นๆ
ลด ละ เลิก การทดสอบเมื่อพัฒนาเสร็จทั้งหมด
ซึ่งเราพบว่ามันไม่เคย work เลยนะ !!
แต่ชอบทำกันเหลือเกิน …
ทดสอบยิ่งช้า มันหมายถึงเราซ่อน หรือ สร้าง bug ไว้เยอะ
การแก้ไขก็ใช้เวลาเยอะตาม
ส่งผลให้ส่งมอบงานล่าช้าอย่างแน่นอน
ดังนั้น ทีมที่เกี่ยวกับกับการพัฒนา software
ไม่ใช่เพียงทีมพัฒนา และ tester นะ
จะต้องช่วยกันทดสอบ ทั้ง TDD, BDD, ATDD, Manual testing
รวมไปถึงระบบ Continuous Integration ก็ต้องมีไว้ให้ครบ
3. คุยกับลูกค้าอยู่บ่อยๆ เพื่อทำให้รู้ว่าสิ่งที่กำลังสร้างมันใช่หรือไม่ ?
เนื่องจากการพัฒนา software มันคือกระบวนการแก้ไขปัญหา
มันคือกระบวนการเรียนรู้ ดังนั้น
เราจะรู้ได้อย่างไรว่าสิ่งที่กำลังพัฒนามันตรงตามความต้องการหรือไม่ ?
เราจะรู้ได้อย่างไรว่าสิ่งที่กำลังพัฒนาผู้ใช้งานชอบไหม ?
เราจะรู้ได้อย่างไรว่าสิ่งที่กำลังพัฒนาผู้ใช้งานเกลียดไหม ?
ดังนั้น เราต้องส่งมอบงานเป็นรอบสั้นๆ เพื่อเก็บ feedback จากผู้ใช้งานอย่างต่อเนื่อง
เพื่อทำให้เราพัฒนาได้โดนใจผู้ใช้งาน
เพื่อปรับปรุงให้ software มันดีขึ้นอย่างต่อเนื่อง
ทำแบบนี้อยู่อย่างต่อเนื่อง และ สม่ำเสมอ
4. เลิกหา Best practice ต่างๆ หรือ How to แบบ 1 2 3 ได้แล้ว
แต่ให้เลือกทำในสิ่งที่จำเป็น และ ตอบโจทย์ในสิ่งที่เราทำจะดีกว่า
หาสิ่งที่เหมาะสมกับงานนั้นๆ
เราไม่สามารถใช้วิธีการแบบเดิมๆ ใน software ทุกๆ ตัว
เราไม่สามารถใช้วิธีการแบบเดิมๆ ในทุกๆ ทีม
ต้องปรับเปลี่ยนให้เหมาะสมกันไป
ดังนั้นก่อนที่จะนำอะไรมาใช้นั้น
เราควรต้องลองทำ หรือ ลองผิดลองถูกมาแล้ว
จนทำให้เราเข้าใจว่า มันดีอย่างไร แก้ไขปัญหาอะไร
จากนั้นจึงนำมาประยุกต์ใช้งานต่อไป
ดังนั้น การเรียนรู้มันสำคัญอย่างมาก
5. รับฟังความคิดเห็นจากทีมพัฒนาเสียบ้าง
คนที่ทำงานจริงๆ คือ ทีมพัฒนา
ดังนั้น ควรที่จะรับฟังความคิดเห็นด้วย
ถ้าอะไรที่ทางทีมพัฒนาบอกว่า จะไม่เสร็จ ก็ควรตั้งใจรับฟัง
เพื่อให้รู้ และ เข้าใจว่า ปัญหาคืออะไรบ้าง
คำถาม
คนที่รู้ปัญหาเชิงลึกเกี่ยวกับการพัฒนาที่สุดคือใคร ?
ดังนั้น ถ้าคุณไม่เชื่อเขาเหล่านั้น แล้วจะไปเชื่อใครอีกล่ะ !!
สุดท้ายแล้ว การเรียนรู้จากสิ่งที่ผิดพลาดมันคือสิ่งที่ดี
แต่ควรที่จะเรียนรู้ที่จะแก้ไขไม่ให้มันเกิดขึ้นซ้ำแล้วซ้ำเล่า
ยิ่งถ้าเราทำงานเป็นรอบสั้นๆ แล้ว
เราก็สามารถนำปัญหาที่เกิดขึ้นมาพูดคุย เพื่อหาแนวทางการแก้ไข
ซึ่งทำให้เราแก้ไข และ ปรับปรุงอย่างทันท่วงที
ปัญหาต่างๆ ก็อย่าไปโทษว่าเป็นความผิดของใครล่ะ !!
ให้คุยกันว่า เราจะแก้ไขปัญหาอย่างไรกันดีกว่า
น่าจะสร้างสรรมากกว่านะครับ
ยิ่งถ้าเป็น feedback แย่ๆ จากทางผู้ใช้งาน ยิ่งมีความสำคัญมากมาย
เราต้องใส่ใจเป็นพิเศษ
Reference Websites
http://swreflections.blogspot.com/2015/07/dont-blame-bad-software-on-developers.html
http://www.stevemcconnell.com/articles/art04.htm
