เราควรจะเลือก Software Development Framework / Software Development Life Cycle อย่างไรดี?
หลายครั้งที่ทีมบริหารพยายามพัฒนา Software Development Framework ของ Jitta ทางทีมก็ได้ Research ข้อมูลเพิ่มเติม ซึ่งส่วนใหญ่ก็มักจะได้แนวทางหลายๆ อย่างจากบริษัท Technology ยักษ์ใหญ่ที่เป็นที่รู้จักกันดี ซึ่งหลายๆ ครั้งมันช่างไม่สามารถเอามาปรับใช้ให้เข้ากับลักษณะการทำงานได้ในทันที คิดว่าถ้าแบ่งปันเรื่องนี้น่าจะเป็นประโยชน์ นอกจากนี้ยังได้แรงบันดาลใจจากน้องๆ Engineer ที่ Jitta ที่ได้แบ่งปันความรู้ Technical ต่างๆ อยู่สม่ำเสมอ ผมก็เลยคิดว่าถ้าได้แบ่งปันเรื่องราวของ การบริหารงานทางด้าน Software Development บ้าง น่าจะเป็นประโยชน์
คำถามที่ CTOs และ IT Managers จำนวนมากรวมทั้งผมด้วย ครุ่นคิดอยู่เสมอๆ มักจะเป็น “เราจะใช้ Framework/วิธีการ อะไร ในการบริหาร Software Development ดี?” ถ้ามาถกกันเรื่องนี้ ก็มักจะมีปรมาจารย์ และผู้สนับสนุน จากหลายค่ายออกมาอภิปรายกัน โดยไม่จบไม่สิ้น ซึ่งเรื่องที่อยากจะคุยให้ฟังในวันนี้ ไม่ใช่คำตอบของคำถามนี้ แต่เป็นแนวคิด และวิธีการที่จะให้ได้มาซึ่งคำตอบในคำถามนี้ต่างหาก … นั่นแปลว่ามันไม่มีวิธีการบริหาร Software Development ที่ดีที่สุดหรือ? คำตอบคือ ใช่ครับ … “บทกวีที่ไพเราะที่สุดยังไม่ได้แต่ง ปติมากรรมที่สวยที่สุดยังไม่ได้ปั้น” ในโลกแห่งความเป็นจริงนั้น คงไม่ใช่ดีที่สุด ถูกหรือผิด แต่มันเป็นเรื่องของ “ความเหมาะสม” ต่างหาก
ความเข้าใจในองค์กรของเราเอง ย่อมเป็นจุดเริ่มต้นแรก “รู้เขารู้เรา รบร้อยครั้งชนะร้อยครั้ง” … เป็นคำกล่าวที่คนไทยมักเข้าใจว่าเป็นคำพูดของซุนวู แต่ที่จริงแล้วไม่ถูกต้องเสียทีเดียว ซุนวูกล่าวว่า … “หากรู้เขารู้เรา แม้นรบกันตั้งร้อยครั้งก็ไม่มีอันตรายอันใด ถ้าไม่รู้เขาแต่รู้เพียงตัวเรา แพ้ชนะย่อมก้ำกึ่งอยู่ หากไม่รู้ในตัวเขาตัวเราเสียเลย ก็ต้องปราชัยทุกครั้งที่มีการยุทธนั้นแล” กระนั้นก็ตามการ “รู้เรา” ก็ยังเป็นปัจจัยที่สำคัญในการรบ และการบริหารนั่นเอง สิ่งที่เราจะต้องวิเคราะห์ ก่อนที่จะเลือก Software Development Framework ที่เหมาะสม ที่สำคัญคือ Culture, Team, Technical, และ Constraints
Culture ของแต่ละองค์กรเป็นสิ่งที่สำคัญ และห้ามมองข้ามเด็ดขาด Culture นั้นจะเป็นตัวบ่งชี้ความแตกต่างระหว่างองค์กรหนึ่งๆ ส่วนสำคัญๆ ที่จะต้องดูน่าจะอยู่ที่ความพร้อมในการเปลี่ยนแปลงของทีม เช่น บางทีมคนส่วนใหญ่ทำงานใน Framework เดิมๆ มาเป็น 10 ปี จะให้มีการเปลี่ยนแปลงอย่างทันทีทันใดน่าจะลำบาก หรือ Culture ในการทำงานร่วมกันกับ Stakeholder อื่นๆ ว่ามี Involvement มากแค่ไหน
Team เป็นอีกปัจจัยที่สำคัญมากๆ ซึ่งจะต้องพิจารณาทั้ง Technical Skill ของแต่ละคน และภาพรวม ขนาดของทีม รวมถึงลักษณะการทำงานที่เฉพาะ เช่น บางองค์การมีทีมทำงานต่างสถานที่กัน หรือแม้แต่ระดับความรับผิดชอบของแต่ละคน โดยเฉพาะ Framework บางอย่างต้องอาศัย Skill และความรับผิดขอบส่วนตัวค่อนข้างสูง โดยเฉพาะ Agile, Scrum, และ XP
Technical ที่จะต้องพิจารณาที่สำคัญคือ ขนาด และความซับซ้อนของ Software ที่พัฒนาอยู่ Technology stacks ที่ใช้ รวมถึง Software architecture ที่จะส่งผลต่อการพัฒนาด้วย ถ้าเป็นเทคโนโลยีที่ใหม่กับองค์กรมากๆ อาจจะต้องใช้ Prototyping หรือ Spiral
Constraints อื่นๆ ขององค์กร โดยเฉพาะสิ่งที่เป็นลักษณะเฉพาะของธุรกิจ เช่น Compliance ต่อกฎหมาย และระเบียบต่างๆ ลักษณะการติดต่อ และทำงานร่วมกับ Partner ต่างๆ นอกจากนี้ยังจะต้องพิจารณาเรื่องปริมาณงบประมาณที่มีถ้ามีค่อนข้างน้อยอาจจะต้องใช้ Iterative and Incremental หรือ Agile ถ้าต้องเอกสารเป็นสิ่งที่จำเป็นอาจจะต้องใช้ Waterfall หรือ V-Shape
เมื่อ “รู้เรา” แล้ว ก็ศึกษาข้อดีข้อเสียของ Software Development Framework แต่ละตัว ดูข้อดี ข้อเสีย และเทียบกับสิ่งที่องค์กรของเราเป็น ส่วนนี้คงไม่ได้ลงไปในส่วน Decision Making จริงๆ มากนัก เพราะคงจะต้องคุยกันยาวหน่อย ถ้ามีโอกาสอาจจะมาคุยต่อกันในโอกาสหน้า
ทางเลือกของเรา มักจะไม่ใช่ Framework ใด Framework หนึ่งโดยเฉพาะ มักจะเป็นทางออกที่เป็น Hybrid ระหว่าง Framework ต่างๆ ขึ้นกับปัจจัยที่ได้วิเคราะห์มาก่อนหน้านี้ ซึ่งย่อมเป็นที่เข้าใจได้ว่าความแตกต่างระหว่างองค์กรต่างๆ ย่อมนำมาซึ่งความแตกต่างใน Framework การทำงานที่เหมะสมในแต่ละองค์กร เราไม่สามารถลอกความสำเร็จใน Framework ของบริษัทอื่นๆ มาใช้ได้ทั้ง 100% ต้องการการแก้ไข ดัดแปลงให้เหมาะสม
ตัวอย่างกรณีศึกษา
มีบริษัทแห่งหนึ่งในประเทศไทยดำเนินธุรกิจโดยให้บริการ Service ทางด้าน IT ให้กับลูกค้า Corporate เพื่อให้บริการต่อไปยัง End-user อีกต่อหนึ่ง บริษัทนี้เติบโตขึ้นจากการทำงานที่ไม่เป็นระบบ และไม่มี Framework ที่ชัดเจน ถ้าพูดง่ายๆ ก็ ออกจะลูกทุ่งนิดนึง ใครต้องการให้ทำอะไรก็มีคนรับงาน กึ่งๆ เป็น PM มาคุยรายละเอียดกับ Developer แล้วก็ลงมือทำ
Culture ดั้งเดิมของบริษัทเน้นที่การทำงานให้ได้ตาม Functional ที่ต้องการ ไม่ได้คำนึงถึง non-functional อื่นๆ เช่น performance, security, และ maintainability การเรียนรู้ และพร้อมในการใช้เทคโนโลยีใหม่ต่างๆ ค่อนข้างต่ำ แม้จะมีความพยายามในการพัฒนา และปรับปรุงวิธีการทำงาน และการใช้ Development Tools ต่างๆ เพิ่มเติม แต่ก็เป็นไปอย่างเชื่องช้า การทำงานร่วมกับฝั่ง Business มีการทำงานกึ่งๆ Waterfall
ในที่สุดผู้บริหาร IT ตัดสินใจ Implement Scrum ในระบบ Software Development โดยจ้างบริษัทที่ปรึกษาเข้ามาทำ Training รวมถึงให้เข้ามาร่วมทีมเป็น on-the-job training เพื่อให้ทีมเข้าใช้ Scrum อย่างเต็มตัว
ผลลัพธ์คือ การ Implement ไม่สามารถเข้าไปถึงหลายส่วนได้ Developer บางคนก็ไม่สามารถรับได้ และทยอยลาออกไป Product Owners ก็ไม่ได้เข้ามา Integrate เข้ากับ Scrum ได้ ไม่มี Product Owners หรือคนจากฝั่ง Business เข้ามา Join Scrum อย่างเต็มตัว ไม่ได้เข้ามา Join Standup Meeting ไม่มีคนที่สามารถคุยเรื่อง Requirment ได้ ทาง Developer ต้องเข้าไปคุยเรื่อง Requirements เพิ่มเติมกับ Business ในประชุมต่างหาก เป้าหมายที่ตั้งไว้ก็ไม่สามารถ Achieve ได้ในเวลาที่คาดไว้
จากนั้นบริษัทก็มีอันต้องระงับการให้บริการไป ด้วยสาเหตุและปัจจัยมากมาย สิ่งที่พอจะเรียนรู้ได้บางอย่าง คือ วัฒนธรรมองค์กร และลักษณะการทำงานของบริษัทในขณะนั้น ยังไม่เหมาะสมกับการใช้ Scrum นัก นั่นแหละครับ มันมักจะไม่มี Framework ใดที่เราสามารถลอกมาจากตำรา แล้วนำมา Implement ให้เข้ากับองค์กร ลักษณะการทำงาน และ Constraints ต่างๆ ได้ในทันที
หวังว่าบทความนี้ จะทำให้แต่ละท่านเกิดไอเดียในการพัฒนา Software Development Framework ขององค์กรต่อไป พยายามศึกษา และปรับหาวิธีการในการที่ดีขึ้นเรื่อยๆ อยากให้กำลังใจกับคนที่กำลังเสาะหาวิธีการทำงาน โดยเฉพาะ Startup ที่กำลังเติบโตนะครับ
