3 สิ่งที่ทีมสามารถพัฒนาการทำงานได้โดยที่ไม่ต้องออกแรงเยอะ

Photo by Jungwoo Hong on Unsplash

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

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

Ubiquitous language

การทำงานร่วมกัน (collaboration) ระหว่างฝั่ง business และ technical ที่ไม่ราบรื่น มีสาเหตุมาจากหลาย ๆ อย่าง หนึ่งในนั้นคือ

Poor communication among customers, developers, users and project managers

ตัวอย่างเช่น business ใช้คำว่า Promotion ในการสื่อสาร ในขณะที่ทีมพัฒนาใช้คำว่า Discount ทำให้เวลาทีมพัฒนาทำความเข้าใจ context หรือให้ feedback เพื่อทำการปรับปรุง requirement ให้เกิดประโยชน์กับผู้ใช้งานเป็นไปได้อย่างไม่ราบรื่น ทีมพัฒนาจะต้องแปล Promotion เป็นคำว่า Discount ทั้งตอน

• ตอน requirement analysis
• ตอนทำการทดสอบ
• ตอนเขียน code ตั้งชื่อ class ชื่อ method!

จากประสบการณ์ของเรา นี่เป็นสิ่งหลายคนมองข้ามไปว่ามันสร้างความปวดหัวมากขนาดไหน แต่กลับกลายเป็นว่ามันก็เป็นเรื่องปกติ

จึงเกิดแนวคิด Domain-driven design (DDD) โดยมีเป้าหมายคือทำให้ความรู้ความเข้าใจในระบบ (business domain) เป็นไปตามสิ่งที่ผู้เชี่ยวชาญ (domain expert หรือ subject-matter expert) ได้บอกกล่าว หนึ่งในนั้นคือการใช้ภาษาเดียวกัน (ubiquitous language) ส่งผลให้

• ลดเวลาการทำความเข้าใจ context และแปลภาษาไป ๆ มา ๆ
• การดูแลรักษาง่ายขึ้น เพราะ business และ technical ใช้ภาษาเดียวกัน สามารถต่อยอดตาม requirement ได้ง่าย
• ลดอาการปวดหัวสำหรับคนที่เข้าทีมมาใหม่ เมื่อต้องเข้ามาพัฒนาต่อยอดจากคนเดิมที่ทำไว้

แนวคิดนี้ไม่ได้จำกัดแค่บทบาทของ developer แต่รวมถึง business analyst, quality analyst หรือแม้กระทั่ง experience designer สั้น ๆ ก็คือ “ทุกคน” นั่นแหละ

Pair development (not only coding)

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

• การดูแลรักษา ซ่อมบำรุงระบบให้ทำงานได้ตามที่ตกลงกับลูกค้าไว้
• การเขียนเอกสาร คู่มือการใช้งานต่าง ๆ
• การทำ requirement analysis กับเพื่อนตำแหน่งอื่น ๆ ในทีม
• การออกแบบ ดูแล architecture ของระบบ

สิ่งเหล่านี้ย่อมต้องใช้ความรู้และพื้นฐานที่ไม่ต่างจาก programming เลย ดังนั้นงานต่าง ๆ เหล่านี้ก็ควรจะทำในลักษณะ pair เหมือนกัน หรือเราเรียกว่า pair development ที่มากกว่า pair programming นั่นเอง

Pair development != Pair programming

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

Documentation as a definition-of-done

หนึ่งในปัญหาสุด classic ของทีมพัฒนาเมื่อมีคนเข้ามาใหม่คือ เอกสารไม่ดี นั่นหมายถึง

• เอกสารมีข้อมูลไม่เพียงพอต่อการทำงาน/เรียนรู้
• เอกสารไม่ update ตรงตามระบบจริง
• เอกสารอยู่กระจัดกระจาย หายาก ใช้งานยาก

สุดท้ายแล้วเมื่อถึงเวลาที่จะต้องใช้งาน ก็ใช้ไม่ได้ กลายเป็นของไร้ค่า ลงเอยด้วยการต้องมา update documentation ซึ่งกินเวลาเยอะมาก ส่งผลต่อสุขภาพจิตของทีมพัฒนา

น่าจะดีกว่าหากเรานำเรื่องของ documentation เข้ามาเป็นหนึ่งในสิ่งที่จะบอกว่างานนี้เสร็จหรือไม่ (definition of done) ประโยชน์ที่จะได้รับคือ documentation มีความน่าเชื่อถือ มีการปรับเปลี่ยนเมื่อมีการเปลี่ยนแปลง ในขณะเดียวกัน effort ที่ใช้ก็ไม่มาก ขึ้นอยู่กับขนาดของการเปลี่ยนแปลงนั่นเอง และจะน้อยลงไปอีกหากทีมเรามีแนวคิดเรื่อง Continuous delivery หรือ Continuous deployment

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

วิธีแก้ก็คือ เลือกคัดดูว่าอันไหนที่ไม่ใช้แล้ว หรือมีซ้ำกัน ก็ลบทิ้งไป หรือจัดเก็บไว้ใน archived เป็นที่ ๆ ไป ส่วนไหนที่ต้อง update นำมาจัดกลุ่มเสียใหม่ สำหรับใครที่คิดไม่ออก เราขอแนะนำ technique ชื่อว่า Documentation quadrants จากนั้นค่อย ๆ ปรับปรุงเนื้อหาและตัดลดจำนวนของ documentation ลงไปให้เรียบง่ายขึ้น เช่น ลบ documentation ที่สุดท้ายอ่านจาก code เอาก็ได้ (สิงที่น่าสนใจคือ code ของเรามันดีพอที่จะอ่านรู้เรื่องไหมนะ)

จากแนวทาง 3 ข้อที่ยกมานั้น จะเห็นว่าเราไม่จำเป็นต้อง “เริ่ม” ทำการปรับปรุงโดยใช้ effort มากมาย ขอแค่ให้เราปรับปรุงทีละเล็ก ๆ น้อย ๆ อย่างสม่ำเสมอ ถ้าเราอดทนพอ สุดท้ายแล้วเราจะเห็นผลที่ดีขึ้นอย่างแน่นอนครับ