คำถามติดแท็ก teamwork

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

11 project-management  teamwork  project  project-planning 

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

11 scrum  teamwork 

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

11 team  teamwork  configuration-management  role 

ที่นี่ในสำนักงานของฉันเราได้ฝึกฝนมาก่อน 9.00 น. (ไม่ว่าในกรณีใดโดยผู้บริหาร) และเริ่มต้นด้วยการประชุม Standup ที่นี่เราเริ่มต้นด้วยการพูดคุยกับปัญหาของวันก่อนหน้าการปรับปรุงใด ๆ จากผู้จัดการ (ตามโอกาสในการขาย) และแผนงานสำหรับวันนี้ การประชุมครั้งนี้อาจฟังดูดีและเน้นไปที่กระบวนการ แต่บางครั้งถ้ามีการแสดงลงมามันจะทำลายอารมณ์ในตอนเช้าหรือหากมีความเห็นที่แตกต่างกันแล้วมันก็ไม่ใช่เรื่องดีที่จะเริ่มต้นด้วย ดังนั้นฝ่ายทรัพยากรบุคคลและฝ่ายบริหารจึงตัดสินใจว่าในขั้นต้นเราจะหารือเรื่องส่วนตัวเป็นเวลา 10 ถึง 15 นาทีจากนั้นเราจะข้ามไปยังการอภิปรายทางเทคนิคและเป็นทางการเป็นเวลา 15 นาทีทุกวันคุณจริงจังไหมฉันไม่ได้รับหัวข้อ ด้วยลีดเดอร์ของฉันที่แก่กว่าฉันมากและไม่เคยคุยเรื่องส่วนตัวเลยจนถึงตอนนี้และคุณต้องการเริ่มต้นด้วยมันแบบนั้น !!! ดังนั้นมันจึงกลับไปที่หนึ่งตาราง ทุกคน (น่าแปลกใจในทุกทีม) กำลังพูดคุยกันอีกครั้งในด้านเทคนิคเฉพาะในตอนเช้า / ยืนขึ้นการประชุม ดังนั้นที่นี่มาวันนี้ฉันมีอาหารกลางวันกับการจัดการและหัวข้อสำหรับการสนทนาคือ: จะทำให้การประชุม Nice Day (Morning / Standup) มีประสิทธิภาพได้อย่างไร?

11 teamwork  team  communication 

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

10 teamwork  junior-programmer 

ทีมนักพัฒนาที่มีประสบการณ์ 4 คนของฉันทำงานบนแอพพลิเคชั่น Windows ขนาดใหญ่ (ประมาณ 200 KLoC) ฉันได้มุ่งเน้นไปที่ codebase หลักตั้งแต่จุดเริ่มต้นของโครงการ (3 ปีที่แล้ว) และค่อยๆเปลี่ยนไปสู่ตำแหน่งผู้พัฒนากึ่งนำแม้ว่าฉันไม่ใช่ผู้จัดการทีม การวนซ้ำปัจจุบันของเราคือการรีเฟรช UI ที่มีลำดับความสำคัญสูงที่ผู้บริหารระดับสูงร้องขอซึ่งเกี่ยวข้องกับการเปลี่ยนแปลงประมาณ 15 ครั้งในฐานข้อมูลหลัก เมื่อผู้จัดการถามฉันฉันคาดว่าการเปลี่ยนแปลงทั้ง 15 ครั้งจะใช้เวลาน้อยกว่าสี่ชั่วโมงกว่าจะเสร็จสมบูรณ์รวมน้อยกว่า 7 วันทำงาน ฉันอาสาไปทำงาน ผู้จัดการตัดสินใจที่จะแบ่งงานทั้ง 15 ให้กับนักพัฒนาทั้งสี่คนอย่างเท่าเทียมกัน ในสามวันนับตั้งแต่เราเริ่มทำงานฉันได้สังเกตสองสิ่ง: สมาชิกในทีมที่ไม่มีประสบการณ์คนอื่น ๆ ทำภารกิจอย่างน้อย 1 อย่างให้เสร็จ กฎหมายของ Brook ใช้งานได้ : ฉันใช้เวลาประมาณครึ่งหนึ่งในการให้ความช่วยเหลือ (พยายามสอนพวกเขาเกี่ยวกับการใช้ส่วนประกอบ) เป็นผลให้ฉันทำงาน 2 อย่างด้วยตัวเองแทนที่จะเป็น 5 หรือ 6 อย่างที่คาดไว้ ฉันเข้าหาผู้จัดการด้วยความกังวลว่าเรามาช้าและแนะนำอีกครั้งว่าฉันทำภารกิจที่เหลือให้เสร็จ คำขอของฉันถูกปฏิเสธอย่างสุภาพและเหตุผลที่กล่าวไว้ในการแบ่งโหลดอย่างเท่าเทียมกันนั้นเป็นสองเท่า: จำกัดปัจจัยรถบรรทุก …

10 teamwork  code-ownership  brookslaw 

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

10 open-source  teamwork  contribution 

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

10 code-quality  teamwork 

เมื่อเร็ว ๆ นี้ฉันได้มีส่วนร่วมในโครงการเปรียว (โดยใช้การทะเลาะกัน) ซึ่งฝ่ายบริหารคิดว่าทีมจะเสนอชื่อผู้พัฒนา 'MVP' รวมถึง QA 'MVP' ในตอนท้ายของการวิ่งแต่ละครั้งโหวตโดย ทีม. จากนั้น MVP จะได้รับเงินจำนวนเล็กน้อยและอาหารกลางวันฟรีรวมถึงถ้วยรางวัลสำหรับแสดงบนโต๊ะทำงานของเขา เรามีการวิ่งสองครั้งด้วยระบบรางวัลนี้ สิ่งที่ฉันเห็นจากสิ่งนี้คือ: ข้อบกพร่องเพิ่มเติมได้รับการแก้ไข (ซึ่งเป็นสิ่งที่ผู้บริหารระดับสูงต้องการที่จะเห็นการเปลี่ยนแปลงจำนวนในทิศทางที่พวกเขาต้องการ) MVP จากแต่ละทีม 'ได้รับการยอมรับและได้รับการเพิ่มความนับถือตนเอง (หรือมันคือการเพิ่มอัตตา?) ฉันสังเกตเห็นบางสิ่งที่ฉันจะพิจารณาด้านที่ไม่ดีในการทำสิ่งนี้ (อย่างน้อยจากมุมมองนักพัฒนา): มีนักพัฒนาซอฟต์แวร์บางคนที่กังวลกับจำนวนที่คุณภาพของการแก้ไขข้อบกพร่องลดลง การแก้ไขในพื้นที่หนึ่งเป็นสาเหตุของการถดถอยในพื้นที่อื่น มีนักพัฒนาไม่กี่คนที่กำลังหยิบบั๊ก 'ง่าย / เร็วขึ้น' เพื่อเพิ่มจำนวนบั๊ก อาจจะดีไม่ดีที่นี่ฉันเดา ลำดับความสำคัญที่สูงกว่า (ซึ่งบ่อยครั้งมากจะสัมพันธ์กับ 'ยากขึ้น / ยาวขึ้นเพื่อแก้ไข') ข้อบกพร่องจริง ๆ แล้วกลายเป็นลำดับความสำคัญที่ต่ำกว่า ข้อบกพร่องในการบล็อกจะไม่ได้รับการแก้ไขในเวลาที่เหมาะสมเนื่องจากโดยปกติแล้วพวกเขาจะใช้เวลานานกว่าและต้องการการประสานงานกับ QA มากขึ้น มุมมองของทีมภายในทีม Dev หายไป แง่มุมของทีมของ Dev และ QA …

9 agile  scrum  teamwork  motivation 

ปิด คำถามนี้จะต้องมีมากขึ้นมุ่งเน้น ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้มุ่งเน้นที่ปัญหาเดียวโดยแก้ไขโพสต์นี้ ปิดให้บริการใน4 ปีที่แล้ว สมมติว่าฉันมีวัตถุ PHP สมมติว่า: companyObj class companyObj { private company_name; private company_address; public function print_contact() { //logic } } นี่คือสิ่งที่ฉันเขียนและแชร์กับเพื่อนร่วมทีม ตอนนี้ฉันต้องการทำให้มีประสิทธิภาพมากขึ้นเช่นนี้ class companyObj { private company_name; private company_address; private company_contact_person; public function print_contact() { //logic updated } } ตอนนี้ฉันจะแจ้งเพื่อนร่วมทีมของฉันได้อย่างไรว่าวัตถุของฉันมีคุณสมบัติมากกว่าที่พวกเขาสามารถตั้งค่าได้ แทนที่จะส่งอีเมลให้กับทุกคนในทีมพัฒนาฉันจะทำให้ทีมรู้ได้อย่างไรว่าเกิดอะไรขึ้นเมื่อฉันไม่ต้องการให้เพื่อนร่วมทีมเสียเวลาเพื่อดูว่ามีการเปลี่ยนแปลงอะไรในระดับซอร์สโค้ด

9 programming-practices  teamwork  communication 

ฉันทำงานกับทีมเล็ก ๆ ใน บริษัท ขนาดกลางซึ่งส่วนใหญ่ไม่ได้เกี่ยวข้องกับการพัฒนาซอฟต์แวร์ ฉันเป็นนักพัฒนาซอฟต์แวร์รุ่นใหม่ล่าสุดและมีประสบการณ์น้อยที่สุดและไม่มีพื้นฐานด้านอาชีพหรือการศึกษาด้านซอฟต์แวร์ก่อนที่จะเริ่ม แต่ฉันรู้สึกยินดีเป็นอย่างยิ่งกับความเคารพที่ได้รับจากข้อมูลของฉัน แต่ถึงกระนั้นฉันรู้สึกว่าฉันควรจะทำมากขึ้นด้วยเวลาออกอากาศจำนวนใจกว้างนี้ ในฐานะทีมเราดูเหมือนจะมีปัญหาในการทำสิ่งต่างๆให้เสร็จ ฉันอยากจะแนะนำสิ่งที่จะปรับปรุงสถานการณ์และฉันคิดว่าฉันจะฟังถ้ามันเป็นความคิดที่ดี แต่ฉันสูญเสียสิ่งที่จะแนะนำ สิ่งที่ฉันสามารถระบุได้ว่าเป็นปัญหารวมถึง: รายละเอียดของงานในมือมีน้อย ส่วนหนึ่งเป็นเพราะการจัดการเป็นปัญหาคอขวดและเราไม่มีเงินหรือผู้คนที่จะทำตามข้อกำหนดรายละเอียดเท่าที่เราต้องการ ส่วนหนึ่งเป็นเพราะซอฟต์แวร์ที่เรากำลังพัฒนานั้นกำลังสืบสวนและวิธีการที่แม่นยำยังไม่ชัดเจนจนกว่าจะมีการสาธิตและนำมาใช้เพื่อกำหนดประสิทธิภาพ Lead Dev นั้นชื่นชอบสิ่งที่เขาเรียกว่า 'การสร้างต้นแบบ' จนถึงจุดที่เขาเริ่มยืนยันว่าทุกอย่างคือ 'prototyped' ซึ่งส่วนที่เหลือของเราดูเหมือนจะเขียนโค้ดไม่ดีและให้มันแก่ modellers เพื่อเล่นกับ ไม่ชัดเจนว่าเขาคาดหวังอะไรจากการออกกำลังกายนี้ในหลายกรณี การดำเนินการ 'ที่เกิดขึ้นจริง' นั้นได้รับความทุกข์ทรมานเนื่องจากการยืนยันของเขาว่าการปฏิบัติที่ดีต้องใช้เวลามากเกินไปจากการสร้างต้นแบบ ฉันยังไม่ได้เริ่มที่จะสามารถแก้ปริศนาตรรกะที่คลี่คลายนี้และฉันไม่แน่ใจว่าฉันต้องการลอง ผู้ดัดแปลงคาดว่าจะบอกทุกอย่างเกี่ยวกับวิธีการที่ต้องการในรายละเอียดที่แม่นยำและเชื่อมั่นอย่างแน่นอนว่าสิ่งที่พวกเขาออกมานั้นไม่มีเหตุผลในทางทฤษฎี เรื่องนี้แทบจะไม่เคยเกิดขึ้นจริง แต่ไม่มีการดำเนินการใด ๆ ที่จะแก้ไขสถานการณ์นี้ ไม่มีใครในด้านการสร้างแบบจำลองยกข้อกังวลใด ๆ ในลักษณะที่มีโครงสร้างที่มีแนวโน้มที่จะดำเนินการและพวกเขาไม่แสวงหาแนวทางในการใช้แนวทางปฏิบัติที่ดีที่สุด ไม่มีอะไรทำเกี่ยวกับความเฉยเมยเช่นกัน ฉันเคยพยายามที่จะผลักดัน TDD ในทีมก่อนหน้านี้ แต่พบว่ามันยากเพราะมันใหม่สำหรับฉันและในขณะที่ผู้ที่มีหน้าที่กำกับดูแลงานของฉันก็เต็มใจที่จะทนมันไม่มีความกระตือรือร้นมาจากคนอื่น ฉันไม่สามารถพิสูจน์ได้ว่าฉันใช้เวลาไปกับการหมกมุ่นและไม่ทำฟีเจอร์ให้จบดังนั้นความคิดนั้นก็ถูกทอดทิ้ง ฉันกังวลว่ามันจะไม่ถูกหยิบขึ้นมาอีกเพราะไม่มีใครชอบที่จะบอกวิธีการทำงานของพวกเขา ตอนนี้เรามีเซิร์ฟเวอร์รวมอย่างต่อเนื่อง แต่ส่วนใหญ่จะใช้เพื่อทดสอบการถดถอยหลายชั่วโมงเท่านั้น มันถูกเปิดทิ้งไว้ว่าควรจะใช้การทดสอบเต็มรูปแบบและการรวมเข้าด้วยกันเช่นกัน แต่ในขณะนี้ไม่มีใครเขียนมัน ทุกครั้งที่ฉันยกประเด็นเรื่องคุณภาพด้วยนักพัฒนานำฉันจะได้รับคำตอบเกี่ยวกับผลของ 'การทดสอบคุณสมบัติ …

9 productivity  agile  testing  teamwork 

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

9 asp.net  teamwork  team-foundation-server  team-building  configuration 

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

9 version-control  teamwork  mercurial 

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

9 agile  team  teamwork 

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

9 teamwork  knowledge-transfer