ทำให้ดีที่สุด — ด้วยสิ่งที่เรามี

เคยเจอมั้ยที่มีบางคนชอบหยิบยกความถูกต้องและงดงามตามหลักการของการออกแบบระบบ (System Architectural Design) มาเป็นข้ออ้างในการไม่ยอมทำตามความต้องการของ Product Owner ซึ่งพูดแทนลูกค้า เช่น

  • โหยพี่ เล่นอ่านค่าเซ็ตติ้งจากเท๊กซ์ไฟล์เนี่ยะนะ โบราณ เห่ย ไม่มีใครเค้าทำกันแล้ว ต้องเก็บในฐานข้อมูลครับ ต้องมีหน้าเวปแอดมินให้เข้ามาแก้ไขได้ซิ
  • อะไรพี่ ดั้มพ์ฐานข้อมูลมาเป็นก้อนๆทุกคืนแล้วมาอิมพอร์ตและประมวลผลทีหลัง? คิดได้ไง มันต้องเขียนเป็น API เปิดให้ระบบข้างนอกเชื่อมต่อเข้ามาเพื่อรับส่งข้อมูลสิคะ มันถึงจะถูกต้อง
  • พูดตรงๆนะพี่ ระบบที่พี่จะทำมันไม่สมบูรณ์หรอก เนี่ยะนะทำขึ้นมาก็เป็นแค่ทางออกชั่วคราวให้กับลูกค้าแค่รายเดียว แบบนี้มันไม่คลีนครับ พี่ต้องไปบอกให้ลูกค้าที่เหลือ (อีก 20 ราย) ย้ายมาใช้ระบบใหม่นี้ด้วย มันถึงจะถูกต้อง

อ้างเรื่องการออกแบบทางเทคนิคเพื่อบังคับให้ Product Owner กลับไปทำการบ้านมาใหม่ กลับไปคุยกับลูกค้ามาใหม่ กลับไปคิดสรุปความต้องการทางธุรกิจมาใหม่


เคยเจอมั้ยที่มีบางคนชอบอ้างเรื่อง Performance ของระบบ เอะอะอะไรก็ห้ามทำการส่งข้อมูลแบบทันที (Real-Time) นะมันหน่วงระบบ ต้องรอเก็บเป็นแบทช์ (Batch) ไว้ค่อยส่งทีเดียวเยอะๆตอนดึกๆ — ผมก็สงสัยอยู่ว่าถ้าผมถามเค้ากลับไปด้วยคำถามนี้เค้าจะตอบได้มั้ย

“น้องๆ แล้ว ณ ปัจจุบันระบบน้องรองรับได้กี่รีเควสต่อนาทีครับ? คอขวดมันอยู่ตรงไหนครับ?”

ผมว่ามีเยอะที่ตอบไม่ได้ เชื่อปะ? เพราะอะไร? — เพราะพวกเค้าเองก็ไม่รู้ไงว่าจริงๆแล้วระบบของเค้าเองมันมีความสามารถแค่ไหน เพราะพวกเค้าไม่เคยใส่ใจที่จะรู้ ไม่เคยทำ Load Test ไม่รู้จัก Stress Test ไม่รู้อะไรเลย แต่ แต่ แต่ … แต่ขออ้างปัญหา Performance ไว้ก่อน เพราะคนส่วนใหญ่ฟังแล้วจะรู้สึกกลัว เฮ้ยถ้าทำ Real-Time แล้วระบบล่ม แกรับผิดชอบนะ … อ้าาา งั้น Batch ก็ได้ครับเพ่

ทีแบบนี้หละอ้างความเสี่ยงทางเทคนิคเพื่อให้ตัวเองสบาย


หลายต่อหลายครั้งที่งานไม่เดินหน้าไปไหนก็เพราะคนในมาขัดแข้งขัดขากันเองแบบนี้ ทีมไหนที่วันๆเอาแต่ประชุมและถกเถียงกันโดยไม่ได้ทำงานจริง (เขียนโค๊ด เตรียมเทส บิ้วด์เซิร์ฟเวอร์ อื่นๆ) เดาได้เลยว่าพวกเค้ากำลังตบตีกันเองอย่างเมามัน

ผมเขียนบทความนี้จากมุมมองของ Product Owner ที่มีความพยายามจะแก้ปัญหาให้ลูกค้า แน่นอนเค้าทำคนเดียวไม่ได้ เค้าต้องการเพื่อนร่วมงานที่เป็นที่ปรึกษาและเป็นผู้นำให้เค้าได้ในด้านเทคนิค … Product Owner คนนี้อยากได้เพื่อนร่วมงานที่มีแนวคิดว่า

“Do The Best With What You Have” — “ทำให้ดีที่สุดด้วยสิ่งที่คุณมี”

ไม่ใช่แค่ “Do The Best” ทุกคนก็อยากทำให้ดีที่สุดอยู่แล้วแต่คำว่าดีที่สุดมันมีข้อจำกัดอยู่ด้วยทรัพยากรที่คุณมีไม่ว่าจะเป็นเวลา เงิน คน ความรู้ ทักษะ เครื่องไม้เครื่องมือ … Product Owner คนนี้เข้าใจและเห็นด้วยถ้า

  • ค่าเซ็ตติ้งในเท๊กซ์ไฟล์มันเชย เก็บในฐานข้อมูลดูจะดีกว่าแต่ถ้าต้องใช้เวลาเพิ่มอีกหนึ่งเดือน — ลูกค้าเค้ารอไม่ได้
  • มี API รับส่งข้อมูลแบบเป็นระบบย่อมดีกว่าดั้มพ์ฐานข้อมูลมาแบบทึ่มๆแต่คนในทีมไม่มีใครเขียน API เป็น (สมมติๆ) แปลว่าต้องใช้เวลาอีกสามเดือนหาคนเพิ่ม ของบประมาณเพิ่มอีก 30% และงานจะต้องเลื่อนออกไปอีกหกเดือน — ป่านนั้นคู่แข่งกวาดลูกค้าไปเกลี้ยงตลาดแล้ว
  • มันมีปัญหา Performance จริงๆถ้าส่งข้อมูลแบบ Real-Time เพราะคอขวดอยู่ที่ระบบหลังบ้านที่ทีมเราไม่ได้เป็นเจ้าของ ถ้านั่นแปลว่าเค้าต้องกลับไปต่อรองกับลูกค้าเพื่อทีม — เค้าก็พร้อมจะทำ

ไม่ว่าจะเลือกทางไหนผมเชื่อว่ามันไม่คลีนหรอก จริงๆก็ไม่มีอะไรคลีน ไม่มีอะไรสมบูรณ์แบบ ทุกอย่างมันมีหนี้ที่เราต้องชดใช้ในอนาคตอยู่แล้ว หนี้ทางเทคนิค (Technical Debt) หรือหนี้ทางธุรกิจ (Business Debt) หน้าที่ของคนที่อยู่ทีมเดียวกันคือ

  1. ยึดความต้องการและความสุขลูกค้าและผู้ใช้เป็นหลัก
  2. วิเคราะห์และชั่งน้ำหนักเพื่อเลือกทางออกที่เหมาะสมที่สุดของทั้งธุรกิจและเทคนิค (Trade-Off)
  3. “Do The Best With What You Have”

ทีมที่เก่งหรือไม่เก่งมันวัดกันตรงนี้ — ด้วยข้อจำกัดมากมาย ใครสามารถสร้างผลงานที่ยอดเยี่ยมที่สุดออกมาได้


ผมเขียนบทความนี้เพราะอยากเปลี่ยนแปลงสิ่งที่เป็นอยู่ในอุตสาหกรรมการผลิต ซอฟท์แวร์ให้ดีขึ้นตามความเชื่อและประสบการณ์ของผม ถ้าเพื่อนๆเชื่อในแนวทางเดียวกัน เรามาช่วยกันคนละไม้คนละมือทำให้สังคมของเราดีขึ้นครับ จะแชร์บทความนี้ผ่าน Social Network หรือจะแบ่งปันเรื่องราวนี้ให้คนที่นั่งข้างๆฟังบ้างก็ได้

The Future Has Arrived — It’s Just Not Evenly Distributed Yet, William Gibson

อนาคตอยู่ตรงนี้แล้ว เรามีหน้าที่ต้องถ่ายทอดมันออกไปให้คนอื่นได้สัมผัสสิ่งดีๆร่วมกันครับ

Show your support

Clapping shows how much you appreciated Piyorot’s story.