ว่าจะไม่เขียน Blog นี้แล้ว แต่มันอดเขียนไม่ได้จริง กล่าวถึง DataSet LQ1 ของ BOT แหละ Site ที่จ้างบริษัทที่ผมรับเงินเดือนไปทำเนี่ย ไม่รู้ว่าที่ต้องส่ง BOT จริงๆ ต้องส่งอย่างไร มันเลยเป็นปัญหาที่ว่า UAT บน Production เนี่ยแหละ (แล้วมันมีช่วงการ UAT ไปทำไม ในเมื่อ User ต้องเซ็นผ่านให้ตรงกับ KPI องค์กร)
มาที่ Timeline ของ DataSet ชุดนี้ก่อน
- 2015 (ช่วงต้นปี) : เริ่มทำระบบนี้แหละ หลังจากไม่มีใครกล้าเสี่ยงมาทำ ตอนนี้เข้าใจแล้ว ลึกซึ้งงง
- 2015-06: ส่งให้ User UAT และจบช่วงต้นเดือน 8 และขึ้น Production เรียบร้อย
- 2015-08 (ช่วงสิ้นเดือน) : BOT มีประกาศให้ใช้ข้อมูล ณ วัน Settle
- 2015-09-30 : ปรับแก้เสร็จ ส่งให้ไปใหม่ จำวันแม่นครับ User ขอเปลี่ยนเอาราคาตลาด T-1 แทน
- 2016(ช่วงมกราคม) : ส่งโปรแกรมใหม่ไปให้ตรวจ และตรวจผ่านด้วย !!!!!
- 2016-03-xx : หน่วยงานใหม่ของ Site ที่ทำโผล่มาบอกว่ามันคิดผิดนะ และเป็น User ที่ใช้งาน DataSet นี้ด้วย
- ปัจจุบัน : Dev ก้มหน้ารับชะตากรรมแก้งานต่อไป และไปเจออะไรที่มันขัดแย้งมากเลยเขียน Blog เลย
มาที่ฝั่ง User ก่อน
- ไม่รู้สาระของตัว DataSet ว่าต้องส่งอะไรให้ BOT
มาฝั่งทีม BA บ้าง
- ไม่ศึกษาเนื้อหาว่า โดยให้เหตุผลว่าเวลามันเร่ง สุดท้ายเอกสาร มาแต่ Code ตัวย่อ 3 ตัวว่า LQ1 มันก็ LKILL1 จริงๆ และบอกว่ามันย่อมาจากอะไร พระเจ้าาาาา ไม่มีการศึกษาเลยว่าตัว Core หลักของระบบมันทำได้ไหม
- Change ที่มาจาก User ไอ้คนทำอย่างผม ก็มองว่ามันแปลกๆแล้ว ลาก BA ไป 3 คนประกบ User มันมาจากปัญหาข้อแรกแหละ กลายเป็นว่าไปรับปากแก้
- ไม่ศึกษาว่าใครต้องใช้งานบ้าง ผมทำโปรแกรมตามแนวคิดที่ผิดๆเสร็จ Dev ทำระบบเสร็จใช้งานจริงไปแล้วครึ่งปี อยู่ๆก็มีหน่วยงานใหม่ ที่ไม่เคยยุ่งกับระบบตั้งแต่ตอนแรกเลยยยยยย อยู่มาบอกว่า ไอ้ที่มันคิดลบหนึ่งวัน มันผิดนะ เอาประกาศ BOT ไป (ผมเข้าใจว่าที่ Site นี้ตื่นตัวเนี่ย เพราะ BOT มาสุ่มตรวจนี่เอง)
Dev ผู้รับกรรม
- อยู่ดีๆ ก็มาซวยก็ตอน BOT ประกาศว่า เวลาทำต้องคิดจำนวน ณ วัน Settle นะ เฮ้ยยยย ตอนไปทำ TOR DRS ทำไมไม่ตรงลงให้เรียบร้อย กลายเป็นว่าอยู่โปรแกรมผิดซะงั้น
- ผิดแค่ลบหนึ่งวัน รื้อทั้งระบบ
- สุดท้ายวันที่ประชุม Final กับ User ใหม่ Dev ต้องทำตัวอย่าง ลากคนที่เกี่ยวข้องมาประชุม และช่วยกันตอบแทน (ไม่ใช่หน้าที่กรูเลยยยย)
จากปัญหาเปลี่ยนแนวคิดของระบบบ้าง มันก่อปัญหาอะไรบ้าง
- จากคำพูดเล็กๆ "เอาราคาตลาด T-1 นะ" คำพูดสั้นๆ แต่ปัญหาที่หมกเพียบครับ ถ้ารายการเพิ่งทำสัญญาวันแรก เอา T-1 จากไหน BA แก้ปัญหาเฉพาะหน้าไป ทำอย่างงี้นะ ...... บอก Dev ไปเฉพาะหน้า แต่ไม่ทำเอกสาร !!!!! และปัญหาจิปาถะอื่นๆ และประวัติศาสตร์ถูกบันทึกไว้ใน Code
- ดอกที่สอง เอาข้อมูล ณ วัน Settle แต่ปัญหา คือ Core หลักตอน Process EOD คิดวัน Trade !!!!!
จากปัญหาทั้งหมดรวมถึงเรื่องที่ User ชอบไป UAT บน Production เนี่ย ส่งผลอะไรกับองค์กรบ้าง
- เสียเวลา - มานั่งแก้วนไป วนมา
- มีความเสี่ยง - ต้องมาเสี่ยงตายแก้ปัญหาที่ Production ทั้งๆที่เราเคยไล่ให้ User ทดสอบตอน UAT หรือลองทดสอบ Flow การทำงาน แก้ตอน UAT ยังทันนะ
- เสียองค์ความรู้ - เพราะ ไม่รู้ว่า Business จริงๆ คือ อะไร แก้ไปแก้มาสับสน
- Code เน่าๆแน่ๆ - ถ้าแก้แบบรีบๆส่ง และเป็นหนี้สะสมทบต้นไป (Technical Debt)
- อารมณ์คนแก้งาน - อารมณ์เสียแน่ๆ โปรแกรมตรวจผ่านแล้ว อยู่มาเปลี่ยน แล้วตีเป็น Defect กรู อดหลับ อดนอนมาหลายคืนทำงานวันหยุด เพื่อ KPI ของ User นะครับ T____T
และปิดท้ายด้วยตำนานของ DataSet ทำเสร็จแล้ว ออกยกทีม 55555 ตอนนี้ BA ก็ออกไปแล้วนะ
Discover more from naiwaen@DebuggingSoft
Subscribe to get the latest posts sent to your email.