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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

본인들이 살아남기위한

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

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

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

언제쯤 달라질까요?

달라질 수 있을까요?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 업무 주인의식

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

고견 듣고 싶어요

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

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

내용 공감이 잘 안되네요.

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

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

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

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

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