# data[].attributes.headline
조직과 구성원이 함께 가기 위해

# data[].attributes.subject
조직과 구성원이 함께 가기 위해

# data[].attributes.body
최근 변경된 조직 체계에 대해 기존 업무가 여전히 마무리되지 않은 상황 속에서도, 변화된 구조에 적응하고 이해하려는 노력을 지속해 왔습니다.

다만 업무를 수행하는 과정에서, 리더 분들께서 각 구성원이 어떤 역할을 수행하고 있는지, 현재 어떤 어려움을 겪고 있는지에 대한 관심과 이해가 충분히 이루어지고 있는지에 대해서는 의문이 드는 상황입니다.

정리되지 않은 기존 업무가 여전히 진행 중인 가운데, 새로운 과제가 지속적으로 부여되고 있습니다. 그로 인해 본인의 기존 업무를 유지하면서 새로운 업무에 대한 대응이 일시적으로 늦어지면, 그 모습만으로 구성원이 ‘업무 역량이 부족하다’는 인상을 주게 되는 경우도 있습니다. 이는 구성원 간 신뢰 형성에 부정적인 영향을 줄 수 있고, 장기적으로는 조직 내 위화감으로 이어질 수 있습니다.

현재의 체계가 구성원 간 상호 이해와 협력을 이끌어낼 수 있는 구조인지, 또 리더십이 구성원의 상황을 진심으로 고려하고 있는지를 함께 고민해볼 필요가 있다고 생각합니다.

조직은 구성원 개개인이 존중받고 자신의 역할을 이해받을 때 더 건강하게 성장할 수 있다고 믿습니다. 단순히 ‘적응하지 못하면 떠나는 것’이 답이 아닌, 함께 방향을 맞춰나갈 수 있는 조직이 되기를 진심으로 바랍니다.

# data[].attributes.body
과제 중심을 위한 형태로 조직개편을 하였다고 하였지만 결국 스쿼드별로 '서비스 무중단'이라는 KPI가 포함되어 있습니다.

결국 스쿼드 내에서 과제 수행 뿐만 아니라 서비스 운영도 하는 걸 인정하는 꼴인데 왜 SR이나 운영에 대한 KPI는 스쿼드 KPI에 없는건가요?

KPI만 놓고보면 스쿼드 인력 구성도 결국 SR/서비스 운영 인력이 포함 되어야 하는거 아닌가요?

KPI와 스쿼드 구성과 개편 방향이 전혀 다른 말을 하고 있으니 이런 혼란만 야기하고 있다는 생각은 해보셨을까요?

혹시 모르고 계셨다면 이렇게 구성원도 가지고 있는 부분들에 대한 해소 방안 마련 부탁 드립니다.

# data[].attributes.body
조직 개편 후 몇 개월이 지났지만, 향후 업무 방향이 불확실해 혼란이 지속되고 있습니다. 개편의 목적이 제대로 이행되고 있는지 의문입니다.

조직이 언제쯤 안정화될 것으로 예상하시며, 안정된 조직이 갖춰야 할 체계는 무엇인지 알고 싶습니다.

# data[].attributes.headline
우리는 한 팀이 맞는가?

# data[].attributes.subject
우리는 한 팀이 맞는가?

# data[].attributes.body
현재의 조직개편이 IT내부적으로 쌓인 기술부채를 개선하고 기술의 향상을 촉진 시킬 수 있다고 생각합니다. 방향성 자체는 동의합니다. 선진IT로 갈 수있는 기반을 닦는 중이라고 생각합니다. 단, 기술 관점에서만 동의합니다.

각 개발구성원들을 시스템에 귀속시키지 않고 내부인력을 토대로 신규 프러덕트를 애자일하게 만들어 낸다. 좋습니다.

여기서 애자일의 주요 원칙 중 하나를 살펴볼까요.

비즈니스, 프러덕트 개발자들은 동기부여된 개인중심으로 매일 소통하며 프로젝트를 구성하라.

현재 이 동기 부여는 제대로 되고있을까요?

티에프의 연속화로 인해 각 인력들은 의미없는 공수쪼개기를 통해 여러 개의 스쿼드에 속해지면서 오너쉽을 가질수도 없는 상태로 일하고 있는 것 같습니다.

프론트, 백엔드, 모델링 중 특정 과업에 가중치를 줄 수 없는 상황에서 평가받는다고 하면 구성원들이 과연 동기부여를 받을 수 있을까요?

위 내용은 개편 당시에도 나오던 내용이었습니다. 여전히 해결되지 않았죠.

다음은 조직 관점에서 봅니다.

현재 개발/운영 조직이 분리되어 개발은 프로덕트 개발에 집중하고 운영은 운영 중인 서비스에 대해서 대응하고 있죠.

과연 조직 관점에서 시너지가 나고 있을까요?

스쿼드 조직의 모호함에 따라, 여전히 운영 업무를 하고 있는 개발담당 조직원이 있고 반대로 운영인력 중 일부는 CS처리식으로 주인이 사라진 시스템의 새 주인이 되어버렸습니다. 그 과정에서, 속한 조직에 대한 열등감이 생기고 업무 오너쉽은 사라집니다.

더구나, 기존 개발인력들은 더해진 스쿼드 업무에 sr도 같이 처리하고 있으나 그 실적 기준으로 인정받지도 못하는 상황에서 운영과의 협업은 쉽지않죠.

개편이 이루어진지 벌써 4개월차입니다. 개편 당시 모두가 가진 의문이 지금은 해결됬을까요?

기존 솔루션 운영인원과 Techops 모호함

내재화 운영시스템의 관리방안

스쿼드, 과제 수립기준
(운영시스템의 고도화? 신규 프러덕트?)

업무 주인의식

결국 한 분기가 지났습니다. 이런 부분들이 해결이 하나도 안됬는데 누굴 내쳐야하니 정치니 이런 얘기들이나 하고 있으니 문제입니다. 원팀 마인드로 가야합니다.

결국 우리역할은 사업에서 잘 돈을 벌 수있게 도움을 주는 IT 프러덕트를 만들고 유지하는 것인데 지금 실제 사업에서는 이를 체감하고 있을까요. 역으로 가고있다고 생각하지는 않을까요?

이 개편이 고객이던 조직적으로던 가치를 줄 수있는 형태인지는 다시 한 번 생각해봐야할 문제입니다. Q&A만 봐도 근 4개월 동안 구성원들 마음이 얼마나 곪아있는지 보이네요.

# data[].attributes.headline
내재화/비내재화 시스템

# data[].attributes.subject
내재화/비내재화 시스템

# data[].attributes.body
내재화된 시스템과 비내재화된 시스템의 조직형태와 운영방식은 달라야 하는 것 아닌가요?

업무협조도 안되고 더 늘어난 절차로 업무 진행이 안됩니다.

# data[].attributes.body
조직 이기주의가 없는 하나의 IT 조직을 간절히 바랍니다. 일할 의지와 욕구가 거의 다 사라져갑니다.

# data[].attributes.body
스쿼드 업무를 하면서 평가는 '어떤 기준'으로

'누가' 평가를 '어떻게' 진행되는지 알고 싶습니다. 업무 기여도 등 상세한 내용은 해당 스쿼드 인원들이 알고 있을텐데, 명확한 기준이 있는지 알고 싶습니다.

# data[].attributes.body
1인 1스쿼드로 업무에 집중 할 수 있는 환경을 조성한다고 했는데, 다중 스쿼드를 맡거나 내부 과제를 맡아서 하고 있습니다.

일하는 방식에 대해 다시 가이드 부탁드립니다.

# data[].attributes.headline
스쿼드와 팀업무, 운영업무 병행

# data[].attributes.subject
스쿼드와 팀업무, 운영업무 병행

# data[].attributes.body
스쿼드 방식은 1인 1과제 형식으로 빠르게 과제를 수행하고, 완료 후 다른 과제로 (다른 스쿼드로) 재편되는 식으로 이해했는데, 현재 하나의 스쿼드 안에 메인 과제 뿐만 아니라 운영성 업무, 개발담당 내 팀 업무(KPI과제)까지 병행하는 스쿼드가 많은 것 같습니다. 기존 팀 방식보다 인원은 줄었지만 일은 훨씬 늘어난 느낌입니다. 스쿼드별 제대로 된 공수 산정(1일 8시간 기준이 아닌 실제 야근까지 포함한 업무하는 기준)으로 인력조정이나 업무조정이 필요할 것 같은데 어떻게 운영이 될 지 알고 싶습니다.

# data[].attributes.body
조직 개편으로 인해 운영 업무를 담당하던 부서가 사라지면서, 기존 시스템과 관련된 협업 업무가 반복적으로 지연되고 있습니다. 필요한 지원을 받기 어려워 실제 업무 진행에 차질이 생기고 있습니다. 모두가 자기 일이 아니라고 합니다.

# data[].attributes.body
1인 1스쿼드도 안바랍니다.

이 사람이 진짜 일을 많이 하고있는지 PO와 소통 후 업무 지시 부탁드립니다.

# data[].attributes.headline
다중업무처리의 일하는방식 변화

# data[].attributes.subject
다중업무처리의 일하는방식 변화

# data[].attributes.body
일하는 방식의 변화에 대해 적극적으로 동참하고 공감하고 있습니다. 현재 각 팀원은 한 개의 스쿼드에 속해 스프린트에 맞춰 집중적으로 업무를 해야 하는 상황입니다. 그러나 현실적으로 업무를 수행하는 사람은 스프린트 태스크, 운영성 업무, 장애 대응 및 기타 문의 처리 등 여러 업무를 동시에 맡고 있어 어느 한 곳에 집중하기 어려운 상황입니다.
심지어 특정인원은 복수개의 스쿼드에 구성이 되어 있구요~

사업부에서는 운영 업무도 중요하고 스프린트 과제 역시 우선순위가 높다고 보고 있습니다. 이로 인해 운영성 업무와 스프린트 태스크 모두 지연될 수밖에 없고, PO가 일정 조정을 하더라도 사업부는 여전히 모든 업무에 높은 우선순위를 두고 있기 때문에 해결이 쉽지 않습니다.

결과적으로 업무량은 그대로인데, 이를 처리할 수 있는 인원은 점점 더 줄어들고 있으며, 이전 팀제로 운영되던 방식에 비해 현재 시스템이 더 어려운 상황입니다. 이와 같은 방식이 우리가 원하는 방식이 아니었을 것이라고 생각합니다.

어떻게 이런 부분을 해소해 주실수 있을까요?

# data[].attributes.headline
업무에 집중 할 수 있는 환경

# data[].attributes.subject
업무에 집중 할 수 있는 환경

# data[].attributes.body
스쿼드로 조직 개편된 이후 소수의 인원이 운영성 업무와 개발 업무를 동시에 수행해야되서 업무에 집중 할 수 없는 환경이 조성되고 있습니다. 결과적으로 업무 효율이 크게 떨어지고 있습니다. 조직 개편 이전에 비해 체감상 이전 많이 힘들어졌고 개선된 점을 느끼기 어려워 현재로서는 스쿼드 조직이 좋은지 우리에게 적합한지 의문입니다..

# data[].attributes.body
현재 스쿼드 업무와 기존 운영 업무, 그리고 내부 프로젝트를 동시에 진행하고 있는 상황입니다. 각 업무가 중요한 만큼, 업무 간 우선순위를 명확히 정리해주시면 더 효율적으로 진행할 수 있을 것 같습니다.

# data[].attributes.body
우리회사는 아직까지

본인들이 살아남기위한

내부적인 정치가 많은 것 같습니다.

그렇기에 은폐되는것이 많지요,

모두가 같은시선을 바라보고 달려야 할 필요성이 있습니다.

언제쯤 달라질까요?

달라질 수 있을까요?

# data[].attributes.body
기술력은 부족하고 시키기만 하시는 분들께 부탁드립니다. 제발 본인이 스스로 발전하시거나, 뭔가를 찾아보고 공부하려는 노력을 해주셨으면 합니다.

매번 메일로 ‘담당님 지시사항으로 급한 건입니다’라는 말도 안 되는 개발 요청이 반복되지 않기를 진심으로 바랍니다.

# data[].attributes.body
기존에 각 팀별로 사일로로 일하던게 많이 해소 되고 있는게 느껴집니다. 앞으로도 지속적으로 사일로 해소 부탁드립니다.

# data[].attributes.body
기존에 오픈소스 및 신기술 지향보다 , 안정된 회사의 제품을사서 설치 해서 사용 했는데, 도전적으로 일하는 방식이 회사도, 개발자도 좋은 방향으로 가고 있는 것 같습니다.

# data[].attributes.body
운영과 개발이 분리되기 전에는 위클리 미팅을 통해 회사의 주요 이슈와 돌아가는 상황을 공유해주셨었는데요,

최근에는 일부 인원 중심으로 회의가 진행되고, 이슈가 공유되고 있습니다.

이 조직이 하나의 목표를 향해 달려가고 있는지 의문이 듭니다.

# data[].attributes.body
조직 개편 이후 방향이 반대로 가고 있습니다.

신규 리더 분들은 아직 시스템 파악이 안되서 구성원에게 의지하며, 장애가 발생하고 나서 왜 이렇게 했는지 추궁하기 보다는 바꾸고자 하는 부분을 같이 고민하고 참여를 부탁드립니다.

저희도 장애 없는 시스템을 만들고 싶고 충분히 테스트하고 싶고 충분한 검증을 하고 싶은데 일은 많은데 규칙은 계속 생기고, 만들어야 할 자료와 보고는 산더미입니다.

리더들이 솔선수범하여 불합리한 프로세스는 줄이고, 부족한 부분을 가이드 해줘야 하는데 업무만 쌓이고, 갈 수록 힘들어 집니다.

리더도 실무를 통해 불합리한 부분을 찾아 개선하여 각자 업무를 즐겁게 할 수 있는 분위기가 조성되면 좋겠습니다. (일개 부서원이 이야기 해봐도 바뀌는 부분이 없어서 이런 부분은 리더들이 개선점 보고해야 할 겁니다.)

# data[].attributes.body
조직개편의 목적과 방향성이 있지 않았을까요?

각 담당님들은 소속 팀과 스쿼드의 목적과 R&R을 직접 작성하여 공유 부탁드립니다.

# data[].attributes.body
스쿼드나 팀에 들어와서 같이 하나로 움직여야 할거 같아요. 제가 본 애자일 책에서는 다 그렇던데요 ㅎㅎㅎ

# data[].attributes.body
IT 조직의 KPI에 특허 출원이 필수인 이유가 있는지 문의 드립니다.

# data[].attributes.body
품질 때문에 일을 못합니다 문서작성만 하루종일 하면 개발은 언제하나요? 품질 제출을 위한 문서작성도 일정에 포함시켜주시나요?

# data[].attributes.headline
IT 개발은 애자일하게 가려고 하는데....

# data[].attributes.subject
IT 개발은 애자일하게 가려고 하는데....

# data[].attributes.body
다른건 모두다 Gate 단위로 움직이니까 혼란스럽습니다.

품질, 보안, 전부 폭포수로 움직이는데 우리만 애자일하게 간다고 해도 한계가 있을거 같아요~~

# data[].attributes.headline
많이 힘든 시기인거 같습니다.

# data[].attributes.subject
많이 힘든 시기인거 같습니다.

# data[].attributes.body
국내 외 정치 상황도, 경제도, 혼란스러운 가운데 재난까지 겹친 요즘..

일하는 사람들에게 공포 보다는 안정감을 줄 수 있는 환경을 마련해줄 수는 없을까요?

# data[].attributes.headline
운영/고객 요구사항에 대한 효율적 대응 

# data[].attributes.subject
운영/고객 요구사항에 대한 효율적 대응 

# data[].attributes.body
기존 운영하던 시스템 , 지속적인 고객/사업부의 개선 요구사항은 접수가 되나 기존 운영인력의 조직 변경으로 빠르게 대응이 안되는것 같습니다.

고객 요청이 오면 어떻게 회신을 해야할지

전체적으로 Delay가 발생이 되고 있습니다.

효율적 운영을 위해 프로세스 / 대응 방법에 대해 명확한 기준이 필요해 보입니다.

아직은 주요 몇명이 처리해서 문제가 발생하지는 않지만 앞으로가 걱정이 됩니다.

# data[].attributes.body
개발은 하지 않으면서 지시만 하시는 분들께서는, 해당 내용을 먼저 찾아보고 공부하신 후 지시해주시기 바랍니다.

뭔가 스스로 찾아보고 시도해보려는 최소한의 의지라도 갖춰주시기 바랍니다.

매번 말도 안 되는 담당자 지시사항 때문에 ‘급한 개발 건’이라는 명목으로 처리해야 하는 업무가 수두룩합니다.

# data[].attributes.body
당장의 장애를 줄이기 위해서는 개발 조직도 중요하지만 운영전문 스쿼드나 팀이 있어야 할거 같습니다.

지금 개발을 아무리 잘해도 지금 운영중인 솔루션의 장애를 막을수는 없을거 같아요~

# data[].attributes.body
지금 노트북 스펙으로는 개발표준이라고 가이드나온 WSL을 소화하지 못하고 있습니다.

WSL 안쓰고 그냥 로컬개발을 하는것도 벅찰 정도입니다.

개발장비 교체를 건의드립니다.

# data[].attributes.body
코틀린 쓰라고 강요하지 말고 기술 스택내에서 선택 할 수 있게 해주세요.

강요할거면 기술스택 정의를 왜 한건가요?

# data[].attributes.body
업무 체계가 조직개편 이후 산으로 갑니다.

리더분들은 파악중이라는 말은 그만하고 직접 업무 파악 부탁드립니다.

자꾸 떠넘기니까 업무 파악이 느린거 같습니다.

# data[].attributes.headline
TES 경영진들께 묻고 싶습니다.

# data[].attributes.subject
TES 경영진들께 묻고 싶습니다.

# data[].attributes.body
조직 개편 후 장점이 뭐가 있을까요?

고견 듣고 싶어요

# data[].attributes.headline
개발담당 vs 솔루션담당

# data[].attributes.subject
개발담당 vs 솔루션담당

# data[].attributes.body
현재 구조에서 S조직의 경우 개발 담당과 솔루션담당이 전혀 상관이 없는 일들을 하고 있는데 이게 원래의 취지가 맞나요?

사업부 및 운영은 솔루션담당, 실제 개발은 개발담당이라고 알고 있는데, S조직은 개발담당에서 개발, 운영, 사업부 대응까지 다하고 있는데, 전혀 다른 R&R인것 같아서요

# data[].attributes.body
모두가 각자의 분야에서 전문가로서 이 곳에 있는데 각 분야를 존중하지 않고 어디선가 봤는데~ 옛날에 내가 해봤는데~ 요즘은 AI가 다 해주는데~ 등의 무시하는 일은 없어야 한다고 생각합니다. 그런 형태의 대화는 업무에도 좋은 영향을 주지 않는 것 같습니다

# data[].attributes.headline
내부과제란 무엇인가..

# data[].attributes.subject
내부과제란 무엇인가..

# data[].attributes.body
처음 이 조직체계가 출범할 때 업무는 스쿼드로 담당자 배정해서 진행하고, 팀내에서는 역량강화, 인력관리등의 역할을 수행하기로 디자인 돼 있었습니다.

실제 조직체계를 4달간 운영하면서 스쿼드로 하는 업무들도 있지만 팀 내에서 관리하는 내부과제, 담당내과제 등이 진행되고 있습니다. 그래서 1명의 인원이 스쿼드 과제, 내부과제를 같이 진행하는 경우들이 있습니다. 내부과제란 무엇이고 어떤 프로세스로 발의되고 진행되는건지.. 스쿼드과제와 차이점은 무엇인지 명학히 할 필요가 있어보입니다

# data[].attributes.body
지금까지 나온 질문마다 답변을 부탁드립니다.

내용 공감이 잘 안되네요.

# data[].attributes.body
타 담당 스쿼드와 협업 과제를 진행하면서 다음과 같은 어려움이 발생하고 있습니다.

PO와 PM이 테일러링, 인프라, 정보보안 관련 프로세스를 충분히 이해하지 못한 채 배포 일정을 급하게 잡는 경우가 있습니다.

과제에 대해 사업부서에서 비용 지원이 어렵다는 이유로 Lois Cloud를 사용하지 않고 운영 배포를 요청하는 사례도 발생하고 있습니다. (CI/CD구축 없이ㅜㅜ)

개발해야 할 과제 자체도 많은데, 개발 외적인 부분에서 협의하고 설득하는 데 많은 리소스가 소모되고 있습니다.

특히 타 담당에서 TES 개발 프로세스를 따르지 않거나 사전 일정 협의 없이 지시하는 경우가 반복되고 있습니다.

이러한 상황에서 실무자들이 매번 조율하는 것도 상당한 부담이 되며, TES 개발 프로세스의 준수를 강제할 수 있는 담당 간의 룰과 기준이 필요하다고 생각됩니다.