รักษาความสงบและเปลี่ยนไปสู่ทีมพัฒนาใหม่

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

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

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

ผ่านคบเพลิง: การเริ่มต้นทีมพัฒนาใหม่

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

แต่ถ้าคุณไม่ได้เปลี่ยนทั้งทีมล่ะ? คุณควรรบกวนการอ่านสิ่งนี้หรือไม่?

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

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

เพื่อไม่ให้เป็นการเสียเวลา ไปดำน้ำกัน!

รวบรวมเอกสาร

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

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

เอกสารที่ดีต้องครอบคลุมหัวข้อต่อไปนี้เป็นอย่างน้อย:

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

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

ก่อนการเปลี่ยนแปลงใด ๆ เกิดขึ้น ขอให้ทีมพัฒนาก่อนหน้านี้อำนวยความสะดวกในการถ่ายทอดความรู้โดยการสร้างทรัพยากรที่เกี่ยวกับหัวข้อข้างต้น!

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

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

ทำความเข้าใจผลิตภัณฑ์ของคุณ

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

คำถามต่อไปนี้เป็นเรื่องธรรมดา และคุณควรจะรู้คำตอบโดยไม่ต้องค้นหา:

• แอปพลิเคชันของคุณใช้เทคโนโลยี stack ใด? - มีเฟรมเวิร์กแอปพลิเคชันทั่วไปมากมายสำหรับแบ็คเอนด์และฟรอนต์เอนด์ และทีมพัฒนาใหม่ควรมีความคุ้นเคยในสิ่งที่แอปพลิเคชันของคุณใช้ ตัวอย่างของเทคโนโลยีเว็บแบ็คเอนด์ ได้แก่ Ruby on Rails, Node.js และ Django ตัวอย่างของเทคโนโลยีเว็บส่วนหน้า ได้แก่ React.js, Angular.js และ Ember.js
• มันเป็นเจ้าภาพที่ไหน? - โฮสต์เว็บที่ต่างกันมีกระบวนการปรับใช้ที่แตกต่างกัน ซึ่งต้องการระดับประสบการณ์ที่แตกต่างกัน ในช่วงไม่กี่ปีที่ผ่านมา เทคโนโลยีคลาวด์ได้สร้างตัวเลือกโฮสติ้งใหม่มากมาย และคุณจะต้องระบุว่าคุณกำลังใช้ตัวเลือกใดและอธิบายว่าเหตุใดจึงได้รับเลือกให้เหนือกว่าตัวเลือกอื่นๆ
• กระบวนการพัฒนาเป็นอย่างไร? - ทีมของคุณใช้เครื่องมือการจัดการการควบคุมแหล่งที่มาโดยเฉพาะ เช่น Git หรือไม่ ถ้าเป็นเช่นนั้น กระบวนการในการพัฒนา ทดสอบ อนุมัติ และปรับใช้คุณลักษณะใหม่มีขั้นตอนอย่างไร กระบวนการต้องได้รับมาตรฐาน จัดทำเอกสารอย่างถูกต้อง และง่ายต่อการทำซ้ำโดยผู้มาใหม่
• แอปพลิเคชันของคุณใช้บริการของบุคคลที่สามใดบ้าง - แอปพลิเคชันบางตัวสร้างขึ้นบนบริการของบุคคลที่สาม เช่น Shopify โปรดทราบว่าการพึ่งพาบริการของบุคคลที่สามนั้นค่อยๆ เพิ่มขึ้น และแม้ว่าคุณจะไม่ได้ใช้บริการเสริมใดๆ ในปัจจุบัน แต่โปรเจ็กต์ของคุณอาจตัดสินใจใช้บริการของบุคคลที่สามในภายหลัง
• แอปพลิเคชันของคุณสามารถทำงานบนแพลตฟอร์มใดได้บ้าง - แอปของคุณเป็นแอปพลิเคชันเดสก์ท็อป เว็บแอป เว็บไซต์มือถือที่ตอบสนอง แอปพลิเคชัน iOS ดั้งเดิม แอปพลิเคชัน Android ดั้งเดิม หรืออย่างอื่นหรือไม่ มันทำงานบนหลายแพลตฟอร์มที่แตกต่างกันหรือไม่? แพลตฟอร์มใดเป็นลำดับความสำคัญของคุณในช่วงเวลาที่กำหนด? แพลตฟอร์มใดที่ผลิตภัณฑ์ของคุณแข็งแกร่งและอ่อนแอที่สุด? อย่าลืมทราบรายละเอียดทั้งหมดของแพลตฟอร์มปัจจุบันของแอปพลิเคชันของคุณ และแม้แต่รายละเอียดที่สามารถขยายไปยังแพลตฟอร์มอื่นๆ ได้

เป็นเจ้าของ

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

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

ต่อไปนี้คือรายการเครื่องมือหรือบริการภายนอกต่างๆ ที่แอปพลิเคชันของคุณอาจใช้:

• การจัดการการควบคุมแหล่งที่มา - GitHub, Bitbucket, Gitlab
• เว็บโฮสติ้ง - Heroku, EngineYard, Digital Ocean, Bluehost, Amazon Web Services
• ไฟล์โฮสติ้ง - Amazon Web Services (S3)
• ผู้ให้บริการ DNS - GoDaddy, DNSimple, Hover
• บริการพัฒนา - NewRelic, FileStack, Segment, Bugsnag (และอื่น ๆ อีกนับไม่ถ้วน)
• บริการชำระเงิน - Stripe, Braintree, PayPal
• บริการบล็อก - WordPress, Tumblr, Ghost
• โซลูชันอีคอมเมิร์ซ - Shopify, Squarespace
• การวิเคราะห์ / การติดตาม - Google Analytics, Mixpanel, Kissmetrics
• การตลาดผ่านอีเมล: MailChimp ติดต่อคงที่

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

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

ให้สิทธิ์การเข้าถึง

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

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

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

การจัดการแฮนด์ออฟ

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

ทีมที่เข้ามา

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

ทีมขาออก

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

บทสรุป

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

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

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

มาทบทวนประเด็นสำคัญที่ควรมาก่อนการโอนกรรมสิทธิ์ผลิตภัณฑ์ซอฟต์แวร์ของคุณ:

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