What an EXCELLENT question!
Ready! --- FIRE! --- Aim.
The easy part of the answer is to build a workflow before converting it to a macro or an app. If it looks like it's going to be a macro calling another macro, I'll likely build some very limited functioning workflows and prototype nominal data flowing through the modules before I add any complexity to the work. I'd build a K.I.S.S. (keep it simple) prototype before diving into complexity.
I like to understand the need and value of the workflow first and don't always need requirements to do that. What features are needed (agile methodology) to deliver value comes first. After understanding the concept I like to start at the beginning of the process and understand the data being accessed. The building of the workflow is usually very linear. In that way, yes I will gather minimum requirements first, sketch (mental or physical) a flow and go forward. I work in small sprints within an agile framework. It is important (if requirements are not fully vetted) to have reviews with your product sponsor at the end of each sprint. Some of the complexities you'll know up-front, some will appear as you code, and some will appear as testers find your 'bugs'. Some of the complexity will disappear as your knowledge grows and you realize that the complexity is quickly solved with Alteryx.
I try to simplify the complex by breaking it down to logical components. If you can use peer-programming techniques and walk others through your design/code this will force you to simplify your workflow. My mentor would ask me to explain the process as though I was talking to my Mom. Granted, my Mom would likely be yawning throughout the explanation but it would help me to make sure that the modules could be maintained by others in the future.
When I look at other people's workflows I try to resist having them do it "my way", but rather look to understand their approach to the problem. Problem one is to get the right result. Once you achieve that, you can always improve on the performance and the simplicity of the solution. Don't worry about having the elegant solution to the complex problem in your first iteration. Looking back at work I did months ago, I'll scratch my head wondering why I ever approached the problem that way. The bottom line is to set aside time to improve performance and to simplify the workflow in a later phase.
In summary, get enough of an understanding to start the work. Where you need help for the complexity look for help online or through resources like this community. Open up Alteryx and build a simple prototype. Share your findings and where you see the complexity see if someone else might have a different approach to assist you. Avoid waiting to know everything. The people writing the requirements will only write what they know to be the requirements. Once you're involved and looking at the data, you'll be asking some very intelligent questions. For project management, do estimate the effort in small units of work and measure yourself (better or worse) against the estimates. Ask for help when you need it. Do your best work and keep your commitments. Agile frameworks value people over processes and working products over documentation.
Leverage your insight into asking a question like this by applying that consciensousness into your work and I'm certain that you'll be delivering value.
Much thanks for the question. I hope that this helps.
Mark
Alteryx ACE & Top Community Contributor
Chaos reigns within. Repent, reflect and restart. Order shall return.
Please
Subscribe to my youTube channel.
