[펌] 완벽주의 - 엔지니어링 산업에서 생산성을 가장 크게 저하시키는 요인 중 하나

main

 

 

 

완벽이란 단어는 좋아보이지만 그렇지 않으 때도 있습니다.

우리는 개발이라는 것을 하면서 항상 목적에 따라 Trade Off를 합니다. 완벽이란 것도 시간이란것과 함께 Trade Off를 할 수 있어야 좋은 개발자로 남을 수 있을 것입니다.

다음 글을 보면 완벽이란게 반드시 일하는데 있어서 포함되어야 하는 것인지 다시 한번 생각해볼 수 있는 시간이 되면 좋겠습니다.

 

 

---

소개

 

완벽주의는 우리가 깨닫지 못한 채 우리를 해치는 것들 중 하나입니다. 우리는 결과가 "완벽"하도록 하기 위해 많은 노력을 기울이는 것이 좋다고 생각할 수 있지만, 결국 우리는 그것을 결코 끝내지 못하고 끝없는 "진행 중인 작업"이 되는데, 이는 큰 문제입니다.

본 기사는 Pinterest의 수석 소프트웨어 엔지니어이자 뉴스레터 High Growth Engineer 의 저자인 Jordan Cutler 와 협력하여 작성되었습니다 .

우리 둘 다 완벽을 추구하는 게 최선의 방법이라고 생각해서 많은 실수를 했지만, 시간이 지나고 나서는 발전이 훨씬 더 좋다는 걸 깨달았어요!

그리고 오늘, 우리는 여러분과 우리의 이야기를 공유합니다! 먼저 조던의 이야기부터 시작해 볼까요.

완벽주의를 다루는 조던의 이야기

 

경력 초기에는 코드를 쓰는 데 많은 시간을 보냈습니다. 사실, 엔지니어로서 처음 3년 동안 1,200개가 넘는 풀 리퀘스트(PR)를 발송했고, 하루에 평균 1~2개의 PR을 발송했습니다.

코드 속도가 빠른 반면, 저는 잘못된 것에 집중하고 있었습니다. 대부분의 PR은 코드베이스를 "완벽하게" 하는 데 전념했습니다.

당시에는 제가 대단한 일을 하고 있다고 생각했습니다. 누가 코드를 멋지게 꾸며서 좋아하지 않겠습니까? 하지만 돌이켜보니 제 시간을 훨씬 더 잘 보낼 수 있었을 거라는 걸 깨달았습니다.

코드를 완벽하게 만드는 대신, 특히 수년 동안 건드리지 않았고 건드릴 필요도 없는 코드를 만드는 대신, 팀에 가치를 더할 수 있었습니다.

다음과 같은 것들:

• 더 많은 코드 검토를 통해 팀원들의 업무를 늘리는 대신 그들의 업무를 줄이는 것입니다.
• 현재 기능을 더 빠르게 제공하고 다음 기능을 앞서 나가기
• 내가 어떻게 그들을 더 도울 수 있는지 관리자에게 물어보기

그래서 제가 경력 초기에 모든 홍보 활동을 했음에도 불구하고, 오늘날에는 그것이 얼마나 무의미한 일인지 깨달았습니다.

코드를 완벽하게 만드는 데 시간을 덜 들였다면, PR을 50%나 적게 출시하고 팀에 2배 더 많은 가치를 더할 수 있었을 겁니다.

오늘날, 일주일에 3개 이상의 PR을 배송하면 운이 좋습니다. 그 이유는 제가 올바른 일에 집중하기 때문인데, 이는 종종 팀을 돕고, 파트너십을 만들고, 제안서를 작성하고, 문서를 통해 스스로를 확장하는 것을 의미합니다. 코드를 배송할 때는 팀이나 비즈니스에 가치를 전달하려는 명확한 의도가 있습니다.

이 예 외에도 나는 다음 3가지 일을 통해 완벽주의를 피합니다.

1. 주 초에 우선순위를 적어두면 가장 중요한 것이 무엇인지 알 수 있습니다. 힌트: 보통 무언가를 완벽하게 하는 것은 아닙니다.
2. 내부 또는 외부 고객에게 가장 작은 가치 단위를 배송합니다 . 예를 들어, 기능 플래그 뒤에 80% 작동하는 프로토타입을 배송하여 내부적으로 조기 피드백을 받습니다.
3. 조기 피드백을 구합니다 . 하루를 시작할 때 4시간 집중 시간 블록을 설정하고 최대한 진전을 이룹니다. 그런 다음 스스로에게 "내가 이룬 것을 바탕으로 공유하거나 피드백을 요청해야 할 것이 있는가?"라고 묻습니다. 기술 문서에 대해 항상 이렇게 합니다. 팀에 "여기서 완전히 잘못된 방향으로 가고 있는가, 아니면 이 길을 계속 가야 하는가?"라고 묻습니다. 때때로 제안보다 더 간단한 해결책이 있거나 이미 탐색되었거나 가치가 없는 경우가 있습니다. 그러면 문서를 완성하는 데 소요되는 시간을 몇 시간이나 절약할 수 있습니다.

마음가짐에 따른 시간분배 비교

 

완벽함은 덜하고, 진전은 더 많아.

 

 

728x90

 

완벽주의를 다루는 그레고르의 이야기

 

완벽주의는 어린 시절부터 저에게 문제였습니다. 저는 항상 모든 것을 가능한 한 최상의 품질로 만들고 싶었고, 특히 저에게 중요한 것들은 더욱 그렇습니다.

그것이 실제로 역효과라는 것을 깨닫는 데 오랜 시간이 걸렸습니다. 소프트웨어 엔지니어와 관리자로서 제가 완벽하게 하고 싶었던 가장 두드러진 것들은 다음과 같습니다.

튜토리얼로 '완벽하게' 배우고 싶었어요

저는 독학으로 엔지니어가 된 초기에는 튜토리얼을 통해 정말 많은 것을 배웠습니다.

그 당시를 돌이켜보면, 항상 튜토리얼을 100% 끝내야 한다는 생각과 "한 순간도 놓치지 말아야지"라는 사고방식을 갖고 있지 않았다면 훨씬 더 빨리 발전할 수 있었을 거라고 생각합니다.

지금 제가 아는 바로는 튜토리얼에서 배우는 가장 좋은 방법은 필요한 것을 얻고 그것을 자신의 프로젝트에 적용하는 것입니다. 자신의 프로젝트를 만드는 것이 배우는 가장 좋은 방법입니다. 이에 대한 자세한 내용은 여기에서 찾을 수 있습니다: 사이드 프로젝트를 진행하여 더 나은 엔지니어가 되세요 (유료 기사).

나는 "완벽한" 것을 디자인하고 싶었습니다.

소프트웨어 엔지니어로서 학생 시절에 일할 때, 배너, 웹사이트 디자인과 같은 디자인 관련 일을 많이 했고, 그래픽 디자인도 했습니다. 디자인할 때 반복되는 패턴을 보았습니다.

그 패턴은 제가 초안을 꽤 빨리 만든 다음, 2-4배의 시간을 마무리 작업에 사용하는 것이었습니다. 이는 저에게 상당히 역효과를 냈고 스트레스가 많았습니다.

저는 그것이 "픽셀 완벽함"을 보장하는 데 많은 시간을 보냈습니다. 올바른 색상, 올바른 글꼴, 올바른 간격 등. 제가 그것으로 괜찮다면 훨씬 더 많은 진전을 이룰 수 있었을 것입니다. 재밌는 것은 최종 결과가 첫 번째 초안보다 별로 좋지 않았다는 것입니다(아마 조금 더).

나는 "완벽한" 코드를 만들고 싶었습니다.

특히 소프트웨어 엔지니어로서 경력을 시작했을 당시, 다른 사람에게 보여주기 전에 완벽한 코드를 작성해야 한다고 느꼈습니다.

저는 함수를 리팩토링하고, 변수 이름을 바꾸고, 접근 방식을 재고하고, 전반적으로 최적화 방법을 찾는 데 많은 시간을 보냈습니다. 제가 이걸 할 만큼 훌륭하지 않다고 말하는 것은 제 사기꾼 증후군이었습니다.

그래서 전반적인 진행이 힘들어졌고, 디자인도 마찬가지여서 추가적인 스트레스를 받았습니다.

충분히 좋은 코드에 집중하고 일찍 피드백을 받는다면 훨씬 더 많은 진전을 이룰 수 있을 텐데요! "완벽하게" 하려고 시간을 너무 많이 낭비했어요.

관리자로서 나는 "완벽한" 타이밍을 기다리고 "완벽한" 결정을 내리고 싶었습니다.

피드백을 줄 타이밍이 완벽해야 한다고 생각했습니다. 글쎄요, 기다린 결과 상황이 훨씬 더 나빠졌습니다.

나는 나 자신에게 말했다: "조금 더 기다리면 상황이 나아질지도 몰라". 글쎄, 현실은 그렇지 않았다. 그리고 완벽한 타이밍을 기다린 것이 상황을 훨씬 더 악화시켰다.

시간에 따른 팀 분위기

 

결정을 내리는 것과 비슷합니다. "그들은 완벽해야 해." 저는 스스로에게 말했습니다. 그리고 그것은 제가 결정을 충분히 빨리 내리지 못하는 지점으로 저를 이끌었고, 실제로 제 팀의 발전을 막았습니다.

그리고 저는 시간이 지나면서 모든 결정이 절대적으로 옳은 것은 아니라는 걸 깨달았습니다. 하지만 결정을 내리고 나서 필요하면 나중에 번복하는 게 전혀 내리지 않는 것보다 훨씬 낫습니다.

제가 얻은 가장 중요한 3가지 교훈은 다음과 같습니다.

• 완벽을 추구하는 대신 진행에 집중하면 생산성이 훨씬 높아지고 정신 건강에도 훨씬 좋습니다.
• 완벽한 순간은 존재하지 않으며, 완벽한 순간을 기다리면 훨씬 더 많은 문제가 발생할 뿐입니다. 중요한 일을 다룰 때는 지금 또는 가능한 한 빨리 일을 하는 것이 최선의 방법입니다.
• "완벽하게" 하려고 노력하는 것 같을 때마다, 저는 이렇게 생각합니다. 100%는 존재하지 않으며 대부분의 경우 95%면 충분합니다. 그러면 완벽해지는 대신 진전을 이루는 데 마음이 바뀝니다.

---

 

반응형

 

 

 

천재가 아닌 이상 제품을 만드는데 있어 완벽함은 절대 있을 수 없습니다. 개발자인 우리들도 항상 완벽하고 싶은 마음에 사로 잡힐때가 많습니다. 이유는 여러가지가 될 수 있습니다. 인정을 받고 싶거나, 버그를 수정하는데 비용이 너무 많이 들었던 경험이 있거나 등 여러가지가 있을 수 있습니다. 하지만 우리는 단 한가지 명심해야 할 것이 있습니다. 

처음 언급했듯이 완벽과 시간이라는 자원에 저울질(Trade Off)을 하여 자기만의 가성비 좋은 "완벽"을 구성하면 좋겠습니다.

 

 

 

 

출처: https://newsletter.eng-leadership.com/p/perfectionism-one-of-the-biggest