I'm a selftaught (web) developer. On sunny days, you can find me hiking through the Teutoburg Forest, on rainy days coding or with a good fiction novel in hand.
TL:DR:
Decide on PM style (agile for complex, waterfall for trivial)
Understand the problem. Do lots of interviews. Gather and maintain intel
Understand the solution. Use visualisations to get the big picture and start breaking it down
Write the code. It should be your final specification.
&It implements your technical solution for the functional problem of your client.
Below steps are vague. I try and follow them whenever I have access to the necessary resources. When in doubt, I cut back anywhere, except for the buffer time.
0: General project management
Always depends on your project's complexity. Using the following matrix to estimate what's it gonna be always turned out to be a good idea
Collect as much intel as you can.
It's (often) the least fun part to gather and collect. Unfortunately, also the most crucial one. Interview the heck out of your stakeholders. Take time to put things in order. Ask questions. Try to get the functional side of the story.
Tools to use:
For business cases with workflows, use BPMN2.0 (e.g. with Camunda, Draw.io, Excalidraw)
For business cases with a lot of complex, nested sequences (imagine the worst if-else hell you can), use a supporting spreadsheet with a matrix showing all cases.
A written collection of business units (like users, ERP resources, systems) you must consider. Bonus points if you cover interfaces. Extra bonus points if you're able to embed them into your flowcharts (1). Tools to use: Draw.io/Excalidraw, I saw mermaidjs can do ER- models, but never tried it myself.
A document that enriches the above resources with details and holds them as references (= Functional Specification). This is ideally x-checked by your client's IT-guys, given there are any.
If you're doing UIs, map out some wireframes. Use powerpoint to make it interactive if you figure your client is a visual learner.
Communicate these documents early to the guys building the project so they can wrap around the case! If they see a flowchart for the first time in step 2, it's too late
The more you cover and write down here, the better. You probably won't cover all cases initially, but can always extend.
Time spent on this one: 30-35% of the estimated project time. This includes refinement of the above documents, user feedback and manual testing.
Technical planning
You'll know you did a good job in step 1 if your
Workflow diagram(s) translate into your code's control flow
Business units translate into your project's data structure
Functional specification translates into a technical document supporting these two
What's left to do is how your software fits into the big picture. A good method I've applied once before is the C4 - Model. Like the above documents, once you've built its foundation, you can extend and refine it with little worries.
I've read a concept here called the Critial Path, which also seems like a good idea at this point.
Once you've done got a clear view about structure, flow and data, you can start planning out class diagrams. If you're using a new technology, you can start prototyping.
Communicate these documents with the dev team and gather feedback!
Time spent on this one: 15-20% of the estimated project time.
Start the development workflow
If, at this point, you haven't written a single like of code, that's good. You took the time to understand - and possibly already solved - the problem. Now write that code. This includes:
Actual development of modules, classes and features
Writing (at least unit-) tests
Write & refine technical documentation based on the documents in step 2
Time spent on this one: 25-30% of the estimated project time
Now you'll have 15-30% of time left. Depending on the size of your project, you'll want to spend another 10% on roll-out and implementation.
The rest is your buffer. Use it for unexpected trouble, problems during go-live, unplanned client meetings, (un)expected leave of colleagues, and so forth. These events show up as amen does in church and cost a lot of miles towards the deadline.
WOW!! This is really great stuff
I like the fact that you start the actual development so late in the whole timeline and give ample time for the, like you said, the least fun but crucial stuff.
Fortunately, the clients we work with do a lot of the heavy lifting during this phase. Our team is more focused on technical side only, but reading the part about gathering feedback from dev team
Communicate these documents with the dev team and gather feedback!
This has left me wondering if we could make the whole process more of a to and fro thing instead of one way
I’m so excited to start using this knowledge in our project
Thanks a lot!
I'm a selftaught (web) developer. On sunny days, you can find me hiking through the Teutoburg Forest, on rainy days coding or with a good fiction novel in hand.
yw. if you can, please let me know how it worked for you. I'm not getting the chance to put all tools out at once very often and will appreciate some field-feedback :-)
Yeah, I’m hoping to write a second part for this post with parts we’ve implemented in our day to day process.
But you might have to wait some time since we’re all a bit new to this and things might take some time to get fully used to.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I think you got the basic process right
Below steps are vague. I try and follow them whenever I have access to the necessary resources. When in doubt, I cut back anywhere, except for the buffer time.
0: General project management
Always depends on your project's complexity. Using the following matrix to estimate what's it gonna be always turned out to be a good idea
Tools to use:
Communicate these documents early to the guys building the project so they can wrap around the case! If they see a flowchart for the first time in step 2, it's too late
Time spent on this one: 30-35% of the estimated project time. This includes refinement of the above documents, user feedback and manual testing.
You'll know you did a good job in step 1 if your
What's left to do is how your software fits into the big picture. A good method I've applied once before is the C4 - Model. Like the above documents, once you've built its foundation, you can extend and refine it with little worries.
I've read a concept here called the Critial Path, which also seems like a good idea at this point.
Once you've done got a clear view about structure, flow and data, you can start planning out class diagrams. If you're using a new technology, you can start prototyping.
Communicate these documents with the dev team and gather feedback!
Time spent on this one: 15-20% of the estimated project time.
If, at this point, you haven't written a single like of code, that's good. You took the time to understand - and possibly already solved - the problem. Now write that code. This includes:
Time spent on this one: 25-30% of the estimated project time
Now you'll have 15-30% of time left. Depending on the size of your project, you'll want to spend another 10% on roll-out and implementation.
The rest is your buffer. Use it for unexpected trouble, problems during go-live, unplanned client meetings, (un)expected leave of colleagues, and so forth. These events show up as amen does in church and cost a lot of miles towards the deadline.
WOW!! This is really great stuff
I like the fact that you start the actual development so late in the whole timeline and give ample time for the, like you said, the least fun but crucial stuff.
Fortunately, the clients we work with do a lot of the heavy lifting during this phase. Our team is more focused on technical side only, but reading the part about gathering feedback from dev team
This has left me wondering if we could make the whole process more of a to and fro thing instead of one way
I’m so excited to start using this knowledge in our project
Thanks a lot!
yw. if you can, please let me know how it worked for you. I'm not getting the chance to put all tools out at once very often and will appreciate some field-feedback :-)
Yeah, I’m hoping to write a second part for this post with parts we’ve implemented in our day to day process.
But you might have to wait some time since we’re all a bit new to this and things might take some time to get fully used to.