เหตุใดทีมแบบกระจายจึงมีความสำคัญ และวิธีการสร้างทีม

“สมมติว่าคุณเริ่มต้นธุรกิจโดยลำพัง และคุณต้องการพันธมิตร คุณต้องใช้เวลามากในการหาคู่หูใช่ไหม? เขาจะเป็นครึ่งหนึ่งของบริษัทคุณ ทำไมคุณควรใช้เวลาน้อยลงในการค้นหาหนึ่งในสามของบริษัทของคุณ หรือหนึ่งในสี่ของบริษัทของคุณ หรือหนึ่งในห้าของบริษัทของคุณ? เมื่อคุณอยู่ในสตาร์ทอัพ 10 คนแรกจะเป็นตัวกำหนดว่าบริษัทจะประสบความสำเร็จหรือไม่ แต่ละคนคิดเป็น 10% ของบริษัท เหตุใดคุณจึงไม่ใช้เวลามากเท่าที่จำเป็นในการค้นหาผู้เล่น A ทั้งหมด ถ้าสามคนไม่ได้ยอดเยี่ยมนัก ทำไมคุณถึงต้องการบริษัทที่พนักงานของคุณ 30% ไม่ได้ยอดเยี่ยมขนาดนั้น” - สตีฟจ็อบส์

ในปี 2003 ผู้เขียน Michael Lewis ได้ตีพิมพ์หนังสือชื่อ Moneyball: The Art of Winning an Unfair Game หนังสือเล่มนี้เป็นเรื่องราวที่ตกอับแบบคลาสสิก ทีมเบสบอลที่กำลังดิ้นรนตระหนักว่าหน่วยสอดแนมที่มีความสามารถซึ่งอาศัยภูมิปัญญาที่มีอายุหลายสิบปีกำลังขาดโอกาสในการสร้างทีมที่ชนะ ด้วยการพัฒนากลวิธีในการสอดแนมของพวกเขาเพื่อรวมเครื่องมือและแนวทางปฏิบัติที่ทันสมัย ​​ทีมระบุและจ้างรายชื่อผู้เล่นที่ประเมินต่ำเกินไป บรรลุสถิติการชนะคู่ต่อสู้ที่มีเงินเดือนสูงกว่ามาก

บทเรียนที่แท้จริงของ Moneyball นั้นชัดเจน: ไม่ว่าคุณจะเป็นบริษัทใหญ่หรือบริษัทหัวก้าวหน้าที่กำลังมองหาความได้เปรียบเหนือหน้าที่ที่ทำได้เหนือกว่าคุณ คุณก็มีโอกาสที่จะปรับกลยุทธ์ของคุณและจ้างแหล่งสำรองที่ไม่ได้ใช้ของพรสวรรค์คุณภาพสูงด้วยการตระหนักรู้ เมื่อภูมิปัญญาดั้งเดิมในการสร้างทีมไม่สะท้อนความเป็นจริงอีกต่อไป

บริษัทเล่น Moneyball โดยใช้ทีมแบบกระจาย

ในมุมมองของเรา องค์กรมีโอกาสที่จะเล่น "ลูกบอลเงิน" ในการค้นหาความสามารถที่มี ROI สูงอย่างชัดเจน: ส่งเสริมให้ทีมของคุณจ้างพนักงานที่อยู่ห่างไกล

มากกว่า 43% ของคนงานในสหรัฐฯ สื่อสารโทรคมนาคมในปีที่ผ่านมา เพิ่มขึ้นอย่างมากจาก 9% ที่พูดแบบเดียวกันในปี 2538

ในปี 2559 บริษัท TinyPulse สร้างความผูกพันกับพนักงาน ได้ทำการสำรวจพนักงานที่อยู่ห่างไกลกว่า 500 คน และพบว่าพวกเขามีความสุขมากขึ้น รู้สึกมีคุณค่ามากขึ้น และมีประสิทธิผลมากกว่าเพื่อนร่วมงานที่ทำงานนอกสถานที่อย่างท่วมท้น มากกว่า 43% ของคนงานในสหรัฐฯ ทำงานทางไกลในปีที่ผ่านมา เพิ่มขึ้นอย่างมากจาก 9% ที่พูดแบบเดียวกันในปี 2538 โดยรวมแล้ว บริษัทที่อนุญาตให้ทำงานทางไกลได้แสดงให้เห็นถึงความเครียดที่ลดลง ประสิทธิภาพมากขึ้น และอัตราการลาออกของพนักงานที่ลดลง

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

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

ความกังวลร่วมกันกับทีมงานแบบกระจาย

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

• คุณภาพ: เมื่อเกือบ 20 ปีที่แล้ว การเปิดเผยครั้งแรกกับทีมแบบกระจายเกิดขึ้นในบริบทของรูปแบบการเอาท์ซอร์สแบบดั้งเดิม ซึ่งขับเคลื่อนด้วยการประหยัดต้นทุนโดยสิ้นเชิง การทำงานร่วมกันรู้สึกเป็นไปไม่ได้: เครื่องมือที่เราใช้โดยปกติในปัจจุบันเช่น Slack หรือ GitHub ไม่มีอยู่จริง การแลกเปลี่ยนอีเมลใช้เวลาหลายวันเนื่องจากปัญหาเขตเวลา แบนด์วิดท์มีราคาแพง และด้วยเหตุผลบางอย่าง ทุกคนประหลาดใจเมื่อซอฟต์แวร์ถูกสร้างโดยราคาถูกที่สุด นักพัฒนาซอฟต์แวร์ที่เราพบว่ามีหมัด
• การมองเห็น: ผู้จัดการโครงการเกลียดความประหลาดใจ นี่คือเหตุผลที่ผู้จัดการโรงงานตรวจสอบสายการผลิตเป็นประจำ หรือหัวหน้างานก่อสร้างนั่งที่โต๊ะในรถเทรลเลอร์ที่ไซต์งาน แน่นอนว่า มีหลายกรณีที่คุณต้องการความใกล้ชิดทางกายภาพเพื่อตรวจสอบความคืบหน้าในผลิตภัณฑ์ซอฟต์แวร์หรือบริการระดับมืออาชีพ—นอกเหนือจากความใกล้ชิดกับการเชื่อมต่อ Wi-Fi ที่ดีหรือเสาสัญญาณมือถือ—แต่การแสดงตนยังคงมีความสำคัญในหมู่ผู้จัดการทั้งหมด ชนิด
• ออร์โธดอกซ์แบบ Agile: เราเห็นบริษัทหลายแห่งกำลังพิจารณาหรือดำเนินการเปลี่ยนแปลงแบบ Agile อย่างจริงจัง ในส่วนหนึ่งของการเปลี่ยนแปลงดังกล่าว พวกเขามักจะขอคำแนะนำสำหรับผู้บริหารจากหนังสือ โค้ช และบริษัทที่ปรึกษาแบบ Agile เมื่อพูดถึงการสร้างทีม ผู้เชี่ยวชาญเหล่านี้มักจะพูดในสิ่งเดียวกันว่า "ทีมของคุณควรอยู่ร่วมกัน" นี่เป็นคำแนะนำที่ดีเมื่อสิบห้าปีที่แล้ว—ในหลาย ๆ ด้าน Agile เป็นปฏิกิริยาตอบสนองต่อเงื่อนไขข้างต้นที่ทำให้การทำงานร่วมกันเป็นไปได้ยากในระยะทางไกล และทำให้การจัดการโครงการน้ำตกที่เข้มงวดเป็นสิ่งจำเป็น

ส่วนใหญ่ต้องขอบคุณเทคโนโลยีที่ได้รับการปรับปรุงสำหรับการทำงานร่วมกันและการสื่อสาร เงื่อนไขที่นำไปสู่ข้อกังวลเหล่านี้ไม่มีอยู่อีกต่อไป เมื่อใช้แนวทางปฏิบัติที่ดีที่สุด 5 ประการที่สรุปไว้ด้านล่าง องค์กรจะมีความพร้อมในการสร้างทีมแบบกระจายที่มีประสิทธิภาพสูง และเพิ่มศักยภาพในการเปลี่ยนแปลงของงานทางไกลให้ได้มากที่สุด

1. จ้างเพื่อใช้งานร่วมกันได้ระยะไกล

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

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

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

2. ในการจัดการทีมแบบกระจาย ให้สร้าง Sandbox

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

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

กล่าวอีกนัยหนึ่ง ควรมีการกำหนดกรอบงานและกระบวนการสำหรับการทำงานร่วมกันอย่างแน่นหนา แต่การพัฒนาซอฟต์แวร์เป็นศิลปะมากพอๆ กับวิทยาศาสตร์ ดังนั้นจึงเป็นเรื่องสำคัญที่พนักงานระยะไกลต้องมีละติจูดในการสร้างสรรค์ภายในแซนด์บ็อกซ์

3. ฝึกอบรมผู้จัดการเพื่อติดตามผลลัพธ์ ไม่ใช่ผลลัพธ์

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

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

4. ใช้เครื่องมือที่เหมาะสม

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

• การแชทแบบเรียลไทม์ : การแชทตามเวลา จริงเป็นเครื่องมือสำคัญสำหรับทีมที่อยู่ห่างไกล คุณต้องการทำซ้ำการโต้ตอบและการทำงานร่วมกันในทันทีที่คุณจะมีในทีมที่จัดไว้ การแชทแบบเรียลไทม์ไม่เพียงแต่จำเป็นสำหรับการสื่อสารเท่านั้น แต่ยังมีประโยชน์สำหรับการสร้างวัฒนธรรมทางไกลอีกด้วย เพื่อให้ประสบความสำเร็จ การสื่อสารในทีมทั้งหมดต้องรวมศูนย์ไว้ในที่เดียว โปรดจำไว้ว่าแซนด์บ็อกซ์จำเป็นต้องมีกำแพง ที่ Toptal เราใช้ Slack แต่ทางเลือกอื่น ได้แก่ HipChat, Flowdock และ Skype
• ผู้ให้ ข้อมูล: หากไม่มีปฏิสัมพันธ์แบบตัวต่อตัวเพื่อสังคมข้อมูล คุณจะต้องมีวิกิออนไลน์และสตอรี่วอลล์เพื่อเผยแพร่ข้อมูลไปยังทีม ในการพัฒนา Agile หรือ Kanban ทั้งทีมและผู้มีส่วนได้ส่วนเสียที่เกี่ยวข้องทั้งหมดควรมีสิทธิ์เข้าถึงข้อมูลทันทีเกี่ยวกับสถานะของการพัฒนา—เรื่องราวในเที่ยวบิน การรอการทดสอบ ข้อบกพร่อง ฯลฯ ทีมควรมีสิทธิ์เข้าถึงแดชบอร์ดสำหรับไปป์ไลน์การสร้างและ สถานะ ความครอบคลุมของรหัส และข้อมูลสำคัญอื่นๆ ในฐานะผู้จัดการระยะไกล คุณต้องการแหล่งข้อมูลความจริงแหล่งเดียวสำหรับข้อมูลแต่ละด้านที่ทีมและผู้มีส่วนได้ส่วนเสียใช้สำหรับสถานะ
• การประชุมทางวิดีโอ: วิดีโอแชทแบบเรียลไทม์เป็นส่วนเสริมที่จำเป็นสำหรับการส่งข้อความโต้ตอบแบบทันที จากประสบการณ์ของเรา ไม่มีอะไรที่เหมือนกับการพูดคุยกับคนอื่นจริงๆ ที่ Toptal เราใช้ Zoom, Slack call และ Skype แบบตัวต่อตัว, การประชุมสถานะและการแสดงรหัสเป็นครั้งคราว การต่อสู้เพื่อแย่งชิงรายวันผ่านการประชุมทางวิดีโอเป็นวิธีที่ยอดเยี่ยมในการสร้างวัฒนธรรมของทีมและความไว้วางใจ

5. พิธีโอบกอด

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

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

บทสรุป: คุณอาจพึ่งทีมกระจายอยู่แล้ว

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

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

ไม่ว่าคุณจะติดตามผู้นำของโลกโอเพ่นซอร์สหรือรับคำแนะนำจาก Michael Lewis เพื่อเล่น "moneyball" ในโลกที่ขับเคลื่อนด้วยพรสวรรค์ของการพัฒนาซอฟต์แวร์และบริการระดับมืออาชีพ ให้พิจารณาข้อจำกัดที่คุณกำหนดในองค์กรของคุณโดยยืนยันว่าพวกเขา สามารถจ้างจากแหล่งรวมความสามารถในท้องถิ่นเท่านั้น

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