배민다움 만들기
왜 자꾸 질문할까?
p-68
같은 질문이 계속 된다는 것은 업무 프로세스상 문서화가 덜 됐거나, 의사소통의 명확성이 떨어지는 등의 문제가 있다고 볼 수도 있습니다. 다른 이유로는 비즈니스 프로세스 자체가 문서화로는 해결되지 않을 정도로 복잡할 수도 있습니다.
질문하는 것을 막아서는 안되겠지만 질문이 왜 반복되는지, 그럴 필요가 없게 만들 수는 없는지 고민이 필요해 보입니다.
KPT에서 주의할 점
p-76
통합 시연이란 애자일 개발 방법론에서 자주 나오는 항목인 '지속적인 통합'을 실천한 것입니다. 오픈 일정은 정해져 있습니다. 오픈 직전까지 완전 통합 서비스를 끝내야만 합니다. 그 시기까지 일주일 단위로 할 일을 나누고, 일주일마다 그것이 달성되었는지 통합시연을 보여줍니다. 실제로 일주일마다 시연을 하면 제대로 작동하는 경우가 별로 없습니다. 그리고 제대로 작동을 하더라도 문제가 발생합니다.
"저건 제가 애기했던 게 아닌데요?"
여러팀이 만든 각종 API는 의도대로 구현이 되었는가?
기획자의 의도대로 구현된 것이 맞는가?
기획자의 의도대로 했지만 오히려 불편한 점이 없는가?
위 사항들을 찾는 점에 의의가 있습니다.
1주일에 한 걸음씩 무엇을 했는지 살피면 성취감도 느낄 수 있고 집중력도 오래 유지할 수 있습니다.
p-78
KPT를 하면서 몇 가지 주의할 점이 보였습니다.
첫째로 남 탓을 해서는 안됩니다. 내 문제가 아닌 남의 문제 혹은 남의 잘한 점을 내가 개선할 수는 없습니다. 문제의 초점을 남이 아닌 나로 옮겨서 살펴봐야 내가 할 일이 도출될 수 있습니다.
두 번째는 구체적이고 실천적이어야 합니다. "이번에 소통이 안 돼서 장애가 났습니다. 공유를 잘합시다." 이건 하나마나한 얘기입니다. 공유를 잘할 수 있는 구체적인 방안이 Try로 도출되어야 합니다.
공유를 잘할 수 있는 구체적인 방안이 Try로 도출되어야 합니다.
예시)
problem: 광고 상품이 추가되면 유관 부서에 공유해줘야 하는데 안 해줘서 데이터 정합성이 안 맞는 일이 발생했다.
처음 나온 Try: 상품이 추가되면 x, y, z 팀에 잘 알려주도록 합시다~
구체적 Try: 상품을 추가하는 코드가 호출되면 유관 팀을 모아둔 그룹 메일을 자동 발송하는 기능을 넣도록 합시다. 유관 팀이 변경되면 그룹 메일에 해당 팀을 추가/삭제해주면 됩니다.
더 근본적인 Try: 광고 상품의 추가와 무관하게 작동하는 보편적 시스템을 구축하자.(여기까지는 아직 못갔음)