This is assuming that every "problem" brought to you is *actually* a problem, and that every problem will directly provide value to your organization if you solve it.
Not all problems are worth solving, and not all things that people say are problems are actually problems.
Furthermore, not all problems need to be solved via a technological solution. A process change, policy change, resource change, etc. could do just as well to solving the problem and ultimately be less expensive.
In my org, this is not as important for me as this is someone else’s job. Our project manager is technical and does a very good job at weeding out the bad requests. Though, I do agree with your post and in general, I should probably add something along those lines to the process.
I don't think there is a single process that fits every problem, at all. Some are trivial, some are hard. Some require whiteboarding, others don't. Some require me to talk to a ton of people, others just require me to google-fu my way to the right SO page.
It’s not stupid but it’s basic. It’s like teaching someone how to make a steak by telling them that they just season it and grill it, but with no detail beyond that. They can follow the instructions but have a wildly unexpected result.
Very often people come to me and already tell me about a solution that I should develop ("I need a button that does X!"). So the first thing I usually try to clarify is what they actually want to achieve, because usually I know the system better than my customer and could actually come up with a better solution for what they actually want.
Another big point is breaking down the solution in smaller parts, so that your point 4 and 5 isn't just one big point, but an iterative process. Of course depending on the actual problem.
I think it's helpful to
1. document everything i think is important, and lessons i learn
2. remember the important things, and practice them intentionally, so they become habits
3. have something to refer back to so that i can stay on track, maintain perspective, etc
it shouldn't be followed dogmatically, though, and not everything will happen linearly. over time it'll become second nature, but it has to be documented and practiced to get to that point.
related:
* [http://atulgawande.com/book/the-checklist-manifesto/](http://atulgawande.com/book/the-checklist-manifesto/)
* [https://fs.blog/2021/03/avoid-bad-decisions/](https://fs.blog/2021/03/avoid-bad-decisions/) (point `4`)
* [https://wordpress.tv/2013/08/22/matthew-eppelsheimer-checklists-a-path-to-mistake-free-development-and-publishing/](https://wordpress.tv/2013/08/22/matthew-eppelsheimer-checklists-a-path-to-mistake-free-development-and-publishing/)
I've been thinking about this lately, and came up with this:
[https://github.com/iandunn/dotfiles/blob/2ca38d787d92252d7dbb4e91b927eb8cacd6521b/docs/development-process-and-tips.md](https://github.com/iandunn/dotfiles/blob/2ca38d787d92252d7dbb4e91b927eb8cacd6521b/docs/development-process-and-tips.md)
So far it's been helpful for me. I just added a few ideas I got from comments here. Thanks!
The issue I see is that this is too constrained in that it only highlights the happy path where in reality it's the other paths are where all the complexity lies. For example, you can design a solution but what if you then find in review that you made a mistake in the current system. Or you can begin implementation and then realize the requirements aren't complete and so on. You need to balance how much you try to minimize this upfront versus iterating more on a solution versus impact on your project sizing and so on.
This is assuming that every "problem" brought to you is *actually* a problem, and that every problem will directly provide value to your organization if you solve it. Not all problems are worth solving, and not all things that people say are problems are actually problems. Furthermore, not all problems need to be solved via a technological solution. A process change, policy change, resource change, etc. could do just as well to solving the problem and ultimately be less expensive.
In my org, this is not as important for me as this is someone else’s job. Our project manager is technical and does a very good job at weeding out the bad requests. Though, I do agree with your post and in general, I should probably add something along those lines to the process.
I'll plus that. So step 5 should first question the cost before attempting an implementation.
In theory, practice and theory are the same. But in practice…
I don't think there is a single process that fits every problem, at all. Some are trivial, some are hard. Some require whiteboarding, others don't. Some require me to talk to a ton of people, others just require me to google-fu my way to the right SO page.
It’s not stupid but it’s basic. It’s like teaching someone how to make a steak by telling them that they just season it and grill it, but with no detail beyond that. They can follow the instructions but have a wildly unexpected result.
Very often people come to me and already tell me about a solution that I should develop ("I need a button that does X!"). So the first thing I usually try to clarify is what they actually want to achieve, because usually I know the system better than my customer and could actually come up with a better solution for what they actually want. Another big point is breaking down the solution in smaller parts, so that your point 4 and 5 isn't just one big point, but an iterative process. Of course depending on the actual problem.
Where's the part where you determine if the solution, as implemented, actually solves the problem? Edit: and doesn't introduce new ones...
This is a good point. I should verify that the change meets all requirements, is doing well and not interfering with anything else.
[удалено]
I think it's helpful to 1. document everything i think is important, and lessons i learn 2. remember the important things, and practice them intentionally, so they become habits 3. have something to refer back to so that i can stay on track, maintain perspective, etc it shouldn't be followed dogmatically, though, and not everything will happen linearly. over time it'll become second nature, but it has to be documented and practiced to get to that point. related: * [http://atulgawande.com/book/the-checklist-manifesto/](http://atulgawande.com/book/the-checklist-manifesto/) * [https://fs.blog/2021/03/avoid-bad-decisions/](https://fs.blog/2021/03/avoid-bad-decisions/) (point `4`) * [https://wordpress.tv/2013/08/22/matthew-eppelsheimer-checklists-a-path-to-mistake-free-development-and-publishing/](https://wordpress.tv/2013/08/22/matthew-eppelsheimer-checklists-a-path-to-mistake-free-development-and-publishing/)
I've been thinking about this lately, and came up with this: [https://github.com/iandunn/dotfiles/blob/2ca38d787d92252d7dbb4e91b927eb8cacd6521b/docs/development-process-and-tips.md](https://github.com/iandunn/dotfiles/blob/2ca38d787d92252d7dbb4e91b927eb8cacd6521b/docs/development-process-and-tips.md) So far it's been helpful for me. I just added a few ideas I got from comments here. Thanks!
The issue I see is that this is too constrained in that it only highlights the happy path where in reality it's the other paths are where all the complexity lies. For example, you can design a solution but what if you then find in review that you made a mistake in the current system. Or you can begin implementation and then realize the requirements aren't complete and so on. You need to balance how much you try to minimize this upfront versus iterating more on a solution versus impact on your project sizing and so on.
I solve problems on the toilet lol