[IT/리뷰] 실용주의 소프트웨어 개발 리뷰

책정보, 실용주의 소프트웨어 개발 : 네이버 책 (naver.com)

실용주의 소프트웨어 개발

"현장에서 걷어올린 소프트웨어 개발 베스트 프랙티스"라는 부제와 함께 실용적인 개발 방법이 무엇일지 궁금해서 책을 보게 되었다.

내용 자체는 다른 개발 프로세스 관련된 책들과 크게 다른 바가 없는 것 같다. 하지만, 정말 현장에서 필자가 필요하다고 느꼈던 점들에 대해서만 간략하게 작성된 것을 알 수 있었다. 다양한 내용들에 대해 소개하고 있고 엄청 깊게는 다루지 않고 필요한 정도만 소개하고 있다.

그리고 작성 스타일도 정말 개발자가 읽기 쉽게끔 작성되어 있는 것 같다는 느낌을 받았다. 어떤 점이 문제고, 어떻게 보통 생각을 하고 있거나 현실은 어떻고, 베스트 프랙티스는 무엇인지 설명한다.

 

아무튼 많은 주제에 대해 필요한 정보들을 설명해주는데, 꽤 마음이 와닿거나 유용한 정보들이 있었다. '내가 잘하고 있구나'라고 생각한 부분도 있었고, 반대로 '내가 이 점이 부족한 것 같다'라고 생각한 부분도 있다. 그리고 회사에서도 어느 시스템이 잘못된 것 같다는 느낌도 많이 받았다.

현재 개발자의 개발에 대한 인터럽트가 많이 걸린다는 느낌이다. 물론 많은 부분을 올해 들어서 해결하긴 했다. QA에서 1차적으로 문의 대응들을 해준다는 것이다. 그런데, QA에서 대응하는 것도 수준들이 많이 떨어지는 것들이 있다는 것도 문제다. 결과적으로 QA도 업무 수행에 있어 인터럽트가 많이 걸리고 있다. 엔지니어 교육부터 문의 대응 관련 프로세스가 개선되었으면 좋겠다고 책을 읽으면서 많이 느껴졌다. 아마, 다른 책에도 있는 내용들이겠지만, 현 상황과 맞물려 많이 느끼게 되었다.

 

아래부터는 책의 일부 내용에 대한 요약 및 느낀 점이다. 프로젝트에 대한 내용도 있지만, 시간 관리라던지 자기 계발에 대한 내용도 다루고 있다.

---

요약

---

프로젝트에 맞는 소프트웨어 생명주기 선정

어떤 모델이나 개발 방법론도 프로젝트에 적합한 모델이 무엇인지 선정해야 하며, 프로젝트 특징에 맞춰 조정(Tailoring)을 통해 적용해야 한다.

폭포수 모델

• 사용하는 경우
  • 고객 요구사항이 잘 정의되고 문서화됨
  • 고객이 첫 납품에 모든 성능을 원함
  • 고객이 기존 시스템을 한 번에 폐기하기를 원함
• 사용하지 말아야 하는 경우
  • 인력과 예산 투입이 점진적임
  • 시스템이 너무 커서 한 번에 개발이 힘듦
  • 시스템을 논리적 부분들로 나눌 수 있음
  • 목표와 기술의 급속한 변화가 요구사항의 변화를 가져올 수 있음

점진형 모델

• 사용하는 경우
  • 고객 요구사항이 잘 정의되고 문서화됨
  • 인력과 예산 투입이 점진적임
  • 시스템이 너무 커서 한 번에 개발이 힘듦
  • 시스템을 논리적 부분들로 나눌 수 있음
• 사용하지 말아야 하는 경우
  • 고객 요구사항이 잘 정의되지 않음
  • 목표와 기술의 급속한 변화가 요구사항의 변화를 가져올 수 있음
  • 고객이 첫 번째 납품에서 모든 성능을 원함
  • 고객이 기존 시스템을 한 번에 폐기하기를 원함

진화형 모델

• 사용하는 경우
  • 고객 요구사항이 잘 이해되지 않음
  • 목표와 기술의 급속한 변화가 요구사항의 변화를 가져올 수 있음
  • 인력과 예산 투입이 점진적임
  • 시스템이 너무 커서 한 번에 개발이 힘듦
  • 시스템을 논리적 부분들로 나눌 수 있음
  • 고객이 첫 번째 납품에서 모든 성능을 원함
  • 고객이 기존 시스템을 한 번에 폐기하기를 원함사용하지 말아야 하는 경우

---

요구사항 도출의 중요성

소프트웨어 개발의 전 단계는 요구사항과 밀접한 관계가 있다.

• 분석 단계 : 요구사항이 무엇(What)인지 정의
• 설계 단계 : 요구사항을 어떻게(How) 구현하는지 정의
• 개발 단계 : 요구사항을 시스템이 이해할 수 있는 언어로 변환(Conversion)하는 과정
• 테스트 단계 : 요구사항이 제대로 구현되었는지를 검증(Verification)하고 확인(Validation)하는 과정

---

프로젝트 실패 요인

표가 책에 실렸는데, 순서대로 나열만 하겠다.

불완전한 요구사항(13.1%), 고객 참여 부족(12.4%), 자원 부족(10.6%), 비현실적 기대치(9.9%), 경영진의 지원 부족(9.3%), 요구사항 및 규격의 잦은 변경(8.7%), 미흡한 기획(8.1%), 더 이상 필요치 않음(7.5%)

---

요구사항 특징 7가지

요구사항 도출 및 명세화를 위해 반드시 기억해야 한다.

1. Complete : (설계 및 구현을 위해) 완성도가 높아야 한다.
   • 요구사항이 설계 단계에서 활용될 수 있을 정도로 구체적
2. Correct : (사용자의 요구를) 정확히 정의해야 한다.
   • 요구사항은 사실이어야 하며, 요구사항 간에 모순이 없어야 함
3. Feasible : (목표 시스템에 구현) 타당해야 한다.
   • 구현 가능하다면, 제약사항과 전제조건 작성 
4. Necessary : (사용자가 실제로) 필요한 것이어야 한다.
   • 고객에게 무한 서비스를 제공하면 프로젝트는 실패
   • 요구사항이 정말로 필요한 것인지 분별(비즈니스 요구사항, 즉 프로젝트의 목표에 부합하는지)
5. Prioritzed : (구현을 위한) 우선순위를 부여해야 한다.
   • 반드시 완벽하게 구현해야 할 중요한 요구사항을 찾고 선택과 집중을 달리
6. Unambiguous : (모두가 이해할 수 있도록) 모호하지 않아야 한다.
   • 서로 다르게 이해할 수 있는 여지가 없도록 기술
   • 별도 용어집을 작성하는 것도 좋은 방법
7. Verifiable : (구현 여부를) 검증 가능해야 한다
   • 기능 누락 없이 구체적으로 기술되어 있느냐의 관점

---

요구사항 정의서의 상세 내용 작성을 위한 10가지 지침

1. How 보다 What에 초점
2. 중요한 요구사항 상세화에 집중
3. 업무 처리 순서를 염두에 두고 작성
4. 6하 원칙을 염두에 두고 작성
5. 테스트를 염두에 두고 작성
6. 짧은 문장으로 분명하게 작성
7. 주어와 동사를 맞춰서 작성
8. 구체적으로 요구사항을 정의하고 싶으면 화면을 삽입
9. 필요시 ASIS와 TOBE 상태를 비교해 설명
10. 공통 요구사항 도출

잘못 작성한 예시

• 공인인증서의 상태 정보(유효기간, 정상 유무 등)를 확인할 수 있어야 한다.
  • 불명확성
  • '등' 표현은 사용하지 않아야 한다.
• 고객정보를 안전하게 로그아웃 할 수 있어야 한다.
  
  • 모호성
  • 어느 정도가 '안전하게'인지
• 보유 계좌에 대한 리스트를 확인한다.
  
  • 세부 기능 누락 및 구체성 결여
  • '확인'뿐만 아니라 계좌를 선택할 수 있어야 한다.

• 계좌 정보를 보여한다.
  
  • 오류 및 부정확성
  • '보여'라는 오타
• 오류 시 메시지를 뿌려준다.
  
  • 용어 순화 필요
  • '뿌려준다'라는 말은 개발자만의 구어체다.
• 이체한 금액 및 현재 잔고를 표출해야 한다.
  
  • 공통 단어 사용 필요
  • 자신만의 단어이며, 공통 단어의 사용이 필요하다.
• 계속 이체 여부를 출력한다.
  
  • 정확한 단어 표현 필요
  • 어떻게 출력할 것인지 모른다.
• 거래는 반드시 3단계 인증을 거친다.
  
  • 명사, 동사 위주 표현
  • '반드시'와 같은 부사, 형용사는 가급적 삭제한다.
• OTP 발생기 비밀번호를 입력받는다.
  
  • 사용자 입장에서 기술
  • 수동태 또는 시스템 관점에서의 표현을 변경한다.
• 암호를 입력해 로그인할 수도 있다.
  
  • '~한다.' 또는 '~해야 한다.'로 표현
  • 애매한 표현은 사용하지 않는다.

---

유지보수 요구사항

유지보수 시 발생하는 요구사항에 대한 비용이 더 많이 소요된다. 기존 시스템을 이해하는 데에도 많은 시간이 소요되기 때문이다.

그것보다 더 힘든 이유는 제대로 요구사항을 정의하지 않기 때문이다. 신규 개발 프로젝트 요구사항에 비해 개수가 적고 간단하기 때문에 단순히 한 마디, 한 문장으로 요구사항을 요청하는 경우가 많다. 그러나, 그 요구사항 반영을 위해 기존 밀접한 관련이 되어 있는 시스템 사이의 파악에 오랜 시간이 걸린다.

유지보수 요구사항도 프로젝트 개발할 때처럼 명확하고 구체적으로 정의해야 유지보수 소요 시간을 단축할 수 있다.

---

품질 요구사항과 아키텍처

품질 요구사항은 비기능 요구사항이다. 이 품질 요구사항은 개발 초기 아키텍처에 반드시 반영되어야 고객이 만족하는 시스템이 개발될 수 있다. 예를 들어 SSO 구현을 원한다면 초기 설계에 포함되어야 한다는 것이다. 품질 요구사항이 누락되어 개발 도중에 알았을 경우 시스템 개발 전체 구조가 흔들릴 가능성이 있다.

그러니, 품질 요구사항도 빠트리지 않도록 주의하자.

---

성공적인 시스템과 실패한 시스템의 차이

부치의 말에 따르면, 성공적인 시스템에는 실패한 시스템에서 볼 수 없는 공통적 특징 두 가지가 있다.

1. 강력한 아키텍처 상(Vision)이 존재한다.
2. 반복적이고 점증적인 개발 주기를 잘 적용했다.

아키텍처 관련 개념

• 아키텍처 : 품질 속성 달성을 위한 프로젝트의 청사진
• 아키텍처 드라이버 : 아키텍처가 모습을 갖추기 위한 여러 기능적, 품질적, 업무적 요구사항
• 품질 속성 : 가용성, 변경 용이성, 성능, 보안, 시험 용이성, 사용 편의성
• 품질 속성 시나리오 : 이해관계자들의 요구사항에서 도출된 품질 속성을 소프트웨어 아키텍처 설계 관점으로 명확히 이해하기 위해 6개 항목으로 표현한 시나리오
• 아키텍처 스타일 : 작동 원리를 중심으로 계층적(Layer) 아키텍처 스타일을 정의하고 디자인 패턴을 활용
• 아키텍처 뷰 : 소프트웨어 아키텍처를 조직적 정의하기 위해 시스템의 여러 측면을 고려해 도면 형태로 표현
• 아키텍처 패턴 : 설계 전술을 일정한 방식으로 묶은 패키지로, 시스템 디자인 시 자주 발생하는 문제에 대해 재사용할 수 있는 해결책
• 애플리케이션 아키텍처 : 사용자가 원하는 기능/비기능 요건을 분석해 소프트웨어 배포, 기능 추가, 업그레이드에 유연하게 대처하는 모델 아키텍처
• 데이터 아키텍처(DA) : 소프트웨어 기능 추가, 업그레이드에 유연하게 대처하는 데이터 모델 아키텍처
• 기술 아키텍처(TA) : 다수 운영 환경에 유연하게 대처하기 위한 성능, 가용성 등에 대한 인프라 모델 아키텍처

---

프로그램 명세 작성 이유

프로그램 명세를 작성하는 첫 번째 이유는 프로그래밍을 잘하기 위해서다. 명세와 코드는 서로 대립적인 것이 아니다. 서로 다른 관점일 뿐이다. 명세화는 프로그램이 어떻게 동작하는지를 미리 작성해보는 것이며 프로그램이은 명세서의 내용을 특정 개발 언어로 구현한 것이다.

명세를 작성하는 두 번째 이유는 문제 해결이 용이하다는 점 때문이다. 명세서를 작성하다 보면 생각하지 못한 문제와 의사 결정이 필요한 사항을 만나게 된다. 해당 문제를 해결하고 의사 결정이 이루어져야 프로그래밍이 완벽해질 수 있으며, 그렇지 않을 경우 개발자가 알아서 판단해 프로그래밍을 하게 되고 이것은 추후 재작업의 불씨를 초래한다.

프로그램 명세 작성 7가지 습관

회사에서 명세 작성을 하면서 어려움을 많이 겪었었다. 그동안 느낀 점과 책에서 말하는 내용과 일치해서 추가해둔다.

1. 프로그램 유형별로 다르게 작성
   • 일반적으로 세 가지 경우로 구분할 수 있다. 화면을 토대로 실시간 처리를 하는 온라인 프로그램, 특정 시간에 자동으로 수행하는 배치 프로그램, 외부 시스템과의 인터페이스를 위한 프로그램이다.
   • 각 프로그램 유형별로 프로그램 명세서 템플릿을 만들어 차별적으로 관리하라.
2. 온라인 프로그램은 사용자 인터페이스 화면을 검토한 후에 바로 작성
   • 온라인 프로그램은 프로그램 단위보다는 화면 단위 명세 작성이 좋다.
   • 고객과 화면 검토 후에 바로 작성해야 기억의 소실을 막고 빠르게 명세서를 완성할 수 있다.
3. 미해결 사항을 프로그래밍 이전에 반드시 해결
   • 고객과 사전 검토했더라도 의사 결정이 필요한 사항부터 사소한 질문까지 예상하지 못한 현안들을 만나게 된다. 이럴 때는 지체 없이 이해관계자와 대화를 하거나 자료를 찾아 해소해야 한다.
4. 중요도와 복잡도가 높은 프로그램은 반드시 명세서를 작성
   • 모든 프로그램에 대해 명세서를 작성할 필요는 없다. 중요한 요구사항과 관련된 프로그램 명세서는 필수적으로 작성한다. 세세한 부분도 중요하게 여겨야 한다. 로직이 명확해야 프로그래밍이 정확해지기 때문이다.
   • 그러나 단순 조회 프로그램 같은 경우 명세서 작성은 불필요하다.
5. 업무 흐름과 데이터 입출력을 표현
   • 구현할 프로그래밍 언어 또는 데이터베이스 언어로 명세서를 작성할 필요는 없다.
   • 명세서는 업무 처리 흐름과 데이터 입출력 이 두 가지를 한글로 구체적으로 표현한다.
6. 변경을 관리
   • 명세서 작성 후 형상관리 도구로 변경을 관리하라.
   • 워드 프로그램의 변경 추적 기능 등을 활용해 변경을 관리할 수도 있으나, 어쨌든 추후 제품의 업그레이드나 유지보수를 할 때 명세서를 활용할 수 있도록 변경 이력을 관리하라.
7. 참고자료를 관리
   • 개발을 위해 필요한 모든 내용을 명세서에 담을 수 없다.
   • 구현을 위해 필요한 사항이지만 굳이 상세히 알 필요가 없는 경우 별도 기술 문서를 참조하도록 링크로 연결해 관리하라.

---

2인 1조 프로그래밍(짝 프로그래밍)

2인 1조 프로그래밍은 얼마 전까지만 하더라도 굉장히 리소스 낭비가 심하고 불필요한 것으로 여겼다. 그런데, 이번 책에서 읽은 내용과 최근 회사에서 팀장님과 같이 짝 프로그래밍처럼 진행할 일이 있었어서 크게 도움이 된다고 느꼈다. 물론 팀장님의 공수를 빼서 투자하는 것이기 때문에 어느 정도 리소스 낭비라고 생각할 수 있다. 그렇다 하더라도 내 입장에서는 크게 도움이 된 것은 확실하다. 아래부터는 책의 우수사례 내용을 정리한 것이다.

• 전체 개발 기간이 아니라 잘게 쪼개서 진행한다.
  • 비용 문제가 거슬린다면, 잘게 쪼개서 부분적으로 도입을 고려한다.
• 새로운 인력이 프로젝트 환경에 신속히 적응할 필요가 있거나 신기술을 도입하여 관련 개발자가 부족한 경우에 적용한다.
  • OJT(On the Job Training)을 실시해 교육훈련을 진행할 때 직무교육으로 사용한다면 배움의 효과가 크다.
  • 협업과 팀워크의 스킬도 배울 수 있다.
• 숙련된 작업 또는 전문가들에게는 적용하지 마라.
  • 개발자가 숙련도가 낮고 난이도가 높은 작업일 때 2인 1조 프로그래밍의 효과가 크다.
• 코드 인스펙션(Inspection)을 적절하게 사용한다.
  • 혼자 프로그래밍을 하는 것보다는 15% 정도의 시간이 더 소요된다. 따라서, 코드의 품질 향상이 15%의 시간을 투자하는 것보다 좋다고 판단될 때 도입하라.
• 무엇보다 개발환경과 인간적 요소를 세밀하게 신경을 써야 한다.
  • 의자와 모니터와 같은 물리적인 환경과 함께 프로그래밍 시간 및 규칙 등을 정해놓아야 한다.
  • 불편한 자리, 긴 시간 동안의 짝 프로그래밍은 지양하라.
• 2인 1조 설계로 확대한다.
  • 2인 1조 프로그래밍 성숙도가 올라간다면 설계부터 공동으로 진행할 수 있을 것이다.

---

소스코드 클린업(Cleanup) / 리팩터링(Refactoring)

아래는 리팩터링을 하기 좋은 시점에 대한 우수사례 내용이다.

• 구현 후에 하지 말고 수정의 필요성을 느끼는 그 순간 수행한다.
  • 코드가 잘 맞지 않아 문제에 부딪혔을 때, 두 개의 모듈을 하나로 합쳐야 할 때, 전역 변수를 써야 할 때, 무엇인가 잘못되었다고 판단되었을 때, 그때 변경하라.
  • 일이 더 진척된다면 신경 써야 할 의존성이 더 많이 생겨 문제를 고치기 위한 시간이 더 투자되어야 한다.
• 일주일의 후반부에 소스코드 통합 작업, 코드 리뷰를 실시한 후에 리팩터링을 실시하면 효과가 크다.
• 월 1회 클리닝 데이를 실시해 소스코드를 정비하는 시간을 정기적으로 갖는다.
• 기본기를 갖추자.
  • 줄 간경을 맞추는 것에서부터 시작한다. 알고리즘과 자료구조에 대한 이해도 기본이다. 기본을 갖추고 기교를 부리자.
• 새로운 기능을 추가해야 하는데 프로그램의 코드가 구조화되어 있지 않은 경우에는 먼저 리팩터링을 한 후에 기능을 추가한다.
  • 레거시 시스템을 오랫동안 사용할 경우 소스코드 라인이 증가하고 누더기가 된다. 리팩터링 연습의 기회로 여기자.
• 작게 시작하고 점차 확대한다.
  • 너무 많은 것을 한 번에 시도하지 마라.
  • 코드 정리에 가까운 일들부터 시작한다.(사용하지 않는 헤더 없애기, 사용하지 않는 변수 없애기, 호출되지 않는 함수 없애기, 이름 바꾸기, 함수 옮기기 등)
  • 이후 조금 더 깊이 있는 리팩터링을 시도한다. 컴파일 에러를 발생시키는 리팩터링을 시도해본다. 캡슐화를 해 의존성을 최소화하기 위한 작업들이다.(멤버 변수 캡슐화, 전역 변수들의 멤버 변수화, 전역 함수들의 멤버 함수화, 메서드 추출 등)
• 작은 단위로 나누어 프로그램을 변경하라.
  • 실수를 하더라도 쉽게 버그를 찾을 수 있다.
• 주석을 최소화한다.
  • 주석을 최소화하더라도 코드 가독성은 높아야 한다.
• 짝 리팩터링을 실시한다.
  • 동료와 함께 리팩토링 수행한다.

---

위험 기반의 테스트 전략 수립(비기능 요구사항 관련)

아키텍처와 관련된 비기능 요구사항의 위험 요소에 대한 테스트 전략은 무시되는 경우가 종종 있다. 테스트 전략을 담은 문서도 찾기 힘들다. 늦어도 분석 단계가 끝날 때까지 테스트 전략 수립이 되지 않는 프로젝트는 효과적인 테스트를 수행할 수 없어 대규모 결함이나 대형 사고가 발생할 확률이 높다.

---

개발자 채용과 경력 개발

사람이 부족하다는 것은 사실 쓸 만한 사람을 구하기 힘들다는 말이다. 전반적으로 IT 인력의 수준이 낮아진 경향도 있겠지만 열악한 근무 현장이 우수한 인력의 유입을 막는 것도 있다. 사람을 자원이 아니라 부품으로 취급하는 것도 아직 남아있다. 소프트웨어는 제조가 아니라 개발이다. 개인 역량에 따라 작업 시간과 효율 측면에서 많은 차이가 나는 것이다.

자주 범하는 개발자 채용의 오류는 일정만을 우선시해 인력을 신중히 살펴보지 않고 급하게 채용하려 한다는 점이다. 검증을 제대로 하지 않고 무조건 채용하는 경향이 있다. 이후 개발자가 일을 제대로 하지 못해 난처한 상황에 빠지게 된다. 생산성이 뛰어난 개발자가 나타날 때까지 기다리는 것이 개발자가 생산성을 갖출 때까지 기다리는 것보다 좋은 방법이다. 물론 일의 특성과 상황에 맞춰 개발자 능력 차이를 반드시 고려해야 한다.

경력 개발은 회사에서 개발자 육성의 노력이 미흡해 개발자 개인의 노력에 맡길 수밖에 없는 현실이다. 그러나 개발자도 일에 치여 자기 계발 노력을 기울이기 힘들다. 그렇다 하더라도 '내가 가만히 있어도 회사가 나의 경력을 개발해 줄 것이다'라는 생각은 하면 안 된다. 회사는 어디까지나 스폰서나 지원자로 여기고 스스로 경력개발을 해야 한다. '개인에게는 성장 비전을, 조직에게는 경쟁력을'

경력개발은 교육과 다르다. 경력개발은 단기적인 교육으로 이루어질 수 없고 채용부터 퇴사까지의 전 과정에서 직원의 성장 관점에서 바라보아야 한다.

개발자 채용

보통 지원자와 면접 시 지원자의 경험과 기술에 대해 질문은 하지만 직접 확인하지는 않는다. 그것이 요구되면 대부분 그들은 기꺼이 능력을 보여 줄 것이다.

• 일에 대한 태도
  • 특히 신입사원은 채용할 때 기술이나 경험보다 태도를 우선적으로 고려해야 한다. 그들에게 일은 태도다.
  • 일에 대한 자세, 고객 마인드, 팀워크 등을 경험 기반으로 묻고 확인한다.
• 전문기술
  • 어떤 사람이 적어도 하나의 특정 분야에 정통한 실력을 갖추었다면, 다른 분야의 기술과 지식도 마스터할 수 있는 능력이 있다고 볼 수 있다.
  • 기술은 매우 빠르게 변하므로 스스로 공부할 수 있는 자세와 능력을 갖추고 있는지 확인할 필요가 있다.
• 프로젝트 수행 사례
  • 프로젝트 중에서 기억에 남는 성공, 실패 사례를 한 가지씩 이야기하면서 왜 그런 결과가 나왔는지 원인을 분석하게 함으로써 가치관을 엿볼 수 있다.
• 팀워크
  • 팀워크가 잘 발휘한 멋진 사례 또는 반대의 사례를 들어봐야 한다.
  • 진척이 처진 동료를 도와준 사례가 있었는지, 왜 도와주었는지 등과 관련된 질문을 통해 동료들과 함께 일을 잘 수행할 수 있는지를 확인한다.
• 문서작성 능력
  • 이력서와 자기소개서에서 경험한 이력에만 초점을 두지 말고 글쓰기 능력을 살펴보아야 한다. 문서작성은 소프트웨어 개발의 중요한 요소다.
• 장단점
  • 자신의 장점과 단점을 듣고 면접 중 관찰한 것과 일치하는지 비교하게 된다.

개발자 경력개발을 돕는 회사

• 경력 스폰서링(Sponsoring)
  • 인사 관리권을 가진 경력 스폰서가 직원들을 지원한다. 이를 큰 팀이라 부르고, 큰 팀 밑에는 프로젝트나 업무 성격에 따라 작은 팀을 둔다. 작은 팀은 팀 리더가 지도하며, 인사권을 갖지는 않지만 프로젝트와 업무 성과에 대한 책임을 진다.
  • 경력 스폰서는 팀 리더의 피드백, 개인 면담 등을 통해 직원의 기질과 재능, 관심 분야와 전문성 등을 심도 있게 자문하고 중장기 경력 지원을 해준다.
• 직문 순환(Job Rotation)
  • 기업 차원에서 전반적인 경력관리를 지원하는 방법 가운데 가장 효과적인 것이다.
  • 직원의 욕망, 재능, 전문성에 부합하는 현장을 제공하는 것이 좋다. 직무와 개인의 능력을 제대로 연결해주기만 하더라도 얻을 수 있는 이점이 크다.
  • 스폰서링을 원하는 직원들에게 이력서나 자기 추천장을 쓰게 해 앞으로 어떻게 전문성을 획득할 것인지에 대해 작성하도록 한다. 자신의 기질과 재능에 대한 소견, 그리고 소견을 뒷받침하는 과거의 성취, 원하는 특정 부서나 직무의 이유 등을 담아 직문 순환에 활용한다.
  • 10퍼센트 만이라도 직원이 자신이 원하는 직무를 찾아간다면 전 직원의 절반 정도가 5년 뒤면 자신이 원하는 부서에서 자신이 선택한 직무를 수행할 것이다.
• 현장학습
  • 직무수행과 경력 개발을 연결해 경력개발의 결과를 축적, 공유, 활용함으로써 조직의 역량 강화를 목적으로 실시한다.
  • 업무일지 작성 / 프로젝트 또는 팀 단위 업무일지 공유 / 자기 계발 시간 부여

신입 개발자 단기간 육성법

• 2인 1조 프로그래밍
• 제안서 작성
• PMO(Project Management Office) 참여
  • PM이 프로젝트 관리 역할을 하지만, 중대형 프로젝트의 경우 PMO 조직을 운영해 체계적으로 관리한다. 이때 PMO 조직에 참여해 어떻게 프로젝트가 진행되는지를 경험적으로 알게 된다.
• 사내 세미나 발표

---

품질에 대한 인식 전환

제품이 정상적으로 동작하지만 고객이 원하는 제품이 아니라면 결함이다. 결함은 요구사항을 위반하는 것이다. 따라서 요구사항이 만족되지 않는 경우는 품질이 나쁜 것이다.

한때 휴대용 무선 호출기와 6 시그마 혁신 운동으로 유명한 모토로라 회사는 2012년 구글에 인수되어 스마트폰 부문은 중국 기업에 매각되어 이제 거의 자취를 감추었다. 6 시그마는 100만 개의 제품을 만들 때 불량을 단 3.4개 만을 허용한다는 무결점 혁신 운동이다. 그런데, 사실 이것을 지키는 것보다 340개의 불량을 허용하는 게 싸다. 곧 폐기될 제품에 대해 3.4개의 불량률을 지키는 게 무슨 소용인가? 모토로라는 고객의 새로운 수요에 대해 주목하지 못해 실패한 것이다. 니즈가 아닌 원츠를 공략하는 시대다.

---

요구사항 변경에 대처하는 자세

첫째, 무조건 수용 아니면 절대 불가를 외친다. 무조건 수용할 경우 변경에 소요되는 시간과 비용은 초과근무로 채워지기 쉽다. 갑과 을의 관계에서 추가 비용 지불 없이 을이 수용하는 경우가 대부분이기 때문이다.

둘째, 직원을 추가로 충원한다. 이 방법도 쉽지 않다. 비용이 추가로 들고 적절한 인력을 충원해야 하는 문제가 있다. 오히려 프로젝트 막바지에 추가된다면 커뮤니케이션 비용이 기하급수적으로 증가해 투입 전보다 오히려 일이 많아질 수 있다.

셋째, 일정을 연기한다. 일정을 연기한다고 변경을 반영하는 노력이 줄어드는 것은 아니며, 시스템 오픈 일정이 고정되어 있다면 연기가 쉽지 않을 수 있다.

넷째, 품질 수준을 낮춰 개발한다. 납기를 지키려고 품질을 희생하는 방식인데, 바람직하지 않은 방법이다.

마지막 다섯 번째, 협상(trade off)이다. 고객과 협의로 변경 영향 범위를 구체적으로 분석하고 추가로 소요되는 시간과 비용을 고려해 대안을 모색한다.

변경에 대한 7원칙

1. 변경이 프로젝트를 통제하느냐? 프로젝트가 변경을 통제하느냐? 당연히 후자가 되어야 한다.
2. 요구사항은 진화(변경)한다. 요구사항 변경은 필수 불가결한 것으로, 능동적으로 대처하라.
3. 요구사항 변경은 부정할 수 없다. 부작용을 줄이기 위해 최대한 억제할 뿐이다.
4. 요구사항 변경 관리는 변경 억제를 위한 것이 아니라 제대로 변경하기 위한 것이다.
5. 변경에 대해 심사숙고하고 가치가 있다고 판단되는 것이 그리 많지 ㅇ낳다.
6. 변경 제안을 체계적으로 하면 프로젝트에 불필요한 변경이 없어진다. 불필요한 기능 추가는 가장 큰 리스크다.
7. 요구사항에 대한 변경관리 이전에 요구사항 베이스라인이 확정되어야 한다. 산출물이 엉성한 상태에서 변경에 대한 관리는 의미가 없다.

---

성장을 위한 4가지 질문

• (성과) 누구에게나 자신 있게 말할 수 있는 자신만의 탁월한 업무 성과를 이룬 적이 있는가?
• (고객) 구체적으로 자신의 고객에게 깊은 감동을 준 적이 있는가?
• (전문성) 내가 일하는 분야에서 전문가임을 입증할 수 있는가?
• (휴면 네트워크) 일은 혼자 하는 것이 아니다. 일을 성공적으로 수행할 수 있는 휴면 네트워크가 있는가?

위 4가지 질문에 제대로 답을 할 수 있는 직장인은 많지 않다. 이 질문에 답을 준비하지 않으면 성공적인 직장생활이 어렵다. 매년 4가지 질문에 대해 답변을 해보면서, 이력서를 써서 정리해보도록 하자.

질문별 우수사례

 

• (성과) 누구에게나 자신 있게 말할 수 있는 자신만의 탁월한 업무 성과를 이룬 적이 있는가?
  • 클라우드 기반의 글로벌 의료정보 솔루션 개발 및 수출 목표 달성
  • 전사 기술 인력의 경력개발 프로그램 수립
  • 전사 프로젝트 대상 CMMI 국제 표준 획득
• (고객) 구체적으로 자신의 고객에게 깊은 감동을 준 적이 있는가?
  • XX 회사 회장상 표창
  • 매년 책 출간 후 다수 독자에게 감사 메일 받음
• (전문성) 내가 일하는 분야에서 전문가임을 입증할 수 있는가?
  • XX 회사 올해의 기술인상 수상
  • 정보처리 기술사 자격 취득
  • 그룹 역량 면접관
• (휴면 네트워크) 일은 혼자 하는 것이 아니다. 일을 성공적으로 수행할 수 있는 휴면 네트워크가 있는가?
  • 고객 및 파트너
  • 온라인 커뮤니티 멤버, 정기 메일링 독자

---

테크니컬 라이팅

테크니컬 라이팅은 특정 사람을 대상으로 특정 목적을 갖고 기술적인 주제에 대해 정보 전달하는 것을 말한다. 기술 문서 작성자의 관점이 아니라 사용자 관점에서 문서를 작성해야 한다.

글쓰기 수준을 올려야 소프트웨어 개발의 일부인 문서화 작업을 잘할 수 있다. 글쓰기 능력도 개발자의 필수 능력이라는 것이다.

테크니컬 라이팅 3원칙

1. 쉽고 간결하게 읽는 사람을 고려하라
2. 논리적으로 살이 아닌 뼈로 써라
   • 서론, 본론, 결론을 일관성 있게 전개한다.
3. 명확하게 핵심과 구체적인 사실을 써라

테크니컬 라이팅 8 계명

1. 전문용어 남발을 피할 것
   • 대체할 말이 없다면 그대로 사용하되 쉬운 말로 풀어준다.
2. 문장은 가능한 짧게 쓸 것
3. 하나의 문장에는 주어, 동사가 하나씩 들어갈 것
4. 영어나 한자를 많이 섞지 말 것
5. 피동형으로 쓰지 말 것
   • 영어 수동태 영향에서 벗어나자. 피동형은 문장이 어색할 뿐만 아니라 자신감이 없어 보인다.
6. 주어를 생략하지 말 것
7. 딱딱하게 쓰지 말고 쉽게 쓰려고 노력할 것
   • 글의 성격상 딱딱하기 쉬운데 최대한 이해하기 쉽게 쓰고 사례나 예시를 활용한다.
8. 항상 읽는 사람을 염두에 두고 글을 쓸 것

---

시간 관리

프로젝트에서의 시간 관리도 포함되겠지만, 보다 일반적인 생활의 시간을 다루고 있다.

1. 너 자신의 시간을 파악하라
   • 자신의 시간을 먼저 분석해야 한다.
   • 보통 일이 중심이 되면 자기 자신의 하루를 되돌아보지 않는다. 시간을 스스로 분석하는 것부터 시작해야 한다.
2. 하루를 재편하라
   • 불필요한 요소를 제거해라.
   • 이외에도 제거 / 감소 / 강화 / 창조 항목을 구분해야 한다.
3. 우선순위를 부여하고 소중한 일을 먼저 하라
   • 소중한 일에 가장 먼저 시간을 투자하는 것이 삶에서 성공하는 열쇠다.
   • 소중한 일에서 급한 일은 많지 않다. 사소한 것이 급한 경우가 많다. 급한 일부터 처리하면 소중한 일을 미뤄지게 되고, 후회하게 된다.
4. 활용 가능한 시간을 연속적으로 통합하라
   • 능력을 최대로 발휘하는 일의 시간의 양이 중요하다.
   • 가능한 큰 연속적인 단위로 시간을 묶는다. 10분, 30분의 조각난 자투리 시간은 업무에서는 별 쓸모가 없다.
   • 최소한의 시간을 투입하는 것은 아예 시간을 하나도 투입하지 않은 것보다 나쁘다. 아무것도 이루지 못하고 다시 시작하게 된다. 이는 낭비다.
   • 자투리 시간은 메모나 검색 등 부담 없는 활동을 하라.
5. 자동화된 습관을 들여라
   • 실천은 간단하다. 매일의 힘을 빌려 습관을 만들어라.
   • 의지는 약하나 습관은 강하다.

---

작가의 10 계명

1. 전문가로서의 뜻을 세우자. 이 일로 세상에 자신을 우뚝 세우리라는 결심을 하자. 무엇으로 유명해지고 싶은가?
2. 문제의식을 가져라. 문제의식 없이는 단순 반복적인 하루만 흘러갈 뿐이다. 반복이 재생산되면 혁신과 개선은 이루어지지 않고 발전과 성장은 기대하기 어렵다.
3. 나를 평생 먹게 살게 해 줄 기술, 필살기 하나를 연마하라. 선택한 분야에서 차별성을 만들어 내기 위해 시간과 관심을 집중 투자하자. 자신의 라이프 사이클에 가장 잘 맞는 시간대에서 자신을 훈련하라.
4. 자신만의 일하는 방식을 찾아라. 평범한 일은 없다. 다만 평범한 방식으로 수행되었을 뿐이다. 실패의 제1요소는 자신에게 맞지 않는 유망 직업을 따르는 것이다. 자신에게 맞는 일을 찾고 유일한 방식으로 서비스하라.
5. 현장의 경험을 책으로 써라. 자신의 전문성을 높이면서 동시에 동종업계의 동료와 후배를 도울 수 있다. 게다가 자신의 브랜드 파워를 갖게 해 준다. 글 쓰는 재주가 없더라도 알고 있는 것을 담담히 적어내도 훌륭한 매뉴얼이자 전공서가 될 것이다.
6. 실험하라. 전문가는 깊게 배우는 사람으로, 아예 빠져들어 연구하고 실험하고 재해석하고 다시 실험해야 한다. 실패를 두려워하지 말고 실험하라. 실패는 아주 잘 배우는 또 하나의 방법일 뿐이다.
7. 휴먼 네트워크를 만들어라. 지금 자리에 안주하지 말고 시야를 넓혀 적극적으로 인적 교류를 개척하라. 단순히 이해관계를 뛰어넘는, 깊은 관계를 지향하라.
8. 누군가의 멘토가 되어라. 누군가의 멘토가 되는 것은 가장 많이 배울 수 있고 가장 많이 얻을 수 있는 방법 중 하나다. 먼저 자신의 멘토가 되고 스스로를 믿고 따를 수 있도록 하라.
9. 나만의 커뮤니케이션 방식을 개발하라. 중요한 요소 중 하나는 '전정성'이다. 또 다른 중요한 요소는 말하는 것이 아니라 들어주는 것이다. 이 두 중요한 요소를 바탕으로 자신의 커뮤니케이션 방식을 개발하고 적용해보자. 말을 유창하게 잘하고, 다양한 표현을 사용하고, 논리적으로 말할 수 있으면 좋지만, 꼭 그렇지는 않아도 된다.
10. 혼자 공부하는 것을 즐겨라. 독학 없는 배움은 없다.

---