대기업은 대개 직원과 돈이 부족하여 직원이 원하는 모든 프로그램을 작성 (시간 절약 및 프로세스 최적화) 할 수 없다는 문제가 있습니다.

그런 다음 숨겨진 프로그램은 (적어도 일부) 코딩 경험이있는 사람들 (또는 저렴한 학생 / 인턴)에 의해 만들어 질 것입니다. 경우에 따라 이러한 응용 프로그램의 중요성이 높아지고 한 사용자에서 전체 부서로 확산됩니다.

그렇다면 중요한 점은 다음과 같습니다. 누가 응용 프로그램을 유지 관리하고 새로운 기능을 추가합니까? 그리고이 앱은 매우 중요합니다. 필요합니다. 그러나 인턴은 회사를 떠났습니다. 그것이 어떻게 작동하는지 아무도 모릅니다. 당신은 많은 소스와 일종의 문서 만 가지고 있습니다.

IT 부서 외부에서 임시로 수행 한 응용 프로그램 개발을 시도하고 제어하거나 금지하는 것이 합리적입니까 (Excel 매크로와 같은 사소한 것 제외)?

우리가 제공 한 모든 앱에서 다음과 같은 질문을했던 회사에서 일했습니다.이 데이터를 Excel로 내보낼 수 있습니까?

잠시 후, 나는 왜 그들이 모든 것에 대한 Excel 내보내기에 집착했는지 알아야한다고 결정했습니다. 많은 부서에 한 사람이 Excel 전문가였으며 곧 유용한 데이터 분석 앱을 작성할 수있는 것으로 나타났습니다. 이러한 앱은 산불처럼 부서 전체에 퍼져 있었고 우리 기술자들은 그들이 존재한다는 것을 전혀 몰랐습니다.

왜 그들이 먼저 우리에게 오지 않았습니까? 기술 팀이 할 일이 너무 많았다는 평판이 나 왔으며, 요청한 경우 6 개월 후 대기열에 올릴 수 있습니다.

그것은 불공평 한 비난이 아니었고 우리에게 Excel 앱을 지원하도록 요청하지 않았으므로 아무도 그것이 문제라고 생각하지 않았습니다. 이 Excel 개발자는 떠날 때 항상 다른 사람을 찾아서 가져 왔습니다.

당신은 그것이 우리가 잘못 우선 순위를 정했다는 것을 의미한다고 주장 할 수 있었으며, 중요한 일은 끝나지 않았습니다. 그러나 나는 그것이 더 많은 돈을 지불하는 개발자들이 더 어려운 작업을 수행 할 수 있도록 해주 었다고 주장 할 것이다. 무엇을 다칠 수 있습니까?

이제 개발 팀 외부에서 작성되는 데이터베이스를 업데이트하는 소프트웨어 는 금지합니다. 그리고 개발팀 외부에서 작성된 앱은 지원하지 않습니다. 그러나 모든 소프트웨어가 비즈니스 자체에서 작성되는 것을 금지하려고 시도하지 않았으며, 데이터 내보내기를 작성하여 권한을 부여하기 위해 행복하게 데이터 내보내기를 작성하려고합니다. ).

사람들이 여기에 일반적인 요점이 빠져 있다고 생각합니다.

진행중인 모든 사용자 지정 개발이 ​​마음에 들지 않으면 잘못된 문제를 해결하지 못하고 대신 허용되지 않는다고 말하는 것이 아니라 IT를 둘러싼 이유를 묻는 것입니다. 귀하 (IT)는 업무 수행을 개선하기 위해 존재하며 사람들은 소프트웨어가 멋있거나 깔끔하거나 새롭기 때문에 소프트웨어를 사용하지 않으며 문제를 해결하기 때문에 소프트웨어를 사용한다는 것을 기억하십시오.

이러한 앱이 처음에 생성되는 이유는 무엇입니까?

내가 본 모든 경우에 일반적인 이유가 있습니다.

비즈니스 그룹은 회사 전체의 맥락에서 동일한 요구보다 우선 순위를 정합니다.

마케팅은 마케팅에만 책임이 있으므로 목표에 도움이되는 이니셔티브는 다른 그룹에 대한 보풀로 간주되는 반면 IT와 같은 제한된 리소스에 대해서는 우선 순위가 낮은 경향이 있습니다. 우선 순위 지정은 공유 리소스를 사용하려는 경우에만 적용됩니다. 프로젝트를 전적으로 자체 부서로 유지하는 경우 부서 책임자 만 예산과 일정을 관리해야합니다.

내가 이런 종류의 개발을 금지 한 이유는 없다. 이유는 공유 리소스 (주로 IT)에 대한 제약을 완화하고 각 그룹이 스스로 고유 한 문제를 해결할 수있게 해준다 (고급 Excel에 능통 한 사람들은 일반적으로 이것은 일반적인 문제이므로 대부분의 부서에는 하나 이상이 있습니다.

그러나 이러한 응용 프로그램에서 발생하는 문제를 해결하거나 원래 개발자가 회사를 떠난 후 지원할 수는 없습니다. 다른 게시물에서 언급했듯이, 이는 빅 보스가 지원을 요구하는 것을 막지는 않지만, 사용자 정의 응용 프로그램이나 프로세스의 종류에 대해 느끼면 무언가가 중요 해지면 느낄 수 있습니다. "사내"로 가져 오려면 참여해야 할 수도 있습니다. 또한 어떤 것이 IT 제어를받는 시스템에 연결하고 수정하는 경우 중앙 시스템의 보안과 무결성을 보장하기 위해서만 IT가 관여해야합니다. 그러나 그것이 사용자의 데스크탑에만 국한된 것이면 그것을 금지?

그러나 기억 해야 할 것이 있습니다. IT 외부에서 개발 된 모든 사용자 지정 응용 프로그램은 IT가 충족하지 못하는 요구에 해당합니다 . 회사의 우선 순위가 아니거나 매우 전문적인 문제가 아닌 다른 옵션만큼 좋지 않거나 IT 직원이 모르는 사용자 지정 언어 등 IT 관리자가 충족하지 못한 이유가있을 수 있습니다. 합법적이지만 이러한 솔루션은 일부 부서에서 IT 부서가 충족 할 수 없었거나 충족하지 못할 필요성이 있었기 때문에 만들어졌습니다.

그들이 문제를 해결하도록 도와주십시오. 시간이나 자원이 없으면 스스로 해결하도록하십시오. 사람들을 귀하의 비즈니스에서 제외시키는 유일한 목적으로 가파른 학습 곡선을 가진 일부 언어를 명령하면 대부분의 비즈니스 사용자가 IT에 대해 인식하는 엘리트주의 태도를 향상시키는 데 도움이되고, 결국 그러한 엘리트 태도는 사용자가 IT에 접근하는 것을 두려워하고 IT가 자신의 요구 나 요구를 이해하지 못한다고 확신하기 때문에 동일한 문제에 더 가깝습니다. 관계를여십시오-그들이 필요한 것을 이해하는 것이 그들이 당신을 돌아 다니는 것을 막는 유일한 방법입니다.

또한 IT 부서에 무능한 직원이있는 회사의 경우를 고려해야하며, 숨겨진 앱은 회사 내에서 개발자가 아닌 직종이있는 숙련 된 개발자가 작성해야합니다. 내 경험상 그러한 경우는 매우 빈번합니다.

소프트웨어 개발자와 회계사의 이중 프로파일이 있다고 가정하십시오. 이것은 당신이 회계사로 고용되었습니다. 왜냐하면 이것은 당신이 잘 지불 된 직업을 얻을 수있는 기회 였기 때문입니다. 당신은 동료들 (그리고 지금 당신)이 프로그램에 의해 몇 초 안에 반복되는 일을하는 데 시간을 보낸다는 것을 금방 알 수 있습니다.

모든 작업을 수행 할 앱을 작성하기 위해 저녁을 보냅니다. 개인 랩톱에서 동료에게 보여 주면 매우 유용합니다. 회사 PC에 설치하려고하지만 IT 부서의 동의가 있어야합니다. 요청하지만 응용 프로그램을 지원하지 않기 때문에 거부합니다.

바보 같지 않니?

이외에도이 특정 경우, 지원을 문제가 발생할 하나 개 많은 기업에서 매우 다르지 않다 모든  도, IT 부서 내에서 작성 한 소프트웨어 : IT 부서 모범 사례를 적용하지 않을 경우, 코드는, 심하게 / 문서화되지 것입니다 유지 보수에 관심이없고 몇 년 전에 떠난 경험이없는 사람들이 작성했습니다.

결론적으로 주요 질문은 수익성 입니다. IT 부서에서 가장 기본적인 소프트웨어 개발 규칙을 이해하지 못하는 직원이 개발 한 앱을 유지 관리하도록 요청받은 경우, 이 작업이 얼마나 즐겁 든 문제가되지 않더라도 여전히 가져와야합니다. 회사에 많은 돈 . 또는 작업을 수행하는 가장 저렴한 방법이라면 처음부터 다시 작성하십시오.

당신은 그것을 완전히 통제 할 수 없습니다 ...

직원들은 항상 악성 코드를 생성하고 다른 방법으로 확산시킬 수 있기 때문에 완전히 통제 할 수는 없다고 말하고 싶습니다. 따라서 몇 가지 기본 규칙과 프로세스를 작성하고 시행하고 몇 가지 도구를 설정 한 후에는 너무 많은 집착을 사용하지 않아도됩니다.

아이디어는 사람들이 아무 것도 생산하지 않는 새로운 일을하는 것이 불가능하기보다는 사람들이 이러한 규칙을 존중하고 도구를 사용하는 것이 가능한 매력적으로 만드는 것입니다.

그러나 코드 친화적 인 환경을 만들 수 있습니다

종종 매우 큰 많은 회사들이 이것을합니다. Google의 좋은 예는 모든 사람들이 다른 사람의 코드를 모니터링하고 볼 수 있도록 회사 전체에 단일 SCM을 사용한다고 말했다.

다음을 수행하는 것이 좋습니다.

• SCM의 일부 영역에 공개적으로 액세스
• 지속적인 통합 및 지속적인 검사 서버에 대한 액세스를 쉽게 요청하고
• 사람들이 도구를위한 빌드 작업을 만들도록 장려하십시오.

문제는 기술의 확산입니다. 분명히, 일부는 X보다 Y를 사용하는 것을 선호 할 것이며, 그럴 경우 아키텍처에 맞추기가 더 어려워집니다. 그러나 불가능하지는 않으며 코드를 유지하려면 1 마일이면 추가 마일을 얻습니다.

좀 더 임의의 자세를 취하고 언어 L과 스택 S 만 허용되도록 결정할 수 있지만 여기저기서 불량한 것들이 생길 것이므로 조금 넓히는 것이 좋습니다. 일부 CI 시스템은 직원들이 약간의 글루 코드 또는 구성 스크립트를 작성하여 적합하게 만들 수 있다면 몇 가지 플러그인으로 놀라운 일을 할 것입니다.

팀에게 자유를 주라

팀에게 변덕을 느끼고 실험적인 것들로 작은 새 프로젝트를 시작할 자유를주는 것이 중요합니다. 그것은 그들의 발가락에 그들을 유지하고, 당신뿐만 아니라 당신에게 문제를 일으킬 때까지 영원히 쌓아 두지 않고 이러한 기술을 고려하도록 강요합니다.

따라서 애완 동물 프로젝트를 테스트하기 위해 자체 시스템을 설치할 수 있어야합니다. 그러나 IT 부서에 대해 이야기하는 습관을 들여야합니다.

IT와 대화하고 참여하도록

직원이 IT에 전자 메일 요청을 찍는 것에 대한 반사를 개발하고 직원이 자신을 위해 무언가를 설정하고 수용 할 수 있는지 물어 보는 것이 훨씬 좋습니다. 대부분의 시간이 단축되지만 최소한 제어와 담당자의 개념이 있으며 다른 팀의 요구에 대해 IT에 가시성을 제공합니다.

프로젝트가 더 중요한 덩어리를 찾으면 다시 요청할 수 있으며 다시 고려할 수 있습니다. 의사 소통이 중요하며 개발자, 컨설턴트, IT 지원 직원 또는 코드를 다루는 사람으로 구성된 팀이 있어야합니다. 그들 중 누구도 길을 잃은 프로그램을 원하지 않기 때문에 모두에게 최선의 이익입니다. 규칙을 자체 백업하는 경우 규칙을 적용하는 것이 훨씬 쉽습니다.

사람들이 실제 비즈니스 문제를 해결하도록하기 때문에 이러한 "숨겨진"응용 프로그램을 중지 할 수 없습니다. 당신이 할 수있는 일은 그들이 "올바른"방법으로하도록 돕는 것입니다. 그리고 "오른쪽"이란 앱을 시작한 사람이 떠난 후에도 앱을 유지할 수 있도록하는 것을 의미합니다. Up 또는 Out 에서 제안 된 언어를 사용하는 것이 좋습니다 . 이 프로세스를 자세히 문서화하여 나중에 야후가 떠난 후 1 년 후에 이해할 수 있도록해야합니다. 버전 관리 설정 및 사용 방법 표시, 위키 (작업이 실제로 수행되는 방식에 대한 비공식 메모 유지) 및 간단한 버그 추적 시스템을 도와줍니다. 작업을 정말 매끄럽게하려면 예비 서버 (있는 경우)에 지속적인 통합을 설정하십시오.

모든 비즈니스 스쿨이 이제 Excel을 가르치고 있으며 많은 비즈니스 과정에서 사용되는 주요 도구이기 때문에 Excel 통합 (또는 적어도 가져 오기 / 내보내기)에 대한 열망이 있습니다.

사베 인 옥 슬리 (Sarbanes-Oxley) 및 미국 외의 유사한 법률은 개인 정보 보호법 및 내부적으로 개인 정보 보호 및 보안 프로세스 및 정책과 결합되어 그림자 -IT 현상을 억제하는 데 사용될 수있는 "해머"입니다.

고객 또는 직원의 개인 식별 정보 (나가고 싶지 않은 데이터)가이 스프레드 시트에서 유통되기 시작하면 사고가 발생하기를 기다리는 것입니다.

마찬가지로, 이러한 skunkworks IT 프로젝트 중 하나가 Excel 스프레드 시트를 가져와이를 해킹 된 외부 웹 응용 프로그램의 데이터로 사용하자마자 CIO와 CEO가 해당 앱을 만든 사람의 사무실로 스톰 핑합니다. 주말은 결과를 설명하기 위해옵니다.

그리고 이러한 노력을 Fortune 500 대 기업의 수백 (또는 수천) 부서에 곱하면 100 개가 넘는 고객 "마스터"데이터베이스가 있다는 문제가 곧 발견됩니다. 고객은 한 곳에서 연락처 정보를 업데이트했지만 10 곳에서는 아직 구식이 아니거나 정보가 10 개의 그림자로 분산되어있어 큰 파트너와 얼마나 많은 비즈니스를 수행하고 있는지조차 모른다고 불평하기 시작합니다. IT 데이터베이스.

이 모든 것이 누구에게나 재미 있지 않지만 기업 환경에서 IT의 삶에있어 어려운 사실 인 강력한 규정 준수 및 감사 프로세스를 발생시킵니다.

좋은 전략은이 작업을 수행하는 모든 부서를 살펴보고 섀도 IT에 대한 투자를 IT로 적절하게 전환하여 IT가 규모의 경제를 달성하고 현재보다 더 효율적으로 수행 할 수 있다는 주장을하는 것입니다. 임시 분산 스 sk 크 웍스 모델. 이는 IT 예산 제약과 전달 속도가 처음으로 스 unk 크 웍스를 야기한 환경에서 어려운 판매 일 수 있지만 감사 / 신뢰 위험과 결합하면 좋은 1-2 투 펀치를 만들 수 있습니다.

새로운 신청서를 작성하기로 한 결정은 종종 요청의 비용 편익 분석에 근거합니다. 비즈니스에 대한 전반적인 가치뿐만 아니라 사용 가능한 IT 리소스, 요청 범위, 비즈니스 목표 및 방향 등의 다른 많은 동인을 고려하는 동시에 몇 가지만 언급하면됩니다. 부서 관리자 / 이사가 합리적인 ROI를 제시하지 못했거나 단순히 정해진 절차를 따르지 않아 특정 부서 요청이 거부되는 경우가 종종 있습니다.

이유가 무엇이든 'IT 부서'는 결정이 통제 범위를 벗어난 경우에도 종종 희생양이됩니다. 따라서 요청 거부가 IT 부서에 제대로 반영되지 않을 수도 있지만 인식은 완전히 다릅니다.

그럼에도 불구하고 전 세계 거의 모든 비즈니스 조직에서 불량 응용 프로그램을 찾을 수 있습니다. 잘 작성된 것과 그렇지 않은 것 중에는 결코 빛을 본 적이없는 코드가 포함되어 있습니다.

우리는 내부 고객의 요구를 충족시키기 위해 합리적으로 할 수있는 모든 것을해야하지만 단순히 할 수없는 때가 있습니다. 그렇게되면 문제를 해결할 다른 곳을 찾을 것입니다.

IT 그룹이 프로젝트에 적극적으로 참여하는 경우 표준 준수를 요구하고 컨설턴트가 내부 코딩 지침을 따르도록 지원하며 시스템 (데이터베이스, 네트워크, 방화벽 등)과의 응용 프로그램 상호 작용 및 요구 사항을 이해할 수 있습니다. 이러한 개입 없이는 우리의 업무 시스템이 SLA를 충족시키지 못하는 이유를 파악하는 데 시간이 많이 걸리고 많은 시간을 소비하게됩니다.

IT 부서가이를 용납하고 지원하는지 여부는 IT 부서가 측정하는 지원, OLA 및 SLA 약속 측면에서 직접적인 영향을 줄 수 있습니다.

다음과 같은 이유로 회사에서 금지됩니다.

• 비밀번호를 아는 유일한 사람이 회사를 떠난 비밀번호로 보호 된 Excel 매크로,
• 경험이 부족한 사람들이 작성한 잘못된 보고서에 대해 책임을 져야합니다.
• 이전에 보거나 들어 본 적이없는 보고서를 수정하라는 요청을 받았습니다.

IT가 바쁠 때 사용자에게 불편을 줄 수 있으며 '그냥 스스로'하는 경향이 있다는 것을 알고 있습니다. 그러나 IT는 존재조차 알지 못하는 것에 대해 책임을 질 수 없으며, 전체 IT를 책임지는 사람이 없다면 앞으로 큰 문제가 있습니다.

여기에 문제가 있으면 IT 부서에 문제가있는 것입니다.

전문적인 비즈니스 / 도메인 지식을 가진 사람들이 자신의 데이터를 조작하고 처리 할 수있게하는 데 아무런 문제가 없습니다.

IT 부서는이를 인정하고 지원해야합니다. 재사용 가능한 인터페이스를 제공하고 EXCEL 또는 Access DB와 같은 편리한 형식으로 데이터를 제공하고 유연한 툴링 (COGNOS, Jasper Reports 등)을 제공합니다.

IT 부서는 우선 순위를 다시 생각해야합니다. 비즈니스를 수행하거나 최신 방법론을 구현하지 않거나 가장 섹시한 하드웨어를 설치해야합니다.

많은 회사 나 회사의 부서가 가지고있는 좌절은 IT 부서가 방해를 받고 업무를 수행하거나 새로운 일을하기가 어렵다는 것입니다. 이는 IT 정책에 의해 보류되는 것처럼 느끼는 부서가 자신의 문제를 해결하려고합니다. 의사 소통이 핵심입니다. 부서에서 IT 관련 작업을 수행하는 경우 실제로 문제는 IT 문제입니다. IT는 적으로 볼 여유가 없습니다. 회사, 특히 IT 부서는 서로 대립하는 대신 협력해야한다는 사실을 인식해야합니다. 부서가 IT 직원 (특히 감독해야하는 직원)과 의사 소통하고 자신의 요구와 자신의 문제를 해결하기 위해 노력하고있는 방법을 알려 주면, 최소한 IT는 위기가 다가온 사실을 파악하는 대신 문제를 해결하는 데 도움을 줄 수있는 옵션을 갖게 될 것입니다. IT를 신속하게 관리하십시오.

응용 프로그램이나 스프레드 시트 등 이러한 특수 도구가 거의 필요합니다. IT 부서에는 두 가지 선택이 있습니다. 인 에이 블러 또는 디스 에이블 러일 수 있습니다. 내 경험상, 장애인은 유효한 비즈니스 요구를 방해하고 공통의 적이되기 때문에 잃어 버립니다. 반면 인 에이 블러는 비즈니스를 진정으로 도와줍니다.

그렇다고해서 부서 자금 개발이 자유 통치를 받아야한다는 것은 아닙니다. 다음과 같은 일부 요구 사항이 적용되어야합니다.

• 모든 코드는 IT 부서가 운영하는 버전 관리 시스템에 정기적으로 투입되어야합니다. IT는이를 가능하게하기 위해 자유롭게 계정과 디렉토리를 작성해야합니다. IT 부서에서 지침을 제공 할 수도 있습니다.
• PII (개인 식별 정보), 인증, 권한 부여, 암호화, 법률에 의해 보호되는 데이터 또는 비즈니스가 중요하다고 생각하는 데이터와 관련된 모든 것은 IT 컨설턴트가 포함하고 승인해야합니다. IT / 컨설턴트는 앱 개발을 지원하면서 비즈니스를 올바르게 보호하기 위해 지원, 라이브러리 등을 제공해야합니다.
• 기본 데이터베이스는 보호해야합니다. 데이터베이스에 따라 읽기 액세스가 비교적 쉽고 읽기 액세스가 어렵습니다. IT 부서는 계정, 로깅 또는 감사를 제공해야 할 수도 있습니다.

활성화하면 많은 이점이 있습니다.

• IT는 고객의 요구를 충족시키는 방법에 대해 더 많이 배웁니다. 이를 통해 우선 순위 및 공유가 향상됩니다.
• IT는 문제가 아니라 친구와 혜택으로 여겨집니다.
• 실제 비즈니스 요구가 충족됩니다.
• IT와 관련되어 비즈니스 데이터가 적절히 보호되어 백도어가 필요하지 않습니다.
• 이직 도구는 이직으로 인해 손실되지 않으며 필요한 경우 IT로보다 쉽게 ​​이동할 수 있습니다.

도와 드릴 수 없었습니다. 설명하는 문제는 문화, 언어 및 대륙에 걸친 보편적 인 것으로 보입니다.

할 수있는 일 :

• 관리자의 승인을 요청하여 데이터베이스 계정 생성을 제한하십시오 . 로컬 컴퓨터를 데이터베이스 서버로 사용하거나 응용 프로그램을 독립 실행 형으로 작성하면 유용성이 크게 줄어 듭니다.

• IT와 관련된 모든 인턴 들이 IT를 통해서만 계약 되도록하십시오 .

• OS 정책을 통한 소프트웨어 설치 제한 . 모든 소프트웨어 설치는 IT 헬프 데스크를 통해 이루어져야하며 감독자의 승인이 필요합니다. 그렇게하면 MS Access, PHP, Visual Basic 등의 설치가 눈에 띄지 않게 전달하기가 더 어려워집니다.

• 지원을 받으려면 모든 새로운 개발을 Java, C #, C ++ 또는 가파른 학습 곡선 이 필요한 다른 언어 로 작성해야한다는 정책을 발표하십시오 . 그렇게하면 "프로그래밍에 대한 특정 지식"을 가진 사람들의 세계가 줄어들게됩니다.

• 요구 사항 즉 A는 기업의 IT 요구 사항의 반영이기 때문에 사람들은 회사 주변의 "엑셀 솔루션"을 살펴해야합니다.

• 구현 데이터웨어 하우스 및 최종 사용자 친화적 인 데이터 마이닝 및 보고 도구 . 이렇게하면 맞춤형 인턴 작성 작은 앱의 필요성이 줄어 듭니다.

그러나 단 한 번도 Big Chief 의 전화 를 능가하지 않고 IT 관리자에게 전화하여 인턴이 만든 앱을 지원하도록 요구할 것입니다.

이런 상황에서 회사가 도와주는 한 가지 방법은 언어에 구애받지 않는 것입니다. 앱 / 프로그램을 고려하기를 원한다면 선택한 언어 (java)로되어 있어야합니다. 일부 JQuery 또는 j에 대해 규칙을 약간 확장 할 수 있지만 중요한 요구를 충족하는 잘 구성된 애플리케이션이어야합니다. 정책 시트가 제공 될 것이므로 "내가 호스팅해야하는이 PHP 앱이 있습니다"라고 말하지 마십시오.

물건이 너무 커지기 전에 물건을 훔치는 것이 중요합니다. 일단 당신이 그것을 배우는 데 헌신하거나 그것을 다시 쓸 수있는 누군가가있는 것이 더 좋습니다. 일단 위의 큰 가발이 결정되면 그는 내 경험에서 그것을 없애지 않을 것입니다.

괴짜의 오만!

많은 경우 비즈니스 사용자는 도구를 사용하여 IT 직원이 이해하지 못하는 작업을 수행 할 수 있습니다. 이것은 본질적으로 나쁘기 때문이 아니라 비즈니스를 알고, 작동 방식 및 작동 방식을 알고 있기 때문입니다.

예를 들어, 소프트웨어 회사는 시장 데이터 피드에 (비용으로) 액세스를 최적화하는 응용 프로그램을 개발했습니다. 그들은 나중에 사용자가 스프레드 시트를 통해 최신 주가에 액세스 할 수 있도록 Excel 플러그인을 제공했습니다. 1 년 전과 제가 일했던 회사의 거의 모든 트레이더에게는 거래 전략을 지원하기 위해 하나 이상의 매우 복잡한 스프레드 시트가있었습니다. 매번 매크로에 문제가 생겨 IT 담당자 중 한 사람에게 도움을 요청했지만 대부분 거부했습니다. 비즈니스가 왜 우리를 미워하는지 궁금합니다. 그러나 여러 가지 기능 매개 변수 및 순환 참조로 기술적 문제를 해결할 수는 있지만 전체 스프레드 시트가 실제로 무엇을했는지 전혀 알지 못한다고 솔직하게 말할 수 있습니다. 그것들이 잘못 구성되었거나 프로그램이 잘못 되었기 때문이 아니라 거래자가 달성하려는 미묘한 점을 이해할 지식이나 경험이 없었기 때문입니다. 또한 표준 IT 프로젝트로 "적절한"프로그래밍 언어로 이러한 스프레드 시트 중 하나의 기능을 복제하기 위해 5 년제와 IT 프로젝트를 예상합니다.