0811 업무방식 회의

확장하자만 있으니까 네, 시작하셔도 됩니다 제가 생각한 거는 일단 DRI는 무조건 유지한다 근데 어제 근데 개인 퇴근이나 이런 거를 다들 했을 때도 그 DRI에 책임을 절 수 있게 하고 제가 그런 거에 대해서 디테일하고 관여 안 하는 게 또 사실 원하는 방향이었긴 했어서 그거 전제를 그대로 가져간다로 얘기를 드리면 어제 말한 대로 맨 처음에 이 제품의 방향 그게 하나의 기능, 그 피처든 이 프로젝트 자체든 방향은 제가 결정하고 고민하고 결정해서 해야 된다라고 먼저 제안을 하고

근데 그거를 그 PRD, 그리프 형태로 먼저 가져와서 지금은 사실 DRR 회의룩 자체를 그리프가 좀 쓰고 있잖아요 아유 형태의 길딩인 것으로 계속 사용이 되는데 그렇기 때문에 DRI 구리가 쉽지 않은 것도 있는 것 같아서 애초에 딱 DRI를 나눠주고 하나하나의 단위로 문서를 가져와서 그 문서를 브리프를 하고 그거를 기준으로 누군가에게 DRI가 부여되면 그거를 기본 골조로

본인의 나머지 PRD를 채우는 DRI로서 하고 그 안에서 그 DRI 담당자로서 해야 되는 PRD의 파트가 있고 이 프로젝트에 참여하는 개발장과 디자이너가 할 파트들이 있을 거잖아요 그것들을 각자 같이 PRD로 완성하는 작업이 되면 완성된 PRD로 이제 전체 계기가 있었으면 좋겠어요 왜냐면 사실 이 4명의 속도를 내려면 무조건 전체 회의로 C6의 일부분은 가져가야 될 것 같거든요. 그래서 다 같이 한번에 논의를 해서 결정을 짓는 것.

대신 근데 그 결정 짓는 거는 그때 의사결정은 그 DRI를 맡은 사람이 그 회의를 주도하고 준비해 올 때도 여기서 의사결정을 해야 되는 게 뭘지 같은 것들. 그게 이미 PRD에 나와 있겠죠. 그거를 하고 그 다음에 다시 로우파이를 부활시켰으면 좋겠어요. 근데 그거를 피드마로 만들어 온다는 보다는 누구가 있잖아요. 그냥 손그림으로 그려와가지고 이런 맥스고 그거 소재로 사실 문의하면 정말 빠르게 잘 됐던 경우들이 많기 때문에 그거를 해서 이게 새로운 기승이든 기존에 있는 건데 바꾸고 싶은 거든

그래서 그거를 디자이너가 DRI로 회의를 진행을 해주고 왜냐면 어쨌든 저는 그걸 주고받는, 역시 주었거든요. 프로덕트 디자이너가 갖고 있긴 해야 된다고 생각하거든요. 그래서 그걸 해준 다음에 그리고 의견들을 교환하고 당첨도 다 해서 그 피드백을 반영해서 하이파이를 가져오는 거. 그래서 그 하이파이를 가져온 것도 전체 메일을 해도 되지 않나 싶어요. 지금의 제일 흐름은. 그래서 맨 처음에 완전 제로 베이스일 때 다 같이 회의 한 번. 그러면 이제 프로덕트의 방향을 이해했으니까 로우파이 그리는 동안 개발자도 뭔가 빼게 해서의 다른 걸 준비할 수 있고 기술 검증을 하고 있을 수 있잖아요.

그런 식이 병행이 되고 하이파이가 완성되어 오면 그게 그 노우 어제 말했던 그거랑 비슷한 것 같아요. 가져오고 나서 내가 이거 하겠다. 피치 같은 거 하겠다 였잖아요. 이런 의견이 있었는데 내가 판단하기에는 이런 레플레스 창고에서 이렇게 결정했다 이렇게 하면 이 점이 더 좋아서 이렇게 했다 같은 게 설명되면 납득하면 그대로 해서 구체적인 인터넷션 이런 것들 확인하고 바로 작업 시작하면 되는 거고 봤을 때 개발자가 그중에 기술 검증 해범도 있는데 어 안 되는데 들어가 있어 아니면

안 되는 것 같아서 이렇게 했어요 라고 우리가 말했는데 확인해 보니까 어! 저번째 업데이트가 돼서 뭐가 될 것 같아 그러면 또 더 고도화된 기술을 제한해 주면 되는 거고 그런 것들이 됐으면 좋겠고 그 다음에 근데 그거 과정에서 이제 이건 디자인의 DRI 파트였지 이제 이 기능 자체, 이 종교를 위한 DRI는 누군가가 있는 거잖아요 그래서 그 다음에 마지막에 이 기능이 다 개발되고 나서는 그 DRI가 와서 그거에 대해서 이렇게 마무리가 됐고 같은 최종 피치가 있으면 될 것 같아요

그래서 거기서 뭔가 근데 완성을 해왔는데 완성해놓고 보니까 UX를 계산해야 될 것 같을 수도 있잖아요 그런 것들을 그 자리에서 논의해서 다음 테스크가 정해지면 될 것 같아요. 그런 흐름을 생각하고 있습니다. 좋습니다. 혹시 무슨 과정 프로세스부터 바로 공유를 할까요? 아니면 제가 말한 거에서 뭔가 이해가 안 된 부분이 있다든지 아니면 이 부분 파트 이렇게 바꾸면 더 나을 것 같은 그런 의견이 있으시나요?

저는 근데 크게 하기, 크게 뭔가 생각보다는 자발적으로 할 수 있는 장치에 대한 위주로의 프로세스에 고민하고 있고요 자기 등감을 어떻게 잘하면서 테스트를 할 수 있냐? 네, 기능입니다 뭐 이제 DRI를 확실하게 나눈다 -던지? -아 어떻게 DRI 확실이 나올 것인 것 같은데? -DRI 확실이.. -그러니까 지금은 뭐하고

뭐는 누가 해야 되고 같은 큰 틀을 일단은 나눠야 된다고 생각을 했고요 -아 애초에 누구의.. 그러니까 이런 일이 생겼을 때는 누구에게 DRI를 줄 거냐 같은.. -그쵸 그러니까 저의 작동하는 그 큰 흐름은 사실 NO가 디자인이고 프로덕트 디자이너에 대한 DRI를 아예 온전히 배정한다라고 하면은 노우파이나 이런 것들에 대한 것들도 이제 노우가 알아서 고민해야 되는 거고 팀을 위한 것을 알아서 고민해야 되는 건데

그러면은 똑같이 제대로 작동 안 할 거란 말이죠 노우 저격 그런 건 아니에요 예시가 너무 근데 그거의 존재로 그래서 이 택초의 PRD 분석에서 이미 다 정의된다의 개념으로 저는 해결이 된다고 생각하거든요 뭐 그런 형태면은 뭔가 그거를 증빙크니까 이 명확한 DRI를 배정하는 것 그다음에 이제 저는 평가를 지속적으로 해야 된다. 좋아요. 그러니까 그게 잘 이루어지고 있고

그러니까 이거 명확하게 적진 않은 게 성과제나 아웃제가 있어야 된다고 생각해요. 누가 말한 그 3아웃처럼 그런 것들? 네. 이런 장치가 있고 책임을 부여했을 때 자발적으로 돌아갈 수 있고 자기의 업무 안에서 잘하는 거는 본인이 고민하는 구조가 이상적이지 않나요? 누가 이 엉불 제세를 준비할 때 생각했던 DRI를 분명하게 해놔야 된다는 사실 제가 말한 맨 앞에 대표가 적은 거기에 이미 어떤 임무가 부과될지 정해질 거니까 1차는 해소도 될 거 같거든요

근데 스트라이크아웃 같은 거에 대해서는 저는 아직은 생각해 온 건 없는데 근데 제가 이 평가제도를 만들었잖아요 그 이유는 이 평가제도에서 지금 만약에 개선하겠다 하는 항목 있잖아요. 그게 4주 뒤에 수행이 안 됐거나 그거에 대해서 그때 근데 제가 우리가 그 썼잖아요. 확인 기준이 뭔지도. 근데 그게 문서가 있다고 해서 쓰니까 됐네 라고 안 할 거예요. 그때 똑같이 이 투표 이걸 쓸 거예요. 똑같이 지금 제가 그 투표에 이거

설문, 설문 투표 말고 이거 뭐죠? 평가지! 이럴 수 있거든요. 근데 그때 평가지의 기준은 지금은 3월부터 지금까지 기준이었잖아요. 그때는 딱 지금 이제 8월 12일부터겠죠? 8월 12일부터 평가하는 그 다음 KPT 회고 전까지의 에? 평가지에 본인이 개선하겠다고 약속한 거를 어떻게 했는지를 똑같은 평가지로서 할 거예요. 근데 거기서도 낮은 점수가 나오거나 이견이 있다 그러면 그거는 객관적 평가지표잖아요 이 업무에 대한 그럼 그거는 수행이 안 됐다고 보고 개인연담을 해서 제가 그 사람에게 왜 안 되는지 확인하고 원인을 찾고

안 되면 정말 퇴사를 권유하는 식의 그 평가지 자체가 하나의 그게 될 거고 그리고 근데 사실 그 노무가 말하는 여기에 속이 안 된 내용들도 수행이 안 될 수 있는 거잖아요 그런 스트라이크 제도 같은 거는 제가 고민을 해서 모지를 해보겠습니다. 이 DRI 시작할 때. 근데 이 시작이 사실 당장 다음주 화요일이 시작되지 않겠나 싶거든요. 그래서 다음 평가 기준은 다음주 화요일부터 일 거라고 생각이 되는데. 왜냐하면 지금 논의된 것들을 정비하는 시간은 필요하니까.

그래서 일단 제가 처음에 가져올 PRD에는 그걸 적을 거예요. 누가 어떤 업무에 무슨 문제를 해결해야 된다. 이로 올 거예요. 근데 임재경은 뭐죠? 누가 뭐 이런 거죠? 스트릿 누가 소사이사 앱에서 구동되게 한다의 목적이 가질 수도 있는 거고 아니면 지금 핀그룹의 UX가 되게 많이 변화가 돼야 되는 거라서 이거 UX 구조를 개선한다가 그냥 과제일 수도 있는 거고 그런 식으로 하면 UX를 개선하는 구조면 노우에게 DRI일 수겠죠?

개발이 주가 되긴 하겠지만 주는 거고 근데 그 안에 그렇게 참여해 둘 중에 한 명의 개발이 들어가 있겠죠 그렇게 되는 거고 스트립뷰를 구성되게 한다면 누가 DRI를 하겠죠 스트립뷰 안에서 어쨌든 인터렉션을 결정을 하던 제안을 하던 그 디자인의 역할도 크긴 하잖아요 지금 왜냐면 나와있는 그 앱에 아직 얹어진 UI가 없다 보니까 그러면 같이 거기서 참여해야 되는 거고 근데 사실 디자인부 명세도 필요 없는 어떤 개발 과제가 있어 그러면 본인 스스로가 아예 온전히 책임져서 하는 거겠죠?

아니면 근데 그게 MDM이야. 그러면 문 앞에 뭐가 있으면 자꾸 물을 예시를 드리게 되네. 그러면 이게 PCI야. 그러면 김정인 교수님 만나서 알아서 라푸스 쌓고 알아서 정보 계속 캐내고 하는 거는 알으냐고 그거를 제때 공유하는 이 시점에는 어느 정보까지 얻어서 그 정보 얻은 걸로 뭘 하겠다 같은 말통을 다 잡아놓고 그걸 수행하고 하는 거겠죠. 그리고 제가 그 말통 잡은 거에 대해서 일정 안 된다 같은 것들을 이제 진실을 하겠죠. 그런 식.

그래서 제가 맨 처음 해야 될 줄 때는 어쨌든 그건 말아 문제의 근거. 문제와 근거 왜 해결해야 되는지. 그러니까 이 사업 목적이 뭔지. 제가 스트릿도 해야 돼요 하면 이게 완성이 되면 이거를 빌미로 국수본에 연락을 해보겠다라든지 이것까지 완성된 업데이트된 버전을 김종 교수님께 가져가서 우리 시각화 지금 요 정도까지 돼 있다. 근데 경찰에만 어떤 기능을 조언해 줄 수 있냐 같은 거를 쓰겠다. 그러니까 이걸 어떻게 활용할 건지 같은 것도 얘기해줬고 그 안에 또 사업의 우선순위. 다들 그랬지만 우선순위가 뭔지 애매해지는 게 있다. 그럼 할 때 제가 그거를 P형 1, 2, 3 단위로 주는 거는

너무 개발 측면의 우선순위인 것 같아서 일정적인 우선순위를 드릴 것 같아요. 지금 우리가 크게 잡고 있는 게 이런 것들인데 그거를 미루더라도 이거 완성을 몇 월 몇 시까지 해야 된다 개념의 우선순위가 제한이 될 것 같고 그리고 뭔가 핵심 가치 같은 거 이게 될 때고 단순위 이런 것일 수도 있잖아요. 프로토타일만 나오면 된다의 가치만을 지금 가지면 되는 게 있을 거고 아니면 경찰이 진짜 썼을 때 수사 그림에 쓸 수 있을 정도까지 해 줘요 오면 이제 본인이 할 때 프리할드에 경찰 만나서 유티하는 거까지 포함이 돼야겠죠

그런 식의 어느 정도 가치나 기능을 작동해야 되는지의 수준도 정해질 거고 완료 기준 어제 얘기했던 날짜 명확히 제가 이미 줄 거고 끝까지가 될 거고 그리고 만약에 여기서 돈이 나가면 돼 서버 이렇게 막 변개돼 있어 그럼 예산에서 얼마까지 써도 되는지 제가 정해줄 예정입니다 그거를 받고 나서는 이제 역할마다의 DRI가 뭐 어플업 디자인 같은 경우는 사용자 플러그 어떻게 갈 거냐 그리고 만약에 뭐 UX 같은 것도 안이 만약에 1, 2, 3안이 있으면 이 약까지 줄여와서 제안을 하고나 이렇게 되는 거일 수도 있고

개발자 같은 경우에도 좀 많이 꼬여있겠죠. 데이터 같은 어떻게 구조할 거냐, API 같은 거 어디 거 끌어올 거냐 그런 것들, 그리고 기술 제약 같은 거, 그런 것들을 각자 DRI 고민해서 하는 식으로 하면 될 것 같습니다. 그래서 이미 조선을 비교 안 됐는데 질문을 저한테. 그럼 저희가 바로 발휘할 거예요. 더 수행해서 물어보세요. 그리고 뭐 아니면 오히려 내가 볼 때는 제가 볼 때는 개발 범위 내에서 그냥 결정만 하면 그만이야. 아니면 디자이너가 결정해도 그만이야. 근데 물어보면

'어? 그냥 이거는 스스로 판단할 것 같아요'라고 그냥 제가 참여를 안 하고 밸려하는 경우가 있을 수도 있고 그러면 그때그때 하면서 레벨을 맞춰 가보면 좋겠다는 생각이 듭니다 좋습니다 그래서 이 프로페스 적용은 다음 주 화요일부터 하면 될 것 같아요 그 화요일에 제가 이 DRI를 형식을 만들어가서 짜잔~ 어머~ 근데 이미 사실 짜져있긴 한데 아니 굵직하게는 그 안에 세 분을 어떻게 기다려야 하는 거니까?

네 그걸 화요일에 가고 그래서 그래서 화요일을 하기 전까지 지금 하고 있는 업무들을 스탑? 문서를 줄 필요 없는데 스탑을 외워도 상관없을 것 같겠네요 근데 이 전체 문서를 줄 필요 없고 굵직하게 수행하고 있는 프로젝트의 벽 뭐 OCR, PCI, MDM, 뭐 스트립규어 이런 식으로 그걸 주면 제가 이 업무를 하는 거에 대한 그 목적과 아까 말했던 제가 정리해야 되는 PRD의 양식으로 가져오겠습니다. - 그렇죠. - 응.

가장 굵직한 하나의 그런 이름, 금방 예시처럼 가져오겠습니다. 로독핀 유엑스 이런 게 있는 것 같죠. 그런 걸로 하면 회원님께 화요일에 딱딱 분배가 되는 걸로 그럼 일주일 휴식? 네 그래서 그 얘기를 하고 싶은데 휴가 같은 게 있긴 해야 되잖아요 제발 그래서 이것을 근데 리프레션은 3주 화요일에 시작을 해야 될 것 같긴 한데 근데 그 다음날이 출장 가면 좋고 어 저는 그거 준비해야 되겠네요 아 그거 그거 하나네?

네 그러면은 진짜 지금 하고 있는 개발 업무를 스톱하고 이것만 하는 라이브 하는 그러면 가장 많이 될 것 같아요. 저는 그거 준비하고 PRD 적용할 거 준비하고 그래서 피그마에 들고 있는 연계 쓰는 거 개발하고 있는 코드 이런 거는 스탑이 될 것 같습니다. 그 MDM도 그냥 하고 될 것 같습니다. 그리고 - 김지영 선생님이 질문할 거. - 그냥 누구만 리스트. - 아, 네. - 한 번.

- 이거 좋은 거 어떻게. - 좀 꺼지는 건가 지금? - 그리고 그 폰 분배도 미리 지금 분배하는 게 나온 것 때문에 하고 아니면 MDM 세팅할 때 누가 다 세팅해서 관리하는 거 해보고 싶으면 그냥 다 가져가도 돼요. - 그렇죠. 저 다 가져가는 거 아니었어요. 무에게 달려있어요. 한 개 근데 저 갖고 있긴 해요. 저 벌레예요. 저는 근데 당연히 제가 다 가져야 된다고 생각해요. 아 그래요? - 근데 그게... - 아니 아니 아니. 아예 문방 달려가... 근데 테스트 어차피 두 대밖에 못해서 가져가고 싶은데 가져가도 돼요.

- 아 두 대밖에 못한다고 그랬지? - 네. 최대 두 대 생각해보는 거 같아요. 아 켜지네. 근데 그게 찝찝해요. 그래서 아이클로우트까지 연도를 안 해놔서 그냥 제 거 로그인을 해야 쓸 수 있긴 하잖아요. 그래서 로그인 해놓고 수사위당하면 다 넣었겠거든요. 근데 그게 다른 그 같은 걸 연결을 안 해보니까 쓰기 그냥 애매한? 왜냐면 데이터도 안 들어가 있으니까 진작 내가 일일이 수기로 입력하는 것 밖에 못 써보니까 애매하긴 한데 근데 이테라도 좋아요 이테라라서 좋아요 - 근데 그걸로 용량을 쓰기? - 이테라로? - 사진 찍고 나야 하는 거세요? - 이걸로요?

- 진심으로? - 사진 찍은 거 밖에 없어요 - 그래요? - 아니 저 폰이 진짜 용량이 한 0.5기가 있거든요 - 아 이걸 쓰시는구나 - 1기가가 안 돼 - 저는 완전 개발용 말 만한지 - 다른 기기 없이 설정해도 돼요? 아 네네. 저 두 번 들고 나가봤어요. 집 밖에. 진심으로 여행 갈 때. 너무 잘 찍혀서 문양이 아직도 이태라고 할 것 같아요. 근데 그거 말고 진짜 테스트할 게 없고. 뭐 가져갈 거 흰색도 있고. 흰색 갈 거. 오렌지색인데. - 저도 오렌지색. - 이거 오렌지색 반납이죠 얘가.

- 10월. - 10월. 저 흰색 흰색. 그리고 데이비드 만났을 때 그쪽으로 얘기해서 연장할 수 있지 않을까? - 필요하면 가져가세요. - 안 필요하긴 해요. 그냥 가져갈 거면. 들고 있으면 또 관리를 해야 되는데. 그러니까. 저한테 다 행기. 네 오늘만 놀고 드릴게요 아 그러세요 이건 어쨌든 다 논의가 된 것 같아서 하얀 분이 많아 무슨 프로세스적인 거나 아니면 뭔가 누구처럼 이런 걸 해소하고 싶은 게 있었다 같은 거 있나요?

저 하나 더 있긴 해요 어 뭐예요? 60분 남아 있을까요? - 아 10분 안에 끝내야 되고 - 왜 이렇게 냄새가 구리지? 아 근데 저는 그때 얘기했던 어 그쵸 뭔가 핸드크림 찍어먹고 어느 공간에 그쪽 오래 있었다 - 그 같은 - 말씀하셔 블루베리 버튼 같은 - DRI에 대한 거에요 - 아 그 부분에 너무 많구나 제가 피처를 바꾸자 보다는 이제는 좀 제가 리서치 분야로 조금 더 하는 게 낫지 않냐고 얘기했던 이유도

자기 평가에서도 뭔가 나타났다고 생각하거든요 그러니까 각자가 잘 할 수 있고 강점이 있고 제가 약한 분야가 있고 강한 분야가 있는데 그거를 활용할 하고 DRI를 배정을 해야 되는데 그게 지금은 잘 안 돼 있다고 생각하고 그거를 저희가 판단할지 아니면은 그 개개인의 역량을 대표가 판단해서 배정할지는 고민을 해봐야 될 것 같아요 근데 이거 아까 맨 처음 말 때 저는 이 얘기하는 것 같다고 생각했거든요

왜냐면 그 DRI를 하면 해결될 문제까지는 얘기가 됐는데 그래서 DRI 기준이 뭐냐 하면 애매하긴 하잖아요. 근데 저의 지금 고민이고요. 어제 드러났던 평가로는 이걸. 여기서 앞에 연구하고 기술에 대한 비전과 고도하고 방향을 제안하고 빠르게 프로토타입을 실행하는 게 사실 남는 거잖아요. 근데 그렇게 치면 이제 모든 피처의 개발 두 명이 그러니까 이 개발팀 이제 이렇게 된 거예요. 개발팀 안에 모든 피처가 다 있는 개념이 돼버리는데 그것도 어떻게 보면 위험하긴 하잖아요. 그것도 살짝 고민이고 또 하나는 이미 그 피처들을 썼거나 교환하는 거에 대해서 거절을 했어.

이미 논의가 그리고 물어봤을 때도 종결이었다 라고 했어. 그럼 거기서 그 다음 바꿀 때 저에게 기준이 없는 거죠. 왜냐면 바꾸고 싶은 의사가 확실히 있는 것도 아니고 아니면 제가 이거 누구에게 바꾸세요 했을 때 그 사전 업무가 어떻게 될지도 고려를 해야 되잖아요. 그 기준치가 지금 없어서 애매하긴 한데 사실 지금 제가 대화를 준다면 지금 잡고 있는 사람이 누구냐에 따라서 그러니까 만약에 A를 고도화해야 돼 그러면 그게 지금 A와 상관없이 새로운 기술 개발일 수도 있잖아요. 코드가 그냥 다 후에 새로 쓰는 거일 수도 있잖아요.

그렇더라도 A에게 준다의 전제가 사실 우선될 수밖에 없긴 하거든요. 근데 이렇게 하면 또 문제는 또 CCS에 병폐가 이어질 수 있다. 그리고 이렇게 하다보면 그 업무 균형이 안 맞을 수 있거든요. 지금 A를 가지고 B를 가지고 있어. 근데 새로 계속 고도화를 해야 되는 과제들이 B 안에서만 주어지는 거예요. 경찰을 만나 보니까. 여기 새로운 기능 추가되면 좋겠지. 추가되면 좋겠지. 추가되면 좋겠다면서 B가 계속 스택이 쌓여요. 그럼 결국에는 이걸 떼서 균형을 맞춰야 되는데. 그거를 고려하면 애초에 개발 한 팀 안에 모든 테스트가 달려있게 하는 게 또 맞기도 하고

근데 이거를 일부분이 해소를 하기 위해서 있는 게 그 PRD 안에서 각자 역할 맡은 것에서 각자 PRD를 쓰는 구조를 만들긴 한 거거든요. 그걸 해보면서 한번 해보고 어차피 DRI라는 건 내가 진짜 이 안에 프로젝트를 하기 위한 모든 일을 내가 한다의 개념이 아니라 관리한다의 개념을 가지고 그 안에서 내가 수행할 파트와 누군가가 수행할 파트가 나눠져 있긴 하니까 그걸 내가 만약에 태인이에게 맡겼어 근데 뭐.. - 태인이가 계속 하얀색으로만 해? -

- 어, 맡겼어 근데 할 때 보니까 태인이는 프로토타입만 만든 게 맞는 것 같고 그 전에 뭔가 다른 거를 누가 해주는 게 맞는 것 같아 그러면 이제 그 프로젝트 팀넬을 시켜서 그 테스크를 나눠보고 이걸 관리를 스스로 하는 걸 하면서 베스트 안을 찾아서 제안하는 게 맞는 거 근데 저는 약간 이게 좀 맞는 거 같은 게 만약에 작업이 많아지면 좀 넘겨 봤거나 아니면 내가 너무 많거나 시간이 부족하면 그걸 상대한테 주거나 해서

이게 조금 합이 맞았으면 좋겠구나 그게 지하라이가 해내면 될 것 같다 근데 그게 만약에 본인의 고민이야 그리고 사실 지하라이가 줬는데 받는 사람이 지금 저 룸이 풀입니다 할 수 있는 거잖아요 그런 것들을 이제 관리자의 개념으로서 해보고 근데 거기서도 만약에 해소가 안 돼 그리고 제가 이미 우선순위를 써놨는데도 그 사람에게 업무를 요청하려고 보니까 우선순위가 꼬여서 또 모르겠어. 그럼 그때 이제 대표한테 가서 물어보던지 모두가 있는 자리에서 아직 꼬여가지고 다시 정리해야 될 것 같아요 하면서 좀 해보게 될 것 같아요.

비중? 당장에 뭔가 딱 뾰족한 그럼 지금 앉아가지고 다시 비춰 나누자 이게 지금 좀 안 되긴 할 것 같아요. -끝! -끝! -끝! -끝! -끝! -끝! -끝! -끝! 끝이긴 끝인데 저는 약간 소감 같은 거 한 번 했으면 좋겠다. -소감? -그래요? -근데 저는 그게 진짜 궁금해요. -네. 정말 개선 의지가 있는지가 사실 중요한 의견이거든요.

저는 이 어제 주고받았던 피드백이나 개선할 사항을 찾는 것에 대해서 적극성이 없으면 그것도 저는 개선은 이제 없는 사람이라고 생각을 하기 때문에 정말 어떻게 개선을 하고 싶은지와 지금까지 우리가 문제 진단한 거에 대해서 어떻게 생각하는지가 스스로 인식이 어떤지를 자기 입으로 말하였으면 좋겠군요 누가 생각한 소감은 혹시 아 좋아요 우리 이제 화이팅 합시다 이건가요? 저는 절대 아니죠 저는 가혹해요 늘 그러면 소감 가시죠 근데 그런 결은 아니었고

제가 느낀 거는 그냥 완전 쿠션 없이 얘기할게요 저는 자기 평가에서 너무 개개인한테 후하게 점수를 줬다고 생각해요 그러니까 결과적으로 지금까지 보고 국가수사본부까지 간 게 우리의 시간과 노력과 성과로 왔냐고 하면 저는 절대 아니다라고 생각하거든요

이거는 그냥 우주의 기운이 와서 된 거지 저희가 뭐를 잘한지 개개인이 다 스스로 의심을 해야 된다고 생각해요 그래서 저는 다 평균적으로 스스로 높게 준 거에 대해서 좀 놀랐다고 생각하고 그거에 대해서 인지를 하고 자발적인 개선이 이루어져야만 이 회사에서 살아남을 수 있다고 생각합니다.

-이상? -네. 그럼 저 덧붙이자면 저 어제도 사실 개개인에게 질문할 때마다 퍼실리에이터를 하면서 확인을 했는데 뭐 이런 거잖아요 내가 만약에 4.5점을 줬어 라고 한다면 이게 1점에서 5점에서 4,5점을 준 게 아니라 그 4점의 내용을 수행한 근거가 있기 때문에 4점을 줘야 되는 게 이 평가지표의 원칙이었잖아요 근데 그걸 정말 내가 그게 있느냐를 돌아보고

내가 근데 만약에 이미 그 점수를 줬어 그래서 내 죽음이가 일단 그 점수에 안했다고 믿고 있어. 그러면 그 믿고 있는 거에 대한 근거를 남은 사주 안이라도 만들어 내는 게 진짜 팀에 기여하는 거라고 생각을 해요. 왜냐하면 제가 지금까지 느끼기에는 정말 주어진 테스트만 하면서 그러니까 우리에게 필요성이 있는 일만 했다고 느껴지거든요. 왜냐하면 근데 그 전제가 그 부분 제가 이해하는 게 그냥 딱 하나예요. 모든 주도권을 우리가 가질 수 없는 이 B2G와 특히 수사이사의 특성상

어? 그럼 다음에 뭐 UTS의 결과가 나오면 하자. 시범 도입되어서 나오면 하자. 옥수본에서 정보를 더 주는 단계가 되면 하자 라는 핑계 아닌 핑계로 미뤄진 일들이 있거든요. 그렇기 때문에 사실 사후점에 나올 수 없는 것들이 있는데도 테스트 이상을 했다라는 존재가 되는 거는 조금 더 구체적으로 돌아보긴 해야 된다 아니면 본인이 생각할 때 근거가 있다면 정말 그게 팀에서 느껴지고 팀의 성과로 보여질 만큼의 결과물이 같이 있어야 된다

그런 생각이 들었고 또 하나는 다른 사람들이 이런 사례에서 이런 어려움이 있었다 그래서 이렇게 개선했으면 좋겠다라는 거에 좀 더 수용을 하는 태도가 있었으면 좋겠어요. 아니면 정말 해결책을 찾아보려는 그 해결책을 강구하려는 몸부림을 쳤으면 좋겠어요. 왜냐면 저는 이걸 평가지를 만들 때도 그랬지만 스스로 평가하고 동료평가를 하면서도 계속 이걸 개선할 해결책을 고민을 엄청 많이 했거든요. 그래서 이미 뭔가 DRI를 해소할 방식이라든지

제가 저를 이미 낮게 평가한 게 있기 때문에 어 그러면 이걸 어떻게 개선한다고 말해야 되지를 생각해서 사이사이 단계에서 확인하는 거 하는 대신에 아 목표를 잘 설명해놓고 자유도를 줘야 되는 건가 보다 이런 판단을 해놓고 와서 그게 맞냐 그렇게도 되겠냐를 확인하고 했던 거거든요 근데 다른 분들도 본인이 자기를 낚여간 거에 대해서 아 이거 문제네 이게 아니라 이걸 내가 어떻게 해결하면 팀에 기여가 되지? 라던지 아님 누군가가 기여해 달라고 했어 이런 식으로 그러면

그 기여해달라는 말 앞에 붙들던 어떤 사례 아닌데 그 상황에 내 시선 이랬는데 이게 아니라 아 이거를 개선하면 우리 팀 더 좋아지는구나 내가 뭔가 움직여야 되는구나 라는 좀 긍정적이고 운동적인 판단이 있으면 좋겠어요 그리고 그게 안 됐다는 거는 팀의 피해라는 인식이 있어야 된다고 생각합니다 저도 뭔가 하면서 되게 돌아보는 계기가 왕이 됐고

이제 앞으로 조금 더 구체적이게 수행할 수 있는 프로세스가 만들어졌으니까 그거에 맞춰서 그 이상으로 하려고 조금 더 이렇게 볼 것 같아요 -불바? -불바? 저 열심히 하겠습니다 각자 얘기한 걸 잘 지켜보도록

요구되는 것들을 노력해볼 게 아니라 정말 수행한다 수행해보겠습니다 그리고 저에게도 사실 기존에는 팀원의 입장으로 얘기할 때도 있고 대표님께 할 때도 있고 약간 그게 있는 거 같거든요 이제는 대표에게 뭔가 근데 사실 회사도 그렇잖아요 시대들한테 요구하는 게 없을 수는 없잖아요 그런 것들에 대해서도 허심탈이니까 굉장히 좋고 원원의 개념이든 진짜 면담이든 아니면 업무에 뭔가 보충이나 고민이든 잘 소통이 되면 좋을 것 같습니다

왜냐면 사실 기존의 소통은 진짜 실무의 개념에서의 소통이 대부분이었어서 각자 새롭게 정리된 역할과 이 테스크를 수행하기 위한 소통이 잘 되면 좋겠네요 - 화이팅 해보시죠 - 아자! - 화이팅 - 녹음 멈추겠습니다