2020.06.22

기고 | SW 프로젝트 속도를 높이는 11가지 방법

Peter Wayner | CIO
전략적 의사결정은 소프트웨어 프로젝트 속도에 박차를 가해 비즈니스 기회를 활용하는 데 도움이 될 수 있다. 하지만 IT리더는 서둘러서 프로젝트를 끝내는 것만이 능사가 아님을 인지하고 주의해야 한다.
 
ⓒGetty Images Bank


IT리더와 고객은 소프트웨어 프로젝트가 신속히 마무리되기를 원한다. 그러나 속성 개발은 오류 코드, 부실한 테스팅, 불완전한 솔루션, 심지어 보안되지 않은 소프트웨어로 이어지기 쉽다. 소프트웨어 프로젝트가 실패하기를 원하는 사람은 없겠지만 때에 따라 특정 상황, 예를 들어 시장 환경, 비즈니스 요구, 기회의 여지로 속도를 우선시하는 선택이 정당화될 수 있다. 

소프트웨어 개발은 단순히 합리적 노력에 그치지 않는다. 이는 요령이기도 하고 여러 조직에서 비즈니스 전략의 불가결한 부분이기도 하다. 이들 요소가 서로 접하는 지점에서 개발 프로세스를 좀더 효율적으로 조정할 가능성이 존재한다. 물론, 이는 효과적이고 적절하며 단순하고 안전해야 한다. 완전한 소프트웨어를 개발한다는 꿈을 접고, 그 대신 취사선택이 필요함을 인지하고 프로젝트를 간소화하는 결정을 내려야 할 것이다.  

IT리더가 소프트웨어 프로젝트에 속도를 내고자 할 때 고려할 수 있는 11가지 전략적 결정을 소개한다. 

이해관계자의 희망 사항을 조율하라 
모두가 의견을 제시하고 싶어 한다. 마케팅팀, 출하 부서, 회계팀의 이해 관계자는 커다란 희망을 안고 회의실로 들어선다. 요령은 성취하기 가장 쉬운 희망을 찾는 것이다. 언젠가 필자의 소프트웨어팀은 회의를 거듭하면서 단순히 한 양식 필드에 미리 채워진 기본값들을 추가함으로써 데이터 작성자의 부담을 크게 덜 수 있음을 발견했다. 하루에도 수없이 처음부터 양식을 작성하는 판매 직원이 수없이 많았다. HTML에 문자를 몇 개 더 집어넣는 것만으로 우리 팀은 마치 천재처럼 대우받았다.  

이해관계자가 현실을 직시하도록 하는 것은 프로젝트의 범위를 제어하는 데 유용하다. 이해관계자가 소소하면서도 매우 가치 있는 기능과 개선에 집중하도록 함으로써 프로젝트 기간을 크게 앞당길 수 있다.  

개발자의 과욕을 억제하라 
그러나 버릴 수 있는 것은 이게 전부가 아니다. 개발자 역시 현실을 직시해야 한다. 프로젝트 목록에 있는 모든 항목이 개발자에게는 똑똑하고 참신하고 믿기 어려울 정도로 시간을 소비하는 일부 전문 용어를 마침내 실현할 기회로 보인다. 화면상에 2개 열이 정렬되지 않았는가? 그렇다면 이제 다중 그라디언트 전력 하강 최적화 퀀텀 머신러닝 알고리즘(multi-gradient power descent optimizing quantum learning algorithms)을 이행하는 수학 함수로 전체 스택을 다시 작성할 시간이다. 

개발자의 열정은 흔히 일정을 가속하는 데 필수적이지만, 그러한 열정이 간소화된 목표를 지향하도록 하는 것이 매우 중요하다. 

기능을 배제하라 
요구 사항을 잘라낸다면 나태하다는 인상을 줄 수 있다. ‘모든 것’을 작은 규모로 재정의한다면 ‘모든 것’을 더 빨리 달성할 수 있다. 

한편 분산보다 집중이 필수적이고 유용한 경우도 있다. 영리한 접근법이란 누락시킨 기능을 다음에 처리하기에 충분할 정도로 기반을 확고히 다져 두는 것이다. 예를 들어 데이터베이스 스키마는 향후 추가될 것으로 예상되는 보강에 대비할 수 있어야 한다. 스키마를 약간 조절하는 것이 전부라면 이번에 누락된 기능을 다루어야 할 때 시간을 절약할 수 있다.  

테스팅을 간소화하라  
코드를 전개할 때 어려운 점 한가지는 실무에 투입하기 전에 테스트해야 한다는 것이다. 최근에는 모든 것을 독립적으로 행할 수 있는 소형 프로젝트로 나누는 것이 유행이다. 이들 프로젝트를 개별적으로 테스트한다면 테스팅이 훨씬 더 많아질 것이다. 수십 개의 소형 프로젝트로 채워진 최신 마이크로서비스 아키텍처라면 수십 번의 테스트를 거쳐야 한다. 

테스트를 건너뛸 수는 없다. 요령은 함께 작용하는 여러 프로젝트를 동시에 테스트하는 것이다. 때에 따라 여러 부분을 한데 묶음으로써 개별 테스트의 필요를 제거할 수 있다. 
 

---------------------------------------------------------------
프로젝트 관리 인기기사
->프로젝트 실패를 경고하는 적신호 5가지
->칼럼 | 솔직히 말하자, 프로젝트 후원자와 관리자가 문제다
->프로젝트 리더가 기억해야 할 '사람 우선' 전략 4가지
->프로젝트 관리·추적은 이렇게 '7가지 체험 팁'
->"기대치 조율은 이렇게" 프로젝트 관리 11가지 팁
->"온라인 협업과 프로젝트 관리에 그만!" 무료 툴 7선
->예산•일정•진척도 관리 도와줄 PM툴 5선
->폭포수 프로젝트 관리에도 민첩성이 필요하다
-> ‘에이스프로젝트 · 베이스캠프 · 조호 프로젝트’··· PM 툴 3종 비교분석
-> PM이 대비해야 할 흔한 프로젝트 문제 7가지
---------------------------------------------------------------

아키텍처를 단순화하라 
기능을 배제하고 일부 작업을 연기할 생각이라면 그와 동시에 아키텍처를 재고할 수 있는 경우가 있을 수 있다. 그렇지 않은 경우 또한 있다. 

기능을 다음 분기, 심지어 다음 해에 처리할 생각이라고 해도 이의 기반을 조성해 두는 것이 좋다. 그러나 이들이 필수적이지 않다면 아키텍처의 큰 부분을 생략하는 것도 나쁘지 않다.

 




2020.06.22

기고 | SW 프로젝트 속도를 높이는 11가지 방법

Peter Wayner | CIO
전략적 의사결정은 소프트웨어 프로젝트 속도에 박차를 가해 비즈니스 기회를 활용하는 데 도움이 될 수 있다. 하지만 IT리더는 서둘러서 프로젝트를 끝내는 것만이 능사가 아님을 인지하고 주의해야 한다.
 
ⓒGetty Images Bank


IT리더와 고객은 소프트웨어 프로젝트가 신속히 마무리되기를 원한다. 그러나 속성 개발은 오류 코드, 부실한 테스팅, 불완전한 솔루션, 심지어 보안되지 않은 소프트웨어로 이어지기 쉽다. 소프트웨어 프로젝트가 실패하기를 원하는 사람은 없겠지만 때에 따라 특정 상황, 예를 들어 시장 환경, 비즈니스 요구, 기회의 여지로 속도를 우선시하는 선택이 정당화될 수 있다. 

소프트웨어 개발은 단순히 합리적 노력에 그치지 않는다. 이는 요령이기도 하고 여러 조직에서 비즈니스 전략의 불가결한 부분이기도 하다. 이들 요소가 서로 접하는 지점에서 개발 프로세스를 좀더 효율적으로 조정할 가능성이 존재한다. 물론, 이는 효과적이고 적절하며 단순하고 안전해야 한다. 완전한 소프트웨어를 개발한다는 꿈을 접고, 그 대신 취사선택이 필요함을 인지하고 프로젝트를 간소화하는 결정을 내려야 할 것이다.  

IT리더가 소프트웨어 프로젝트에 속도를 내고자 할 때 고려할 수 있는 11가지 전략적 결정을 소개한다. 

이해관계자의 희망 사항을 조율하라 
모두가 의견을 제시하고 싶어 한다. 마케팅팀, 출하 부서, 회계팀의 이해 관계자는 커다란 희망을 안고 회의실로 들어선다. 요령은 성취하기 가장 쉬운 희망을 찾는 것이다. 언젠가 필자의 소프트웨어팀은 회의를 거듭하면서 단순히 한 양식 필드에 미리 채워진 기본값들을 추가함으로써 데이터 작성자의 부담을 크게 덜 수 있음을 발견했다. 하루에도 수없이 처음부터 양식을 작성하는 판매 직원이 수없이 많았다. HTML에 문자를 몇 개 더 집어넣는 것만으로 우리 팀은 마치 천재처럼 대우받았다.  

이해관계자가 현실을 직시하도록 하는 것은 프로젝트의 범위를 제어하는 데 유용하다. 이해관계자가 소소하면서도 매우 가치 있는 기능과 개선에 집중하도록 함으로써 프로젝트 기간을 크게 앞당길 수 있다.  

개발자의 과욕을 억제하라 
그러나 버릴 수 있는 것은 이게 전부가 아니다. 개발자 역시 현실을 직시해야 한다. 프로젝트 목록에 있는 모든 항목이 개발자에게는 똑똑하고 참신하고 믿기 어려울 정도로 시간을 소비하는 일부 전문 용어를 마침내 실현할 기회로 보인다. 화면상에 2개 열이 정렬되지 않았는가? 그렇다면 이제 다중 그라디언트 전력 하강 최적화 퀀텀 머신러닝 알고리즘(multi-gradient power descent optimizing quantum learning algorithms)을 이행하는 수학 함수로 전체 스택을 다시 작성할 시간이다. 

개발자의 열정은 흔히 일정을 가속하는 데 필수적이지만, 그러한 열정이 간소화된 목표를 지향하도록 하는 것이 매우 중요하다. 

기능을 배제하라 
요구 사항을 잘라낸다면 나태하다는 인상을 줄 수 있다. ‘모든 것’을 작은 규모로 재정의한다면 ‘모든 것’을 더 빨리 달성할 수 있다. 

한편 분산보다 집중이 필수적이고 유용한 경우도 있다. 영리한 접근법이란 누락시킨 기능을 다음에 처리하기에 충분할 정도로 기반을 확고히 다져 두는 것이다. 예를 들어 데이터베이스 스키마는 향후 추가될 것으로 예상되는 보강에 대비할 수 있어야 한다. 스키마를 약간 조절하는 것이 전부라면 이번에 누락된 기능을 다루어야 할 때 시간을 절약할 수 있다.  

테스팅을 간소화하라  
코드를 전개할 때 어려운 점 한가지는 실무에 투입하기 전에 테스트해야 한다는 것이다. 최근에는 모든 것을 독립적으로 행할 수 있는 소형 프로젝트로 나누는 것이 유행이다. 이들 프로젝트를 개별적으로 테스트한다면 테스팅이 훨씬 더 많아질 것이다. 수십 개의 소형 프로젝트로 채워진 최신 마이크로서비스 아키텍처라면 수십 번의 테스트를 거쳐야 한다. 

테스트를 건너뛸 수는 없다. 요령은 함께 작용하는 여러 프로젝트를 동시에 테스트하는 것이다. 때에 따라 여러 부분을 한데 묶음으로써 개별 테스트의 필요를 제거할 수 있다. 
 

---------------------------------------------------------------
프로젝트 관리 인기기사
->프로젝트 실패를 경고하는 적신호 5가지
->칼럼 | 솔직히 말하자, 프로젝트 후원자와 관리자가 문제다
->프로젝트 리더가 기억해야 할 '사람 우선' 전략 4가지
->프로젝트 관리·추적은 이렇게 '7가지 체험 팁'
->"기대치 조율은 이렇게" 프로젝트 관리 11가지 팁
->"온라인 협업과 프로젝트 관리에 그만!" 무료 툴 7선
->예산•일정•진척도 관리 도와줄 PM툴 5선
->폭포수 프로젝트 관리에도 민첩성이 필요하다
-> ‘에이스프로젝트 · 베이스캠프 · 조호 프로젝트’··· PM 툴 3종 비교분석
-> PM이 대비해야 할 흔한 프로젝트 문제 7가지
---------------------------------------------------------------

아키텍처를 단순화하라 
기능을 배제하고 일부 작업을 연기할 생각이라면 그와 동시에 아키텍처를 재고할 수 있는 경우가 있을 수 있다. 그렇지 않은 경우 또한 있다. 

기능을 다음 분기, 심지어 다음 해에 처리할 생각이라고 해도 이의 기반을 조성해 두는 것이 좋다. 그러나 이들이 필수적이지 않다면 아키텍처의 큰 부분을 생략하는 것도 나쁘지 않다.

 


X