I tried, and I really enjoyed it. But this does not care - the main thing that readers liked. Those who stopped reading long ago began to return, branding me a graphomaniac. And another good man advised me to write a brief summary for each old article. I agreed and now, in between, I am writing these shorties. He called them shorts.
I bring to your attention several such shorts, according to several publications. Suddenly you will find something useful for yourself.
The cat died, the tail peeled off
Meetings very often fail. Gathered, battered, parted.
Results, or products of a meeting, are decisions. Here they are usually not. And if there is, it is not always of good quality.
If the meeting is limited in time, and the decision must be taken, then it (the decision) is of poor quality.
If the meeting is not limited in time and lasts until a decision is made, then any decision is made if only the meeting ended.
If a decision is invented at a meeting, then it will be made - simply because the brain values what it comes up with.
Understanding the poor quality of the solution will come later, but it will be too late.
To make an effective decision, it is better not to participate in the discussion, but to silently observe.
First, the brain will not be busy thinking up answers.
Secondly, there is no need to make a decision.
After the meeting, you can calmly ponder and make a decision. It will be better.
Key: at the meeting, keep quiet and listen. So that others do not worry, say that this is a conscious position.
→ habr.com/en/post/341654
Latent parasites
Fundamentally, there are two approaches to setting goals and controlling performance: parasitic and symbiotic.
The symbiotic approach is to make the problem be solved.
The parasitic approach is to make the task NOT solved.
The symbiotic approach is direct and straightforward, but difficult to implement. Therefore, it is rare.
The task is set so that everything is clear - and goals, and resources, and limitations.
Control is carried out so that the task is precisely solved.
The symbiotic approach is to leave part of the responsibility (and more) for solving the problem on the stage director.
The parasitic approach is florid and cunning, but easy to implement. Therefore, it is common.
The task is set so that nothing is understood. The less clear the better.
Control, preferably not at all.
There is no responsibility on the task director; the whole “monkey” is transplanted onto the performer’s neck.
The purpose of the parasitic approach: manipulation, FSW, self-affirmation. Therefore, it is often found in the work of mentors with novice employees.
Better, of course, a symbiotic approach.
→ habr.com/en/post/343696
Dimensions vs Illusions
If you evaluate the process and the results of your activity without measurements, then you will be mistaken all the time.
Evaluation without numbers depends on the mood. Bad mood - it will seem like you are not working well. A good mood is the other way around.
So you can sit and work badly for a week, and on Friday give the result “to the mountain”, and it will seem that the whole week went well.
Fundamentally, there are two types of metrics: quantitative and alternative (better known to programmers as Boolean).
"The task is completed on time" - this is Boolean. This is the same as “Detail fit” (an alternative sign of quality when they cannot be measured in numbers).
“We work well”, “We are fulfilling the plan”, “I am well done” - also Boolean.
On estimates such as Boolean, the control process is difficult to build. It is recommended that you switch to quantitative metrics as quickly as possible.
Boolean breeds bureaucracy and formalism. For example, the fulfillment of tasks on time can be achieved by increasing the time, inventing tasks for themselves, and carrying out an IDB.
To manage based on Boolean indicators, you need to spend a lot of time - for meetings, analysis, etc. Because there is too little information.
It is recommended to measure both the process and the result. Then the picture will be the most complete.
For programmers, the "Poker Planning" method from Scrum is recommended.
→ habr.com/en/post/343910
This is Sparta
Suppose you are a programmer, and they brought you a serious task. And you think that it is not necessary to solve the problem - it is stupid, harmful.
Typical behavior in such a situation: bring the task to a public field. Send to coordinate with the boss, start the internal project, fix it in the system, etc.
At this point, everything breaks. The person who brought the task does not want to be considered a fool. And once they went into a public field, they will defend themselves.
It is important for a person not to lose face, in the political sense. The main thing in politics is never to admit your mistakes. You can do nothing, but the main thing is not to have recognized errors.
A man will do his best to prove that a programmer is a villain, an idiot, an opponent of change. And the programmer will still have to solve the problem.
In some cases, a person will arrange everything so that the programmer does not solve the problem at all. Then the person will be “white”, and the programmer - absolutely “black” (and resisted, and failed in the end).
There are several solutions.
The first is to become a business programmer, to understand related fields, and to determine what needs to be automated there and how.
The second is the article by the Chief for Change. For example, development director.
The third is not to arise, and just do what they say.
Fourth - the Path of Sparta, quick rejection of decisions. It is better known as fail fast, fail cheap (get out quickly, get out cheap).
The main thing is not to include publicity. To tell the person - let's not spend a lot of time, we will make a prototype, and see if the solution is viable or not.
The prototype will take a little time. In case of success, both will get their own - both a normal decision and political points.
In case of failure, no one will suffer. Well, a person will be better for a programmer.
→ habr.com/en/post/344650
Surrogates
Business does not like 1C and its products, web developers, QMS, accounting, economists, development projects, Scrum, CBT, controlling, KPI and motivation systems.
Business loves increasing profitability through automation, increasing turnover from Internet promotion, improving product quality, a simple and clear picture of the business in numbers, forecasts of the state of the company, a real increase in efficiency, accelerating projects 2-4 times, a multiple increase in profits and a decrease in inventory , an accurate management system, a clear and understandable system for assessing the state of affairs in business, a labor assessment system that allows dismissing half of the managers.
Business loves achieving business goals. Business does not like surrogates.
A surrogate is when they asked to achieve a business goal, but received an automation project, a website, a pile of paper, a staff of obscure employees or unreadable foot-reports.
A surrogate is when a goal on the road is replaced with a means of achievement. And they forgot about the goal together.
Surrogate production is based on three pillars: formalism, gradualism and mutual responsibility.
Formalism is the transfer of goals to paper with decomposition. But in fact - the translation of the focus of attention from a large target into small details. Nobody remembers the goal anymore - everyone discusses the details.
Gradualism is a low rate of transition from goals to means. At first, the goal is still sometimes discussed. But gradually, step by step, is mentioned less and less. Until the customer himself forgets about it, drowning in the details.
Mutual responsibility is that all contractors operate approximately the same. There is not a single automator that really increases profit. Therefore, the customer especially and there is no way out.
What to do
Avoid surrogates and the first step towards their creation: formalism. At least on internal projects. Set a goal and talk with the performer about it constantly. On the scale, resources, plans, etc. - also. But the main thing is about the goal.
Otherwise, the focus of attention will certainly shift, and you will get another surrogate.
→ habr.com/en/post/344844
Jeb Klitschko
There is such a boxer - Vladimir Klitschko. He has a feature - the constant use of jab. Well i.e. more permanent than other boxers.
Jeb constantly keeps the opponent in suspense, exhausting.
Key features of Jeb Klitschko: ease of execution (relative, of course) and constancy.
The fact that constantly performed, useful, but simple actions can bring many benefits, say many authors.
I decided to try it too. I made a simple accounting system - which jabs I made today.
It was at the factory. He made Jebah at lunch (I don't have lunch), i.e. 1 hour a day. He did what others do not (they say it leads to success).
I set up checks on a self-learning system, came up with ideas for development, implemented other people's ideas for development, set up auto tasks, refactored and optimized the code.
Every day - any task from this list. He did one task - handsome. You can have a few.
Observations led 3 months. During this time, he made 30 checks, came up with 200 ideas, realized 80 other people's ideas, built automated processes in two departments, made three cool optimizations.
Cool. Well this is "between things." I recommend to everyone.
→ habr.com/en/post/344934
Flexible surrogate
The word “Scrum” refers to at least two entities: philosophy and the framework.
The philosophy, or approach to work, is described in a book by Jeff Sutherland.
Framework, i.e. the algorithm of actions described in a document called the Scrum Guide.
Philosophy turned into a framework because the authors of philosophy wanted to make money on it (in their own words).
The framework is greatly simplified compared to philosophy. The main thing is that the goal has been simplified, or rather thrown out.
The purpose of philosophy: accelerating the achievement of results. Moreover, at times. There are 8 times acceleration examples in the book.
The goal of the framework is to have Scrum. It says so: do according to the instructions - you have Scrum, violate the instructions - you do not have Scrum.
The framework does not imply accelerating the achievement of the result, in general.
People who teach or implement Scrum work with the framework. They tell and implement an algorithm that does not lead to any results, except for “we now have Scrum”.
The point is clear. Philosophy is very difficult to sell. The framework is simpler.
A framework is a product. He, as expected, passed the "packaging". It is simple, understandable, there is support and many specialists. Doesn’t resemble anything?
Everything is good, except for the result - it is not there.
If the customer is not familiar with the Scrum philosophy, then the implementation of the framework will suit him perfectly.
If the customer is familiar with the Scrum philosophy, then he will be disappointed with the implementation of the framework - there will be no acceleration in achieving the result.
It will be cool, fashionable, modern, but no business goals will be achieved (except for the development of the budget for “something new”).
How to be? Learn the philosophy of Scrum. It is based on the Japanese philosophy of quality management, the essence of which is: measurements and endless improvements.
Unfortunately, there you have to think, experiment, observe and, alas, work a lot. If this does not suit you, take the framework.
→ habr.com/en/post/345540