“IT 현장에서 마주할 수 있는 다양한 문제를 어떻게 해결해야 할까요?” 크고 작은 다양한 규모를 가진 기업과 일을 하면서 ‘시스템을 잘 모르겠다’라는 분위기를 종종 느낍니다. 이는 정보 시스템을 담당하는 입장에 있더라도 마찬가지입니다. 확실히 시스템은 개별 상황에 따라 실시해야 할 일도 천차만별입니다. 전체상을 알지 못하면 어떤 행동을 해야 하는지도 모르고, 새로운 기술이 계속 나오기 때문에 따라가지 못하는 것이 실정일지도 모릅니다. 이에 도움이 되고자 이 책을 만들게 되었습니다. 책의 3가지 특징은 다음과 같습니다. 1) 전체상을 제시하였습니다. 전체상을 잡아야 무엇을 해야 하는지 보이기 때문입니다. 각 행동을 취해야 할 프로세스 위치를 명확하게 표현하므로 현업에 계신 분들에게 도움이 될 것입니다. 2) IT팀이 해야 할 일을 제시하였습니다. 시스템의 수명주기인 기획, 개발, 도입, 유지보수, 운용, 폐기 등을 중심으로 IT팀 활동을 구체적으로 알 수 있습니다. 3) 현장에서 활용할 수 있습니다. 직접 경험한 바에서 얻은 노하우를 바탕으로 정석을 제시하면서 독자 개개인의 상황에서는 어떻게 해야 할지 연상하기 쉽도록 설명하였습니다. 많은 분이 이 책을 활용하여 다양한 문제를 해결하는 데 도움을 받으셨으면 좋겠습니다. 이 책을 추천합니다. - IT 시스템 관리 부서와 시스템을 구매하는 사업회사, 발주처 - SI 회사의 개발자, 기획자, 프로젝트 관리 매니저 - 예비 프로젝트 관리자

머리말 저자 소개 옮긴이의 글 옮긴이 소개 베타 추천사 제1장 IT팀이 가진 과제와 이 책의 역할 1.1 IT팀의 현재 상황 [현장 과제 ①] IT팀에 노하우가 축적되지 않는다 [현장 과제 ②] IT 인재 육성이 어렵다 [현장 과제 ③] 인재 부족(1인 IT팀이나 부서 겸업의 일상화) [현장 과제 ④] 시스템의 복잡화 1.2 과제에 대한 이 책의 역할 1.2.1 이 책에서 얻을 수 있는 것 1.2.2 대상 독자 1.2.3 과제 해결을 위한 이 책의 ‘내용’ 1.3 이 책의 구성 1.3.1 전체 구성 1.3.2 각 장의 구성 1.3.3 요인에 대해서 1.3.4 등장 인물에 대해서 제2장 기획 2.1 기획이란 2.1.1 조감도에서의 위치와 내용 2.2 서비스 기획 2.2.1 서비스 기획의 활동 내용 2.2.2 서비스 기획 작성 포인트 2.2.3 특히 중요한 사외 요인, 사내 요인 2.2.4 〈실패 사례〉 경영 전략과 방향성이 달라 기획에 좀처럼 승인이 나지 않는다 2.3 시스템 기획 2.3.1 시스템 기획의 활동 내용 2.3.2 시스템 기획 작성 포인트 2.3.3 특히 중요한 사외 요인, 사내 요인 2.3.4 〈실패 사례〉 IT 자산을 효과적으로 활용하지 못해 운용 비용이 몇 배로! 2.4 RFP 2.4.1 RFP 작성의 활동 내용 2.4.2 RFP 작성 포인트 2.4.3 특히 중요한 사외 요인, 사내 요인 2.4.4 〈실패 사례〉 RFP를 리뷰할 부서의 선정이 충분하지 않아 중요한 요구가 누락되어 큰 문제로 발전! 2.5 제안서 평가, 계약 2.5.1 제안서 평가, 계약의 활동 내용 2.5.2 제안서 평가, 계약 포인트 2.5.3 특히 중요한 사외 요인, 사내 요인 2.5.4 〈실패 사례〉 개발 벤더가 프로그램을 재이용, 판매했다! 2.6 서비스 평가 2.6.1 서비스 평가의 활동 내용 2.6.2 서비스 평가의 포인트 2.6.3 특히 중요한 사외 요인, 사내 요인 2.6.4 〈실패 사례〉 기존 시스템을 대체하고자 서비스 이용을 선택했으나 작업량이 많아 업무가 원만하게 이루어지지 않는다! 2.7 정리하기 제3장 시스템 개발 3.1 ‘시스템 개발’이란? 3.1.1 조감도에서의 위치와 내용 3.2 프로젝트 계획 3.2.1 프로젝트 계획 활동 내용 3.2.2 프로젝트 계획서 작성 포인트 3.2.3 특히 중요한 사외 요인, 사내 요인 3.2.4 〈실패 사례〉 릴리즈 시점을 너무 세분화한 나머지 비용은 오르고 품질은 내려갔다! 3.3 요건 정의 3.3.1 요건 정의 활동 내용 3.3.2 요건 정의 작성 및 리뷰 시의 포인트 3.3.3 특히 중요한 사외 요인, 사내 요인 3.3.4 〈실패 사례〉 ‘지금처럼’이라면 ‘지금’을 알 수 없는 개발 벤더는 요건을 설계에 반영할 수 없다! 3.3.5 〈실패 사례〉 비기능 요건이 구체적으로 정의되지 않았다! 시스템 테스트에서 개발 벤더와 다투게 되는 사태 발생 3.4 설계(기본 설계, 상세 설계) 3.4.1 설계(기본 설계, 상세 설계) 활동 내용 3.4.2 설계(기본 설계, 상세 설계)의 리뷰 포인트 3.4.3 특히 중요한 사외 요인, 사내 요인 3.4.4 〈실패 사례〉 항목이 일치하지 않고 통일성이 없는 설계가 이루어졌다! 3.5 개발, 벤더 테스트 3.5.1 개발, 벤더 테스트의 활동 내용 3.5.2 개발, 벤더 테스트의 리뷰 포인트 3.5.3 특히 중요한 사외 요인, 사내 요인 3.5.4 〈실패 사례〉 코드 규약을 따르지 않고 구축해서 유지 보수 단계에서 대혼란이 발생했다! 3.5.5 〈실패 사례〉 단위 테스트에서 발견해야 할 버그가 통합 테스트에서 대량으로 발생하여 일정이 대폭 지연되었다 3.6 사용자 수용 테스트 3.6.1 사용자 수용 테스트의 활동 내용 3.6.2 사용자 수용 테스트의 포인트 3.6.3 특히 중요한 사외 요인, 사내 요인 3.6.4 〈실패 사례〉 중요 기능 확인을 나중으로 미룬 결과, 버그를 제때에 개선하지 못했다 3.7 업무 훈련 3.7.1 업무 훈련의 활동 내용 3.7.2 업무 훈련 포인트 3.7.3 특히 중요한 사외 요인, 사내 요인 3.7.4 〈실패 사례〉 설명할 순서나 내용에 미비점이 있어 사내 설명회가 혼란에 빠졌다! 3.8 이행 리허설, 실제 이행 3.8.1 이행 리허설, 실제 이행의 활동 내용 3.8.2 이행 리허설, 실제 이행의 포인트 3.8.3 특히 중요한 사외 요인, 사내 요인 3.8.4 〈실패 사례〉 지속 가능한 계획이 없다! 장애 복구에 시간이 걸려 업무에 영향을 미쳤다 3.9 정리하기 제4장 서비스 도입 4.1 ‘서비스 도입’이란 4.1.1 조감도에서의 위치와 내용 4.2 프로젝트 계획 4.3 서비스 도입 설계 4.3.1 서비스 도입 설계 시 활동 내용 4.3.2 서비스 도입 설계의 포인트 4.3.3 특히 중요한 사외 요인, 사내 요인 4.3.4 〈실패 사례〉 백업 수준이 사내 규칙에 미달하여 추가적인 시스템 개발을 해야 한다! 4.4 서비스 설정, 확인 4.4.1 서비스 설정, 확인 시 활동 내용 4.4.2 서비스 설정 시 포인트 4.4.3 특히 중요한 사외 요인, 사내 요인 4.4.4 〈실패 사례〉 계산 방법이 달라서 산출 결과가 이전과 달라졌다! 4.5 업무 훈련 4.5.1 업무 훈련 시 활동 내용 4.5.2 업무 훈련 시 포인트 4.5.3 특히 중요한 사외 요인, 사내 요인 4.5.4 〈실패 사례〉 많은 인원으로 업무 훈련을 시작했는데 서비스에 접속하지 못하게 됐다! 4.6 이행 리허설, 실제 이행 4.6.1 이행 리허설, 실제 이행의 활동 내용 4.6.2 이행 리허설, 실제 이행 시 포인트 4.6.3 특히 중요한 사외 요인, 사내 요인 4.6.4 〈실패 사례〉 데이터 클리닝 범위에 누락이 있어 테스트 데이터가 남은 상태로 업무를 시작했다! 4.6.5 〈실패 사례〉 데이터 이행이 끝나지 않아, 일정 기간 업무가 복잡해졌다! 4.7 정리하기 제5장 유지 보수 5.1 ‘유지 보수’란? 5.1.1 조감도에서의 위치와 내용 5.2 유지 보수의 전체 설계 5.2.1 유지 보수 전체 설계 시 활동 내용 5.2.2 유지 보수 전체 설계 시 포인트 5.2.3 특히 중요한 사외 요인, 사내 요인 5.2.4 〈실패 사례〉 갱신해야 할 문서가 명확하지 않다! 5.3 유지 보수 계약 체결 5.3.1 유지 보수 계약 체결 시 활동 내용 5.3.2 유지 보수 계약 체결 시 포인트 5.3.3 특히 중요한 사외 요인, 사내 요인 5.3.4 〈실패 사례〉 영업일에 대한 정의가 애매하여 장애 대응을 받지 못했다 5.4 우선 순위 두기, 안건 실시 5.4.1 우선 순위 두기, 안건 실시 활동 내용 5.4.2 우선 순위 두기, 안건 실시의 포인트 5.4.3 특히 중요한 사외 요인, 사내 요인 5.4.4 〈실패 사례〉 안건 관리 부족으로 인해 병행 개발에 실패했다! 결국 장애가 다발하는 사태로 이어졌다 5.4.5 〈실패 사례〉 갈라파고스화1된 독자적인 유지 보수 개발 때문에 후임에게 민폐를 끼쳤다! 5.5 평가, 개선 5.5.1 평가, 개선의 활동 내용 5.5.2 평가, 개선 포인트 5.5.3 특히 중요한 사외 요인, 사내 요인 5.5.4 〈실패 사례〉 인력 부족으로 유지 보수 품질이 악화되어 장애가 다발했다 5.6 정리하기 제6장 운용 6.1 ‘운용’이란? 6.1.1 조감도에서의 위치와 내용 6.2 운용 계획 6.2.1 운용 계획 시 활동 내용 6.2.2 운용 계획 작성 포인트 6.2.3 특히 중요한 사외 요인, 사내 요인 6.2.4 〈실패 사례〉 운용 수용에 대한 설명을 하지 않아 다툰 끝에 매일같이 잔업을 하게 됐다 6.3 이벤트 관리 6.3.1 이벤트 관리의 대표적인 관리 대상 6.3.2 이벤트 관리 시 포인트 6.3.3 특히 중요한 사외 요인, 사내 요인 6.3.4 〈실패 사례〉 외부 서비스 중단을 파악하지 못해 시스템 오류가 다발했다! 6.4 시스템 관리 6.4.1 시스템 관리 시 대표적인 관리 대상 6.4.2 시스템 관리 시 포인트 6.4.3 특히 중요한 사외 요인, 사내 요인 6.4.4 〈실패 사례〉 하드웨어의 연장 보증을 파악하지 않아 비용이 부족해졌다! 6.5 장애 대응 6.5.1 장애 대응 시 활동 내용 6.5.2 장애 대응 시 포인트 6.5.3 특히 중요한 사외 요인, 사내 요인 6.5.4 〈실패 사례〉 안이하게 재실행한 결과, 데이터 불일치로 인해 2차 장애가 발생했다! 6.6 평가, 개선 6.6.1 평가, 개선 시 활동 내용 6.6.2 평가, 개선 시 포인트 6.6.3 특히 중요한 사외 요인, 사내 요인 6.6.4 〈실패 사례〉 평가에 사용하지 못하는 자료만 존재하기에, 자료를 수집하기 위한 개선점이 발생했다 6.7 정리하기 제7장 폐기 7.1 ‘폐기’란? 7.1.1 조감도에서의 위치와 내용 7.2 프로젝트 계획 7.3 폐기 설계 7.3.1 폐기 설계 시 활동 내용 7.3.2 폐기 설계 시 포인트 7.3.3 특히 중요한 사외 요인, 사내 요인 7.3.4 〈실패 사례〉 어느새 누군가가 데이터를 이용함으로써 시스템 폐기와 동시에 트러블이 발생했다 7.4 폐기 실시 7.4.1 폐기 실시의 활동 내용 7.4.2 폐기 실시의 포인트 7.4.3 특히 중요한 사외 요인, 사내 요인 7.4.4 〈실패 사례〉 외부 서비스에 한 의뢰가 거절당해 관계없는 타사에 영향이 발생했다 7.5 정리하기 제8장 매니지먼트 8.1 ‘매니지먼트’란? 8.1.1 조감도에서의 위치와 내용 8.2 매니지먼트의 기본 8.2.1 매니지먼트의 기본이란? 8.3 각 단계의 ‘계획 시’에 검토해야 할 것 [Plan] 8.3.1 검토해야 할 것은 무엇인가? 8.3.2 각 단계의 ‘계획 시’에 주의해야 할 포인트 8.3.3 특히 중요한 사외 요인, 사내 요인 8.3.4 실패 사례 끝냈다고 생각한 과제가 다시 발생했다! 8.4 각 단계의 ‘실행 시’에 확인해야 할 것 [Do] 8.4.1 확인해야 할 것은 무엇인가? 8.4.2 각 단계의 ‘실행 시’에 주의해야 할 포인트 8.4.3 특히 중요한 사외 요인, 사내 요인 8.4.4 〈실패 사례〉 개발 벤더를 너무 나무랐더니 최소한의 대응만 해주다가 품질이 나쁜 시스템이 탄생했다 8.5 각 단계의 ‘평가 시’에 확인해야 할 것 [Check] 8.5.1 평가해야 할 것은 무엇인가? 8.5.2 각 단계의 ‘평가 시’에 주의해야 할 포인트 8.5.3 특히 중요한 사외 요인, 사내 요인 8.5.4 〈실패 사례〉 이전 단계에서 좋지 않은 부분이 개선되지 않아서 다음 단계에까지 이어졌다! 8.6 각 단계의 ‘개선 시’에 검토해야 할 것 [Action] 8.6.1 개선해야 할 것은 무엇인가? 8.6.2 각 단계의 ‘개선 시’에 주의해야 할 포인트 8.6.3 특히 중요한 사외 요인, 사내 요인 8.6.4 〈실패 사례〉 다른 안건의 개선점이 공유되지 않아 유지 보수 안건에서 같은 실수가 발생했다! 8.7 정리하기 부록 도움이 되는 프레임워크 참고문헌 맺음말 찾아보기