미국 회사 업무 6개월차 회고.

 

 

지난 3월에 입사해서 이제 8월, 슬슬 6개월차에 접어 든다. 

문화 차이를 비롯해 배워야 할 점 등을 포함해 한번 정리 해 본다. 

 

수평적 업무 구조

 : 듣던대로 수평적 업무 구조로 보인다. 즉, 팀 리더가 내 업무를 세세히 트랙킹 하지 않는다. 내 업무는 내가 알아서 하며 딱히 필요한 경우를 제외하면 주로 결과로 평가 및 피드백 받는다. 

 

생각보다 많은 회의

 : 생각보다 많은 회의를 한다. 하루종일 거의 회의만 할때도 있다. 

 

결과를 통한 피드백 보다, 작업 이전에 리서치를 많이 한후 업무진행

 : 결과를 통해 피드백을 할경우, PD의 의도에 기반한 여러 실험을 해 볼수 있는 장점이 있다. 반면에 개발진이 소진되기 쉽고, 전체적인 완성도가 다소 낮아질 수 있는 등의 단점이 있다. 여기서는 반대의 전략을 취한다. 특정 단계로 가기 전에 충분한 리서치와 관계자들의 동의를 얻고 다음 단계로 넘어간다. 따라서 전체 기대결과를 얻기까지 많은 시간이 걸리지만, 개발진은 결정된 대로만 개발하면 되기 때문에 큰 피로가 없게 되고 남는 시간을 온전히 구조개선에 사용할 수 있기 때문에 결과의 완성도는 전자보다 높을 가능성이 높게 된다.   

 

버젼 회고 회의

 : 매 버젼 빌드를 릴리즈하고 해당 빌드에 대한 회고 리뷰 회의를 한다. 무엇을 잘했고 잘못했고, 잘못한것은 어떻게 하면 개선될수 있을까를 모든 관련 개발진들이 모인 상황에 터 놓고 논의를 한다. 한국에는 없는 충격적인 회의다. 한국에서는 애초에 이런 얘기를 할 수 있는 분위기가 조성되어 있지 않다. 

 

도구를 통한 프로젝트 매니징

 : 모든 개발자들은 티켓이라는 식으로 업무를 할당 하거나, 받는다. 따라서 누가 어떤일을 하고 있고 언제 끝나며, 어떤 일들에 기여하고 있는지 누구나 볼수 있고 관리 할 수 있다. 매우 효과적이다. 

 

QA팀 주도의 버젼 빌드 구조

 : 메인 빌드 브랜치에 들어가는 어떤 리소스나 코드도 QA의 확인이 없으면 통합되지 못한다. 통합하고 확인하는 것이 아니고, 확인한 후에 통합하는 구조다. 물론 통합 하고 나서도 최종빌드 전에 다시 재확인을 하긴 한다. 결과의 완성도가 높음은 자명하다. 

 

Tech debt 해소에 큰 자원 투여

 : 서비스 중인 프로젝트라도 기술개선을 위해 자원투여를 아끼지 않는다. 개발자가 직접 건의하여 업무를 만들수도 있고, 실제로 업무의 큰 비중을 차지 한다. 

 

자율적 적극성(?)이 강요되는 업무 구조

 : 업무 할당을 제외하면 서로 크게 관여하지 않는다. 따라서 더 좋은, 최신의 기술을 사용하는 등의 실험적인 작업들의 가능하며 이런것들 또한 업무평가에 포함된다. 

 

 

 

It's been 6 months since I had worked for this company. 

Trying to catch up things and make some list to learn things include the difference in culture. 

 

Horizontal Organization Structure

More meetings

Research-based work process

The retrospective meeting

Project managing by the tool 

QA driven integration system

High passion to resolve Tech-Debt

Self-driven work process