Features and risks of a major web project. How to build a work between the client and the developer
How to define a great project?
What is a big project? How is it different? What is dangerous and what is interesting?The truth is that for each client and developer's big project is the concept with different content.
A big project is a unique ordering, creating new risks for both sides.
New risks — so you don't have proven in practice technology for dealing with such risks. What is a big project?
We have formulated a number of grounds:
run is carried out in several stages.
Phased commissioning always involves greater risks than start for 1 admission. The experts point out that the maximum duration of one stage is 3-6 months. With longer stages accumulate the changes, the negative side of the waiting customer, changing priorities, everyone is tired and running becomes more problematic.
project exceeds the previous by more than two times.
This criterion applies to the customer and the developer. If the client has previously requested the web-site, ordering large online shop and communication with the developer for him will be full of surprises. Similarly, a developer is almost impossible without serious missteps to do the project in excess of your past experience more than half.
the new features of the idea or technology.
Untested idea or technology, which are pinning high hopes is always a risk. A simple rule of thumb: a new technology for the first time always REDUCES efficiency. A new idea, and worse, casts doubt on all undertakings.
the
big project
Project management is a reduction in the probability of occurrence of risks. In a large project risks in particular:
Major project — always policy
Large site, web-design, automation changes the logic of business. It is always a revolution.
So, there will be people who will suffer from the introduction that are NOT interested in starting the project.
Project participants from the client side are always multiple, and spurious power, their efforts in fighting each other, always create additional problems
the Uncertainty of requirements and the range of estimates
In this unit we will talk about the risks of the client.
A big project so great that it has a lot of unresolved issues.
At the initial stage, the task is usually described only in General terms, which is totally understandable and normal
On the other hand, when deciding about the start of the project and the selection of a contractor supervisor always wants to know very accurately the time and cost of the project.
And this is not. What to do?
The common practice of collecting proposals from different artists.
The accuracy of such a review is always very low even in the presence of TK.
In the end, the leader is in a situation when he doesn't have the ability to choose wisely. Prices are in the tens and hundreds of times, companies implementing on the surface all the same.
Integration with external information systems and the embedding in the business processes of the client — a special and large risk
Large web projects do not exist in a vacuum, they communicate with other information systems. Such exchanges typically require revision of at least one of the systems, often both. Organizationally and technically, this issue is on the powers and otvetstvennosti of the project, and because it is often the decision is delayed.
Once said friend specialist in the implementation of accounting systems: "to this program, we need some money, and then it worked — other".
the
customer Questions
Generally speaking, the client and the developer — almost the equal of the development process, and the risks they are similar. What questions puts (or should put) in front of a client, who decided to do something unusual and great is a large web project: aim and objective
You need to understand why the project is created. Profit? Thank? Support the core business? New market?
As a result, will be checked?
What period of time? it is clear that "yesterday", but really what?
These questions need to be thoughtful and give the most accurate answers.
Marketing calls instead of the goals and objectives of the project is a bad sign.
framework and priorities
Often think so: once the project is huge and, even once all. It is very important to understand and document the scope, the limits of the project. Remember: the chances of a successful launch are reduced with each additional day. It is better to run fewer functions, but faster and better.
Priorities and allow customer and developer to understand what is most important in the project, where should I start and what is secondary and can be done later and with less attention.
A competent project Manager always tries to do first the most difficult but not the easiest. And making — trying to run it in work for real clients and employees.
load on the client's specialists
Often the client has no idea how much work will have him. When creating a large custom project the load on the customer can be very significant. In our practice, several times there were cases when projects have folded or their timing and composition is very varied because the Manager client was not ready, could not or did not want to commit a lot of time and qualified to perform their part of the work — to think, to prepare information, make decisions, analyze options.
Often, client-side need not only the Manager and the operator for data input, but also developers, system administrators, marketers, copywriters.
The wrong understanding of separation of duties ("how, I thought it too are you doing!?") is a large risk.
Clever and far-sighted customer, regardless of cause him the trust of employees of the contractor, will ask: "what and when will need to we do?". Careful — and even write it down in the contract.
the Domino project we are lucky, twice. Originally the project dealt with Olga Sumiregawa (Vorobiev), which owns a huge role in the design of the website. Unfortunately, in the midst of her project, she left the company and started the project Alexey Markelov, who has shown knowledge, experience, and common sense. Everything turned out, although the change of the channel in the project is one of the most severe risks.
who will do and how?
What developer should I choose? External people or your employees? Local or "Vikings"? Boxed system, a flexible framework or the original code, where "all his"?
Our own team is good, if you have it: energized, professional, structured and managed.
Team can not consist of one person. Attempt to assemble a team of "the street" and immediately entrust it with the development multiplies the risks.
The proximity to the developer, the opportunity to meet and talk and, if necessary, and work in the same room greatly simplifies the dialogue, especially at the stage of task setting and delivery stages, and then the whole project. Sometimes a customer may be willing to pay several times more for the opportunity.
One of the main principles of effective software development is: personal contact is the best way of dialogue.
how can I be sure this will work?
custom development of a major project is always very risky. A survey of IT Directors by Intelligent Enterprise magazine showed that
31% of projects fail
53% of projects are completed over budget on average 1.9 times
16% (!) skladyvayutsya projects on time and budget.
Agree, you would like to get to 16%? However, much more likely, especially with the lack of experience, caution and luck to get into other groups.
the
developer Questions
Generally speaking, the relationship of developer and client, especially when the first collaboration, tension and sins on both sides, and even a light feeling of mistrust, can easily slip into the plot of "alien vs predator". It's frustrating on a human being and harms the project. In addition to thoughts about the quality of the project, the developer needs to care about the relationship. However, as the client. So, what should an experienced developer of: - evaluate the project
in any way, which he owns, to try to assess the amount of work, then it is reasonable to apply the "multipliers": the new technology, weak TK, deadlines, lack of coordinated command, ill-defined limitations.
Generally speaking, there are statistically proven methods of assessing the scale of the project PERT, CoCoMo II, and others. In pure form they are unlikely to work, but useful thoughts.
to recognize a big project
Time to understand that the project is new, large, risky, and see their risks, and then to understand how to manage them.
the
to determine the method of project management
among the developers is often a popular modern so-called "flexible" technologies of project management. They have many advantages, but there are associated challenges. It is important to understand how you will work and negotiate with the client.
make a list of risks
And decide what to do with each: to accept, transfer, insure, reduce. The main thing — to see it.
to do everything for success
normal ambitious developer wants to achieve a result. Question — can.
the
Main risks
incorrect assessment tasks performer and too much trust of the client.
Bad not even the fact that the contractor makes a mistake in the assessment tasks and their forces. The bad thing is that he does not understand that its evaluation is very poorly substantiated.
risks associated with the technical specifications and other descriptions of the project
Have two main problems:
— the client may not understand the technical language of the job and even refuse to work on it. Like I said, you heard me, now do it.
on a large project are the technical specification of tens to hundreds of sheets, with many diagrams and tables. Even with extremely competent, organized and motivated employees from both parties, this document will contain errors, inaccuracies and contradictions. It is incomplete and sometimes irrelevant, especially towards the end of the project. The leadership will change priorities and come up with new ideas.
Theoretically it is possible to write consistent, comprehensive and detailed TOR for the project, but it will be spent huge amount of time for which the TK text will become obsolete, the project itself will not be as relevant.
big time and a loss of contact
If the development is large stages, what logically leads attempt to make "all the big sow", in the process lost the human contact between the parties, many of the details are forgotten, the customer gets tired of waiting and experiencing the negative rather than anticipating success. This risk lies not so much in the rational sphere, but also emotionally, and that's why he's dangerous.
Its consequences — difficulty receiving, uncontrolled flow of requests that the customer finds errors or logical requirements, and by pure "wishlist".
This risk eventually threatens not only the project, but relations between the parties.
This risk was partially realized in our project Domino. We did it more than a year, and during that time much has changed. In our opinion, it was better to run first one the most difficult section (e.g. Car), to run on a common mechanism and then to develop. The customer also chose to get the price and the period of "all at once", though much was not ready for such a big stage. The result was a lost a lot of time, nerves and money.
change of requirements and price development
Changes in the project it is perfectly normal for the customer, for business, for life. Nothing concrete established in real life. Regardless of which method of project management you choose will have changes.
May, by contract or practice, the relations they will be able to minimize or even crush at all, but it is unnatural. And each day of the project until start-up is only to save these changes.
For the developer's work in a changing job like the race of Achilles with the turtle: close, but to catch up is not possible.
There are several ways to work with this risk, the choice between them depends on the project and the client's relationship with the developer.
General recommendation — stages less, run faster.
In bad job with this risk can be 2 consequences:
project is always 90% ready,
— price development (in time, money, nerves becomes unacceptably high: quality suffers, accept short-term solutions, testing is missing).
real data volume and performance
Individual a big problem, about which often forget or do shallow to fully test the project on real amount of data, users, views; to identify and remove all bottlenecks in the project.
Such stress testing is not too difficult technologically, but extremely useful for the future.
the
a Key issue of decision-making
When you create a project the most important thing is the people who will be responsible for it. Nothing can replace the brains and the desire to solve the issues of the project. What should be people? They must: -
the
- to have experience in such tasks (the criterion size of the project) the
- understand the idea and got enthusiastic about her, want to do the project the
- will ask you questions that you yourself did not ask the
- are you cute. A lot of you will be dealing with these people, and if the emotional connection is missing, problems can not be avoided
You just need it to do, and to do consciously.
the
the Technology of interaction: ideal and reality
In the theory all is simple. the -
the
- He wants that the development was carried out quickly and without error, and the result met all the requirements, including and not expressed explicitly. the
- Customer all types of communication prefer telepathy and is prone to all the errors of understanding to blame the Contractor.
-
the
- He is waiting for the customer to accurately set the task and was able to quickly provide answers to specific questions. the
- the Developers will offer their own versions, but expect final decisions to take an intelligent and responsible contact with the client. the
- By all types of communication prefer paper detailed a consistent task, preferably written for him or even by the performer. the
- Solution to all problems of understanding so the developer sees only through the search for the appropriate item in the TOR.
In practice it is different. the
-
the
- Customer rarely is willing to give the information that the objective for this project. Changing not only technical requirements, but also understand the business result. Often in the course of the project in the most unpredictable and inconvenient the time change key employees of the customer. the
- the Contractor (under pressure from the customer or from their own inexperience) rarely has a margin in time and money to implement risks. If small projects, this strategy is still viable, then in large, when the risks are many and some of them doesn't realize, is extremely dangerous. the
- Called without reserve the terms and cost are then difficult to change, and to meet them will not work if anything goes wrong. the
- is Almost impossible for the developer kept ready programmers to include them in the project. Most likely, people will be taken from other works, often with the imposition of tasks. It's all very complicated planning of resources and greater demands to meet deadlines. the
- And time in large projects almost always fail.
Almost always in a large project implemented at least some of the risks, and almost always it is not the agreed plan, and in the manual control mode. In our project Domino realized fully the risks of replacement contactee, integration with external systems, the risk of long stages and the accumulation of the changes and partly the risk of large TK.
the
Assessment and planning of the project
I mentioned the situation when one and the same project quite sane developers on the technical task was assessed at various time and cost, and the range of estimates was nearly 100 times. At first glance the reason is simple — developers are greedy idiots are too inexperienced and wrong. It is actually more difficult. Even if you have experience and knowledge of the accuracy assessment of the project for TOR, especially short, extremely low. If a coherent paper document with the described limitations, the cost can be safely taken "from the ceiling": you'll be wrong. It is an objective reality that in the beginning of the project no one knows its cost and launch date. Existing scientific and statistically valid methodology is extremely weak and in practice is hardly applicable. What can be done to make the project work (customer interest) and earned income (the interest of the developer), and the time kept within the allotted frame (all I want): rough estimates and a detailed plan
Indeed, one can make a rough estimation, make it 10 times margin for all risks at once (the stock seems to be huge, but if the risks were not analyzed, no one knows whether it is sufficient), and then to draw up a detailed plan and do not give the customer any freedom to revise requirements and deadlines.
You can enter into a separate agreement in writing detailed TOR. It is worth 10-30% of the price of the development. The problem is that customers usually don't like that he pays TK, which, in his opinion, it is necessary only to the developer. In addition, a large and detailed task descriptions that in itself is a separate risk.
development small portions
This approach is becoming more popular. The development is in small portions with duration from 2 weeks to 3 months, tasks which are not very large. Is paid for each portion, each portion starts and extends the capabilities of the project. Technology is good because the customer is always the product, which can be used. There are not many risks: the loss of contact, large TK, the lack of testing. There are also disadvantages: nobody knows how many servings will be required, what will be the result, the cost and development time. The client doesn't like it.
However, it is symmetric: the developer never knows the whole problem is that often he doesn't like.
the
a Contract and the rules of the game
the Paradox is that most developers use a common agreement about anything. Such a contract does not fix the terms, obligations, division of responsibilities, presentation materials and so on. According to a recently published study, 30% of sites are generally without a contract. When creating websites it is excusable, but the projects of thousands of man-hours to do the weak agreement is simply impossible. So, what should be the agreement: - the Contract must be written so that if the customer's representative or Manager of the contractor will be replaced by other people, the project can still be completed. No substantial part of the agreements should not remain oral. the
- Good things are not made under the contract. Good things can be done only with human relations. The contract is an insurance in case of problems.
the Agreement can be simple, complex, flexible or formal, but it should be recorded however, the actual scheme of work. the
the
No need to automate the mess
designing the website, thinking through the interface, logic, and details of normal analyst will offer their own versions. To simplify logic, changing the sequence of steps to revise the rules. It is not only technical or design changes, they will also affect the nature of the processes the business logic. "If you automate a mess, get an automated mess." Not worth it. Why is this happening? Third-party analyst is a "fresh head", which sees not entirely logical or consistent elements of the project and can offer their. On the one hand, such changes are often extremely useful, as make the project easier, it is running faster, and cheaper support. On the other, only a representative of the business, the end customer can accept the change, evaluating it from their point of view.
for Example, a group of Newspapers Domino Volgograd and Volga Newspapers used significantly different methods of calculating ad prices. If they do not lead to uniformity, actually need two different feeder interface that will confuse people. And if you change the formula change and financial performance and established work scheme. Major project is about Economics and politics
The developer must offer the Customer not to be surprised and to consider the proposals seriously, and everyone should think about the quality of the project. The paradox that usually all want success, but so different he is and so do not know how to talk to each other that the interaction problem can ruin everything even when there is no serious factual dispute.
the
Documentation tasks
Document — is an important part of the organization of work. I had to deal with projects where the total number of regulations, instructions, specifications reached several dozen. Documents is not a panacea, a universal prescription is not here. What are the specifics of a major project: -
the
- lots of information the
- puzzles the
- items initially unknown, then there is a refinement.
a brief statement of the problem in the contract. 6, where the specified constraints: no more than 30 types of ads, not more than 10 file formats exchange is not more than 300 fields in all data entry forms. These limitations are very important
actual technical job we did on the basis of Axure, used to create a live clickable layouts, multiple charts, documenting the state changes, ad
the TK text was written, read, discussed in google docs
the
Tracking development process
When a job is signed and started production, some things are just necessary: -
the
- Gantt chart, where you have to mention the real and actual timing the
- bug, which has limited access and the customer the
- regular meetings with clients (especially if the project is one huge piece)
- each checked stage, you need to check tests, preferably automated. And the tests themselves need to prepare before implementation.
the inevitable changes in the TOR caused by the correction of errors, clarifications (e.g., added private the field house basement) is necessary to record in the worksheet changes. They have been scattered by mail. the
the
delivery of the project. Load testing.
Upon delivery of the project, always doing user testing, sometimes the unit tests of the code. We believe that another type of testing is extremely important: load. Tell you the example of Domino's:
right at the contract we wrote requirements for the work site on shared hosting: 200 thousand views a day (about 3 views per second), the average time of page generation by up to 0.5 seconds, percentage error 50? less than 1%
the specifics of the project that data very intensively updated and the caching mechanisms are not very effective
upon delivery of the project, we conducted a test (Timeweb, the rate Eterno). The average generation time was about 0.2 seconds, the error 500 did not exist. 200,000 views website stand easy
it is significant that during the test it was found about 10 bottlenecks in the code that required processing. Troubleshooting these problems gave approximately two-fold reduction.
when I decided to move to a different server hosting the same mechanisms load testing helped to quickly choose the best option.
the
the Paradox of large projects
I think that doing a project as a set of stages, each of which runs separately evaluated and best practice. This is the best option and from the point of view of planning, and the quality of the result, and for business. For customer usually all the arguments outweighs the plus version of "one contract, one TK, one stage" — from fixed launch date and budget. Sadness that time can not withstand for obvious reasons (delaying approvals, implementation risks, processing requests), and the customer suffers. Accordingly, the project for the extension of time is significantly less profitable than planned, and suffers from the developer. The paradox is that the risks in a staged work less, and the chance to get a quality result of the above, despite the open budget and the end date of the project. It is necessary to tell about this very "end date". Modern design, designed for business, is constantly changing. And no final date just yet. Is the current state of continuous change. the
Insights
close project is not so terrible as it may seem. All solved if the customer and the developer have common sense, experience and desire to solve problems. We believe that: -
the
- job stages is the best option; the
- data exchange with external systems need to do and test at the beginning of the project; the
- to work on the job needs to collectively and "live" via Google Docs; the
- large project is always politics, and it always significantly change the business; the
- and remember: your next project should not exceed the previous one by more than 2 times.
the
And conclusion
The customer needs to understand what the project he will have to do very much. You will need to select the employee who will have the knowledge, expertise and authority to make decisions on the project. This staff will have to allocate to the project a lot of time, possibly all day.
And succeed.
New site Domino (may be based, at Timeweb problems)
the Source of the article, a little bit neater. Sorry, to fight with the parser Habra hard.
