"Essay" 태그로 연결된 23개 게시물개의 게시물이 있습니다.

가끔 나는 비정기적으로 회고를 작성하곤 했는데 대부분 특정 사건이나 일련의 경험이 방점을 찍을 때, 그때의 감정과 교훈을 기억하기 위해서 작성해왔다. 이번에는 특별히 한해를 돌아보는 방식의 회고를 작성해보려고 한다. 내 회고에는 특별히 형식은 없고, 이번년도에 내가 '무엇을 고민했는가'에 대한 스냅샷을 남겨놓는 것이 목적이다.

1년차때는 나에게 주어진 태스크를 그저 '달성'하는데에 집중했다. 단순히 기능을 '구현'하는게 가장 주요한 관심사였고, 그외의 것들까지 모두 다 챙기기는 쉽지 않았다.

첫 회사에서 딱 6개월 정도 지나니까 기능 구현 그 자체에는 큰 문제가 없기 시작했다. 특별히 어려운 기능이 아니라면, 적절히 비즈니스적으로 필요한 시기까지 기능을 딜리버리하는데에는 무리가 없었다. 이때부터, 기능 구현 이상의 것들을 생각하기 시작했다. 나에게 주어진 기능을 개발하는 것 뿐만 아니라, 팀 동료와 함께 성장할 수 있는 기회를 만들어내는 법, 리소스를 효율적으로 쓸 수 있는 환경을 구축하는 법, 조금 더 좋은 코드, 서비스 운영을 위한 시스템 등을 고민하기 시작했다.

처음 개발자 커리어를 시작했을 때, 데일리 스크럼에서 누군가가 "어제는 회의가 너무 많아서, 일 할 시간이 없었습니다." 라고 자신의 일의 진행상황을 팀에 공유했다. 그 워딩 자체를 듣고 바로 들었던 생각은 "회의는 일이 아닌가?" 라는 생각이었다.

2일전, 세분의 사람을 만났다.

한분은 소마 과정에서 우리를 도와주시는 구글 클라우드 아키텍트 멘토님, 한분은 YC에 투자받고 현재 사업을 하고 계신 대표님, 한분은 위 멘토님 소개로 인연을 이어가고 있는 대표님이었다.

나는 지금까지 워크플러그를 만들면서, '어떤 가치를 가진 제품을 만들까?'가 아닌, '어떻게 만들까?'를 훨신 많이 생각했던 것 같다.

어제 가설 검증 방법의 중요성에 대해 이야기하면서, 인터넷을 통해 관련 자료를 찾으면서 공부하기 시작했다.

현재 아이템을 시작하면서 가장 크게 실수한 부분이 있다면, 가설 검증 설계에 시간을 투자하지 않은 것이다.

팀을 리딩하는 사람의 역할은 무엇일까?

아직 유의미한 사용자를 모으지는 못했지만, 서비스를 열어두니 재밌는 일이 일어난다.

3일전, 그동안 준비했던 제품을 출시했다.

https://workplug.framer.website/

소프트웨어 개발 방법론에는 애자일(Agile)이라는 개발 방법론이 존재한다.

나는 프로그래머라, 애자일도 많이 들어보고, 팀에 나름 적용해 보려는 시도도 해봤다.

그런데, 애자일의 본질을 정말 잘 알고 쓴다는 느낌을 받지는 못했다.