랜턴의 서비스 기획 이야기 15

화면기획서 등 개발 문서 부재의 아쉬움 

 

중소업체는 문서 작성에 대해 큰 부담을 느낀다.

그럴듯한 기획자 인력을 운용하는 것이 비용적으로 쉽지 않을 뿐더러 

사실, 문서 작성이 가능한 기획자 인력이란 생각보다 요구되는 조건이 높기 때문이다. 

조직 자체가 RQMT만 만족시키는 정도만 하면 된다는 생각의 허들 자체가 낮을 수도 있다.

 

나는 모두가 개발 전 과정에 참여하는 스크럼 형식으로 이 프로젝트가 운영되길 바랬다.

이런 노력은 개발업체의 메인 디자이너가 PM역할을 해주기도 했고,

개발자 인력이 대거 교체되면서 자연스럽게 문화를 빌드할 수 있는 여건이 되기도 했기 때문에

그럭저럭 그렇게 되긴 했다.

다만, 나 역시 초보 기획자였고, 문서의 중요성에 대해 잘 몰랐으며

급하게 꾸려진 개발업체의 팀 역시 마찬가지였다. 

 

Q/C를 해야되는 상황에 닥치자, 개발문서가 아쉬어졌다.

가령, 화면설계서라도 잘 구비가 되어있었다면,

화면설계서 기반으로 테스트 시나리오를 빠르게 구축할 수 있었을 것이었다.

하지만, 화면설계서는 없는 경우가 많았으며 

개발 문서 없이 테스트 시나리오를 구축하는 것은 시간을 엄청나게 지연시킬 뿐이었으므로 

도저히 할 엄두가 나지 않았다. 

---

델타랩 시동 + 내 실력은?

 

이 프로젝트를 하면서, 스스로도 엄청난 성장 폭을 느꼈다.

하지만, 홀로 다르게 일하는 것이 조직 내에서 부질 없는 짓으로 쉽게 치환됨도 느끼고 있었다. 

개발업체와 일하는 게 끝나고, 다시 나의 조직으로 돌아왔을 때, 

정작 나의 팀원들이 구시대의 방식에 갇혀있다면, 나 역시 그 제자리로 돌아와야 함이었다. 

더불어 나홀로 다르게 일하는 것으로는 (심지어 그 방식이 확실하게 진보된 방식이라할지라도) 

업무를 진척시킬 수 있는 한계가 명확해 보였다.  

 

이외에도 여러가지 이유들이 있었지만, 상기의 상황을 반전시키고 싶다는 괜한 욕심이 있었다. 

나는 나와 업무를 디벨롭할 수 있는 후배

그리고 가까운 선배 몇 명을 모집하여 단체 Q/C를 실시했다.

업무 중심의 구시대적 R&R에서 기능 중심으로 관계를 재편하면

일하는 방식과 문화가 바뀔 수 있는 좋은 실마리가 될 것으로 보았다.

한편으로는,  이런 경험을 말미암아 델타랩 활동으로 이어가려는 포석이기도 했다. 

 

한편 Q/C를 혼자 준비하면서, 나의 실력이 어땠는지 가늠해볼 수도 있었다.

개발자도구를 키면서, 어떻게 코딩했구나를 하나하나 검토할 수 있던 게 Q/C에 꽤나 도움이 되었다.

나중에, 협력업체 Q/C한 내용과 비교했는데, 

나혼자 Q/C한 내용들이 조금 더 많았다. 

---

ISMS 대응 Q/C 코드 정리 동시 작업 

 

11월에 Q/C를 진행했으나, 바로 개선하여 런칭에 돌입할 수가 없었다.

회사에서 처음으로 ISMS 심사를 진행한 바, 12월에는 심사관 방문

그리고 심사관의 의견에 따른 개선 대응 조치가 기다리고 있었기 때문이었다. 

 

당시 팀장님은 언제 런칭되냐고 나름의 압박이 있었다. 

하지만, 전사적 보안 업무 대응이 먼저 이뤄져야 했기에, 

런칭을 위한 준비는 기약없이 뒤로 밀릴 수 밖에 없는 처지였다. 

예상범주 바깥의 일들이긴 했다.

하지만, 그럼에도 조직 내 프로젝트를 하면서

이런 부분까지 고려해서 일정 수준의 마진을 마련하여

보고와 계획을 세워야 하는구나를 깨닫는 계기가 되었다.