Total 9 Posts스프린트IT 제품 개발의 방법론 차이: 빠른 개발 vs. 지속적인 개선
IT 제품을 개발할 때, 빠른 개발이 항상 가장 중요한 가치일까요? 요즘 많은 프로젝트 관리 툴들이 스프린트 기반 생산성 관리 서비스를 제공하며, 빠른 제품 개발과 주기적인 스프린트 수행 최적화를 통해 팀의 생산성을 높이는 것을 목표로 합니다. 이 방식은 단연 빠르게 제품을 만들어내기에 효과적입니다. ✔ 작은 목표를 설정하고 빠르게 실행하여 결과를 내기 좋고, ✔ 빠르게 제품을 출시하며, ✔ 시장과 사용자 반응을 빠르게 반영할 수 있다는 장점이 있습니다. 그런데, 빠르게 만들기만 하는게 항상 최고의 답일까요? 제품이 시장에서 자리 잡거나, 우리가 원하는 제품을 만들어낸 후에는 이제 단순한 '빠른 개발'이 아니라, 안정적인 운영과 보다 긴 기간에 대해 연속성을 갖는 개선을 고민해야 합니다. 하지만 스프린트 기반 방식으로 긴호흡의 개선을 이루는 것은 생각보다 쉽지 않습니다. ❌ 스프린트 방식의 한계 1️⃣ 짧은 목표 주기 방식은 장기적인 개선에 적합하지 않음 스프린트는 짧은 단위의 목표를 빠르게 수행하는 방식이라,긴 호흡으로 진행해야 하는 연속성을 갖는 개선과는 잘 맞지 않습니다. 2️⃣ 기능 단위의 변경에 집중되어, 큰 그림을 고려한 개선이 어려움 장기적인 개선보다는 기능 추가/변경 같은 단기 목표에 집중하는 경향이 있음. 전체적인 제품의 완성도를 높이는 것보다, 스프린트 단위의 작은 목표를 달성하는 것이 우선되는 경우가 많음. 3️⃣ 스프린트 사이의 공백으로 인해 일관된 개선 흐름 유지가 어려움 스프린트마다 목표를 설정하고 진행하다 보니, 일관된 개선 방향을 유지하기 어렵고, 운영이 단절되는 문제가 발생할 수 있음. 장기적으로 보면, 스프린트의 인위적인 마감 기한이 개선과 운영의 부담이 될 수도 있음. 지속적인 개선과 운영을 위한 개발팀 최적화 이제 제품이 안정적으로 운영되고 지속적인 개선이 필요한 상황이라면, 단순히 특정 목표를 작은 단위로 빠르게 수행하는 것이 최선이 아닐 수 있습니다. ✅ 개발자 한 명 한 명이 최적의 업무를 수행할 수 있도록 돕는 것이 중요합니다. ✅ 개발자의 성향과 업무 스타일을 이해하고 최적화하는 툴을 활용하면, 팀 운영이 더욱 효율적이 됩니다. 💡 개발자 개개인의 업무 이력 및 장단점을 이해하고, 최적화된 업무 환경을 제공하는 데 도움을 줄 수 있는 도구가 필요합니다. 💡 빠른 마감기한을 지키는 개발보다, 어제와 오늘의 업무를 쌓아나가 업무의 생산성을 높히기 위해 개개인의 업무를 들여다 볼 수 있는 도구가 필요합니다. 🚀 제품 개발 방식, 이제 단순한 속도가 아니라 장기적인 운영과 개선까지 고려할 때입니다.2025.04.09
개발자패턴개발팀관리에 선입견 활용하기
보통 사람에 대한 선입견은 그다지 긍정적인 정보로 활용하기 어렵습니다. 하지만 개발자의 업무 패턴에 대한 선입견은 개발팀 운영에 훌륭한 밑 데이터가 될 수 있습니다. 실제 경험에 따르면, 개발자의 개발습관/패턴에 대한 선입견을 통해 일정조정이 큰 도움이 되었습니다 두 가지 사례로 살펴본 선입견을 통한 일정 조정 개발자 A의 경우, 이 친구는 항상 시간보다 더 걸릴게 뻔해 A는 평소에 공유된 일정을 빠듯하게 처리하거나 약간 늦어지는 경향이 있습니다. 만약 A가 5일의 작업 일정을 제시했다면, 관리자는 이를 참고하여 6일 정도의 여유를 두고 계획을 수립할 수 있습니다. 이와 같이 선입견을 반영하면, A는 부담 없이 최선을 다해 일정 내 작업을 수행하게 되고, 결과적으로 신뢰 관계가 형성됩니다. 개발자 B의 경우, 항상 일정을 여유롭게 잡지 반대로 B는 일정에 대해 여유롭게 접근하는 스타일입니다. B가 말하는 5일은 지켜질 확률이 크고, 일정이 시급한경우 사정을 설명하고 약간 일정을 줄여내는 버퍼를 가져올 수 있게 됩니다. 선입견을 활용하는 이유 효율적인 일정 조정: 늦어질것을 고려하고, 안정적으로 제시한 일정을 맞출것을 통해 개발완료까지 시간간 지연을 사전에 줄여냅니다다 신뢰관계 구축: 개발자와 관리자가 서로 민망해질 대화가 줄어들게 되고, 높은 이해도를 통해 서로의 말을 (선입견을 통한 보정) 신뢰 하고 그 신뢰에 기반에 개발 진행이 가능해집니다 선입견을 만들어내기 어려운이유 주의력: 평소 개발 습관부터 어쩔땐 생활 습관까지 각 개발자에 대한 집중 및 주의를 크게 요하게 됩니다 경험: 개발 및 개발 관리 경험이 필수적이며, 개발자들의 과거 이력부터 현재까지 모든 경험을 기록하고 기억해두어야 합니다 개발자 수의 증가에 따라 위의 두가지 사항의 관리는 기하급수적으로 어려워 지게 됩니다 전문 툴의 활용 선입견 즉 개발자의 습관 및 패턴을 파악해 내기위해서는 전문적인 툴을 사용하는것이 필요해집니다: 실시간 작업 현황 파악 개별 개발자의 업무 패턴 분석 일정 예측 및 조정의 정확도 향상 등의 효과를 제공하여, 관리자가 보다 전문적으로 팀을 이끌 수 있도록 ‘경험’을 부여하여 돕습니다. 우리 팀의 각 개발자들의 특성을 알고 계신가요?2025.04.09
KPIIT 개발자의 KPI/OKR 관리
개발자들에게 KPI/OKR은 왜 이렇게 어려울까? 연초가 되면 많은 개발자들이 한 가지 공통적인 고민에 빠집니다. 바로 KPI(핵심 성과 지표)와/또는 OKR(목표 및 핵심 결과) 설정입니다. 익숙하지도 않고, 무엇을 어떻게 설정해야 할지 난감하기만 합니다. 심지어 그것때문에 관리자와의 소통이 더욱 단절되는 원인이 되기도 하죠. 도대체 왜 이렇게 어려운 걸까요? KPI/OKR 설정이 어려운 이유 그 이유는 바로 개발 업무의 특성 때문입니다. 일반적으로 비즈니스에서는 연간 목표와 계획을 수립하고, 이에 맞춰 개발팀에 새로운 기능 개발이나 수정 요청을 전달합니다. 하지만 개발 업무는 처음부터 모든 것을 계획하고 나아갈 수 없는 특성을 지니고 있습니다. 예를 들어, "신규 기능 10개, 디버깅 100개"와 같은 단순한 목표를 설정하는 것이 과연 적절할까요? 현실적으로, 비즈니스가 1년 동안의 모든 개발 내역을 정확히 정의할 수 없다면, 개발자가 이에 맞춰 명확한 KPI를 설정하는 것도 불가능에 가깝습니다. 그렇다면 개발자는 KPI/OKR을 관리하지 않아도 될까? 그렇지는 않습니다. 오히려 개발자의 KPI/OKR 관리는 비즈니스를 얼마나 효과적으로 지원했으며, 어떤 프로덕트를 개발해 왔는지를 측정하는 중요한 기록이 됩니다. 이 과정에서 중요한 것은 과거의 개발 업무를 기록하고 관리하는 것입니다. 개발한 기능과 개선 사항, 각 테스크(Task)의 목표, 핵심 결과(Key Result), 그리고 해당 테스크에서 자신의 역할을 명확하게 정리하면, 이를 기반으로 개발자 개인의 KPI/OKR을 보다 구체적으로 측정할 수 있습니다. KPI/OKR 관리, 쉽지 않지만 가능하다 물론, 이러한 기록과 관리를 수동으로 진행하는 것은 쉽지 않습니다. 하지만 개발자의 테스크와 개발 내역을 개발자별, 테스크별, 기간별로 조회할 수 있는 효율적인 툴을 사용한다면 이야기가 달라집니다. 이런 도구를 활용하면, 개발자의 1년간 활동을 효과적으로 정리하고 KPI/OKR을 보다 명확하게 평가할 수 있습니다. 마무리 개발자의 KPI/OKR은 단순히 숫자로 측정하는 것이 아닙니다. 비즈니스에 대한 기여도, 개발한 프로덕트의 가치, 그리고 자신의 성장 과정을 기록하는 것이 더 중요합니다. 이를 위해 효과적인 기록과 관리가 가능하도록 도구를 활용하는 것이 필수적입니다. 개발자들도 KPI/OKR이 부담스럽기만 한 것이 아니라, 자신의 성과를 객관적으로 확인하고 성장하는 기회로 삼을 수 있도록 접근해보면 어떨까요?2025.04.09
개발자개발자 마인드에 대한 이해와 효과적인 일정 관리
한창 개발을 할때 기획자나 관리자들이 어쩌다 보면 "ㅉㅉ 개발자 마인드 하고는..." 하는 경우가 종종 있었다. 이 개발자 마인드라는게 뭘까? 주로 어떠한 개발/이슈에 대해 부정적으로 반응하거나 방어적인 스케쥴 제시 때 들었던걸로 기억을 하는데, 개발자들이 처음부터 그렇게 반응하지는 않는다. 개발 건 을 들고 와서 "얼마나 걸려?" 라고 물어보고는 개발자가 제시하는 일자에 해당 기능 개발이 완료되지 않을경우 "네가 스케쥴 잡았잖아" 라는 무한 책임을 몇번 겪고 나면, 일정 자체를 1.5~2배 정도로 잡기도 하고, 최대한 부정적으로 대답을 하게 된다. 개발 시작전 예상하지 못했던 상황도 오롯이 개발자에게 책임을 묻기 때문인데 해가 가고 경력이 쌓이면서 그러한 상황을 "예측" 해서 일정을 잡게 된다. 그렇게 경력자가 된 개발자는 일정을 잘 지키게 될지는 모르겠으나, 그것은 기업 특히 스타트업같은 작은 기업에게 긍정적인 효과로 작용하지는 않는다. 개발자의 일정이 지켜지지 않는것에서 만일 개발자가 노력했음에도 문제가 생겼을때는 개발자의 변명을 되도록 수용해주고 인정해주어야 그 다음에도 일정을 최대한 회사측 입장에서 잡을 수 있게 된다. 그리고 또한 우리 사업에 더욱 긍정적인 반응을 보이게 되어 "그거 안되요, 오래 걸려요"같은 반응보다는 "힘들거 같은데 한번 해볼게요" 같은 반응을 가져올 수 있게 된다. 개발자 마인드에 대한 이해와 효과적인 일정 관리 개발을 진행하다 보면 기획자나 관리자들이 종종 "개발자 마인드하고는..."이라는 말을 하곤 한다. 특히, 일정 산정 과정에서 부정적인 반응을 보이거나 보수적으로 일정을 제시할 때 이러한 표현을 듣는 경우가 많다. 하지만 개발자들이 처음부터 이런 태도를 취하는 것은 아니다. 개발자의 일정 산정 방식과 방어적 태도의 형성 일반적으로 새로운 기능 개발을 요청받으면 기획자나 관리자는 "이 기능을 개발하는 데 얼마나 걸릴까?"라는 질문을 던진다. 이에 대해 개발자가 신중하게 일정 예측을 하고 답변을 하지만, 실제 개발이 진행되면서 예상치 못한 문제들이 발생하기 마련이다. 그러나 개발 일정이 지연될 경우, 개발자에게 "네가 스케줄을 잡았으니 책임도 네가 져야 한다"는 부담이 돌아오는 경우가 많다. 이러한 경험이 반복되다 보면, 개발자들은 일정 산정을 할 때 점점 더 보수적으로 접근하게 된다. 예를 들어, 예상 소요 시간을 1.5배에서 2배 정도로 늘려 잡거나, 최대한 부정적인 시나리오를 가정하고 대답하는 방식을 택한다. 이는 단순한 방어 기제가 아니라, 경험을 통해 형성된 합리적인 대응 방식이다. 실제 개발 과정에서는 예상치 못한 변수들이 많기 때문에, 이를 감안한 일정 조정이 필요하다는 것을 학습한 결과이다. 경력자의 일정 예측과 스타트업 환경 경력이 쌓인 개발자들은 이러한 변수를 고려하여 일정을 보다 현실적으로 산정한다. 하지만 일정 준수율이 높아지는 것이 반드시 스타트업 같은 작은 기업에게 긍정적인 효과로 작용하는 것은 아니다. 개발자가 지나치게 보수적으로 일정을 잡게 되면, 기업의 기민한 대응 능력이 저하될 수 있기 때문이다. 스타트업에서는 빠른 실행과 적절한 리스크 감수가 중요하다. 따라서 개발 일정이 지연될 경우, 개발자가 충분히 노력했음에도 불가피한 문제가 발생했다면, 이를 인정하고 유연하게 대응하는 것이 중요하다. 개발자의 입장에서 "왜 일정이 늦어졌는가?"라는 질책보다는 "어떤 문제가 있었고, 어떻게 해결할 수 있을까?"라는 접근이 필요하다. 개발자와의 협업을 위한 긍정적인 문화 조성 개발자들이 지나치게 방어적인 태도를 취하지 않도록 하려면, 일정이 지연되었을 때 개발자의 변명을 무조건 배척하기보다는 이를 수용하고 인정해 주는 문화가 필요하다. 그렇게 해야 개발자들도 일정 산정 시 회사의 입장을 더욱 고려하게 되고, 보다 적극적인 태도로 업무에 임할 수 있다. 예를 들어, 개발자가 "그거 안 돼요, 오래 걸려요"라고 말하는 대신 "힘들 것 같지만 한번 해볼게요"라고 반응할 수 있도록 유도하는 것이 중요하다. 이를 위해서는 신뢰를 바탕으로 한 협업 환경을 조성하고, 실패를 지나치게 비난하는 문화를 지양해야 한다. 개발자가 새로운 도전에 긍정적인 태도를 가질 수 있도록 지원하는 것이 결국 기업의 성장에도 도움이 될 것이다. 결론 '개발자 마인드'라는 말이 종종 부정적인 의미로 사용되곤 하지만, 사실 이는 경험을 통해 형성된 현실적인 대응 방식이다. 효과적인 협업을 위해서는 개발자의 일정 산정 방식을 이해하고, 일정 지연에 대한 책임을 지나치게 가중시키지 않는 것이 중요하다. 이를 통해 개발자와 회사 모두가 긍정적인 방향으로 나아갈 수 있을 것이다.2025.04.09
디버깅
IT개발에서 개발자의 버그를 나쁘게만 평가해서는 안되는 이유
IT개발에 있어 버그가 나오는것을 대단히 죄악시 하는 경향이 있는데 버그 자체는 서비스의 품질을 저하시키는게 맞지만 그 버그를 만들어낸 개발자는 비난받아야 하는지에 대해서는 조금 생각할 문제 인거 같습니다. 저는 개발자와 개발관리자를 모두 경험해봤고 그를 통해 겪은 내용들을 공유하고 있습니다. IT 서비스 개발 및 운영에서 버그가 나오는건 분명 사용자의 서비스 경험을 좋지 안헥 하는 것은 분명합니다. 그렇다면 버그를 만들어낸 개발자는 비난을 받아야 할까요? 일견 그렇기도 하지만 아니기도 합니다. 전에 특정분야의 제 지인께서는 버그의 개수 개발자의 성과관리 지표로 사용하는 방안을 얘기 했었습니다. 버그=나쁜것, 버그를 만든 개발자=실력없는 개발자, 혹은 도움이 안되는 개발자. 라고 생각하는건 개발팀에 대단히 안좋은 영향을 줄 수 있습니다. 버그가 내 성과 점수를 낮춘다면, 그 누구도 무리한 개발을 하지 않으려하고 일정도 대단히 방어적으로 잡게 될겁니다. 버그를 안만들어야만 하니까요. 무리한 개발에는 반대할 것이고, 익숙하지 않은 개발은 다른이에게 넘기려 할거에요. 개발팀은 대단히 부정적인 기류를 타게 되죠. 특히 스타트업의 경우 숙련된 개발자도 부족하고, 사용할 수 있는 시간도 적은데 버그로 개발자를 평가하려 한다면 개발 기피 현상이 눈에 띄게 나타나게 될겁니다. 버그는 개발 실력 보다는 해당 도메인에 대한 경험 부족, 개발 경험 부족에서 기인하는 경우가 더 많습니다. 버그의 발생 빈도는 시간이 지날수록 낮아지는것이 정상이며, 만일 버그 발생빈도가 갑자기 높아진다면, 개발업무 배분 혹은 개발시간의 부족에 대해서 개발팀과 논의 해보시는것을 권장 드립니다. 지금 우리 개발자들은 어떤 업무에 집중하고 있을까요? 버그 수정빈도는 증감하고 있을까요? 2025.04.09프론트엔드개발자프론트(화면) 개발자는 억울하다!
개발자로서, 그리고 관리자로서 경험한 내용을 이야기 해볼께요! 사실 일정에 관련해서는 프론트엔드 개발자 만큼 억울하기도 어렵습니다. 디자인이 끝나야 업무가 시작되고, 백엔드API개발이 끝나야 업무를 마무리 할 수 있거든요. 프론트엔드 개발자가 게으르거나 부지런해서 업무가 빨리, 혹은 지체가 되는 경우는 그다지 많지 않아요. 그런데도 개발이 마무리가 안되고 있으면 대표님도 관리자도 프론트엔드 개발자에게 다그치게 됩니다 "화면 언제 나와?" 그나마 디자인이 나오지 않아서 화면 작업이 진행 안되는건 설명이 쉽지만, 백엔드 기능 개발이 완료되지 않아 화면 개발이 완료되지 않는다는건 조금 설명하기 어렵기도 해요 그럴땐, 백엔드 개발자의 개발을 참조하시라고 Git을 공유드려서 알려드려보실수 있어요. 다만, 프론트엔드 개발자의 경우 백엔드 API의 레파지토리에 초대 되지 않았을 수 있으니, 백엔드 레파지토리에 관리자 초대를 요청해두세요. 혹은 BCTO같은 서비스를 사용하면 레파지토리에 초대 받지 않아도 Commit 내역을 보여드릴 수 있습니다, 테스크와 연동해서요 그래서 저는 저희 프론트엔드 개발자분께, 일없으시면 유튜브나 넷플릭스 보시길 권해드려요. 곧 프론트만 바빠지실테니까요.2025.04.09백엔드개발자백엔드(서버) 개발자는 억울하다!
지난 개발자로서의 경험, 그리고 관리자로서의 경험을 통해 백엔드 개발자들의 억울함을 올려봅니다. 스타트업에서 일하다 보면 대표분들이 종종 물어 보시더라구요 "우리팀 A는 일하고 있는거 맞아요?" 특히 그런 오해를 백엔드 개발자분들이 많이 받으세요. 언제든 바뀐게 거의 일단위로 보여줄 수 있는 프론트개발과 달리 백엔드 개발에는 수일의 시간이 걸리는 일들이 많기 때문이죠 게다가, 보고서를 쓸때도 엊그제와, 어제와, 오늘이 내용이 같을 수밖에 없고, 물어봐도 어제도, 오늘도 "가입 기능 개발중이에요" 라고 같은 보고를 하게 되면 "너무 성의 없는거 아냐?" 라는 오해를 받곤 합니다. 게다가 개발이 완료되어도 보여줄 수 있는건 DB조회값, 혹은 JSON같은 응답값인데, 그게 굉장한 일을 한거론 보이지 않는경우가 더 많습니다. 프론트에서 개발이 완료되어야만 백엔드의 개발이 비로서 눈에 보이게되고, 그런데 그건 프론트엔드에서 다 개발한거처럼 보이거든요. 조금 더 오해를 없애고 원활히 업무를 하고 있다고 어필하려면, 아무래도 Git작업내역을 통해 보여주는게 효과적이지 않을까 합니다. <GitLab Commit log> 혹은, 더 쉽게 내가 처리한 태스크와 엮어서 보여주면 효과적일 수 있어요 혹은 현재 개발 추이를 보여주는 방법도 있어요 백엔드 개발자분들이 하는일이 궁금하시다면, Git을 통해 알려달라고 해보세요! (곧 프론트엔드 개발자분의 억울함을 얘기해볼께요!)2025.04.09개발팀보고서개발자의 효율을 떨어뜨리는 일단위 보고 업무 및 문서
약 18년간 개발자로서, 관리자로서 IT 개발자들과 일해본 경험에 있어, 개발자들이 싫어 하는 업무중 하나가 "내가 뭘 하고 있는지 매일 보고하는 일" 이었습니다. 그것은 문서작성 일 수도, 미팅 일 수도 있습니다 https://www.explore-group.com/blog/top-10-developer-hates/bp60/ Top 10 Developer Hates | Blog Being a developer or programmer is a great job, but no job is perfect all the time. Find out what annoys developers the most in our Top 10 Developer Hates www.explore-group.com 개발만 신경쓰기도 바쁜데 퇴근때 보고하고, 출근해서 또 스크럼이란 이름으로 구두로 보고 할 내용을 매일 매일 새롭게 구성해 내는게 꽤나 스트레스로 다가오게 됩니다. 하지만, 관리자가 개발팀을 정확히 들여다 볼 수 없다면 개발자가 귀찮더라도 매일 보고를 요청할 수 밖에는 없죠. 안그러면 뭘 하는지 알 수가 없으니. 그중 특히나 백엔드 개발자쪽 고충이 꽤나 심한편인데요, 눈에 보이지도 않고, 확인도 불가 하며, 같은 개발내역을 몇일동안 똑같이 하고 있다면. 관리자 눈에 일을 안하거나 보고에 건성이라고 보이게 되거든요, 그런데! 개발자의 개발업무는 다른어떤업무에 비해 투명합니다. Git서비스들 (GitHub으로 대표되는)에 개발내역이 모두 올라가고, 위변조도 힘들기 때문이며, 업데이트 내역은 사실 개발 보고를 위해 쓰는게 아닌 자신의 개발내역을 되돌아 볼 필요가 있을때를 위해 남기기 때문에 개발내역을 알기 쉽고 이해 하기 쉽게 코멘트를 남기며 Commit 을 하게 됩니다. 다만, 해당 서비스들의 Commit 내역 및 개발 Activity 들은 개발자의 개발을 위해 존재하는 내역이어서, 개발자가 아닐경우 읽어내는것이 상당히 불친절 하기에 잘 들여다보지 않게 됩니다. 해당 내역들을 쉽게 읽을 수 있다면, 개발자들이 보고 보다는 개발에 더 집중할 수 있는 환경이 될 것이고, 관리자는 언제든지 지금 우리팀의 개발진행 상황을 쉽게 이해 하게 될 수 있습니다. 개발자분들께 Git서비스에 초대를 요청하시고 메시지들을 확인해보세요. 그리고 개발자분들과 개발상황을 공유한다면 개발자 입장에서도 더 자신의 개발상황을 얘기하기 편해질거에요. 그리고 또한, 만일 티켓 서비스 (Jira로 대표되는)를 사용하고 있다면, 티켓 서비스와 Commit 메시지를 연결하여 "아! 내가 준 이 업무를 수행하기 위해 이러한 개발변화가 있었구나" 라고 보다 쉽게 우리 개발팀이 어떤업무를 현재 처리 하고 있고 어떤 변화가 있었는지 쉽게 알아보실 수 있을꺼에요. 이제 새로운 한해가 시작되었습니다. 개발자/개발팀 그리고 관리자와의 문제를 더 살펴보고, 혹시라도 도움이 될 수 있는 내용이 있다면 계속 올려보도록 할께요!2025.04.09
프로젝트관리프로젝트 관리 툴 사용이 점점 귀찮아지는 이유
IT 개발관리를 위해 많으 프로젝트 관리툴이 나와있어요, 대표적으로 Jira, 그리고 IT말고도 티켓등을 활용해 업무를 관리 할 수 있는 Asana, Trello 그리고 Swit등 그런데, 해당 서비스들을 적극적으로 도입했던것 만큼 사용하고 계신가요? 만일 처음처럼 잘 안쓰게된다면, 게을러저서 그런걸까요? <어우쓰기귀찮아> 도입후 일정기간 사용하다보면 해당 툴들의 사용이 또다른 업무처럼 느껴지시고, 억지로 사용하는 느낌이 드실꺼에요 많은 이유가 있겠지만, 개발자들 측면에서 보게되면, 개발이나 프로젝트진행 이외의 업무에 신경써야 하는경우가 되면 더욱 그렇게 되는거 같아요. 제가 겪은 경험에서는 프로젝트 관리툴이 점점 비활성화 되는데는, 대표님 및 관리자등 다른 부서 관련자들이 해당 툴을 사용하지 않을때 였어요. 처음엔 사용법을 듣고 적극적으로 모두 사용할거 같지만, 시간이 지나면서 대표님등 개발을 모르시는 분들은 해당툴의 사용이 어렵고 내가 알고 싶은 정보를 알 수 없으니 "일일보고 엑셀로 제출해주세요" 라는 요청을 내리게 되고, 이렇게 되면 개발자분들에게 프로젝트관리툴은 정말 쓸데없는 일이 되어 버립니다. <개발만신경쓰기도바쁜데> 그럼 이러한 상황을 가져오지 않게하여, 개발자분들은 개발만 하고 티켓에만 신경쓸 수 있는 방법은 없을까요? 비씨티오를 사용하세요. 비씨티오에서는 프로젝트 관리 툴 API를 연동하여, 개발자분들은 사용하시던 그대로 사용하면, 그 중 대표님들이 보셔야 하는 정보만을 가져다 보여드려요. 개발자분들은 개발만 하고 프로젝트 관리툴을 사용해서 업무관리만 하면, 대표님 혹은 개발 관려자분들은 그것들을 아주 쉽게 읽어내실거고 프로젝트 관리툴 기준으로 개발자분들과 소통 하시게 됩니다. <작업중인티켓과상세개발내역> <티켓의 상세내역> 비씨티오는 개발자분들이 정말 개발에만 신경쓰는 환경을 만들어가겠습니다.2025.04.09 
