15장 전희수

15장/15장 전희수.md

@@ -0,0 +1,9 @@
+*“무엇이든지 새로운 것을 배울 때는 시간이 걸리는 점이 문제다. 새로운 실행관례를 도입한다는 것은 기존의 익숙하던 일하는 방식을 벗어나야 한다는 것을 의미한다.”*
+
+- 새로운 방식의 도입은 바쁜 상황에서 항상 망설여지는 것 같다. 지금하고 있는 방식도 나쁘지 않은데.. 너무 도박수가 아닐까?하는 고민을 하면 새로운 방식의 도입을 망설이곤 했는데, 처음 하는 일이 시간이 오래걸리는 것은 당연하다. 중장기적인 관점에서 장단점을 파악해 보고 결정하는 습관을 드려야겠다.
+
+<br>
+
+*“실행 관례와 절차들은 그보다 더 나은 실행 관례와 절차가 나타나기 전까지만 가치가 있다. 장인이라면 실행관례들을 절대 불변의 진리라고 믿어서는 안 된다. 지금 당장 우리가 XP를 추구한다고 해서 더 나은 방법을 찾아보는 것을 멈춰서는 안된다. 우리가 활용해야 할 실행 관례들이 정해져 있다고 믿는 순간 우리는 진화를 멈추게 된다.”*
+
+- 보통 일을 할 때 나한테 맞는 프레임워크를 찾게 되면, 새로운 방식 보다는 손에 익은 방식으로 일을 하는 경우가 대부분인거 같다. 이렇게 일해봤는데 이 방식이 제일 좋은거 같아요! 라고 말하기 위해서는 다양한 프레임워크를 찾아보고 활용해보는 것을 멈추면 안되겠다는 생각이 다시한번 들었다. 내가 가장 좋다고 이야기하는 것이 과연 가장 좋은 것일지에 대한 고민은 계속되어야한다.

16장/16장 전희수.md

@@ -0,0 +1,29 @@
+장인의 길
+
+*“열정. 이 단어 하나가 모든 것을 요약한다. 장인은 개발과 자신의 직무에 열정적이다. 문제를 단순한 방법으로 푸는 데 열정적이다. 배우고 가르치고 공유하는 데에도 열정적이다. 그들의 경험을 공유하는 데도 열심이다. 뿐만아니라 소프트웨어 장인은 겸손하다. 항상 더 나은 개발자에게 무언가를 배울 자세가 되어 있고, 경험이 적은 개발자를 돕기를 주저하지 않는다.”*
+
+- 어떤 일을 하던 ‘열정’은 굉장히 중요한거 같다. 힘들고 어려워서 죽을 거 같지만, 재밌다고 느끼는 감정. 정말 잘 해내고 싶다고 느끼는 감정이 어떤 일을 끝까지 잘 해내게하는 원동력이 되는 거 같다. 내가 재밌고 잘하고 싶으니까 정보를 공유하게 되고, 내가 가지고 있는 것들을 알려주게 되고, 새로운 것들을 배우고 싶어지는 것 같다. 이렇게 중요한 열정인데 이를 지속시켜 나가는 방법은 뭘까? 처음부터 끝까지 열정을 잃지 않는 방법이 뭐가 있을까?
+
+<br>
+
+*“장인이 된다는 것은 새로운 것에 대해 호기심을 가지고 실험한다는 것과 같은 의미다. 장인은 특정 도구, 개발 언어, 프레임워크에 독단적인 고집을 부리지 않는다. 항상 주어진 문제에 가장 적합한 도구를 찾고 단순한 해결책을 추구한다.”*
+
+- 호기심, 독단적인 고집을 부리지 않는 것! 모든 일의 결정은 뇌피셜이 아닌 주어진 문제에 집중하여, 가장 적합한 도구를 찾아 진행해야한다. 내가 틀렸다는 것에 집중하기 보다는 상황에 맞는 유연한 사고와 내가 내린 결정이 과연 맞는지에 대한 고민과 생각을 잃지 말자.
+
+<br>
+
+*“장인은 자신이 떠나고 난 후 스스로 부끄러운 일로 떠올리는 상황을 만들지 않는다. 엉망인 코드, 작성자 본인 외에는 아무도 이해할 수 없는 코드로 하여금 남아 있는 개발자들의 지탄을 받을 일을 만들지 않는다.”*
+
+- 에매하게 못할거면 시작도 하기 싫다.. 내 이름 걸고 하는 프로젝트와 활동에는 최선을 다하고 잘하고 싶다. 대충할거면 시작도 하지 말것.. 이런 마인드세팅이 행동으로 계속 이어질 수 있길
+
+<br>
+
+*”그저 ‘아니오’라고 답하는 것만이 장인으로서의 태도는 아니다. 모든 ‘아니오’에는 항상 대안을 제시해야한다.”*
+
+- 밋업 셀프 성찰 기간이 생각난다. 현 상황에 대한 문제점을 지적하고 싶을 때는 지적 + 그에 맞는 내가 생각하는 대안을 고민하고 제시할 것. 그냥 이거 별론거 같아요, 잘못 된거 같아요.라는 너무 단적인 말들은 별로 도움이 되지 않는 것 같다. 내가 문제점을 찾아서 끌어올렸으면, 다 같이 그 문제점에 대해 논의할 지점들, 러프한 방향성 정도는 같이 제시하자.
+
+<br>
+
+*”급여를 대가로 해서 일을 하는 것 말고도 우리의 열정과 헌신 그리고 업무 외 개인 시간을 들여 확보한 지식을 투자하여 일터를 더 나은 곳으로 만든다. 단순히 일을 하는 곳이 아니라 배우고 성장하는 장이 되게 한다. 일터를 더 나은 곳으로 만드는 데 투자한다는 의미는 우리의 커리어를 더욱 풍요롭게 할 수 있는 기회를 늘린다는 것과 같다.”*
+
+- 이 문장을 보고 논쟁의 주제가 되는 부분이 생각났다. 사실 많은 사람들은 일터는 돈을 버는 일일 뿐, 나의 삶은 회사 이외에 시간에서 찾아야한다고 이야기하는 것 같다. 그런데 반대로 나는 하루에 8시간씩 있는 회사에서 하는 일이 재미가 없다면, 무의미한 시간 같다면 시간이 더 아까울 거 같다. 회사에서 나만의 만족도를 찾고, 일을 하는 과정이 프로젝트를 진행하는 과정이 배움과 즐거움으로 가득찼으면 좋겠다. 누군가는 너 회사도 아닌데 그렇게까지 해야해?라고 말할 수도 있겠지만, 이왕 내가 가장 오랜시간 생활하는 공간을 좋은 공간으로 만드는 건 좋지 않나?라고 생각한다! 다들 분위기 좋게 일하면 좋으니까~

5장/5장 전희수.md

@@ -0,0 +1,33 @@
+# 5장 영웅, 선의 그리고 프로페셔널리즘
+
+*“우리는 전혀 프로답지 못했다. 한번도 ‘아니오’라고 말하지 않았기 때문이다.”*
+
+*“빡빡한 일정을 다루는 가장 좋은 방법은 필요한 모든 것을 분석하여 가능한 위험과 우려사항을 터놓고 관계자들과 소통하는 것이다. 불명확하거나 불편한 사실들, 걱정되는 사항들을 최대한 이른 시점에 문제제기 해야한다.”*
+
+- **‘노력해보겠다’라는 언어의 어려움과 고민**
+    <br>
+
+    스터디에서 유일한 기획자인 나도 ‘노력해보겠다’라는 단어가 참 어려운 단어인 것 같다. 사실 기획자 입장에서는 모든 기능이 구현되는 것이 당연히 좋다! 하지만 개발 리소스를 구체적으로 알지는 못하기 때문에 가능할까요?라는 질문을 정말 많이 하곤 하는데, 사실 보통 가장 많이 듣는 말이 ‘해볼께요, 될 수도 있을거 같아요’ 등과 같은 말인데 그러면 자연스럽게 무의식중에 되는 기능이구나라고 생각하고 계획을 짜게 되는 것 같다.
+    <br>
+
+    물론 안되는 경우의 수도 계산해서 작업을 하는게 멋진 기획자의 자세겠지만,, 보통 기능하나가 바뀌면 그 기능과 연결되어 있는 전체적인 플로우를 수정하고 디테일도 수정하고 UX라이팅, 기획로직, 화면설계, 기능명세, 기획문서 등등 바뀌어야하는 것들이 많기도 하고 당장 해결해야하는 이슈들도 많아서 명확하게 안된다는 말을 듣기 전까지는 일단 된다고 생각하고 일을 하는 특징이 큰 것 같다!
+    <br>
+
+    하지만 또, 개발자들의 입장을 너무나 이해하는게 보통 기획자는 A가 안된다면 이 기능을 수정한 A’는 어때요? A’’는요?라는 질문을 끊임없이 하기 때문에 무언의 압박으로 느끼지 않을까? 싶기도 하다. 
+    <br>
+
+    기획자는 가능한한 범위 내에서 최대한의 결과를 만들어내고 싶기 때문에 보통 한 기능이 반려당하면 다양한 대안을 제시하는 경우가 많은데, 이를 개발자들이 덜 부담스럽게 느낄 수 있는 커뮤니케이션 방법에는 뭐가 있을지 고민이 많다..!
+    <br>
+
+     이거는요, 저거는요를 이야기하기전에 A가능이 어려운 이유가 어떤 부분때문일까요? 이런 부분이 문제가 되는 걸까요? 전체적인 일정 측면에서 불가능한걸까요?라고 큰 틀에서 먼저 질문을 하고 세부 수정사항을 제안해보는 것이 좋을까? 
+    <br>
+
+    그리고 이 상황을 기획자와 개발자 관계가 아닌 상사와 사원의 입장으로 바꿔서 보면, **나도 ‘아니오’란 말을 잘 못하는 거 같긴하다.** 약간 하면 되긴 될 거 같긴해서 ‘어 좀 빡빡하긴한데 해볼께요’라는 말을 많이 하는 거 같다. **하지만 안해봐서 나도 될지 안될지 잘 모르겠는걸…? 해본 일의 경우 가능여부 판단이 명확한데 안 해본일의 경우 가능여부를 판단하는 기준이 참 어렵다.** 
+
+<br>
+
+*“훌륭한 관리자는 현재 프로젝트 상태가 어떠한지 명확하게 이해하고 주어진 일정 동안 무엇을 할 수 있을지 개발자들과 함께 추산 가능해야한다.”*
+
+- 현재 밋업의 PM을 맡고 있는데, 개발리소스와 일정을 파악하는 것은 아직도 너무 어렵다. 개발을 많이 경험해보지 않은 내가 일정을 파악하는 방법은 책에 나와있듯 명확한 ‘아니오’와 구체적인 진척사항을 이끌어내는 것인거 같다. 
+<br>
+- 사실 많은 업무량을 소화하면서 세세한 진척도와 불만사항을 자발적으로 공유하기는 어려운거 같다. 그러니까 업무 진척사항을 공유하게 만드는 다양한 프레임워크, 스프린트별 회고시간 도입등을 통해서 소통과 공유를 할 수 밖에 없는 상황을 만들어내는 것이 중요할거 같다.

6장/6장 전희수.md

@@ -0,0 +1,22 @@
+# 6장 동작하는 소프트웨어
+
+*“소프트웨어 개발자의 삶에 있어 압박은 피할 수 없다. 우리는 압박을 받는다고 느낄 때 중심을 잃고 고만고만해진다. 게으른 탓이 아니다. 더 빨리 해야 한다고 느끼기 때문에 그렇게 한다. 상황을 솔직하고 투명하게 밝히고 며칠 더 늦게 안정적인 솔루션을 전달하기보다 버그가 좀 있더라도 일정 안에 전달하는 편이 더 낮다고 느낀다.”*
+
+*“뻘리하는 것과 허술한 것은 다르다.”*
+
+- 소프트웨어 개발자의 삶 뿐만 아니라 대부분의 IT업계 종사자들의 삶에 있어 압박은 피할 수 없는 것 같다. 기획자, 디자이너, 개발자등 협업의 대상이 많다보니 각자 자신의 맡은 업무를 빠르고 정확하게 해치워야 타임라인 안에 결과물을 만들어낼 수 있는데, 그러다보니 나도 개괄적인 틀만 완성되면 빠르게 기획을 넘겼던 경험이 많다. 빨리 넘겨줘야한다는 압박감에 너무 휩싸이면 좋은 결과물이 잘 나오기 쉽지 않다는 것에 공감한다. 빠르게 넘기는 것도 중요하지만 그 안에 있는 디테일과 정확도도 잊어선 안된다. 나중에 수정해야지하고 생각해도 일을 하다보면 후순위로 밀릴때가 다분하기 때문에,,,  빨리하는 것과 허술한 것은 다르다는 것을 명확하게 인지할 것! 속도에 너무 매몰되서 정확성과 생각의 깊이를 잃지는 말자.
+
+<br>
+
+*“아무리 한탄하고 불평하고 저주해보았자 삶이 쉬워지거나 나아지지는 않는다는 점이다. 무언가 나아지길 원한다면 그에 맞는 행동을 취해야한다.”*
+
+- 밋업을 하다가 새벽에 자아성찰한 내용과 비슷하다. ‘어떤 점이 부족한거 같아. 설득력이 부족해.’라고 말하기 보다는 ‘이런이런 점이 부족한거 같아서 이런자료들을 찾아서 이렇게 구성해봤는데 어떄?’라고 행동하는 사람이 되자. 입만 산 사람이 되는 건 최악이다~ 무언가 부족하고 아쉽다는 생각이 든다면 이를 해결하기 위해 행동하고 이상과 행동이 일치하는 사람이 되자 ! 
+<br>
+
+*“모든 퍼즐 조각들을 한꺼번에 펼쳐놓고 맞추려 들면 도통 진도가 나가지 않는다. 각 조각을 그룹으로 나누고 모서리나 경계선부터 시작해야 한다. 조각들을 색상이나 패턴을 기준으로 분리해서 모아두어도 도움이 된다. 몇 가지 작은 그룹들이 만들어지면 큰 형태가 머릿 속에 그려진다. 몇몇 조각들을 맞추는데 성공하면 전체 그림의 일부분을 볼 수 있다.”*
+
+-  모든 퍼즐 조각들을 한꺼번에 펼쳐놓고 맞추려 들면 도통 진도가 나가지 않는다는 말에 매우 동의한다. 한번에 효율적으로 문제를 잘 해결하는 방법이라는 건 없다. 문제를 하나하나 쪼개고 살펴보고 문제 해결을 위한 생각과 정보들을 모으고 조립해나가보면, 결국 해결할 수 있는 큰 그림이 그려질 것이다. 당면한 문제에 조급해하지말고, 빠른길을 찾아헤매지말고, 할 수 있는 것부터 차근차근 해결해 나가야한다.
+
+<br>
+
+- 6장은 정말 개발자적인 내용이 많아서 조금 어려웠지만, 레거시코드의 이야기를 기획의 로직, 문제 해결법 등으로 차용해서 보니까 깨닫고 생각나는 점이 많았다. 성공적인 문제해결을 위해서는 상황을 말로만 나열하기보다는, 하나씩 차근차근 직접 시도해보고 고민해보고 앞으로 나아가는 것이 중요하다는 생각을 다시한번 상기시킬 수 있었다.