Geographical Distribution (การกระจายตัวทางภูมิศาสตร์)

ทีมที่อยู่ในสถานที่เดียวกันจะพบว่าการสื่อสารแบบ synchronous เป็นเรื่องง่ายมาก โดยเฉพาะเพราะปกติแล้วพวกเขาอยู่ที่เดียวกันในเวลาเดียวกัน ถ้าทีมของคุณกระจายตัว การสื่อสารแบบ synchronous ก็อาจยากขึ้น แต่ก็ยังทำได้ถ้าสมาชิกทีมอยู่ในโซนเวลาเดียวกันหรือใกล้เคียงกัน เมื่อสื่อสารกับคนในโซนเวลาต่างๆ ต้นทุนการประสานงานอาจเพิ่มขึ้นอย่างมาก ในตำแหน่งงานก่อนหน้านี้ครั้งหนึ่ง ผมทำงานเป็นสถาปนิก ช่วยสนับสนุนทีมที่ตั้งอยู่ในอินเดีย สหราชอาณาจักร บราซิล และสหรัฐฯ ในขณะที่ตัวผมเองอยู่ในออสเตรเลีย การนัดประชุมระหว่างผมกับหัวหน้าทีมต่างๆ นั้นยากมาก นั่นหมายความว่าเราจัดประชุมเหล่านี้ไม่บ่อยนัก (ปกติจะเดือนละครั้ง) และเราต้องมั่นใจว่าจะพูดคุยเฉพาะประเด็นที่สำคัญที่สุดในเซสชันเหล่านี้เท่านั้น เพราะบ่อยครั้งที่มากกว่าครึ่งของผู้เข้าร่วมประชุมจะทำงานนอกช่วงเวลาทำงานหลักของตัวเอง

นอกเหนือจากเซสชันเหล่านี้ เราจะสื่อสารแบบ asynchronous ส่วนใหญ่ผ่านอีเมล เกี่ยวกับประเด็นอื่นๆ ที่ไม่เร่งด่วนเรื่องเวลา แต่เมื่อผมอยู่ในออสเตรเลีย ความล่าช้าในการสื่อสารรูปแบบนี้ก็มีนัยสำคัญ ผมจะตื่นนอนเช้าวันจันทร์และเริ่มต้นสัปดาห์อย่างค่อนข้างเงียบสงบ เพราะคนส่วนใหญ่ในโลกยังไม่ตื่น—นี่ทำให้ผมมีเวลาประมวลผลอีเมลที่ได้รับจากทีมในสหราชอาณาจักร บราซิล และสหรัฐฯ ในบ่ายวันศุกร์ของพวกเขา ซึ่งตรงกับเช้าวันเสาร์ของผม

ผมจำได้ถึงโปรเจกต์ลูกค้าโปรเจกต์หนึ่งที่ผมเคยทำงานด้วย ซึ่งความเป็นเจ้าของไมโครเซอร์วิสตัวเดียวถูกแบ่งปันระหว่างสองสถานที่ทางภูมิศาสตร์ ในที่สุด แต่ละไซต์ก็เริ่มเชี่ยวชาญเฉพาะงานที่ตัวเองจัดการ สิ่งนี้ทำให้แต่ละไซต์รับความเป็นเจ้าของส่วนหนึ่งของ codebase ซึ่งภายในนั้นสามารถมีต้นทุนการเปลี่ยนแปลงที่ต่ำกว่า จากนั้นทีมก็มีการสื่อสารแบบหยาบมากขึ้นเกี่ยวกับวิธีที่สองส่วนนี้เชื่อมโยงกัน อันที่จริงแล้ว เส้นทางการสื่อสารที่เป็นไปได้ภายในโครงสร้างองค์กรสอดคล้องกับ API แบบหยาบที่เป็นขอบเขตระหว่างสองส่วนของ codebase

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

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

ควรสังเกตด้วยว่า ณ จุดนี้ อย่างน้อยก็จากการสังเกตของผู้เขียนรายงาน "Exploring the Duality Between Product and Organizational Architectures" ที่ผมอ้างอิงไปก่อนหน้านี้ ถ้าองค์กรที่สร้างระบบมีความผูกพันแบบหลวมๆ มากกว่า (เช่น ประกอบด้วยทีมที่กระจายตัวทางภูมิศาสตร์) ระบบที่ถูกสร้างขึ้นก็มักจะเป็นโมดูลมากขึ้น และหวังว่าจะ coupled น้อยลงตามไปด้วย แนวโน้มที่ทีมเดียวที่เป็นเจ้าของหลายเซอร์วิสจะเอียงไปทาง integration ที่แน่นขึ้นนั้น ยากมากที่จะรักษาไว้ในองค์กรที่กระจายตัวมากขึ้น