[개발생각] 익숙치않은 개발(론)에 팀원들을 적응시키는 방법에 대해서

개발자라면, 같은 회사에서 오랜기간 개발하게 되면, 그 회사만의 방식/방법에 익숙해지게 마련이고,

마치 관습과도 같이 코드를 작성하게 된다.

이런게 '콘웨이 법칙'의 예가 아닐까? ㅎㅎ

 

만약 위와 같은 상황에 지속적으로 노출된다면, 개발자는 점점 관습으로 개발을 하게 되고,

(관습이 나쁘다는 이야기는 아니다. 다만, 필연적으로, 개발에 고민하는 시간이 줄어든다는 이야기이다)

어느 순간 개발자가 아닌 코더로 전락하게 된다.

그런데 정말 무서운것은 코더가 된것을 자신은 모른다는것이다... 정말 무섭다..

 

나도 코더였던 경험이 있다. (지금은 당연히 코더가 아니라고 자신있게 말할수있다 ㅎ)

대학 졸업후에, 작은 SI개발회사에서 몇년 일하게 됬는데,

어느 순간, 내가 일명 CCCV (컨트롤 C + 컨트롤 V)의 고수가 된걸 알게 되었다.

 

그날 곰곰히 누워서 생각한게 있다.

내가 몇년 개발한 코드들은 뭐지?? 내가 사용해왔던 기술에 대해서 설명을 할수있나??? 

하나도 대답할수없다고 생각했다. 그냥 코더 CCCV가 되버렸었다.

 

물론 그때의 충격이 지금은 보약이 되어, 그래도 지금은 노력하는 개발자가 되려고 하니... 다행이지..

 

 

다시 본론으로 돌아와서,

 

만약 위와 같은 기존 조직의 관습에 개발멤버들이 적응이 되버린 상황이라면,

그리고, 전혀 다른 개발론, 개발방식, 개발언어로 신규 프로젝트를 하게 된다면,

그리고, 감사하게도(??),

내가 프로젝트리더가 된다면,

어떻게 팀원들을 적응시켜야 할까?

 

큰 고민이 될수있다.

 

이 상황이라면, 프로젝트 진행 얼마간의 시간동안은 개발멤버들은 주니어 개발자들이라고 봐야한다.

(바로 개발을 원활하게 할수없다면 주니어 개발자와 같은 조건이기 때문이다. 다만, 절대적인 주니어라고 생각하라는 이야기가 아니다. 퍼포먼스만의 기준으로만 봤을때, 이 프로젝트에서는 주니어의 퍼포먼스라고 생각하라는 의미이다. 이부분은 명확히, 오해가 없어야 한다.)

 

 

그렇다면, 답은 나와있다.

 

 

이 상황이라면, 팀원들에게는,

1) 많은 의견을 요구해도 안되고 (의견을 줄수도 없는 상황일것이다.)

2) 큰 기대을 걸어서도 안된다. (적응하는것만해도 스트레스가 어마어마할것이다.)

3) 조급해해서도 안된다. (러닝커브가 높기에 일정 기간은 기다려 줘야한다.)

4) 내가 포기해서도 더더욱 안된다. (시간이 지나면 많은 부분이 해결될것이다.)

5) 항상, 프로젝트리더는, 팀원들에게 설명해주고, 같이 고민해주고, 의견을 제시해주는걸 중요시해야한다. 

 

이 시점에 가장 팀원들에게 도움이 필요한것은 명확한 방법/방향을 제시해주는것이다.

명확한 규칙/방법/방향을 제시하고,

그 부분에 대해서 공유를 통해 잘 이해할수있게 시간을 할애하는것이다.

(설령 당장은 이해를 못하다고 하더라도,지속적으로 시간을 할애해야한다)

그리고 그 규칙에 맞게, 개발을 진행하게 하고, 그 규칙에 맞지 않으면, 다시 규칙에 맞춰서 개발을 하도록 '요구/지시' 해야한다.

 

 

때로는, 팀원들은 너무 짜여진 규칙/규율로 개발을 하는것이 답답하거나,

자유롭고 창의적인 개발에 악영향을 주는것 같다는 생각을 할수도있다.

하지만, 팀리더는 이런 상황은 눈 딱감고, 견뎌야 한다.

 

 

이렇게 생각하는 이유를 적어본다.

 

1) 새로운 방법에 대해서 이해를 하는건 상당한 러닝커브가 존재한다. 가장 좋은건, 그 방법에 익숙해 지는것이고, 그 방법에 익숙해지기위해서는 그방법 그대로 적용/개발하려고 해야한다. (게임 튜터리얼 하는 것과 비슷하다고 해야하나?ㅎ)

 

2) 처음에는 규칙/방법/방향에 맞게 개발하는 것만해도 버겁다. 아마 같은 코드를 몇번을 다시 짜고, 몇번을 이클래스,저클래스로 옮겨야하는거야? 또는 값하나 사용하는건데 왜 이렇게 고민하고 시간을 들이는걸까? 라는 불만이 있을수있다. (불만이 없다면, 감사하다 ㅎ)

 

3) 하지만, 참고 버티고, 그 규칙에 맞게 개발하다보면, 어느순간부터, 하나하나의 퍼즐조각이 맞춰지기 시작한다.

궁금했던 부분이 이해 될것이고. 왜 이렇게 개발했고, 구조/설계가 됬는지 팀원들도 이해를 하게 되는 시점이 올것이다.

 

4) 이 시점부터 아주 흥미로워진다. 이 시점 전까지는 프로젝트 리더는 외롭다.

동조/의견을 나눌사람이 없거나, 부족하기에 혼자 개발하는 느낌을 받을수도있다.

하지만 이 시점이 되면, 이제는 팀원들 사이에서, 슬슬, 구조/설계/개발에 대해서 하나둘 의견이 나오기 시작할것이다.

(하나씩 하나씩 구조가 보이기 시작하기에)

 

5) 기존의 규칙/방법/방향에 대한 개선 의견이 나오고, 처음에 정했던 방향에 대해서 수정이 필요하다는 의견들이 나온다면, 의견수렴을 거쳐 수정을 진행한다. (여기서 가장중요한건 초기의 규칙/방법/방향성을 잘 정해야한다는것이다. 잘 정하지 못한 방향성은 나중에 이 의견수렴을 통한 수정이 불가하게 되기에, 프로젝트 리더의 역할이 아주 중요하다) - 초기에 리더는 마치, 정신병자와 같이 설계/구조에 예민해야한다. 잘못된 수정/결정 하나,하나가 나중에는 스노우볼로 프로젝트에 돌아오게된다.

 

6) 위의 경험을 한 팀원들은, 다른 신규 프로젝트에서는 개개인의 실력이 크게 발휘될것이다.

 

위 내용을 간단히 정리하면 '무조건 그냥해! 그러면 나중에는 이해될꺼야!' 라는식의 내용이 상당히 거북할수도있지만,

팀원들이 동의하고, 잘따라와준다면, 나의 경험으로는 이게 가장 효율적인 방법중에 하나라고 생각된다.

 

천재 개발자가 아닌이상, 전혀 경험하지 못한 환경에 바로 적응하고 이해하는 개발자가 몇이나 될까?

이 개발자들은 바뀐 개발환경 하나하나가 버거운 대상이기에, 그 대상에 대해서 온전하게 집중할수있게 시간을 주어야하고 도와주어야 한다....

 

(주의!! 부작용으로, 악덕업주라고 욕먹을수있음 ㅋ)