필요한 일들을 적시에 해결하는 것이 중요하다. 이 문장에서 강조해야 하는 부분은 '필요한' 이 아니라 '적시에' 이다. 그럼 여러 문제해결책 중 어떤 것이 '적시' 인지 어떻게 알 수 있을까? 문제 해결책에 대한 속성을 검증하려면 그 해결책이 대상으로 하는 문제에 대해 같은 질문을 던져보면 된다. 기술 개발을 통해 접근하고자 하는 문제의 실체에 대한 분석을 진행할 수록 문제 해법에 대한 고민도 함께 깊어지기 때문이다.

동일한 접근이 개발 방법론에 대해 적용되기도 한다. 최근에 진행한 몇몇 스프린트에서 얻은 교훈은 개발 리소스를 투입하기 전에 개발 밑그림에 대한 공유가 필요하다는 것이었고 여기에 대한 해결로 개발 스펙 문서를 작성하기로 했다. 개발전 디자인 단계에서 가능한 많은 피드백을 얻어야, 개발 리소스 낭비를 최대한 줄일 수 있다.

문제점에 대한 확인과 낭비의 상관관계를 확인할 수 있었던 좋은 예가, 최근에 진행했던 아파치 스톰 도입이었던 것 같다. 주기적으로 MR 을 실행하는 기존 설계상의 문제가 확인된 후 바로 작업을 시작했는데, 그 결과 두 스프린트가 지난 지금 회사의 사업 방향 피벗을 지원할 수 있었다. 만약 그 때 바로 손을 쓰지 않았다면, 지금 개발실이 만들어놨던 설계 부채로 인해 영업이 멈추고 기다려야 하는 상황이 왔을 지도 모른다.

결국 스타트업에서 이뤄지는 활동들 중 비개발 인력이 해야 될 일은 문제점 확인이다. 진짜 고객을 만나고 그들이 겪는 문제점을 확인하고, 요구사항을 수집한다. 수집된 문제들에 대한 우선순위가 메겨지면 해결책 제시는 개발팀의 임무이다. 이 프로세스에서 선순환을 만들어 낼 수 있느냐 하는 것에서 스타트업의 실행력이 판가름난다.

그 외에 돌아보자면, 갈등을 다룰 수 있는 액션아이템들도 필요하다고 보여진다. 머릿속에만 담아두고 있다보면 업무의 과도함과 겹쳐서 스트레스가 넘치게 되고, 그럴 때는 자기 관리에도 태만하게 된다. 팀 리더의 자기 관리 태만은 결국 팀 관리의 태만으로 이어지고, 그 결과 팀의 퍼포먼스에 영향을 미치게 된다. 이런 면에서 수신제가치국평천하는 그 의미가 남다르다 하겠다. 스트레스 관리도 반복되는 문제점이라면 여기에 대한 해결 루틴도 존재해야 한다. Don't repeat yourself. 가 생존의 모토라면 스트레스 관리 실패가 반복되는 것도 위험한 상황이라 하겠다.