분석이 기술에 구애받지 않아야합니까? [닫은]

어제 동료 중 한 명과 논쟁이있었습니다. 그는 비즈니스 분석가, 이전에는 프로그래머였으며 시스템 구현에 사용 된 기술을 알고 있어야 더 나은 디자인 결정을 내릴 수 있다고 생각합니다. 제 생각에는 (프로그래머입니다) 분석을 기술과 결합해서는 안되며 훌륭한 분석가가 구현 세부 사항에 대해 걱정하지 않고 훌륭한 디자인을 만들 수 있다고 생각합니다.

내가 그렇게 생각하는 것이 맞습니까? 비즈니스 분석가가 시스템을 구현하는 데 사용 된 기술을 알아야하는 이유가 있습니까?

편집 : 나는 말할 때 잘못된 용어를 사용했다고 생각합니다 business analyst. 건축 가나 시스템 분석가를 의미했을 수도 있습니다. 나는이 용어들에 익숙하지 않다. 원하는 경우 건축가 또는 시스템 분석가와 같은 것을 의미했습니다.

당신의 멋진 답변에 감사합니다! 나는 아직 경험이 많지 않아서 이것에 눈을 뜨게되어 기쁘다.

비즈니스 분석가가 특정 기능이 얼마나 중요한지 비즈니스 사용자에게 질문하는 것이 적절한 곳을 이해하기에 충분히 기술을 이해하는 것이 적절한 경우가 있습니다. 예를 들어, 새로운 응용 프로그램이 웹 기반 일 때 비즈니스가 팻 클라이언트 응용 프로그램의 동작에 익숙하다면, 팻 클라이언트에서는 사소하지만 비교적 어려운 "요구 사항"이 많이있을 수 있습니다. 웹 기반 응용 프로그램과 함께. 비즈니스 분석가가 비즈니스 요청이 개발 팀에게 사소한 것인지 또는 20 시간의 AJAX 개발을 포함 할 것인지 이해하는 경우,

특정 프로젝트에 대해 다양한 종류의 트레이드 오프를 수행하여 실제로 비즈니스를 만족시키는 수많은 요구 사항이있을 수 있습니다. 비즈니스 분석가가 어떤 트레이드 오프에 대해 잘 알고있을수록 비용을 최소화하면서 비즈니스에 대한 이점을 최대화하는 일련의 요구 사항을 제공 할 가능성이 높습니다.

이 문제의 양쪽을 모두 수행 한 후 분석가의 의견에 동의해야합니다. 기술의 기능에 대한 이해 부족으로 인해 극도로 열악한 디자인을 보았습니다. 경우에 따라 마케팅 과대 광고를 진실로 채택한 결과 일 수도 있습니다. 일반적으로 문제는 기술적 기능과 일치하지 않는 사양을 생성하는 것입니다.

분석가는 수행해야 할 작업,시기 및 작성자를 지정해야합니다. 그들은 왜 그것이 이루어지고 있는지 알아야합니다. 개발 우선 순위는 다른 요소보다 이유에 더 의존해야합니다. 설계 및 개발 팀은 방법을 처리해야합니다. 비용 효율적인 시스템을 개발하기 위해 분석가는 사용 가능한 기술의 한계를 뛰어 넘지 않는 측면에서 수행해야 할 작업을 지정해야합니다.

경계를 넓히면 여러 가지 방법으로 비용이 증가 할 수 있지만 경우에 따라 상당한 수익이 발생할 수 있습니다. 일부 비용 요소는 다음과 같습니다.

• 작업 솔루션을 개발하려면 실험이 필요할 수 있습니다.
• 전문 지식을 갖춘 신입 사원 또는 컨설턴트를 확보해야 할 수도 있습니다.
• 새로운 기술에 대한 교육이 필요할 수 있습니다.
• 개발 속도가 느려지고 버그 비율이 높아지는 경향이 있습니다. 과
• 더 많은 노력을 기울이면보다 즉각적인 가치를 가진 단순한 솔루션이 지연 될 수 있습니다.

사용될 기술이 알려진 경우, 설계를 작성할 때 분석가가 고려해야합니다. 다른 기술은 다르게 작동하며 이러한 차이를 고려하지 않은 디자인에는 문제가 있습니다.

그러나 비즈니스 분석가는 어떤 기술이 사용되는지에 대해 신경 쓰지 않아야합니다. 업무 규칙은 비즈니스 규칙을 수집하여 기술 팀이 이해할 수 있도록하는 것입니다. 시스템 분석가 / 건축가 / 디자이너 또는 그들이 부여 할 수있는 다른 이름은 비즈니스 분석가가 아니라 실제 디자인을 수행하는 기술이어야하므로 사용중인 기술을 알고 주변에 디자인해야합니다.

두 생각의 선 사이에는 아마도 더 현실적인 점이 있다고 생각합니다. 기술에 구애받지 않고 높은 수준의 디자인이 가장 좋을 수도 있지만, 디자인에 포함되어야하는 알려진 실제 제약 조건과 요구 사항을 고려해야합니다. 이 디자인은 어느 수준입니까? 충분한 요구 사항이 있습니까? 환경이 얼마나 유연합니까? 경영진이 특정 기술 방향에 투자하고 있습니까?

특정 방향으로 운전할 수있는 작동 매개 변수가 없습니까? 모든 기술 스택에서 솔루션을 구현할 수있는 광범위한 리소스가 있습니까? 다른 시스템에 액세스해야하는 상호 운용성 문제가 있습니까?

기술이 방정식의 일부 여야하는지 또는 설계가 기술 선택을 주도해야하는지 여부를 확실하게 말하기 전에 이러한 질문에 대한 답변이 필요합니다.

제약이없고 매우 높은 수준의 디자인이라면 디자인이 진정으로 무의미하다는 생각에 동의 할 것입니다. 그러나 20 년 이상의 경험에서 나는 선택을 제한하는 제약이 없었고 특정 기술이나 기술 가족을 향한 디자인을 이끌어 낸 상황이 거의 없었습니다.

이상적인 사용자 인터페이스는 사용자가 생각을 생각하고, 그들이 수행 원했던 것은 단순히 수행된다 할 것이다. 그보다 부족한 것은 우리가 처리 할 수있는 기술 제한으로 인해 어려움을 겪기 때문에 BA는 물론 시스템을 설계 할 수있는 컨텍스트를 이해해야합니다.

서로 다른 기술은 주어진 문제를 해결하기 위해 매우 다른 비용 및 효율성 구조를 가질 수 있습니다. 이러한 비용에는 해당 지역의 고용 비용, 특정 시스템의 에너지 및 냉각 비용, 기존 코드 및 기존 장비 재사용 가능성 등과 같은 것들이 포함될 수 있습니다. 항공 안전, 원자력 발전소 제어, 의료용 임플란트 등과 같이 다른 고려 사항만큼 중요하지 않은 비용과 효율성이있는 프로젝트를 수행하는 경우. 그러나 대부분의 비즈니스 상황에서 경영진은 잠재적 솔루션의 비용 구조와 시스템 구현의 이점을 고려할 수 있습니다.

비즈니스 분석 알아야 할 우리가 같이 개발하고 그런 종류의 응용 프로그램의 어떤 * / 웹 응용 프로그램 / 콘솔 응용 프로그램 / 모바일 응용 프로그램 등 응용 프로그램을보고 * 그래서 그녀는 더 나은 사용자에 좋은의 응용 프로그램에 대한 기능을 설정하거나 밀어 다시 가지고 올 수 있음 3 단계 중첩 드래그 앤 드롭과 같은 불가능한 기대치 (예 :)

그는 / 그녀는 하지 않는 한 알 필요가 자바 / C #을 / 파이썬 / SQL과 같은 기술 등

분석 프로세스 자체는 전적으로 기술에 구애받지 않아야합니다. 고객과 고객의 요구를 조사 할 때는 완전히 열린 마음으로해야합니다. 그러나 동전의 다른 측면은 분석가가 종종 권장 사항을 제공하도록 요청받으며 시스템 아키텍처도 처리해야 할 수도 있다는 것입니다. 이는 사용 가능한 기술에 대한 폭 넓은 이해가 중요한 역할의 전적으로 다른 측면입니다. 프로젝트를 시작할 수있는 능력뿐만 아니라 고객과도 큰 차이를 만들 수 있기 때문입니다. 고객의 장기적인 요구와 프로젝트 자체의 지속 가능성.

소프트웨어 설계의 대부분이 사용 된 기술에 관계없이 본질적으로 동일하다는 것은 사실이지만, 기술 선택에 따라 디자인이 영향을받는 영역이 항상 있습니다. 플랫폼 선택은 언어 및 API 선택에 영향을 줄 수 있지만 전문 지식, 지원 및 비용의 가용성은 선택에 영향을 미칩니다. 따라서 한 관점에서, 특정 기술의 영향을받지 않고 실제 분석을 수행해야한다는 입장의 일부가 정당하지만, 분석을 사용하여 설계를 결정하려면 항상 더 광범위한 기술 지식이 필요하므로 분석가가 권장 할 수 있습니다. 이를 통해 고객의 요구를 충족시키기위한 디자인을 적용 할 수 있습니다.

각 기술에는 한계와 제약이 있으므로 분석가가 이러한 한계를 고려하는 것이 합리적입니다. 반면에 .net을 잘 알고 있지만 90 년대 후반에 Java를 보지 못한 분석가는 Java (또는 RoR 등)를 사용하더라도 .net 용어 및 디자인 패턴을 사용하여 .net 솔루션을 설계 할 가능성이 높습니다. 문제에 더 잘 맞을 것입니다. 나중에 다른 기술에서 이러한 디자인을 구현하는 것은 상대적으로 어렵습니다.

따라서 기술을 아직 선택하지 않았지만 이미 선택한 경우에 경험이있을 때는 분석가가 불가지론 적이라고 생각합니다.