Agile manifesto (human remix)

    In the management of large web projects, they most often apply the principles of the classic American project management - scrupulous creation of a work plan and its precise implementation. Strict reports, tricky graphics and presentations at the power point (exaggerate).

    As an opposition, they increasingly put the principles of Agile software development , where lazy documentation programmers (exaggerate) put code writing and the final product in priority.

    I have never been an ardent fan of the first method, but I have many contradictions with the second. Interested in control 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.

    Responding 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 basically it concerns negative situations - risks, delays, sidings. But imagine that in the middle of working on a project, previously unknown opportunities appeared to improve it: new mechanisms appeared, closed resources or information became available. Ignore the gift of heaven or redraw the whole plan of the scruff of the neck for an eversion? But the choice can directly affect the competitiveness and profit of the final product.

    The solution is that project management was not created to manage web projects. Changing the environment on the Internet is far more common than building or trading. Call me a lousy leader, because I rarely finish a web project on the dates I gave before starting work. I do this not arbitrarily: all the bosses are faced with a choice - either we follow the schedule and look at the competitors from the bottom up, or we increase the time by a factor of n-twenty and increase the profit by the same amount.

    Bosses go for changes and extensions. Web projects, in fact, have no deadlines. With rare exceptions, there are no hard deadlines, and all dates are fiction of common sense, budget restrictions and personal wishes of the customer. If you have reasons - do not be afraid to change the deadlines, do not be afraid to change anything.

    Reaction to changes in plans is one of the advantages of man over robots.

    Collaboration with the customer is more important than contractual obligations

    The discussion of this item smoothly flows from the previous one - whatever the contract, there will always be a situation where 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 pictures of the mountain goats” and you can literally execute it at the nearest zoo, but who needs this contract? Maybe it's better to break the deal? Advise another photographer to the customer and not stain his reputation.

    Or the reverse situation with the classic example, when the client asks "change color to neutral blue." Every second designer angrily nods at the signed layout with a brown gamut and does not want to hear about the changes. It looks funny when it comes to the home page. But if the client is the owner of a large social network, and a year ago he fired the manager who signed the brown mockup, it’s more profitable for the designer to fulfill the contractual effort.

    Most people in the web business claim that they like their job, that money is not the only criterion. So be human! Look not at the piece of paper with the contract, but at the interlocutor. Swear, argue, persuade, believe, deceive and be offended. Live!

    “Do you want me to throw a tape recorder into the water?” Well, I will do it. ” (Did not)

    Personalities and their interactions are more important than processes and tools

    And first of all it concerns ordinary workers of the project. The classic project management has a nasty unit of man hours. Through this unit, all key project dates and most of the budget are calculated. But to trust the main document with abstract values ​​is the same as selling gold sand with zhenyas.

    In web development, you work with designers - who are essentially van Gogh artists - and with programmers - who are even more crazy and foolish mathematicians, Einsteins. 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 again: as a leader, I do not have three abstract full-time programmers. I have Eric, Ahmet and Seryozha - living people with all their strengths and weaknesses. When I calculate the terms of the project, I don’t have man hours, but I have Eric on Skype. When I give out the assignment, I don’t have an “excel-format task form” - Seryozha I explain everything on my fingers.

    These three are fictional characters, but in my practice there is a great example in exact numbers:
    On one of the news sites worked bill editor. The duty of the build editor is to draw illustrations for the news. Since there is a lot of news, the illustrations did not go to everyone, but only to the elite. Before I came to the project, the editor-in-chief even wrote in the contract: 2 illustrations a day, and the editor-in-chief indicates the drawn news. And so the man sat in the office, giving out ten pictures in a week.

    After I appeared in the project and became acquainted with the build editor, I redid the contract. He removed the mandatory limit of two pictures and gave the artist the right to choose the illustrated news himself. The man felt freedom, relaxed, and during the year gave out at least eighteen pictures a week. Efficiency - 180% for the same money and with the same quality.

    One freethinking Rambo had half a hundred enemy soldiers blindly following 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 an exhaustive guide to my successor. A list of all the problems and their solutions, advice on optimization and further modernization, address-passwords, appearances and weaknesses of key officials is a huge job, because I really wanted a long life for my brainchild.

    The change of manager was excellent, and the project did not stop for a second. And two months later the lead programmer left and the project died.

    I love documentation, I write tons of instructions to everyone who needs and does not need, I think that the web is one big documentation. But unlike the adherents of the project management church, I do not give the office a key role. I saw a lot of projects - and these were big, profitable projects - that were created in anarchy mode. I saw how many companies - working on the system - simply simply could not cope with growth and time.

    But to programmers following agile manifesto, I cannot attribute myself - not that character. Nevertheless, I am the head of web projects.

    The project managementa system with its reports, tables, graphs is, as it were, a blue matrix tablet. Freedom agile programmers with their talent and dislike for the system - as it were, the red pill Neo. Are there any options?

    Yesterday I found out why that lead programmer left the project. He got bored after I left! We had never been friends with him, argued, complained to the authorities about each other, helped in business - we simply maintained human relations in communication. And I could not write such a simple instruction to my successor - “be a man”.

    Also popular now: