Contract and Collaboration

ในที่ประชุมของทีม Architect เราก็จะมีปัญหามาปรึกษากัน

หัวข้อวันนี้คุยกันว่าทีม front-end กับ back-end ไม่ยอมคุยกัน ทำให้เวลาเกิดปัญหา ก็ปัดกันไปมา แล้วก็ปรึกษากันถึงวิธีการแก้ไข

สรุปประเด็นได้ 2 วิธีหลักๆ คือ contract กับ collaboration

Contract คือการให้ back-end มี deliverable ที่ชัดเจน เช่น มี Postman Script แสดงขั้นตอนของการทำ function ต่างๆ ตัว Postman Script ถือเป็นสิ่งส่งมอบของ back-end เช่นเดียวกับ UI ที่ทีม front-end ส่งมอบให้ลูกค้า การต่อรองก็จะอยู่บนสิ่งที่ส่งมอบ

อีกวิธีคือ collaboration วิธีนี้พยายามเอาเส้นแบ่งออก เวลาเกิดปัญหาก็ถือเป็นปัญหาของทุกคน ตัวอย่างที่สำเร็จคือ มีทีมที่ส่ง back-end มาทำงานประกบกับ front-end เป็นคู่ๆ เพื่อแก้ปัญหาเดียวกัน เมื่อทำงานด้วยกัน feedback loop ก็จะรวดเร็วขึ้น API ของ back-end ก็จะถูกออกแบบมาเพื่อให้ใช้กับ front-end ได้ง่ายขึ้น ในขณะเดียวกัน front-end ก็จะเข้าใจข้อจำกัดของ back-end และอาจจะปรับ UI บางอย่างให้ back-end ทำงานได้ง่ายขึ้น

อย่างไรก็ตาม ทั้ง contract และ collaboration ก็มีกับดัก

สำหรับ contract สิ่งที่ส่งมอบควรจะเป็น working solution คือเอาไปใช้ประโยชน์ได้ เช่น Postman Script ซึ่งถือเป็นทั้งตัวอย่าง และไว้สำหรับทดสอบในคราวเดียวกัน แต่ถ้าสิ่งที่ส่งมอบเป็นเอกสารส่วนใหญ่มักไม่มีประโยชน์ เช่น งานของ Business Analyst ถ้าสิ่งที่ส่งมอบเป็น requirement spec ซึ่งในแง่ของ agile จะถือว่าเอกสารเป็นสิ่งที่ค่อนข้างสิ้นเปลือง และไม่ยืดหยุ่น หากเราตัด contract ออกไป ให้ requirement ใส่หัวข้อได้แค่ post-it แผ่นเดียว และเกิดการสื่อสารกัน ยิ่งเป็นการสร้าง collaboration ให้ดียิ่งขึ้น

ส่วน collaboration ทุกฝ่ายควรมีอะไรเสนอเพื่อประโยชน์ในการแก้ปัญหา หากมีแต่ฝ่ายเดียวได้ประโยชน์ ระบบของ collaboration ก็จะอยู่ได้ไม่นาน เช่น การทำงานกับลูกค้าในโครงการที่เป็น fixed scope/fixed budget เวลาที่คนในทีมไปทำงานกับลูกค้ามักจะเกิด commitment ต่างๆ ได้โดยง่าย ซึ่งบางครั้งอาจจะยากในการปฏิเสธ scope ออกไปหลังจากเกิด commitment แล้ว

ดังนั้นวิธี contract และ collaboration มักจะขึ้นอยู่กับสถานการณ์ และในกรณีของ front-end และ back-end เราอาจจะสร้างทั้ง contract และ collaboration ก็เป็นไปได้