How Engineering Teams Use Guru

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

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

การตั้งค่าและการฝึกอบรมเบื้องต้น

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

สำหรับทีมวิศวกรรมหลายทีม กระบวนการฝึกอบรมกลายเป็นงานที่ยากลำบากสำหรับเพื่อนร่วมงานคนอื่น ที่ถูกกำหนดให้เป็น "Buddy" ของพนักงานใหม่และต้องพาพวกเขาไปดูข้อมูลนี้แบบเรียลไทม์. แต่การให้ทีมมี การ์ดที่ได้รับการตรวจสอบโดยผู้เชี่ยวชาญและมีข้อมูลล่าสุดใน Guru ผู้นำทางวิศวกรรมของ RS21 มอบความยืดหยุ่นในการทำงานในกระบวนการฝึกอบรมตามจังหวะของตนเอง. นี่ทำให้พวกเขาประหยัดเวลาที่จะใช้กับ "Buddy" ในการสร้างความสัมพันธ์ระหว่างกันมากขึ้นหรือตอบคำถามที่ outstanding.

เมื่อวิศวกรใหม่เข้าร่วมทีม RS21 พวกเขาลงชื่อเข้าใช้ Guru เพื่อเริ่มต้นทำงานกับ เอกสารการฝึกอบรมของพวกเขา. พวกเขาจะดูผ่านบอร์ด "ข้อมูลทีม" ที่พวกเขาสามารถทำความรู้จักกับเพื่อนร่วมงานได้บ้าง ใช้การ์ดโครงสร้างพื้นฐานเพื่อทำให้สภาพแวดล้อมของพวกเขาตั้งค่าอย่างถูกต้อง และอ่านผ่านมาตรฐานการเขียนโค้ดของทีมเพื่อเข้าใจการทำงานร่วมกันกับเพื่อนใหม่อย่างดีที่สุด.

ในทำนองเดียวกันที่ Guru เมื่อวิศวกรเข้าร่วมหรือลงไปยังทีมใหม่ การฝึกอบรมของพวกเขาจะทำใน Guru. พวกเขาจะใช้ การ์ดเรื่องราวในชีวิต เพื่อรู้จักเพื่อนร่วมงาน ดูคู่มือเกี่ยวกับ วิธีที่พวกเขาควรทำงานร่วมกัน และเรียกดูคอลเลคชั่นของทีมใหม่ใน Guru เพื่อทำความคุ้นเคยกับฟีเจอร์และพื้นที่ที่พวกเขาตอนนี้รับผิดชอบ.

แนวปฏิบัติที่ดีที่สุดและมาตรฐานของทีม

เมื่อทีมทั้งหมดได้รับการฝึกอบรม เอกสารทรัพยากรที่สร้างแล้ว เช่น มาตรฐานการเขียนโค้ดและแนวปฏิบัติที่ดีที่สุดในการจัดทำเอกสาร มีที่อยู่ใน Guru. เมื่อถูกบันทึกในลักษณะที่เข้าถึงได้ในกระบวนการทำงานของพวกเขา ทำให้วิศวกรสามารถ ทำงานร่วมกันอย่างกะทัดรัด กับส่วนที่เหลือของทีมและส่วนที่เหลือของบริษัทได้ง่ายขึ้น. นอกจากนี้ยังช่วยป้องกันไม่ให้พวกเขาต้องจดจำกฎระเบียบหรือขั้นตอนการทำงานหรือแย่กว่านั้นคือต้องบุ๊กมาร์กและพึ่งพาเอกสารที่ล้าสมัย.

คอลเลคชันวิศวกรรมของ RS21 ใน Guru รวมถึงบอร์ดที่เฉพาะเจาะจงสำหรับแนวทางการแปรรูป รวมถึงการ์ดที่มีคำแนะนำสำหรับการรวมโค้ด การสร้างสคริปต์แบช การขอรีวิวโค้ด และอื่น ๆ. พวกเขายังมีบอร์ดที่เฉพาะเจาะจงสำหรับสไตล์ซินแทกซ์ที่ตกลงกันของทีม คำแนะนำในการตั้งค่า AWS ข้อมูลผู้ดูแลระบบ และอื่น ๆ. พวกเขายังมีโค้ดสคริปต์ที่ใช้บ่อยอย่างง่ายสำหรับการคัดลอกและวางในการ์ด Guru.

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

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

การวางแผนโปรเจกต์และเอกสารการพัฒนา

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

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

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

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

เอกสารที่มีความพร้อมสำหรับอนาคต

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