วิธีการโน้มน้าวใจเพื่อนร่วมทีมที่มองตัวเองว่าเป็นรุ่นพี่เพื่อเรียนรู้พื้นฐานแนวคิด SVN ได้อย่างไร [ปิด]

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

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

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

ตัวอย่างเช่นเขาได้ประกาศนโยบาย "1 SVN กระทำต่อวันต่อนักพัฒนา" เพราะมิฉะนั้น "เซิร์ฟเวอร์จะหมดพื้นที่ดิสก์ในไม่ช้า" เมื่อฉันอธิบายเขาว่า SVN กระทำการเป็นเดลต้าไม่ใช่ฉบับเต็มเขาตอบด้วยความสงสัยและแม้กระทั่งทุกวันนี้ฉันก็ไม่แน่ใจเลยว่าเขาเข้าใจความหมายของมันหรือไม่

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

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

ฉันจะโน้มน้าวให้เพื่อนร่วมทีมที่เห็นตัวเองเป็นผู้อาวุโสเพื่อให้เข้าใจพื้นฐานของ SVN ได้ดีขึ้นได้อย่างไร

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

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

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

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

หาก บริษัท ของคุณใช้วิกิให้เขียนบทความคุณภาพสูงเกี่ยวกับ SVN:

• ทำไมคุณควรใช้มัน?
• คุณควรใช้เมื่อใด
• มันแก้ปัญหาอะไรได้บ้าง?

เป็นต้น

มันจะดึงดูดสายตาของ CTO และทุกคนที่ปฏิเสธที่จะใช้จะต้องใช้ :)

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

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

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

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

• แหล่งที่มาไม่น่าเชื่อถือ ในอุตสาหกรรมที่มีการโพลาไรซ์มากขึ้นเรื่อย ๆ ในแต่ละวันระหว่าง "ลัทธิของ Mac" และ "ผู้นมัสการ MS"; ระหว่าง "อุดมการณ์โอเพนซอร์ซ" และ "การปฏิบัติจริงที่เป็นกรรมสิทธิ์" ... ฯลฯ ฯลฯ - มีหลายคนที่มักจะมีข้อสงสัยเกี่ยวกับข้อมูลที่ให้ไว้และความเป็นไปได้ของการทุจริตอันเนื่องมาจากอคติของผู้ส่งหรือผู้เขียน ตรวจสอบแล้วว่าน่าเชื่อถือ
• ประสบการณ์เลวร้ายเป็นเวลานาน ...ด้วยเทคโนโลยีหรือการปฏิบัติที่เหมือนกันหรือคล้ายคลึงกัน ไม่มีอะไรสมบูรณ์แบบเมื่อมันเริ่มต้นและหลาย ๆ ตัวเริ่มต้นด้วยคุณสมบัติน้อยกว่า 1/4 ของคุณสมบัติที่จบลงด้วย เป็นไปได้ทั้งหมดที่เขามีเวลาหลายชั่วโมงหรือหลายวันหรือหลายสัปดาห์ในการทำงานกับผลิตภัณฑ์ที่ต่ำกว่าหรือตัวที่เหมือนกันระหว่างขั้นตอนการนำไปปฏิบัติที่ไม่ดี
• แหล่งที่มา "น่าเชื่อถือ"ขัดแย้งกับข้อมูลที่เขานำเสนอ โดย "ความน่าเชื่อถือ" ฉันหมายถึงบุคคลหรือนิติบุคคลที่เขาเชื่อใจ หลายคนมักจะยกระดับคนที่เราไว้วางใจในระดับที่ไม่ได้เป็นตัวแทนของความเป็นจริง แหล่งข้อมูลนี้ไม่จำเป็นต้องกำหนดความเชื่อนี้กับบุคคล บ่อยครั้งที่เราทำมันเอง บ่อยครั้งที่เราให้บางสิ่งบางอย่างหรือใครสักคนที่ต้องการเป็นอย่างน้อยหนึ่งด้าน
• ขาดการรักษาความปลอดภัยนี่คือการเน้นโดยโปสเตอร์ก่อนหน้า โปรแกรมของเรากลายเป็นสินทรัพย์จากวินาทีที่เราเริ่มทำงานกับพวกเขา ไม่เพียง แต่กับ บริษัท ที่เราทำงาน แต่เพื่อคนที่เราทำงานด้วย นี่ไม่ใช่เพียงปัญหาการควบคุม พวกเราบางคนต้องการแสดงสิ่งที่เป็นระเบียบของเราให้กับคนที่เราใส่ใจ เราบางคนต้องการตรวจสอบให้แน่ใจว่าไม่ได้รับความเสียหายจากบุคคลหรือผลิตภัณฑ์ภายนอก สำหรับบางคนมันเป็นส่วนเสริมของความคิดและความรู้สึกของเรา มันเป็นบ้านของปรัชญาและอุดมการณ์ของเราและเผยให้เห็นคอร์ทางปัญญาของเรา สำหรับหลาย ๆ คนมันเป็นอนาคตของเราไม่ว่าจะเป็นในชั้นเรียนนายจ้างหรือลูกค้า สำหรับบางคนมันคือทั้งหมดที่ "ความปลอดภัย" ในแง่นี้ไม่ได้ใช้กับข้อมูลที่จำเป็นหรือรหัส

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

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

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

FuzzicalLogic

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

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

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

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

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

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

ไม่กี่สัปดาห์ต่อมาคนอื่นสามารถไปเที่ยวได้

ฉันจะพยายามให้คำแนะนำแก่คุณจากประสบการณ์ส่วนตัวของฉัน

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

ตัวอย่างเช่นเขาได้ประกาศนโยบาย "1 SVN กระทำต่อวันต่อนักพัฒนา" เพราะมิฉะนั้น "เซิร์ฟเวอร์จะหมดพื้นที่ดิสก์ในไม่ช้า" เมื่อฉันอธิบายเขาว่า SVN กระทำการเป็นเดลต้าไม่ใช่ฉบับเต็มเขาตอบด้วยความสงสัยและแม้กระทั่งทุกวันนี้ฉันก็ไม่แน่ใจเลยว่าเขาเข้าใจความหมายของมันหรือไม่

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

ทางออกที่เรานำมาใช้ใน บริษัท ของเราคือมีตัวกรองปฏิเสธการคอมมิทที่มีไฟล์ไบนารี่ เราสามารถบังคับกระทำโดยใช้คำสำคัญพิเศษในความคิดเห็นเช็คอิน (เราต้องแสดง SVN ว่าเรารู้ว่าเรากำลังทำอะไรอยู่) หนึ่งปีหรือสองปีผู้จัดการโครงการจะเก็บสาขาเก่าและลบออกจากที่เก็บ ด้วยกลยุทธ์นี้เราไม่มีปัญหาด้านพื้นที่ที่ฉันรู้ (ที่เก็บของเราสนับสนุนหลายโครงการและมีการแก้ไขมากกว่า 100,000 รายการ)

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

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

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

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

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

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

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

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

ฉันจะโน้มน้าวให้เพื่อนร่วมทีมที่เห็นตัวเองเป็นผู้อาวุโสเพื่อให้เข้าใจพื้นฐานของ SVN ได้ดีขึ้นได้อย่างไร

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

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

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

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

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

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

แค่ 2 เซ็นต์ของฉัน

ชี้ให้เขาเห็นเนื้อหาการเรียนรู้เกี่ยวกับวิธีการทำงานของ SVN และแนวทางปฏิบัติที่ดีที่สุดเมื่อใช้งาน SVN

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

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

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

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

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

3. ขอการสนับสนุนจากด้านบน อย่าเข้าไปโต้แย้ง "คุณไม่ใช่เจ้านายของฉัน" กับผู้ชาย แต่ถ้าพฤติกรรมของเขาทำให้เกิดปัญหาสำหรับคุณให้แน่ใจว่าผู้จัดการของคุณตระหนักถึงสถานการณ์ หากคุณไม่แน่ใจว่าจะติดต่อผู้จัดการของคุณได้อย่างไรลองขอคำแนะนำ: "ไมค์ฉันพยายามคุยกับแลร์รี่ แต่ฉันไม่ผ่านเลยเขายืนยันใน X, Y และ Z และ พวกเราที่เหลือใช้เวลาที่ไม่จำเป็นในการแก้ปัญหาที่เกิดขึ้นมากมายคุณช่วยแนะนำวิธีจัดการกับผู้ชายให้ฉันได้ไหม? "

4. ไม่สนใจเขา ทำไมทุกคนในทีมที่ฟังผู้ชายคนนี้? เขามีอำนาจที่แท้จริงในโครงการหรือไม่? ใครสนใจว่าเขาประกาศนโยบายแบบมุ่งมั่นต่อผู้พัฒนาหากเขาไม่มีอำนาจในการบังคับใช้นโยบาย ปล่อยให้เขาคิดว่าเขาคือYertle the Turtleถ้ามันทำให้เขารู้สึกดีขึ้นอย่าปล่อยให้เขาสร้างปัญหาที่แท้จริงให้กับคุณ

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

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

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

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

ในฐานะที่เป็นข้อความด้านข้างฉันจะระมัดระวังในการใช้อารมณ์ขัน มันอาจทำงานได้อย่างมหัศจรรย์หรืออาจทำให้คุณฟังเหมือนของจริง ดังนั้นฉันจะหลีกเลี่ยง

พื้นฐานเลือกการต่อสู้ของคุณอย่างระมัดระวังเพราะคุณอาจไม่ชนะ หากเป็นเช่นนั้นก็ไม่สนใจอะไรอีกหรือมองหางานอื่น ฉันรู้ว่ารุนแรง

ฉันเคยอยู่ในตำแหน่งที่คุณกลับมาเมื่อประมาณ 8 ปีที่แล้วเมื่อ SVN เป็นเทคโนโลยีที่ค่อนข้างใหม่ ฉันเป็นนักพัฒนาอาวุโสและได้รับการร้องขอ / สั่งให้ติดตั้ง SVN โดยรุ่นจูเนียร์ dev (จริง ๆ แล้วเขาเป็นฝ่ายสนับสนุนด้านไอทีที่แม่นยำกว่ารุ่น dev) ฉันเปิดใจแม้จะมีข้อสงสัยในเบื้องต้นเกี่ยวกับปริมาณงานที่เพิ่มขึ้นความซับซ้อนที่ไม่จำเป็น ฯลฯ ... และจากนั้นก็กลายเป็นแฟนตัวยงของมัน

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

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

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

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

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

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

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

ในระหว่างนี้คุณมีปัญหาจริง:

1. คนที่แต่งตัวประหลาดตรวจสอบไฟล์. project ของเขาลงใน repo: เพียงแค่เพิกเฉย คุณไม่จำเป็นต้องแก้ไขไฟล์ไม่มีใครในทีมที่รู้จักดีกว่า ปล่อยมันไป. ถ้ามันให้ "สมาชิกอาวุโส" ของคุณรู้สึกอบอุ่นและมีความสุขเหมือนผ้าห่มรักษาความปลอดภัยดังนั้นไม่ว่าจะเป็น
2. มีงบประมาณที่รับรู้เกี่ยวกับพื้นที่ดิสก์: นี่คือเหตุผลที่นายอาวุโสสั่ง 1 การกระทำต่อวัน การขาดแคลนอวกาศเป็นเรื่องจริงหรือเป็นเรื่องรับรู้หรือไม่? แม้ว่าจะเป็นเพียงการรับรู้ แต่อาจมีบางสิ่งที่คุณสามารถทำได้เพื่อเปลี่ยนการรับรู้นั้น สิ่งนี้ควรได้รับการจัดการทันที - หากคุณริเริ่มสิ่งนี้จะช่วยสร้างความเชื่อมั่น

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