분석 및 비즈니스 인텔리전스에서 실패하는 12가지 이유
숫자 9는 당신을 놀라게 할 수 있습니다
분석 및 비즈니스 인텔리전스에는 잘못될 수 있는 많은 것들이 있습니다. 결국 우리는 진실의 단일 버전을 찾고 있습니다. 보고서든 프로젝트든 데이터와 결과가 일관되고 검증 가능하며 정확하고 무엇보다도 최종 사용자가 수용할 수 있도록 하려면 정확해야 하는 체인에 대한 많은 링크가 있습니다. 소프트웨어 개발자가 발명하고 분석 및 비즈니스 인텔리전스 커뮤니티에서 차용한 지속적인 통합 방식은 실수나 오류를 조기에 포착하려는 시도입니다.
그래도 실수는 최종 제품에 들어옵니다. 왜 틀렸어? 여기 몇 가지가 있습니다 변명 대시보드가 잘못되었거나 프로젝트가 실패한 이유.
- 더 빨라질 것입니다. 예, 아마도 사실일 것입니다. 절충안의 문제입니다. 당신은 어느 것을 선호합니까? 빨리 하시겠습니까, 아니면 제대로 하시겠습니까?
솔직히 말해서 우리는 때때로 그런 입장에 놓이곤 합니다. 금요일까지 필요합니다. 오늘 필요합니다. 아니요, 어제 필요했습니다. 사장님은 얼마나 걸릴지 묻지 않으셨습니다. 그 이야기 우리가 그것을 해야만 했던 시간. 영업팀이 필요할 때이기 때문입니다. 고객이 원할 때이기 때문입니다. - 충분히 좋을 것입니다. 완벽은 불가능하며 완벽 외에 선의 적입니다. 그만큼 발명자 공습 조기 경보 레이더의 "불완전한 숭배"를 제안했습니다. 그의 철학은 "최고는 불가능하고 차선은 항상 늦기 때문에 항상 군대에 XNUMX등을 제공하기 위해 노력한다."였습니다. 우리는 군대를 위해 불완전한 숭배를 떠날 것입니다. 나는 최종 결과를 향한 민첩하고 점진적인 진행의 요점을 여기에서 놓치고 있다고 생각합니다. 애자일 방법론에는 MVP(Minimum Viable Product)라는 개념이 있습니다. 여기서 핵심 단어는 생존 가능한. 도착했을 때 죽지 않았고 완료되지도 않았습니다. 당신이 가지고 있는 것은 성공적인 목적지로 가는 여정의 중간 지점입니다.
- 더 저렴할 것입니다. 설마. 장기적으로는 아닙니다. 나중에 수리하려면 항상 더 많은 비용이 듭니다. 처음에 제대로 하는 것이 더 저렴합니다.
초기 코딩에서 제거된 모든 단계에 대해 비용은 훨씬 더 높습니다. 그 이유는 첫 번째 배달 속도와 관련이 있습니다. 프로젝트 관리 삼각형의 세 가지 측면은 범위, 비용 및 기간입니다. 다른 하나에 영향을 주지 않고 하나를 변경할 수 없습니다. 여기에도 동일한 원칙이 적용됩니다. 두 개를 선택하십시오. 좋은. 빠른. 값이 싼. https://www.pyragraph.com/2013/05/good-fast-cheap-you-can-only-pick-two/ - POC뿐입니다.. 이 개념 증명을 프로덕션에 적용하려는 것은 아닙니다. 그렇죠? 이것은 기대치를 적절하게 설정하는 것입니다. POC는 일반적으로 애플리케이션 또는 환경을 평가하기 위한 특정 목표 또는 사용 사례 세트로 시간 제한이 있습니다. 이러한 사용 사례는 필수 필수품 또는 일반적인 패턴을 나타냅니다. 따라서 POC 평가는 정의에 따라 추가 결정의 기반이 될 수 있는 더 큰 파이의 조각입니다. 그것은이다 드물게 소프트웨어든 하드웨어든 POC를 프로덕션에 적용하는 것은 좋은 생각이 아닙니다.
- 일시적일 뿐입니다.
결과가 잘못되었거나 성능이 좋지 않거나 그냥 보기 흉하다면 프로덕션 단계로 넘어가지 말았어야 합니다. 중간 결과물이라 하더라도 표현 가능해야 합니다. 최종 사용자와 이해 관계자는 이를 수락하지 않습니다. 그러나 주의해야 할 점은 이것이 프로세스의 일부로 설정된 기대치라면 수용할 수 있다는 것입니다. "숫자는 정확하지만 대시보드의 색상에 대한 피드백을 원합니다." 그러나 이것은 생산 중이 아니어야 합니다. 낮은 환경에 있어야 합니다. 너무 자주 "일시적일 뿐"이 영구적인 문제의 좋은 의도가 됩니다. - 이것이 내가 아는 유일한 방법입니다. 때로는 하나 이상의 정답이 있습니다. 그리고 때로는 목적지에 도달하기 위한 하나 이상의 경로가 있습니다. 때때로 우리는 우리의 오래된 습관을 가져옵니다. 그들은 열심히 죽습니다. 이것을 학습의 순간으로 사용하십시오. 올바른 방법을 배우십시오. 시간을 내십시오. 도움을 요청.
- 이것이 우리가 항상 해왔던 방식입니다.. 이것은 고치기 어렵고 논쟁하기 어렵습니다. 프로세스와 이를 수행하는 사람을 변경하려면 진정한 조직 변경 관리가 필요합니다. 종종 새 프로젝트, 새 소프트웨어, 업그레이드 또는 마이그레이션은 오랫동안 숨겨져 있던 문제를 드러냅니다. 이제 바꿀 시간입니다.
- 아차, 나는 그것을 다시했다.
저는 목공이고 모토가 있습니다. 실수가 너무 많기 때문입니다. 두 번 측정하고 한 번 자르십시오. 나는 이 격언을 알고 있다. 나는 나 자신에게 그것을 반복한다. 하지만 아직 내 보드가 너무 부족할 때가 있습니다. 이것은 부주의입니까? 혹시. 하지만 대개는 빠르고 쉬운 일입니다. 나는 계획이 정말로 필요하지 않습니다. 하지만, 그거 알아? 시간을 내어 계획을 세웠다면 숫자가 계산되었을 가능성이 큽니다. 너무 짧은 조각은 종이에 있었고 지우개로 고쳤을 수 있습니다. 분석 및 비즈니스 인텔리전스도 마찬가지입니다. 빠르고 쉬운 계획이라도 이러한 종류의 실수를 줄일 수 있습니다. - 산만. 보고 있지만 보지 않습니다. 무주의 맹시. 당신은 본 적이있을 수 있습니다 비디오 한 팀의 농구 패스 수를 세는 것과 같이 수행해야 할 작업이 제공되는 곳입니다. [스포일러 경고] 그 간단한 작업을 수행하는 데 주의가 산만해지면 달을 걷는 고릴라를 알아차리지 못합니다. 나는 무슨 일이 일어날지 알고 있었고 범죄가 저질러졌다면 끔찍한 증인이 되었을 것입니다. 보고서를 개발할 때도 마찬가지입니다. 요구 사항은 픽셀 완벽한 정렬을 요구하고 로고는 최신 상태여야 하며 법적 면책 조항이 포함되어야 합니다. 계산이 유효한지 확인하는 데 방해가 되지 않도록 하십시오.
- 당신은 의도.
또는, 예상됩니다. 적어도 그것은 항상 선택 사항이었습니다. 토마스 에디슨은 “나는 실패하지 않았다. 작동하지 않는 방법을 만 가지나 찾았습니다.” 그의 철학은 실패할 때마다 성공에 한 발짝 다가서는 것이었습니다. 어떤 의미에서 그는 실패를 계획했습니다. 그는 가능성을 배제하고 있었다. 그는 이론이 다 떨어졌을 때만 시행착오를 겪었습니다. 에디슨처럼 제 이름에 대한 특허가 천 개가 넘지는 않지만 분석이나 보고서를 개발하는 데 더 나은 접근 방식이 있을 수 있다고 생각합니다. (Thomas Edison의 백열전구 특허출원 1882.) - 우둔. 부정하지 마세요. 이것은 존재합니다. 어리석음은 "당신이 의도한"과 "죄송합니다." 사이 어딘가에 있습니다. 이러한 유형의 장엄한 실패는 시계-이-홀드-마이 맥주, 다윈 어워드(Darwin Award)의 다양성입니다. 그래서 때로는 알코올이 관련될 수도 있습니다. 다행스럽게도 내가 아는 한 우리 직업에서는 술 취한 대시보드로 사람을 죽인 적이 없습니다. 하지만 여러분도 마찬가지라면 원자력 발전소에서 일하고 계시다면 냉철하게 분석해 보십시오.
- 성공은 중요하지 않습니다.
전설적인 스턴트맨 Evil Knievel은 죽음을 무시하는 스턴트를 수행하여 돈을 받았습니다. 성공이든 실패든 그가 착륙을 막았든 그렇지 않든 그는 수표를 받았습니다. 그의 목표는 살아남는 것이었다. 부러진 뼈에 대한 보상을 받지 않는 한 Knievel은 평생 가장 많은 부러진 뼈에 대한 기네스 세계 기록을 보유하고 있습니다. 성공이 중요합니다.
