모두 같은 방향 바라보기
개인적으로 애자일 프로세스 정확히는 스크럼 도입뿐만 아니라 '협업'에서 늘 가장 어려웠던 부분은 마음의 합일이 아닐까 생각한다
모두가 롤에 대해서 이해하고 애자일에 대해서 공부하고 그걸 어떻게 적용해야될지 알았으면 좋았을 텐데 그게 잘 안되었다.
(여기서 모두는 개발자 뿐만 아니라 모든 조직구성원이다)
요는 결국 교육과 조직 전체의 성장에 기여하는 기버(Giver)의 존재 그리고 모든 조직체계원들이 얼마나 공감하고 그 가치에 대해서 한 마음이 되었느냐 이였을것이다.
참고로 기버(Giver)란 문자 그대로 아낌없이 자신의 리소스를 나눠주는 사람이다.
그러나 결과적으로 결국 바꿀수 있는건 나 자신밖에 없으니 동기를 고취시키지 못한 내 잘못일 터이다. 물론 나도 일개 직원에 불과했지만
그 때 당시에는 '기버' 라는 언어를 몰랐지만 같이 있던 PM도 그렇고 나도 그렇고 기버가 되려고 노력했던 것 같다.
(PM의 경우에는 예전 고군분투글에도 적혀있지만 '함께 자라기' 라는 책을 추천해줬었다.)
여담이지만 둘이 서로 기버하는(?) 부분이 다르기도 했다. 나는 좀 심리같은 부분까지 합쳐서 총체적인 느낌이였고 PM은 지식에 관련된 부분에 한정한 느낌이였다고 할까 그쪽에 강한 사람이기도 했고
허나 개인적으로 애자일과 스크럼에 대한 가치 전파에 성공했다고 하더라도 내려오는 업무에 대해서 이 일을 왜 해야되는지에 대한 의문을 매꿔줄 이가 없었다.
가치는 전파했는데 모두가 같이 바라볼 우리만의 프로덕트에 대한 방향은 없었던 셈이다.
애자일도 결국 그 방향에 대한 실현 방법이지 그 자체를 하려던 건 아닐텐데 결과적으로 수단이자 목적이 되어버린 어떻게 보면 반대로 애자일을 할려고 했던 셈이다.
(어찌되었건 추후에 생겼으면 사실 순서는 개인적으로 이 경우에는 의미가없다고 보지만 결과적으로나 과정적으로 생기지않았다)
요구사항이 정제되어 오지 않았다고 하는 그런 문제가 아니라 요구사항의 뿌리인 비전과 미션 그리고 전략에 대한 가치가 공감 되지 않았을 뿐더러 대부분 부재라고 느껴졌었다.
이에 대한 문제를 프로페셔널 제품 책임자 라는 책에서도 접할 수 있었다.
https://www.yes24.com/Product/Goods/103755046
프로페셔널 제품 책임자 - 예스24
스크럼을 활용하는 제품 책임자의 오랜 경험을 바탕으로 제품의 가치를 식별하고, 측정하고, 극대화하는 효과적인 방법을 보여준다. 또한 체계적인 큰 그림 기반 아래 전략을 수립하고, 복잡성
www.yes24.com
퇴사 이후 프로덕트에 대해서 공부하고 다양한 관점에 대해서 수집하고 생각해보니 정말 나는 시야가 짧았다는걸 느꼈다.
이 책은 그 좁은 시야를 더 넓게 해준 책 중 하나로
특히나 이 일을 왜 해야되는지 알려줘야 되는 사람이 누구이며 그 이유가 부재가되었을때 어떤식으로 일할 수 밖에 없다는 그 예시로 짧게 지나가는 것들이 바로 나의 현실이였던것을 느끼며 되돌아보게 해주었다.
책에서는 왜 만들어야 하는지 그 이유를 알려줘야 하는 제품 관리자 유형에 앵무새, 대리인, 비즈니스 담당자, 스폰서, 사장 5가지 유형을 말하는데
짧게 말하자면 앵무새는 한 이야기를 고대로 전달하는 사람("나도 모르겠는데 위에서 이렇게 하란다.")이고 대리인은 비즈니스에는 관심이 없지만 개발자들을 대리하는 사람 ..... 등등으로 나뉜다.
뭐 일개 직원이였고 수평적이였지만 내가 할려고했던게 퇴사후 생각해보면 개발팀의 대리인에 가까웠다는 생각이든다. 비즈니스에 대해서 관심이없었던 건 아니고 잘 몰랐을 뿐이지만.
시야가 짧았다고 느낀 부분은 주로 계속해서 바뀌는 요구사항에 관한 부분으로
매번 이랬다 저랬다 바뀌는 요구사항에 대해서 아주 단적으로 우유부단하고 바보같은 일 이라는 생각이 당시에는 지배적이였다
물론 앞서 말했듯이 사유에 명확함이 없으니까 그렇게 느낄만도했지만
이에 대해서 해명이든 변명이든 하려면 이유는 차고 넘치지만 어찌되었건 간에 공부하면서 느낀 건 지금 생각해보면 절대적으로 요구사항 변경에 대한 내 관점은 정말 짧은 편이였다고 할 수 있을 것 같다.
가치 부재나 이런걸 말할 것만이 아니라 비즈니스 도메인에 대해서 스스로 많이 공부한 것도 아니였으니까 이 부분은 통감하는 부분이고 지금에서는 시야를 많이 넓히려 하는 부분이다.
마지막으로 모두의 이해를 위해 한 활동을 되돌아보면 개발자들에게는 스크럼이 어떻고 애자일이 어떻고 하는 가치를 전파하는데에는 성공했지만
생각해보니 다른 팀에는 시도하지않았던 것이 진행에 있어서 병목이였을수도 있겠다는 생각도 든다.
이에 대해서는 3편에서 다룰 권한 에 대한 글에서도 다루겠지만 애자일에서 중요한 '권한' 에 대한 문제도 섞여있는데 내가 아무리 주도적으로 시도하고 환경에 구애받지 않으려고 한다 하더라도
그건 나의 권한이 아니라고 인식했기 때문에 그렇게 행동한 것도 있다.
결론: 모두의 이해를 위해서는 요구사항에 대한 회사만의 넓고 변하지 않는 가치가 있어야 되며 , 다 같이 성장 해야한다.
'쌩 스타트업에서의 생존 혹은 그냥 스토리' 카테고리의 다른 글
쌩 스타트업에서 1년동안 느낀 5가지 (0) | 2024.11.28 |
---|---|
애자일 실패기 - 좌충우돌 1 . 빠르게 실패하기 (3) | 2024.11.15 |
유저 스토리와 스키마를 통해 커뮤니티 비용을 줄인 경험 (1) | 2024.04.14 |
프론트엔드의 로그 설정기 -1 : 사용자 행동 로그 (0) | 2024.02.04 |
쌩 스타트업 에서의 3.5 달 차 : 기회는 어디에서 오는가 (1) | 2023.12.17 |