애자일 방법론의 바이블로 불리는 명성이 자자한 <함께 자라기>를 읽어보았습니다.
명성에 걸맞게 유익한 책이었습니다. 아직도 개발자는 혼자 일한다는 인식이 있는데 그 틀을 완전히 깨 줍니다. 함께 자라기를 그저 제안하는 것이 아니라 함께 자라야 성장한다는 것을 직시하게 해 줍니다.
제 해당 게시물 제목에서도 보실 수 있듯이 결국 협력하여 학습해야 좋은 조직이 형성되고, 그로 인해 더 쉽고 더 적은 비용으로 빠르게 성장하여 좋은 프로젝트를 만들어낼 수 있다는 내용입니다.
이것이 왜 중요할까요? 결국 프로젝트를 완성해 내서 세상에 내보인다는 것은 고객에게 가치를 주기 위함이기 때문입니다.
개발자인 우리가 무언갈 만들고 개선해 가는 이유 자체가 고객에게 가치를 제공하기 위해서입니다. 그걸 더 쉽게 할 수 있는 방법을 담은 치트키 공식이에요. 한 번쯤은 꼭 읽어보시길 추천드립니다!
좋은 조직을 만들어야 하는 이유와 내가 개발자로서 어떻게 성장해야 하는지 생각하게끔 만들어주는 책입니다.
책을 읽으면서 느낀 제 생각을 정리해 보겠습니다.
조직 문화는 왜 중요한가? (좋은 팀장이란)
심리적 안전감은 조직에서 정말 중요하다고 생각합니다. 멍청한 질문을 해도 괜찮다는 안전감은 계속해서 팀원들이 주도적으로 '시도'할 수 있는 촉진제가 됩니다. 이건 팀장뿐만 아니라 함께하는 팀원들도 마찬가지로 안전감이 드는 분위기와 환경을 함께 조성하는 게 중요합니다. 그것이 곧 그 팀의 문화가 됩니다. 한 사람이라도 "그거 정말 별로예요."라고 비판이 아닌 비난을 일삼게 된다면, 그리고 그 비난이 당시 상황에서 그저 넘어가게 된다면 암묵적으로 허용되었다는 뜻입니다. 그 순간부터 벽이 허물어져 순식간에 문화가 망가진다고 생각합니다.
이때, 누구든 그게 잘못되었다는 것을 피드백해주어야 합니다.
저도 언젠가 개발을 계속해서 하면서 어떤 팀의 팀장이 되겠지요. 그럴 때 난 어떻게 함께하고 싶은 팀장이 될 수 있을까라고 생각했을 때 이건 참 어려운 문제 같습니다. 책을 바탕으로 제가 미래에 팀장이 되었을 때 스스로 되묻기 위해 정리해 보았습니다.
- 팀원들과 주기적으로 소통하고 업무적으로 피드백을 받는가? -> 여기서 말하는 피드백이란 팀원들이 담당하고 있는 업무가 과하게 어렵거나 지루하진 않은지 파악 (성장할 수 있는 환경을 제공하는가)
- 독재자가 아닌 파트너가 되어 함께 일을 하는가?
- 무언가 하기 전에, 나는 팀원들에게 신뢰 자산을 쌓았는가?
- 나로 혹은 누군가로 인해 문화가 잘못되고 있을 때 잘못되었다라고 명확하게 피드백줄 수 있는가?
팀장에게 정말 솔직하게 업무적으로 소통하는 팀원이 있다고 바라는 건 아닙니다.. 누군가는 면담 자체가 귀찮을 수도 있고 누군가는 문제 인식을 하고 있지만 알리고 싶지 않을 수도 있어요.
그래서 굉장히 이상적이고 희망적이게 보일지 모르겠습니다만 그럼에도 불구하고 할 수 있는 것을 시도해 본다는 게 중요하지 않을까 합니다.
팀에서 이탈하는 팀원이 발생한다는 것은 그게 크든 작든 내가 잠시 점검하고 가야 한다는 신호입니다. 이탈하는 팀원이 생겼다고 해서 무조건 문제가 발생했다는 아닙니다. 약간의 변화가 필요할 수도 있으니 확인하자로 인식해야 합니다.
소프트스킬의 중요성: 경력이 오래 쌓이거나 스킬이 좋은 사람들이 모이면 완벽할까?
저는 이 말에 Yes라고 생각했었습니다. 저자는 단호히 No라고 하지만 어느 정도는 Yes이기도 하겠다는 생각도 듭니다. 애초에 경력이 오래되고 실력이 좋은 분들은 높은 확률로 커뮤니케이션 능력이 좋기 때문입니다. 제가 감히 판단할 부분은 아니지만, 모두가 그런 것은 아니어도 어느정도 확률적으로 그런 분들이 이 필드에서 인정받아 가치를 창출하고 있다고 생각합니다.
책에서는 소프트 스킬의 중요성을 함께 설명하기 위해 단호하게 말합니다. 경력이 오래 쌓이거나 능력이 좋은 사람들을 모아둔다고 해서 좋은 조직이 만들어지는 게 아니다. 즉, 보장되어 있지 않다는 거죠. 흔히 말해 몸값이 비싼 사람들을 모아다가 팀을 꾸려놓고 알아서 해봐라라고 해도 안될 수 있다는 겁니다. 왜냐하면 시스템과 문화에 문제가 있으면 그런 사람도 실력을 100% 발휘할 수 없기 때문입니다. 반대로 시스템과 문화가 좋다면 실력이 월등하지 않아도 능률을 낼 수 있다고 말합니다.
제가 경력과 연차가 쌓이게 된다고 하더라도 고정된 생각을 가지고 타성에 젖어서 머물러 있으면 안 된다는 의미이기도 합니다..
지속적으로 나의 소프트 스킬을 높일 수 있는가? 메타인지가 있는가? 질문하고 답할 수 있어야 하겠습니다.
결국 탁월한 사람들이 모여 각자가 잘하기보다 같이 성장할 수 있는 문화가 있어야 결과물이 더 좋다고 강조합니다.
책 내용을 기반으로 한 나의 경험
책에 나온 것처럼 저도 업무를 진행할 때 다소 지루해진 경우가 있었습니다. 평소에 하던 일과 동일했기 때문입니다. 그래서 책에서 가이드를 제시해 준 대로 난이도를 높여봤습니다. 평소 걸리던 시간을 단축하는 방향이었습니다.
다양한 시도가 있었는데,
VScode에서 단축키를 활용한다거나 반복되고 단순한 작업은 gpt를 통해 html 마크업을 하도록 하거나(보안을 위해 내용은 제외하여 진행) 컴포넌트를 재활용 혹은 리팩토링하여 본인뿐만 아니라 추후 작업자들의 시간을 줄인다거나 무작정 작업하는 게 아니라 큰 틀을 잡고 시작했을 때 평소 시간보다 소요된 시간이 줄어든 것을 확인할 수 있었습니다.
퍼블리셔로 일하던 때에 PL을 담당하여 프로젝트를 진행한 적이 있었습니다. 팀원으로부터 완료되었다고 받은 결과물이 동작하지 않거나 기능이 누락되거나 하는 모습을 보면서 초조해하며 힘들어했던 경험이 있는데, 이때 적극적으로 협력하고 모두 함께 기술적으로 혹은 비즈니스적으로 해결해 나가려고 시도했다면 뜻깊었으리라 생각되었습니다.
개발 업무는 더더욱 비확실성 속에서 진행되기 때문에 그걸 인정하고 함께 해결하려고 노력하고 공유했다면 더 좋은 조직이 되었을 것 같아서 아쉬웠습니다. (181p)
회사에서 신입 개발자로서 기여할 수 있는 부분이 크지 않지만 제가 팀원들에게 줄 수 있는 것을 주고 싶었습니다.
이미 진행 중인 프로젝트에서 당장 기여할 수 있는 건 QA였고, 계속해서 테스트해 보고 결함을 찾아내 문서화하여 정리해 개선할 수 있도록 도우니 개발팀 내에서 좋은 피드백을 받았습니다.
신입(제품을 처음 경험해 보는 고객의 입장이기도 함)인 덕분에 찾아낼 수 있던 버그도 많았으며 주기적으로 제품을 경험해 보면서 비즈니스적으로 깊이 이해해 볼 수 있는 기회도 되었습니다.
해당 업무가 주어진 업무는 아니었기에 좀 더 자유로우면서도 몰입하여 만들어낼 수 있었던 것 같다는 생각도 드네요.
주기적으로 좋은 글이나 행사가 있으면 공유하는 습관이 있었는데 이게 책에도 언급되어서 반갑고 뿌듯했습니다.
쉬운 일에서 시작해 어려운 일로 점차 넓혀가면 정확도가 올라간다는 내용을 읽고 실천해 보았는데 뇌가 받아들이는 저항도 덜하고 몰입에 도움이 되어서 업무가 아닌 곳에도 잘 활용하고 있는 방법 중 하나입니다.
업무 진행에 있어서 비확실성은 어쩔 수 없는 것인데 자꾸 확실성을 바라면서 일을 진행하게 된 것에 깊이 반성했습니다 ㅠ 이러다 보면 스스로 정신적으로 굉장히 피폐하고 스트레스받아서 못 버티게 되는 것 같습니다.. 주기적인 피드백(점검)과 개발만이 방법!
프로젝트 설계에 앞서 팀원분들께 구성하게 될 구조를 설명드렸고 이와 동시에 리드님께도 이런 방식을 원하신 게 맞는지 피드백받을 수 있는 자리를 만들었습니다. 시간은 1시간가량 소요되었는데 프로젝트를 시작하기에 앞서 먼저 짚어가면서 심리적 안전감과 양질의 피드백을 받을 수 있는 시간이었습니다.
이 글을 읽는 여러분들도 이런 식으로 크고 작게 실천해 보시면 큰 도움이 되시리라 확신합니다!!
마지막으로 제가 느끼기에 이 책에서 가장 중요한 부분을 정리해보고자 합니다.
주기적으로 스스로에게 상기시키기 위함이기도 합니다.
- 짧은 주기로 양질의 피드백을 받고 개선해 나가기 (그렇다면 매일 성장할 수 있다 -> 피드백을 받을 수 없다면 스스로 계속 피드백하는 습관을 가져야 함, 회고 등으로 내가 얼마나 기여하고 있는지 정확하게 가치를 제공하고 있는지)
- 기량 향상: 자신의 약점을 개선하려고 애쓰는 수련, 하던 것만 하지 마라
- 내가 가진 정보와 지식들을 적극적으로 공유할 것: 조직과 개개인 성장에 매우 효과적 - 페어 프로그래밍, 코드리뷰 등
- '때문에' -> '덕분에': 환경이 동일하게 주어지더라도 사람마다 해석하는 게 다르다. 주어진 환경에서 Giver가 될 수 있도록 하자.
- 코딩만 하는 게 아니라 협상, 설득, 상호작용할 줄 아는 개발자는 오래간다
- 지루할 경우: 난이도를 높이기 - 항상 하던 일만 할 경우엔 평소 10분 안에 하던 일을 5분 안에 할 수 있는 방법을 강구해 보기
- 불안할 경우: 피드백받기, 난이도 낮추기 - 목표를 작게 쪼개서 작은 성공을 맛보기
- 쉬운 일로 시작해서 점차 난이도 있는 일을 하면 정확도가 높아진다
- 조직에서 무언가 개선하고 도입하기 위해서는 신뢰 자산을 쌓는 게 먼저다
- 복수 공유: 여러 개의 아이디어 및 작업물을 다 함께 보여주고 협력하여 고민하고 결정하다 보면 -> 성과와 신뢰도 UP
결국 이 공유는 심리적 안전감을 바탕에서 시작해야 한다 - 실수 방지가 아니라 실수 관리: 실수하여도 괜찮은 안전망(심리적 안전감)에서 성장이 이루어진다
- 계획하려고 하기보다는 직접 해보면서 고치기
- 고객참여, 리팩토링, 자동화 단위테스트, 코드 공유
제가 내린 결론: 나 자신이 계속해서 내가 하고 있는 일을 점검하며 스스로 질문해야만 성장한다
+ 요즘 드는 생각: 자기계발은 매일 꾸준히! 영양가 없고 책임도 없고 불필요하고 쓸데없지만 재미있는 무언가를 만들어보는 건 나에게 크게 도움이 된다 (매일 코딩할 수 있는 자양분이 됨)
'기록 > 독서기록' 카테고리의 다른 글
| 동물농장 / 조지오웰 :: 서늘하지만 위트있는 풍자 (0) | 2022.08.07 |
|---|