Tag: 배움

시간 관리와 방향성, 그리고 꾸준한 배움

세상은 약한 자나 강한자, 성공한 자와 실패한 자, 만들거나 만들지 못하는 자로 나누는 것이 아니라 배우는 자와 배우지 않은 자로 나뉜다. 

하늘 아래 완전히 새로운 제품은 없으므로 경쟁 제품의 장점과 단점을 파악해서 장점과 단점을 도입하고 개선한다면 사용자에게 좋은 제품을 제공할 수 있다.

측정할 수 없으면 관리할 수 없고 관리할 수 없으면 개선할 수도 없다. 따라서 측정할 수 없는 변화는 의미가 없으므로 제품에 주는 모든 변화는 측정이 가능해야 한다.
지속적인 변화만이 최고의 제품을 만든다.

도그푸딩(dogfooding)이란 내가 만든 개밥을 스스로 먹는다는 뜻으로 본인이 만든 제품을 직접 써본다는 뜻이다. 자신이 만든 제품에 대한 이해가 중요하며 자신이 만드는 서비스를 직접 써보고 경쟁 제품을 직접 분석해봐야 한다.

한마디로 내가 제품을 써보고 좋아해야 사용자도 제품을 좋아하게 된다.

개발은 좋은 제품 만들기가 목적이다. 멋진 코드와 확장성 있는 아키텍쳐도 좋지만 기술은 좋은 제품을 만들어내야 의미가 있다.

제품은 기획자의 인사이트를 넘어 사용자 반응 데이터를 활용해 빠르게 방향과 기능을 결정하며 발전해야 한다. 따라서 좋은 제품을 만들려면 좋은 데이터를 수집하고 분석하는 능력이 필수이다. 

애자일 선언 이면의 원칙은 다음과 같다.

– 최우선 순위는 가치있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다.
– 애자일 프로세스는 변화를 활용해 고객의 경쟁력에 도움이 되게 하므로 개발의 후반부일지라도 요구사항의 변경을 환영한다.
– 작동하는 소프트웨어를 자주 전달하고 비즈니스 담당의 사람들과 매일 함께 일해야 한다.
-동기가 부여된 개인들을 중심으로 프로젝트를 구성하고 필요로 하는 환경과 자원, 그리고 신뢰를 준다.
– 개발팀 내부에서 정보를 전달하는 가장 효율적인 방법은 1:1 대화이다.
– 작동하는 소프트웨어가 진척의 척도이다.
– 기술적 탁월성과 좋은 설계에 대한 지속적 관심이 기민함을 높인다.
– 단순성(안하는 일의 양을 최대화)이 필수이다.
– 팀은 정기적으로 효율을 숙고하고 팀의 행동을 조율하고 조정해야 한다.

애자일(agile)은 각 단계를 너무 작게 만들거나 건너뛰고 빠르게 개발해서 출시하는 개념이 아니라 굉장히 작은 기능, 최소한의 기능으로 최대한 빠르게 개발하는 방법이다.

애자일 이외에도 다양한 개발 방법이 존재하지만 모든 기능은 모든 개발 주기를 거치게 된다. 

애자일은 짧은 주기를 반복하여 큰 프로젝트를 완성해 나가는 방법론으로 유용한 프로젝트 관리 방법으로는 스크럼이나 칸반이 있다.

스크럼은 소규모 팀으로 제품을 기민하게 개발하는 방법으로 스프린트라는 업무 주기를 반복한다.

제품 책임자(Product Owner)가 할 일 목록에서 스프린트동안 수행할 일을 결정하고 스프린트마다 결과물을 산출한다. 팀이 성과를 낼 수 있도록 스크럼 마스터가 장애 요소를 제거하며 프로세스를 인도한다. 

스크럼이 시간을 제한하는 방법론인 반면 칸반은 수를 제한하는 방법론이다. 칸반은 ‘할 일’, ‘진행중인 일’, ‘완료된 일’ 열을 만들고 중요도에 따라 색이 다른 업무로 관리한다. 칸반은 진행중인 일로 옮길 수 있는 업무의 최대 숫자를 제한한다.

애자일을 효과적으로 실천하려면 도구를 사용해야 한다.

프로젝트 관리 도구는 지라(Jira), 협업 문서 관리 도구는 노션(Notion), 소통에는 슬랙(Slack)을 많이 사용한다. 또한 구글 닥스(Google Docs)는 협업 문서를 만드는 최고의 도구로 표현된다. 도구는 프로세스를 구체화하는 것이다.

프로덕트 백로그(Backlog)는 구현해야 할 사항을 정의한 문서로 미래 업무 후보들을 넣어두고 백로그에 있는 아이템이나 사업상 또는 기술적으로 중요한 아이템을 정리해서 분기 계획을 만든다.

출시는 일정 주기로 진행하는 것이 제일 안전하다. 정기적인 출시를 통해 지속적으로 시장의 반응을 확인하기 좋고 안정성 확보에도 도움이 되기 때문이다.

또한 출시에는 항상 위험이 따르므로 롤백에 대한 계획도 항상 필요하다.

동시에 여러 기능을 구현한다면 소스 코드 분리와 통합에 신경써야 한다.

애자일에서 중요한 포인트는 회고이다. 매달 또는 분기에 한 번 정도씩 정기적으로 조직, 기술, 제품, 프로세스에 대해 논의하고 문제 개선 방안에 대해 깊게 살펴보는 과정이다. 

애자일이 원활히 동작하려면 적극적인 소통이 중요하며 소통은 모든 방향에서 원활히 이루어져야 한다. 

매니지먼트는 프로젝트 관리, 팀 관리, 프로세스 관리로 구분한다. 

프로젝트 관리는 출시 시기와 중점을 둬야 하는 일을 관리하는 기술이다. 팀 관리는 사람 관리이며, 프로세스는 진행 과정을 관리하는 기술이다. 

프로젝트 관리는 기본적으로 비용(리소스/인력), 시간(출시일), 제품 범위(기능)를 관리한다. 시간과 인력은 늘 부족하므로 제품의 범위를 줄여야 한다. 기능의 80-90%만 넣어 최소기능제품을 출시하고 지속적으로 기민하게 업데이트하는 방법론이 애자일이다. 이 때 핵심기능을 빠트리면 품질과 경쟁력에 영향을 미치므로 주의해야 한다.

팀을 만들게 되면 forming -> storming -> norming -> performing의 단계를 거치게 된다. 즉 폭풍처럼 싸우고 잔잔해지고 사람들이 친해져서 결과를 만들어내는 단계에 이른다.

여기서 핵심은 신뢰와 지식이다. 팀이 잘 돌아가게 되면 시너지가 생겨 함께 일하며 더 큰 성과를 만든다. 팀 관리자는 팀원에게 큰 그림을 보여줘야 팀에서 위치를 파악하고 자신이 무엇을 어떻게 해야 할지 알 수 있다. 

팀 존재의 이유는 서로의 장점을 공유해서 극대화하고 약점을 보완해주는 것이므로 서로가 강점과 약점을 알아야 한다. 

프로세스란 일을 하는 과정을 정리하는 것으로 한 번 했던 일을 다시 할 때 잘하기 위한 장치이다. 프로세스를 만들면 규격화해 측정할 수 있게 되며 두 세번 반복하면서 최적화할 수 있다. 프로세스 관리는 실패를 막고 우연을 막고 철저하게 품질을 관리하고 최적화하는 과정을 만드는 것이다. 개발 주기, 코드 리뷰 등 개발과 관련된 모든 것이 프로세스에 해당한다. 프로세스가 정립되어야 회사의 현 상태를 측정하고 고도로 최적화할 수 있다.

매니지먼트 역량의 바탕이 되는 다섯가지 소프트 스킬은 소통, 협업, 긍정적인 자세, 프로 의식, 리더십이다. 매니지먼트 역량은 직원에게도 필요하며 더 멀리 내다보고 자신이 바라는 관리자 모습을 그려보고 관리자를 해당 방식으로 유도해야 한다.

소통에는 투명성이 중요하며 투명성이란 사람들이 알아야 할 정보를 충분히 공급해주는 것이다. 상사가 투명하게 이야기하면 더 쉽게 의도가 전달되고 부하는 상사를 더 쉽게 예측할 수 있다. 투명성과 예측 가능성이 확보되면 직원에게 자율성이 생긴다. 자율성이 보장될 때 창의성이 발현되고 직원은 더 행복해지므로 결과적으로 더 나은 성과를 도출하게 된다. 투명성은 개방성과 함께일 때 더 빛을 발하며 리더라면 개방성을 갖고 경청할 줄 알아야 한다. 결국 투명성과 개방성이 소통의 핵심이다.

협업은 논쟁 테이블 위에서 벌어지는 관철과 양보의 줄다리기이다. 좋은 리더는 협업을 잘해야하고 그러려면 8할을 양보해야 한다. 제대로 된 협업은 이견이 생길 때 모두의 의견이 조금씩 관철되어야 하는 것이며, 한 사람이 항상 이기는 것은 욕심에서 비롯된 문제이다. 좋은 리더라면 작은 것을 버리고 큰 것을 얻어야 한다. 중요하지 않은 일은 원하는 대로 하게 두고 정말 중요한 일을 관철하도록 해야 한다. 중요한 일에는 물러서지 말고 끝까지 이겨야 한다. 건강한 조직이라면 협업 테이블에서 치열한 논쟁이 벌어져야 최고의 선택을 할 수 있다.

여기서 양보란 무관심이 아니라 자율 선택권을 주는 양보와 타협이다. 

리더십에서 중요한 것 중 하나는 인사이트로 현재 시장을 파악하고 향후 변화의 큰 물줄기를 분간하는 능력이다. 인사이트가 있어야 기술 변화를 내다보고 개발 방식과 방향을 결정할 수 있다. 리더에게 인사이트가 없으면 개발만 하다가 도태될 가능성이 크다.

인사이트를 계발하기 위해서는 좋은 책과 좋은 사람 그리고 비판적 사고가 중요하다. 이를 통해 얻어진 것들을 실제 업무에 적용해보고 비판적 사고를 확장하면서 좋은 피드백을 반영해 나갈 때 집단 지성을 이끌어내며 발전할 수 있다.

중간 관리자의 역할은 프로젝트 리딩, 테크니컬 리딩, 피플 매니징이다. 세 가지를 모두 다 잘하기는 쉽지 않으므로 관리자는 본인이 잘하는 부분에 집중하고 부족한 부분은 도움을 받아 메워야 한다. 하지만 각 역할에 대해 명확한 이해는 필요하다.

개발 주기는 요구 사항을 분석하고 시스템 구조를 설계하고 개발하고 테스트와 출시하고 피드백을 받아 업데이트하는 전체 과정이다. 최소한의 개발 계획을 갖고 계획 안에서 실행해야 리소스가 관리된다. PM은 전체 과정과 목표를 이해하고 리소스를 관리해야 하며 프로젝트 관리를 하면서 연 단위, 월 단위, 일단위 계획을 세워야 한다.

계획을 세우는 이유는 완벽한 준수를 위해서가 아니라 성공을 위해서 세우는 것이다. 따라서 상황에 맞게 수정하면서 대비해야 한다. 

우선 순위 정하기와 시간을 효율적으로 관리해야 성공적으로 제품을 출시할 수 있다.

역할은 팀 크기에 따라 달라질 수 있으며 사람들이 적절히 부딪히며 일할 수 있게 역할을 정의해야 한다. 완벽히 격리된 역할을 주면 의욕이 떨어지고 역할 이기주의에 빠질 수 있다. 따라서 모든 사람에게 기본적인 역할을 정해주되 약간은 자기 범위 밖에서 일할 수 있도록 자유를 제공해야 생산적인 충돌이 발생하여 협동이 원활해진다.

시간을 아끼는 최고의 방법은 낭비를 없애는 것이다. 시간을 잡아먹는 요인은 필요없는 코드, 개발 과정에서 준비 미비로 인한 기다림, 불명확한 요구사항, 내부 정치, 느린 내부 소통이 있다.

필요없는 코드는 요구 사항이 명확하지 않거나 기술 구조를 잘 정의하지 않았을 때 발생하므로 요구 사항을 명확히 정의하고 기술 구조를 초기에 제대로 잡아야 한다.

시간을 아끼기 위한 방안 모색으로 미팅이나 워크숍보다는 일상에서 하나씩 낭비를 줄이는 방식이 낭비를 만들지 않는 더 효과적인 방법이 될 수 있다.

때로는 돈을 더 많이 버는 것보다 덜 쓰는 게 더 쉬운 방법이 될 수 있는 것처럼 낭비를 줄이면 업무 효율과 생산성이 올라간다. 생산성을 올리는 방법은 모두를 바쁘게 하는 것이 아니라 낭비를 없애고 서로에게 병목이 되는 요소를 없애는 것이다.

문제는 항상 발생하고 일이란 문제를 잘 정리하고 계산하고 해결하는 행위이므로 문제가 재발되지 않게 하는 것이 중요한 것이다. 따라서 문제를 싫어하지 않는 것이 중요하다. 

문제 해결 시스템을 통해 시간 낭비를 줄일 수 있으며 문제 해결을 나누는 단계는 다음과 같다.

1 문제 고르기
2 고른 문제 정의하기
3 문제 분석하기
4 해결책을 찾고 최선의 해결책 선택하기
5 선택한 해결책 실행여부 승인받기
6 문제 해결 확인하기

문제 해결의 핵심은 하나의 해결책만 적용하는 것이 아니라 여러 해결책을 고안하고 그 중에서 제일 좋은 해결책을 고르고 실패 시 다른 해결책을 적용하는 것이다. 하나의 해결책만으로는 적용 실패 시 더 위험한 상황이 올 수 있기 때문이다.

제한된 시간을 효과적으로 사용하려면 산적한 문제를 효과적으로 분류하고 대응해야 한다. 문제의 경중과 해결 가능성을 따져서 중요하고 풀 수 있는 문제는 풀고 중요하지만 풀 수 없는 문제를 미뤄두고 중요하지 않지만 풀 수 있는 문제는 위임한다. 그리고 중요하지도 않고 풀 수도 없는 문제는 무시하는 것이 중요하다. 이를 통해 시간의 낭비를 줄이고 해결할 수 있는 문제에 집중하여 재발하지 않는 해결책을 만드는 것이 효율적으로 프로젝트를 리드하는 방법이다.

프로젝트 관리는 우선 순위를 정하는 것이 중요하다. 우선 순위대로 일하고 문제를 해결하고 낭비를 없애 사람들의 역할을 연결해야 한다. 우선 순위의 기본은 시급성과 중요성에 있다. 대게는 생각할 시간이 없고 눈앞에 닥친 일만 하다보니 급한 것 위주로 일을 하게 된다. 그러나 급한 일의 늪에 빠지지 않고 중요한 일을 해야 한다. 할 일을 고를때는 시급성을 따지지 말고 한 발 물러서서 중요성에 따라 일을 진행해야 한다. 따라서 중요하고 급한 일로 분류될 일을 먼저 처리하고 난 뒤 중요하고 급하지 않은 일 위주로 처리하면 자신의 삶과 시간을 주도하면서 살 수 있다. 급한 일만 하게 되면 일에 쫓기고 끌려다니게 된다.

테크니컬 리드는 실현 가능성과 기술의 이점을 고려해야 하며 개발 환경 자체도 최적화해야 한다.

프로젝트 리드가 what to do를 고민한다면 테크니컬 리드는 how to do를 고민한다. 남이 안 만든 서비스를 출시해야 성공 가능성이 높으므로 테크니컬 리드는 모르는 일을 어떻게하면 잘할 수 있을지 고민해야 한다. 초보 개발자는 시키는 일을 잘하고 중급 개발자는 시키지 않아도 잘하고 고급 개발자는 남에게 시키는 일을 잘하면 된다. 그보다 위는 모르는 일과 한번도 안해본 일을 하는 것이다.

필요한데 모르는 일에는 리소스가 얼마나 투입될지 알 수 없으므로 필요하지만 잘 모르는 일을 먼저 진행해야 한다. 어렵고 큰 일이나 모르는 일을 먼저 해야 하며 성공을 목표로 한다면 어려운 문제를 먼저 푸는 게 좋다. 테크니컬 리드가 이를 관리해야 하고 모르는 일을 잘게 쪼개고 나눠서 모르는 일 하나를 아는 일 100개로 만들어야 한다. 모르는 것을 아는 것으로 바꾸는 능력이 테크니컬 리드에게 가장 중요하다.

일은 올바른 방향으로 빠르게 가는 게 가장 좋지만 대게 일은 잘못된 방향으로 엄청 느리게 간다. 따라서 성공보다 실패하는 제품이 많다. 프로젝트는 성공하더라도 제품은 실패할 수 있다. 프로젝트를 진행하면서 일이 너무 잘 돌아간다면 멈춰서서 돌아봐야 한다. 속도보다 방향에 중요하므로 항상 바른 방향으로 가고 있는지 점검해야 하며 속도에 집중하면 안된다. 이 방향에 대한 확인 작업을 짧은 주기로 진행하는 것이 애자일 방식이며 목적지에 따라 방향을 수시로 수정하며 개발해야 한다. 따라서 느리더라도 올바른 방향의 선택이 중요하다.

일은 make it working, make it right, make it fast의 격언과도 같다. 먼저 방향을 정해 일을 시작하고 일하는 방식을 개선한다. 그 후 모든 것이 정해지면 속도를 올리는 방식으로 단계별로 접근해야 한다. 모든 일에는 지속 가능성이 중요하므로 속도보다 방향이 중요하다. 지속가능한 성공이 중요하므로 항상 방향과 지속적이고 안정적인 속도에 집중해야 한다.

최소기능제품을 만들 때는 기능만큼 기술도 중요하다. 빨리 만들려면 알려진 기술을 써야하고 개발 속도를 높이려면 개발 환경이 좋아야 한다. 물리 환경까지 쾌적하게 만들고 최적의 개발 방법론을 적용해 짧은 주기의 속도감 있는 개발을 진행해야 한다. 개발 과정에서 기술 부채가 늘어나지 않도록 상황과 전략에 맞춰 개발을 해야 한다. 경쟁력은 기획에서 나오므로 좋은 기획을 빠르게 구현하는 개발 역량을 키워야 한다.

사람은 저마다의 성향이 있으며 why, what, how로 구분할 수 있다. 각각 고객, 제품, 기술에 대한 집중도를 나타낸다. 미국 회사에는 여러 성향의 사람이 섞여 있어 프로젝트 진행 시 성향별로 질문이 고르게 나오는 장점이 있다. 

관리자라면 팀을 구성할 때 성향을 골고루 배치하는 것이 좋으며 각각의 성향이 다를수록 시너지를 낼 수 있어서 좋다. what if의 성향은 굉장히 독특하거나 큰 기여를 하기도 하므로 엉뚱한 말을 하는 사람이 있더라도 다양성을 존중해주는 것이 중요하다. 

일의 진행 시점별로도 일을 시작하는 사람, 일을 수행하는 사람, 일을 마무리하는 사람이 있다. 각각의 성향을 잘 섞어주면 좋은 효과를 낼 수 있다. 프로젝트 초기에는 시작하는 사람이 많을수록, 출시 직전에는 마무리하는 사람이 많을수록 좋다.

관리자와 직원의 관계는 정확한 기대치를 알려주고 결과가 나왔을 때 좋았던 점과 아쉬웠던 점을 알려주며 피드백을 주는 사이가 좋은 관계이다.

관리자는 직원의 성과, 행복, 성장에 신경써야 한다. 관리자도 리소스의 일부이므로 직원이 일을 잘 할 수 있도록 돕는 사람이 되어야 한다. 직원이 스스로 성과, 행복, 성장을 확인하고 관리자를 사용하도록 해야 한다. 관리자가 모든 것을 다 해줄 수는 없으므로 스스로 자신의 역량과 행복을 이끌어 내도록 도와주는 역할을 한다. 성과를 확인할 때는 개인이 일을 잘하는지, 팀이 잘하는지, 무엇을 잘했는지, 무엇이 힘들었는지 구체적으로 질문해야 하며 가장 중요한 것은 회사 차원에서 일이 잘 진행되는지, 개인이 만족하는지, 의미있는 일을 하는지의 여부이다. 

훌륭한 개발자의 7가지 요건은 다음과 같다.

– 생산성 (의미있는 제품과 코드를 많이 만드는지)
– 프로의식 (책임감)
– 팀워크 (협업, 소통)
– 지식 (도메인, 소프트웨어)
– 기능성 (제품성)
– 코딩 능력 (코드의 간결함)
– 구조 설계와 아키텍쳐

회사는 위 기본을 갖춘 사람의 성장을 도와야 하며 성과와 성장이 연결되지 않으면 현재의 성과가 지속될 수 없다. 지금 성장해야 미래의 성과도 보장되는 것이다.

직원은 회사에서 의미있는 일을 했을 때 가장 큰 행복과 만족감을 느낀다. 회사에 자신이 기여를 했다고 느낄 때 자존감이 생기고 자존감이 높아질 때 직원은 행복을 느낀다. 사내에서 직원의 행복은 일과 관련된 것이어야 한다. 일을 하는 이유는 일 자체의 즐거움, 일을 통한 성장, 비전, 목표와 일과의 연결성이다. 생각한 꿈과 현재의 일이 연결되어 있으면 하는 일이 힘들지 않다. 먼 미래가 아닌 10년 후, 5년 후, 내일하고 싶은 일을 정해두어야 과정에서 오는 시련을 이겨낼 힘이 생긴다. 직원이 성장해서 다른 회사를 가게 되더라도 아깝지만 어쩔 수 없다. 오히려 성장하지 못하는 직원이 회사에 짐이 된다.

하고 싶은 일을 계획해두면 계획대로 살게 된다.
세상은 계획을 가진 사람의 계획대로 움직이는 것이다. 

관리자라면 팀원에게 원하는 바를 듣고 도와주는 성장형 조직을 만들어야 하며 스타트업이라면 특히 더욱 중요하다. 

성장은 역량, 잠재력, 현재 성과를 함께 살펴야 한다. 성과는 역량보다 아래에 있으므로 역량을 넘어서는 일을 하면 실패하기 마련이다. 역량과 비슷하거나 조금 더 어려운 일을 수행하면 크고 작은 실패를 경험하면서 성장하게 된다. 역량도 근육과 같아서 비슷하거나 조금 높은 수준의 일을 해야 역량이 높아지며 쉬운 일은 아무리 많이 해도 역량이 늘지 않는다.

잠재력은 높은데 역량이 자라지 않는다는 고민이 생긴다면 쉬운 일만 해서 그런 것이다. 어려운 일을 통해 실패를 경험하고 깨달음을 통해 역량을 올려야 잠재 능력을 실현할 수 있다. 실패는 초기에 하는게 좋으며 감당할 수 없는 큰 실패나 막바지 실패를 하지 않도록 유의해야 한다. 사람은 성공만이 아니라 실패에서도 배우므로 실패에서 교훈을 얻고 성장할 수 있도록 성공과 실패 요인을 분석하고 다시 시도할 때의 방법을 고민한다. 

프로세스는 모든 것의 바탕이다. 제품, 기술, 사람 등 모든 영역에서 프로세스가 필요하다. 문서와 인력으로 진행하는 프로세스는 언제 어긋날지 모르므로 모든 프로세스는 최대한 시스템에 녹여내는 게 좋다. 사내 프로세스가 동일해야 다른 조직 업무에 투입되어도 빠르게 일할 수 있으므로 시너지를 낼 수 있다. 회사가 커질수록 프로세스를 통일시키는 것이 중요하므로 회사가 작을 때부터 프로세스를 통일하는 것이 좋다. 

혁신적인 아이디어는 어디서든 얻을 수 있다는 신념을 가지고 업무 시간의 15%를 아이디어 창출에 사용하는 3M의 원칙은 혁신을 이끄는 원동력으로 볼 수 있으며 지속적으로 최적화하는 회사의 좋은 사례이다. 회사의 생애 주기 진행 속도는 회사마다 천차만별이며 생명을 길게 가져가기 위해서는 프로세스가 제대로 잡혀있어야 한다. 

프로세스 관점에서 팀 성과는 개인 성과와 다르다. 팀 성과 평가는 생산성, 소통, 프로세스를 기준으로 평가한다. 모든 조직에는 문제가 있으며 문제를 해결하려면 프로세스가 제대로 세워져 있어야 한다. 

회사를 네 가지 관점에서 점검할 수 있는 balanced card는 재정 안전성, 고객의 제품 만족도, 내부 프로세스, 교육과 성장이다.

재정 안전성은 매출과 지출 규모를 통해 확인한다. 고객을 만족시키려면 고객을 생각하며 제품을 개발해야 하며 고객이란 회사 외부만이 아닌 내부에 있는 모든 직원도 고객이다. 모두가 제품을 사용하고 좋아해야만 성공할 수 있다.

프로세스는 일이체계적으로 돌아가는지에 대한 여부이며 교육은 직원과 회사가 함께 성장하기 위한 방법이다. 

변화는 회사에서 매우 중요한 부분으로 회사는 변하지 않으면 망하지만 변화는 어렵기 때문에 매우 조심히 관리해야 한다. 변화는 한 군데에서 시작하지만 모든 분야로 퍼져나가며 변화가 무뎌질 때 조직에 어려움이 온다. 

비전이 정립되어 있으면 회사가 하나로 뭉쳐 비전 안에서 문화가 탄생한다. 비전에 대한 세세한 가이드나 사상을 핵심 가치(core value)라고 하며 핵심 가치를 정하고 지키면 조직 문화가 만들어진다.

문화는 미리 세워진 가치와 정책에 의해 결정되므로 비전과 가치가 결정되어야 문화가 따라간다.

조직 문화는 사람들이 생각하고 행동하고 일하는 방식이다. 문화는 제품, 기술, 프로세스의 바깥 영역에서 돌아가며 사람들이 생각하고 행동하고 해야할 일을 자연스럽게 결정해주는 큰 개념이다. 제품, 기술, 프로세스가 결과에 가깝다면 조직문화는 모두를 아우르는 운영체제에 가깝다. 운영 체제에 따라 프로세스가 만들어지고 프로세스에 따라 모든 일이 결정된다. 

직원을 채용할 때는 좋은 사람을 뽑는데 집중하기보다는 잘못된 사람을 뽑지 않기 위해 노력해야 한다. 좋은 회사를 다녔다고 해서 좋은 사람인 것은 아니므로 이전 회사에서 어떤 일을 했고 어떤 성공과 어떤 실패를 경험했는지가 중요하다. 한 사람의 경력을 회사를 기준으로 봐서는 안되고 좋은 회사를 짧게 다녔어도 위험할 수 있다. 반대 입장에서도 마찬가지이므로 채용을 대충 진행하는 회사가 있다면 대충 채용한 사람들과 함께 일하게 되는 것이다. 

면접관은 지원자를 너무 마음에 들어하면 객관적인 평가를 하기가 어렵다. 블리자드는 면접 후 면접관이 모여서 점수로 투표하는데 최고점과 최저점을 제외한다. 본인과 코드가 맞는다는 이유만으로 최고점을 주거나 반대의 경우가 발생할 수 있기 때문이다. 따라서 지원자도 면접 분위기에 따라 당락의 기준을 잡는 것이 아니라 전문 지식과 이력에 집중해야 한다. 

프로세스는 도로 체계와 같아서 좋은 프로세스라면 문제가 발생하지 않아야 하며 적합하고 효율적이어야 한다. 잘 만든 프로세스는 반복해서 사용하는 것이 중요하며 기술, 서비스, 문화의 변화에 맞게 프로세스도 변해야 한다. 그리고 프로세스는 데이터를 근거로 해야 한다. 

개발자가 실력을 키우는 방법은 공부하고 반복하고 경험하기다. 개발자는 어떤 자리나 회사를 목표로 하는 것이 아니라 어떤 사람이 되거나 어떤 것을 해야겠다는 것을 목표로 삼아야 한다. 어떤 회사에 지원하는 이유는 그 곳에 하고 싶은 일이 있어서이다. 따라서 나의 역량에 집중하면 기업의 흥망과 상관없이 내가 원하는 일을 할 수 있게 된다.

이력서는 지원하는 회사에 최적화해서 해당 회사에 왜 가고 싶은지, 왜 뽑아야 하는지, 무엇을 하고 싶은지를 이력서에 꼭 써서 제출해야 한다. 그동안 해온 일과 지원하는 회사를 매칭해야 하며 읽는 사람이 보고싶어 할 내용으로 최적화해야 한다.

코딩 테스트는 기초 지식과 연결되며 알고리즘 문제의 난이도가 높아짐에 따라 업무만으로는 테스트를 통과하기가 쉽지 않다. 따라서 시니어라도 코딩테스트를 따로 준비하는 게 좋으며 과정이 무의미하다고 생각할 필요는 없다.

역량이 없는 상태에서 취업 성공은 위험하다. 역량이 있으면 다시 시도할 수 있으므로 실패하더라도 역량을 키우는 실패가 낫다. 역량없이 이룬 성공은 우연이며 우연은 반복되지 않는다. 한 프로그램을 여러번 다시 만들어보면 더 잘 만드는 방법을 고민하게 되고 개발 역량이 자란다.

면접 시 지원 동기를 묻는 질문은 중요하며 모범 답안은 이직할 회사의 서비스나 기술에 대한 흥미이다. 

소프트웨어 개발자로 성공하는 3가지 요소는 재능, 노력, 기회이다. 재능이 있더라도 많은 노력이 필요하며 지속적으로 노력하면 언젠가는 기회가 찾아오기 마련이다. 따라서 기회가 올 때까지 자신에게 집중하고 가고자하는 길을 구체적으로 그려보고 필요한 역량을 채워나가면 된다. 

스티브 잡스가 똑똑한 사람들을 고용해서 무엇을 할지 알려주는 것은 이치에 맞지 않으므로 그들을 고용해서 우리가 무엇을 해야할 지 알려줄 수 있도록 해야한다고 하였다. 그러므로 스타트업은 새로 채용한 사람의 말을 듣고 기존 아이디어와 새 아이디어가 합쳐져 자연스럽게 제품이 진화하도록 해야 한다. 이후 제품을 빠르게 출시하고 반응을 보면서 계속 업데이트하는 지속적인 피봇팅(pivoting)이 중요하다.

기술의 우월성도 중요하지만 시장에서 최고의 기술만이 대표 상품이 되는 것은 아니다. 잘 만들었다면 역시 잘 팔아야 한다. 조금 느리더라도 변화를 계속 만들고 변화에 유동적으로 방향을 맞춰야 탁월한 기술력이 빛을 발하고 사업을 지속적으로 영위할 수 있다.

모든 것을 잘하는 직원은 훌륭한 관리자가 필요없지만 반대로 문제가 많은 직원에게는 훌륭한 관리자가 필요하다. 따라서 훌륭한 관리자가 되고 싶다면 문제있는 직원을 만나고 훌륭한 직원이 되고 싶다면 문제있는 관리자와 일해야 성장한다. 다른 사람의 약점은 자신의 강점을 키울 기회이다. 

개발자는 기술적, 제품적인 면에서 실패할 가능성을 파악하고 제거해야 하며 성공은 시장이 결정하지만 실패는 개발자가 의도치않게 만들어낼 수 있다.

경쟁 회사가 만든 제품도 써보고 분석도 해야 하지만 그와 같은 제품을 만들 수 있었던 과정인 회사의 조직 문화도 확인하고 문화를 개선해야 한다. 

기민한 조직이 되려면 모두가 비전을 정확하게 맞춰야 하고 목표 달성에 헌신하지 않을거라면 뒤로 물러나야 한다.

쇠사슬의 강도는 가장 강한 부분이 아니라 가장 약한 부분이 결정하므로 다양성도 이 관점에서 보고 약한 부분을 빨리 발견하는 것이 좋다. 다양성이 있는 문화는 모두가 기여하고 싶어하므로 자신의 생각을 이야기하고 이런 환경에서는 문제와 약점을 조기에 발견하고 개선할 기회가 주어진다. 

일을 어제처럼 하면 어제만큼의 성과만 나온다. 따라서 더 나은 성과를 만들려면 한계를 뛰어넘는 것이 아니라 한계를 치워버려야 한다. 

조직 문화에 변화를 주려면 변화를 하겠다는 말을 하지 않고 천천히 조금씩 안 보이게 시도하는 것이 중요하다. 변화를 이야기하는 순간 오랜 시간 체득한 습관을 바꾸어야 하므로 쉽게 움츠러들기 때문이다. 습관은 개인에게 해당하는 프로세스로, 변화를 만들려면 습관을 바꿔야 하고 습관을 바꿀 때는 작은 것부터 시작해야 한다.

조직이 애자일하다는 것은 실무자한테 권한을 더 주는 것이다. 실무자의 의견을 많이 들어야 빨리 움직일 수 있다. 한 사람만 결정권을 가지고 있으면 속도가 나올 수 없으므로 모두가 결정권을 가지고 있어야 한다. 정책, 시스템, 문화를 바꾸고 실무자에게 권한을 주고 리더 교육을 진행할 때 변화가 생기고 변화가 조직 문화를 바꾼다. 

개인이 모여 조직과 회사가 되므로 회사가 변하려면 구성원 개인이 변해야 한다. 일본 경제학자 오마에 켄이치(大前研一)가 말하는 사람이 바뀌는 세 가지 효과적인 방법은 다음과 같다.

– 시간 배분을 변경한다. (時間配分を変える)
– 사는 장소를 바꾼다. (住む場所を変える)
– 함께 어울리는 사람을 바꾼다. (付き合う人を変える)

그리고 새로운 결심이 가장 무의미하다. 

직원이 오래 근무해야 조직과 회사가 오래가고 다양한 일을 경험해 볼 수 있는 문화를 만들어야 큰 그림을 볼 수 있다. 따라서 다양한 직군의 사람과 교류하는 것이 중요하다.

무작정 모든 것을 열심히 하기보다는 시간 관리가 중요하다. 효율보다는 생산성이 중요하므로 중요한 일을 잘하는 것이 중요하다. 속도보다 방향이 중요하므로 시간을 아껴서 뭔가를 빠르게 해내는 것이 아니라 정해진 시간 안에 무엇을 어떤 방향으로 어떻게 할지 고민해야 한다.

시간 관리는 시간을 쓰는 프로세스를 바꾸는 것이다. 항상 목표와 계획을 세우고 실천한 뒤 측정해야 하며 반복을 통해 최적화를 해야 한다. 시간을 쓸 때도 목표를 세우고 그 안에서 계획을 만든 뒤 실천하고 반복한다. 어떤 일을 하든 일하는 방식 자체를 체계적으로 관리해야 시간도 체계적으로 쓸 수 있다. 계획을 세우는 것은 목표가 있다는 것이며 목표가 계획을 만들게 한다. 바쁘기만 한 평범한 직장인이 일상에서 벗어나지 못하는 이유는 계획이 없기 때문이다.

혼자만의 몰입이 팀과 회사의 성과에 도움이 되어야 하며 혼자 풀지 못하는 일은 주변에 도움을 요청해야 한다. 결국 도움을 요청하는 것이 시간을 절약하는 것이다. 따라서 일을 시작할 때는 기한을 정하고 중간 점검을 통해 몰입의 역기능을 방지하고 팀 전체의 시간을 관리해야 한다.

사람은 자기가 하는 일을 남에게 주지 않고 끌어 안으려는 경향이 있으므로 계속 버리는 연습을 해야 한다. 

결과를 바꾸고 싶으면 과정을 바꿔야 한다. 결과에 차이가 없다면 일하는 방식, 즉 시간을 쓰는 방식을 바꿔야 한다. 방식을 바꾸려면 쓰는 시간을 측정해서 전체 상태를 파악하고 쓰는 시간을 바꿔서 방향을 바꿔야 한다. 

쓴 시간을 측정하는 목적은 최적화이다. 최적화의 우선 순위는 가장 덩치가 큰 것부터다. 시간 최적화는 낭비를 없애 일하는 방법으로 낭비만 없어져도 시간 관리에 큰 도움이 된다. 주식과 마찬가지로 시간을 벌려면 시간을 써야 하며 바쁠수록 시간을 잘 사용하고 있는지 체크해야 한다. 

회의는 프로덕트가 아니므로 일하는데 시간을 써야 한다. 따라서 회의를 시간을 잡아먹는 하마라고 생각하고 꼭 필요할 때만 써야 한다. 

브레인스토밍 회의는 회의에 적합하지만 정보 전달회의는 이메일이 더 적합하다. 토론 회의는 많은 준비가 필요하므로 준비하지 않으면 생산적이지 않고 정보 전달에 그치므로 미리 자료를 공유하고 아이디어를 가지고 모여야 한다. 따라서 토론 회의는 정말 준비된 사람들만 모여야 한다. 

휴식도 시간을 사용하는 행위이며 계획적으로 몰입해서 쉬어야 효과가 좋고 창조 능력을 유지할 수 있으며 더 효율적으로 일할 수 있다. 

어느 직군이나 똑같겠지만 시간 관리와 방향성 그리고 자신의 분야에 대한 꾸준한 관심과 연구, 학습만이 오래도록 즐겁게 일을 할 수 있게 해주는 묘약인 것 같다.