Làm thế nào để lãnh đạo một dự án phát triển mà không có chuyên môn kỹ thuật

Tôi đã là một nhà phát triển thực hành cho toàn bộ sự nghiệp của mình và thích làm việc với mã. Tôi luôn bực bội với người lãnh đạo nhóm, người có ít hoặc không có chuyên môn về một công nghệ cụ thể và vẫn khăng khăng đòi thực hiện.

Bây giờ tôi thấy mình ở phía bên kia của kính nhìn. Tôi là nhà phát triển chính của một khách hàng béo được triển khai trong C #, tuy nhiên chuyên môn của tôi là xây dựng các ứng dụng web Java. Mặc dù tôi biết rằng tôi có thể tận dụng các mẫu thiết kế và mô hình OO bằng bất kỳ ngôn ngữ nào, tôi bị mất khi nói đến các tiêu chuẩn mã hóa, các công cụ vòng đời dự án và các quy trình phát hành / phân phối. Tôi không có nghi ngờ rằng tôi có thể nhận được những điều cơ bản trong vòng một hoặc hai tháng, nhưng có một số kinh nghiệm nhất định người ta chỉ có thể thu thập với thời gian.

Tôi nên làm gì và làm thế nào để tránh trở thành người dẫn đầu dự án mà tôi ghét khi tôi đang phát triển?

Thành thật mà nói, bạn có bao nhiêu kinh nghiệm với công nghệ, lời khuyên của tôi là như nhau: Đừng thực thi các quyết định công nghệ đối với những người sẽ phải sống với họ trong khi bạn bận quản lý.

Thành thật với chính mình. Tôi cá là lý do bạn ghét những người quản lý trước đó không phải vì họ không có cơ sở tri thức để từ đó đưa ra quyết định, đó là vì họ thi hành quyết định và không bao giờ giải quyết hậu quả.

Điều đó áp dụng cho dù bạn chưa bao giờ chạm vào .NET trước đây hay bạn là nhà phát triển chuyên gia nhất trong nhóm. Công việc của bạn bây giờ là quản lý, không đưa ra quyết định kỹ thuật.

Quản lý có thể, tùy thuộc vào mức độ kỹ năng của nhà phát triển của bạn, có nghĩa là tư vấn cho họ khi họ yêu cầu. "Bạn đã nhìn vào Spring.NET chưa?" (lưu ý thiếu hướng dẫn ở đó) là một điều hoàn toàn tốt để nói. Ngoài ra, "Google xung quanh, hãy xem phần còn lại của thế giới đang làm gì, chúng tôi không phải là người đầu tiên đối mặt với vấn đề này."

Trong một số khía cạnh, là một nhà phát triển Java có kinh nghiệm, bạn có thể ở vị trí tốt hơn hầu hết cho việc này. Hầu hết các khung và công nghệ Java có một tương đương tương tự trong .NET. Vì vậy, bạn không cần phải nói "Đây là thứ tốt nhất để sử dụng", bạn có thể nói "Tôi đã sử dụng cái này trong Java, bạn có biết tương đương .NET không?"

Cũng khuyến khích rất nhiều cuộc trò chuyện trong nhóm. Sắp xếp các cuộc họp thảo luận kỹ thuật hàng tuần. Tất cả những gì bạn cần là thông tin, cuối cùng; bạn cần biết họ đã đưa ra quyết định gì và tại sao. Bạn không cần phải đưa ra quyết định cho nhóm.

Tôi đã có một số nhà quản lý / trưởng nhóm rất giỏi, những người biết rất ít về công nghệ và một số người quản lý tồi nhất của tôi là những người nghĩ rằng họ biết tất cả mọi thứ.

Để trở thành một nhà lãnh đạo, nếu bạn có những người có năng lực hợp lý, điều chính yếu là có thể phán đoán năng lực và phán đoán của họ, và đưa ra từng vĩ độ như anh ta có thể xử lý, trong khi vẫn giữ "vịt hoang" trong nhiệm vụ và "hầu như không các đối thủ "bận rộn với các hoạt động" an toàn "nhưng hiệu quả. Hãy chắc chắn rằng mọi người đều diễu hành đến cùng một tay trống.

Thách thức lớn hơn của bạn có khả năng giữ cho quản lý cấp trên bay. Họ sẽ muốn báo cáo và lịch trình và đánh dấu, và bạn cần tìm ra những gì họ muốn và làm thế nào để giả mạo chúng hợp lý. (Chà, không chính xác là "giả", nhưng tạo ra tài liệu thỏa mãn chúng mà không làm mất thời gian của bạn hoặc thời gian của nhóm của bạn.)

Bạn không được chọn cho các kỹ năng mã hóa C # của mình và trừ khi bạn sẽ viết mã ngay từ đầu, điều đó không quan trọng cho dù bạn có biết C # hay không. Bạn cần bắt đầu suy nghĩ ở cấp độ cao hơn:

• Những kỹ năng nào mà mỗi người trong nhóm của bạn mang đến cho bàn?
• Những thành phần nào là quan trọng cho sự thành công của dự án?
• Bạn phải sản xuất gì ngoài mã thực tế? (Bài kiểm tra? Tài liệu?)
• Làm thế nào bạn sẽ thu thập các yêu cầu, nếu bạn chưa có?
• Làm thế nào bạn và nhóm của bạn sẽ tiếp cận quá trình thiết kế?
• Bạn biết rằng có một tiêu chuẩn mã hóa là quan trọng, nhưng bạn có thể dựa vào nhóm của mình để tìm ra chính xác tiêu chuẩn mà họ muốn tuân theo.
• Làm thế nào bạn có thể phát hiện vấn đề sớm?

Một số trong những điều này có thể đi qua lãnh thổ quản lý dự án, nhưng với tư cách là nhà phát triển chính, bạn sẽ làm việc chặt chẽ với người quản lý dự án về những vấn đề này và các vấn đề khác.

Bằng mọi cách, hãy học cách làm việc hiệu quả trong C # nhanh nhất có thể. Chỉ cần nhớ rằng vai trò của bạn là nhìn qua cú pháp và các chi tiết khung và nhìn vào bức tranh lớn hơn.

Hãy tiếp cận. Bắt đầu bằng cách lấy cho mình một đoạn mồi C # đơn giản và viết một số mã. Hãy thử một vài điều cơ bản mà bạn sẽ biết cách bịt mắt bằng ngôn ngữ khác.

Đọc lên về phong cách lập trình và quy ước. Dù sao thì bạn cũng nên tìm thấy phần này trong phần mồi của mình, nhưng bạn cũng có thể sử dụng các sản phẩm như StyleCop và Resharper để thực thi các quy tắc kiểu mà bạn không quen. Điều này sẽ đào tạo bạn một cách hiệu quả rất nhanh để thực hiện mọi thứ theo cách thường được chấp nhận để tránh các vấn đề biên dịch phần mềm của bạn.

Chỉ cần là chính bạn, và áp dụng kiến ​​thức thiết kế bạn đã có. Những điều cơ bản là giống nhau bất kể ngôn ngữ. Trường hợp sẽ có sự khác biệt về cách các ngôn ngữ khác nhau về cấu trúc sẽ khá tối thiểu và phần lớn sẽ trở nên rõ ràng rất nhanh khi bạn kết hợp một hoặc hai ứng dụng thử nghiệm.

Nếu có những điều rõ ràng bạn không biết, hãy đến. Nhóm của bạn sẽ tôn trọng sự trung thực hơn là chỉ đơn giản là mặc cả mà không có manh mối. Đưa ra quyết định sáng suốt và hợp lý, và luôn dành một vài phút để xem xét phản ứng của bạn. Bạn sẽ cần phải quyết đoán mà không cố gắng thống trị, và bạn không thể để sự thiếu hiểu biết của mình trong một lĩnh vực dường như là một sự phản ánh về khả năng lãnh đạo nhóm của bạn. Lãnh đạo ngụ ý cố vấn, nhưng cố vấn không có nghĩa là bạn cũng không thể thể hiện sự sẵn sàng học hỏi điều gì đó mới.

Nếu bạn nghĩ như vậy và thực sự lo lắng về điều đó, bạn đã tránh được rủi ro để trở thành loại người dẫn đầu dự án này. Đó là một loại tính cách hoàn toàn khác, những người dám đưa ra quyết định mà không có kiến ​​thức đúng đắn. Chỉ cần giữ một tâm trí cởi mở với những gì đồng nghiệp của bạn nói với bạn và tạo ra và khuyến khích văn hóa đối thoại và trao đổi thông tin trong nhóm của bạn.

Có vẻ như đó là một vài vấn đề tại đây.

Công nghệ được sử dụng trong dự án bạn đang lãnh đạo và quá trình chi phối sự phát triển của dự án đó.

Bạn có phải là trưởng nhóm, hay một nhà phát triển chính? Một nhà phát triển chính cũng làm khá nhiều công việc thiết kế và phát triển. Vì vậy, cách duy nhất để giải quyết vấn đề này là tìm hiểu công nghệ mới .

Nếu bạn đang thực sự lãnh đạo nhóm, bạn sẽ cần phải tin tưởng vào nhóm và để họ điều khiển phần lớn các hướng kỹ thuật của dự án. Tất nhiên, về mặt khái niệm, bạn sẽ có thể giữ cho tay lái đó đi đúng hướng.

Các quy trình chi phối sự phát triển của dự án nên được áp dụng . Nó chỉ là vấn đề đọc lên chúng, hiểu chúng và thực hiện chúng.

Nếu không, hãy thương lượng với sếp của bạn để có một người cố vấn giúp bạn đưa ra một số quy trình phát triển. Điều này khá quan trọng. Nó sẽ thất bại khá nhanh nếu quá trình không được thực hiện, và là đặc biệt.

Chúc may mắn!

Cơ hội đến một lần trong một thời gian .. Hãy nắm lấy nó .. Tôi sẽ nói, hãy cố gắng học những điều cơ bản của C #. Nhận một số hướng dẫn từ trực tuyến, cố gắng làm việc trên nó. ban đầu sẽ rất khó để học khái niệm mới, sau này khi nhiệm vụ đầu tiên của bạn hoàn thành, bạn sẽ có chút tự tin về nó.

Suy nghĩ tích cực, Cố gắng thực hiện nhiệm vụ khó khăn, Gỡ lỗi mã của riêng bạn và chắc chắn bạn sẽ thành thạo trong đó ..

Đừng đánh mất cơ hội của bạn.

Tôi nghĩ rằng nếu bạn có một nhóm các nhà phát triển .Net tốt, có rất nhiều kiến ​​thức trong nhóm mà có lẽ bạn cần phải khai thác để bắt đầu. Có rất nhiều điểm tương đồng giữa Java và .Net mà những gì bạn đã biết thực sự có thể áp dụng trực tiếp ít hơn. Điều quan trọng là biết điều gì là quan trọng để có được đúng cho dự án này và những rủi ro liên quan. Giao tiếp với nhóm của bạn thường xuyên khi cần thiết. Thực hành kỹ thuật phần mềm phát triển trong suốt một dự án nên có thể khó có "thực hành tốt nhất" từ rất sớm trong dự án.

Tôi đã có mặt trái của trải nghiệm của bạn khi tôi được trao cho một nhóm học sinh rất tốt, những người không thuộc lĩnh vực liên quan đến phần mềm. Trong khi tôi có tất cả lý do để quy định những gì cần phải làm (tôi đã được tuyển dụng), thay vào đó tôi tìm kiếm thực hành để khiến chúng tôi di chuyển và nhiều huấn luyện và thảo luận để phát triển thực hành kỹ thuật phần mềm của chúng tôi. Tôi đã học được rất nhiều từ nhóm trên đường và chúng tôi gần như đã ở đó để giao dự án đầu tiên trong nhà sau hơn một năm làm việc!

Tôi bị mất khi nói đến các tiêu chuẩn mã hóa, các công cụ vòng đời dự án và các thủ tục phát hành / phân phối.

Tìm một sản phẩm nguồn mở sử dụng cùng công nghệ mà bạn sẽ sử dụng.

Nếu có thể, hãy tìm một cái tương tự như miền vấn đề. Điều này không quan trọng bằng việc tìm kiếm một dự án có cùng công nghệ và cập nhật tích cực.

Tải về mã làm việc của họ. Đọc nó.

Chỉ ra những công cụ họ sử dụng. Sử dụng chúng.

Chỉ ra cách xây dựng và phát hành dự án nguồn mở. Xây dựng nó và phát hành nó.

Một dự án nguồn mở (với một số người đóng góp) sẽ minh họa các thực tiễn tốt nhất.

Tôi không có nghi ngờ rằng tôi có thể nhận được những điều cơ bản trong vòng một hoặc hai tháng, nhưng có một số kinh nghiệm nhất định người ta chỉ có thể thu thập với thời gian.

Thật.

Học hỏi từ cộng đồng nguồn mở.