[전희수] 5,6장: 영웅, 선의 그리고 프로페셔널리즘, 6장 동작하는 소프트웨어

5장 /전희수.md

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

6장 /전희수.md

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