"Best Practice" (อาจจะ)ไม่มีจริง

ในโลกของ Software/Technology เราจะเห็นว่าในทุกภาษา เครื่องมือ frameworks ที่เราใช้กัน มักมีบทความหรือการบอกเล่าว่า Best Practice ของการใช้งานสิ่งนี้คืออะไร เช่น คุณต้องทำแบบนี้ ต้องทำแบบนั้น ถึงจะดีที่สุด

จุดที่น่าสนใจคือ คนที่เขียนบทความหรือคนที่พูดถึง Best practice เหล่านั้น เค้าเป็นใครและมาจากไหน? ทำงานแบบไหน? ทำไมเค้าถึงบอกว่า "มันดีที่สุด"

วันนี้ผมจะชวนทุกคน มาตั้งคำถามกับ Best Practice กันครับ

🔗ผัดกะเพราที่ดีที่สุด

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

แต่ผมเชื่อว่ามีอีกหลายคนที่ชอบการใส่หัวหอมใหญ่ลงไปผัดด้วย (อย่างน้อยก็ตัวผม) และอีกหลายคนชอบข้าวโพดเบิร์นของกะเพราจากร้าน Easy Buddy

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

ผมเชื่อว่าการทำ Software ก็เช่นกัน

ฉะนั้น ผมเองจึงมองว่า "Best Practice" มันอาจจะไม่มีจริงในโลกนี้ แต่มันจะเป็น "Best for period of time", "Best for this context and situation" ซะมากกว่า

ถึงจะบอกแบบนั้น ผมก็ไม่ได้หมายความว่า Best practice จะไม่มีประโยชน์เอาซะเลย จากบทความของ Megan Louw เค้ากล่าวเอาไว้ว่า "หากเค้าต้องผ่าตัดหัวใจ เค้าขอหมอเลือกผ่าตัดกับหมอที่ปฏิบัติตาม Best Practice ดีกว่า"

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

🔗เข้าใจ Best Practice และมองหาสิ่งที่ดีกว่าไปพร้อม ๆ กัน

วันนี้ผมจะชวนทุกคนมาคุยทั้งหมด 3 เรื่อง

ทำความเข้าใจ Best Practice
มองหา Better Practice
ThoughtWorks เรามีสิ่งที่เรียกว่า Best Practice หรือเปล่า แล้วเราทำมันอย่างไร?

งั้นเรามาเริ่มที่ข้อแรกกันเลยครับ

🔗ทำความเข้าใจกับ Best Practice

"A best practice is a method or technique that has been generally accepted as superior to any alternatives, because it produces results that are superior to those achieved by other means or because it has become a standard way of doing things."

— Lv Yi, Odd-e (Experiments are at the heart of LeSS)

แปลเป็นไทยง่าย ๆ ว่า "มันคือวิธีการหรือเทคนิคที่ถูกยอมรับโดยทั่วกันว่าดีที่สุดกว่าทุกตัวเลือกที่มี"

ถ้าหากมองดูดี ๆ แล้ว ทุกวิธีนั้นจะเริ่มจาก "ปัญหา" และก่อนการนำมาใช้เราควรเข้าใจเป็นอันดับแรกว่า "เรากำลังจะแก้ปัญหาอะไรอยู่" ยกตัวอย่างเช่น Save cost, Save time, Reduce communication overhead หรือ Mitigate Risk เป็นต้น

เมื่อเราเข้าใจปัญหาแล้วจึงมามองบริบท (Context) รอบข้าง ว่ามีอะไรบ้างที่เราควรพิจารณาก่อนนำเทคนิคมาใช้

ผมขอยกตัวอย่างบริบทที่สำคัญ เช่น

เวลา: เวลาที่ต้องใช้ในการทำ, Deadline ที่ต้องแก้ปัญหา, เวลาที่ต้องใช้นั้นคุ้มค่าหรือไม่เมื่อเทียบกับวิธีอื่น ๆ
ทักษะของคนในทีม: การนำเทคนิคต่าง ๆ มาใช้นั้น ทุกคนในทีมควรเข้าใจว่าเรากำลังแก้ปัญหาอะไร และแก้มันด้วยวิธีไหน สำหรับผมแล้วน้อยที่สุดหากเกิดเหตุการณ์ที่ไม่เป็นตามแผน ทุกคนในทีมจะต้องสามารถกระโดดเข้าไปแก้ปัญหาได้
Stakeholder ที่เกี่ยวข้อง: เราจำเป็นต้องรู้ว่าใครบ้างที่จะกระทบเมื่อเรานำเทคนิคนี้มาใช้
ความซับซ้อนของเทคนิค: ยิ่งซับซ้อน อาจจะยิ่งเรียนรู้ได้ยาก เช่น หากวันหนึ่งต้องเพิ่มสมาชิกในทีม เทคนิคนี้จะทำให้เรา onboard สมาชิกคนใหม่ยากขึ้นหรือเปล่า แล้วเราจะแก้ปัญหาอย่างไร
มาตรฐานของทีมหรือองค์กร: บางเทคนิคจำเป็นต้องอิงกับ Security Operation, Security Policy หรือมาตรฐานในมุมต่าง ๆ เป็นต้น
ผลกระทบในระยะสั้น: ถ้าต้องเริ่มนำเทคนิคมาใช้ในวันนี้หรืออาทิตย์นี้ กระทบกับอะไรบ้าง เช่น งานที่อยู่ใน backlog, ทีมที่เกี่ยวข้อง, งานของทีมอื่น
ผลกระทบในระยะยาว: หากเริ่มใช้งานเทคนิคนี้แล้ว โอกาศที่เทคนิคนี้จะสร้างปัญหาใหม่ขึ้นมาเป็นอย่างไรบ้าง

บริบทเบื้องต้นเหล่านี้ควรเป็นสิ่งที่นำมาคิดทุกครั้งเมื่อเรานำเทคนิคต่าง ๆ มาใช้ในการทำงาน เพื่อให้แน่ใจว่าสิ่งที่เรียกว่า เทคนิคที่ดีที่สุด (Best Practice) เหล่านั้นเหมาะสมกับเราหรือเปล่า

🔗มองหา Better Practice

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

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

มีหลายวิธีที่ทำให้เรารู้ตัวได้เร็ว ผมขอยกตัวอย่างง่าย ๆ ซัก 3 วิธี

ตั้งคำถามกับสิ่งที่ทำอยู่: มองหาสิ่งที่ทำอยู่แล้วเรารู้สึกว่ามันดีได้กว่านี้โดยไม่สนใจว่าใครจะบอกว่ามันคือ Best Practice ลองถามว่าเทคนิคนี้มันช่วยอะไร และถ่วงเราในมุมไหน มองหา Trade-off ของมันว่าจริง ๆ แล้วมันเหมาะสมกับบริบทของเราอยู่หรือเปล่า
เก็บ feedback จากคนในทีม: หลายไอเดียมักมาจากคนที่เราไม่คาดคิด ผมเชื่อว่าทุกคนย่อมมีไอเดียที่อยากให้สิ่งที่ตัวเองทำอยู่มันง่ายและสบายมากขึ้น เพราะทุกคนขี้เกียจทำอะไรที่จำเจ
ลองทำงานกับคนจากต่างทีม: ในทีมหรือฝ่ายอื่น ๆ มักจะมีมุมมองที่ต่างจากเราโดยสิ้นเชิง (เช่น บางคนไม่รู้ว่าเขียนโค้ดทำยังไง) และเมื่อนั้น เค้ามักจะมาพร้อมกับวิธีการแก้ปัญหาที่หลุดจากกรอบของเราโดยสิ้นเชิงเช่นกัน

จากวิธีด้านบน ผมเชื่อว่าทุกคนจะได้สิ่งที่คล้ายว่าจะเป็น Better Practice มาหลายอันเลย จงอย่าลืมกลับไปมองข้อ 1 ใหม่อีกครั้ง เพื่อให้แน่ใจว่าสิ่งนี้มันเหมาะสมกับบริบทและปัญหาของเราหรือเปล่า

สำคัญมากที่สุด จงทดลองใช้ Better Practice เหล่านี้และให้ feedback กันอย่างใกล้ชิดเพื่อให้แน่ใจว่าเรามาทางถูกทางจริง ๆ

ถ้ามันไม่ได้ผลก็แค่กลับมาวิธีเดิม อย่างน้อยเรียนรู้ว่าสิ่งนี้มันยังไม่เหมาะกับสถานการณ์ตอนนี้นะ แต่ถ้ามันได้ผลเราจะได้ Practice ใหม่มาปรับใช้นั่นเอง

และไม่ว่าผลลัพธ์จะเป็นทางไหน เราและทีมก็ได้เรียนรู้และเติบโตเรียบร้อยแล้ว

🔗ThoughtWorks มีสิ่งที่เรียกว่า Best Practice หรือเปล่า

เท่าที่ผมรู้ ที่นี่เราไม่มีสิ่งที่เรียกว่า Best Practice ตรง ๆ ขนาดนั้น เราเรียกมันว่า "Sensible Defaults" หรือแปลเป็นไทยว่า "ค่าเริ่มต้นที่สมเหตุสมผล"

my colleagues are partial to the term "sensible defaults"
— Martin Fowler (@martinfowler) May 15, 2020

ตัวมันไม่ได้บอกว่าเป็น Best Practice ที่ต้องทำตามแบบนี้เท่านั้น แต่กลับกัน ตัวมันบอกว่านี่เป็น Practice เริ่มต้นที่สมเหตุสมผลนั่นเอง โดยมีคำนิยามแปะไว้ว่า คืออะไร? เพื่ออะไร? ทำอย่างไร? เป็นต้น

ซึ่ง Sensible Defaults จะเป็นมุมไหนก็ได้ ทั้ง Software Engineering Sensible Defaults, Project Management Sensible Defaults, Product Stretegy Sensible Defaults จะเป็นอะไรก็ได้ทั้งหมด

สำหรับตัวผม ผมคิดว่ามันคือ Guideline คร่าว ๆ ที่ส่วนใหญ่ตัวผมจะหยิบมาพิจารณาใน 2 เหตุการณ์

ช่วงเริ่มต้นของงาน หากเราไม่รู้ว่าต้องเริ่มต้นยังไงดี เราจะไปดู Sensible Defaults ว่ามีอะไรที่เราทำได้บ้าง
ช่วงที่เริ่มทำงานไปแล้ว ถ้าอยากมองหาว่าเราพัฒนาตรงไหนได้บ้าง เราจะกลับมาดูที่ Sensible Defaults ว่าจุดไหนที่เราลืมนึกถึงไปบ้างหรือเปล่า มีจุดไหนที่เราพัฒนาต่อยอดได้อีกนะ

และที่สำคัญที่สุดคือหมั่นให้ feedback สิ่งเหล่านี้ตลอดเวลา เพราะ Sensible Defaults ไม่ใช่สิ่งที่ต้องใช้ตลอดไป มันมีเพื่อแค่ให้เราใช้ในตอนเริ่มต้นอะไรบางอย่าง เมื่อเราเห็นว่าสิ่งนี้เหมาะจบเก็บมันไว้ เมื่อเราเห็นว่ามันขาดจงเติมเข้ามา และเมื่อเราเห็นว่ามันไม่มีประโยชน์ก็แค่นำออกไป เพื่อให้มันเหมาะสมกับการทำงานของเราปัจจุบันนั่นเอง

ยกตัวอย่างให้เห็นภาพ เช่น สมมุติเรานำ Ceremony ของ Scrum มาใช้ทั้งหมดก่อน ทุกการทำงานใน Iteration/Sprint เราจะเริ่มเห็นและเข้าใจว่า Ceremony ที่เราหยิบยกมานั้น มันเหมาะหรือไม่เหมาะกับทีมการทำงานเราอย่างไร และหลังจากนั้นเราจะค่อย ๆ ปรับให้ Ceremony ต่าง ๆ เป็นไปตามจังหวะของทีมเรานั่นเอง หรือเราอาจจะเพิ่มบาง Ceremony จากเทคนิควิธีอื่น ๆ เพื่อให้เราทำงานได้ดีขึ้นก็ได้ อยู่ที่ความเหมาะสมนั่นเอง

We have many methods which applied Agile But these methods are a starting point. If what you do never changes, you are doing agile wrong

🔗เริ่มต้นอย่างไร

อย่างที่ผมกล่าวไว้ในข้อหัวด้านบน ถ้าหากเราไม่มี Best Practice มาก่อน ผมแนะนำว่าเมื่อเกิดปัญหาหรืออยากพัฒนาอะไรบางอย่าง ลองมองดูว่าจากปัญหาเหล่านี้เราจะแก้ไขมันอย่างไรได้บ้าง ลองเริ่มหยิบ Best Practice ที่มีอยู่มาศึกษา ลองนำไปปรับใช้และหมั่นให้ feedback อยู่สม่ำเสมอ

แล้วถ้าหากเรามีสิ่งที่เรียกว่า Best Practice อยู่ในทีมหรือองค์กรแล้วล่ะก็ ผมแนะนำให้ตั้งคำถามกับมันดู ลองสอบถามคนในทีมของเรา ลองให้ feedback กับวิธีการเหล่านั้น ว่าเป็นอย่างไร มีจุดไหนบ้างที่ดีขึ้นได้ และค่อย ๆ เริ่มปรับให้มันเข้ากับบริบทปัจจุบันของเรานั่นเอง

ทั้งหมดที่กล่าวมา ผมไม่ได้ต้องการจะกล่าวร้ายให้กับ Best Practice ใดๆ บนโลก ทุก ๆ อย่างในโลกล้วนมี Trade-off ที่เมื่อเราได้สิ่งหนึ่งมา เราอาจจะต้องเสียบางอย่างไป ผมเพียงแต่อยากให้ทุกคนลองตั้งคำถามกับการนำ Best Practice เหล่านั้นมาใช้ ว่าแท้จริงแล้วมันเป็นสิ่งที่เหมาะสมกับตัวงาน กับทีมหรือองค์กรของเรา ณ ตอนนี้หรือเปล่า

ย้อนกลับไปที่ผู้อ่านทุกคน ตอนนี้เราใช้ Best Practice อย่างเหมาะสมแล้วหรือยัง?