Salesforce 연동이 프로토콜 때문에 실패하는 일은 거의 없습니다. 인증은 이미 풀린 문제이고, 레코드 하나를 등록하는 것도 이미 풀린 문제입니다. 프로젝트를 끝장내는 것은 하루치 요청 할당량과 데이터 모델의 형태이며, 이 두 가지는 대개 가동 후 3주쯤 지나 야간 작업이 오류를 뱉기 시작하고 테스트에서는 왜 멀쩡했는지 아무도 설명하지 못하는 시점에 발견됩니다. 패턴은 예측이 가능할 만큼 일정합니다. 개발자가 Developer Edition 조직을 상대로 만들고, 전부 통과하고, 고객이 검수를 승인합니다....
맞춤형 소프트웨어 개발
맞춤형 소프트웨어 개발에 관한 기사, 가이드 및 튜토리얼. 개발자와 기업을 위한 실용적인 정보를 제공합니다.
소프트웨어 임치는 소스코드를 중립적인 제3의 기관에 맡겨 두는 제도이며, 충분히 합리적인 두려움에 답하기 위해 존재합니다. 핵심 시스템을 만들고 운영해 온 공급업체가 사라지고, 여러분에게는 의존하고 있지만 스스로 유지보수할 수 없는 무언가만 남는 상황 말입니다. 임치 계약은 소스코드를 그 기관에 보관해 두었다가, 그런 일이 실제로 벌어지면 여러분에게 인도하도록 정해 둡니다. 두려움 자체는 정당합니다. 문제는 이 제도가 자주 오해된다는 점이고, 그 간극에서 매년 돈은 나가지만 정작 필요한 날에는 아무 도움이 되지 않는 계약이 생겨납니다....
고정가 계약과 투입 정산 계약 가운데 무엇을 고를 것인가 하는 문제는 대개 리스크에 관한 선택으로 설명됩니다. 그 설명 자체는 옳지만, 바로 다음 단계에서 잘못 다뤄집니다. 발주사와 수행사 모두 리스크가 자리를 옮길 뿐이라는 사실을 잊고, 어느 한쪽을 고르면 리스크가 사라진다고 가정하기 때문입니다. 리스크는 사라지지 않습니다. 고정가 방식에서는 견적이 틀릴 위험을 공급사가 떠안고, 그 위험을 제시 금액 안에 미리 얹어 둡니다. 투입 정산 방식에서는 같은 위험을 발주사가 떠안습니다. 질문은 어느 쪽이 불확실성을 없애 주느냐가 아닙니다. 어느 쪽이 그 불확실성을 더 잘 ...
소프트웨어 제안요청서, 즉 RFP는 원래 여러 공급업체를 나란히 놓고 비교할 수 있게 만드는 문서입니다. 그런데 실제로 오가는 문서 대부분은 정반대의 결과를 냅니다. 해법을 지나치게 자세히 지정해 답변의 폭을 묶어 놓으면서, 정작 가격을 산출하는 데 누구에게나 필요한 정보는 빠뜨리기 때문입니다. 그 결과 자릿수가 하나 차이 나는 다섯 개의 견적이 나란히 도착하고, 형식상으로는 모두 요구에 응답했지만 같은 것을 재고 있는 견적은 하나도 없습니다. 흔한 진단은 공급업체가 말을 흐린다는 것입니다. 가끔은 사실입니다. 그러나 훨씬 더 자주 벌어지는 일은, 문서가 그 안에 담...
소프트웨어 유지보수 비용은 성공한 프로젝트를 열여덟 달 뒤 껄끄러운 대화로 바꿔 놓는 숫자입니다. 구축은 예산이 잡혔고 승인이 났고 납품까지 끝났습니다. 그런데 서비스가 가동된 다음에 벌어지는 일은 그냥 “지원"이라는 한마디로 정리되었고, 누군가 감으로 찍은 금액이 붙었으며, 그 금액은 거의 언제나 너무 적었습니다. 이유는 부주의가 아니라 구조에 있습니다. 구축에는 값을 매길 수 있는 범위가 있습니다. 유지보수에는 범위가 없습니다. 아직 일어나지 않은 일들이 그 범위를 정하기 때문입니다. 취약점이 발견되는 라이브러리, API를 바꾸는 공급업체, 아무도 예상하지 못한 ...
기술 실사는 코드 품질을 겨루는 대회가 아니며, 실사를 준비하는 팀은 대개 엉뚱한 곳에 시간을 쏟습니다. 회사를 인수하려는 사람 중에 당신이 만든 추상화에 점수를 매기려는 사람은 없습니다. 인수자는 이 시스템을 소유하는 데 얼마가 들지, 그리고 돈이 오간 뒤에 상황이 얼마나 나빠질 수 있는지를 계산하려는 것입니다. 이렇게 질문을 다시 세우는 일이 중요한 이유는, 무엇부터 손봐야 하는지가 달라지기 때문입니다. 보기에 지저분해도 돌아가고, 팀이 이해하고 있으며, 안전하게 바꿀 수 있는 코드는 사소한 지적에 그칩니다....
핀테크 소프트웨어 개발은 누군가 돈을 보유할 권한이 누구에게 있는지 묻기 전까지는 일반 소프트웨어 개발과 똑같이 견적되고 일정이 잡힙니다. 그 질문이 나오는 순간부터 프로젝트는 엔지니어링 과제이기를 멈추고 엔지니어링 요소가 딸린 규제 과제가 되며, 머릿속에 그려두었던 일정은 더 이상 달성 가능한 것이 아니게 됩니다. 기술은 어려운 부분인 경우가 드뭅니다. 돈을 옮기는 일은 이미 해결된 문제이고, 성숙한 제공업체와 문서화된 인터페이스, 첫날부터 쓸 수 있는 테스트 환경이 갖춰져 있습니다. 핀테크 구축 기간을 늘리는 것은 인가 지위, 감사에 대응할 증적 의무, 그리고 여...
MVP 소프트웨어 개발이 어긋나는 지점은 구현 단계가 아니라 범위를 정하는 회의입니다. 누군가 “최소 기능 제품"이라고 말하면 모두가 고개를 끄덕이고, 그다음에 도착한 기능 목록에는 사용자 계정과 관리자 화면, 결제, 알림, 대시보드, 그리고 모바일 앱까지 들어 있습니다. 그것은 최소 기능 제품이 아닙니다. 그것은 이미 완성된 제품이고, 머릿속에 떠올린 숫자보다 세 배는 더 오래 걸립니다. 정작 문제를 일으키는 단어는 “기능하는”, 즉 뒤에 붙는 viable입니다. 대부분의 팀은 이 말을 “누구에게나 팔 수 있을 만큼 좋은 상태"로 읽지만, 실제 의미는 “...
영국에서 헬스케어 소프트웨어 개발은 다른 어떤 업종의 같은 작업보다 비용이 더 들고 시간도 더 걸립니다. 이유는 코드가 더 어려워서가 아닙니다. 예산의 상당 부분이 기능이 아니라 증빙에 쓰이기 때문입니다. 임상 위험 문서, 정보 거버넌스, 그리고 구매자가 제품을 시험해보기도 전에 요구하는 보증 서류입니다. 다른 분야에서 소프트웨어를 만들어온 팀은 이를 일관되게 과소평가합니다. 애플리케이션을 견적하고 계약을 따낸 뒤에야, 컴플라이언스 계층이 마지막 단계가 아니라 첫날부터 시작해야 하는 병렬 작업이라는 것을 알게 됩니다. 나중에 되돌리기 비싼 아키텍처 결정을 그 계층이 ...
엔드포인트 개수로 맞춤형 API 개발 비용을 추정하는 사람은 거의 틀립니다. 보통 세 배쯤 틀립니다. 엔드포인트는 이 일에서 가장 싼 부분입니다. 이미 가지고 있는 데이터를 읽고 쓰는 열 몇 개짜리 묶음이라면, 실력 있는 백엔드 개발자에게는 이 주 남짓한 작업입니다. 돈이 드는 쪽은 그 엔드포인트를 다른 회사가 자기 사업을 얹어도 되겠다고 판단할 만한 것으로 바꾸는 나머지 전부입니다. 보안 검토를 통과하는 인증, 나중에 마음을 바꿀 여지를 남겨 두는 버전 관리, 아무도 문의 메일을 보내지 않아도 될 만큼 좋은 문서, 그리고 어느 고객이 지금 곤란을 겪고 있는지 알려 ...