จะสร้างการแลกเปลี่ยนความรู้ในบริษัทอย่างไรไม่ให้เจ็บมาก

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

จะสร้างการแลกเปลี่ยนความรู้ในบริษัทอย่างไรไม่ให้เจ็บมาก
ความรู้ =/= เอกสารประกอบ สิ่งนี้อธิบายไม่ได้ ก็ต้องจำไว้

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

ในตอนสุดท้ายของพอดแคสต์ “Team Lead Will Call” หนุ่มจาก Skyeng พูดคุยเกี่ยวกับการจัดการความรู้กับ Igor อาจแมว Tsubko เป็นบุคคลในคณะกรรมการโครงการ KnowledgeConf และเป็น “ผู้อำนวยการของสิ่งที่ไม่รู้จัก” ของ Flaunt

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

แฮ็กแรก: คุณไม่จำเป็นต้องรู้ว่าจะตรวจสอบระบบใดอีกต่อไป

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

จะสร้างการแลกเปลี่ยนความรู้ในบริษัทอย่างไรไม่ให้เจ็บมาก
กระดาษแผ่นเดียวที่จะค้นหานั่นคือทั้งหมด

แต่วิศวกรของ Flant ประมาณ 60% ใช้การค้นหานี้อย่างน้อย 1-2 ครั้งต่อวัน และมักจะพบคำตอบในตำแหน่งที่หนึ่งหรือสอง และในรูปแบบของการพิสูจน์แนวคิดคือการจัดทำดัชนีเอกสารของ Google: doxs, โฟลเดอร์, van drive และอื่นๆ ทั้งหมดทั้งหมดนี้สามารถขับเคลื่อนเข้าสู่การค้นหาภายในได้อย่างง่ายดาย”

แฮ็คที่สอง: วิธีที่จะไม่พลาดสิ่งสำคัญอย่างยิ่งในการแชทจำนวนมาก

“หากคุณทำงานในทีมที่กระจายตัวออกไป ส่วนสำคัญของวันของคุณอาจถูกใช้ไปใน Slack - และในกรณีนี้ คุณจะคุ้นเคยกับการทำสิ่งนี้: “@myteam, help/look/enter the right one... ”” แต่มีปัญหากับข้อมูลที่มีอยู่มากมาย - และสามารถพลาดการกล่าวถึงแยกจากข้อความอื่น ๆ ได้


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

คำถามที่ต้องตอบ: จะทำอย่างไรกับเอกสาร?

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


ส่วนหนึ่งของพอดแคสต์ที่อุทิศให้กับคำถาม “ต้องใช้คนกี่คนในการเขียนเอกสารที่ดีหรือทำการสาธิตตามปกติ”

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

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

โบนัส: “เอาล่ะ ฉันจะบอกแบบนี้ พวกเขาจะเข้าใจ”

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

จะสร้างการแลกเปลี่ยนความรู้ในบริษัทอย่างไรไม่ให้เจ็บมาก
ช่องทางแบ่งปันความรู้ระหว่างการพัฒนา รายงานภายใน หนังสือที่เป็นประโยชน์ บทความ ฯลฯ สารสกัดที่มีโครงสร้างยังถูกเก็บไว้ใน Notion

ส่วนหนึ่งปัญหาเหล่านี้สามารถแก้ไขได้ด้วยการปฏิบัติตามรายงานภายใน สัปดาห์ละครั้งจะใช้เวลา 40-60 นาทีในช่วงเวลาที่มีงานยุ่งน้อยลง และพวกเขาก็จัดทำรายงานวิดีโอสำหรับเพื่อนร่วมงานจากโครงการต่างๆ ทีมงานส่วนหน้าของผลิตภัณฑ์หลัก - Vimbox - เขาบอกว่า เกี่ยวกับชุด UI ของคุณ ซึ่งสามารถใช้เป็นธีมสำหรับโปรเจ็กต์อื่นได้ ทีมพัฒนาการตลาดพูดคุยเกี่ยวกับไลบรารีสำหรับการติดตามและบันทึกคำขอ ซึ่งดึงดูดความสนใจของโครงการอื่นๆ อีกหลายโครงการในทันที ทีมงานโครงการคณิตศาสตร์แบ่งปันประสบการณ์ในการเปลี่ยนจาก REST API เป็น GraphQL ทีมบทเรียนกลุ่มกำลังคิดที่จะแชร์ว่าพวกเขาเป็นคนแรกที่เปลี่ยนมาใช้ PHP 7.4 ได้อย่างไร และอื่นๆ

จะสร้างการแลกเปลี่ยนความรู้ในบริษัทอย่างไรไม่ให้เจ็บมากรายการนี้ได้รับการดูแลตั้งแต่เดือนพฤษภาคม 2018 และมีมากกว่า 120 รายการ

การประชุมทั้งหมดเริ่มต้นผ่าน Google Meet ขององค์กร ซึ่งบันทึกไว้และจะปรากฏในโฟลเดอร์บน Google ไดรฟ์ที่แชร์ภายใน 1.5 ชั่วโมง และลิงก์ไปยังการบันทึกจะถูกทำซ้ำใน Slack เดียวกัน นั่นคือคุณไม่จำเป็นต้องมาหากมีเหตุฉุกเฉิน แต่ดูในภายหลังด้วยความเร็ว 20 ซึ่งโดยปกติแล้วรายงานจะมีความยาวสูงสุด XNUMX นาทีและการอภิปราย - จะเป็นเช่นไร แต่เราอย่าไปเกินชั่วโมง)

PS อะไรได้ผลและไม่ได้ผลสำหรับคุณ?

ลิงค์ที่เป็นประโยชน์

ที่มา: will.com

เพิ่มความคิดเห็น