SW 기획, 품질활동 컨설팅 후기
(Vlog성 주의)
이런 저라도 일상 공유는 할 수 있잖아요....?
여러분 입추가 지난 지 한참 되었다고 하는데
이 날씨 믿어지시나요....?
지금 서울의 날씨는 미쳐가는 중입니다...
날씨가 이상하든 하늘이 무너지든....
직장인이라면 한 그루의 사과나무는 심어야죠
신나는 근무시간! 하하
이날은 다른 날과 달리 조금 특별하게, 컨텐츠 회사의 컨설팅 지원을 하러 갑니다!
네? 아직 공부할 게 많은 저인데
제가 컨설팅을 진행하냐구요?
컨설팅 지원팀의 지원인력의 지원인력....입니다 ㅎㅎ
1호선을 탔는데 사람도 엄청 많더라구요....
압축될 뻔했습니다....
그렇게 출구로 나왔는데.....
오오.....///
청계천까지 와서 일만 하고 가면 아쉽잖아요?
생각보다 올 일이 별로 없어서 조금 기대하고 갔는데
완전 기대이상이었어요..!
맑게 흐르는 강물을 보고 있자니 좀 시원해지는 기분이었습니다 ><
게다가 강물에 두루미...? 같이 생긴 것이 먹이를 찾고 있더라구요
귀여운 것....-///-
건물 안으로 들어가니까, 사무실 내부도 엄청 깔끔하더라구요...!
여러분들이 상상하시는 그 깔끔한 사무실 느낌 그대로입니다 :)
간식 GET
커피도 원샷!
덕분에 활력 완충한 뒤 제대로 컨설팅 지원을 시작해 볼까요?
이번 자리에서는 특정 업무에 대해 간단하게 질의응답을 하고자 해요
주제는 "기획 > 개발 > 검증 단계에서의 업무와 개선하고 싶은 점" 입니다!
실제 실무자분들의 의견을 들을 수 있는
정말 흔하지 않은 기회였습니다...!
컨텐츠 기획도 물론이고 시스템 기획까지
엄청 열정적으로 질문에 응해주셨습니다
다시 한번 감사의 말씀을.....
의외였던 점은, VOC 대응도 도맡아서 진행하시더라구요...!
심지어 IA 구조도까지 제작하신다고 합니다..!
출처: https://blog.naver.com/soomichip_/223127062784
초보라면 모르는 단어가 나오는 즉시 구글링해버리는 순발력이 필요하더군요 ㅎㅎ
쉽고 간편하게 이해한다면 일종의 서비스 메뉴 트리, 기능 구조들을 나열한 문서입니다..!
위처럼 필요한 서비스들을 텍스트로 나열하여 IA 구조도의 일부로 구성할 수 있겠네요
요구사항 명세서에 화면정의서, 버전 관리까지....!
어째서 해당 문서를 작성할 필요가 있었을까요?
1. 브레인스토밍이나, 탄탄한 설계를 도울 수 있다는 장점도 있고
2. 무엇보다 다른 팀원과의 소통을 위한 수단으로 이용할 수 있기 때문이죠. :)
3. 인수인계에 필요할 수도 있고, 상부 보고용으로도 쓰이겠네요
프로젝트 규모가 크면 클수록 가담 인력이 많아지는 건 자연스러운 현상이죠?
여러 사람들의 자문을 듣다 보면, 문서 정리가 정말 중요하다는 것을 깨닫게 됩니다..!
개발 일정을 조율할 때도 기획자분들이 적극 참여하신다고 합니다.
물론 소통이 아주 매끄럽게 진행되는 건 아닐...수도....있다고 보이네요
그나마 다행인 점은, 구글 스프레드시트가 참 좋다는 거....? ㅎㅎ
그마저도 잘 안 쓰는 건 안 비밀
아무리 팀 내부 업무 체계가 잘 짜여 있더라도, 부서 간 소통은 참 어려운 법이지요...
기획 "의도"가 잘 전달이 안된다거나, 개발 변경사항을 다른 기획, 검증자들이 따라오지 못하는 점...?
이 문제는 어떻게 보완하는 게 좋을까요?
1. 현재 운영 중인 서비스 및 앱의 현황을 조사하고
2. 각 서비스의 목적 및 운영현황에 따른 서비스 수준관리를 계획하는 건 어떨까요?
조사할 현황은 현시점의 VOC발생 정보
요구사항 변경 빈도 등을 고려한 관리 계획 목록
등이 있겠네요...!
활동명 자체를 정의하자면, 버전 관리 내역을 모두가 공유해 보는 것입니다...!
변경된 버전, 변경 사유, 어떤 방향으로 변경하였음~ 등을 적어보는 거죠
출처: https://coding-lks.tistory.com/162
깃 스냅샷(snapshot : 특정 시점에서 파일, 폴더 또는 개발 상태)
뿐만 아니라 일반 텍스트로 정의해 볼까요?
버전 관리를 편리하게 해주는 도구도 많으니까, 변경 사항에 대해서 자세하게 적시하고, 큰 변경사항에 의해 기획 문서가 변경되어야 한다면 기획 문서 관리도 해주면 참 좋겠죠?
해당 실무자 분들도 프로젝트에서 작성된 각 제품의 산출물들이
유지보수 단계에 들어오면 갱신되고 있지 않다고 말씀하셨어요.
각 제품별(서비스 또는 앱) 유지보수 중에 필수적으로 갱신되어야 할 산출물을 정의하고, 유지보수의 범위가 일정 수준 이상일 경우 해당 산출물의 변경을 확인하는 절차가 마련된다면 좋을 것 같습니다...!
다음 인터뷰는 검증 활동 위주로 질문해 보았습니다~
검증 담당자분들에게서 주목할 점은
크게 달성률(%) 그리고 릴리즈 일정, 개발자 소통이었는데요
일단 내부적인 보완점으로는
검증 팀 내부에서 진행되는 Ad-hoc 테스트 진행 로그를 남겨놓긴 해도, 관리를 잘 못해서
문서 정리를 하는 유의미한 이유를 찾지 못한 적이 있다고 합니다.
이 부분, 분명 테스트가 필요해 보이는데
TC에 명시되어있지 않아도 진행해야 하잖아요...?
그런 경우 테스터가 자체적으로 테스트를 진행하게 되기 때문에, 진행자가 따로 기록을 해야 돼요
한 문서에서 다 같이 기록을 해도
전사 차원의 체계가 잡혀있지 않으면 관리하기 힘든 점이 있죠.
전체적인 품질 정책을 마련하거나 이를 프로젝트에서 준용하기 위한 각 프로젝트의 품질 보증 활동으로 애드훅 테스트 관리 문서를 포함한다면 어떨까요?
..... 일이 점점 더 많아지는 건 기분 탓인가.....
그뿐만 아니라 VoC 및 긴급배포에 대한 대응, 수정이 들어오면 일정 내에 재빨리 작업을 끝내야 하는 경우가 많다고 합니다
릴리즈 일정은 확실히 지켜야 해서 업무에 여유가 없어질 수밖에 없더라구요.
배포까지 열심히 달려야 하는 입장이겠네요
기획자분들이 마감 일정에 맞춰서 개발일정을 잡으면
개발자와 상의 후 일정을 수정하고,
마감일자에 맞추어 검증 일정을 끼워 맞추는 방식(?!)으로 일정 조율을 많이 하셨다는데
그래서 업무가 점점 밀릴 수밖에 없었던 거예요...!
근데 또 마감 안 지키면 큰일 나잖아요....
사실 이 부분은 오히려 일을 더 많이 하기보다는, 템포에 여유를 찾아야 품질이 개선이 되는 부분이라
인력을 더 보충하거나 마감 일정을 검증팀과 상의 후에 결정할 수 있으면 좋겠다고 생각했습니다.
그런데,
때마침 인원 확장과 함께 전사 차원의 품질 활동 개선에 불을 붙이기 시작했다고 합니다.
더불어 버전업 관리에 대한 릴리즈 일정을 확실히 정하고
소프트웨어 이슈 티켓을 등록하고, 관리할 수 있는 툴이 잘 되어있기에
노티스 방식을 안정화하면 이 부분은 빠른 해결이 가능하고, 개선 기댓값도 나쁘지 않아서 계속 발전시키기로 하셨답니다!
이런 추진력이 있어야 회사 운영하나 봅니다
멋지다 +_+
이제 인터뷰 마무리하고 슬슬 나가볼까요?
좋다~ 서울의 중심
강남과는 다른 느낌인데, 저는 종각 쪽이 좀 더 좋은 거 같습니다
이번 인터뷰 계기로 얻은 게 참 많은 것 같아요
오늘 들었던 정보들이 다 한쪽에만 국한되는 게 아니라
모두가 어느 정도 고민하고 있는 문제일 거라고 생각합니다
전체적인 컨설팅 결과를 보면, 뭔가 다 아는 사실이기도 하고
해결해야 할 문제가 너무 많아서 막막해 보이기도 하는데
사실 아무도 지적해주지 않으면 개선이 안 되는 것도 있으니까요...
꼭 한 번쯤은 누군가의 주도하에 전체적인 프로세스 개선이 이루어질 수 있다면 좋을 것 같습니다 :)
