วิธีที่ดีกว่าในการฝึกอบรมพนักงานใหม่ [ปิด]

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

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

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

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

ฉันจะเขียนเอกสารอย่างรวดเร็วเพื่อรับการจ้างงานใหม่ล่าสุดได้อย่างรวดเร็วที่สุดโดยไม่ต้องเสียเวลาในการเขียนเอกสารหรือไม่

ข้อมูลเพิ่มเติม:
ขณะนี้เรามีทั้งวิกิและเอกสารการฝึกอบรมบางอย่างอย่างไรก็ตามทั้งคู่นั้นค่อนข้างกระจัดกระจาย

คำถามที่ดี. การฝึกอบรมโปรแกรมเมอร์ในที่ทำงานนั้นไม่ค่อยได้รับความสนใจและไม่ได้พูดถึงบ่อยนัก

แนวคิดบางอย่างที่ฉันเห็นทำงานได้ดี:

• ในวิกิของคุณมีเอกสารการเช่าใหม่ (เอกสารที่คุณกำลังเขียน) ในเอกสารนั้นให้อธิบายถึงงานที่การจ้างใหม่จะดำเนินการใน 1-2 สัปดาห์แรก ที่ทำงานของฉันมีอะไรให้รู้มากมายตั้งแต่ go-go ตั้งแต่ซอฟต์แวร์ / เครื่องมือภายในไปจนถึงกระบวนการจนถึงตำแหน่งของข้อมูลบางประเภท แก้ไข> เรามีคำแนะนำเช่น "ติดตั้ง x, y, z ตามลำดับ" พร้อมภาพหน้าจอสำหรับการกำหนดค่าเป็นต้นดังนั้นการกำหนดค่าระบบหรือฟาร์ม (VMs) ด้วย Win Server, SQL Server, SharePoint, BizTalk ซอฟต์แวร์ของเราไม่ง่ายอย่างที่คิด เสียง สิ่งนี้มีไว้สำหรับแอปพลิเคชันอื่น ๆ ที่เรารองรับ
• ปัญหาการปฏิบัติ ฉันอยู่ที่ไหนเรามีผลิตภัณฑ์ที่เปิดเผย API ขนาดใหญ่ ดังนั้นจึงเป็นประโยชน์สำหรับเราที่จะอ่านเอกสารประกอบผลิตภัณฑ์ของเราเพื่อเขียน (กำหนดล่วงหน้า) ส่วนขยายเช่นเดียวกับที่ลูกค้า / ลูกค้าของเราต้องการ ดังนั้นหากคุณมีห้องสมุดคณิตศาสตร์เป็นส่วนหนึ่งของ API ผลิตภัณฑ์ของคุณมีปัญหาการปฏิบัติที่ "เขียนเครื่องคิดเลขโดยใช้ API ของเรา" หรืออะไรทำนองนั้น
• พี่เลี้ยงเป็นสิ่งที่ดี เก็บไว้ เราทำสิ่งนี้ด้วยเช่นกันและไม่เพียง แต่เป็นวิธีที่ดีในการพบปะผู้คน / ทำความรู้จักกับเพื่อน แต่พวกเขายังประเมินค่าไม่ได้ว่าเป็นแหล่งเรียนรู้ ฉันขอแนะนำไม่ให้เป็นคนล่าสุดที่จะจบการฝึกอบรมเนื่องจากพวกเขาไม่มีประวัติความรู้ขององค์กรที่บุคคลอื่นอาจทำได้ ให้ทุกคนลงมือหมุน
• เราทำการนำเสนอ / พูดคุยเกี่ยวกับเทคโนโลยีทุกสัปดาห์ ให้พนักงานใหม่รับของบางอย่างจากผลิตภัณฑ์ของคุณ (หรือมอบหมายให้มัน) และทำการนำเสนอหลังจากสัปดาห์ที่ 3 ตรวจสอบให้แน่ใจว่าพวกเขารู้ว่ามีที่ว่างสำหรับพวกเขาผิดและทีมสามารถแก้ไขได้หากพวกเขาทำอะไรผิดพลาดในการนำเสนอ
• ให้การว่าจ้างใหม่ทำงานกับเอกสารเมื่อพวกเขาเริ่มต้น มันบังคับให้พวกเขาอ่านมัน

ดังที่ Dan McGrath ตั้งข้อสังเกตมันเป็นความคิดที่ดีที่จะสนับสนุนให้มีการจ้างงานใหม่เพื่อปรับปรุงวิกิสำหรับพวกเขาเช่นกัน

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

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

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

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

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

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

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

• ผู้จัดการโครงการ (โจ) มอบหมายงานให้คุณในจิรา
• ตั้งเวลาเสร็จสิ้นโดยประมาณของงานตามสูตร x
• ตั้งค่าตั๋วเป็น 'กำลังดำเนินการ' เมื่อคุณเริ่มทำงานกับมัน
• สร้างสาขาจากคอมไพล์คลิกลิงค์เพื่อดูวิดีโอ 30 วินาทีในความคืบหน้านี้
• เขียนการทดสอบหน่วยตามข้อ จำกัด ในเอกสารการออกแบบดูหน้า y สำหรับข้อตกลงการตั้งชื่อการทดสอบหน่วย
• ตั้งค่าตั๋วเพื่อตรวจสอบและส่งรหัสเพื่อตรวจสอบระบบ .. 'ฯลฯ

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

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

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

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

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

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

ถ้าฉันมีเวลามากขึ้นฉันจะเขียนน้อยลง

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

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

ไม่ต้องพูดถึงว่าการฝึกอบรมที่ดีไม่ จำกัด เฉพาะเอกสารที่เป็นลายลักษณ์อักษร แต่จะรวมถึงแหล่งเรียนรู้แบบเต็มรูปแบบเช่นแหล่งเรียนรู้ออนไลน์ห้องเรียนมัลติมีเดียเป็นต้น

ตามที่พวกเขาพูด "ถ้าคุณคิดว่าการศึกษานั้นมีราคาแพงให้ลองใช้ความไม่รู้"

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