Iterative approach to solving engineering problems

Well, I lived to see the day when I was drawn to write to this blog.
Good day, habrachelovek!

It so happened that many of the inhabitants living on the glorious Habré are somehow connected with the development . By development, I mean a slightly wider and abstract term here than writing programs. Development is primarily a creative action, a creative process. At the entrance of this process is a thought, an idea, and at the exit is a tangible product, the brainchild of a developer. The final product can be anything: website, design, program, smart device, smart home, etc.

Having become accustomed to some independence in my actions and without disdaining to make decisions, I often create problems for myself and set myself tasks that I have to solve. This, in fact, earn a living with bread and butter. Having won over a number of successfully solved tasks and having spent a lot of time on it, the banal thought came that every time you encounter the same sequence of steps to solve them, during the passage of which you step on the same rake. Rubbing his bruised forehead once again, my hands finally decided to put an end to this state of affairs and began frantically writing something into the sclerotic. As a result, a clever plan was born to combat the cones on the forehead, which over the past few months has saved me a certain number of man-hours. Details on the cut.

')
Imagine a standard for the engineer situation - an idea appeared in our brain. She was born herself, was thrown up by sympathetic comrades or injected by the customer of another crazy project - the mechanism of its appearance in the brain is not important. Suppose the idea is: “Happiness to all, for nothing! And let no one leave offended! ”(C). Usually, from the formulation of the idea it is obvious that we want to get in the end. But it is not obvious how we want to achieve this. This is where the task appears. The task of implementing the idea.

Tasks need to be addressed. So learned in school. But how to take up this smooth person without a single clue? We feel the confusion caused by ignorance of what specifically needs to be done to solve the problem. So,
I suggest the following algorithm. Immediately I will mention that I do not pretend to originality here, perhaps a similar campaign has already been described elsewhere, but I have never met it before.


The starting point will be the formulation of the problem (“get some happiness for everyone”). We will assume that we are working on a project for its production. So what should be done first to complete it? To begin with, it is necessary to formulate how the customer represents the output project (in this particular example, the whole of humanity, in the general case it could be an employer or even ourselves). That is, to identify external requirements for the project . In our case, everything is simple - every inhabitant of the globe should become happy. In the general case, the result of this step may be a couple of pages of text containing the most general information about the final goal . In the case when the result is difficult to describe in general phrases, you can resort to describing the desired through the way it is used by end users (users should see two buttons “more happiness” and “share happiness with neighbors.” When you press button 1 ... etc. ).

So, it is already better, since half the work has been done - we have started to work! What's next? Next, you need to explore the subject area in which you have to work. The purpose of this stage is to get acquainted or update in memory the ways of working with the entities of this subject area, learn to talk and think in terms of the problem being solved. The end result of the second stage is the conversion of the general requirements obtained in step 1 into clear subtasks for achieving these requirements. In our case, it might look something like this: “Happiness ... What is it and what is it eaten with? Happiness is a state of mind achieved with a favorable combination of external and internal factors affecting a particular individual. Children make happy ice cream, lovers - kisses, politicians - power, system administrators - backup. Therefore, the following is necessary: ​​to build factories for the production of power, to provide children with ice cream ... "

Great, now we know exactly what needs to be done to complete the project. But what if the project risks delaying for a long time? Or if we are working on it with a whole team? The third step is to bring order to the heap of information that we collected at the previous stage and specify (yes, write down!) The formulated subtasks. So, we make the maximum decomposition of subtasks and highlight the sequence of actions to solve minimal tasks that can no longer be broken down into components (something like: "... we need factories for the production of happiness. To do this, we need workers. Workers need to be trained. : we take 20 promising high school students and ... "). Specifying subtasks is serious, difficult and partly tedious work. But it has several advantages in itself - firstly, this is an implicit design. It often happens that when you write what you are going to do (and not immediately rush into the code with the keyboard at the ready), some subtleties are revealed that were missed as a first approximation, useful architectural decisions are made and simplifying further development is made. And some tasks have to be abandoned. =) Secondly, it allows you to more accurately estimate the labor costs for the implementation of the conceived, because the smaller the amount of work is estimated, the more likely it is to further name the correct dates for its implementation. And thirdly, when there are approved specifications, it is easier to avoid the temptation to infinitely improve existing features and add new ones, delaying and delaying the launching moment of the project. In fact, it is difficult to determine in advance what exactly the users will need and what possibility will determine the popularity of the product in the future. First you need to start with a certain minimum set that ensures viability, and only then add new functions based on the real needs of users. The result of this step is a document containing a description of subtasks and how to solve them.

Finally, we are closer than ever to the most beloved - to the actual implementation. But we are not in a hurry - at first it is necessary to estimate the time it will take to complete each subtask separately. By this time, we have already maximally simplified our lives, having written specifications, it remains only to put down the numbers (“Make the people of Australia happy - 48 hours, Albania - 32 hours, America - 72 hours ...”). The main goal of this stage is to try to drive each of the subtasks into some time frame. In fact, despite the existence of a huge number of methods for planning and estimating labor costs, this stage is very abstracted from reality and it would be more correct to put not parrots, not hours, but next to numbers, but some approximation will be obtained. And this approximation will be more accurate with each subsequent iteration (about which we have not said a word yet). The result is project schedules .

Well, here comes the sweet moment when you need to work with your hands. Feel free to grab the keyboard, hammers, soldering irons and other tools and implement our plans and described. We are at the implementation stage. The result will be a code, chip, device, whatever, but - only a trial version . Here a fork in the road appears - does our offspring satisfy what we talked about so long ago at stage 1? If yes - safely sum up the results and send it to adulthood. But at the first attempt to answer “yes” to this question very rarely succeeds. Most likely, after all the stages described above, we only realize that we now understand better what we wanted to achieve as a result of what we need to do in order to realize the idea and achieve the goal . What do we have as a real result of the implementation phase? Clearer, informed, tested in practice, requirements born in battles! Well, have you guessed it? Feel free to stage 1! The first iteration was successful, congratulations, colleague!

Conclusion

The described method is the essence of a tool that allows a uniform approach to the solution of any technical problem, minimizing the stage of confusion. Iteration and division into stages within each iteration allow maximum concentration on each of the tasks. And concentration is the key to quality and success. The truth is to remember that the best is the enemy of the good, so excessive perfectionism should still be avoided.
Good luck in your endeavors, friends!

UPD: The user iason offered to look in the direction of TRIZ :: ARIZ, which has such an interesting scheme . All together we stamp and study.