Coding for non-coders
Practical habits non-coders can use with AI coding tools to reduce risk and build maintainable, reliable solutions.
You’ve sold your product or service into a client. They’ve trusted you enough to get you in to look at what they need, and are paying you to work through a process to help them understand their next steps.
Normally, what I’d do in this situation is to run a face-to-face discovery workshop - led by your solutions architect or consultant.
This has a three-fold aim:
Sometimes a workshop like this will just last a day, but often it’s longer. Much depends on the complexity of the project. But the critical thing is it must be face-to-face. Whilst it’s tempting to do this virtually, you will find that this causes major problems further down the line, as you just won’t have the quality of relationship needed to solve problems together.
So here’s how I run things - remembering that this is a generic agenda, and is likely to need adapting for specific circumstances.
There are all sorts of ways to run through this agenda. My approach is to try to make it as interactive as possible, using group work exercises to get people talking and thinking.
| Item | Expected outcomes | Leader |
|---|---|---|
Set the scene |
Agreement on the agenda |
Supplier team |
Introductions |
Who is in the room? |
Supplier team |
|
What are the problems we're here to solve? NB. Don't skimp on this - it's important! |
Background to the project |
Client team |
Project vision statement |
An agreed 2 sentence statement of the form:
For: «target user» |
Supplier team |
Product capabilities |
A shared understanding of the existing capabilities of your product or service |
Supplier team |
User journeys |
What will the users do? |
Supplier team |
Integrations |
Map out the integration points with other systems |
Supplier team |
Identify items for work |
A list of key functional areas that need to be developed |
Supplier team |
Project approach |
A shared understanding of how the project will be managed (eg. Waterfall, Kanban, Scrum |
Supplier team |
Identify priorities |
All the items from the lists of work items in order of importance to the client |
Supplier team |
All the Discovery outputs should be created, written up and agreed during the Discovery workshop. This saves time in the long run, as everyone is engaged and committed to the outputs.
What you then have is a set of work packages (agile: epics or user stories), which can be estimated (Agile) or costed (Waterfall) in order to move on to the next stage of the project.
If you need help to run your next Discovery workshop - either as a client or a supplier please get in touch.
If you'd like to discuss this article, or how I can help you, get in touch.
Posted: 17 May 2017
Tags: Project management Project management Coaching
Practical habits non-coders can use with AI coding tools to reduce risk and build maintainable, reliable solutions.
Eight step process to reduce the risk of buying software that doesn't work
Resources to aid the move
You've got your Moodle site setup and configured to meet your organisation's needs. So now it's time to introduce your team to it.
Three things which have made the greatest contribution to my personal professional development:
The following is a summary of advice taken from a number of sources (links below) on how to run an online conference.