5장 서기

5장/서기.md

@@ -0,0 +1,54 @@
+# 서기
+
+---
+
+## 전희수
+
+### 5장
+
+**인상깊은 부분**
+
+- 스터디에서 유일한 기획자인데, 본인도 노력해보겠다라는 말이 어렵단 생각을 해왔음. 기획자입장에선 모든 기능이 구현되는 것이 중요함. 그러나 개발 리소스를 구체적으로 알지못하니까 개발자에게 “되나요?”를 많이 물어봄. 개발자는 “노력해볼게요…!”를 많이 말함. 이런 경우 “된다!”란 생각을 하고 계획을 짜왔음. 개발자가 안될수도 있다.. 라는 말을 하기에 그런 부분도 고려해야하지만 보통 기능이 바뀌면, 기능과 연결된 기능들이 다 바뀌어야 하는 경우가 있음(기획 문서, 디자인 등등등..). 그러다보니 안되는 것을 고려하지 않고 성공할 거란 생각으로 일을 진행해왔음. 기획자는 A 가 안되면 A’, A”는 ? 이렇게 물어봤던 경험이 있음. 이는 개발자에게 압박이 되었을지도… 기획자는 기능을 살리고 싶어하는데 이를 덜 부담스럽게 얘기할 방법이 무엇이 있을까? 고민하게 됨. A 가 안되면 A’, A”는 ? 이렇게 물어보기 전에 큰 틀에서 왜 안되는지를 먼저 알고 그 안에서 답을 찾아가면 더 좋은 커뮤니케이션이 될 듯!
+- 나도 상사와의 관계에서 ‘아니오’란 말을 잘 못했음. 해본 일에 대해선 “네”, “아니오”를 대답했지만, 해본 적 없는 일엔 나도 노력해볼게요! 를 말했던거 같다. 이를 통해 자아성찰도 했다.
+- 큐시즘에서 PM을 하고있는데, 아직도 개발 리소스와 일정을 제대로 파악하는 것이 쉽지 않다. 이럴 땐 개발자의 명확한 아니오와 진척 상황을 빠르게 아는 것이 중요할 것이라 생각함. 자발적으로 진척 상황을 말하고, 아니오를 말하는 것이 쉽지않다는 것을 알고있음. 이럴 땐 짧은 스프린트와 회고를 통해 개발자들의 상황을 자연스레 이끌어 내도록 노력해야겠음.
+
+---
+
+## 한상호
+
+### 5장
+
+**인상깊은 부분**
+
+- 스토리가 재밌었다. 마음 아픈 부분도 있었고 감정 이입도 했었다. 예전에 개발자들이 어떻게 개발했고, 어떤 취급을 받았는지에 마음이 아팠다. 요즘은 처우가 많이 좋아졌다 느낌. 우리나라도 IT가 발전하고 개발자가 창업을 하면서 개발자가 CEO, PM이 되면서 개발자에 대한 인식이 좋아졌음. 그게 아닌 몇십년전부터 이길을 걸어온 선배 개발자들이 많이 힘들었겠다 느낌.
+
+- 나도 취준을 하는 입장이고, 또 주변에 취준생들이 많음. 예전과 다르게 요즘 취업이 쉽지않다며 이렇게 비교하는 사람들이 있다. 그것도 사실이고 경기도 어려운게 맞음. 다른 신입들의 실력이 좋은것도 맞다. 그러나 다 이유가 있다고 생각함. AI, 더 많은 레퍼런스, 더 많은 멘토들이 있기에 다른 신입들의 실력이 올라갔다고 생각함. 중요한 것은 다른 사람들이나 내가 처한 환경보다 내 실력. 내 실력에 집중하는 것이 좋겠다 느낌. 나만의 가치를 만들려고 노력한다면 그 가치를 알아주는 사람이 있을 것이라 생각함. 취업을 한다고 개발자가 끝나는 것이 아니다. 취업을 하나의 과정이라 생각하고 마음을 편하게 먹으려 노력중. 취업해서도 계속 공부하고 스터디하고 그런 과정들이 있기에 길게 보고 준비해야겠다 다짐함.
+
+- 큐시즘 29기를 하면서 개발자로 많이 부족했다. 급급하게 기능을 구현할 생각만 했다. PM이나 기획자가 요청했을 때 의문보단 하겠다! 라고 했었음. 많은 것을 구현했고 이를 통해 한계를 극복하고 실력도 올랐음. 그러나 이 부분이 왜 필요한지 설명하지 못했고, 힘들게 구현한 기능을 실제 사용자가 쓰지 않아 허탈했었음. 이 경험을 통해 나중엔 기획에도 목소리를 내야지 다짐했다. 그 다짐은 30기에서 프로젝트를 진행할 때 기획에 많이 참여하려 노력하며 실천했다. 일정상 안되는 부분들은 안된다 쳐내며 개발을 진행했고, 이를 통해 좋은 프로젝트를 했다고 생각함. 5장의 많은 내용에 공감했고 재밌게 봤음.
+
+---
+
+## 강연주
+
+### 5장
+
+**인상깊은 부분**
+
+- 책을 읽으면서 지금 진행하는 밋업 프로젝트에 대입하게 되었고 반성하게 되었음. 백엔드 개발자로 프로페셔널하지 못했다 느끼는 부분이 많음. 책에서 ‘아니오’라고 말하지만 말고 대안을 제시해라! 라는 것을 읽으면서 느낀 점이 있음. 이번 밋업 도중 기능을 구현할 때 기준이 복잡해서 구현이 어렵다. 라고 기획자에게 전달한 적이 있음. 이때 불가능하다고만 했지 대안을 말하지 않았음. 이때 대안을 제시했으면 어땠을까? 느끼며 기획자에게 미안함을 느낌. 정렬이 불가능하다 얘기한 것도 처음엔 가능하다 말했지만, 개발하다보니 불가능하다는 것을 깨닫고 말한거라 늦은 감이 있었음. 먼저 넓게 볼 수 있는 사람이 되어야겠다 생각함.
+- 책에서 진척 상황 공유에 대한 얘기가 있었는데, 이번 프로젝트를 진행하며 개발 진행상황 공유가 원활히 되고 있지 않다 느낌. 책을 읽고 우리도 제대로 공유를 안하고 있었지! 반성을 하게 됨. 한달 남았는데 진행도를 꾸준히 전달해야겠다! 느낌.
+
+---
+
+## 이은학
+
+### 5장
+
+**인상깊은 부분**
+
+- 기업 프로젝트를 할 때 팀원들이 다 너무 잘했다. 동기들과 했던 프로젝트를 넘어 한 기업의 프로젝트를 맡았던게 조금은 겁도 났다. 기업 프로젝트 개발 3주차에 프론트엔드들은 많이 힘들지 않았을까 생각함. 그러나 지금 생각해보니 그때의 경험들도 좋은 경험이었음. 그때 개발한 부분이 지금 사이트에 적용되어 있어서 좋기도 했음.
+
+- 문제상황에 대한 가설을 세우지 않고 데이터를 그냥 분석했던 과정과 비슷했다. 무작정 분석하지 말고 고객 중심적 사고를 통해 고객에게 실제로 질문을 하거나 , 우리끼리 판단하지 말고 초반에 많은 커뮤니케이션을 통해 대안을 제시하는 것이 중요하다 느낌.
+
+- ‘아니오’라고 말하는 방법 배우기도 와닿았음. 개발자들이 무리하게 일정표를 만들고 우리에게 책임을 밀어붙이는 상급자가 많다.란 표현이 있었는데, 조금은 당연하다 느낄 수 있지만 자신의 의견을 숨기지 않고 말해야 효율과 능률이 오를것이라 생각함. 개인 혹은 팀이 생각하는 타협점을 제시하는 것이 더 좋은 협력을 이끌어낼 수 있을 것이라 생각함. 큐시즘 면접에서 받은 질문 중 하나가 마감 일주일전 디자인 팀에서 절반을 바꿔달라 하면 어떻게 할것이냐 물어봤었는데 난 그때 모든 요구사항을 다 받진 않을거같고 개발팀 안에서 의사결정을 해 기획과 디자인을 설득해 타협점을 찾아야한다라고 대답한 기억이 있음.
+
+- "코드의 품질 수준을 낮추고 야근과 휴일 근무를 연이어 하게 되면 모두가 지쳐 쓰러지고 프로젝트 전체가 위태로워진다." 이러한 문장은 좀 안쓰러웠다. 우리의 모습이 될 수도 있다는 생각이 들어서 마음이 아팠다.