'OLIVE LAB'는 오늘도 성장을 갈망하는 일잘러들을 위한 뉴스레터 입니다.
올리브영의 조직 성과와 조직 건강의 지속 성장을 연구합니다.
한 주간 인상깊게 읽은 비즈니스, 리더십, 매니지먼트, 조직문화 관련 아티클을
요약 정리해서 정성껏 담아 보내드립니다:D (마음에 드는 글에 '👍좋아요'도 눌러주세요)
✍️응원, 소감, 궁금하신 내용 그리고 함께 나누고 싶은 내용은 댓글로 남겨주세요.
개발자 경력을 위협하는 나쁜 습관들 (Chad's Pick)
"좋은 개발자의 정의는 개인마다 모두 다를 것 같습니다. 그렇기에 좋은 개발자의 정의에 대해 다른 사람들의 의견을 듣고 나누는 것이 도움이 될 수 있습니다. 아를 통해서 다른 사람의 관점을 배울 수 있습니다. 여기 좋은 개발자가 되기 위해 피해야 하는 습관들에 대한 글이 있어 공유합니다. 이 글의 소개하고 있는 나쁜 습관들 하나하나에 대한 가치 판단은 여러분들이 몫일 겁니다. 하나하나 살펴보고 선택하고 자신의 가치관과 통합하여 모두가 더 좋은 개발자가 되시길 기원합니다."
- 개발자로서 앞서 가는 과정은 좋은 코드를 지속적으로 제공하는 능력에 달려 있습니다. 그리고 당신이 팀플레이어라는 사실도 중요합니다. 경력이 쌓이면 팀워크가 어떤 기술적인 도전보다 발전의 장벽이 됩니다. 불행히도 성장을 방해하는 나쁜 습관은 일반적인 모습으로 나타납니다. 여기 나쁜 습관들을 소개합니다.
- 영웅되기 - 좋지 않은 습관은 스스로를 영웅이라고 생각하는 것입니다. 스스로 영웅이 되어 팀의 모든 문제를 스스로 해결하는 이유는 무엇인가요? 한사람이 혼자 일하는 것보다 팀의 지혜와 함께 일하는 것이 훨씬 나은 해결책을 만들어 냅니다.
- 다른 사람들이 해결책을 제시하기를 기다립니다. - 엔지니어가 지침이나 도움을 기다리는 경우가 너무 많습니다. 티켓을 받고 정의된 대로 작업을 수행하며 그 이상의 질문을 하지 않습니다. 단순히 지시를 따르는 사람이라면 더 복잡하고 자율적이며 창의적인 엔지니어링 역할로 나아가지 못할 것입니다.
- 피드백과 비판 피하기 - 피드백은 듣기 어렵지만 성장에 필수적입니다. 최고의 엔지니어는 피드백을 받고 통합하는 방법을 조기에 배웁니다. 그들은 피드백을 요청하고 이에 응답하는 습관을 기릅니다. 그 과정에서 어떤 피드백이 정당하고 어떤 피드백을 걸러야 하는지에 대한 감각을 개발합니다.
- 일관성이 부족합니다.(Being Sporadic). - 최고의 엔지니어는 일관성이 있습니다. 성취도가 낮은 엔지니어도 뛰어난 순간이 있습니다. 하지만 그런 엔지니어는 부진한 성과, 미루는 습관, 번아웃의 계곡을 지나며 낮은 성과로의 균형을 만들어 냅니다. 훌륭한 엔지니어는 꾸준히 무언가를 제공함으로써 결과가 나온다는 것을 알고 있습니다.
- 호기심과 목적을 희생시킵니다. - 최고의 엔지니어라도 인간으로서의 의미와 목적을 훼손하는 일을 계속할 수는 없습니다. 목적의식과 연결하는 것은 개발자 경력을 쌓는데 중요합니다. 돈을 버는 일에만 몰두하지 마세요. 호기심과 목적을 희생하면 번아웃이 옵니다. 호기심을 유지하고 참여하고 사명감을 가질수 있는 방법을 찾으세요.
- 매니저 스케쥴에 빠집니다. - 하루 종일 회의하는 것이 매니저의 스케쥴입니다. 우리는 제작자입니다. 우리는 일을 끝내기 위해 방해받지 않는 긴 시간이 필요합니다. 최고의 엔지니어는 자신의 시간을 보호합니다. 불필요한 회의에 나가거나 일괄적으로 조정된 회의에서 빠지는 방법을 찾습니다.
- 참을성이 없습니다. - 성급한 개발자들은 조직이 의사결정을 내리는 방법, 시장의 압박에 대해서 알지 못합니다. 하지만 이런 것들을 배워야 하는 순간이 있습니다. 개발자는 다른 사람이 운명을 결정할때까지 기다리면 안됩니다만, 동시에 성급하게 행동해서도 안됩니다. 이러한 균형을 배우는 것이 개발자 경력을 성장시키는데 중요합니다.
이런 피드백은 무시해도 좋아요 (Eddy's Pick)
"우리는 다양한 피드백을 받고 살아갑니다. 그리고 모두에게 좋은 피드백을 받지 못해 마음 아파하기도 합니다. 모든 피드백에 신경써야 할까요? 어떤 피드백은 무시해도 될까요? 무시해도 좋을 피드백을 소개합니다."
- 피드백이 도움이 되지만, 모든 피드백을 똑같은 비중으로 받아들일 필요는 없습니다. 개중에는 무시해도 좋을, 오히려 도움이 전혀 안 되는 피드백이 있으니까요. 어떤 피드백을 무시해도 좋을까요?
- 첫째, 막연한 피드백. 특별한 근거 없이 그냥 느낌이 그렇다는 식의 피드백은 들을 필요가 없습니다. 그래도 뭔가 도움이 되는 부분을 찾고자 한다면, '왜 그렇게 생각하세요?'라고 꼭 물어보세요. 이 질문에 제대로 답을 못한다면 그냥 무시해도 좋습니다.
- 둘째, 혼자만의 의견. 유독 어떤 사람만이 완전히 반대되는 내용으로 피드백을 준다면 일단 거리를 두세요. 그 의견이 타당한지 곰곰히 생각해보고 '아니'라는 판단이 들면 무시해 버리세요. 그 사람이 쳐놓은 감옥에 스스로 갇히지 마세요.
- 셋째, 인신공격성 피드백. 이건 당연히 무시해 버려야 하는 피드백입니다. 하지만 많은 이들이 '악플'을 피드백으로 여기고 가슴앓이를 합니다. '손절'만이 답입니다.
- 넷째, 출처가 명확하지 않은 피드백. '누가 그랬다더라'식의 피드백은 심각하게 생각하지 마세요. 일부러 제3자를 끌어들여서 자신의 생각을 돌려말하는 것일 수 있습니다. 비겁하게 말이죠. 그렇게 자신 없는 피드백은 진정성이 없으니 무시해도 좋습니다.
- 좋은 피드백은 취하고 나쁜 피드백은 무시하는 법을 연습하는 것이 피드백을 잘 받는 것만큼이나 중요합니다.
MVP와 PoC, Prototype, Pilot 차이 (Woody's Pick)
"우리 조직에서 혹시 MVP를 최소 기능 제품이나 순차적 오픈의 1단계로 바라보고 있진 않나요? MVP의 의미와 다른 비슷한 용어인 Prototype과 PoC, Pilot를 설명하면서 MVP의 의미를 자세히 설명한 내용이 도움이 될 것 같아서 공유하게 되었습니다 :)"
- Agile, Lean Startup의 MVP(최소 실행가능 제품, Minimum Viable Product를 이해하기 위해 PoC(개념증명), Prototype(프로토타입), Pilot(시범적용)과 비교해보겠습니다. 이들 모두는 검증이라는 공통점이 있습니다.
- 특히 MVP는 제품을 완전히 개발하지 않고도 제품에 대한 고객의 관심을 초기에 이해하고 개선/검증합니다. 따라서 고객의 반응에 따라 방향성을 개선 할 수 있으며, 시장에서 성공하지 못할 제품에 대한 시간, 노력, 비용을 줄일 수 있습니다.
- 개념 증명(POC, Proof of Concept)은 (기존 시장에 없었던) 신기술을 도입하기 전에 이를 검증하기 위해 사용
- MVP와의 차이점 : 실사용자인 고객이 사용/피드백을 안함 - 프로토타입은 정보시스템의 미완성 버전 또는 중요한 기능들이 포함되어 있는 시스템의 초기모델
- MVP와의 차이점 : 실사용자인 고객이 사용/피드백을 안할 수도 있음 - Pilot은 전체 확대 적용하기전에 소규모로 테스트해서 추후 발생할 수 있는 여러 문제의 원인을 미리 파악하고 수정 보완하기 위해 모의로 시행해 보는 활동
- MVP와의 차이점 : 실사용자인 고객이 사용/피드백은 유사하나 성공 또는 실패를 확인하기 위해 사용하며 지속적으로 검증하며 사용하지는 않음 - 최소 실행 가능 제품(Minimum Viable Product, MVP)은 고객에게 가치를 제공해야 하며, 고객 피드백을 받아 생존하기 위한 최소한의 노력을 들여 만든 기능(features)을 구현한 제품이다.
- MVP는 최소한의 노력으로 고객에게 Value를 주며 가설을 검증하며 개선 - 최근에 MVP라는 용어를 주변에서 많이 사용 하지만, 내부 데모용 초기 버전을 MVP로 칭하는 경우가 있습니다.
- 순차적 오픈 : 서브 시스템 10개중 우선 4개를 1단계 프로젝트로 개발하고 우선 오픈하는 순차적 오픈을 MVP라고 부르기
(부연 : 프로젝트 계획서에는 1단계 프로젝트 종료 후 개선없이 바로 2단계 프로젝트 시작) - 베타 버전 : 아직은 시장에 출시할 수준이 되지 않은 초기 버전을 MVP라고 부르기
(부연:알파,베타, 사용성 테스트처럼 출시전 문제확인을 위한 테스트 목적임) - Demo용 : 막연하게 제3자에게 보여주기 위한 용도를 MVP라고 부르기
의견을 남겨주세요