웹 애플리케이션 유지 관리가 더 중요해야 하는 이유

전통적인 소프트웨어 개발자는 우리에게 비밀을 숨기고 있습니다. 논란의 여지가 없는 사실이기도 하다. 그것은 그들의 비즈니스 모델의 일부입니다.

무료 syslog 관리자와 같이 직장이나 비즈니스에서 우리 모두가 매일 사용하는 도구를 작성하는 고급 엔터프라이즈 소프트웨어 공급업체 또는 소규모 소프트웨어 하우스에 대해 이야기하는 것은 중요하지 않습니다. 바로 앞과 중앙에 있습니다. 그들이 숨기지 않고 우리가 지불하는 데 익숙해진 추가 비용.

그래서 이 비밀은 무엇입니까?

글쎄요, 많은 전통적인 소프트웨어 공급업체는 초기 판매보다 자신이 작성한 소프트웨어를 유지 관리함으로써 더 많은 돈을 벌고 있습니다 .

확신하지 못하셨나요?

"총 소유 비용(Total Cost of Ownership)"이라는 용어를 빠르게 검색하면 Gartner에서 제공하는 것과 같은 유사한 정의가 많이 제공됩니다(강조 사항).

[TCO는] 애플리케이션 을 구현, 운영, 지원 및 유지 관리 또는 확장하고 폐기하는 데 드는 비용 입니다.

또한 Stanford 대학의 이 백서에서는 일반적으로 소프트웨어 제품 TCO의 60~90%에 해당하는 유지 관리 비용이 발생한다고 주장합니다.

그것은 1분 동안 가라앉게 할 가치가 있습니다. 그들은 지속적인 지원 및 유지 관리 계획을 판매함으로써 초기 구매 가격보다 훨씬 더 많은 돈을 벌고 있습니다.

우리는 유지 보수를 강요하지 않습니다

내가 보기에 문제는 웹 개발 업계에서 웹 애플리케이션 유지 관리가 우리가 집중하는 것이 아니라는 것입니다. 월간 보유자라는 아이디어가 마음에 들어서 제안서에 넣을 수도 있지만 간단한 하우스키핑 작업이나 새로운 기능 요청을 다룰 것입니다.

고객이 우리가 필수적인 개선으로 보는 것에 대해 비용을 지불하기를 원할 것이라고 확신하지 못하기 때문에 이후 반복을 위해 견적 내에 필수 업그레이드 및 최적화를 숨기는 것은 전례가 없습니다. 우리는 그들을 뒷문을 통해 들여보냅니다. 다시 말해서, 우리는 더 전통적인 소프트웨어와 마찬가지로 이러한 응용 프로그램을 유지 관리해야 하는 개방적이고 투명하지 않습니다.

이유를 불문하고 우리가 미래를 위해 문제를 축적하고 있음이 분명해지고 있습니다. 우리가 구축하고 있는 소프트웨어 애플리케이션은 장기적으로 여기에 있습니다 . 우리는 전통적인 소프트웨어 공급업체처럼 생각해야 합니다. 우리 소프트웨어는 지금부터 10년 또는 15년 동안 계속 실행될 것이며 잘 유지되어야 합니다.

그렇다면 이것을 어떻게 바꿀 수 있습니까? 업계로서 우리 모두는 고객이 안전하게 보호되어 최신 상태로 유지되도록 어떻게 보장합니까? 마찬가지로, 유지 관리 파이의 일부를 차지하는 방법은 무엇입니까?

유지보수란 무엇입니까?

2012년의 효과적인 애플리케이션 유지 관리(Effective Application Maintenance) 논문에서 Heather Smith와 James McKeen은 유지 관리를 다음과 같이 정의합니다.

애플리케이션을 새 서버로 이식하거나, 다른 운영 체제와 인터페이스하고, 최신 릴리스로 업그레이드하거나, 세금 테이블을 변경하거나, 새로운 규정을 준수하려면 유지 관리가 필요합니다. 결과적으로 유지 관리는 생산성 및/또는 비용 효율성을 유지하기 위해 응용 프로그램을 업그레이드하는 데 중점을 둡니다 . 포커스 그룹이 선호하는 애플리케이션 유지 관리의 정의는 다음과 같습니다. 성능을 향상시키기 위해; 또는 응용 프로그램을 변경된 환경 또는 변경된 요구 사항에 맞게 조정합니다. 따라서 기존 응용 프로그램에 새로운 기능을 추가하는 것(즉, 향상)은 엄격히 말해서 유지 관리로 간주되지 않습니다 .

다시 말해 유지 관리는 소프트웨어 애플리케이션이 안정적이고 안전하게 계속 작동할 수 있도록 수행해야 하는 필수 작업입니다.

새로운 기능을 추가하는 것이 아닙니다. 로그 파일을 확인하거나 백업이 실행되었는지 확인하지 않습니다(이것은 하우스키핑 작업임). 최신 상태를 유지하고 사용자가 기대하는 대로 작동하며 표시등이 켜져 있는지 확인하기 위해 코드와 기본 플랫폼에서 작업하고 있습니다.

다음은 몇 가지 예입니다.

• 기술 및 플랫폼 변경
  타사 라이브러리를 업데이트해야 합니다. 기본 언어는 업데이트가 필요합니다. 예를 들어 PHP 5.6에서 PHP 7.1로 현대적인 운영 체제는 업데이트를 정기적으로 보냅니다. 이 위에 유지하는 것은 유지 관리이며 때로는 특정 작업을 수행하는 이전 방식이 더 이상 사용되지 않게 됨에 따라 코드 기반을 변경해야 합니다.

• 스케일링
  애플리케이션이 성장함에 따라 리소스 문제가 발생합니다. 하루에 10,000건의 트랜잭션으로 잘 작동하던 코드 내의 루틴은 시간당 10,000건으로 어려움을 겪습니다. 애플리케이션을 모니터링해야 하지만 경고가 트리거될 때 조치를 취해야 합니다.

• 오류 수정
  분명하지만 분명히 할 가치가 있습니다. 소프트웨어에 버그가 있으며 수정이 필요합니다. 프로젝트를 배송한 후 짧은 기간의 무료 버그 수정을 포함하더라도 어느 시점에서 클라이언트는 이에 대한 비용을 지불하기 시작해야 합니다.

판매하기 어렵습니까?

흥미롭게도 동료들과 이 문제에 대해 논의할 때 유지 관리가 필요하다고 고객을 설득하는 것이 어렵다고 생각합니다. 그들은 고객에게 예산이 없고 너무 비싸다는 인상을 받고 싶지 않다고 우려합니다.

글쎄요, 여기에 문제가 있습니다. 실제로는 매우 쉽게 판매됩니다. 우리는 비즈니스 사람들을 상대하고 있으며 상업적 용어로 유지 관리에 대해 이야기하기만 하면 됩니다. 비즈니스 사람들은 자산을 유지 관리해야 하며 그렇지 않으면 부채가 될 수 있음을 이해합니다 . 또 다른 표준 진행 중인 월간 간접비입니다. 사업을 하는 데 드는 비용. 우리는 이것을 제안서에 넣고 후속 조치를 취하기만 하면 됩니다 .

매우 효과적인 방법은 핵심에 유지 관리를 통합하지만 다음과 같이 클라이언트를 위한 많은 추가 가치를 번들로 제공하는 유지 장치를 제공하는 것입니다.

• 진행 상황과 KPI(예: 트래픽, 전환, 검색량)에 대한 보고
• 매월 사이트에 대한 작은 수정을 위한 제한된 '무료' 시간
• 다운타임, 서버 업데이트 또는 개발 작업 완료에 대한 보고
• 질문에 답변하기 위해 전화로 귀하 또는 귀하의 팀의 특정 구성원에게 액세스

실제로 보유자가 고객의 돈을 절약하고 스스로 비용을 지불하게 할 수 있습니다. 이에 대한 좋은 예는 오프라인 처리를 위해 매달 데이터베이스에서 간단한 보고서를 얻거나 내보내기를 요구하는 클라이언트의 요구 사항입니다.

처음에 가정한 것보다 더 복잡할 수 있는 보고 사용자 인터페이스를 구축하기 위해 여러 개발 일 동안 견적을 내거나 고객에게 귀하의 보유자를 가리킬 수 있습니다. 매월 개발자가 미리 설정된 SQL 쿼리를 수동으로 실행하여 동일한 데이터를 수동으로 제공하는 작업을 여기에 포함합니다.

귀하 또는 귀하의 팀을 위한 사소한 작업 고객에게 많은 가치를 제공합니다.

실용적인 예

물론 제안서를 작성하는 자신만의 방법이 있을 수 있지만 여기에는 예시 피치에서 몇 가지 스니펫이 있습니다.

미래에 대한 비전을 그릴 수 있는 제안 섹션에서 유지 관리에 대해 추가할 수 있습니다. 이것을 장기적인 관계 형성에 대한 씨앗을 심을 기회로 사용하십시오.

장기적인 위험을 최소화하려고 합니다.

애플리케이션이 잘 수행되고 보안이 유지되며 작업하기 쉬운지 확인하려고 합니다.

또한 모든 비즈니스 자산에서 유지 관리가 얼마나 중요한지 이해하고 있습니다.

나중에 결과물 섹션에서 유지 관리에 대한 부분을 독립 실행형 옵션으로 추가하거나 지속적인 유지 장치와 함께 번들로 추가할 수 있습니다.

다음 예에서는 이를 단순하게 유지하고 선불 개발 리테이너와 함께 번들로 제공합니다.

우리는 모든 고객이 유지 관리를 웹 사이트의 필수 오버헤드로 간주할 것을 강력히 권장합니다. 최신 웹 애플리케이션은 집이나 자동차처럼 유지 관리가 필요합니다. 나중에 부채가 되는 유형의 위험을 줄이기 위해 자산을 유지 관리합니다.

응용 프로그램의 유지 관리를 계속 유지하고 새로운 기능을 추가하고 싶어하는 고객으로서 일반 유지 관리 및 개발 유지를 위해 한 달에 N일(출발점)을 제안합니다.

개발자가 [같은 기간] 동안 문제가 발생할 경우 개발자가 더 중요한 것으로 전환할 수 있도록 하는 분명한 이점을 제공하여 개발자가 최소한 [주당/월간] 시스템에서 작업할 수 있도록 모든 것을 분산할 것입니다. . 우선 순위에 따라 모든 시간을 새로운 기능 작업에 사용하거나 유지 관리로 나눌 수 있습니다. 일반적으로 새로운 기능과 중요한 유지 관리를 75%/25%로 나누는 것이 좋습니다.

앞서 언급했듯이 이것은 성능 보고, 백업 확인과 같은 하우스키핑 작업 수행, 진행 상황 및 우선 순위를 논의하기 위한 월간 통화와 같은 기타 부가가치 지속적인 서비스와 함께 유지 관리를 일괄 처리할 수 있는 좋은 기회이기도 합니다.

당신이 발견할 수 있는 것은 당신이 작업을 착륙한 후에 그 보유자가 다시 언급되지 않는다는 것입니다. 프로젝트 시작 시 귀하와 귀하의 클라이언트가 고려해야 할 사항이 많기 때문에 이해할 수 있지만 프로젝트가 마무리되면서 프로젝트 오프보딩 프로세스의 일부로 이를 다시 도입하기에 좋은 시기입니다.

이것이 2단계에 관한 것이든 단순히 최종 송장을 소개하고 전달하는 것에 관한 것이든 유지 관리에 대해 상기시키십시오. 지속적인 교육, 보고 및 지원 가능 여부를 상기시키 십시오. 동일한 상업적 용어로 이야기하는 것을 기억하면서 보유자를 위해 밀어 붙이 십시오.

유지 관리가 짜증날 수 있습니까?

일반적인 오해는 유지 보수가 추가 부담이 될 수 있다는 것입니다. 문제는 고객이 지속적으로 전화를 걸어 리테이너의 일부로 작은 조정을 요구할 것이라는 점입니다. 이것은 소규모 팀이나 솔로 컨설턴트에게 특히 우려되는 사항입니다.

그러나 일반적으로 그렇지 않습니다. 아마도 처음에는 클라이언트가 해결해야 할 문제 목록을 가지고 있을 것입니다. 당신이 경험이 있다면, 당신은 그것을 기대하고 있습니다. 이는 커뮤니케이션 채널을 개선하고(이슈 트래커 사용) 모든 요청을 하나로 묶음으로써 쉽게 관리할 수 있습니다 . 즉, 단일 히트에서 작업합니다.

응용 프로그램이 완성되면 틱 오버 모드로 전환됩니다. 여기서 리테이너는 양 당사자에게 특히 중요합니다. 그것은 분명히 당신이 리테이너를 어떻게 구성했는지에 달려 있지만 당신의 관점에서 당신은 매달 고객에게 당신이 얼마나 소중한지 상기시키기 위해 노력하고 있습니다. 그들에게 월간 보고서를 보내고 해당 루틴의 속도 저하를 수정한 방법과 이번 주 글로벌 OS 익스플로잇을 위해 서버가 패치되었음을 알릴 수 있습니다.

물론 추가 요금이 부과되는 새로 요청한 여러 기능에 대한 작업도 가능했습니다. 클라이언트의 관점에서 그들은 당신이 거기에 있고 진행 상황을 보고 목록에서 "웹사이트에 대한 걱정"을 제거하게 됩니다. 분명히 '그 고객'이 존재하므로 가장 중요한 것은 유지 관리 문구를 올바르게 지정하고 그에 따라 기대치를 관리하는 것입니다.

고객이 저렴한 월 사용료로 달빛을 기대한다면 뒤로 미루거나 재협상하십시오. 월별 보고서 및 기타 보조 작업을 제공하는 중에 한 달에 2시간의 유지 관리 및 하우스키핑을 수행하는 데 비용을 지불하는 것이 바로 그것입니다. 임시 변경을 많이 하는 것은 백지 수표가 아닙니다. 무엇이 포함되고 무엇이 포함되지 않았는지 상기시켜 주십시오.

유지 관리를 더 쉽게 만드는 방법은 무엇입니까?

마지막으로, 클라이언트에게 최고의 가치를 보장하고 삶을 더 쉽게 만들려면 애플리케이션을 빌드할 때 이러한 전술 중 일부를 사용하십시오.

장기 지원(LTS)

• 문서화된 LTS 릴리스 및 업그레이드 경로가 있는 기술 플랫폼을 사용하십시오.
• 진행 중인 OS, 언어, 프레임워크 및 CMS 업그레이드는 모든 프로젝트에 대해 예상되고 고려되어야 하므로 LTS 버전을 추적하는 것은 쉬운 일이 아닙니다.
• 모든 것이 지원되는 버전에서 실행되어야 합니다. 그렇지 않은 경우 큰 알람 벨이 울려야 합니다.

좋은 프로젝트 위생

• 기능 백로그 또는 문제 추적 시스템에 유지 관리 작업을 공개하고 클라이언트와 우선 순위에 동의합니다. 유지 관리 작업을 숨기지 마십시오.
• 코드 수준 및 기능 테스트를 통해 특히 문제가 있는 코드를 주시할 수 있으며 리팩토링을 위해 모듈을 가져올 때 도움이 됩니다.
• 애플리케이션을 모니터링하고 병목 현상과 오류가 있는 위치를 파악합니다. 모든 문제는 개발 백로그에 추가되고 그에 따라 우선 순위가 지정될 수 있습니다.
• 지원 요청을 모니터링합니다. 최종 사용자가 유지 관리 요구 사항을 나타낼 수 있는 유용한 피드백을 제공하고 있습니까?

응용 프로그램은 이식 가능해야 합니다.

• 여러분뿐만 아니라 모든 개발자가 시스템을 로컬에서 쉽게 시작하고 실행할 수 있어야 합니다! 가상 서버 또는 컨테이너를 사용하여 애플리케이션의 개발 버전이 프로덕션과 동일한지 확인합니다.
• 신청서는 잘 문서화되어야 합니다. 최소한 실제 배포에 필요한 프로비저닝 및 배포 워크플로와 모든 특수 주문을 기록해야 합니다.

유지 관리는 진정한 Win-Win입니다.

유지 관리는 애플리케이션이 안전하게 정지할 수 있도록 애플리케이션에서 수행해야 하는 작업입니다. 표준 비즈니스 비용입니다. 소프트웨어 애플리케이션의 수명 동안 총 소유 비용의 평균 75%.

전문가로서 우리는 처음부터 고객에게 유지 관리에 대해 교육해야 할 주의 의무가 있습니다 . 여기에는 고객에게 실질적인 가치를 제공하면서 추가 수입을 얻을 수 있는 엄청난 기회가 있습니다. 지속적인 상업적 관계를 유지하고 새로운 요구 사항이 있을 때 가장 먼저 찾는 사람이 됩니다.

리테이너를 통해 계속해서 가치를 제공하면 고객과의 신뢰가 쌓이게 됩니다. 개선 사항이나 새로운 기능을 제안할 수 있는 플랫폼이 제공됩니다. 승률이 높은 작품. 고객은 평생 비용을 절감하고 위험을 줄이며 성능이나 보안에 대한 걱정을 하지 않아도 됩니다.

당신 자신, 당신의 고객, 그리고 우리 업계 전체에 호의를 베푸십시오. 웹 애플리케이션 유지 관리가 더 중요해지도록 도우십시오.