Technical Debt ไม่ได้เกิดจาก Developer อย่างเดียว !!!

วันนี้น่าจะเป็นวันที่ผ่านมากับ 1 ปี กับ อีก 6 เดือน สำหรับงานที่เข้ามาทำ BOTDMS - DataSet เป็น Module ที่เหมือนถูกทิ้งไว้กลางทาง หลายคนอาจจะส่งสัยว่าทำไมผมเขียน Blog ตอนนี้ขึ้นมา โดยที่ผมอยากเขียน เพราะอยากแชร์ประสบการณ์ครับ ถ้าเป็นเมื่อ 2-3 ปีก่อน ผมมองว่าเรื่อง Technical Debt มันเกี่ยวกับตัว Developer เป็นหลัก แต่หลังจากทำงานที่เรียกว่าเป็น Full-Stack ก็ได้

• รับ Requirement แต่หลังๆ ต้องไปเก็บเอง เพราะ มันมาแต่ตัวย่อ 3 ตัว
• Develop Code
• Testing
• Build & Release
• Install & Config
• จัดการ Database บ้าง
• จับ User แต่ละกลุ่มที่งานเกี่ยวข้องกันมาคุยกัน
• เดินเอกสาร
• คุยกับ User เพื่อให้ Defect บางข้อมันเคลียร์ หรือชัดเจน

หลังจากทำงานนี้มานานจนเขียนได้หลาย Blog ตาม Tag Technical Debt มุมมองของคำว่า "Technical Debt" ของผมเปลี่ยนไปมาก ผมว่าหนี้พวกนี้ ไม่ได้เกิดจากความมักง่ายของ Developer แต่เกิดจากทุกๆคนที่ทำงานร่วมกัน ทำไมหละ ลองมาดูเหตุผลของผมกัน

User ไม่เข้าใจสิ่งที่ตัวเองทำ รู้แต่ว่าเป็นงานมรดก ที่ส่งมาจากรุ่นสู่รุ่น แต่ไม่มีใครรู้ว่าจริงๆ คือ อะไร

• ตอนที่ทำงานกลายเป็นว่าทีมงานต้องไปดูก่อนว่างานประจำที่ทำ ถูกต้อง หรือป่าว
• ผมว่าก่อนเริ่มงานควรชี้แจงกับ User ถึง งานที่ทำ คำว่า Defect กับ Change ต่างกันแต่ไหม

DRS / CRS คือ เอกสารที่ทำให้มีส่ง เพราะ งานที่ผมต้องทำจาก DRS มันมีแค่ตัวย่อ 3 ตัว

• DRS - Draft Requirement Spec
• CRS - Customer Requirement Spec
• ลูกค้า กับทีมงาน เข้าใจว่าเป็นเพียงเอกสารที่มีให้ครบตามกระบวนการ !!!

ความมักง่ายของทีม BA (Business Analyst) ที่ล่ามระหว่างโลก IT กับ โลกของธุรกิจ

• โปรแกรมเดิมถูกอยู่แล้ว - หลังจาก Developer ทำไปอยู่ 3 เดือน มันถูกครับ โปรแกรมทำงานถูกตามทำโปรแกรมอันเก่าที่ผิด
• ลูกค้าใส่เงินไทยเสมอ !!!! - BA  บอกว่า "อย่าคิดเยอะ" แม้ว่า Developer จะเตือนไปหลายครั้ง ท้ายที่สุด Dev ก็ต้องมารื้อ ระบบต้องมีการหาอัตราแลกเปลี่ยน
• ทำงานไม่เคยมีหลักฐาน Confirm !!!
• ไม่ได้มองภาพรวม ความสัมพันธ์ระหว่าง Module ต่างๆ ทำให้งานกลายเป็น งูกินหาง !!! แก้วนไปวนมาก ลูกค้าชอบใจ กลายเป็นว่า Developer ของ Software House ไปเก็บพนักงานของ Site ลูกค้า แต่ไม่ได้เงินเดือน

มาผู้ที่อยู่เกือบปลายทางอย่าง Developer (SA+Programmer) บ้าง

• ทำใจครับ T___T
• งานโดนเร่งจากเวลา เมื่อเวลามันเร่ง Code มันเลยเน่า หรือไม่คนลาออก งานไม่ต่อเนื่อง
• พยายามดันงานให้ทัน มันก็ต้องมากินเวลาส่วนตัว
• ท้ายที่สุดโปรแกรมเสร็จ แต่มีแก้แบบงูกินหาง
• การดูแลต่อ คู่มือ เอกสาร ที่ควรมีบ้าง กลับไม่มีเลย !!!

• ขาดการนำ Engineering Practice ที่ดีมาใช้งาน CI/CD หรือ พวก Automate Test ครับ แนวคิด Clean Code / DIY / SOLID เป็นต้น

มาผู้ที่อยู่ปลายทาง QA

• งานจากต้นน้ำ มันมาเละมาขนาดนี้ ปลายน้ำทำได้ แค่ทำให้ดีที่สุดครับ

Chain สุดท้ายและทีม MA

• ต้นทางมาดี ทุกอย่างก็ดีครับ มันส่งผลไปเป็นทอดๆ เมื่อก่อน ผมแคร์เส้นนี้้มา ใครไม่ทำอะไรเติมให้ครับ
• แต่ทีม MA หลังมองเป็นผู้ประสบภัยเอง แต่ไม่ Raise นะ ด่าใครก็ได้แต่ ตรงนี้คุณควร Raise ตั้งแต่แรก จะรับไม่รับ สัดส่วนเงิน MA ที่ถือ ถ้าไม่ทำโยกให้คนอื่นก็ได้ ที่เจอประจำ หัวหน้าเอา แต่ลูกน้องไม่เอา และโยนงานต่อจน DEV / QA ออกๆกันไปครับ

ทุกอย่างมีเหตุมีผล Code ไม่ดี อ่านยาก Code เน่า งานไปถึงลูกค้ามี Defect ทำไม Dev ไม่ Test ก่อน แต่ทำไมไม่ลองย้อนกลับไปมองว่าต้นเหตุที่แท้จริงของปัญหา คือ อะไร หรือ เราจะทำแค่ อุดรูรั่วของเรือที่มีเพิ่มเรื่อยๆ จนไม่มีเวลาไปทำสิ่งใหม่ๆ

!!! Technical Debt เกิดจากทุกคนในทีมครับ !!!