중소 SW기업 대표는 “네이버, 카카오 등 플랫폼·게임사가 SW 개발자 연봉을 두 배 이상 올려 스카우트하는 상황에서 인력 유출을 막기 위해 임금을 10∼30% 인상할 수밖에 없었다”면서 “SW 개발비에서 비중을 가장 많이 차지하는 SW 개발자 임금이 증가했지만 SW 사업 대가는 이를 반영하지 않아 사업 운영에 어려움이 많다”고 말했다.
수많은 조언을 읽고 듣고 있지만 IT 부서를 제대로 운영하고 있는지 불안한가? 여기 현대 IT 리더들이 종종 저지르는 7가지 실수를 정리했다.
오늘날 CIO는 수많은 소스에서 보다 효율적인 IT 부서 관리 방법에 대한 조언을 얻을 수 있다. CIO닷컴을 비롯해 수많은 시장 조사 기관이 도움을 주려 한다. CIO의 최우선 사항이 무엇이 되어야 하는지를 목록화한 수많은 콘텐츠가 있다. 보통 너무 뻔한 내용인 경우도 흔하지만, 딱히 손해볼 것도 없는 자료들이다.
흔하지 않은 조언을 제공하기 위한 시도로, 이 글에서는 IT 관리 측면의 7가지 중요한 잘못을 살펴보고자 한다. 뻔한 글로 읽히지 않기를 바란다. 1. ‘리드’는 부족하고 ‘관리’만 많이 함 흔하지 않은 조언이라는 앞서의 약속이 벌써부터 위태롭다. 관리 대신 리드하라는 조언을 많이 접해봤을 것이다.
다리가 없는 개(a dog with no legs)에 대한 오래된 농담이 있다. ‘다리 없는 개를 어떻게 불러야 하나?’라는 질문과 ‘중요하지 않다. 어쨌든 그 개는 오지 않을테니’라는 답변이다. 매일 아침 개의 주인은 개를 질질 끌어내게 된다. 직원들을 질질 끌고 가는 것과 그들이 스스로 올바른 방향으로 나아가도록 하는 것 사이에 차이를 만드는 것이 바로 리더십이다.
2. '그러나' 리드는 너무 많이 하고 관리는 충분히 하지 않음 당신은 업무에 대해 돈을 받는다. 그것이 바로 관리과 관련을 가진다. 즉, 당신이 책임지고 있는 기업의 업무를 확실히 수행하는 것이다.
리더십은 그러한 목표를 달성하는 데 유용한 도구이다(위의 ‘개’를 참조할 것). 하지만 그것은 유일한 도구는 아니다. 정보 기술이 명백한 예이다. 비즈니스 프로세스 최적화 이니셔티브도 마찬가지이다. 그리고 종종 리더십에 너무 중점을 두고 있기 때문에 관리자들은 자신이 무엇 때문에 월급을 받는지 놓치곤 한다.
3. 차지백을 다투기 차지백은 ‘위대한 이론이지만…’이라고 표현할 수 있겠다. ‘위대한 이론’ 부분은 IT 리소스에 대해 비용을 지불하게 함으로써 (현업) 이용자가 IT에 무엇을 요청해야 하는지에 대한 결정을 보다 신중하게 내릴 수 있도록 한다는 것이다.
‘이지만’ 부분은 IT가 얼마나 청구하는지 설명할 때 발생한다. IT가 차지백을 계산하는 2가지 방법이 있다. 먼저 단순한 방법으로 IT 예산을 현업 관리자에게 할당할 수 있는데, 예를 들어, 기업의 총 인원의 백분율 또는 관리자가 통제하는 총 기업 예산의 백분율과 같은 이해하기 쉬운 지표를 기준으로 한다.
아니면 IT는 각 IT 리소스 유형별로 세분화된 단위 비용을 계산하고, 해당 리소스의 소비를 모니터링하며, 단위 비용으로 제시할 수 있다.
단순한 접근 방식은 잊어버려라. 그것을 매력적이게 하는 그 단순성이 문제가 된다. 현업 관리자가 IT 소비를 줄임으로써 차지백 비용을 절감할 수 있는 방법이 없기 때문에 전제와 어긋난다.
세분화되고 정확한 접근 방식의 경우, 청구값에 대한 논쟁으로 인해 전체 시간과 예산이 낭비되기 쉽다. 즉 이 접근 방식은 복잡하기 때문에 입증할 수 없는 수많은 가정의 결과로 이어진다. 게다가, 누가 논쟁에서 이기든, 양측이 잃어버린 시간은 그들의 시간의 비용으로 환산하면, 같은 돈이 어느 주머니에서 나올 것인지 결정하는 것과 같다.
포기하라.
4. 기술자가 아닌 사업가(business person)가 되기 위한 노력 CIO라면 이 충고를 반복해서 읽었다. 오늘날 명함에 ‘기술’이 적힌 최고 경영자가 기술자여서는 안 된다는 독특한 주장이 제기되고 있다.
그러나 선후를 혼동해서는 안 된다. 우선, 둘을 비교해보면 사업가가 되는 것이 더 쉽다. 둘째로, 회사의 CFO가 재무 전문가가 아닌 사업가여야 하며 최고 마케팅 책임자가 마케팅 전문가가 아니라 사업가여야 한다고 생각하는가?
어쨌든 당신의 관심을 끌었으니 비유를 더해본다. 기술자가 아닌 사업가가 되려고 노력하는 CIO들은 ‘인싸’가 되려고 필사적으로 노력하는 ‘아싸’ 고등학생들과 같다. 그래봤자 그들은 여전히 소외될 것이다. 쿨하지 못할 뿐더러 한심함까지 더해지게 되었다.
5. ‘아키텍트’를 동사로 사용하기 이것은 단지 필자의 의견일 뿐이다. 하지만 나는 동사로서의 아키텍트가 앞으로 당신이 할 일에 대해 ‘엔지니어’를 동사로 대체하는 것과 비슷하다고 생각한다. 종종 “우리는 해결책을 아키텍트 해야 한다”는 말을 들으면 비즈니스 인싸 모임에 가입하는 데 실패한 누군가가 대신 기술 인싸 모임에 가입하기로 결정한 것처럼 들린다.
6. ‘베스트 프랙티스’ 활용하기 지는 싸움이다. 어떤 것이 ‘모범관행’이라고 주장하는 사람에게 반박하기는 어렵다. 그저 좋은 관행, 검증된 관행, 또는 기본적인 전문성의 최소 기준을 의미하는 경우가 태반이다. 이에 반박한다는 것은 그저 불평처럼 들리기 십상이며 명분을 잃기도 쉽다. 현실은 그저 희망사항을 나열하는 것에 그친다. . 싸움에 졌을테니 행운의 숫자 7로 넘어가겠다.
7. 프로젝트 관리에서 제품 관리로 초점 전환 프로젝트 관리는 조직이 계획적이고 의도적인 방식으로 미래를 어제와 다르게 만드는 방법이다. 제품 관리는 기업의 제품 또는 제품군 중 하나의 발전을 관리하여 시장의 매력을 유지하고 강화하는 접근법이다.
IT 제품 관리는 애자일 세계에서 벗어나 비즈니스 제품 관리와 느슨하게 연결되어 있다. 비즈니스 기술 또는 애플리케이션 포트폴리오의 일부 부분의 매력을 향상시키는 데는 한계가 있지만, IT 제품 관리는 그렇지 않다. 그것은 책임과 의사결정 권한을 확립하는 것에 관한 것이다.
제품 관리가 프로젝트 관리보다 더 나은 것은 말할 것도 없고 흥미롭게 만들 만큼 충분히 다른가?
3당사자 모델의 경우 카드사가 가맹점 및 회원 서비스를 함께 수행한다. 따라서 3당사자 체제에서는 승인 및 매입 업무와 가맹점 모집 및 관리 업무를 위탁 수행하는 VAN사 또는 PG사가 개입하게 된다. VAN사가 주로 오프라인에서 신용카드사와 가맹점 간 네트워크를 구축해 신용카드 거래 승인, 매출 전표 매입 등 지급결제대행업을 수행한다면 온라인에서는 추가적으로 PG사가 전자상거래에서 가맹점과 구매자 간 결제에 참여한다. 이러한 프로세스에서 신용카드사는 가맹점으로부터 가맹점 수수료, 소비자에게 연회비 등 가입비, VAN사로부터는 VAN 수수료를 받게 된다.
프로그래머는 엄격한 규칙을 따를 필요가 없습니다.따라서 프로그래밍 스타일을 개발하는 데 아무런 문제가 없습니다.그러나 나쁜 습관에 빠지는 것은 우리 모두가 겪은 일입니다.최고의 개발자라도 단기적으로는 작업을 더 편리하게 만들 수 있지만 나중에는 자신과 동료, 고객에게 문제를 일으킬 수 있는 지름길, 방법 및 태도에 의존할 수 있습니다.
이 기사 전체에서 개발자가 즉시 버려야 하는 7가지 최악의 습관에 대해 논의할 것입니다.이러한 습관을 알면 향후 이러한 습관을 피하고 개발자로서 성공하는 데 도움이 됩니다.성공적인 소프트웨어 개발자와 비효율적인 소프트웨어 개발자 모두 이러한 불행한 습관에 빠지기 쉽습니다.
1. 코드 복제
소프트웨어가 올바르게 작동하면 중복 코드를 수정할 필요가 없다는 것이 프로그래머 사이의 일반적인 인식입니다.당신이 하고 있는 유일한 일은 당신의 소프트웨어에 불필요한 벌크를 추가하는 것입니다.대부분의 개발자가 몇 개의 코드 블록을 실행하는 데 몇 밀리초밖에 걸리지 않는다고 주장할 것이라는 데는 의심의 여지가 없습니다. 이는 소프트웨어를 몇 번 사용하려는 경우에만 가능합니다.
뿐만 아니라 중복 코딩은 코드 품질에도 영향을 미칩니다.그것은 당신의 코드를 냄새나게 만들고 기술적 부채를 증가시킵니다.이 부채를 복구하려면 개발자에게 비용을 지불하여 단순화하거나 중복을 제거해야 합니다.
코드의 중복이 적을수록 프로그램이 더 빨리 실행되고 공간이 덜 소모된다는 점을 항상 기억하십시오.참을성 있게 기다리던 시대는 갔다.이제 모든 것이 원활하고 빠르게 실행되어야 합니다.
2. 자신의 방식대로 일하기
우리 모두는 코딩 스타일이 있습니다.그러나 당신의 방식대로 일을 쉽게 할 수 있음에도 불구하고 다른 사람들이 당신의 코드 스타일에 적응하지 못할 수도 있고, 그것이 일반적이지 않다면 당신을 따르는 누군가가 당신의 작업을 사용하는 데 어려움을 겪을 수도 있습니다.그것을 하는 사람은 장기적으로 코드를 작성하는 것이 생산적이지 않거나 행복하지 않을 것입니다.
3. 코딩 스타일에서 문제 수정 미루기
훌륭한 프로그래머는 코드의 모든 부분이 중요하다는 것을 알고 있으며 수정 사항을 찾는 과정에서 기능 뒤에 있는 디자인과 아이디어에 의문을 제기합니다.수년 동안 저는 개발자가 다른 문제보다 코딩 스타일 문제를 수정하는 것을 더 미루는 경향이 있음을 알게 되었습니다.코딩은 일반 개발자도 마스터가 되지 못하게 하는 수많은 나쁜 습관이 있는 기술이라는 점을 명심하십시오.자신을 개선하고 더 나은 개발자가 되려면 자신의 나쁜 특성을 이해하고 수정하기 위해 노력해야 합니다.
4. 코드 최적화 방법을 모름
효과적인 최적화 전략을 개발하려면 경험이 필요합니다.이 프로세스에는 관련된 각 시스템에 대한 탐색, 분석 및 지식이 필요합니다.이러한 사항을 숙지해야 합니다.일반적인 성능, 알고리즘 복잡성 및 데이터베이스 쿼리 평가를 측정하는 방법을 알아보세요.
성능은 알고리즘 복잡성, 비효율적인 데이터베이스 작업, 타사 API 사용 또는 N+1 쿼리 실행과 같은 일부 상황에서 큰 문제가 될 수 있습니다.성능 문제를 분석하는 방법을 이해하고, 무엇이 시간이 걸리는지 파악하고, 문제가 발생하는 즉시 수정하는 것이 중요합니다.알고리즘과 데이터 구조를이해하는 것은당신에게 큰 도움이 될 것입니다.
5. 도움 요청 거부
내 경험상 개발자는 이러한 습관을 가질 가능성이 가장 높습니다.그렇다면 이 개발자들이 상사나 팀원에게 도움을 요청하지 않는 이유가 궁금하다면?음, 두 가지가 이 요인으로 이어집니다.첫 번째, 자부심, 두 번째는 그들이 부끄러워하고 승진이나 급여 인상의 기회에 영향을 미칠 수 있는 특정 사항에 대한 지식이 부족하다는 인상을 다른 사람들에게 주고 싶지 않다고 생각합니다.
우선, 더 높은 사람에게 도움을 요청하는 것을 부끄러워할 필요가 없습니다.자기 의심을 경험하는 것은 흔한 일이지만, 그것에 매달리는 것은 흔한 일이 아닙니다.자신감을 가지세요!팀으로 작업하는 경우 팀이라고 하는 데에는 이유가 있습니다!의심이 들 때마다 팀원이나 원하는 사람과 자유롭게 이야기하십시오.긍정적인 태도를 유지하고 가능할 때마다 도움을 요청하십시오.
6. 건강에 집중하지 않음
프로그래머가 밤늦게까지 일하는 것은 흔한 일입니다.일반적으로 이는 대부분의 프로그래머가 서버에 과부하를 주지 않고 디버그 및 컴파일할 수 있도록 밤늦게까지 일하고 낮에는 회의가 없기 때문입니다.따라서 프로그래머는 일반적으로 늦은 밤에 가장 생산적입니다.
하지만 아침에 출근해야 한다는 걸 알면서도 밤늦게까지 일하는 것은 건강상의 문제를 누적시킨다.지금은 기분이 좋지 않을 수도 있지만 직장에서 너무 많은 시간을 보내거나 재미로 코딩을 한다면 웰빙에 주의를 기울여야 합니다.
수면 부족은 정신 및 생리적 문제로 이어질 수 있으며, 소진, 우울증, 질병 등의 자기강화 주기로 이어집니다. 규칙적으로 충분한 수면을 취하고, 상쾌하고, 명상하고, 전체 기간 동안 생산적이고 집중하는 법을 배움으로써 이 문제를 해결할 수 있습니다. 낮.
7. 쉽게 포기한다
해결책을 찾을 수 없는 문제를 해결하는 데 어려움을 겪고 있습니까?하나도 생각이 안난다면 당신은 굉장한 개발자임에 틀림없죠?그것은 그것이 작동하는 방식이 아닙니다.어딘가에 갇혀 있다고 해서 무능하다는 의미는 아닙니다.그러나 포기는 이 개념이 사실임을 증명합니다.
모든 문제는 코드로 해결할 수 있음을 항상 기억하십시오.정확한 시간과 자원을 확보하는 것이 관건입니다.문제에 갇혀 있다고 느낄 때마다 포기하지 마십시오. 문제를 해결하기 전에 시간과 조사가 필요할 것입니다.
"명랑한 마음은 인내하고 강한 마음은 천 가지 어려움을 헤쳐나갑니다."— 스와미 비베카난다
