Agile manifesto (human remix)
In the management of large web projects, the principles of the classic American project management are most often applied - the clever creation of a work plan and its precise implementation. Strict reports, tricky graphics and presentations at the power point (exaggerate).
As an opposition, more and more often they put the principles of Agile software development , where programmers who are lazy for documentation (I exaggerate) put code writing and the final product as priorities.
I have never been an ardent fan of the first method, but I have many contradictions with the second. Interested in management theory, I wrote my own vision of the famous agile manifesto - Agile manifesto (human remix). Deciphering the four ideas of the manifesto from the position that we are all human. Even if we work for money.
')
The classic project management teaches you to plan ahead for possible changes to the project. And mainly it concerns negative situations - risks, delays, siding. But imagine that, in the midst of working on a project, there were previously unknown opportunities to improve it: new mechanisms appeared, closed resources or information became available. Ignore the gift of heaven, or redraw the entire plan of the collar to eversion? But the choice can directly affect the competitiveness and profit of the final product.
The answer is that project management was not created to manage web projects. Environmental change on the Internet is much more common than in construction or commerce. Call me a lousy manager, because I rarely complete a web project on the time frame I gave before starting work. I do this not arbitrarily: all bosses are faced with a choice - either we go on schedule and look at competitors from the bottom up, or we increase the time n-twenty times and at the same amount increase profits.
Bosses are going to change and extend the deadlines. Web projects, in fact, have no deadlines. With rare exceptions, there are no hard deadlines, and all dates are an invention of common sense, budget constraints, and personal customer wishes. If you have a reason - do not be afraid to change deadlines, do not be afraid to change anything.
The discussion of this point smoothly flows from the previous one - whatever the contract, there is always a situation when its non-fulfillment is beneficial to both parties.
If you are a freelance photographer, and because of your illness you could not go to the Alpine mountains to shoot mountain goats. The contract says “take a picture of mountain goats” and you can literally execute it in the nearest zoo, but who needs such an implementation of the contract? Maybe better to break the deal? Customer advise another photographer and do not sully their reputation.
Or the opposite situation with the classic example, when the client asks "to change the color to neutral blue." Every second designer angrily nods at the signed layout with a brown scale and does not want to hear about the changes. It looks funny when it comes to the homepage. But if the client is the owner of a large social network, and he fired that manager who signed the brown layout a year ago, it’s more profitable for the designer to do a supercontract effort.
Most people in the web business claim that they like their work, that money is not the only criterion. So be human! Look not at a piece of paper with a contract, but at the interlocutor. Swear, argue, persuade, believe, deceive and take offense. Live!
And first of all it concerns ordinary project workers. In the classic project management there is a nasty man-hour unit. Through this unit all key project deadlines and most of the budget are calculated. But to trust the main document to abstract values ​​is the same as selling golden sand with zhmenky.
In web development, you work with designers — who are inherently van gogh artists — and programmers — who are even more crazed and frivolous mathematics-Einstein. What kind of system, what processes and rules can you talk about in this wild society? Forget it!
I said a thousand times and I repeat: I, as a manager, do not have three full-time abstract programmers. I have Eric, Ahmet and Serezha - living people with all their strengths and weaknesses. When I calculate the terms of the project, I do not have man-hours, but I have Eric on Skype. When I issue a task, I do not have a “task form in the Excel format” - I explain everything to Sergey on my fingers.
These three fictional characters, but in my practice there is a perfect example in exact figures:
A bild editor worked on one of the news sites. The duty of the Bild Editor is to draw illustrations to the news. Since there is a lot of news, illustrations did not go to everyone, but only to the elect. Before I joined the project, the bild editor even recorded the contract: 2 illustrations per day, and the editor-in-chief points out the news being drawn. So the man sat in the office, giving out ten pictures in a week.
After my appearance in the project and acquaintance with the bild editor, I redid the contract. I removed the obligatory limit in two pictures and gave the artist the right to choose the illustrated news himself. The man felt freedom, relaxed, and during the year gave at least eighteen pictures a week. Efficiency - 180% for the same money and with unchanged quality.
I'll tell you another, sad but true story:
Six years ago, finishing work in one of the projects, I wrote a comprehensive guide to my successor. A list of all the problems and their solutions, tips on optimizing and further upgrading, addresses, turnout-passwords and weak points of key officials are a lot of work, because I really wanted a long life for my brainchild.
The change of manager went perfectly, and the project did not stall for a second. Two months later, the lead programmer left and the project died.
I love the documentation, I write tons of instructions for all who need and do not need, I believe that the web is one big documentation. But unlike the adherents of the church project management, I do not give the office a key role. I have seen many projects — and these were large, profitable projects — that were created in anarchy mode. I saw how many companies - working on the system - simply could not cope with growth and time.
But also to the programmers who are following agile manifesto, I cannot relate myself - not that character. And yet I am the head of web projects.
Yesterday I found out why that lead programmer left the project. He was bored after my departure! We never were friends with him, argued, complained to the authorities about each other, helped in business - we just maintained human relations in communication. And I could not write such a simple instruction to my successor - “be a man”.
As an opposition, more and more often they put the principles of Agile software development , where programmers who are lazy for documentation (I exaggerate) put code writing and the final product as priorities.
I have never been an ardent fan of the first method, but I have many contradictions with the second. Interested in management theory, I wrote my own vision of the famous agile manifesto - Agile manifesto (human remix). Deciphering the four ideas of the manifesto from the position that we are all human. Even if we work for money.
')
Reaction to change is more important than following a plan.
The classic project management teaches you to plan ahead for possible changes to the project. And mainly it concerns negative situations - risks, delays, siding. But imagine that, in the midst of working on a project, there were previously unknown opportunities to improve it: new mechanisms appeared, closed resources or information became available. Ignore the gift of heaven, or redraw the entire plan of the collar to eversion? But the choice can directly affect the competitiveness and profit of the final product.
The answer is that project management was not created to manage web projects. Environmental change on the Internet is much more common than in construction or commerce. Call me a lousy manager, because I rarely complete a web project on the time frame I gave before starting work. I do this not arbitrarily: all bosses are faced with a choice - either we go on schedule and look at competitors from the bottom up, or we increase the time n-twenty times and at the same amount increase profits.
Bosses are going to change and extend the deadlines. Web projects, in fact, have no deadlines. With rare exceptions, there are no hard deadlines, and all dates are an invention of common sense, budget constraints, and personal customer wishes. If you have a reason - do not be afraid to change deadlines, do not be afraid to change anything.
The reaction to changes in the plans - one of the advantages of man over robots.
Cooperation with the customer is more important than contractual obligations.
The discussion of this point smoothly flows from the previous one - whatever the contract, there is always a situation when its non-fulfillment is beneficial to both parties.
If you are a freelance photographer, and because of your illness you could not go to the Alpine mountains to shoot mountain goats. The contract says “take a picture of mountain goats” and you can literally execute it in the nearest zoo, but who needs such an implementation of the contract? Maybe better to break the deal? Customer advise another photographer and do not sully their reputation.
Or the opposite situation with the classic example, when the client asks "to change the color to neutral blue." Every second designer angrily nods at the signed layout with a brown scale and does not want to hear about the changes. It looks funny when it comes to the homepage. But if the client is the owner of a large social network, and he fired that manager who signed the brown layout a year ago, it’s more profitable for the designer to do a supercontract effort.
Most people in the web business claim that they like their work, that money is not the only criterion. So be human! Look not at a piece of paper with a contract, but at the interlocutor. Swear, argue, persuade, believe, deceive and take offense. Live!
"Do you want me to throw the tape recorder into the water?" Ok, I'll do it. " (Did not)
Personalities and their interactions are more important than processes and tools.
And first of all it concerns ordinary project workers. In the classic project management there is a nasty man-hour unit. Through this unit all key project deadlines and most of the budget are calculated. But to trust the main document to abstract values ​​is the same as selling golden sand with zhmenky.
In web development, you work with designers — who are inherently van gogh artists — and programmers — who are even more crazed and frivolous mathematics-Einstein. What kind of system, what processes and rules can you talk about in this wild society? Forget it!
I said a thousand times and I repeat: I, as a manager, do not have three full-time abstract programmers. I have Eric, Ahmet and Serezha - living people with all their strengths and weaknesses. When I calculate the terms of the project, I do not have man-hours, but I have Eric on Skype. When I issue a task, I do not have a “task form in the Excel format” - I explain everything to Sergey on my fingers.
These three fictional characters, but in my practice there is a perfect example in exact figures:
A bild editor worked on one of the news sites. The duty of the Bild Editor is to draw illustrations to the news. Since there is a lot of news, illustrations did not go to everyone, but only to the elect. Before I joined the project, the bild editor even recorded the contract: 2 illustrations per day, and the editor-in-chief points out the news being drawn. So the man sat in the office, giving out ten pictures in a week.
After my appearance in the project and acquaintance with the bild editor, I redid the contract. I removed the obligatory limit in two pictures and gave the artist the right to choose the illustrated news himself. The man felt freedom, relaxed, and during the year gave at least eighteen pictures a week. Efficiency - 180% for the same money and with unchanged quality.
On one free-thinking Rambo accounted for half a hundred enemy soldiers who blindly carried out the orders of the generals.
Running software is more important than complete documentation.
I'll tell you another, sad but true story:
Six years ago, finishing work in one of the projects, I wrote a comprehensive guide to my successor. A list of all the problems and their solutions, tips on optimizing and further upgrading, addresses, turnout-passwords and weak points of key officials are a lot of work, because I really wanted a long life for my brainchild.
The change of manager went perfectly, and the project did not stall for a second. Two months later, the lead programmer left and the project died.
I love the documentation, I write tons of instructions for all who need and do not need, I believe that the web is one big documentation. But unlike the adherents of the church project management, I do not give the office a key role. I have seen many projects — and these were large, profitable projects — that were created in anarchy mode. I saw how many companies - working on the system - simply could not cope with growth and time.
But also to the programmers who are following agile manifesto, I cannot relate myself - not that character. And yet I am the head of web projects.
The project managementa system with its reports-tables-graphs is, as it were, a blue matrix tablet. Free agile-programmers with their talent and dislike for the system - as it were, the red tablet Neo. Are there options?
Yesterday I found out why that lead programmer left the project. He was bored after my departure! We never were friends with him, argued, complained to the authorities about each other, helped in business - we just maintained human relations in communication. And I could not write such a simple instruction to my successor - “be a man”.
Source: https://habr.com/ru/post/121281/
All Articles