2017.04.27

기고 | 클라우드 컨설턴트를 볼 때 6가지 체크리스트

David Taber | CIO
엉터리 클라우드 컨설턴트와 능력 있는 클라우드 컨설턴트를 어떻게 구분할까? 적절한 체크리스트가 없다면 이런 문제가 부딪힐 수 있다. 여기 몇 가지 간단한 체크리스트가 있으니 참고하기 바란다.



우리는 개인위생 습관이 필요하다는 사실을 알고 있지만 꾸준히 실천하지는 않는다(어제 치실질을 3번 했나?). 그리고 우리가 추구하는 사회적 관행이 존재하며 심지어 그 관행으로 사람을 평가하기도 한다. 하지만 대부분 기업이 IT에 관해서는 주요 행동과 정책을 기준으로 컨설턴트를 심사하는 것 같지는 않다.

IT습관과 내부 정책은 프로젝트 성공 가능성에 중대한 차이를 낳기 때문에 좋은 현상은 아니다.

아래에 제시한 몇 가지 정책 문제 목록은 일반적인 클라우드 컨설턴트와 세일즈포스 컨설턴트 심사 기준에 포함돼야 한다. 현재 컨설턴트가 아래 체크리스트의 모든 항목을 준수하는지가 꼭 필요한 것은 아니지만 여기에서 파생되는 정책이 무엇이든 계약 체결에 앞서 건전한 대화를 나눌 기회다. 다양한 정책에 대한 탄탄한 근거가 있다면 알아야 하겠지만 “우리는 너무 게을러서 매번 그럴 수 없다”는 경우도 알아야 한다.

• 시스템 접근 – 프로젝트 시작부터 종료까지 컨설턴트는 그 어떤 직원, 계약자, 외부 업체의 애플리케이션이나 데이터 소스와도 공유하지 않는 로그인이 필요하다고 강조해야 한다. 여러 가지 이유로 이 정책은 컨설턴트 자신과 고객에게 이익이 되며, 혹시라도 프로젝트가 잘 되지 않을 때 책임을 면하는 데 도움이 된다. 컨설턴트가 이를 강조하지 않으면 그 이유를 이해해야 한다. 컨설턴트는 자신들이 다루는 각 시스템에서 복수의 로그인(개발, 통합, 시스템 구성용으로 분리)을 요구하는 것에 대해 추가 점수를 얻는다.

• 데이터 및 시스템 구성 백업 – 외부인이 시스템에 진입하도록 허용하기에 앞서 시스템 데이터 및 메타데이터 전체를 백업해야 한다. 그 실행 여부에 상관없이 컨설턴트는 우선 영향 분석 속도를 올리고 파괴적 오류의 위험을 낮추기 위해 취급하는 각 시스템에 대한 자신만의 백업을 작성해야 한다. 이것이 발견 단계에 포함돼 있지 않은 경우 상당한 점수를 차감해야 한다. 하지만 컨설턴트가 각 스프린트(Sprint) 마지막에 자신만의 백업을 작성하는 경우 추가 점수를 얻는다.

• 샌드박스(Sandbox) – 시스템 개발, 통합, 마이그레이션 작업의 경우 (복수의) 샌드박스가 효율적이며, 이는 안전한 작업을 위해서도 꼭 필요하다. 그렇다. 반드시 플랫폼 업체에 비용을 지불해야 하지만 전반적인 프로젝트 비용과 위험이 낮아지게 될 것이다. 컨설턴트는 복수의 샌드박스(일부 전체 데이터)를 요구하는 경우 추가 점수를 얻으며 모든 샌드박스, 스테이징(Staging) 영역, 생산 시스템에서 GIT 또는 기타 구성 관리 시스템을 사용할 계획을 수립하는 경우 더 많은 추가 점수를 얻는다.

• 구성 로그 – 모두가 알고 있듯이 개발자는 문서 작성이나 코드에 관한 설명을 싫어한다. 세일즈포스는 자체적으로 구성과 코드 변경의 일부를 추적하기 때문에 세일즈포스 컨설턴트는 공짜로 1점을 얻는다. 하지만 그 어떤 시스템도 마음을 읽을 수 없기 때문에 시스템에서 작업하는 모든 사람이 매시간 자신이 하는 일에 대한 개인적인 로그를 유지하는 것이 중요하다. 시간 카드에 주석을 기입하거나 개별적인 텍스트 또는 스프레드시트 문서로 가능하지만 사용하는 매체에 상관없이 기관 메모리의 중요한 부분이다. 기록해 두지 않으면 앞으로 6주 후에는 그 누구도 누가, 언제, 왜, 어떤 변경사항을 적용했는지 기억하지 못할 것이다. 이런 따분한 일을 하지 않으면 디자인 결정을 역추적하거나 단순한 월간 송장을 정당화하는 것도 어려워지기 때문에 매시간 30초 정도는 투자할 만한 가치가 있다. 컨설턴트의 프로세스가 이를 지원하는지 파악하고 90일 정도마다 SFDC로그 파일을 백업하는 경우 추가 점수를 주자(이것들은 자동으로 백업되지 않으며 시간이 지나면 잊어버리게 된다). 구성 로그를 모든 프로젝트 참가자가 볼 수 있도록 게시하는 경우 추가 점수를 줘야 한다.

• 프로젝트 의사소통 매체 및 SLA – 어느 프로젝트나 현장 및 현장 외 자원을 활용하며 역외 자원을 활용하는 경우도 많다. 전화와 이메일이 일반적이지만 프로젝트 수명 동안에는 팀들이 여러 위치에서 협업하기 어렵다. 컨설턴트는 고객 습관을 수용해야 하지만 모두가 유의미한 의사소통을 위해 (구글 스프레드시트처럼 원시적이거나 프로젝트 관리 포탈처럼 정교한) 프로젝트 협업 플랫폼을 사용하도록 지시해야 한다. 또한 컨설턴트는 7일 24시간 기준으로 의사소통 기대 응답 시간을 밝혀야 한다(물론, 그 누구도 일요일 오전 3시에 발행된 조치 항목에 대해 즉각적으로 응답하기를 기대하지는 않지만, 모두가 적어도 월요일 오후 3시까지 응답할 것이라고 예상하지는 않을 것을 알아야 한다).

• 끝맺음 – 대부분 컨설턴트는 프로젝트 중 끝맺음을 기대한다고 말하겠지만 그 ‘시기’와 ‘방법’이 정말 중요하다. 최소한 변경 주문 또는 프로젝트 완료 시 명시적인 끝맺음이 있어야 한다. 또한 현명한 컨설턴트는 발견 종료 시(“이것들이 요건이며 우선순위다”고 밝히고) 중요한 프로젝트 마일스톤(‘기능 완료’ 또는 ‘데이터 가져옴’ 등, 애자일 프로젝트의 경우 각 스프린트 종료 시) 시 명시적인 끝맺음을 요구해야 한다.

자명한 사실이다
바람직한 컨설턴트 행동과 습관에 관한 포괄적인 목록은 아니다. 하지만 이제 이것을 읽었으니 분명 스스로 “여기에서 핵심은 무엇이며 상식이 아닌가?”고 자문할 것이다. 그리고 그 질문의 답이 이 글의 핵심이다. 상식일 수는 있지만 일반적인 습관은 아니다.

*David Taber는 'Salesforce.com Secrets of Success'의 저자이자 SalesLogistix의 CEO이다. 세일즈포스닷컴 인증 컨설턴트로, 주로 CRM을 이용한 비즈니스 프로세스 향상 관련 컨설팅을 제공한다. ciokr@idg.co.kr
 

2017.04.27

기고 | 클라우드 컨설턴트를 볼 때 6가지 체크리스트

David Taber | CIO
엉터리 클라우드 컨설턴트와 능력 있는 클라우드 컨설턴트를 어떻게 구분할까? 적절한 체크리스트가 없다면 이런 문제가 부딪힐 수 있다. 여기 몇 가지 간단한 체크리스트가 있으니 참고하기 바란다.



우리는 개인위생 습관이 필요하다는 사실을 알고 있지만 꾸준히 실천하지는 않는다(어제 치실질을 3번 했나?). 그리고 우리가 추구하는 사회적 관행이 존재하며 심지어 그 관행으로 사람을 평가하기도 한다. 하지만 대부분 기업이 IT에 관해서는 주요 행동과 정책을 기준으로 컨설턴트를 심사하는 것 같지는 않다.

IT습관과 내부 정책은 프로젝트 성공 가능성에 중대한 차이를 낳기 때문에 좋은 현상은 아니다.

아래에 제시한 몇 가지 정책 문제 목록은 일반적인 클라우드 컨설턴트와 세일즈포스 컨설턴트 심사 기준에 포함돼야 한다. 현재 컨설턴트가 아래 체크리스트의 모든 항목을 준수하는지가 꼭 필요한 것은 아니지만 여기에서 파생되는 정책이 무엇이든 계약 체결에 앞서 건전한 대화를 나눌 기회다. 다양한 정책에 대한 탄탄한 근거가 있다면 알아야 하겠지만 “우리는 너무 게을러서 매번 그럴 수 없다”는 경우도 알아야 한다.

• 시스템 접근 – 프로젝트 시작부터 종료까지 컨설턴트는 그 어떤 직원, 계약자, 외부 업체의 애플리케이션이나 데이터 소스와도 공유하지 않는 로그인이 필요하다고 강조해야 한다. 여러 가지 이유로 이 정책은 컨설턴트 자신과 고객에게 이익이 되며, 혹시라도 프로젝트가 잘 되지 않을 때 책임을 면하는 데 도움이 된다. 컨설턴트가 이를 강조하지 않으면 그 이유를 이해해야 한다. 컨설턴트는 자신들이 다루는 각 시스템에서 복수의 로그인(개발, 통합, 시스템 구성용으로 분리)을 요구하는 것에 대해 추가 점수를 얻는다.

• 데이터 및 시스템 구성 백업 – 외부인이 시스템에 진입하도록 허용하기에 앞서 시스템 데이터 및 메타데이터 전체를 백업해야 한다. 그 실행 여부에 상관없이 컨설턴트는 우선 영향 분석 속도를 올리고 파괴적 오류의 위험을 낮추기 위해 취급하는 각 시스템에 대한 자신만의 백업을 작성해야 한다. 이것이 발견 단계에 포함돼 있지 않은 경우 상당한 점수를 차감해야 한다. 하지만 컨설턴트가 각 스프린트(Sprint) 마지막에 자신만의 백업을 작성하는 경우 추가 점수를 얻는다.

• 샌드박스(Sandbox) – 시스템 개발, 통합, 마이그레이션 작업의 경우 (복수의) 샌드박스가 효율적이며, 이는 안전한 작업을 위해서도 꼭 필요하다. 그렇다. 반드시 플랫폼 업체에 비용을 지불해야 하지만 전반적인 프로젝트 비용과 위험이 낮아지게 될 것이다. 컨설턴트는 복수의 샌드박스(일부 전체 데이터)를 요구하는 경우 추가 점수를 얻으며 모든 샌드박스, 스테이징(Staging) 영역, 생산 시스템에서 GIT 또는 기타 구성 관리 시스템을 사용할 계획을 수립하는 경우 더 많은 추가 점수를 얻는다.

• 구성 로그 – 모두가 알고 있듯이 개발자는 문서 작성이나 코드에 관한 설명을 싫어한다. 세일즈포스는 자체적으로 구성과 코드 변경의 일부를 추적하기 때문에 세일즈포스 컨설턴트는 공짜로 1점을 얻는다. 하지만 그 어떤 시스템도 마음을 읽을 수 없기 때문에 시스템에서 작업하는 모든 사람이 매시간 자신이 하는 일에 대한 개인적인 로그를 유지하는 것이 중요하다. 시간 카드에 주석을 기입하거나 개별적인 텍스트 또는 스프레드시트 문서로 가능하지만 사용하는 매체에 상관없이 기관 메모리의 중요한 부분이다. 기록해 두지 않으면 앞으로 6주 후에는 그 누구도 누가, 언제, 왜, 어떤 변경사항을 적용했는지 기억하지 못할 것이다. 이런 따분한 일을 하지 않으면 디자인 결정을 역추적하거나 단순한 월간 송장을 정당화하는 것도 어려워지기 때문에 매시간 30초 정도는 투자할 만한 가치가 있다. 컨설턴트의 프로세스가 이를 지원하는지 파악하고 90일 정도마다 SFDC로그 파일을 백업하는 경우 추가 점수를 주자(이것들은 자동으로 백업되지 않으며 시간이 지나면 잊어버리게 된다). 구성 로그를 모든 프로젝트 참가자가 볼 수 있도록 게시하는 경우 추가 점수를 줘야 한다.

• 프로젝트 의사소통 매체 및 SLA – 어느 프로젝트나 현장 및 현장 외 자원을 활용하며 역외 자원을 활용하는 경우도 많다. 전화와 이메일이 일반적이지만 프로젝트 수명 동안에는 팀들이 여러 위치에서 협업하기 어렵다. 컨설턴트는 고객 습관을 수용해야 하지만 모두가 유의미한 의사소통을 위해 (구글 스프레드시트처럼 원시적이거나 프로젝트 관리 포탈처럼 정교한) 프로젝트 협업 플랫폼을 사용하도록 지시해야 한다. 또한 컨설턴트는 7일 24시간 기준으로 의사소통 기대 응답 시간을 밝혀야 한다(물론, 그 누구도 일요일 오전 3시에 발행된 조치 항목에 대해 즉각적으로 응답하기를 기대하지는 않지만, 모두가 적어도 월요일 오후 3시까지 응답할 것이라고 예상하지는 않을 것을 알아야 한다).

• 끝맺음 – 대부분 컨설턴트는 프로젝트 중 끝맺음을 기대한다고 말하겠지만 그 ‘시기’와 ‘방법’이 정말 중요하다. 최소한 변경 주문 또는 프로젝트 완료 시 명시적인 끝맺음이 있어야 한다. 또한 현명한 컨설턴트는 발견 종료 시(“이것들이 요건이며 우선순위다”고 밝히고) 중요한 프로젝트 마일스톤(‘기능 완료’ 또는 ‘데이터 가져옴’ 등, 애자일 프로젝트의 경우 각 스프린트 종료 시) 시 명시적인 끝맺음을 요구해야 한다.

자명한 사실이다
바람직한 컨설턴트 행동과 습관에 관한 포괄적인 목록은 아니다. 하지만 이제 이것을 읽었으니 분명 스스로 “여기에서 핵심은 무엇이며 상식이 아닌가?”고 자문할 것이다. 그리고 그 질문의 답이 이 글의 핵심이다. 상식일 수는 있지만 일반적인 습관은 아니다.

*David Taber는 'Salesforce.com Secrets of Success'의 저자이자 SalesLogistix의 CEO이다. 세일즈포스닷컴 인증 컨설턴트로, 주로 CRM을 이용한 비즈니스 프로세스 향상 관련 컨설팅을 제공한다. ciokr@idg.co.kr
 

X