🫒 '소프트웨어 엔지니어로 20년간 배운 20가지' 등

'OLIVE LAB'는 오늘도 성장을 갈망하는 일잘러들을 위한 뉴스레터 입니다.
올리브영의 조직 성과와 조직 건강의 지속 성장을 연구합니다.

한 주간 인상깊게 읽은 비즈니스, 리더십, 매니지먼트, 조직문화 관련 아티클을
요약 정리해서 정성껏 담아 보내드립니다:D (마음에 드는 글에 '👍좋아요'도 눌러주세요)

✍️응원, 소감, 궁금하신 내용 그리고 함께 나누고 싶은 내용은 댓글로 남겨주세요.

소프트웨어 엔지니어로 20년간 배운 20가지 (Chad's Pick)

"긴 시간 한분야에 있다보면 많은 것을 깨우치게 됩니다. 멘토링이라는 이름으로 이러한 지식이 공유되기도 하죠. 소프트웨어로 엔지니어로 20년동안 배운 것을 공유하는 글을 소개합니다. 사람들은 비슷한 경험에서도 다른 것을 배우는 것 같습니다. 여러분들은 개발자라서 어떤 것을 배우고 있나요? 아래 글에서 공감하는 것은 무엇이고 다른 배움은 무엇인가요?"

조언이 많은 블로그 게시글을 읽으려고 노력하지만 맥락을 이해하지 못하는 조언은 해롭기까지 합니다.
내 조언의 맥락 또한 존재합니다. 나의 맥락은…(본문을 확인해주세요..^^)
1. 아직 잘 모르겠다. : 비슷한 분야의 사람들도 큰 지식 격차를 가질수 있습니다. 가면을 쓰기 보다는 다른 사람에게 배우고 가르치는 것을 기뻐하세요.
2. 최고의 소프트웨어 엔지니어는 디자이너처럼 생각한다. : 훌륭한 소프트웨어 엔지니어는 코드의 사용자 경험에 대해 깊이 생각합니다.
3. 소프트웨어는 목적을 위한 수단이다. : 모든 소프트웨어 엔지니어의 주요 업무는 가치를 제공하는 것입니다.
6. 때때로 톱 갈기를 멈추고 시작해야 한다. : 어떤 사람들은 연구하고 연구하고 분석 마비에 걸리는 경향이 있습니다. 이러한 경우 마감일을 정하고 솔루션 탐색을 시작하세요.
8. 모든 시스템은 결국 형편 없으니 극복하라. : “올바른” 아키텍처는 없으며 기술 부채를 모두 갚을수 없으며 완벽한 인터페이스를 디자인할 수 없으며 테스트는 항상 너무 느를것입니다. 우아함과 완벽함에 대해 덜 걱정하고 대신 지속적인 개선을 위해 노력하세요.
12. 사람들은 진정으로 혁신을 원하지 않는다.: 진정으로 혁신하고 싶은 사람들이 일을 하는 방식을 바꾸려면 대부분은 부정적인 피드백이 옵니다. 실제로 개선을 하려고 한다면 긴 전투에 대비하십시오.
15. 겸손을 무지로 착각하지 말라. : 묻지 않으면 의견을 표현하지 않는 소프트웨어 엔지니어가 많이 있습니다. 주변 사람들과 이야기하고 피드백과 조언을 구하십시오.
16. 소프트웨어 엔지니어도 주인의식을 느껴야 한다. : 열정적인 사람들의 그룹에 소프트웨어를 설계, 구축및 제공하는 데 대한 완전한 소유권을 부여하면 놀랄운 일이 일어날 것입니다.

'👍도움이 되었어요' 누르고, 원문 보러가기

토스의 제품 원칙, 제품 전략 그리고 UX 원칙 (Eddy's Pick)

"의미 있는 변화를 만든 제품이나 조직의 이면에는 고집스레 지켜낸 원칙이 있습니다. 고객의 미친 만족감을 쫓은 토스의 제품 원칙, UX 원칙을 소개합니다. 여러분 조직의 원칙은 무엇인가요? 원칙으로 논의하며 원칙에 따라 의사결정이 이뤄지나요?"

(본 글은 도서 ‘유난한 도전’에서 발췌한 내용입니다)

토스가 제품을 만드는 원칙을 'Product Principle', 줄여서 PP라 부른다. PP는 토스에서 좋은 제품과 나쁜 제품을 가르는 기준이 되며, 팀원들은 이를 토대로 서로의 제품에 대해 의견을 개진한다.
개인의 취향이 아닌 일관됫 잣대로 개선점을 찾기 때문에, PP는 토스가 사용자에게 '미친 만족감'을 주는 제품을 지속적으로 만들 수 있는 원동력이 된다.
토스팀은 끊없는 실험을 통해 어떤 화면, 어떤 문구, 어떤 흐름이 사용자의 선택을 받는지 검증해왔고, 그 승리전략(winning strategy)을 PP에 담았다.
PP는 다만 고정불변의 법칙은 아니다. 시간이 흐르며 새로이 추가되기도, 혹은 너무나 당연해져서 자연히 잊히기도 한다.
그럼에도 단 한 번도 변한 적 없는 핵심적인 가치는 'Simplicity', 즉 단순함이다. 토스가 생각하는 단순함이란 사용자가 서비스를 이용하기 위해 특별히 알아야 할 것, 배워야 할 것 없이 직관적으로 이해할 수 있는 상태다.
단순함을 구현하기 위한 세부적인 원칙은 제품 전략과 UX 원칙으로 다시 나뉜다.
<제품 전략>
Casual Concept : 전문적인 금융용어와 개념을 이해해야 하는 수고를 사용자에게 지우지 않고, 친숙하고 이해하기 쉬운 개념으로 전달한다.
Minmum Features : 이 기능 없이는 '절대' 목표를 달성할 수 없는지 다시 한 번 생각한다. 기능이 늘어날수록 제품은 점점 어려워지고, 개선 속도도 느려진다. 기능 추가는 목표 달성을 위한 최후의 선택이다.
Less Policy : 단순한 제품의 시작은 단순한 정책이다. 수많은 정책과 조건으로 복잡해진 제품은 친절한 설명이나 깔끔한 UI로도 극복할 수 없다. 사용자가 서비스를 이용하기 위해 '알아야 하는 것'을 최소화한다.
<UX 원칙>
One Thing per One Page : 하나의 화면은 하나의 메시지만 표현한다. 한 화면에 너무 많은 정보를 전달하지 않도록 지우고, 제외하고, 제거한다.
Tap & Scroll : 핵심 플로우를 누르기(Tap)과 스크롤(Scroll)만으로 구성한다.
Easy to Answer : 사용자가 마주치는 모든 질문에 3초 안에 대답할 수 있도록 한다. 기억하기 힘든 정보는 알아서 찾아준다.
Value First, Cost Later : 사용자에게 제품의 가치를 먼저 전달한다. 정보를 입력하는 등 비용을 부과하는 행동은 그 다음의 일이다.
No Ads Patterns : 광고가 아닌 기능으로 소구한다. 광고 스타일을 사용하지 않을 때 오히려 사용자가 집중하기 쉽다.
Context-based : 사용자가 서비스를 이용하는 맥락을 고려해 플로우를 만든다. 맥락 없이 이어지는 플로우는 사용자의 이탈을 부른다.
No More Loading : 사용자를 기다리게 하지 않는다. 이를 위해 정책, UX 플로우, 새로운 기술 등 모든 방법을 동원한다.
Sleek Experience : 사용자가 의식하지 못할 정도로 매끈한 경험을 설계한다. 모든 시선과 손짓에 어색함이 없도록 배려한다.

'👍도움이 되었어요' 누르고, 원문 보러가기

오늘도 PM이 안 된다고 말했다. (Woody's Pick)

서로 다른 역할자들이 서로를 바라볼때 이해하기 어려운 부분이 있기 마련입니다. PM 또는 PO의 역할자들이 개발자들을 바라보며 느낀점을 정리했던 "오늘도 개발자가 안된다고 말했다"라는 글이 유명해진 적이 있었는데 그 반대 관점에서 개발자가 바라보는 PM, 그리고 그들과 대화하는 방법을 정리한 글을 알게 되어서 공유하게 되었습니다 :)

실제로 있던 일은 아니다. 단지 개발자로 처음 Product Manager(PM)와 일을 시작했을 때 쉽지만은 않았다는 걸 표현하고 싶었다. 직군에 대한 이해와 커뮤니케이션 능력이 부족했고 적응 기간이 필요했다.
내가 경험한 PM에 대해 써보자면 목적 조직에서 최대한의 성과를 내기 위해 사용자와 시장에 대한 이해를 바탕으로 서비스의 비전과 방향성 그리고 전략을 고민하고 구체적인 목표를 정한다.
제안할 때는 구체적으로 말하기
하고 싶은 게 무엇이고 이를 통해 해결하고 싶은 게 무엇인지 구체적으로 말해 상대방이 내가 하고자 하는 것을 상상하기 쉽게 만드는 것이다.
서비스에 어떤 영향을 주는지 전달하기
서비스에 어떤 영향을 주는지 설명할 필요가 있다. PM은 결국 팀이 하는 일이 서비스를 어떻게 변화시키는지 궁금해한다.
서비스 관점으로 시작해 WHY 고민하기
결국 이 기술을 통해 현재 어떤 문제들이 해결이 되고 그 과정이 팀의 목표에 맞는지 고민하고 이해시켜야 하는 과정이 필요하다.
주도적인 일정 관리
우리 모두 PM이 되자!
입사 초기에는 서비스의 방향성과 전략은 PM만이 챙기면 된다고 생각했지만 지금은 다르다. 다양한 시각으로 서비스를 만들어 갈 수 있는 장점을 스스로 버리는 일이다.

'👍도움이 되었어요' 누르고, 원문 보러가기

🫒 '소프트웨어 엔지니어로 20년간 배운 20가지' 등

"사람들은 비슷한 경험에서도 다른 것을 배우는 것 같습니다. 여러분들은 개발자라서 어떤 것을 배우고 있나요? 아래 글에서 공감하는 것은 무엇이고 다른 배움은 무엇인가요?"

소프트웨어 엔지니어로 20년간 배운 20가지 (Chad's Pick)

토스의 제품 원칙, 제품 전략 그리고 UX 원칙 (Eddy's Pick)

오늘도 PM이 안 된다고 말했다. (Woody's Pick)

다가올 뉴스레터가 궁금하신가요?

이번 뉴스레터 어떠셨나요?

댓글

이전 뉴스레터

다음 뉴스레터

다른 뉴스레터