Abstracting 'Activities' in the World
When you abstract things, it becomes easier. Yes, easier.
What makes it easier is that it becomes simpler to understand, and you no longer need to memorize specific know-how as 'knowledge'; instead, you can rely on the reuse of fundamental 'understanding'.
Once you decide to 'do' an activity, the flow—if you distill the necessary tasks for the simplest and most reliable success into an abstract form—might look like the following.

This uses a UML (Unified Modeling Language) activity diagram. 'Activity' literally means 'action' or 'task,' and an activity diagram means a diagram representing such activities.
Whether it is an individual activity or a group activity, and whether it is work, sports, or play, when abstracted, everything becomes the same as or similar to this diagram.
It must be so.
Naturally, project activities in software development are the same. When providing education, whether the recipient is a newcomer or a veteran, it was almost the same.
Perhaps, if even one of these actions is missing, it will inevitably cause some kind of harm. For example...
- If you do not gather information in advance, you will lose even the battles you could have won.
- If it is an activity that involves or affects someone else, rather than just yourself, failing to confirm things beforehand could lead to unexpected accidents.
- If you act haphazardly without a plan, the probability of failure will jump significantly.
- If you do not execute, you will not get results.
- Not reflecting means you are not putting your experience to use.
Play, cooking, travel, work, sports, etc... no matter what you do, if you want to achieve solid success, you must apply this framework. Of course, those who want to fail again can simply take a path that deviates significantly from this diagram.
However, people who are not in the habit of thinking for themselves will likely make excuses here like this:
'It is impossible to gather all information in advance'
'Sometimes work proceeds without confirmation or approval'
'Not everything goes as planned or follows the established path'
Because the above framework is a framework, it removes fine, specific details. How to translate this into means and methods depends on the individual or the organization. Therefore, it is natural to optimize (tailor) it according to the situation.
If conditions are not met, you adjust them to make them easier to meet; if they still aren't met after adjustment, you change the method to one that doesn't require those conditions. If there is no such convenient method, you adjust the schedule, and if even that is difficult, you involve all stakeholders, including the client.
"Purpose" and "Goal"—as long as you do not lose sight of these, you only need to optimize the many 'means' prepared to satisfy them.
Actions are always performed to achieve a "purpose" or "goal", so you should not easily change the "purpose" or "goal" so that the actions themselves do not become meaningless. Changing them would mean losing the identity of the action itself.
Even so, for those who still find it difficult to 'think for themselves', if we break it down a bit more concretely, it would look like the following, for example.

If it is a case where preliminary preparations do not proceed as planned, it would look like this. I think this is generally how most project activities end up. If you keep adding your daily experiences little by little like this, it seems like you could eventually create a perfect framework.
By the way, for me, most of my behavioral algorithms are set like this, and for things not in the defined options, I consider them each time, and I keep adding both successes and failures to expand it. That is why, from the second time onwards, I can make decisions in no time. For the first time, I don't know which one will be a failure, so I charge in without hesitation.
- Customer requirements are not fixed (specifications are not decided)
- Agreement with the customer is difficult to obtain
- Responses from other vendors are not returned
These are cases where, despite the schedule being affected by such things, you cannot just stop, so you have no choice but to proceed with the progress, prepared for rework.
Even in your private past,
'Neglected to collect preliminary information'
'Did not confirm with stakeholders'
'Started without a plan'
I am sure you have had similar troublesome situations due to these. Even if it is clearly not your own responsibility, it is the responsibility of the manager or leader in charge of schedule management to adjust the schedule until the last minute and minimize the impact by the deadline.
Even so, compared to the simple flow mentioned earlier,
'Execution and management according to schedule' and
'Schedule management and adjustment of remaining tasks'
the burden of having to perform these in parallel is not just two or three times greater. If you cannot do this, not only will your ability as a manager be seen as low, but it will also place a considerable burden on your members, and in some cases, it could even disrupt your private life.
Actually, the hardest part of management is this parallel task management. That is precisely why it is meaningful to place importance on how thoroughly you do preliminary preparations,
- Are there any flaws or shortages in preliminary information?
- Is the consensus building with stakeholders, including customers, sufficient?
- Has a plan with a clear outlook been sufficiently considered?
Whether you want to proceed with work in a simple flow or proceed with difficult work in a complex flow, only the manager can decide that.
For example, newcomers and those with insufficient experience will not be entrusted with being a leader or manager early on. However, if you are willing, you should be able to see the way predecessors (seniors and bosses) work and manage very closely.
How difficult does it get depending on how you proceed?
How much easier does it get depending on how you control it?
It would be good to watch every move they make and learn while you can. First, you should try to make efforts to be able to perform such control over your own actions and activities. At first, it is fine to just imitate what you see.
Even just managing your own work (called self-management),
it should require considerable effort.
However, a person who cannot even manage themselves can never manage a large group of people, including others. It is very important to watch the methods of your predecessors from now on and learn even a little at a time.
Many of you who are new to the company will likely say,
'That may be true, but let's start with the actual work first.'
'If I can't do the bare minimum in my actual work, I won't have the bandwidth to spare for anything else.'
You will say this, and these issues will be pushed to the back burner. And I think two or three years will pass while you forget that such themes even exist. You will be working in your assigned department, but the superiors you have there will not necessarily always be paying attention to these kinds of things.
You need to manage these tasks yourself without forgetting them.
To that end, it is a good idea to diagram these work flows. Then, while repeating your mistakes, you should update and expand the diagram little by little. If you do that, someday you will create an activity flow that 'does not fail (only succeeds).'
Furthermore, if you keep it abstract rather than too specific, you will be able to apply it elsewhere as well. You will no longer need to memorize things one by one individually.
Modeling/abstraction is also a very important skill for training youradaptability. If you have the opportunity, I think it would be good to practice it.
いいなと思ったら応援しよう!
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。