기술 전문 지식없이 개발 프로젝트를 이끄는 방법

저는 경력을 쌓고 코드 작업을 좋아하는 실무 개발자였습니다. 저는 항상 특정 기술에 관한 전문 지식이 거의 없거나 전혀없는 팀 리더를 존중하지만 특정 구현을 고집합니다.

이제 나는 유리의 반대편에 있습니다. C #에서 구현할 팻 클라이언트의 수석 개발자이지만 Java 웹 응용 프로그램을 작성하는 데 전문 지식이 있습니다. 어떤 언어로든 디자인 패턴과 OO 패러다임을 활용할 수 있다는 것을 알고 있지만 코딩 표준, 프로젝트 수명주기 도구 및 릴리스 / 배포 절차와 관련하여 길을 잃었습니다. 한 두 달 안에 기본 사항을 선택할 수 있다는 데는 의심의 여지가 없지만 시간이 지남에 따라 수집 할 수있는 경험이 있습니다.

어떻게해야합니까? 개발할 때 싫어했던 프로젝트 리더가되지 않으려면 어떻게해야합니까?

솔직히 말해서 기술에 대한 경험이 아무리 중요하더라도 제 조언은 동일합니다. 관리가 바쁠 때 기술에 대한 결정을 내리지 마십시오.

자신에게 정직하십시오. 이전 관리자가 미워한 이유는 그들이 의사 결정을 내릴 지식 기반이 없기 때문이 아니라, 의사 결정을 내리고 결과를 다루지 않았기 때문입니다.

이전에 .NET을 만본 적이 없거나 팀에서 가장 전문적인 개발자인지 여부에 적용됩니다. 귀하의 직무는 이제 기술적 결정을 내리는 것이 아니라 관리하는 것입니다.

개발자의 기술 수준에 따라 관리하는 것은 개발자에게 요청할 때 조언하는 것을 의미합니다. "Spring.NET을 살펴 보셨습니까?" (지도가 부족하다는 점을 명심하십시오)는 완벽하게 말하는 것입니다. 또한 "Google 주변에서 다른 지역의 활동을 확인하십시오.이 문제에 가장 먼저 직면 한 것은 아닙니다."

어떤면에서는 경험 많은 Java 개발자로서 대부분의 경우보다 더 나은 위치에있을 수 있습니다. 대부분의 Java 프레임 워크 및 기술은 .NET과 비슷한 기능을합니다. 따라서 "사용하기 가장 좋은 것이 여기에 있습니다"라고 말할 필요가 없습니다. "Java에서 이것을 사용했습니다. .NET에 대해 알고 있습니까?"

또한 팀 내에서 많은 대화를 장려하십시오. 매주 기술 토론 회의를 마련하십시오. 결국에는 정보 만 있으면됩니다. 어떤 결정을 내 렸는지, 왜 그런지 알아야합니다. 팀을 위해 그러한 결정을 내릴 필요는 없습니다.

나는 기술에 대해 거의 알지 못하는 훌륭한 관리자 / 팀 리더가 있었고 최악의 관리자 중 일부는 모든 것을 알고 있다고 생각한 사람들이었습니다.

리더가 되려면 합리적으로 유능한 사람들이 있다면, 가장 중요한 것은 그들의 능력과 판단을 판단하고 그가 처리 할 수있는만큼의 위도를 부여하면서 "야생 오리"를 직무와 "간신히"유지하는 것입니다 "안전"하지만 생산적인 활동으로 바쁘다. 모두가 같은 드러머에게 행진하고 있는지 확인하십시오.

더 큰 도전은 경영진을 막는 것입니다. 그들은 보고서, 일정 및 확인 표시를 원할 것이고, 그들이 원하는 것이 무엇인지, 합리적으로 가짜를 만드는 방법을 알아야합니다. (정확하게 "가짜"가 아니라 시간이나 팀의 시간을 낭비하지 않고 만족시키는 문서를 작성하십시오.)

C # 코딩 기술을 선택하지 않았으며 처음부터 코드를 작성하지 않는 한 C #을 알고 있는지 여부는 중요하지 않습니다. 더 높은 수준의 사고를 시작해야합니다.

• 팀원 각자가 어떤 기술을 가지고 테이블에 가져 옵니까?
• 프로젝트 성공에 중요한 구성 요소는 무엇입니까?
• 실제 코드 외에 무엇을 생산해야합니까? (테스트? 문서?)
• 아직 요구 사항을 어떻게 수집하지 않습니까?
• 당신과 당신의 팀은 어떻게 디자인 프로세스에 접근 할 것입니까?
• 코딩 표준 을 갖는 것이 중요 하다는 것을 알고 있지만 팀이 어떤 표준을 따르고 있는지 정확히 파악할 수 있습니다.
• 조기에 문제를 어떻게 감지 할 수 있습니까?

이 중 일부는 프로젝트 관리 영역으로 넘어갈 수 있지만, 수석 개발자는 프로젝트 관리자와 이러한 문제 및 기타 문제에 대해 긴밀하게 협력하게됩니다.

꼭 C #에서 가능한 한 빨리 효과적인 작업을 배우십시오. 여러분의 역할은 구문과 프레임 워크 세부 사항을지나 더 큰 그림을 보는 것입니다.

다가 가세요. 간단한 C # 입문서를 통해 코드를 작성하십시오. 다른 언어로 눈 가리개를하는 방법을 알고있는 몇 가지 기본 사항을 시도하십시오.

프로그래밍 스타일과 규칙을 읽으십시오. 어쨌든 프라이머에서이 부분을 찾아야하지만 StyleCop 및 Resharper와 같은 제품을 사용하여 익숙하지 않은 스타일 규칙을 적용 할 수도 있습니다. 이렇게하면 소프트웨어를 컴파일 할 때 발생하는 문제를 피하기 위해 일반적으로 받아 들여지는 방식으로 작업을 수행하도록 매우 빠르게 훈련 할 수 있습니다.

자신 만 있으면되고 이미 가지고있는 설계 지식을 적용 할 수 있습니다. 언어와 상관없이 기본 사항은 기본적으로 동일합니다. 언어가 구조면에서 어떻게 다른지에 차이가있는 곳은 상당히 최소화되며 테스트 응용 프로그램을 함께 던질 때 많은 언어가 매우 빠르게 나타납니다.

모르는 것이 분명하면 앞으로 나올 것입니다. 당신의 팀은 단서없이 단순히 참여하는 것 이상으로 정직을 존중할 것입니다. 현명하고 합리적인 의사 결정을 내리고 응답을 고려하기 위해 항상 몇 분이 소요됩니다. 당신은 지배하려하지 않고 단호하게해야하며, 한 분야에 대한 지식 부족이 팀을 이끌 수있는 능력을 반영하는 것처럼 보일 수 없습니다. 리더십은 멘토링을 의미하지만 멘토링은 새로운 것을 배우려는 의지를 보여줄 수 없다는 것을 의미하지는 않습니다.

그렇게 생각하고 실제로 걱정한다면 이미 이런 종류의 프로젝트 리더가 될 위험을 피했습니다. 적절한 지식없이 결정을 내리는 것은 완전히 다른 종류의 성격입니다. 동료가 말한 내용을 마음에 새기고 팀의 대화 및 정보 교환 문화를 조성하고 장려하십시오.

여기에 몇 가지 문제가있는 것 같습니다.

주도하는 프로젝트에 사용 된 기술과 해당 프로젝트의 개발을 관리하는 프로세스입니다.

팀 리더입니까, 아니면 수석 개발자입니까? 선임 개발자도 상당 부분의 설계 및 개발 작업을 수행합니다. 따라서이 문제를 해결할 수있는 유일한 방법 은 새로운 기술 을 숙달하고 배우는 것 입니다.

실제로 팀을 이끌고 있다면 팀을 신뢰 하고 프로젝트의 기술적 방향의 대부분을 이끌어야합니다 . 물론 개념적으로는 올바른 방향으로 조향을 유지할 수 있습니다.

프로젝트 개발 을 지배하는 프로세스 는 대부분 제자리에 있어야합니다 . 그것들을 읽고 이해하고 실행하는 것입니다.

그렇지 않은 경우 상사와 협상하여 멘토가 개발 프로세스를 마련하도록 도와줍니다. 이것은 매우 중요합니다. 프로세스가 제자리에 있지 않고 임시로 진행되면 꽤 빨리 실패합니다.

행운을 빕니다!

기회는 가끔옵니다 .. 잡아라 .. C #의 기본을 배우려고 노력합니다. 온라인에서 튜토리얼을 받아보십시오. 처음에는 새로운 개념을 배우기가 어려울 것입니다. 나중에 첫 번째 작업이 완료되면 그 개념에 대해 확신을 갖게됩니다.

긍정적으로 생각하고, 열심히 노력하고, 자신의 코드를 디버깅하고 마스터하십시오.

기회를 잃지 마십시오.

많은 .Net 개발자가 있다면 팀에 시작하여 시작해야 할 지식이 많이 있다고 생각합니다. Java와 .Net 사이에는 이미 알고있는 것이 실제로 직접 적용되지 않을 수도 있다는 많은 유사성이 있습니다. 중요한 것은이 프로젝트에 올바른 것을 얻는 데 무엇이 중요한지, 관련된 위험을 아는 것입니다. 필요할 때마다 팀과 대화하십시오. 소프트웨어 엔지니어링 실무는 프로젝트 전체에서 발전하므로 프로젝트 초기에 "모범 실무"가 어려울 수 있습니다.

나는 소프트웨어 관련 분야 출신이 아닌 매우 녹색의 대학원 팀을 받았던 당신의 경험과 반대였습니다. 내가해야 할 일을 명시해야 할 모든 이유가 있지만 (나를 고용 한) 대신 소프트웨어 엔지니어링 실무를 발전시키기 위해 많은 코칭과 토론을하기 위해 연습을 구했습니다. 도중에 팀에서 힙을 배웠고 일 년이 넘은 후 첫 번째 사내 프로젝트를 수행하는 데 거의 왔습니다!

코딩 표준, 프로젝트 수명주기 도구 및 릴리스 / 배포 절차와 관련하여 길을 잃었습니다.

사용하려는 것과 동일한 기술을 사용하는 오픈 소스 제품을 찾으십시오.

가능하면 문제 도메인과 비슷한 방법을 찾으십시오. 동일한 기술과 활성 업데이트가있는 프로젝트를 찾는 것만 큼 중요하지 않습니다.

작업 코드를 다운로드하십시오. 읽어.

그들이 사용하는 도구를 파악하십시오. 그것을 써.

오픈 소스 프로젝트를 빌드하고 릴리스하는 방법을 알아 봅니다. 빌드하고 해제하십시오.

(기여자가 많은) 오픈 소스 프로젝트는 모범 사례를 보여줍니다.

한 두 달 안에 기본 사항을 선택할 수 있다는 데는 의심의 여지가 없지만 시간이 지남에 따라 수집 할 수있는 경험이 있습니다.

진실.

오픈 소스 커뮤니티에서 배우십시오.