Bạn nên làm gì nếu đàn em không chấp nhận đề nghị của bạn? [đóng cửa]


30

Tôi đang lãnh đạo một nhóm gồm 3-4 nhà phát triển cơ sở. Công việc của tôi - bên cạnh việc viết mã-- là cung cấp sự giám sát và hướng dẫn cho các đàn em.

Nhưng, tôi hoàn toàn hiểu được các nhà phát triển trân trọng sự tự chủ trong công việc của họ như thế nào và tôi không muốn phá hủy động lực nội tại của họ bằng cách cho họ ăn bằng suy nghĩ và thuật toán của tôi; Tôi muốn họ khám phá vấn đề theo cách riêng của họ, và tự suy nghĩ về nó và chỉ đến với tôi khi họ thực sự phải đối mặt với những vấn đề không thể vượt qua.

Khi họ đến với tôi, đôi khi tôi sẽ phải đề xuất một thuật toán hoàn toàn khác để giải quyết vấn đề vì thuật toán của họ không đủ mạnh (hãy nhớ rằng, tôi là người cao cấp và tôi đã nhìn thấy nhiều hơn họ). Tất nhiên tôi sẽ giải thích điều này một cách tử tế để không làm tổn thương cảm xúc của họ, và tôi sẽ nhẹ nhàng phác thảo cách giải pháp của tôi vượt trội hơn nhiều so với họ, không có âm điệu lên án hay lên án.

Nhưng đôi khi, họ đôi khi miễn cưỡng chấp nhận đề nghị của tôi, một phần vì họ đã đầu tư rất nhiều vào thuật toán của riêng họ, hoặc một phần vì sợ rằng việc sử dụng một phương pháp mới sẽ kéo theo thời gian học tập nhiều hơn và khiến họ xuất hiện với ban quản lý như thể họ không đi đâu cả Nhưng sâu thẳm trong tim tôi tôi biết rất rõ rằng thuật toán của tôi tốt hơn nhiều so với thuật toán của họ và họ chỉ nên áp dụng nó.

Tôi nên làm gì nếu họ không chấp nhận đề nghị của tôi? Tôi có nên yêu cầu họ đi theo con đường của tôi không, hay tôi chỉ nên để họ đập đầu vào tường nhiều lần nữa và chờ họ quay lại với tôi? Làm cái trước khiến tôi trở thành một kẻ độc tài, nhưng làm cái sau sẽ khiến chúng ta tốn thời gian phát triển quý giá và phải chịu chi phí sửa lỗi. Tôi thực sự rơi vào tình trạng khó xử ở đây.


9
Lập trình viên rất kiêu ngạo. Bạn có tự tin rằng giải pháp của bạn là vượt trội bởi vì nó là hoặc bởi vì bạn đã phát triển nó? Nếu bạn đã thực sự tốt nhất lý do các nhà phát triển cơ sở cho phương pháp của họ thì có lẽ nó sẽ trở thành một kịch bản "làm theo cách của tôi".
Giàn khoan

6
Xin chào Graviton, các vấn đề chung về nơi làm việc như thế này không có chủ đề ở đây: bạn có thể quan tâm đến một đề xuất trang web sắp tới, Chuyên gia vấn đề , trong đó các câu hỏi chuyên môn chung như vậy sẽ là chủ đề.

27
@MarkTrapp: Bạn có muốn mở rộng lý do của mình tại sao bạn coi lãnh đạo nhóm lập trình viên là lạc đề không? Có lẽ thay vì đóng câu hỏi này nếu có sự đồng thuận, có lẽ tốt hơn nên chuyển sang StackOverflow, hoặc bỏ ngỏ và di chuyển sau này sang các vấn đề Chuyên nghiệp khi có sẵn. IMHO, tôi thấy đây là một chủ đề được quan tâm với tư cách là một nhà phát triển phần mềm và được quản lý lập trình viên là duy nhất để lập trình, tôi coi đây là một chủ đề chắc chắn. Cảm ơn.
S.Robins

35
Tại sao các câu hỏi thú vị nhất được đóng lại?
ThomasX

11
Tôi có thể đồng ý đóng cái này nếu đó là câu hỏi về việc đơn giản là quản lý những người làm việc dưới quyền bạn, nhưng câu hỏi là về việc quản lý mã của những người làm việc dưới quyền bạn, điều mà tôi nghĩ là hoàn toàn tốt cho trang web này. Bình chọn để mở lại.
Rachel

Câu trả lời:


28

Giúp họ hiểu lý do tại sao họ nên thay đổi đề xuất của bạn. Và lắng nghe họ nếu họ có lý do chính đáng để không thay đổi. Có một cuộc thảo luận, và đi đến một thỏa thuận trên cơ sở những gì tốt nhất để làm.

Cách tiếp cận này rất quan trọng vì những lý do sau:

  • Bạn muốn họ thực hiện thay đổi vì lý do kinh doanh / kỹ thuật vững chắc. Điều quan trọng là phải rõ ràng về những điều này là gì (bất kỳ nhớ rằng bạn cũng có thể sai, vì vậy hãy khiêm tốn ....).
  • Bạn thực sự muốn truyền đạt lý do đằng sau đề xuất của bạn - theo cách đó, người nhận sẽ học cách tự giải quyết các vấn đề tương tự trong tương lai. Bạn cũng sẽ có một mối quan hệ tốt hơn nếu đàn em của bạn cảm thấy rằng họ đang học hỏi một số hiểu biết tốt từ bạn.
  • Bạn sẽ không được tôn trọng nếu bạn sử dụng thâm niên của mình và không thể chứng minh rằng bạn thực sự có lý do chính đáng.
  • Sếp của bạn có lẽ muốn tự tin rằng bạn đang sử dụng thời gian của đàn em một cách hiệu quả vào những thứ tạo ra giá trị thực sự, không chỉ là "làm theo cách của tôi" vì lợi ích của nó.

Nếu bạn thông minh, bạn cũng có thể khiến họ đi đến câu trả lời chỉ bằng cách đặt câu hỏi . Thực hiện đúng, đàn em của bạn sẽ tự đi đến kết luận chính xác (và do đó sẵn sàng hơn nhiều để thực hiện nó). Câu hỏi ví dụ:

  • Mã của bạn giả định truy cập vào cơ sở dữ liệu sản xuất. Làm thế nào chúng ta có thể thay đổi điều đó để nó vẫn hoạt động và có thể được JUnit kiểm tra chính xác trong môi trường phát triển bị ngắt kết nối? (câu trả lời tiềm năng: ah! chúng ta nên sử dụng tiêm phụ thuộc ....)
  • Điều gì sẽ xảy ra nếu kẻ tấn công cố tình gửi một số SQL được xây dựng khéo léo trong biểu mẫu nhập dữ liệu trực tuyến của bạn? (câu trả lời tiềm năng: ah! có lẽ chúng ta không nên xây dựng các câu lệnh SQL bằng cách ghép văn bản chưa được xác minh từ các tệp nội bộ)

EDIT : Nếu bạn thành công trong việc thuyết phục đàn em của mình rằng điều đúng đắn cần làm là làm theo đề xuất của bạn, nhưng họ vẫn miễn cưỡng hơn đây là một số lời khuyên bổ sung:

  • Khám phá lý do tại sao họ miễn cưỡng. Có thể là họ cần phải nhận ra một nhận thức cá nhân rằng sẽ không có vấn đề gì nếu bạn ném mã ra ngoài, miễn là bạn nhận được kết quả. Hoặc có thể là họ cảm thấy bị áp lực thời gian vì một số thời hạn. Bạn cần phải biết, nếu không bạn không thể giúp họ .....
  • Bạn có thể đưa ra quan điểm rằng họ có thể coi sự thay đổi là một cách để cải thiện kỹ năng tái cấu trúc của họ. Khi các kỹ năng tái cấu trúc là đủ tốt, bạn sẽ có thể tái mục đích ngay cả một cơ sở mã khá lớn và phức tạp tương đối nhanh chóng.
  • Bạn nên nhấn mạnh rằng mọi thứ sẽ nằm trong sự kiểm soát nguồn, vì vậy chúng luôn có thể trở lại phiên bản cũ nếu cần.

Tôi đã không thấy câu trả lời của bạn khi tôi bắt đầu gõ của tôi! Vì vậy, +1 từ tôi, bởi vì bạn đã nắm bắt được bản chất của những gì tôi đang viết, chỉ thanh lịch và ngắn gọn hơn. ;-)
S.Robins

@mikera, họ đồng ý rằng giải pháp của tôi tốt hơn, chỉ là, họ miễn cưỡng bỏ mã cũ và đầu tư vào mã mới.
Graviton

không có màu đen hoặc trắng. mọi người có thể được butthurt về những điều nhỏ. họ là con người, không phải robot. Vì vậy, mặc dù tôi đồng ý rằng điều quan trọng là truyền đạt rõ ràng và khách quan quan điểm của bạn, hãy cố gắng ngoại giao. có cả một tài liệu về cách thuyết phục mọi người. Bản thân nó là một khoa học. xem một en.wikipedia.org/wiki/How_to_Win_Friends_and_Influence_P
People

8

Tôi ghét thái độ hống hách của Đội trưởng cuối cùng của tôi nhưng tôn trọng anh ấy vì thực tế là anh ấy có kiến ​​thức kỹ thuật vượt trội và anh ấy đã dạy tôi rất nhiều mà không giảng cho tôi. Quan trọng nhất là anh ấy không bao giờ ép tôi đi với kế hoạch của anh ấy. Anh ta sẽ đóng vai người ủng hộ của Devil với kế hoạch của tôi, buộc tôi phải chứng minh rằng kế hoạch của tôi là hoàn hảo. Anh ta sẽ tìm kiếm những sơ hở và chờ đợi lời giải thích của tôi về lý do tại sao nó không phải là một lỗ hổng hoặc là một giải pháp ít tốn kém hơn. Anh ấy sẽ hỏi tôi nếu có bất kỳ giải pháp thay thế nào và đề xuất một số ý tưởng nếu tôi không có bất kỳ giải pháp nào. Tôi sẽ phải đánh giá ý tưởng của anh ấy và kế hoạch của anh ấy không tối ưu hoặc Nếu anh ấy tin rằng kế hoạch của tôi là đúng hoặc ít nhất là có tỷ lệ phần thưởng rủi ro tương tự như anh ấy, anh ấy sẽ đi trước. Nếu tôi thất bại với ý tưởng của mình, tôi sẽ phải thử giải pháp của anh ấy.

Phải có sự đánh đổi giữa tự do và thời hạn. Bạn không có cơ hội kéo dài thời hạn và bạn không thể để đàn em vi phạm. Bạn phải lịch sự nhưng kiên quyết với họ rằng một khi họ đã thử thuật toán của họ và không làm cho nó hoạt động, họ có nhiệm vụ lắng nghe bạn. Chứng minh bằng ví dụ rằng bạn biết công cụ của bạn. Nhưng, quan trọng không kém làm cho họ học, không dạy họ.


5

Nếu nó là một yêu cầu, sau đó lưu ý nó như vậy. Nếu đó chỉ là một gợi ý, như bạn lưu ý, thì họ nên được tự do làm điều đó. Một số câu hỏi tôi sẽ hỏi:

  • Bạn có thẩm quyền để thúc đẩy các giải pháp cụ thể?
  • Mức độ cho thẩm quyền đó là gì?
  • Có giải pháp xấu hay chỉ khác nhau?

Tôi chắc chắn bạn có thể hỏi thêm, nhưng hai điều đầu tiên tập trung vào thẩm quyền của bạn và cuối cùng là liệu vấn đề có thực sự đáng để đẩy hay không.

Câu trả lời sau đây có một số điểm bổ sung tuyệt vời và tôi sẽ nói thêm ở đây rằng bạn cần coi nó như một quá trình hợp tác, nơi bạn làm việc thông qua ít nhất một số trong số đó với "nhóm" của bạn thay vì chỉ đưa ra lệnh cho họ. Họ sẽ học khi họ giải quyết các vấn đề với bạn nhiều hơn là chỉ nói, "xem xét thực hiện theo cách này."


Tôi có thẩm quyền, nhưng tôi không thích sử dụng nó
Graviton

Chính quyền chắc chắn là một con dao hai lưỡi. Tốt hơn là có sự hỗ trợ của đồng nghiệp, hơn là sự oán giận của họ. Việc không tham gia vào một quy trình bao gồm thường dẫn đến những thách thức về thẩm quyền của bạn sau này và nếu bạn bị mắc kẹt với việc cần phải có người quản lý riêng để hỗ trợ cho việc khẳng định thẩm quyền của mình, thì bạn đã mất bất kỳ cơ hội nào để tham gia thành công trong tương lai với đàn em của bạn trong hoàn cảnh tương tự.
S.Robins

1
"Câu trả lời sau". Câu trả lời không thể được dự kiến ​​sẽ được hiển thị theo bất kỳ thứ tự cụ thể. Sử dụng liên kết "liên kết" để nhận URL mà bạn có thể tham khảo trong câu trả lời của mình.

4

Học tập thực sự chỉ xảy ra khi thất bại xảy ra, bởi vì thất bại là một động lực và cung cấp tín hiệu bộ nhớ để nhớ lại trong tương lai. Đây thực chất là những gì chúng ta gọi là kinh nghiệm, và kinh nghiệm tốt tại nơi làm việc sẽ đến từ việc thất bại và học hỏi từ những thất bại. Nếu đàn em của bạn có khả năng sửa mọi thứ ngay lần đầu tiên, thì chúng sẽ không học được gì, hoặc chúng sẽ không phải là đàn em.

Nếu bạn có quá nhiều đàn em làm rối tung mọi thứ, có lẽ công ty của bạn đã bố trí nhân viên không chính xác, với quá nhiều nhà phát triển cấp cơ sở, nơi những hạn chế về thời gian đòi hỏi những người có kinh nghiệm tốt hơn để giảm thiểu rủi ro của bạn, thậm chí sau đó bạn có thể gặp vấn đề và chậm trễ, vì các nhà phát triển cấp cao mắc lỗi để học hỏi là tốt.

Đàn em của bạn sẽ cần phải học hỏi và tích lũy kinh nghiệm để có thể đối phó trong một môi trường có thời hạn chặt chẽ. Là một trưởng nhóm, công việc của bạn là làm gương và truyền cảm hứng cho đàn em làm việc hiệu quả, tuy nhiên thực tế là bạn phải gác lại những lo ngại về niềm tự hào cá nhân và mối quan tâm cho lịch trình chặt chẽ của bạn nếu bạn muốn đàn em của mình thực sự học được điều gì đó và do đó bạn cần cho phép chúng thất bại. Do đó, công việc của bạn là thực hiện cuộc gọi. Đôi khi bạn cần cung cấp cho đàn em không gian để thất bại, và sau đó đưa chúng kiên nhẫn thông qua quy trình xem xét để cho chúng thấy nơi chúng có thể cải thiện ý tưởng của mình. Vào những lúc khác, bạn cần phải đặt chân xuống, nhưng hãy làm điều đó theo cách cho phép bạn thể hiện rằng làm như vậy là không cần thiết thực sự, điều đó không phản ánh kém về khả năng của bạn.

Đối với vấn đề thời hạn chặt chẽ, đây là lúc bạn cần lên lịch và phân bổ công việc theo các điểm mạnh và điểm yếu tương đối trong nhóm của bạn. Cuối cùng, buck dừng lại với bạn. Khi bạn phụ trách người khác, bạn không ở đó để làm bạn với mọi người, bạn sẽ ở đó để hoàn thành công việc khó khăn trong hoàn cảnh khó khăn. Làm thế nào bạn giữ mọi người đứng về phía bạn để nói chuyện với mọi người thông qua các mối quan tâm và vấn đề của bạn, đưa ra một trường hợp hợp lý cho lý do tại sao bạn cần các thành viên trong nhóm của mình làm điều gì đó theo một cách cụ thể.

Từ kinh nghiệm cá nhân của riêng tôi, bạn cần dành một khoảng thời gian nhất định với đàn em để thảo luận về điểm mạnh và điểm yếu của cả hai ý tưởng và sau đó hợp tác tìm ra giải pháp tốt nhất sẽ giải quyết vấn đề trong tay - thậm chí có nguy cơ cho phép bản thân được chứng minh là sai - và sau đó tiến về phía trước. Nếu cả hai bạn không thể đạt được sự đồng thuận vào cuối thời gian được phân bổ, thì tại thời điểm đó, bạn cần kết thúc cuộc họp với một bản tóm tắt có tính đến các mối quan tâm được thảo luận và lưu ý rằng không đạt được sự đồng thuận. Không phụ thuộc vào kết quả của cuộc họp của bạn, bạn cảm ơn junior của bạn cho thời gian chi tiêu, và chỉ ra rằng bạn sẽ trở lại với quyết định của bạntrong thời gian ngắn Sau khi xem xét cẩn thận cuộc thảo luận của bạn, bạn sẽ có tùy chọn phân bổ thêm thời gian để thảo luận thêm hoặc hướng dẫn cho thiếu niên tiếp tục với bất kỳ kế hoạch nào bạn đã giải quyết theo kết quả của cuộc họp.

Đúng vậy, thời gian rất quý giá, tuy nhiên khi bạn chọn tiếp nhận đàn em, bạn cần chấp nhận rằng bạn đang có trách nhiệm đầu tư và nuôi dưỡng sự phát triển chuyên nghiệp của họ, và bạn cần phải chấp nhận điều đó trong một thời gian ít nhất là tốn thời gian của bạn


4

Tôi sẽ hỏi nếu bạn thực sự trình bày đề xuất của bạn theo cách không hạ thấp. Khi bạn đang sử dụng các cụm từ như:

giải pháp của tôi vượt trội hơn họ

sâu thẳm trong tim tôi tôi biết rất rõ rằng thuật toán của tôi tốt hơn nhiều so với thuật toán của họ và họ chỉ nên áp dụng nó.

nó khiến tôi nghĩ rằng bạn có thể bắt gặp một thái độ "cách của tôi là vượt trội". Không ai thích được đưa ra thái độ đó. Khi tôi nhận được nó trong quá khứ, tôi đã chủ động sử dụng một thuật toán khác để chứng minh người đó sai. Nó có thể là đàn em của bạn đang làm như vậy.

Một cách tốt hơn nên là ngồi xuống với người đó và thảo luận về thuật toán của họ. Chỉ ra lý do tại sao bạn không nghĩ rằng nó sẽ hoạt động và lắng nghe câu trả lời mà họ dành cho bạn với một tâm trí cởi mở. Xem nếu thuật toán của họ có thể được sửa đổi để hoạt động chính xác.

Nếu những gì bạn thiếu niên chắc chắn sẽ không hoạt động, thì hãy giải thích cho họ tại sao nó không hoạt động. Những phần nào không chính xác hoặc sẽ liên quan đến việc viết lại sau này hoặc không phù hợp với mô hình kinh doanh. Đảm bảo rằng họ có một sự hiểu biết tốt về lý do của bạn. Sau đó giải thích thuật toán của bạn cho họ, chỉ ra các phần mà nó sẽ hoạt động và mã của họ sẽ thất bại.


3

Trước hết, bạn có biết lý do thực sự tại sao đàn em của bạn không chấp nhận đề nghị của bạn?

Đôi khi bạn biết, một thiếu niên thực sự có thể viết một cái gì đó tốt hơn so với đàn anh của mình do những quan điểm mới hơn và một nền giáo dục CS cập nhật hơn. Mặc dù là một tiền bối, bạn có thể đã thấy nhiều ví dụ thực tế hơn. Nhưng một cái bẫy tồi tệ mà tôi thường thấy người cao niên của mình đôi khi rơi vào là quên rằng những thực tiễn tốt nhất có thể thay đổi theo thời gian. Tôi chắc chắn rằng điều này không áp dụng cho bạn tuy nhiên vì bạn đã tự cập nhật trên các trang như thế này. ;)

Tôi sẽ đề nghị thử tiếp cận với đàn em của bạn mà không có bất kỳ (hoặc ít) "hào quang" của một đàn anh, cố gắng nói chuyện theo cấp độ với họ, thể hiện sự tò mò trong mã họ đã viết. Đặt câu hỏi, nghe câu trả lời của họ. Đừng hỏi theo cách buộc tội như:

"Mã của bạn khá không linh hoạt, bạn cần thay đổi nó thành ..."

thay vì hỏi

"Tôi chỉ tự hỏi, điều gì sẽ xảy ra nếu ai đó ... quản lý mã của bạn xử lý việc đó? ... Tôi nghĩ rằng một mô hình chiến lược có thể giúp ích ở đây. Bạn nghĩ gì?"

Điều này tôi tin rằng sẽ giúp bạn tham gia vào các cuộc trò chuyện lành mạnh hơn với họ hơn là như một giáo sư / giảng viên nhìn xuống họ như biết tất cả. Nó cũng sẽ giúp bạn thấy rõ hơn lý lẽ và quan điểm của họ.


2

Bạn có kiểm soát truy cập đẩy vào kho lưu trữ?

Trong nguồn mở, truy cập đẩy luôn được kiểm soát bởi một người gác cổng chịu trách nhiệm thực thi chất lượng. Nếu bạn đang tích cực theo dõi các cam kết mà họ đang thúc đẩy, bạn nên nhận thức sâu sắc về nơi họ có thể cải thiện.

Do họ có thể hack hoặc cải thiện mã của bạn. Nếu họ có cơ hội thấy những người bên trong về cách mã của bạn hoạt động, họ có thể học cách thích nghi với phong cách của bạn tốt hơn. Nếu bạn đang đưa ra đề xuất của mình mà không chấp nhận đề xuất với một tâm trí cởi mở thì họ sẽ ít có khuynh hướng lắng nghe ý kiến ​​của bạn.

Có một số trường hợp không có câu trả lời đúng (chẳng hạn như tùy chọn kiểu mã hóa). Trong trường hợp đó, hãy thử thiết lập (hoặc thực thi) chính sách toàn công ty để họ hiểu rằng phong cách của mã phải được hướng đến để phù hợp với cơ sở mã chính. Sử dụng một hướng dẫn kiểu đã được thiết lập (như hướng dẫn kiểu microsofts cho C #) là cách tốt nhất để sử dụng, đặc biệt là đối với các nhà phát triển mới trong nhóm.

Nếu bạn đang đưa ra những tuyên bố về các kỹ thuật mã hóa của họ, thì rất có thể bạn không hoàn toàn hiểu lý do đằng sau những lựa chọn của họ. Chỉ cần giọng điệu của câu hỏi của bạn làm cho bạn có vẻ kiêu ngạo. Bạn đạt được / hy sinh điều gì bằng cách thúc đẩy cách tiếp cận của bạn đối với các nhà phát triển trẻ hơn?

Câu hỏi quan trọng bạn cần tự hỏi mình là, các đề xuất của bạn có hướng đến việc duy trì / cải thiện chất lượng của cơ sở mã hoặc để khẳng định sự thống trị / ưu việt của bạn so với các đồng nghiệp không? Cái trước là kiểm soát chất lượng đơn giản và có thể được biện minh như vậy, thang là bất lợi cho nhóm năng động cho dù quyền của bạn có hay không.

Dù bằng cách nào, nếu bạn muốn đẩy giải pháp của mình lên các đồng nghiệp, bạn nên có bằng chứng cụ thể rằng nó thực sự vượt trội. Hiệu suất tăng đáng kể phải đủ dễ dàng để cải thiện, bất cứ điều gì ít hơn đều không đáng để nỗ lực (ngoại trừ các ứng dụng quan trọng về hiệu suất). Buộc công việc của bạn lên người khác để biện minh cho ý thức vượt trội cá nhân của bạn sẽ kết thúc bằng việc bạn bị chỉ trích là 'ông già khó chịu'.

Lưu ý: Những lập trình viên giỏi nhất và tài năng nhất mà tôi đã gặp trong nhiều năm qua dường như luôn là những người sẵn sàng dừng lại và giải thích câu chuyện đằng sau đằng sau nơi họ bắt nguồn từ cách tiếp cận của họ.


2

Chà điều này có vẻ thú vị và rất tự nhiên với các lập trình viên trẻ rất gắn bó với mã họ đã viết, có lẽ họ đã dành khá nhiều thời gian để đến cùng hoặc họ đã chọn nó từ một trang web tốt (thật vậy, Hey Jonet đã viết điều này Đàn ông ! !).

Tuy nhiên, chuỗi cơ bản được đính kèm ở đây có đính kèm với mã là nơi bạn cần tập trung và tôi nghĩ rằng bạn sẽ cần phải nỗ lực đáng kể để khiến họ hiểu rằng việc thực hiện và kết quả mong đợi có ý nghĩa quan trọng hơn là tên của họ khắc trên các kho nguồn để đẩy trong mã này. Bạn sẽ phải vẽ các dòng như tại sao mã của bạn tốt hơn và cũng tốt về mặt duy trì nó cho các công việc trong tương lai.

Hãy xem xét rằng một vài thất bại là nổi bật (cần một vài vết thương lòng cho bất kỳ sự gắn bó nào) nhưng với nỗ lực dần dần tôi nghĩ rằng họ sẽ đi xung quanh và sẽ có thể đánh giá cao những nỗ lực của bạn tốt hơn. Một chút thời gian và một vài thất bại là những gì tôi nghĩ bạn sẽ cần. Buộc họ phải theo cách khác là làm tròn vài câu chuyện thành công và sau đó là ngày tận thế và nổi dậy.


2

Mỗi người có một phong cách khác nhau. Nếu bạn tìm thấy 10 người khác nhau và đưa ra một vấn đề không cần thiết, họ sẽ cung cấp cho bạn 10 cách tiếp cận khác nhau bằng cách sử dụng 10 kiểu "tiêu chuẩn mã hóa" khác nhau.

Vấn đề là: chọn những thứ quan trọng. Nếu một thứ gì đó được trình bày cho bạn bởi một thiếu niên không tạo ra giải pháp chính xác, thì nó có hiệu quả không (thứ tự cường độ +1, không phải là chỉ dẫn ở đây hay ở đó), hoặc tạo ra lỗ hổng bảo mật, sau đó giải thích vấn đề của bạn và tại sao. Nếu đó là một bình luận "Tôi sẽ làm điều này", thì thật tuyệt, bạn đã thực hiện "điều đó" và cô ấy đã làm "điều gì khác" nhưng vấn đề vẫn được giải quyết đầy đủ (xem các điểm trên). Chuyển sang tính năng tiếp theo hoặc sửa chữa.

Một phần của việc học để trở thành một nhà lãnh đạo giỏi là học cách nhận ra điều gì thực sự quan trọng và điều gì thực sự không. Thêm vào đó, bạn tự loại bỏ mình như một nút cổ chai tiềm năng đối với hiệu suất của nhóm nếu họ phải kiểm tra mọi thứ thông qua bạn.

EDIT: đảm bảo đề xuất của bạn là chính hãng và không yêu cầu che giấu. Một gợi ý chỉ là - một gợi ý mà ai đó có thể theo dõi hay không. Nếu đó là một yêu cầu, hãy nêu nó như vậy.


2

Như một số người khác đã chỉ ra, nếu bạn thực sự chỉ chứng minh cho các nhà phát triển cơ sở bằng các đề xuất và họ thực hiện theo cách đó thì bạn thực sự không có nhiều cơ sở để làm phiền họ nếu họ không tuân theo vì họ có thể không thấy nhiều lý do để làm như vậy. Tương tự như vậy, bạn thực sự không thể đánh cược họ vì đã không làm theo đề xuất của bạn bởi vì họ không thực sự định hướng để thực hiện mọi thứ theo một cách nhất định.

Liên quan đến việc cố gắng để các nhà phát triển cơ sở làm những việc như bạn muốn làm:

  • Kiểm soát thuật ngữ của bạn, đưa ra một đề xuất không giống như đưa ra một đề xuất mà chắc chắn không giống như cung cấp hướng . Sử dụng thuật ngữ phù hợp để đưa ra quan điểm của bạn và nếu bạn nghĩ rằng cách làm của bạn là một cách tốt hơn để làm điều đó, hãy nói với họ rằng đó là khuyến nghị của bạn để làm như vậy. Tương tự như vậy, nếu hoàn toàn quan trọng rằng mọi việc được thực hiện theo một cách nhất định (nghĩa là không thể chịu được thời gian trễ), thì hãy thẳng thắn và đưa ra hướng cho họ cách thực hiện.
  • Các nhà phát triển cơ sở vẫn đang trải qua quá trình học tập bất kể bạn đang thực hiện mọi thứ như thế nào, luôn cung cấp một số lý do đằng sau những gì bạn đang nói với họ trừ khi có một lý do cụ thể mà bạn không thể. Ngay cả trong trường hợp đó, hầu hết mọi người sẽ hiểu nếu bạn nói điều gì đó dọc theo dòng chữ "Nó phải được thực hiện theo cách này, tôi không quan tâm đến nó nhưng quyết định đã được đưa ra." họ có xu hướng khá hợp lý.
  • Nếu nó thực sự chỉ là một gợi ý thì hãy chắc chắn rằng ý tưởng của bạn thực sự tốt hơn so với cách nó đã làm. Nếu bạn không nghĩ đó là trường hợp thì hãy ngồi xuống với nhà phát triển và thực hiện đánh giá mã và khái niệm để họ có thể biện minh cho giải pháp của họ. Có thể là một khi họ bắt đầu giải thích nó cho người khác - và bạn hỏi đúng câu hỏi - họ sẽ thấy một cách tốt hơn và muốn tự mình giải mã mọi thứ.
  • Đừng ngụy biện cho các chi tiết nếu giải pháp của họ giống với những gì bạn đề xuất ban đầu, có thể là họ đã đưa những gì bạn nói với họ vào tài khoản và làm mọi thứ hơi khác hoặc thay đổi khái niệm ban đầu dựa trên đề xuất của bạn.

2

Đây là một giới thiệu hoàn hảo để thử nghiệm đơn vị. Nếu các nhà phát triển cơ sở của bạn có một giải pháp, nó sẽ có thể kiểm tra được. Có họ sản xuất một bài kiểm tra đơn vị để nhấn mạnh mã của họ. Sau đó xem lại bài kiểm tra đơn vị . Nếu bạn có thể hiển thị các lỗ hổng trong thử nghiệm, thì thật dễ dàng để họ chạy lại thử nghiệm và thấy giải pháp của họ bị phá vỡ dưới áp lực.

Điều đó cho phép bạn chỉ cho họ lý do tại sao giải pháp của bạn tốt hơn, cung cấp cho bạn một bài kiểm tra đơn vị mà bạn có thể sử dụng lại khi mã thay đổi và cung cấp cho các nhà phát triển cơ sở một kinh nghiệm học tập có giá trị. Và ai biết được, bạn có thể thấy rằng giải pháp của họ là tốt.


2

Tại một số điểm bạn phải chịu trách nhiệm. Bạn có vẻ như bạn đang nỗ lực để cho họ nói lên ý kiến ​​của mình. Đề xuất của bạn có thể không hoàn hảo. Các nhà phát triển khác có thể không hiểu / đồng ý với bạn. Có lẽ họ không đồng ý với nhau. Nếu bạn phụ trách, đó không phải là một nền dân chủ. Họ biết rằng khi họ nhận công việc.

Nếu không có tình huống họ phải theo dõi bạn, bạn không xứng đáng và không phục vụ mục đích như ông chủ của họ. Thay đổi vai trò của bạn trong nhóm thành tài nguyên và không phải là cơ quan nếu bạn không có kế hoạch sử dụng nó. Tại một số thời điểm, bạn phải gửi mã tốt nhất bạn có thể theo các ràng buộc về thời gian có sẵn và không thể tranh luận, nghiên cứu và tranh luận lại mỗi dòng mã cho đến hết thời gian.

Đưa ra mệnh lệnh. Sống với hậu quả. Học hỏi kinh nghiệm Tôn trọng là một con đường hai chiều. Bạn đang chứng minh điều đó và họ thì không.


Tôi đã nâng cao điều này một triệu lần.
HLGEM
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.