[Retrospect] 프로젝트 회고 - 장요한

[romantech]

SR의 중요성

SR이 부실할수록 개발력은 떨어지고 프로젝트는 산으로 갈 수도 있다고 느꼈다.
전반적인 청사진이 부족한 상태에서 개발을 시작하면 기획 의도와 전혀 다른 방향의 서비스가 될 수도 있겠구나 생각했다.
우리팀은 다행히 초반 기조를 어느정도 유지하면서 프로젝트를 진행한 것 같다.

• 왜 이 서비스를 개발하는가?
• 이 서비스는 누가 사용하는가?
• 이 서비스의 차별점은 무엇인가?

등을 항상 염두하는 것이 중요한 것 같다.

자유로운 대화

아이디어는 편안한 분위기 속에서 나오는 것 같다.
심지어 사소한 잡담을 할 때 좋은 아이디어가 더 많이 나오는 것을 경험했다.
오히려 서로 각 잡고 아이디어를 내려고 하면 좋은 생각이 떠오르지 않는다.
브레인스토밍의 진짜 의미를 다시 한번 생각하게 만들었다.

사용자 최우선 고려

개인 취미 프로젝트가 아닌 이상 사용자를 최우선으로 생각한다.
내가 좋다고 느낀건 사용자가 별로라고 느낄 수 있고,
내가 별로라고 생각한건 사용자가 좋다고 생각할 수도 있다.
밤낮없이 열심히 개발했지만 사용자 반응이 별로라면 그것만큼 김 빠지는 일은 없을 것이다.
대중적인 감각과 공감 능력의 중요성을 다시 한 번 절감했다.
커뮤니티에 글을 올려서 반응을 먼저 살펴보는 것도 좋은 방법인 것 같다.

소통의 중요성

다른 팀원과 소통하지 않은 상태에서 공통으로 사용하는 코드를 수정하면,
아무것도 모르는 다른 팀원은 수정하기 전의 코드를 기반으로 개발한다.
그럼 Merge 할 때 모든 코드를 다 수정해야 하는 비효율이 발생한다.
팀원 간의 소통은 많으면 많을수록 좋다. 심지어 그게 사소한 잡담일지라도.

공통 컴포넌트

사이트 전반에서 공통으로 사용할 컴포넌트를 정하지 않고 개발한 것이 큰 실수였다.
서로 비슷한 기능을 갖는 컴포넌트를 개발하느라 다른 기능 개발 속도가 더뎌진 것 같다.
프로젝트 초반 재사용할 컴포넌트는 어떤 것이 있는지 먼저 정하는 것도 중요한 것 같다.

삽질의 정도

개발자라면 끊임없는 삽질 과정을 거친다. 삽질을 통해 개발 실력을 향상할 수 있지만,
프로젝트 기간은 한정되어 있다. 1개 작은 기능 때문에 하루종일 삽질했던 점은 반성해야 한다.
프로젝트 기간엔 삽질의 정도를 잘 조절하는 것도 중요한 덕목인 것 같다.