Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

새로 영입된 아키텍트는 한참 분석하더니 결론을 내렸습니다. 이것은 블랙 박스다라고 

언젠가 원래는 팀장이 아키텍트역활을 한다라고 들은적이 없습니다했었습니다. 팀장은  팀장은 결코 자신의 팀장인  기간내에 작성된 팀코드를 블랙박스다란 결론을 내릴수없습니다.

그리고 그것은 좀더 좋은 단어로 바꿔 불렀습니다. 레거시 코드다라고

저는 이의미에 반대하였습니다.  이것을 제가 레거시팀의 메인개발자였으며 

오래된 기술을 사용한다고 해도 현재 서비스를 잘하고 있는데 어떻게 유산이냐고?  새로운 서비스로 바꾸고 나서 그렇게 불러달라고

하지만 늦게 수긍을 하였습니다. 레거시인 이유는 사용된 기술이 오래된게 아니라

기존코드가 비지니스 흐름이 분석이 안되고 개선 지점을 찾을수없으며 문서화도 안되는 예전 고전적인 개발방법을 통해 개발이되었기때문이다라고~ 


어쨋든 이것을 지켜보는 상위 관리팀에서 극단의 지침을 내립니다. 이것은 플래폼의 문제를 뛰어넘는것입니다.

그냥 놀아라, 너희가 노는것을 보장해주겠다.

하지만 활동을 하고 싶은면 너가 하는일이무엇인지?  사소한 일도 티켓을 만들어라~만들고 그 과정을 문서화해라~

티켓:특정한 것을 할 수 있는 자격. (네이버사전)

...

처음에는 , 뭔가 답답했습니다. 우리는 우리만의 아날로그적인 감성과 , 아날로그적으로 일하는것을 더 선호했습니다.

내가 하는일의 제목을 무엇으로 달지?  할당은 하고? 요청해야할 제목은 무엇으로 할것이며? 문서로 어떻게 설득을 시킬것이며 할당은 누구에게 하지?

이전에는 그냥 담당팀 아무개한테 해달라고 하면 해줬는데~~

이런 고민을 하는게 아주 소모적이였습니다. 처음에는 소모적 으로 느껴졌습니다.

그리고 내가 하는 일을 스스로 보고하여 트래킹 당하는것도 싫었습니다.

...

  • 퇴근시간 갑자기 생긴일에 응대를 해주면 착한 개발자 
  • 문의받은 그내용이 무엇인지 어렵풋이알지만 신속하게 잘못된 유추한 정보로 응대를 해줘도 착한 개발자


기존의 그결과는 이렇습니다.

  • 유추한 정보가 전달되더니 서비스에 반영됩니다. 실제 그러했습니다.
  • 팀의 리소스가 분배되지않고, 팀장을 건너뛰어 팀내 외부 담당전문 개발자가 생깁니다. 팀장도 진행사항을 놓치게됩니다.
  • 퇴근시간이되면 문의하는 습관이 생깁니다. 상대가 칼퇴하면 문제 삼습니다.
  • 런칭 1주일도 안되서, 이거 담주 올라가야하니 빨리해주세요 라고 요청합니다. 계획되지 않은걸 문제삼지 않고, 1주일이내에 못끝낸 담당자가 잘못되게 됩니다.


그렇습니다. 기존에는 자신의 팀업무를 위해서 특정누구한테 문의가 집중되었으며 관리도 안되었습니다.

할당수로 측정이되니, 이제 팀내에서 분업을 어떻게 시킬까 고민을 하게 만들었습니다. 대부분의 팀의 일은

이제 팀장에게 직접 할당이 되니까요. 그리고 팀장끼리 협업을 해야합니다. 자신의 팀 문제가 아니면 다른팀에게

넘겨야하니까요


 어쨋건 우리가하는일을 트래킹 시스템을 도입하고 ,아주 세세한 일까지

기록하기로 합의를 하였으며, 프로세스의 잘잘못은 이후에 바로잡아가기로 합니다.

모든 문제의 파악은, 직관적인 티켓을 통해서만 하기로 하였으니까요....,

신규기능 추가

 신규기능은 어떻게 추가하나? 사업부에서 어떠한 아이디어를 떠올려 초안을 세웁니다.

...