개발자들은 보통 예산과 일정 및 비즈니스 요구사항이 정해지면 애플리케이션을 성공적으로 개발하려고 한다. 하지만 개발 시작에서부터 최종 작업까지는 넘어야 할 산이 많다.

프로젝트 수행에서는 애플리케이션에서 제품으로 넘어 가는 과정에서 사용자들의 교육도 잘 되어야 함은 물론이며, 애플리케이션에 대해서도 충분히 이해해야 하는 것들과 같이 예상하지 못한 힘든 시간이 든다.

힘든 시간은 엄청난 스트레스와 수면부족을 수반하기도 한다. 다음은 애플리케이션의 커스터마이징함에 있어 차분히 관리할 수 있게 하는 팁을 정리해 보았다.

#1. 하드웨어를 확인하라.
적절한 장비가 지원되고 구성은 적절한지 확인하라. 서버와 네트워크를 포함하여 같은 리소스를 사용한 다른 애플리케이션에 익숙한지 확인하고, 이러한 애플리케이션이 어떻게 하드웨어를 공유하는지 이해하라.

#2. 서버들은 같은지 혹은 가능한 같은 서버인지를 확인하라.
개발, QA, 생산 환경 셋업을 위해 가능한 비슷하게 하려고 노력하라. 별것 아닌 것 같은 것마저도, 다르다면 기록을 하라. 실행 프로세스에서의 하찮은 일 때문에 그 일에 매달리는 것은 짜증나는 일이다.

#3. 시스템 관리자와 친하게 지내라.
시스템 관리자들에게 제대로 된 문서화 교육을 하라. 그들은 배포를 중요하게 생각하며, 사용자 커뮤니티에 관하여 높은 지식을 가지고 있다. 그들은 여러분들에게서 중요한 피드백을 듣기를 원하며, 그렇지 않은 경우에는 조심해야 한다.

#4. 간단한 롤백계획을 만들어라.
여러분의 애플리케이션이 기존시스템의 교체나 업그레이드인지 아닌지에 관계없이, 신중하게 유저가 그들의 비즈니스 크리티컬 애플리케이션 없이 방치되지 않는 것을 확실히 하는 롤백(rollback) 계획을 구성하라.

유저 그룹이 할 일이 아무것도 없는 것보다 관리와의 단절이 더욱 문제이다. 제대로 설치되어 작동이 잘 된다 해도, 여러분의 애플리케이션에 대한 반발로 매출 저하가 여러분의 애플리케이션 때문이라고 보고 될 것이다.

#5. 잘 작성된 문서
이 부분에 대해서는 합당한 이유와 함께 스트레스도 많다. 완벽한 시스템 문서는 애플리케이션이 라이브 되고 나면, 애플리케이션 유지보수 담당자들이 애플리케이션을 지원하는 데 도움이 된다. 디자인이 잘 되어야 하고, 직접적인 도움이 되어야 하고, 유저들의 애플리케이션 이해에 도움이 될 수 있는 가이드여야 하며, 유저가 받아들일 수 있게 만들어야 한다.

#6. 데이터를 확인하라.
프로젝트를 위해 데이터를 적절히 정제하고, 규격에 맞게 하라. 또, 한 환경에서 다음 환경까지 사용할 데이터 덤프를 담아 두기 위해 좋은 프로세스인지 확인하라. 주말이나 저녁에 이러한 활동을 실행하는 것이 필요하다면, 이것으로 발생할 수 있는 스케줄링 문제를 인식하고 있어야 한다.

#7. 디플로이먼트(deployment) 프로세스 QA
애플리케이션에 QA 기능을 추가하는 것에 디플로이먼트 프로세스 자체가 적절하게 조사되었는지를 확인하라. 애플리케이션 배포의 처음은 대부분 QA 환경에서 이루어질 것이다. 그런 다음에 데이터베이스의 초기화 및 구성, 애플리케이션의 설치 초기 및 구성 등과 같은 일련의 단계에 따라 이루어진다. 디플로이먼트 프로세스를 아는 것은 제품화 과정의 핵심 성공 요소일지도 모른다.

#8. 훌륭한 메타데이터를 만들라.
애플리케이션에서 사용되는 데이터에서 리포트를 만드는 유저에게는 좋은 메타데이터 리포지토리는 중요하다. 어떤 필드와 테이블을 사용하고, 어떻게 사용되는지에 관한 데이터베이스 도큐멘테이션은 유저의 특별한 리포트 작성에 도움이 될 것이다.

좋은 메타데이터는 잠재적인 데이터 문제의 문제해결에 도움이 될 것이다. 어떤 애플리케이션, 데이터베이스에서 발생한 문제의 공유에 대한 생각은 현실적이다. 좋은 메타데이터는 여러분이나 데이터베이스 운영자에게 문제 발생시 곧바로 문제 해결 방법을 구상할 수 있게 도움을 줄 것이다.

#9. 버전 컨트롤 규정
버전 컨트롤 시스템과 결합되는 버그 리포트와 피드백이 들어 있는 좋은 버전 컨트롤 프로세스가 있는지 확인하라.

#10. 리에종(Liaison) 선택
애플리케이션이 적절하게 돌아가는지 유저에게 유지보수에 대한 확신을 줄 수 있는 리에종/커뮤니케이션 코디네이터 역할을 할 수 있는 비즈니스 전문가, 엔지니어, PM, 시스템 운영자 중 한 명을 지정하여 유저가 관심 있어 하는 부분에 신뢰감을 줄 수 있게 한다.

그들이 가져 오는 문제가 해결될 때까지 정확하게 피드백을 하고, 유저와 함께 연락을 유지해야 한다. 이것은 자주 일어나는 개발 방해에서 개발자를 보호하게 된다.

#11: 활발한 피드백을 요구하라.
피드백, 전문적 요구, 버그 리포트를 자동화 되고 사용하기 쉽게 만들어야 한다.

#12: 노스트라다무스처럼 하라.
애플리케이션의 장점과 단점에 대해 예측하려고 노력하라. 수정, 보강에 대한 계획을 만들고 기록하여 유저의 피드백과 기록한 정보를 비교해 보고, 다음 프로젝트에서 어떻게 하면 더 좋게 디자인 할 수 있는지를 구상하라.

#13: 스트레스 풀기
프로젝트와 무관한 일을 하라. 수영을 엄청 하든지, 일정을 맞춰 조금의 보너스를 받는 것처럼 주말에 여행을 떠나보라. 자기 자신을 업데이트 시켜라. 애플리케이션 라이프 사이클에 비판적인 부분에 대한 여러분의 스트레스 수준을 억제하는 데 필요한 무엇이든 하라.

예기치 않은 일이 일어날 수 있다는 것을 기억하라.
마지막으로, 제품의 변화에 시간이 걸린다는 것에 유의하는 것은 중요한 일이다. 생산에의 변천에 시간이 걸린다는 것을 주의하는 것은 중요하다. 이쪽 유저 인터페이스를 약간 바꾸고, 저쪽 데이터베이스는 정제를 해야 하는 등의 변화가 발생한다.

새로운 애플리케이션을 개발할 때 잘 모르는 문제나 예측할 수 없는 문제가 종종 엄청난 화를 만들어낸다. 따라서 여러분이 할 수 있는 것은 계획을 잘 만들어서, 최선을 다하는 것이다. @