Làm thế nào để thuyết phục một đồng đội, người tự coi mình là đàn anh, để học những điều cơ bản về khái niệm SVN? [đóng cửa]

Để bắt đầu với một số nền tảng, tôi đã đảm nhận một vị trí nhà phát triển mới vào mùa hè này và cuối cùng trở thành thành viên mới nhất trong nhóm, nhưng với hầu hết kinh nghiệm dưới vành đai.

Cho đến nay tôi đã cố gắng thúc đẩy các sáng kiến ​​về sự tỉnh táo đủ dễ dàng vì chi phí nhận con nuôi thấp (về thời gian và công sức). Tuy nhiên mọi thứ đã lên cấp một chút.

Một trong những đồng đội của tôi, mặc dù có kinh nghiệm nhưng không thực sự hiểu SVN. Đương nhiên, các khu vực trống trên bản đồ tinh thần của anh ta mô tả các đại dương của SVN khiến anh ta chấp nhận các mô hình sử dụng khá kỳ lạ.

Ví dụ: anh ta đã tuyên bố chính sách "1 SVN cam kết mỗi ngày cho mỗi nhà phát triển" bởi vì nếu không thì "máy chủ sẽ sớm hết dung lượng đĩa". Khi tôi giải thích cho anh ấy rằng SVN cam kết là đồng bằng, không phải là bản sao đầy đủ, anh ấy đã trả lời với sự nghi ngờ và ngay cả hôm nay tôi không hoàn toàn chắc chắn nếu anh ấy hiểu ý nghĩa của nó.

Chúng tôi cũng đã có một cuộc tranh luận sôi nổi về việc có nên đưa .projectcấu hình Eclipse vào SVN hay không. Đồng đội của tôi khẳng định chúng ta nên, mặc dù nó đã gây ra vô số xung đột vô nghĩa. Tôi đã chống lại việc giữ các tệp cấu hình nhà phát triển cá nhân trong SVN. Cuối cùng, hóa ra đồng đội của tôi đã thực hành kiểm tra lại toàn bộ cây nguồn sau mỗi lần xác nhận để đảm bảo "mã được cam kết vào kho hoạt động". Đó là lý do anh ta rất kiên quyết trong việc giữ cấu hình dự án trong SVN - vì vậy sẽ dễ dàng nhập lại dự án. Khi tôi giải thích rằng cam kết đồng bộ hóa bản sao làm việc với từng byte từ xa khiến việc kiểm tra lại không cần thiết, đồng đội của tôi đã trả lời một cách nghi ngờ một lần nữa và cuối cùng đã loại bỏ toàn bộ vấn đề là không đáng kể.

Theo tôi, nhóm của chúng tôi lãng phí thời gian bằng cách giải quyết xung đột SVN trong các tệp cấu hình dự án chỉ chứa các cài đặt dành riêng cho nhà phát triển không cần chia sẻ với SCM. Tất cả điều này lộn xộn bởi vì ai đó đã điều chỉnh quá trình xung quanh các giả định không chính xác.

Làm thế nào tôi có thể thuyết phục một đồng đội, người tự coi mình là đàn anh, để hiểu rõ hơn về những điều cơ bản của SVN?

IMO, tốt nhất là tách những vấn đề gây ra vấn đề / tác hại trực tiếp đến dự án khỏi những vấn đề chỉ ảnh hưởng đến nhà phát triển duy nhất đó . Ví dụ, nếu anh ta thích kiểm tra mọi thứ nhiều lần trong ngày, điều đó sẽ làm anh ta chậm lại, nhưng nếu không sẽ không ảnh hưởng đến người khác. Vì vậy, bạn chỉ có thể để anh ấy làm điều đó (cho đến khi có một độ trễ hiệu suất đáng chú ý trong công việc của anh ấy), và tự cứu mình khỏi những rắc rối khi tranh cãi về nó.

Các vấn đề khác mà bạn đề cập, như giữ .projectcác tệp Eclipse trong repo hoặc 1 cam kết mỗi ngày, là nơi bạn nên tập trung, để cho phép nhóm tiến triển thuận lợi nhất có thể. Trước hết, bạn nên hỏi / thu thập phản hồi từ các thành viên khác trong nhóm , liệu điều này có gây ra vấn đề cho họ không. Nếu có những người khác, cùng nhau bạn có thể gây áp lực nhiều hơn , và nếu cần, bạn có thể dễ dàng leo thang một vấn đề đối với quản lý.

Về "SVN hết dung lượng đĩa", có thể dễ dàng bác bỏ niềm tin của anh ấy bằng cách thực hiện một thử nghiệm (có thể trong một bản thử nghiệm riêng). Bạn chỉ cần theo dõi kích thước của hệ thống phân cấp tệp repo vật lý trước và sau khi thực hiện các thay đổi thành một tệp văn bản lớn hoặc thậm chí rất nhiều tệp. Nếu điều đó không thuyết phục anh ta, không có gì có thể.

Trong trường hợp đó, thật không may, bạn có thể có một vấn đề về thẩm quyền, nơi anh chàng kia thấy việc chấp nhận lời khuyên từ một người nào đó "thấp hơn trong cấp bậc" là sự mất phẩm giá của anh ta. Những xung đột như vậy không thể được giải quyết bằng lập luận logic. Bạn cần nâng cấp nó lên quản lý, nhưng hãy cẩn thận để đảm bảo bạn có đủ sự hỗ trợ (từ đồng đội và / hoặc quản lý) trước khi bạn làm như vậy. Một động thái như vậy có thể được anh chàng kia coi là một cuộc tấn công mở, do đó có thể gây ra hậu quả có vấn đề (với một trong hai bạn, và / hoặc sự bình yên của cả đội). Vì vậy, hãy suy nghĩ ba lần, và thảo luận với các đồng nghiệp hỗ trợ của bạn trước khi bạn thực hiện bước đó.

Nếu công ty của bạn sử dụng wiki, hãy viết một số bài đăng chất lượng cao về SVN:

• Tại sao bạn nên sử dụng nó?
• Khi nào bạn nên sử dụng nó?
• Nó giải quyết vấn đề gì?

v.v.

Nó sẽ lọt vào mắt của CTO và tất cả những người từ chối sử dụng sẽ phải sử dụng :)

Là một người lãnh đạo, quản lý và thành viên trong nhóm, tôi đã phải đối phó với việc giải quyết xung đột nghề nghiệp và nhân cách ở nhiều cấp độ. Bất kể tôi được thuê vào vai trò nào, tôi thường được nhận làm người lãnh đạo ngay cả khi tôi không muốn vai trò đó. Lý do cho điều này là cách tôi đối phó với những xung đột này.

Không giống như nhiều người ở đây, tôi không đồng ý rằng việc giải quyết tình huống này là "từ bỏ" hoặc "chỉ cho anh ta một công cụ mới" hoặc "chờ anh ta ngã vào mông hoặc không thích". Quan trọng nhất, không bao giờ là một ý tưởng tốt để chờ đợi cho đến khi vai trò được xác định chắc chắn hơn. Những vai trò đó được xác định bởi những người không chờ đợi, bởi niềm tin, đạo đức và khả năng xử lý các tình huống quan trọng của họ cho dù họ có liên quan đến mọi người hay không.

Có một số phương pháp để đối phó với kiểu người mà bạn đang mô tả trong những tình huống này. Bước đầu tiên và quan trọng nhất là điều tra lý do tại sao anh ta cư xử theo cách mà anh ta đang có. Nó ít liên quan đến những gì anh ta biết hoặc không biết. Anh ta có thể dễ dàng tìm ra thông tin này trước đây, vì vậy câu hỏi thực sự là một trong hai điều: "Tại sao anh ta không?" hoặc "Tại sao anh ta từ chối thông tin anh ta đang được cung cấp?" Điều này sẽ giúp bạn tìm ra chính xác những gì cần được giải quyết.

Theo kinh nghiệm của tôi, các lập trình viên (bao gồm cả bản thân tôi) từ chối thực hành tốt hoặc các công cụ mới chỉ vì một vài lý do:

• Nguồn không đáng tin. Trong một ngành công nghiệp ngày càng phân cực hơn mỗi ngày giữa "giáo phái Mac" và "những người tôn thờ MS"; giữa "Tư tưởng nguồn mở" và "Tính thực tiễn độc quyền" ... vv - Có nhiều người luôn nghi ngờ về thông tin được cung cấp và tiềm năng tham nhũng của nó do sự sai lệch của người nộp hoặc người viết, ngay cả khi thông tin đó là xác minh là đáng tin cậy.
• Trải nghiệm xấu kéo dài ... với một công nghệ hoặc thực hành tương tự hoặc thậm chí tương tự. Không có gì là hoàn hảo khi nó bắt đầu, và nhiều người bắt đầu với ít hơn 1/4 tính năng so với cuối cùng. Hoàn toàn có thể là anh ta đã có nhiều giờ hoặc nhiều ngày hoặc thậm chí nhiều tuần làm việc với một sản phẩm kém hơn hoặc cùng một sản phẩm trong giai đoạn thực hiện kém.
• Nguồn "đáng tin cậy" ... mâu thuẫn với thông tin anh ta đang trình bày. Theo "đáng tin cậy", tôi có nghĩa là một số người hoặc thực thể mà anh ấy tin tưởng. Nhiều người có xu hướng nâng những người mà chúng ta tin tưởng lên mức không đại diện cho thực tế. Nguồn này thậm chí không phải áp đặt niềm tin này lên người. Thông thường, chúng tôi tự làm điều đó. Nó thường cho chúng ta một cái gì đó hoặc ai đó khao khát được như thế, trong ít nhất một khía cạnh.
• Thiếu an ninh Điều này đã được đánh dấu bằng một poster trước đó. Các chương trình của chúng tôi trở thành tài sản từ lần thứ hai chúng tôi bắt đầu làm việc với chúng. Không chỉ với các công ty chúng tôi làm việc, mà còn cho những người chúng tôi làm việc cùng. Đây không chỉ đơn giản là một vấn đề kiểm soát. Một số người trong chúng tôi muốn có thể hiển thị những thứ gọn gàng của mình cho những người chúng tôi quan tâm. Một số người trong chúng ta muốn đảm bảo rằng nó không bị tổn hại bởi người hoặc sản phẩm bên ngoài. Đối với một số người, đó là một phần mở rộng về cách chúng ta nghĩ và cảm nhận, thậm chí. Nó chứa một số triết lý và ý thức hệ của chúng tôi và phơi bày lõi trí tuệ của chúng tôi. Đối với nhiều người, đó là tương lai của chúng ta, cho dù đó là cho một lớp học, một người sử dụng lao động hoặc khách hàng. Đối với một số người, đó là tất cả. "Bảo mật" theo nghĩa này không áp dụng cho dữ liệu, nhất thiết hoặc mã.

Tìm ra cái nào là yếu tố thường xuyên khá dễ dàng. Đưa người vào một khung cảnh trung lập. Giải thích cho người đó những gì bạn đang quan sát, nói chung. Hỏi người thành thật điều gì gây ra hành vi này. Bây giờ, nó không phải lúc nào cũng tốt, nhưng hầu hết người lớn phản ứng khá tốt khi bạn dường như muốn giúp đỡ một người dường như đang hành động phi lý. Có thể anh ta không hành động phi lý, nhưng không biết rằng không ai có thể hiểu chuyện gì đang thực sự xảy ra.

Một khi bạn tìm ra vấn đề thực sự là gì, bạn có thể trang bị cho mình những công cụ thích hợp để giải quyết nó. Nếu đó là kịch bản số 1, hãy khuyến khích anh ấy thực hiện nghiên cứu từ các nguồn mà anh ấy tin tưởng và (điều này rất quan trọng)lấy lại cho bạn với những phát hiện của riêng mình. Điều này sẽ cho anh ta biết rằng thông tin của anh ta giữ giá trị với bạn. Trong trường hợp của kịch bản # 2, hãy cung cấp các so sánh chính xác với những gì khác biệt so với trước đây. Khuyến khích anh ấy thử, nhưng có một kế hoạch dự phòng nếu nó đi sai. Đối với kịch bản # 3, hãy nói với anh ấy để yêu cầu nguồn của anh ấy với thông tin CỦA BẠN. Rất có thể là nguồn của anh ta không giữ quan điểm mà anh ta nghĩ rằng anh ta làm, nhưng đã làm một lần. Hầu hết chúng ta thích nghi theo thời gian, vì vậy quan điểm của anh ấy có lẽ đã thay đổi. Nếu anh ấy không sẵn lòng, khuyến khích anh ấy giới thiệu bạn với nguồn của anh ấy. Và cuối cùng, đối với kịch bản số 4, đảm bảo với anh ấy rằng những lo lắng của anh ấy là của riêng bạn. (Chúng nên ở một mức độ nào đó) Chứng minh làm thế nào công cụ "mới" này có thể bảo vệ lợi ích của anh ấy và tăng tính bảo mật của anh ấy. Và nếu không thể,

Tôi biết tất cả điều này nghe có vẻ quá đơn giản để làm việc, nhưng đôi khi nó chỉ đơn giản là làm. Trong thực tế, bạn càng chân thành, nó càng thường xuyên hơn. Bằng cách giải quyết nhu cầu của anh ấy, bạn đang giải quyết nhu cầu của đội, cho dù anh ấy có phải là "tiền bối" hay không, bởi vì anh ấy là một phần của đội. Cho anh ấy thấy rằng bạn muốn ở cùng một trang với anh ấy, nhưng đơn giản là không, có thể khuyến khích anh ấy bắt đầu làm việc cùng với bạn. Nếu bạn đã làm tất cả những điều này mà vẫn không đạt được giải pháp, thì bạn đã làm tất cả những gì bạn có thể nói ngắn gọn với trưởng nhóm.

FuzzicalLogic

Có rất nhiều sự mê tín xung quanh việc kiểm soát nguồn. Nó phản trực giác, toán học rất phức tạp và nó liên quan đến tài sản quan trọng nhất mà một công ty phần mềm sở hữu. Tôi phải thừa nhận rằng có một phần của tôi vẫn không tin tưởng nó. Nhưng tôi sẽ không làm mà không có nó trong một phút.

Một giải pháp có thể là đề nghị nhận trách nhiệm chăm sóc repo. Tất nhiên, nếu bạn trình bày nó là "nó rất nhiều việc cho bạn, và đây chỉ là một lĩnh vực mà tôi có một số kinh nghiệm", chứ không phải là "bạn không biết bạn đang làm gì" mà sẽ có cơ hội làm việc tốt hơn

Nếu "tự coi mình là đàn anh" có nghĩa là những gì tôi nghĩ, thì anh ta sẽ không từ bỏ vì anh ta coi đó là nguồn quyền lực và sự kiểm soát. Vì vậy, cách giải quyết cho bạn có thể là sử dụng Git cục bộ để quản lý các đơn vị và chi nhánh cam kết lành mạnh, sau đó chỉ cần đẩy sang svn mỗi ngày một lần như anh ta yêu cầu. Git được thiết kế như một hệ thống ngang hàng và để có một bản sao repo đầy đủ trên mỗi máy cục bộ. Bạn có thể cung cấp git cho các nhà phát triển khác, những người muốn làm theo cách đó và nó vẫn có thể chỉ là một bổ sung cho SVN mà các nhóm làm việc riêng lẻ (cho dù một hoặc nhiều nhà phát triển, chính thức hoặc quảng cáo) sử dụng nội bộ. Và khi ngày mà anh chàng cao cấp nương tựa, chuyển sang bộ phận hoặc công ty khác, hoặc tự vẽ mình vào một góc không thể phục hồi với các chính sách SVN của anh ta, bạn sẽ bắt đầu làm sạch tất cả.

Chỉ cần nói chuyện với họ. Hãy nhìn xem, tôi là một nhà phát triển cao cấp, nhưng có những điều tôi không biết. Đó là bản chất của kinh doanh. Nếu họ trở nên phòng thủ hoặc hung hăng, đó là vấn đề cá tính với nhà phát triển trong trường hợp và điều đó nên được giải quyết bởi trưởng nhóm, hoặc nếu họ là trưởng nhóm, bởi ông chủ của họ.

Bắt đầu một sáng kiến ​​túi màu nâu, một vài tuần một lần ai đó tổ chức một buổi nói chuyện vào giờ ăn trưa về một cái gì đó họ biết và trình bày cho những người khác.

Bạn sử dụng điều này như là lý do để trình bày SVN chi tiết và có thể một số suy nghĩ đằng sau một số lựa chọn thay thế.

Một vài tuần sau người khác có thể có một đi.

Tôi sẽ cố gắng cung cấp cho bạn một số gợi ý được hỗ trợ bởi kinh nghiệm cá nhân của tôi.

Một trong những đồng đội của tôi, mặc dù có kinh nghiệm nhưng không thực sự hiểu SVN. Đương nhiên, các khu vực trống trên bản đồ tinh thần của anh ta mô tả các đại dương của SVN khiến anh ta chấp nhận các mô hình sử dụng khá kỳ lạ.

Ví dụ: anh ta đã tuyên bố chính sách "1 SVN cam kết mỗi ngày cho mỗi nhà phát triển" bởi vì nếu không thì "máy chủ sẽ sớm hết dung lượng đĩa". Khi tôi giải thích cho anh ấy rằng SVN cam kết là đồng bằng, không phải là bản sao đầy đủ, anh ấy đã trả lời với sự nghi ngờ và ngay cả hôm nay tôi không hoàn toàn chắc chắn nếu anh ấy hiểu ý nghĩa của nó.

Ngay cả khi dung lượng ổ đĩa là một vấn đề, bạn luôn có thể cam kết nhiều tệp cùng một lúc, vì vậy tôi nghĩ những gì anh ấy đề xuất là giải pháp sai. Hơn nữa, có thể lãng phí rất nhiều dung lượng bằng cách kiểm tra các tệp nhị phân lớn vì SVN không lưu trữ deltas cho các tệp nhị phân. Một lần đăng ký mỗi ngày cũng rất tệ vì nó buộc bạn phải thực hiện các thay đổi không thuộc về nhau, ví dụ trong trường hợp bạn sửa nhiều hơn một lỗi mỗi ngày.

Giải pháp chúng tôi đã áp dụng trong công ty của chúng tôi là có một bộ lọc từ chối mọi cam kết có chứa các tệp nhị phân. Chúng tôi có thể buộc cam kết bằng cách sử dụng một từ khóa đặc biệt trong nhận xét đăng ký (chúng tôi phải cho SVN biết rằng chúng tôi biết những gì chúng tôi đang làm). Một lần trong một hoặc hai năm, người quản lý dự án lưu trữ các nhánh cũ và xóa chúng khỏi kho lưu trữ. Với chiến lược này, chúng tôi không gặp vấn đề về không gian mà tôi biết (kho lưu trữ của chúng tôi hỗ trợ một số dự án khác nhau và có hơn 100000 phiên bản).

Tóm tắt, bạn có thể nói với anh ta rằng bạn đồng ý với anh ta rằng dung lượng đĩa là một vấn đề quan trọng, nhưng mặt khác, chỉ ra

1. tầm quan trọng của việc đăng ký liên quan đến tính năng thay vì đăng ký hàng ngày nguyên khối;
2. thực tế là bằng cách kiểm tra một tệp nhị phân lớn mỗi ngày, người ta có thể điền vào đĩa.

Sau đó, bạn có thể đề nghị bạn có một cuộc họp (có thể với các nhà phát triển hoặc quản trị viên hệ thống khác) để thảo luận về các chiến lược để kiểm soát việc sử dụng không gian đĩa (ví dụ: bộ lọc tệp nhị phân, sao lưu thường xuyên và dọn sạch các nhánh không sử dụng cũ).

Chúng tôi cũng đã có một cuộc tranh luận sôi nổi về việc có nên bao gồm cấu hình .project của Eclipse trong SVN hay không. Đồng đội của tôi khẳng định chúng ta nên, mặc dù nó đã gây ra vô số xung đột vô nghĩa. Tôi đã chống lại việc giữ các tệp cấu hình nhà phát triển cá nhân trong SVN. Cuối cùng, hóa ra đồng đội của tôi đã thực hành kiểm tra lại toàn bộ cây nguồn sau mỗi lần xác nhận để đảm bảo "mã được cam kết vào kho hoạt động". Đó là lý do anh ta rất kiên quyết trong việc giữ cấu hình dự án trong SVN - vì vậy sẽ dễ dàng nhập lại dự án. Khi tôi giải thích rằng cam kết đồng bộ hóa bản sao làm việc với từng byte từ xa khiến việc kiểm tra lại không cần thiết, đồng đội của tôi đã trả lời một cách nghi ngờ một lần nữa và cuối cùng đã loại bỏ toàn bộ vấn đề là không đáng kể.

Theo tôi, nhóm của chúng tôi lãng phí thời gian bằng cách giải quyết xung đột SVN trong các tệp cấu hình dự án chỉ chứa các cài đặt dành riêng cho nhà phát triển không cần chia sẻ với SCM. Tất cả điều này lộn xộn bởi vì ai đó đã điều chỉnh quá trình xung quanh các giả định không chính xác.

Bạn có sử dụng máy chủ xây dựng không? Chúng tôi có một máy chủ xây dựng để kiểm tra dự án hoàn chỉnh và biên dịch nó mỗi đêm. Sáng hôm sau, người kiểm tra có trình cài đặt sẵn sàng để kiểm tra sản phẩm (nếu bản dựng chính chạy chính xác) và chúng tôi (nhà phát triển) có báo cáo bản dựng với tất cả các cảnh báo (và có lỗi, trong trường hợp có bất kỳ). Tất nhiên, bạn cần thiết lập các tệp cấu hình tiêu chuẩn cho máy chủ bản dựng và kiểm tra chúng. Mỗi nhà phát triển sau đó có thể kiểm tra chúng cùng với phần còn lại của dự án, nhưng họ không được phép kiểm tra bất kỳ thay đổi cục bộ nào.

Trong kịch bản này, bạn giải quyết nhu cầu của anh ấy để có thể kiểm tra dự án hoàn chỉnh và xây dựng nó bất cứ lúc nào. Bạn cũng tránh dành thời gian để hợp nhất các thay đổi không nên được kiểm tra ngay từ đầu vì chúng không phải là một phần của sản phẩm: sản phẩm là bản dựng chính và phải được giữ sạch. Nếu ai đó phá vỡ bản dựng chính (ví dụ: kiểm tra tệp .project của chính anh ta), bạn có thể hoàn nguyên các thay đổi hoặc buộc nhà phát triển khắc phục sự cố.

Có thể nếu anh ta đưa ra vấn đề một lần nữa, bạn có thể đề nghị có một cuộc họp (có thể với các nhà phát triển khác) và tìm ra một chiến lược chung.

Làm thế nào tôi có thể thuyết phục một đồng đội, người tự coi mình là đàn anh, để hiểu rõ hơn về những điều cơ bản của SVN?

Tôi nghĩ rằng chiến lược tốt nhất sẽ là tránh đưa cuộc xung đột đến cấp độ cá nhân và thay vào đó là thảo luận về các vấn đề trong tay và các giải pháp khả thi. Nếu bạn có ấn tượng rằng anh ấy đang tìm kiếm một cuộc đối đầu cá nhân, đây là một số gợi ý (một lần nữa, từ kinh nghiệm cá nhân):

• Làm thế nào là động lực nhóm của bạn? Các đồng nghiệp khác của bạn có trải nghiệm tương tự với đồng đội này không? Có rất nhiều gợi ý nhỏ, không quá rõ ràng mà một nhóm có thể đưa ra cho một thành viên của mình để ngăn chặn một số hành vi nhất định (trò đùa hoặc quan sát nhỏ) và khuyến khích đối đầu mang tính xây dựng (đề xuất một cuộc họp hoặc đưa ra một chủ đề không chính thức trong giờ giải lao ). Đôi khi một nhóm tốt có thể nhanh chóng cô lập một yếu tố đáng lo ngại và đưa mọi thứ trở lại bình thường.
• Làm thế nào tốt là quản lý nhân sự của bạn? Chúng tôi đã có một trường hợp xung đột trong công ty của chúng tôi và người đứng đầu nhân sự đã phải can thiệp để làm rõ tình hình. Điều đó không tốt, nhưng đôi khi bầu không khí làm việc trở nên xấu đi đến mức nó sẽ không trở nên tốt hơn. Tôi hy vọng đây không phải là trường hợp của bạn (tôi không có ấn tượng rằng nó đã đi xa đến vậy) nhưng sẽ rất tốt nếu bạn biết bạn có một quản trị nhân sự tốt hay bạn phải tự mình giải quyết xung đột.

Tại sao tôi viết bài này? Bạn nói rằng bạn muốn "thuyết phục một đồng đội, người tự coi mình là đàn anh, để hiểu rõ hơn về những điều cơ bản của SVN". Đối với tôi có vẻ như cuộc xung đột có thể trở nên quá cá nhân. Một số nhà tâm lý học cho rằng 70% giao tiếp của chúng ta ở cấp độ cảm xúc, nếu mức độ này không hoạt động, thì mọi người ngừng nói về sự thật vì họ quá bận rộn để xử lý cảm xúc.

Vì vậy, bên cạnh việc giải thích quan điểm của bạn, bạn cũng có thể thử làm một cái gì đó để cải thiện giao tiếp. Mời bạn đi uống cà phê hoặc cùng nhau nghỉ trưa, có một cuộc trò chuyện ngắn về một chủ đề không liên quan đến công việc, v.v., có thể cải thiện giao tiếp và khiến sự chú ý của đồng nghiệp trở lại với những sự thật quan trọng mà bạn muốn anh ấy hiểu. Nếu anh ấy chấp nhận kiểu giao tiếp này, thì có lẽ những mâu thuẫn mà bạn có từ trước đến nay có liên quan đến thực tế là bạn không biết rõ về nhau và có một số hiểu lầm nhỏ nhưng có lẽ anh ấy sẵn sàng xây dựng một sự hợp tác mang tính xây dựng. Nếu anh ta từ chối, thì có thể có sự thù địch sâu sắc hơn về phía anh ta.

Trong trường hợp này, tôi nghĩ bạn nên đợi cho đến khi vai trò của bạn trở nên rõ ràng hơn. Nếu đồng đội của bạn không chính thức có thứ hạng cao hơn cấp bậc của bạn, anh ta sẽ không cảm thấy khó chịu với những nỗ lực của bạn để cải thiện mọi thứ. Với thời gian, anh ta sẽ phải chấp nhận nó hoặc tự biến mình thành kẻ ngốc nếu anh ta cố gắng thể hiện rằng anh ta hiểu rõ hơn. Nếu anh ta có thứ hạng cao hơn, bạn nên tìm cách để anh ta hiểu rằng điều này không được thảo luận: các quan sát của bạn nhằm cải thiện năng suất và không làm suy yếu vị trí của anh ta, điều này phải rõ ràng 100%. Khi các vai trò đã được làm rõ, nếu anh ta vẫn không thể chấp nhận những lời đề nghị hoặc chỉ trích mang tính xây dựng, thì anh ta thực sự phải có một số vấn đề với lòng tự trọng hoặc một cái gì đó tương tự.

Vì vậy, nếu tất cả các chiến lược trên đều thất bại và bạn luôn cảm thấy thất vọng, tôi sợ điều hợp lý duy nhất cần làm là đóng gói đồ đạc của bạn và tìm kiếm một nơi tốt hơn. Tôi đã thực hiện trải nghiệm này ba năm trước và tìm thấy một công ty tốt hơn nhiều mà bây giờ tôi rất hài lòng. Có thể đây không phải là trường hợp của bạn (tôi hy vọng không phải vậy) nhưng cũng cố gắng hiểu điểm này.

Chỉ 2 xu của tôi.

Chỉ cho anh ta một số tài liệu học tập về cách SVN hoạt động và các thực tiễn tốt nhất khi sử dụng SVN.

Như @Peter nói - hãy chọn các trận chiến của bạn một cách cẩn thận và đừng lãng phí năng lượng của bạn để chiến đấu với ai đó rõ ràng là không hiểu những điều cơ bản. SVN không chính xác là công nghệ tiên tiến và nó đã ở đây được một thời gian nên có đủ thông tin về nó.

Hãy thử giữ một bản ghi của 'SVN lãng phí thời gian'. Mỗi khi có sự cố xung đột / kiểm tra / phiên bản cần giải quyết, hãy ghi lại thời gian bạn / nhóm mất bao lâu để giải quyết. Nếu hóa ra bạn đang lãng phí một lượng thời gian đáng kể mỗi tuần, hãy leo thang với anh ấy và ban quản lý. Tôi chắc rằng ban quản lý sẽ sớm yêu cầu các giải pháp nếu họ nhận ra năng suất có thể được cải thiện bằng những thay đổi đơn giản trong quy trình làm việc.

Hoặc cố gắng thuyết phục đồng nghiệp của bạn có một tuần dùng thử trong đó nhóm sử dụng hệ thống đăng ký của bạn (nếu điều đó có thể dễ dàng đạt được với các dự án và cơ sở mã hiện tại của bạn). Hãy hứa với anh ấy rằng nếu nó không hoạt động, bạn có thể quay lại hệ thống cũ sau khi hết tuần. Nhưng anh ta có thể đi vòng quanh sau khi tự mình thử.

1. Hãy để Subversion giải quyết vấn đề cho bạn. Theo cách bạn nói, đồng nghiệp của bạn tương đối không phức tạp khi nói đến Subversion. Trong trường hợp đó, một giải pháp kỹ thuật có thể là một lựa chọn tốt. Nếu phần còn lại của nhóm đồng ý và bạn có thể nhận được phước lành của người quản lý, hãy thêm một global-ignorestrường vào tệp cấu hình kho lưu trữ để bạn có thể loại trừ các tệp .project và các tệp khác mà bạn không muốn dưới sự kiểm soát phiên bản.

2. Giúp anh ấy ra ngoài. Thay vì áp đặt cách làm việc của bạn lên anh ấy, hãy cố gắng giúp anh chàng làm mọi thứ theo cách của anh ấy mà không gây ra vấn đề cho những người khác. Nếu đồng nghiệp của bạn đang làm việc trong chi nhánh của anh ấy, bạn thực sự không nên quan tâm đến những gì anh ấy cam kết. Nếu anh ấy muốn cam kết tệp .project của mình để anh ấy có thể kiểm tra một bản sao mới của toàn bộ thư mục, điều đó không có vấn đề gì với bạn. Điều duy nhất bạn nên quan tâm là anh ta không hợp nhất tệp .project của mình trở lại nhánh phát triển chung. Điều đó sẽ dễ quản lý, một lần nữa, bằng cách đặt thuộc tính bỏ qua trên nhánh phát triển để loại trừ tệp .project.

3. Tìm kiếm sự hỗ trợ từ phía trên. Đừng tranh cãi "bạn không phải là ông chủ của tôi" với anh chàng, nhưng nếu hành vi của anh ta gây ra vấn đề cho bạn thì hãy chắc chắn rằng người quản lý của bạn biết về tình huống này. Nếu bạn không chắc chắn làm thế nào để tiếp cận người quản lý của mình, hãy thử hỏi lời khuyên: "Mike, tôi đã cố gắng nói chuyện với Larry, nhưng tôi không vượt qua được. Anh ấy nhấn mạnh vào X, Y và Z, và phần còn lại của chúng tôi dành rất nhiều thời gian không cần thiết để giải quyết các vấn đề tạo ra. Bạn có thể cho tôi bất kỳ gợi ý nào về cách đối phó với anh chàng không? "

4. Mặc kệ anh ta. Tại sao có ai trong đội nghe anh chàng này? Anh ta có bất kỳ thẩm quyền thực tế đối với dự án? Ai quan tâm nếu anh ta tuyên bố chính sách một cam kết cho mỗi nhà phát triển nếu anh ta không có quyền thực thi nó? Hãy để anh ấy nghĩ rằng anh ấy Yertle Rùa nếu điều đó làm anh ấy cảm thấy tốt hơn, đừng để anh ấy tạo ra những vấn đề thực sự cho bạn.

Làm cho anh chàng bị sa thải và được thực hiện với kéo gót chân của anh ta và rõ ràng mờ nhạt đối với công nghệ mới hơn. Hoặc thực sự thổi tâm trí của anh ấy và bắt đầu sử dụng GIT. Nếu anh ta không thể hiểu được SVn thì anh ta chắc chắn sẽ bị GIT thổi bay.

Bạn dường như đang chiến đấu một trận thua nhưng bạn có thể vượt qua. Machiavelli trong Hoàng tử mô tả mức độ khó khăn của một người khi thay đổi hiện trạng. Tôi sẽ đề nghị đọc lại chương đó và sau đó có thể không làm những gì anh ấy gợi ý - nó có thể khắc nghiệt.

Bạn nên đưa mối quan tâm của mình đến nhà phát triển cấp cao một cách riêng tư và đảm bảo rằng bạn chỉ trích một cách xây dựng cách mọi thứ được thực hiện và không phải anh ta hoặc bất kỳ nhà phát triển nào khác. Sau đó đề nghị làm một bài nói chuyện và viết một hướng dẫn thực hành tốt nhất. Chỉ cho họ cách hiểu SVN tốt hơn sẽ giúp cuộc sống của họ dễ dàng hơn. Cuối cùng, tất cả là về chi phí và hiệu quả. Nếu bạn có thể chứng minh rằng cách của bạn cải thiện mọi thứ mà không cần phải nhón chân thì bạn có thể giành được điều này.

Cố gắng hiểu lý do tại sao (các) anh chàng cao cấp đang sử dụng kho lưu trữ. Mối quan tâm của họ là gì? Họ đang cố gắng đạt được điều gì? Làm thế nào bạn có thể giúp họ có năng suất cao hơn? Trên hết, hãy cố gắng giữ một cách tiếp cận bình tĩnh và chuyên nghiệp. Nó rất dễ bị nản lòng. Hãy quyết đoán: Sự quyết đoán trong công việc: Hướng dẫn thực tế để xử lý các tình huống khó xử của Ken Back và Kate Back là một cuốn sách đáng đọc. Cuối cùng, hãy nghĩ "làm thế nào tôi có thể thuyết phục bản thân chuyển đổi?". Hãy là một người ủng hộ ma quỷ trung thực và điều đó có thể giúp bạn đưa ra câu trả lời và câu hỏi hay để hỏi.

Là một lưu ý phụ, tôi sẽ cẩn thận để sử dụng sự hài hước. Nó có thể làm việc kỳ diệu hoặc nó có thể làm cho bạn nghe như một asshat. Vì vậy, tôi sẽ tránh nó.

Về cơ bản, hãy chọn các trận chiến của bạn một cách cẩn thận vì bạn có thể không thắng được trận này. Nếu đó là trường hợp, hoặc không quan tâm nữa hoặc tìm kiếm một công việc khác. Khắc nghiệt, tôi biết.

Tôi đã từng đảo ngược vị trí của bạn khoảng 8 năm trước khi SVN là công nghệ khá mới mẻ. Tôi là một nhà phát triển cấp cao và được yêu cầu / sửa lỗi để cài đặt SVN bởi một nhà phát triển cơ sở (thực ra anh ta hỗ trợ CNTT chính xác hơn một nhà phát triển). Tôi đã có một tâm trí cởi mở mặc dù những nghi ngờ ban đầu của tôi về khối lượng công việc tăng lên, sự phức tạp không cần thiết, vv ... và sau đó trở thành một fan hâm mộ lớn của nó.

Theo quan điểm của tôi, từ những gì bạn đã mô tả vấn đề này chắc chắn xuất phát từ tính cách nhóm - sự bướng bỉnh của anh ấy đang chứng tỏ sự cản trở đối với toàn bộ nhóm về vấn đề này. Bạn có thể tốt hơn là chỉ lùi lại vào thời điểm này và để áp lực từ phần còn lại của đội xây dựng một cách tự nhiên để buộc tay anh ấy.

Đây là khá nhiều trường hợp "thiếu thẩm quyền" và một người áp dụng sức mạnh của nỗi sợ hãi của chính mình để giữ mọi thứ "trong tầm kiểm soát"

Để giải quyết vấn đề này, hãy tìm ai đó đã truyền cảm hứng cho đồng đội của bạn hoặc người mà anh ấy tôn trọng và điều đó có thể giải thích sự cấp bách của việc sử dụng thứ gì đó như SVN. Bằng cách đó, nỗi sợ thay đổi của anh ấy và về cơ bản là "mất quyền" không phải là do chơi vì đó không phải là một thành viên trong nhóm nói cho anh ấy biết phải làm gì. Tôi sẽ không sử dụng ai đó như người quản lý để nói chuyện với anh chàng này bởi vì điều đó chỉ gây thêm áp lực và thậm chí có thể tạo ra một tình huống căng thẳng hơn cho chính bạn.

Gần đây tôi đã đọc Thay đổi kỹ thuật lái xe: Tại sao mọi người trong nhóm của bạn không hành động theo ý tưởng tốt và làm thế nào để thuyết phục họ nên , được xuất bản bởi các lập trình viên thực dụng. Cuốn sách này cung cấp nền tảng mà bạn nên biết trước khi cố gắng giới thiệu thay đổi kỹ thuật, một số mô hình ở những người phản đối hoặc từ chối thay đổi, các kỹ thuật để thực hiện các thay đổi và sau đó là các chiến lược để tối đa hóa việc sử dụng các kỹ thuật này và tất cả những người xung quanh bạn.

Dựa trên bài đăng của bạn, tôi muốn nói rằng đồng đội của bạn có thể rơi vào mô hình Không xác định hoặc kiểu Cynic, nhưng anh ta cũng có thể là một trường hợp của Thủy. Một số kỹ thuật được đề xuất để chống lại những kiểu người này là tích lũy kinh nghiệm trong môi trường mục tiêu để bạn có thể tìm thấy bất kỳ vấn đề nào và đưa ra câu trả lời cho các vấn đề mà người khác sẽ gặp phải trước khi chúng xảy ra, giải quyết vấn đề đúng, truyền tải thông điệp một cách say mê nhưng không quá nhiệt tình, hãy thể hiện các kỹ thuật bằng cách thể hiện rõ lợi thế của các phương pháp và công cụ của bạn và bán chúng một cách hữu cơ (nhưng không tạo ra vấn đề chỉ để giải quyết chúng), và công khai và mua từ các thành viên còn lại trong nhóm của bạn. Tuy nhiên, nếu anh ấy thủy chung, có '

Cuối cùng, sau đó bạn bắt đầu sử dụng các kỹ thuật này, bạn cần một chiến lược tổng thể. Điều quan trọng là không để những người chủ động thù địch hoặc phi lý làm bạn chậm lại - bỏ qua họ. Thay vào đó, hãy tìm những người mà bạn có thể chứng minh và thuyết phục rằng bạn có cách tốt hơn và áp dụng các kỹ thuật phù hợp dựa trên họ với tư cách cá nhân. Một khi nhiều người nhìn thấy những cải tiến mà kiến ​​thức của bạn cung cấp, hãy sử dụng chúng để tiếp tục thuyết phục người khác. Cuối cùng, sử dụng nỗ lực cơ sở này để thuyết phục ban quản lý rằng có một cách tốt hơn, nhưng hãy chắc chắn đưa nó vào những điều mà họ có thể hiểu (thời gian, tiền bạc, chất lượng).

Đừng cố gắng "thuyết phục" anh chàng này bất cứ điều gì. Mọi người (ngay cả lập trình viên) sẽ không phản hồi hoặc tôn trọng các lập luận hợp lý / hợp lý từ người mà họ coi là đàn em đối với họ. Vì vậy, đừng lãng phí hơi thở của bạn. Thay vào đó, hãy xây dựng một mức độ tin tưởng với người này. Người này sẽ lắng nghe những gì bạn nói chỉ khi anh ấy cởi mở với nó.

Trong khi đó, bạn có vấn đề thực sự:

1. Anh chàng kiểm tra tệp .project của mình vào repo: chỉ cần bỏ qua nó. bạn không phải sửa đổi tệp, không ai khác trong nhóm biết rõ hơn. Để nó đi. Nếu nó mang lại cho "thành viên cấp cao" của bạn cảm giác ấm áp, hạnh phúc như một tấm mền bảo mật thì vậy thôi.
2. Có một ngân sách nhận thức về không gian đĩa: Đây là lý do ông Senior ra lệnh 1 cam kết một ngày. Là sự thiếu hụt trên không gian thực hay nhận thức? Ngay cả khi nó chỉ là nhận thức, có thể có điều gì đó bạn có thể làm để thay đổi nhận thức đó. Điều đó nên được xử lý ngay lập tức - nếu bạn chủ động, nó cũng giúp tạo dựng niềm tin.

Tôi cũng có thể nói thêm rằng anh chàng này sẽ sẵn sàng áp dụng các thực tiễn SVN tốt hơn khi anh ta nghĩ rằng đó là ý tưởng của mình. Điều đó sẽ phần nào suy nghĩ về phía bạn, và anh ta có thể sẽ lấy tín dụng để thiết lập các thực tiễn tốt hơn - nhưng bạn ổn với điều đó.