글목록
2) 우리는 애자일 하게 일하고 있을까? (현재 글)
"우리는 왜 애자일 하지 못할까"에 이어, 말씀드렸던, 기존에 제가 느꼈던 제가 했던, 또는 들었던 프로덕트를 만들며 과정에 대해 간단히 설명해 드리고, 해당 방식이 일하는 과정에서 놓칠 수 있을 것 같은 내용들, 그리고 근본적인 가치적인 부분에 대해 설명드리도록 하겠습니다. 몇 가지 사항을 말씀드리자면,
1. 그 어떤 방법도 틀린 건 절대 아니며, 어느 팀에 건 어디에든 맞는 방법들은 존재할 수 있어요. 저는 제가 일하면서 또는 많은 분들과 일하며 느낀 내용들을 공유하는 것이니, 언제든 질문 주시면 감사하겠습니다!
2. 다소 개발적인 부분들이 많이 포함되어 있을 수 있습니다. 모르겠는 단어들이나 과정들은 알려주시면 조금 더 정확히, 그리고 간단히 설명드릴 수 있도록 하겠습니다!
업무를 진행하면서 회사들이 일할 때 겪을 수도 있는 사례입니다.
(다시 한번! 모든 회사가 이렇다는 것은 아니며, 그렇다고 방법이 잘못되었다는 건 아닙니다!)
A라는 기능을 만들어야 해요
PM 측 또는 비즈니스나 마케팅 단에서 의사결정이 완료된 기능, 또는 개발 순서가 정해져 내려옵니다. 대부분의 의사결정은 비즈니스 적인 부분에서 정성적인 또는 정량적인 분석보다는 예상(Assumption)과 막연한 기대를 기반으로 다음 행동을 결정하게 됩니다. 기한은 "가능한 빠르게"로 산정되고, 언제 시작할지에 대해서도 "최대한 빨리"로 형용되게 됩니다.
A에 대한 기획서 적어놨으니 구글 닥스(또는 위키)에서 확인하시고 회의하시죠.
PM 측에서도 해당 기능에 대한 기술을 "와이어프레임" 또는 "플로우 차트"를 기반으로 기획서를 문서화하고, 해당 문서를 기반으로 개발/ 디자인 팀에 전달합니다. PM 측에서도
1. 진짜 유저가 해당 기능을 쓸 것인지
2. 지금 프로덕트가 해당 기능이 왜 필요한지
3. 어떤 부분까지가 유저에게 가치를 줄 것인지
4. 해당 기능을 언제까지 개발할 수 있을지(물리적 예상)
에 대한 정확한 부분은 알 수 없지만, 다른 회사들은 어떻게 해 왔는지에 대한 조사(Benchmark)등을 통해서 개발자, 디자이너의 피드백 없이, 자신이 작성한 기획서를 기반으로 기능 개발을 위해 상의합니다.
해당 기능들 기반으로 지라(Jira) 티켓 만들어 놨으니 작업 진행해 주세요.
회의 진행을 통해 어떤 기능들이 있을 것이고, 해당 기능들에 대해 어느 정도 개발자/ 디자이너들과 이해가 가능한 부분까지의 선을 나누고, 어느 정도 지라, 또는 트렐로 또는 다른 프로젝트 관리 툴을 통해
- "~기능 프런트 작업" 또는 "~기능 백앤드 작업" 그리고 "~디자인"작업
- "... 페이지 프런트 작업" 또는 "... 페이지 백앤드 작업" 그리고 "... 페이지 디자인"등
유저가 얻는 가치를 기반으로 한 작업이 아닌, 개발단에서 어떤 걸 개발해야 한다 라는 목적 기반의 티켓 작성으로 디자이너 또는 개발자들이 얼마나 작업을 했는지에 대해 확인합니다.
디자인은 어느 정도 준비된 거 같은데, 개발은 어느 정도 돼가요?
하루하루 진행되는 과정을 사람대 사람으로 공유하기보단, 프로젝트 관리 툴에 의존해 작업 진행을 확인하고 있고, 개발의 범위가 너무 큰 티켓들을 작업하기 때문에, "어느 부분이 어떻게 작업되고 있는지"를 알기 위해선 물어볼 수밖에 없고 이에 대해 알기 위해선 "얼마큼 작업을 했나요?"라는 질문을 하게 되고, 해당 질문들 들은 작업자들은 잘못한 게 없음에도 불구하고, 작업에 대한 압박과 스트레스를 받고, 최악의 경우, 서로 자신의 일을 최선을 다해하고 있음에도 불구하고, 서로에게 나쁜 감정을 가지게 됩니다.
디자인 가이드랑 기획서가 다른데 어떤 걸로 해야 해요?
피엠은 또 다른 기능들을 준비해야 하거나, 다른 개발자들 또는 디자이너들과의 소통을 하며 고군분투하는 상황에 뛰어다니며 일을 하고 있기 때문에, 디자이너가 작업을 하며 놓칠 수 있는, 또는 더 좋은 아이디어라고 생각해 수정한 부분들에 대해 소통을 할 수 있는 기회가 줄어들게 되고 이렇게 생긴 기획서와 디자인 가이드는 개발단과 디자이너 그리고 중간에 끼인 피엠과의 서포팅이 아닌 줄다리기를 하게 되는 상황에 처하게 됩니다.
이거 누르면 여기로 가는 게 맞아요? 이건 좀 아닌 거 같은데
기획서에 대해 회의를 했지만, 해당 회의 때 정확하게 나오지 않은 부분들이 있거나, 간결하게 넘어간 부분이 있을 때, 개발이 들어가는 상황에서 같이 일하는 팀원들끼리 기능에 대한 정확한 방향이 이해가 되지 않거나, 옳다고 판단되지 않는 것들이 있을 때, 갈등이 생기게 되고(물론 아무 말도 안 하고 있는 게 더 안 좋은 결과를 초래하지만) 서로 간의 이해가 더더욱 힘들어지게 됩니다.
기획 쪽에서 정책이 안정해져서 안 만들었어요 버그 아니에요.
이렇게 힘겹게 줄다리기를 하다 보면, 종종 더 이상의 커뮤니케이션 보단 "빨리 만들어서 일단 올리면 테스트해서 찾아내면 그때 결정하겠지 뭐"라는 낭비, 또는 부채가 생기게 되고, 서로 간의 이해보다는 기능상의 오류에 대해 책임소재를 찾게 되고, 개발에 집중할 수 있는 집중도를 잃을뿐더러 시간 역시 지체되게 됩니다.
TC 확인해 봤는데, 이건 이렇게 가는 게 맞아요.
이렇게 개발을 진행하게 되면, "유저"보다는 "기능"에 "품질"보다는 "기간"에 맞추는 프로덕트를 개발할 수밖에 없는 상황이 되고, 그렇게 되다 보면 "가치"보다는 "지금 적혀있는 문서"에 갇혀 진짜 우리가 필요한 것보다는 "어쩔 수 없지만 해야 하는 것"으로 우리가 하는 일에 대한 가치가 줄어드는 것을 서로가 느낄 수 있습니다.
테스팅 안 끝났어요 배포 못해요.
해당 내용들이 지속적으로 진행되다 보면 정해지는 것보다는, 회의가 늘어나게 되고, 회의가 늘어나다 보면 작업이 늦어지게 되고, 작업이 늦어지게 되면 배포가 늦어지게 되는 불안정한 사이클이 돌아가게 됩니다.
... 롤백하시죠...
그리고 정말 최악의 경우엔, 열심히 만든 우리가 만든 기능이 세상밖에 구경하지 못하게 되는 최악의 사항을 겪게 될 수 있죠 그리고 이렇게 될 경우엔....
이번에는 회고 없이 바로 다음 스프린트(또는 이터레이션) 진행하시죠
이렇게 늦어진 배포(아니면 없어진 배포) 때문에 생긴 시간 만회를 위해 회고를 진행하기보다는 다음 기능 또는 재배포를 위한 준비를 시작하게 되고, 프로덕트팀 서로 간의 신뢰도가 깎이게 되고 신체적 또는 심리적 피로감을 늘린 체 다음 스프린트 또는 연장된 스프린트의 다른 개발 또는 디자인 또는 기획을 진행하게 됩니다.
기본적으로 모든 회사는 이윤을 추구하고, 혼자서 일하는 것보단, 동료와의 협업이 더 높은 생산성을 얻을 수 있기 때문에, 동료 간의 시너지를 얻을 수 있도록 방법론을 찾고 도입하는 것은 어떻게 보면 회사에서 추구할 수 있는 최선의 방법입니다. 그러나, 위의 케이스에서는 애자 일한 오히려 팀의 문화가 깨져버리게 되는 최악의 케이스를 보게 되죠.
제가 찾은 가장 원초적인 문제는 유저가 가질 가치에 대한 공유가 없는데서 시작합니다.
(유저가 가질 가치라는 내용은 우리는 왜 애자일 하지 못할까에서 확인이 가능하십니다..ㅎ 깨알 같은 재 홍보.) 우리가 만드는 프로덕트는 결국 유저가 사용하는 프로덕트이기 때문에,
어떤 유저가 어떻게 사용함으로써 어떤 가치를 얻게 될 것이다.
그 어떤 가치를 얻기 위해서 어떤 어떤 과정을 거칠 수 있다.
어떤 것들을 수행하지 못할 경우, 원하는 가치를 얻을 수 있도록 어떻게 유도한다.
라는 가치를 통한 기능의 생산보다는, 직관과 예상에 의한 의사결정, 유저에 대한 이해보다는 기능 개발에 집중된 프로세스, 그리고 빠른 개발을 위해 놓치는 부분들에 대한 낮은 고려 등으로 가치와 속도, 그리고 팀원 간의 불협화음을 키우는 작업을 하게 되는 것이죠.
분량 조절에 실패했네요...
다음 글에선
1. 어떤 가치를 기반으로 저는 일하고 있고,
2. 이런 방식으로 일하면서도 제가 겪고 있는 수많은 허들들
에 대해서 설명드릴 수 있도록 하겠습니다!
읽어주셔서 감사해요!
가입하기
