by

ในการพัฒนา software เวลาที่มีการพัฒนา software อย่างไม่ถูกต้อง ตัวอย่างเช่น software architecture ที่ออกแบบมาได้ไม่ดี, code ที่เขียนมาแย่ ยากต่อการเปลี่ยนแปลง, process การทำงานที่แย่

ทั้งหมดนี้อาจจะเกิดขึ้นเนื่องจากหลายสาเหตุ ยกตัวอย่างเช่น มีความกดดันจากฝ่ายต่างๆ ให้เราต้องเร่งพัฒนาเพื่อให้ส่งมอบได้ทันกำหนด ทำให้เกิดคำพูดที่ว่า

ทำไปก่อนค่อยกลับมาแก้

การขาดกระบวนการทำงานที่ดี เช่น เขียน code โดยไม่มี spec, หรือมี document ที่ไม่มีการแก้ไขให้เป็นปัจจุบัน, หรือแม้แต่การที่เราไม่รู้ว่าสิ่งที่เรากำลังพัฒนาอยู่นั้นมันไม่ดี เราไม่รู้ด้วยซ้ำว่าเรากำลังใช้วิธีที่ผิด

ปัญหาเหล่านี้เราเรียกว่าเป็น Technical Debt หรือ หนี้ทางเทคนิค

เรียกว่าหนี้ มันก็ต้องมีการชำระ(พร้อมดอกเบี้ยทบต้น)

ถ้าเรารีบเร่ง deliver ของที่ไม่ดีออกมา เวลาผ่านไปเราก็จะเริ่มพบกับปัญหา หรือหนี้ที่เราได้ก่อไว้ เริ่มแรกเราอาจจะมี bug ให้เราต้องแก้ไข, เวลาผ่านไปก็พบว่าเราเจอปัญหาด้าน performance, พอเราเข้าไปแก้ไข ก็พบว่า structure หรือ architecture ที่ออกแบบมามันมีปัญหา ไม่มีใครกล้าแก้ไข เพราะว่าไม่มี executable spec ที่สามารถทำ automated test ได้, พอมีอัศวินกลุ่มหนึ่งเข้ามาแก้ไข ก็พบว่าขาดคนมา test ระบบ อาจะเพราะมีคนไม่พอ หรือไม่มี document บอกว่าระบบเดิมเป็นอย่างไร feature ไหนที่ขาดหายไป

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

สุดท้ายปัญหาเหล่านี้ก็กลับมาส่งผลกระทบต่อธุรกิจในที่สุด

เพราะเหตุนี้จึงมีหลายคนเสนอแนวคิดที่ว่า

Technical Debt เป็นบาป วิธีที่ดีที่สุดคือ เราต้องไม่ปล่อยให้เกิด Technical Debt เลย

ถ้าเราไม่อยากสร้างหนี้เลย เราอาจจะต้องทำตาม engineering practice มากมาย เช่น TDD, pair programming, continuous integration, continuous delivery, automated testing, refactoring, code review และอื่นๆ อีกมากมาย

การทำ software นั้นเป็นงานที่อาศัย skill สูงมาก หากเราอยากได้ของดี เราก็ต้องยอมจ่ายในราคาที่เหมาะสม และเวลาในการพัฒนาก็จะนานกว่าด้วย

ตอนเราเริ่มพัฒนา product/project ใหม่ซักตัว เรามองเห็นภาพ software ที่ perfect มี feature โน่นนั่นนี่ เราก็ควรคำนวนหยาบๆ ได้ว่าจะต้องอาศัยใครมาพัฒนา, ทำกี่คน และจะใช้เวลาอย่างน้อยที่สุดเท่าไร

ถ้าเราเป็นพวก conservative ไม่ยอมก่อหนี้เลย เราต้องยินดีที่จะเสียเวลาพัฒนา software ที่ perfect ยอมเสียเวลาเป็นหลายปีในการพัฒนาเพื่อให้เราได้ของที่ดีตามที่เราตั้งใจออกมา

แต่บังเอิญว่าถ้าเราอยู่ในธุรกิจที่มีการแข่งขันสูง มีอีกแนวคิดหนึ่งที่เราสามารถนำมาใช้ คือเราลองมองว่า

Technical Debt เป็น Leverage

เราไม่จำเป็นต้องทำ software ที่ดีเลิศก็ได้, มี technical debt บ้างก็ได้

อ่าวเฮ้ย ! ได้ไง ?

ลองยกตัวอย่างในโลกจริงดูซักอันสองอัน เช่น

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

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

กลับมาที่ software บ้าง ในขณะที่คนที่เป็น conservative ไม่ปล่อยให้มี technical debt เลย ใช้เวลาเป็นเดือนๆ ปีๆ ทำ feature ออกมาได้เนียนมาก clean code สุดๆ แต่ก่อนที่จะทำเสร็จก็พบว่าคู่แข่งได้ launch product ออกมาก่อนแล้ว ได้พื้นที่สื่อก่อนแล้ว มีรายได้เข้าบริษัทก่อนแล้ว

มันอาจจะแย่กว่านี้ได้อีก ถ้าเราใช้เวลาทำสิ่งที่เทพที่สุดออกมาเพื่อพบว่าผู้ใช้ไม่ต้องการ

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

  • ในช่วงแรก เราไม่รู้ด้วยซ้ำว่า feature ที่เราทำออกมานั้นมีใครต้องการรึเปล่า(นอกจากเรา) การยอมเป็นหนี้บ้าง จะทำให้เราสามารถตัด feature ทิ้งได้สบายๆ เพราะใช้เวลาแค่นิดเดียวในการเข็นมันออกมา – เรา stop loss ได้เร็วกว่าคู่แข่งมาก
  • เมื่อเรา deliver ได้เร็ว ก็เท่ากับเราได้รับ feedback เร็ว ก็ improve ได้เร็ว product จะดีขึ้นเรื่อยๆ
  • การที่เรามีของออกมาโชว์ ทำให้เป็นที่ดึงดูดต่อนักลงทุน เราสามารถระดมทุนได้ก่อนคู่แข่งที่ไม่มีตัวตน แล้วใช้เงินที่ได้มานั้นมาแก้ technical debt ได้

สิ่งที่สำคัญก็คือ เราต้องมีเกณฑ์ว่า เราสามารถปล่อยให้อะไรเป็น debt ได้บ้าง กำหนด definition of done ให้ชัดว่าถ้าทำได้เท่านี้ เรา happy แล้ว และเราต้องตระหนักรู้อยู่เสมอว่าเรามีอะไรที่เป็น debt บ้าง

เมื่อเราใช้ debt เป็น leverage เพื่อ growth แล้ว เราจะได้ผลประโยชน์อะไรจากมัน เพื่อที่ในอนาคตจะได้นำสิ่งที่เราได้มากลับไปชำระหนี้โดยการ improve product ของเราให้กลับมาดี ปลอด debt อีกครั้ง หรือจะคงระดับ debt ไว้เพื่อ growth ก็สุดแล้วแต่ อย่างน้อยที่สุดก็ขอให้เข้าใจความเสี่ยงของ technical debt ว่าอยู่ในระดับไหน ตรงนี้ technical founder จะเป็นผู้ตอบได้ 🙂

Comments

comments

Page 1 of 11