I really like Dmitry Potapenko. With him you can not find a lot of videos on YouTube, but I reviewed everything. If someone does not know, this is a person, the owner of about 15 store and restaurant chains, does business in Russia, Bulgaria and the Czech Republic, 7000 people work under it, the total turnover is $ 140 million per year. Up to the heap, in the past - the two-time world champion in karate, at the age of 25 became the vice-president of Grundig for the CIS. In general, a cool man.
Having watched the video, I found a lot in common in project and launch management with what Dmitri sets out. I would like to write down and sum up. In general, I like to apply principles from completely incompatible, at first glance, spheres, to solving difficult problems - often it gives very beautiful and simple solutions.
Strategy is more important than tactics
Strategic miscalculations cannot be compensated by tactical successes. On War, von Clausewitz
')
The same can be said about the project. We chose a desktop application instead of writing under the Web - a huge miscalculation. They chose the wrong sphere and threatened a huge amount of funds for it - not to realize it. Chose the wrong priority for the functional for a month, a competitor overtook you - again, the loss can be critical. They chose the wrong technology - instead of writing the fast PHP language in the "right" type of Java - again, they lost their starting speed, before they even went into orbit.
By the way, the strategy is an excellent defense against any clever people who will copy your project. See a good article that will help protect your product from thieves.
Employee salary must be floating
An employee must have goals, out of seven words, with measured digital indicators. As Drucker said, everything that can be measured can be controlled. Thus, it is possible to put the dependence of an employee's efficiency on specific tasks, and to get rid of the problem that employees came at 9, went to 18, although the work is not completed. You want to get a lot - bring the tasks to the end, you want even more - work efficiently and again a lot. You want to get nothing - well, ok, sit on Facebook.
Potapenko offers a cool technique, long known, by the way. Each employee has a set of indicators - seven words with digital indicators. ZP is tied to the values ​​of these indicators. That's all. For example, this is a superposition of 10 indicators for a programmer and his manager - project stability, user satisfaction. By making the contribution of one or another indicator more or less, you indicate to the programmer (and his manager) what to emphasize. And people see that they are judged by the result. Of course, there must be a guaranteed salary below which a person will not receive.
The manager must know the price of his minute
The leader must know how much his minute is worth. As in a direct relationship, in terms of its income, and indirectly - as they say in economics, the value of a lost opportunity that appears when a manager does not do what he needs.
Become your customer
Potapenko says that a whole year he lived in the Czech Republic and Bulgaria as a simple person, trying to understand his client. Get used to his role. I already wrote about this, this is the most important thing in project management, understanding the end user. If you do not know how to think, get used to the role of your user, everything else will be wrong: the wrong functionality and the wrong interface prototype will be followed by lost hours and money in the form of the work of designers, programmers, testers and other specialists. Note - I'm not saying that you need to listen to your users, because they are not professionals in the design of projects. The point is to immerse yourself in the role of your user, while remaining professional in the development of the project, and make a user-friendly interface. For, as Ford said, if I listened to my clients, I would hardly have had to give them something more than a little faster and more resilient horse.
Knowing the skin of the end user allows you to see what is important to do now and how exactly it needs to be done, and what can not be done at all, or put it off for a long time.
Think of the risks in advance
When Potapenko was rendered an office at zero (for once a week a consultant came to Dmitry who had long worked in another firm and took in the other firm the original documents, which are in six copies in many places, and this firm now passes on some case), the next day, none of the company quit (and it was on Saturday), and large clients (including Leroy Merlin) were shipped all on time. That's what risk management means.
In essence, this is part of the strategy. There must be a plan for everything so that when the bjaka happens, you don’t waste your time surprisingly, but act on the nakatan clearly and calmly. I especially recommend 9 rules of conducting IT business in Russia.
From my experience, this is, for example, when one of the key employees leaves. The first couple of years of work as a manager, I was shocked, then I just measured how much my risk was accurately calculated in terms of interest and timeframe.
Quick and easy - it means cheap and cheerful
Potapenko prescribes business processes with algorithms, as I understand it, at the level of an eighth grade textbook on computer science. I agree with him - so far the processes known to me completely fall into the classic flowcharts with a cycle and a conditional operator. Everything is complicated, with rare exceptions - from the evil one
Further, Potapenko describes everything in the business processes to the details, to the point at which the cashier should smile at the client.
And at one seminar, where he criticizes the CEO convincingly, his phrase sounds - the people in the Russian Federation are dying out, there is no staff to be found, so what do you rely on smart employees, and McDonalds bypasses you, sharpened by biorobots?
Plus, Seliger says that if you make a network object, you should immediately make the first object according to the network principle. At the same time, making (the principle of SPOT / DRY programming) at one point is something expensive and making it cheap at the expense of outsourcing - for example, the kitchen.
It fits perfectly in the development of startups. People are starting to make a product - it doesn't matter whether it is a new DBMS, an online store for the sale of combers for assholes or automation of financial flows. Intelligent and confident in their professionalism, they think that throwing static prototypes and user stories is a substitute for live data and livelihood in the role of the user. Immediately done on the budget of a couple of millions in six months, a large, stupid, useless shit that drowns once again.
The question is - what's the matter, why don't the cool methodologies work when everyone is grown-up and the professionals seem to be working?
The answer is that you cannot develop a complex project without live data, without feedback on live data. Any complex project is always made with an error; the more complex the first version is, the longer it will take and the higher the error. So, you need to minimize the complexity and thereby reduce the error.
As a result, shit guys get around smart guys like 37signals, who do a minimum of functionality, look through the eyes of end users, immediately roll it out to users and intelligently collect feedback.
That is, the simpler the development process, the faster the version rolls out, the more the first iteration is similar to all further ones - the run-up will be the product. As an online store, the first iteration should have an input - these are initial guesses, what it should look like, and the output information - the difference between speculation and reality, on living data.
Why live data and working prototype (first versions of the project). Because as soon as in any beautiful web layout instead of ispum dolor, insert 100 kb multi-colored texts that the client will insert, as well as 20 menu items - everything becomes different. As soon as instead of clickable HTML from Akzur you see a working search engine with a table that displays 50,000 entries, it immediately becomes clear how you need to filter and what sortings to add. This can not be foreseen on paper. The human brain is too weak to model such entities.
No, of course, I do not deny, you can successfully do big projects, use RUP, and be successful. But if we are talking about a young industry - project management in IT, as a rule - on the Web, I would strongly doubt that it is advisable to act with a traditional approach (even with Agile, but without micro-iterations, fast versions and immersion into the user's role).
And in large projects I remember, I saw the following in some article. Once, airport builders built a model nearby. Prototype. Living people were allowed in there, they studied how they walk, how they behave. The engineers themselves went, studied the pros and cons of various options. As a result, they passed the project on time and reduced the budget by an order of magnitude, in contrast to similar construction projects, where everything is done large and complex at once (and we get ugrebishnye, all of us known airports).
Watch the movie in the subject of how to build an airplane on the fly. Very accurately reflects the idea.
Another idea from Potapenko is universal standardization and transparency of every human action. A la staff bioroboty. I will not deny that the standards for coding, writing articles on a wiki, mandatory comments for commits, and others can save you thousands of hours in different situations.
Startup is a business
Any startup, unfortunately, is a business. If you do not take successful units, in the project it is important to minimize costs. This, incidentally, also applies to speed. You want to write a task manager in C ++, with a cool OOP architecture, so that it can withstand a million requests per second - honor and praise to you. At the same time, in order for people to sit in the same room in an elite business center, everything was done according to the coolest methodologies, all the walls are hung with UML.
But I would not be surprised if such a team, which the investor will have more than one million, will bypass a couple of friends who have accumulated half a million hauls, and releasing a new version of task manager in C # every week. At the same time having remote programmers from all regions of the Russian Federation and Ukraine. Then these people will earn money and rewrite it from scratch. But the first stage is to take off, and take off quickly, due to constant feedback from users, quickly rolling out simple solutions.
Apply ideas from other areas
Potapenko asks the hall: what do you think is the largest retail chain? Mcdonalds? Wallmart?
Wrong answer! The correct answer is the Catholic Church!
No need to be shy to look at how similar processes are arranged in structure, inventions, problem solving in other areas. And, all the more, one should not think that the task, which now stands and seems to be unsolvable, has not risen before anyone. It is always helpful to think in analogies. This often helps to simplify the original task and make it at least partially.
Work hard
This is stupid, but - you need to work a lot. Personally, I work an average of 12 hours a day, 6 days a week. If you work efficiently, at the same time the number of results in a unit of time increases dramatically. Then come the quality. If you want a car - throw away this idea, it is better to rent an apartment near work (or an office near a house, if your business). A car is an asset that falls in value. And your time spent in traffic jams is a non-renewable resource, the cost of which, if you know your minute, can exceed a hundred times the imaginary “comfort” of a car for a year. But when there will be an extra couple of millions - you can buy a car. IMHO, of course.
Outsourcing expensive process sites
Agree - it is better to jerk a superspecial for piecework a couple of times a month than to keep such a frantic salary and not to know how to load it. Therefore, the expensive aspects of the work need to be outsourced and grouped (in networks, the kitchen is usually taken out - Single point of truth from programming works here too).
Conclusion
Write your experience of applying principles from other areas in project management in the comments.