To OO님,

드디어 원하는 곳에서 엔지니어로 커리어를 시작했구나! 새로운 곳에서 시작을 축하해! 게다가 벌써 업무에 투입되서 첫 배포까지 했다니 대단하다. 이번 메일에서 일정으로 인해 고민하고 부담을 갖기 시작한 것을 보니 엔지니어로서 본격적으로 커리어를 시작했구나란 생각이 들어. 사실 경험 많은 시니어도 일정을 지키는 것은 어렵긴 마찬가지거든.

왜 항상 예측보다 시간이 오래 걸리는 이유?

‘애자일 조직혁명’의 저자 ‘스리람 나자얀’은 소프트웨어 개발이 항상 예측보다 시간이 오래 걸릴 수 밖에 없는 이유에 대해 소프트웨어 개발은 생산 공정이 아닌 디자인 공정이기 때문이라고 얘기했어.

  • 소프트웨어 개발이 왜 항상 예측보다 시간이 오래 걸리는 이유?

    • 진행하고 나서야 그 필요성을 깨닫게 되는 것들이 있음

    • 아무리 예측을 잘하더라도 파악할 수 없는 무지(Unknown unknowns)를 비켜나갈 수 없다.

    • 예상조차 하지 않은 일을 대비할 방도란 없기 때문이다.

    • 그러므로 소스코드는 제품이 아니라 디자인이라고 이해해야 한다.

그러니깐 일정을 지키지 못하는 것에 대해 너무 자책하지 않았으면 좋겠어. ‘마틴 파울러’도 소프트웨어에서 모든 노력은 결국 디자인으로 귀착된다.라고 했어. 여기서 디자인의 의미는 설계에 가깝고 creative와 연관이 있어. 예술가의 작업과 비슷한 점이 있다라는 거야. 예를 들어 A 기능을 구현하는데 작업시간 10시간을 예측했다고 했을 때 사실, 코드 라인 수가 1시간 마다 1/10씩 나오지 않잖아. 9시간 동안 고민하다가 1시간 동안 완성되는 경우도 있어. 그렇다면 경험이 많은 시니어일수록 일정 예측이 맞아가는 이유는 아래 두 가지야.

  • 경험을 통해 발생할 수 있는 문제를 예측해서 일정에 반영함.

  • 예측 못한 문제가 발생할 경우 해결 속도가 빠름

중요한 건 예측 못한 문제를 빠르게 해결할 기술 역량이 있는 것이지 문제를 모두 예측하기 때문은 아니라는 점이야.

그렇다면 일정이 무의미하지 않냐고? 아니, 주기적으로 프로덕트의 기능을 사용자에게 전달하는 것은 중요한 목표이기에 일정은 중요해. 그렇다면 일정을 지킨다면 모든 문제가 해결되고 우리는 성장하며 행복할까?

팀, 일하는 방식이 중요한 이유

일정 준수 보다 중요한 것은 조직이 어떤 방식으로 일을 하는지야. 기획팀, 디자인팀, 개발팀 등 직군별로 역할이 나뉜 조직이라면 기획팀은 기획을 완료해서 디자인팀에 넘기고 디자인이 완료되면 개발팀에 전달하기 때문에 결국 최종적으로 개발팀의 일정에 대해 주요한 책임을 지게 되고 불가능한 일정 내에 완료하기 위해 크런치 모드로 개발을 하겠지. 이런 조직에서 개발팀의 목표는 일정 내 해당 기능들을 완료하는 것이야. 여기서 생각해 볼 점은 이렇게 크런치 모드로 몇 일, 몇 주 동안 야근을 해서 완성한 기능이 과연 사용자에게 임팩트를 줄 수 있을까? 사실 아무도 몰라. 그렇기 때문에 팀의 목표가 일정 안에 정해진 기능을 구현하는 것이 아닌 사용자에게 어떤 가치를 줄 수 있는지가 중요해. ‘스리람 나자얀’은 아래와 같이 설명했어.

  • 디자인 공정은 계획에 맞춰 끝내는 게 중요한게 아니라 원하던 가치를 주는 것이 중요하다.

  • 소프트웨어를 개발할 때는 계획지향 프로젝트가 아니라, 가치지향 프로젝트를 추구한다.

원론적인 얘기지만 이렇기 때문에 어떤 조직, 어떤 팀에 있는지가 중요한 이유야. 가지지향 프로젝트를 추구하는 팀에서는 일정 준수보다도 중요한 것은 어떤 가치가 사용자에게 전달되는지가 중요하다는 얘기야.

우선순위가 중요하다

프로덕트 개발 일정으로 많은 조직에서 애자일 방법론에서 나온 스프린트를 많이 사용하고 있어. 조직별로 각자의 성향에 맞게 대략 2~3주 기간을 스프린트로 사용하고 있어. 우리 조직에서는 스프린트는 3주로 아래처럼 활용하고 있어.

  • 1주 : 스토리 분석, 설계 문서(우리는 Design Docs라고 얘기해) 작성 및 리뷰, 구현 시작

  • 2주 : 구현

  • 3주 : 코드리뷰, QA, 배포, 회고, 다음 스프린트에 진행할 백로그 논의

3주는 위킹데이로 15일이지만, 3주차는 실제 구현은 못하기 때문에 스프린트당 10일 정도를 엔지니어가 오롯이 프로덕트 구현에 사용하고 있어. 다시 말해 일정은 10일이야. 엔지니어는 10일 동안 구현할 수 있는 스토리를 PO(프로덕트 오너)를 비롯한 팀원들과 논의해서 결정할 수 있어. 스토리들은 매주 우선순위 논의를 거쳐 늘 우선순위로 정렬되어 있어. 이번 스프린트에 구현되어야할 스토리는 우선순위가 높은 것들이고 그중에서 다시 우선순위 정렬을 거쳐 사용자에게 전달되는 스토리를 정해. 여기서 모든 팀원들이 동의하고 있는 전제는 스토리들 중 함께 논의한 우선순위에 따라 완료될 것이고 완료된 것들이 배포 대상이라는 점이야. 모든 스토리가 반드시 완료되어야 하는 것을 목표로 하고 있지 않다는 것이지.

변경 가능한 인수조건

OO님, 첫번째 메일에서 예를 들었던 스토리 생각나니?

  • 스토리 : 사용자는 A기능을 통해서 구매를 할 수 있다.

  • 가설 : A기능을 통해 사용자는 구매가 2% 증가할 것

  • 인수 조건

    • 사용자 행동이 B, C, D일 모두를 만족할 때 사용자는 A기능을 사용할 수 있다.

OO님이 이번 스프린트에 이 스토리를 구현한다고 생각해볼게. 처음에 스토리를 분석했을 때는 이번 스프린트 내에 구현 가능할거라 판단했어. 하지만 예상과는 달리 구현하다보니 복잡도가 발견된거야 사용자 행동 B, C, D 케이스를 간단하게 파악할 수 있을거라 생각했는데 모두 별개의 작업이 필요했던거지. 이런 경우에는 혼자 끙끙대지 말고 빨리 PO에게 알리고 가설 검증이 가능한 인수 조건 변경 범위가 어디까지인지 같이 얘기해서 결정해야해. 다시 말해 B, C, D 케이스 중 가설 검증에 가장 중요한 것은 어떤 케이스인지를 같이 결정하는거야. 만약 사용자 행동이 B인 경우로도 가설 검증이 충분하다고 결정되면 C, D는 이번 배포에서는 제외하고 백로그로 보내게 되는거야. 다음 스프린트 우선순위 논의시에 다시 결정하는거지. 이 때 중요한 것은 스프린트 기간 동안에 인수 조건은 변경 가능하다라는 전제를 모든 팀원들이 알고 있다라는 거야. 어제의 최선이 오늘의 최선이 아닐 수 있듯이 사용자에게 임팩트를 전달하기 위해서 인수 조건은 계속 변경될 수 있는 것이지. 이렇게 사용자에게 전달된 스토리는 아래와 같아.

  • 스토리 : 사용자는 A기능을 통해서 구매를 할 수 있다.

  • 가설 : A기능을 통해 사용자는 구매가 2% 증가할 것

  • 인수 조건

    • 사용자 행동이 B일 때 사용자는 A기능을 사용할 수 있다.

그럼에도 일정을 지키려면

일정을 지키려면 어떻게 해야할까? 협업 밖에 답이 없어.

예측한 일정보다 늘어나게 될 수 밖에 없는 상황을 만나게 되면, 방법을 찾기 전에 우선 동료들에게 알려야 해. 특히, PO, PM, 시니어 또는 내가 구현한 결과를 사용해야할 다른 엔지니어일 수도 있어. 현재 상황을 가능한 자세히 설명하고 시니어나 동료 엔지니어로부터 문제를 해결하기 위한 도움을 받거나 PO, PM과 논의해서 해당 기능을 제외하거나 일정을 연기해야해. 이런 경우 가장 worst 케이스가 혼자 고민하다가 일정 마지막 전 날 마지 못해 동료들에게 알리는 것이야. 이런 경우는 본의 아니게 팀 모두의 목표 달성을 방해할 수 있으니 조심해야해.

정리하자면 일정을 준수하며 주어진 기획서를 그대로 구현하기 보다는 이 기능을 왜 구현해야하는지, 왜 중요한 기능인지, 불필요한건 아닌지, 더 좋은 방법이 있지는 않은지 고민하고 필요하다면 팀원들을 설득하면서 프로덕트 관점에서 프로세스를 리드하는 엔지니어가 되어야 해. 이런 성향의 엔지니어라면 남들보다 몇 배는 더 빨리 성장할 수 있고 필드에서 이미 이런 엔지니어들이 더 존경받고 인정받고 있거든. 꼭 기억하길 바래.

From. 구현 프로세스를 리드하는 엔지니어로 성장하길 바라며 OO님을 응원하는 Rock