Quality vs Quantity
🤔 คุณภาพดีแต่ทำเสร็จช้า กับ ทำเร็วแต่คุณภาพกาก เลือกไรดี ?
Last updated
🤔 คุณภาพดีแต่ทำเสร็จช้า กับ ทำเร็วแต่คุณภาพกาก เลือกไรดี ?
Last updated
ในเรื่องของธุรกิจ เวลา คือสิ่งที่สำคัญที่สุด เพราะถ้าปล่อยของออกตลาดได้ช้า นั่นก็อาจจะหมายถึงจากไปของบริษัทเลยก็เป็นได้ และแน่นอนเหล่าโปรแกรมเมอร์ก็มันจะโดยท้าทายด้วยตัวเลือก 2 ตัวนี้เสมอ
"ทำให้ส่งงานได้ไปก่อนแล้วค่อยมาแก้ทีหลัง" หรือจะเลือก "ทำให้มันถูกต้องไปเลยแต่อาจจะช้าหน่อยนะ"
คำตอบมีหลากหลายแง่มุมมาก ดังนั้นในบทความนี้ผมอยากจะให้แนวทางแบบรวบรัดว่าทีมควรจะเลือกเดินยังไงต่อเมื่อเจอปัญหาพวกนี้ครับ
1.มันเป็นเรื่องคอขาดบาดตายแล้วจริงๆ - เช่น บริษัทเราอาจไปรับปากอีกบริษัทหนึ่งว่ามันจะเสร็จ ซึ่งเมื่อถึงเวลาที่ต้องส่งงาน เหล่า developer ก็ต้องทำทุกอย่างให้มันได้ตามที่คุยกันจริงๆไม่ว่าจะด้วยอะไรก็ตาม
2.ทีมขวัญกำลังใจตก - เหมือนจะไร้สาระ แต่ถ้าทีมส่งมอบอะไรไม่เคยได้ตามที่ตกลงเลยบ่อยๆเข้า ทีมนั้นจะหมดกำลังใจในการทำงานและยิ่งทำก็จะยิ่งกดดัน ดังนั้นในบางครั้งถ้ามันพอจะปล่อยได้และไม่ได้เป็นเรื่องซีเรียสมาก เราก็อาจจะต้องยอมปล่อย เพื่อให้ทีมได้มีความเชื่อมั่นกลับมาอีกครั้งนั่นเอง
1.สิ่งนั้นมันเป็น Core Architecture และเราคุยกับลูกค้าแล้วเขารับผลกระทบที่ตามมาได้ - เพราะตัว core architecture ถ้าเราทำมันแบบส่งๆแล้วล่ะก็ Bad Code เหล่านั้นจะลามและแก้ยากมาก ดังนั้นตัดไฟตั้งแต่ต้นลมจะดีกว่าครับ
2.ใช้เวลาแก้แล้วก็ยังอยู่ภายใน iteration ที่ commit อยู่ - เพราะ Bad Code ถ้าเราปล่อยไว้แทบจะเรียกได้เลยว่า ไม่มีใครกลับมาแก้หรอก ถ้าไม่ได้ใจรักจริง และการปล่อยให้มี Bad Code อยู่สุดท้ายมันจะกลายเป็น Technical debt ซึ่งเจ้าตัวนี้นี่แหละคือตัวภัยร้ายที่จะฆ่าบริษัทเราในภายหลัง (อ่านเรื่องนี้ได้จากบทความ ปัญหาที่ใหญ่ที่สุดในการทำซอฟต์แวร์) ดังนั้นถ้าไม่มีผลกระทบมากผมเลือกที่จะลดจำนวน features ที่จะ commit ลงแล้วเก็บงานให้มันเป็นของที่มันควรจะเป็นจะดีกว่าครับ
สุดท้าย ไม่ว่าจะเลือกวิธีไหนมันก็ต้องมีผลตามมาแน่นอน ดังนั้นไม่ว่าจะทำอะไร (ถ้าทำได้) เราก็ควรจะปรึกษากับลูกค้าก่อนที่จะลงมือตัดสินใจเดินงานต่อ เพราะในบางทีของที่เราคิดว่าสำคัญนั้น ในมุมของลูกค้าอาจจะไม่สำคัญเลย และตรงกันข้ามกัน ของที่ลูกค้าคิดว่ามัน โคตรสำคัญ เราดันกลับไปมองว่ามันไร้สาระก็เป็นได้