프로세스
첫 워크숍부터 이관까지 다섯 단계입니다. 단계마다 목적과 산출물이 정해져 있고, 프로그램을 멈출 수 있는 종료 기준이 있습니다. 첫 단계도 예외가 아닙니다.
기회가 얼마나 큰지, 무엇이 막고 있는지를 고객사의 재무 언어로 정리합니다. 하지 않는 편이 낫다는 결론도 똑같이 열어둡니다.
종료 기준
담당 임원이 가치 산정치와 제약 목록에 동의해야 다음으로 넘어갑니다. 사업성이 안 나오면 사후 리뷰가 아니라 지금, 4주 차에 말씀드립니다.
찾아낸 것들을 누군가 책임질 수 있는 계획으로 만듭니다. 목표 아키텍처, 의존 관계를 반영한 순서, 투자 논거, 그리고 이번 분기 안에 오픈할 만큼 좁힌 첫 조각.
종료 기준
엔지니어링, 리스크, 재무가 같은 문서에 모두 서명해야 합니다. 셋 중 하나라도 못 하겠다고 하면 그 계획은 아직 덜 된 겁니다.
의견 대신 근거를 만듭니다. 1주 차에 아주 사소한 걸 프로덕션까지 올려봅니다. 그러면 환경, 인증 정보, 보안 심사, 배포 승인이 아직 아무것도 안 걸린 상태에서 전부 드러납니다.
종료 기준
조각이 실제로 오픈됐고 숫자가 예측이 아니라 실측으로 나와야 합니다. 기준선에 못 미치면 범위를 다시 잡거나 멈춥니다. 그 결정을 가장 싸게 내릴 수 있는 시점이 여기입니다.
검증된 한 조각에서 전체로 넓히되 딜리버리 리듬은 유지합니다. 여정과 세그먼트, 채널과 사업장을 늘려가는 동안 플랫폼은 아래에서 계속 단단해집니다.
종료 기준
현실적인 피크를 기준으로 부하와 장애 리허설을 마치고, 고객사 팀이 저희 없이 기능 하나를 처음부터 끝까지 출시해 봤어야 합니다.
저희가 빠지는 걸 사건이 아니라 계획으로 만듭니다. 이관 내용은 킥오프 때 계약서에 들어갑니다. 담당 역할, 날짜가 박힌 마일스톤, 그리고 기능이 하나씩 넘어갈 때마다 내려가는 수수료.
종료 기준
호출을 고객사 팀이 먼저 받고, 도움 없이 장애를 해결하고, 저희 없이 기능을 출시합니다. 3년 차에도 저희가 운영하고 있다면 그건 양쪽이 서명한 문서를 못 지킨 겁니다.
특정 단계에만 해당하지 않는 여섯 가지입니다. 위의 순서가 이름만 바꾼 폭포수로 변하지 않는 이유가 여기 있습니다.
범위를 정한 파트너가 오픈까지 모든 운영위원회에 앉습니다. 자문한 사람과 만드는 사람이 같으니 인수인계 절벽이라는 게 아예 생기지 않습니다.
모든 단계는 배포됐거나, 측정됐거나, 실제 사용자로 확인한 결과물로 끝납니다. 환경 세팅이나 승인, 보안 심사 같은 귀찮은 것들은 범위를 바꾸는 비용이 쌀 때 일부러 먼저 처리합니다.
고객사 담당 엔지니어가 첫 스프린트부터 저희 PR을 리뷰합니다. 처음 2주는 느려집니다. 대신 마지막에 하는 지식 전수 워크숍이 통째로 없어집니다.
게이트는 형식이 아니라 실제로 결정하는 자리입니다. 진단에서 멈추면 4주를 쓴 것이고, 같은 사실을 오픈하고 나서 알게 되면 프로그램을 통째로 잃습니다.
팀이 계속 유지할 수 있는 2주 주기에 맞춰 범위를 잡습니다. 야근은 계획을 잘못 짠 결과로 보고 장애처럼 리뷰합니다. 지친 팀은 그 자체로 딜리버리 리스크니까요.
사업성이 안 나오거나 일정이 비현실적이면 다음 게이트에서 말씀드립니다. 돈 주고 살 만한 자문은 결국 그것뿐이라고 생각합니다.
게이트는 형식이 아니라 실제로 결정하는 자리입니다. 진단에서 멈추면 4주를 쓴 것이고, 같은 사실을 오픈하고 나서 알게 되면 프로그램을 통째로 잃습니다.
모든 역량을 세 가지 형태로 제공합니다. 대부분은 작게 시작해서 첫 릴리스가 나온 뒤에 범위를 넓히십니다.
고정 비용으로 진행합니다. 비용까지 산정한 로드맵과 목표 아키텍처, 바로 착수 가능한 첫 릴리스가 결과물입니다.
AslanWay와 고객사 엔지니어가 한 스쿼드로 움직입니다. 합의한 성과를 기준으로 2주마다 프로덕션에 내보냅니다.
SLA를 걸고 플랫폼을 운영하는 동안, 미리 합의한 일정에 따라 고객사 팀이 단계적으로 넘겨받습니다.
어디서 막혔는지 알려주세요. 영업일 기준 이틀 안에 저희 생각을 정리해 회신드립니다. 저희가 맞는 파트너가 아니라면 그것도 그대로 말씀드립니다.