워크플로우란 무엇인가

워크플로는 마이크로플로에 비해 더 높은 추상화 수준에서 프로세스를 정의하는 방법입니다. 이는 조직 내에서 정기적으로 실행되는 일반적인 비즈니스 프로세스를 관리하고 확장하는 방법입니다. Studio Pro 내부의 마이크로플로와 시각적으로 비슷해 보이지만, 일반적으로 몇 시간에서 드물게는 몇 년 동안 사용자나 시스템에서 실행하는 작업에 더 중점을 둡니다. 작업에 더 중점을 두므로 각 작업과 워크플로의 전반적인 상태를 세부적으로 제어할 수 있습니다.

그들은 도구 상자에 있는 다양한 도구를 사용하여 이를 달성하는데, 이를테면 단계를 건너뛰고 다른 사람이 실행을 완료했는지 확인할 때까지 기다린 후에 다음으로 진행할 수 있는 방법 등을 들 수 있습니다.

그리고 평범하지 않은 일이 있다면 항상 나만의 마이크로플로를 사용하여 툴박스를 확장하고, 심지어 새로운 워크플로를 트리거하여 변화하는 시나리오에 빠르게 적응할 수 있습니다.

이 모든 것이 마이크로플로우에서는 가능하지 않은가?

네. 이게 제가 오랫동안 혼란스러웠던 부분입니다. 마이크로플로우로 모든 것을 달성할 수 있지만, 워크플로우가 때때로 모든 관련자에게 프로세스를 더 좋게 만듭니다.

워크플로를 사용하지 않고 프로세스를 구축하는 것은 가능하지만, 모든 것을 수동으로 구축하려면 프로세스가 효과적으로 관리되도록 하기 위한 신중한 계획과 추가 노력이 필요합니다. 마이크로플로만 사용하여 상태를 관리하고, 알림을 보내고, 보안을 처리하고, 탐색하는 경우... 비슷한 결과를 얻을 수 있지만, 워크플로를 사용할 때보다 복잡성이 더 커지고 기본 제공 지원이 줄어듭니다.

이러한 복잡성은 프로젝트를 함께 진행하는 다른 사람들이 이해하기 어려운 혼란스러운 혼란을 만들어낼 수 있으며, 나중에 애플리케이션을 유지 관리해야 할 수도 있습니다. 워크플로는 프로세스를 순서대로 명확하게 배치하기 때문에 일종의 자체 문서화이며, 따라서 여러 단계에 걸친 프로세스를 명확하게 문서화하는 쉬운 방법입니다. 워크플로는 개발 시간을 절약할 수 있지만, 가장 큰 이점 중 하나는 워크플로를 사용하여 빌드된 앱을 유지 관리하는 데 드는 시간을 절약함으로써 팀과 조직에 제공됩니다.

워크플로가 좋은 아이디어인 경우

워크플로가 필요한 경우나 유용한 경우를 판단할 때 고려해야 할 몇 가지 사항이 있습니다.

워크플로는 대규모 프로세스를 정의하고 개략적으로 설명하는 데 가장 적합하며, 이는 장기간에 걸쳐 발생할 수 있고 일반적으로 많은 단계가 있습니다. 좋은 예로 보험이나 다른 유형의 계약에 대한 견적을 받는 것이 있습니다. 초기 접촉, 정보 수집 및 견적 생성이 있으며, 고객은 신청을 완료하기 전에 제안을 수락하거나 거부해야 합니다. 이는 인간과 시스템 작업을 모두 포함하는 명확하게 정의된 프로세스입니다.

또한 자주 바뀌지 않는 프로세스입니다. 시간이 지남에 따라 회사는 다양한 옵션이나 신제품을 제공할 수 있지만 견적을 받고 수락하는 프로세스는 크게 바뀌지 않습니다.

시스템 및 사용자 작업이 혼합되어 있는 경우 워크플로를 사용하는 것도 고려해야 합니다. 보험 정책의 예에서 고객은 일반적으로 이메일을 통해 전송되는 특정 면책 조항 및 준수 문서를 수락해야 합니다. 사용자 또는 고객의 작업을 기다리는 시스템에서 이메일을 트리거하는 것은 워크플로에 내장된 병렬 분할 및 대기 기능을 사용하여 간소화됩니다.

또한 프로젝트를 여는 모든 사람이 쉽게 이해할 수 있는 명확한 의사결정 트리를 만들어 프로세스를 자체 문서화하는 추가 이점이 있습니다.

워크플로를 사용하지 않는 경우

위의 기준을 준수하지 않는다고 해서 워크플로를 사용할 수 있는 자격이 즉시 박탈되는 것은 아니지만, 몇 가지 위험 신호가 나타날 수 있습니다. 그러나 워크플로를 사용해서는 안 된다는 명확한 지표가 몇 가지 있습니다.

• 프로세스가 미래에 변경될 가능성이 있는 경우. 예상치 못한 결과를 동반하는 예측 불가능한 작업의 특성은 워크플로 상자에 잘 맞지 않습니다.
• 프로세스가 예측 불가능하고 올바른 결과를 달성하는 데 더 집중하는 경우 워크플로의 경직성은 많은 가능한 결과를 수용하지 못할 것입니다. 명확한 목표나 목적지를 갖는 것이 바람직합니다.
• 사용자가 최상의 경로를 결정하는 데 높은 수준의 자유도가 필요한 프로세스는 작업 흐름의 엄격한 제약에 잘 맞지 않을 수 있습니다.

요약하자면, 자주 반복되고 워크플로에 설명된 표준 프로세스에서 벗어나지 않는 예측 가능한 프로세스에는 워크플로를 사용하는 것이 가장 좋습니다.

그것들은 독점적이지 않습니다

워크플로에 대한 제 의견을 바꾼 가장 큰 이유는 둘이 하나가 아니라는 걸 깨달았기 때문입니다. 둘 다 애플리케이션에 넣을 수 있고 넣어야 합니다. 앱이 틈새 시장이라 상자에 맞지 않을 거라고 생각할 수도 있지만, 모든 앱에는 워크플로에서 흔히 볼 수 있고 쉽게 정의할 수 있는 프로세스가 있으며, 더 복잡한 비트의 경우 마이크로플로가 항상 옵션입니다.

보험 견적의 예를 다시 들어보겠습니다. 보험에 가입한 사람이라면 누구나 그 과정이 어떤지 알 것입니다. 담당자는 귀하의 세부 정보를 수집하고, 라이프스타일과 위험에 대해 질문하고, 귀하의 세부 정보를 제출하여 인수를 요청한 다음, 제안된 견적을 수락하거나 거부한 다음 전체 거래를 확인하고 문서화하기 위해 이메일을 발송합니다. 이는 사용자와 시스템 기반 작업을 명확하게 혼합한, 변경되지 않는 명확한 단계입니다. 이 과정은 일반적으로 완료하는 데 몇 분에서 최대 1시간이 걸리며, 사용자가 시스템 외부에서 작업을 수행하기 위해 잠시 애플리케이션을 떠나야 할 수도 있습니다(계정 확인을 위해 이메일을 여는 것).

이를 위해 완전히 사용자 정의 솔루션을 구축할 수 있지만, 프로젝트에서 수백 개의 문서를 빠르게 생성하게 되고, 이를 신중하게 제작된 마이크로플로가 섞인 단일 워크플로로 쉽게 대체할 수 있습니다. 워크플로만으로 전체 앱을 만들 필요는 없지만, 워크플로로 대체할 수 있는 명확한 프로세스를 찾으면 본인과 다른 사람들이 프로젝트를 더 쉽게 유지 관리할 수 있습니다. 개발 중과 개발이 끝난 후 모두 시간을 절약할 수 있습니다. 이 경우 마이크로플로와 워크플로는 모두 용도와 이점이 있으며, 둘 다 포함하지 않으면 더 나은 애플리케이션을 만드는 기회를 놓치게 됩니다.

내가 변화에 저항했던 이유

워크플로를 피한 이유는 워크플로가 무엇인지에 대한 오해 때문이라고 생각합니다. 워크플로는 마이크로플로를 직접 대체하는 것이 아니라 복잡한 프로세스를 대규모로 구성하는 더 효율적인 방법입니다. 마이크로플로를 대체하기 위한 것이 아니라 마이크로플로를 사용하여 비즈니스 프로세스를 지원하는 방법에 대한 프레임워크와 구조를 제공하여 향후 프로젝트를 유지 관리하고 변경하기 쉽게 만듭니다. 효율성을 개선하기 위한 것이지만 가장 큰 효율성 향상은 프로젝트의 초기 개발 이후에 이루어지며 주로 프로세스를 간소화하고 뒤따르는 개발자에게 더 읽기 쉽게 만드는 것과 관련이 있습니다.

내가 만든 앱 중 일부를 돌이켜보면, 워크플로를 사용하기로 했다면 나와 다른 사람들의 시간을 많이 절약할 수 있었을 겁니다. 항상 그랬듯이 앞서 나가는 것보다 새로운 것을 이해하는 데 시간을 보내는 것이 더 합리적일 때가 있습니다.