Technologies of interaction with the internal customer. Project management. Informing the Customer about the project management technology

25.11.2019

Projects are different, and they need to be managed in different ways. In large projects where a large number of developers, not to mention business analysts, testers and the actual customers of the project, the issue of coordination of actions comes to the fore, overshadowing all other tasks.

It is for this case that the Agile project management methodology was invented.

Its 4 main postulates are as follows:
- individuals and their interactions are more important than processes and tools,
- working software is more important than complete documentation,
- cooperation with the customer is more important than contractual obligations,
Responding to change is more important than following a plan.

Focusing on communications and the end result instead of following a plan and full documentation gives you more flexibility and allows you to not bureaucratize the coding procedure. The downside of such a democratic approach is the lack of clear planning, the need to constantly redo already written parts of the code and the regular rushes associated with this.

Despite a number of shortcomings, in many cases the agile methodology is indispensable. Therefore, any head of the development department should be familiar with it.

Responsibilities of the head of the development department

Development of development standards and policies software in accordance with the general IT policy of the company;
- planning and coordination of the work of the development department;
- development and monitoring of compliance with project schedules;
- assessment of the complexity of projects and the distribution of development tasks among programmers / developers;
- management of the development process;
- development terms of reference on software modules;
- planning and control of budget execution of the department;
- management of external resources involved in software development;
- development of normative documentation regulating the work of the department and the procedure for interaction with functional divisions;
- participation in the development of the company's development strategy.

Salary offers and requirements of employers

The average salary offer for the head of the development department in Moscow is 150,000 rubles, in Saint Petersburg - 117,000 rubles, in Volgograd - 66,000 rubles, in Voronezh - 75,000 rubles, in Yekaterinburg - 100,000 rubles, in Kazan - 75,000 rubles, in Krasnoyarsk - 90,000 rubles, in Nizhny Novgorod - 70,000 rubles, in Novosibirsk - 85,000 rubles, in Omsk - 75,000 rubles, in Perm - 85,000 rubles, in Rostov -on-Don - 75,000 rubles, in Samara - 75,000 rubles, in Ufa - 75,000 rubles, in Chelyabinsk - 84,000 rubles.

Applicants applying for the position of head of development for the first time must have higher education(profile or technical), experience in software development for at least 3 years. Knowledge of the principles of object-oriented programming and software development methodology (RUP, MSF) is required, skills in working with DBMS are required. Employers welcome knowledge of several programming languages. The starting salary for novice heads of development departments in Moscow ranges from 70,000 to 110,000 rubles, in St. Petersburg - from 55,000 to 86,000 rubles, in Voronezh and Perm - from 35,000 to 55,000 rubles.

City	Income level, rub. (no experience in this position)
Moscow	70 000 - 110 000	- Higher education (technical / IT) - Knowledge of one or more programming languages - Understanding the principles of object-oriented programming - Knowledge of software development methodology (RUP, MSF) - Knowledge of English language at the level of reading technical documentation - Experience with DBMS - 3+ years of experience in software development Portrait of the applicant in 1 range
St. Petersburg	55 000 - 86 000
Volgograd	30 000 - 48 000
Voronezh	35 000 - 55 000
Yekaterinburg	47 000 - 74 000
Kazan	35 000 - 55 000
Krasnoyarsk	42 000 - 66 000
Nizhny Novgorod	33 000 - 52 000
Novosibirsk	39 000 - 62 000
Permian	35 000 - 55 000
Omsk	40 000 - 63 000
Rostov-on-Don	35 000 - 55 000
Samara	35 000 - 55 000
Ufa	37 000 - 55 000
Chelyabinsk	40 000 - 62 000

From candidates with experience in managing the development department for more than 1 year, employers expect, first of all, developed organizational and leadership skills. Job requirements relate to the experience of planning, organizing and implementing projects, developing technical documentation, as well as skills in using tools project management. Applicants for relevant vacancies in the capital can expect a salary of up to 140,000 rubles, in the city on the Neva - up to 109,000 rubles, in Voronezh and Perm - up to 70,000 rubles.

City	Income level, rub. (with 1 year work experience)	Requirements and wishes for professional skills
Moscow	110 000 - 140 000	- Developed organizational and management skills - Skills in planning, organizing and implementing projects - Skills in using project management tools - Ability to develop technical documentation Portrait of the applicant in the 2nd range
St. Petersburg	86 000 - 109 000
Volgograd	48 000 - 62 000
Voronezh	55 000 - 70 000
Yekaterinburg	74 000 - 94 000
Kazan	55 000 - 70 000
Krasnoyarsk	66 000 - 84 000
Nizhny Novgorod	52 000 - 66 000
Novosibirsk	62 000 - 78 000
Permian	55 000 - 70 000
Omsk	63 000 - 80 000
Rostov-on-Don	55 000 - 70 000
Samara	55 000 - 70 000		Ufa	55 000 - 70 000	Chelyabinsk	62 000 - 78 000

Additional education in the field of IT and experience in setting up a full development cycle - these are the most typical requirements for applicants with more than 2 years of development management experience. The earnings that such specialists can count on reach 175,000 rubles in companies in the capital, 137,000 rubles in St. Petersburg, and 88,000 rubles in Voronezh and Perm.

City	Income level, rub. (with 2+ years experience)	Requirements and wishes for professional skills
Moscow	140 000 - 175 000	- Additional education in the field of IT - Experience in setting up a full development cycle (from technical specifications to putting the project into operation) Portrait of the applicant in the 3rd range
St. Petersburg	109 000 - 137 000
Volgograd	62 000 - 77 000
Voronezh	70 000 - 88 000
Yekaterinburg	94 000 - 117 000
Kazan	70 000 - 88 000
Krasnoyarsk	84 000 - 105 000
Nizhny Novgorod	66 000 - 82 000
Novosibirsk	78 000 - 98 000
Permian	70 000 - 88 000
Omsk	80 000 - 100 000
Rostov-on-Don	70 000 - 88 000
Samara	70 000 - 90 000
Ufa	70 000 - 88 000
Chelyabinsk	78 000 - 100 000

The highest salaries are offered to the heads of development departments large enterprises. These employers require candidates to have at least 3 years of experience in organizations of a similar size. Companies with foreign partners prefer specialists who are fluent in English. The salary maximum in Moscow reaches 300,000 rubles, in St. Petersburg - 235,000 rubles, in Voronezh and Perm - 150,000 rubles.

City	Income level, rub. (with experience from 3 years)	Requirements and wishes for professional skills
Moscow	175 000 - 300 000	- Experience in development management in the structure big company from 3 years Possible Desire: Knowledge of English at a conversational or fluent level Portrait of the applicant in the 4th range
St. Petersburg	137 000 - 235 000
Volgograd	77 000 - 130 000
Voronezh	88 000 - 150 000
Yekaterinburg	117 000 - 200 000
Kazan	88 000 - 150 000
Krasnoyarsk	105 000 - 180 000
Nizhny Novgorod	82 000 - 140 000
Novosibirsk	98 000 - 170 000
Permian	88 000 - 150 000
Omsk	100 000 - 170 000
Rostov-on-Don	88 000 - 150 000
Samara	90 000 - 150 000
Ufa	88 000 - 150 000
Chelyabinsk	100 000 - 170 000

Applicant portrait

Among the applicants for the position of the head of the development department, the majority are middle-aged men with higher education. Representatives of the weaker sex among the applicants are only 5%, which is typical for the IT sector. 58% of applicants are specialists aged 30 to 39 years. 96% of heads of development departments have higher education. Every third applicant is fluent in English.

Blog embed code

Head of Development Department

Project management skills - this requirement is often found in vacancies for development managers. In fact, behind these words there can be much more than it seems at first glance.

result this stage is preliminary decision on working with this client and formation of a positive image in the eyes of the client.

I want to focus on creating a positive image. Based on the collected initial information, we decide which of our employees can be trusted to represent our firm at the first meeting with the client. This is a very important point. For example, if we send an excellent specialist for the first contact, but he has an earring in his ear, a “cook” soaked in grease, etc., then the client can look and say: “Oh, come on!” It happens. Or, for example, a neat, trimmed, in a suit and tie, but a boy of about 20 came in. And the client looks and says: “This is a boy, what should I talk about with him? How to work with them - they don’t respect me at all, they sent a boy to me! Therefore, the collection of this information is necessary, among other things, in order to understand who to entrust with the first contact and how to behave to the contactee, how to build a legend, how to present oneself.

Identification of decision makers

The next very important question is identification of persons who actually make decisions(the so-called LPR). This stage consists of two items:

It turns out, who makes decisions according to our project.
And the second point - persons influencing decision makers are identified.
What does it mean? For example, it is known that decisions in the company are made by the CEO, and he also has a financial director and an accountant. It can be an accountant who does everything the director says and sits quietly in a corner, or maybe vice versa, an accountant who tells the director what to do like this and the director obeys him. And if we initially revealed that this person has influence on his director, then this is our trump card, therefore, we need to try to establish relations with this accountant. I conditionally said that this is an accountant - it can be anyone (for example, the head of the sales department or some deputy who is completely trusted by the general director or the owner of the company). It is necessary to establish relationships with the person influencing the decision maker.

The goal, as you can see, is to identify decision makers. And the result is a list of decision makers and persons influencing decision makers.

Our experience shows that try to meet with the decision makers as soon as possible- usually they are either top management or the owner of the company. It doesn't have to happen at the first contact, but if such a meeting does not occur at the preliminary stage, then, as a rule, nothing good will come of our project.

Establishing partnerships

Next stage - establishing partnerships.

We initially do emphasis on bilateral responsibility: even in the contract, if possible, we prescribe not the Customer-Contractor, but “ First side" (this is the Customer) and " Second side” (this is the Performer). True, sometimes some large state structures say that the legal department does not allow them to do this, because the documents are checked by the Treasury, the Ministry of Finance and others. In this case, we prescribe the standard wording - "Customer and Contractor". But if possible, then - "First" and "Second side".
By all means we are trying to convey that this is a joint work. Leaders on both sides act as high contracting parties - it was they who decided to make this automation project. For this project, they recruit a team of how from the staff of the first parties, those of employees second side is the so-called Joint Working Group", which makes the project. Naturally, each side invests its resources in the project: material, technological, methodological, financial - because, in general, we are talking about fairly large projects.
The work of the joint working group is supervised by« Joint Supervisory Commission" is the highest controlling body, usually consisting of the top management of both parties.
And sign the responsibility of each party so that the customer's employees understand that not only we, but also they are responsible for the project. We spend a lot of time and effort to convey to the client that we are doing this project together with his employees, and that their work directly depends on what quality and, especially, in what time frame the project will be completed.

Well result this stage is fixation(formal or informal) relations equal partners:

Formal fixation is a contract.
And informal - it can be some official documents in which we always try to prescribe the "First and Second Side" and their relationship.

Informing the Customer about the project management technology

The next stage is informing the customer about the technology.

On large projects, we, without fail, have " Course of lectures and seminars on introduction to design technology". In this course of lectures, we bring to the customer's employees how the entire project process will take place:
- How is a project made using our technology?
- Who is responsible for what?
- Who's doing what?
- Why are certain actions being taken?
- Why is this document needed? What does he give both sides? (to make it clear to employees that partnerships provide benefits not only to us, but also to the customer).
- At every opportunity, we We inform the decision maker about all the problems that arise in the course of work. To do this, we have a number of special daily documents - for example, the "Diary of Contacts" or "Statement of Deviations". And if not daily, but every few days, the customer's management should get acquainted with them. And since, as a rule, excuses are immediately found: I was busy, didn’t read, etc., then, accordingly, we need to constantly remind about this, maybe even simulate some situations that force the management to read these documents.

The result of this stage is that all responsible persons of the customer have completed a course of lectures and, most importantly, that the management has a clear idea of how the work is done (naturally, if it controls the project tightly enough).

Organization of relations with the Customer

The next stage is the organization of relations with the Customer. Here I want to tell you about one interesting “trick”: we have such roles on the project (these are not positions, but roles) as “Contract Manager” and “Object Manager” (most often they can also be combined and with some other responsibility). As indicated on the slide here, these roles correspond to the definitions of "bad" and "good".

Contract Manager is "bad". This may be an individual or one of the top managers. Most often, the function of the contract manager is performed by the project manager (if, of course, he is able to do this). This person is “No” - he can come to the decision maker and say: “It’s written like this under our contract, but now you are doing it differently, and because of this there is a deviation. Let's figure it out." He always points out shortcomings, non-compliance with technology, urges to comply with the documentation That's why he's always bad.
BUT object manager- this one good". This is a person who, for various reasons, has developed a good relationship with the decision maker from the customer. Maybe he just happened to like him. Or, for example, they have some kind of ties (kindred, clan, friendly - whatever). The main thing is that the client is located to him.
The manager object actually maintains this object. Please note that this is not a project manager, this is a special person who does what maintains a good relationship with the client's management, and when there are some acute problems, he smooths them out.
For example, after the contract manager has spoken to the client about non-compliance with some conditions of our agreements (this may end, in general, with some kind of unpleasant conversation for us), the object manager comes and begins to calm the client.
It was not for nothing that I said that the manager object is called “good”. It is commonly said that being a "nice guy" is not a profession. But this is our profession. The object manager is the "nice guy". He may not be a professional specialist in anything, but the client feels good with him - he came, talked with him (maybe about politics, football, etc.), and the client felt good, his attitude changed. Before that, the client was going to reprimand us for something, to punish us for something, but now he already understands everything, he is generally uncomfortable talking badly with us.
This is the function of the object manager. It is assigned to each fairly serious client.

Of course, everything I am talking about requires certain resources and costs. And, of course, creating all this structure for the sake of a small shop does not make sense - this is all done only for the sake of sufficiently large objects.

The result of this stage is the appointment of the appropriate contract and object manager for this client, because it is very important to select these people correctly.

Organization of project processes

The next stage is organization of project processes. In my opinion, there are only two of them:

Project progress monitoring;
And making managerial decisions based on monitoring results.

The most important thing is to convince the customer to work according to our technology. This procedure is explained to the customer both in personal conversations with decision makers and when responsible employees attend a course of lectures (it explains how and what will happen on the project - the customer's employees must attend this course without fail, under signature).

Sometimes it can be very difficult to convince a customer to work with our technology. For example, we had one client - a very large IT company. Moreover, she herself was engaged in automation on MS Navision, but for certain reasons she decided to call us so that we could automate them on 1C. So, working with them was a real nightmare - everyone was crying, both managers and programmers. Because it was a very large company (we are small compared to them), and they thought they knew everything and tried to teach us. They constantly said: “guys, you don’t do everything like that, there is such and such a technology, you should do it this way.” Naturally, this happened only at the middle level, the head (who was the main owner and general director of the company), of course, understood everything perfectly, and after his intervention everything was decided, but it was very difficult to get him. And at the middle level there were constant problems, constant attempts to teach.

We are on every project, without fail, We try to convey to the client the idea that in his business he is a professional (and we, of course, do not go there), and in matters of automation we are professionals, so we need to trust and not try to tell us what to do and how to do it. Especially if they do not just tell us, but try to force us: "let's do it differently, because I want to." These are the things we are trying to stop right now. Of course, “stop” is a strong word, in any case, try to explain it mildly enough. If we agreed to this project, decided that it suits us, got involved in this “battle”, now, of course, we have to work with it.

Limitation of the client's desires

The next stage is limitation of the client's desires. Everyone, probably, faced this (when the so-called "Wishlist" begins - more, more and more). Here we do it quite simply:

For example, when a client says that within the allotted budget and deadlines, this and this must also be done, then it starts quite often, a difficult explaining how it all works. We remind the client that we have a budget with him, people are allocated (joint working group), each side of the project invests its resources. Therefore, if additional work arises, then additional hours, additional people are required. Where to take them from?
Or if the client delays the project, then both ours and his people are idle, and they are paid money. Where to get these resources? I'm not talking about the fact that these people not only receive a salary, but also bring some profit to the company. Naturally, the company does not want to lose this profit. It is explained in sufficient detail to the client, and the client usually responds very well.
We explain we give a detailed digital layout- where, what, to the penny. And we say that if you want us to do this too then please it will take so many hours and they have to be paid. In the end, the client agrees with us and either refuses his "Wishlist" or pays for additional hours. Of course, it happens in different ways - I now idealize the picture a little.

Here I want to give another example of relationships. We worked with one very large company (they were already at the maintenance stage), and some tasks for improvements periodically arose there: for example, to make some kind of tricky report or something else. And so, the chief accountant of the company entrusted us with certain work, and we did it. And when it came time to pay, he said: “In general, I was mistaken, we don’t need all this at all.” But the work was done, therefore, it was necessary to pay. And he says: “No, I won’t pay for this, but I can’t go to the president of the company and tell him that I’m a fool and ordered the wrong thing.” Moreover, the company was very large, oil company, relations were good both with it and with this person. And we did not insist - he does not pay, he does not pay. Although, because of this, we lost a fairly large amount of money for us at that time (it was 2004). At the end of the year there was a denomination (the Azerbaijani manat discarded zeros). And for all the clients who were in our service, we did this recalculation in the working order - no additional money. But to this accountant (at that time literally less than a year had passed since that incident), we approached and said: “Remember, you didn’t pay us? We then went to meet you. Now, denomination. Let's do this for free?" No questions asked - we issued an invoice, he paid.

Why did I give this example? On the importance of good relationships. If we had then reared up and demanded to pay us this amount, then we would have had the risk of losing a good client. And so we kept in touch with him.

Who is responsible for explaining this budget:

This in the way of business; in the regular course of work is engaged Project Manager- the head of the joint working group, which, in fact, carries out the project.
If he fails, then he connects contract manager, who explains by numbers and says that this is - breach of contract, breach of agreement.
In the most difficult cases connects object manager who tries to explain (already, of course, without any rigid framework) to the customer why he needs to limit his desires.

Usually, if the numbers are written in great detail, then this layout and its explanation is enough.

Delivery of works

Delivery of works. Here, in general, there are usually no big problems, because The procedure for handing over works is very detailed in our relevant documents.

But at this stage, the element of informality ( good relationship), of course also makes life easier for both us and the customer too.

The purpose of this stage is to achieve the delivery of works in full compliance with the rules established in the relevant documents, which are an annex to the contract signed by both the client and us. Accordingly, one can always show that there are such rules.

Post-project relationships

And finally, post-project relationships. This is also a very important part. What should we aim for at the end of the project? To the conclusion of a service contract, of course. But this is not always the case. Because there is the concept of "result", and there is the concept of "outcome" - and these are slightly different things.

I'll give you an example. We had a project with one very serious company, and the result on that project was brilliant for us - it was one of those rare cases when we completely met both the budget and the deadline, exactly as originally planned. This was the result. And the result of the project was that the service agreement was not signed. Moreover, the customer said that he would never work with us again. Here is the result. In other words, the result is brilliant, but the result is very sad.

Why did this happen? Because there were no informal relationships. We had just developed our design documentation technology at that time, and this was the client on which all this technology, in its full glory, was demonstrated. And when we asked the customer: “Well, you won’t work with us - but are there any claims against us?” And we were told through gritted teeth with anger: “That’s the problem, that we can’t make any claims - whatever you say, you have a piece of paper for everything, and we can’t do anything. We are not satisfied with this, and we will not work with you anymore. Other companies can be asked to do something additionally, but you refuse - here is your budget, here you have it as it should be, here is the deadline. Step aside - and you immediately show us a piece of paper with our signature.

So the result is sad. But once again I emphasize that such a result was due to the fact that there were no informal relationships.

This article is based on a report read by the author at the IE Infostart Conference 2014 October 29-31, 2014.

We invite you to a new conference.

Good day! Today I would like to talk about the ways in which a client interacts with an outsourcing company, and also to receive comments from you on how you interact with your clients/software developers. This article is written based on experience and, for the most part, is intended for software customers. The goal is to find "bottlenecks" in the relationship between the customer and the company that offers software development services.

Allow me to introduce myself: I am Yury Korkhov and this article is the first in my Habré. Graduated from the Belarusian National Technical University (security engineer), Belarusian State University (investment manager). Work experience - more than 6 years in IT in almost all positions: webmaster, layout designer, web designer, programmer, project manager and part-time UI developer, head of department ... In total, during this time, more than 80 projects have been implemented: from small sites, games for mobile phones to large Internet portals... The main profile is the management of the development of projects in the IT field. He worked both on the side of the customer and on the side of the developer, both on the Russian market and on the foreign one.

Background to the creation of the post or Thank you Wargaming.

Bypassing the history of the creation of this post would not be good, because. I’ve been reading habr for a very long time, but my hands didn’t get to write an article, but here it’s a matter of “chance” and now the article is ready.

I've been taking a break from work for a couple of months now, because I'm tired of outsourcing, I decided to find the meaning of life and slowly prepare my project for launch, and one fine day the phone rang. A Wargaming recruiter (the founders of “tanchiki” and, in my opinion, one of the best firms in Minsk) called me with an offer to interview for the Vendor Manager vacancy (it should be said here that I was not looking for a job, and, judging by their vacancy, I didn't suit them well). “That's interesting!” - I thought and decided to complete the test task, especially since it was quite interesting for me. The recruiter said that they had all the conditions for a pleasant, healthy (fitness, insurance, etc.) and well-paid job and, not least, it would take me about 3 hours to complete the test task. I doubt that anyone would have been able to complete the entire test task within the specified time, as for me - it took about 6 hours in total.

To my regret, feedback from the company was in a telephone conversation and was expressed in the dry phrase “everything is fine, everyone liked it” (I don’t remember verbatim, but the essence is this) and without any specifics. I doubt that I was able to point out all the main "bottlenecks"; it’s not good to waste work, I decided to post the answers to the test task (with minor changes, for convenience) to the public and I will be grateful to the habra audience for additions and healthy comments to the article.

Scheme of interaction between the customer and the software developer from the first meeting to the end of the relationship.

When designing a circuit, I mean:

The software developer is able to complete the project.
Before that, the contract was not signed with the software developer and there were no projects.
TK is ready.
Payment terms are regulated by the contract.
Project management systems and software development methodologies (XP, Scrum, Lean, Kanban, ScrumBut, etc.) are used.
Filling the application with content (if necessary) is done by the client.

Aspects of the contract between the software development vendor and the customer are advantageous for the vendor to avoid (simplify, remove from the contract altogether).

The responsibility for meeting the deadlines lies with the developer, and if the deadlines are missed at the last moment (i.e. the developer did not notify in advance that he did not have time before closing), penalties should be imposed (there is a large selection of options).
Reason: failure to meet deadlines is one of the biggest problems and mentioning it in the contract is not very interesting, because. For the most part, the failure to meet deadlines lies on the side of the developer. Here it is necessary to take into account that it is difficult to calculate exactly, but it is necessary to warn in advance that the developer does not have time to complete the development stage within a certain period of time and this must be prescribed in the contract.
Guarantee conditions for fixing "bugs" due to the fault of the developer that were not detected in time. The usual warranty period is 3 months.
Reason: it often happens that some “bugs” have not been fixed or have already appeared in the process of work, so this item is often tried not to indicate or reduce the warranty time. My opinion is that less than 3 months is not enough.
Rights to developed software, modules, blocks, etc. belong to the customer and cannot be used for subsequent resale.
Reason: It is beneficial for the developer to have intellectual property rights or be able to sell / use developments for other clients, which in turn can put the customer in an uncomfortable situation on the market.
When developing a new module in the system that affects the operation of other modules or the entire system, the developer must ensure the functioning of the entire system.
Reason: often the development of one module can harm the operation of another module or the entire system in general, and further improvements can fall on the “shoulders” (financially) of the client. The developer is obliged to take into account the structure of the entire system and, in the case of “bugs” found by the client, correct it for free.
Technical documentation for the development should be prepared taking into account the requirements of the customer.
Reason: it is beneficial for developers to completely tie themselves to the customer and it often happens that documentation is not maintained.
In the case of developing a website, the contractor must take into account SEO optimization for the site, namely: description of images, pages…
Reason: saving time on “little things”, which, depending on the terms of the contract, can lead to financial losses for the customer (the software developer saves time / finances).
System testing should be provided by the system developer.
Acceptance by the customer of the finished module should not turn into testing of the system, i.e. the developer is obliged to undertake the elimination of the identified “bugs” by the client at his own expense. This is necessary in order to ensure quality testing of the product by the developer. By the time the developer says “done” and client-side testing begins, “bugs” are fixed for free.
The responsibility for hosting the project on the customer's side is assumed by the developer. In this case, the customer is obliged to ensure that the technical requirements for the site are met.
Reason: hosting a project on the customer's side can sometimes cause certain difficulties, which can lead to "hatting", so the responsibility for hosting and configuring the server should be on the side of the software developer.
If a software developer is forced to resort to the help of specialists outside his team, he is obliged to take all the associated risks for leakage, loss of data or any other damage that an outside employee can cause by his action or inaction.
Reason: it happens that a developer can get sick, quit, etc. one of the employees. In this case, the customer must be insured.
Backup copies of the project must be provided on the developer's side at least once a day. Any problems with the loss of data on the project should be taken over by the developer.
Reason: here you need to indicate who is responsible for the safety of the project in case of any failures.
The developer should proceed from the popularity of using the technologies he uses when choosing.
Reason: binding to their own technologies, which will complicate life if the customer moves to another developer.

Known ways of overestimating the cost of outsourcing work relative to reality. I suppose there are more of them.

A superficial estimate of the cost of developing the project as a whole, without dividing it into stages, which can lead to a 2x-3x excess of the project cost.
Failure to provide reports on the work done within the period specified by the contract or the inability to control the progress of development by the client
The wrong choice of technology in the implementation of the technical part can significantly increase the cost of development.
The lack of the right specialists in the development team, which increases the time and cost of development.
A fixed cost for the development of a project or module and a further increase in the cost for every little thing that both parties understood differently.
Fixed project development cost setting - a higher risk makes it necessary to include in the project cost.
When developing a design, prototyping is not used, and design development is carried out on the basis of a text TOR, which ultimately leads to a large number of improvements / corrections and, accordingly, an increase in the cost of the project.
Adding / complicating functionality. You can make it easier - make it harder.
“Beautiful” where they are not needed (you can say about the admin. part of the site, if you can use css frameworks for quick customization of the admin. parts - they start developing from scratch).

The relationship pattern ‘customer - software development vendor’, which, in my opinion, is the closest to practical use.

Many outsourcing companies prefer not to provide access to their project management systems without providing detailed information, I personally believe that access should be provided at the request of the customer. The client is responsible for the implementation of the project and seeing the development progress in real time is important!
Also, I think that developing software taking into account the calculation of the total cost of the project is a waste of money and a nerve, such development usually leads to conflict situations.

The main points in the interaction between the software developer and the client, which I consider optimal:

Payment for work based on the hourly pay for the work of employees or the average cost of the work of a specialist of the entire development team. Evaluation of development stages is necessary. Why I think this form of pricing is optimal:
- It does not require a very scrupulous approach in project evaluation, which is almost impossible to make 100% accurate. If the assessment is made incorrectly and the software developer begins to understand this, then the functionality is “infringed” wherever possible, which will ultimately affect the usability.
- Improves mutual understanding between the software developer and the client, as the main task is reduced to the principle - “do it efficiently and quickly”, and not “invest in a tight budget and how it will work well”.
- The client, based on daily reports on hours spent, can see how much time employees spend on different blocks during development, which gives an understanding of the speed and quality of work of software developer employees.
- The interaction between the customer and the project manager is carried out as directly as possible, i.e. when using skype, phones, etc.
Only 2-week reports and plans must be sent by mail (for control).
The client provides a prototype of the application or it is developed by the software development team, if necessary:
- Simplifies the understanding of the main functionality of the project.
- Increases the overall speed of project development.
- Clear requirements for the functionality of both the customer and the developer.
- Clear understanding of where the project will move.
Project management system to keep track of the progress of the project and the ability to monitor the process, development time spent on each task separately. Unfortunately, developers rarely provide access.
It is desirable that the entire project is done by one team, i.e. it should not be that one stage is done by one company, the other by another, and so on.
Checkpoints (“run”) every 2 weeks is the optimal time to control the project.
In development, preference is given to well-known frameworks, also for easier adaptation in case of any situation when it is necessary to transfer the project to other developers.
Quality testing on the developer's side is a direct responsibility. When transferring a project or some part of it to a client, everything must be checked thoroughly.
Supporting different browsers is the direct task of the developer

Conclusion: the main thing is to adhere to partnership / mutually beneficial and trusting relationships with the understanding that developers are the same people and complicating their life complicates life for yourself! Everyone should be responsible for their part of the work, the client should be responsible for providing a clear technical specification and respond promptly to emerging questions, not forgetting to pay for the work, and the developer - for quality, timing, speed. The ideal, of course, has not been achieved, but we are on the right track.

I like

In different sources of literature on sales, you can find a different number of stages of the sale. Each author considers them from his own point of view.

I propose to consider the key stages in working with the Client>:

Stage 1 "Making contact" or "Establishing contact"

Any sale starts from this stage.

The purpose of this stage: win over the Client and interest him in further contact.

When establishing contact with the Client, it is important to greet him and introduce himself.

"Good afternoon. My name is Mikhail, I am the manager of the company "Windows Plus".

Before starting a conversation about the needs of the Client, it is recommended to talk with him on an abstract topic (the “Small Talk” technique), or offer tea, coffee, you can make a compliment, or use a number of other techniques at the stage of establishing contact.

“What do you know about our company? Why choose us? What are you planning to buy?

It is important that the manager, by his non-verbal behavior, demonstrates an interest in contact with the Client, a desire to help him, goodwill. Non-verbal behavior includes open gestures, posture, smile, inclination of the body towards the Client, open gaze.

It is possible to determine whether contact with the Client has been established or not by the behavior of the Client. If he reacts positively to the words of the manager, feels relaxed, asks questions himself, we can assume that contact has been established. If the Client does not maintain eye contact with the manager, is tense, does not answer questions or answers reluctantly, then it makes sense to devote more time to the stage of establishing contact.

Stage 2 "Identification of needs"

The purpose of this stage: to determine the needs of the Client.

The more accurately the manager determines the needs of the Client, the more effectively he will make a presentation of goods and services, which will subsequently lead to a deal.

When identifying needs, it is important for a manager to be able to ask questions and listen to the Client.

When interacting with the Client, it is important that he speaks more, and not the manager; for this, the manager is recommended to set more open questions.

What window are you planning to purchase? Where will you change the window? What is the climate in the apartment in winter and summer? Who else lives in the apartment? On what grounds do you choose a window?

Closed questions manager allow to specify the needs of the Client.

“Do you often ventilate the room? Do you have animals? Is it convenient for you if our measurer arrives tomorrow at 9 am?”

Alternative questions offer the customer a choice of options.

“Is it convenient for you to have the measurer come in the morning or in the afternoon? Are we planning to install new windows this week or next?”

During the entire meeting with the Client, it is useful to listen to him carefully, as Clients often speak openly about their needs themselves. If some words of the Client are not clear to the manager or he listened to them, it is advisable to ask the Client clarifying questions:

“Did I understand correctly that you need a window with increased sound insulation? As far as I understand, you want one sash of the window to be pivoting and the other to be tilt-and-turn?”

It is desirable to sum up the intermediate result after each discussed issue. Especially if the manager discusses several products or services with the Client.

“Thus, we agreed that we will measure tomorrow, and we will install windows next week on Friday. So, you are planning to install two new windows: in the kitchen, a double-leaf window with tilt-and-turn sashes, and in a room, a three-leaf window, in which two sashes are tilt-and-turn and one is “deaf”.

It is important to accurately identify the needs of the client and only then carry out a presentation of goods and services.

Stage 3 "Presentation"

Target: offer a product or service that best meets the needs of the Client.

The presentation of products and services contains a description of the characteristics of goods and services, the benefits from their use by the client and the benefits that the consumer receives.

It is useful to start the presentation with the key benefits of the Client, which follow from the needs of the buyer, identified by the manager at the previous stage.

It is important to distinguish how the benefit of a product or service differs from a benefit.

Advantage is the benefit that any Customer receives by using this product or service.

"With this service, you can save time and cut costs by 10%." "This fitting allows you to reduce the number of adjustments."

Benefit is a characteristic or advantage that allows you to meet a specific need of the Client.

Thus, any characteristic or advantage can become a benefit, provided that the Client has a need for it.

"You wanted the window to be easy to open and close, fittings of European quality can provide it." “You said that the apartment is located on the first floor and you are afraid for the security of the apartment, I suggest you install anti-burglary fittings on the new windows.”

During the presentation, the manager needs to include the Client in an active dialogue using questions.

“How do you feel about my proposal?”, “What do you think about this?”, “How do you like my proposal?”

Stage 4 "Working with objections"

Target: to dispel the Customer's doubts about the purchase and remove the negative in relation to the product or service.

In order to reduce the number of objections of the Client, it is useful for the manager to devote more time to the previous stages. Often the objections of the Clients are related to the fact that the contact with him was not established well, his needs were partially identified, or the presentation of goods and services was not interesting to the Client, too long and did not satisfy his needs.

It is important to perceive the Client's objections as a signal that the manager needs to correct his behavior (especially if there are a lot of objections).

Objections from the Client may also arise at the previous stages of the sale. How to deal with emerging objections?

Effectively adhere to the objection handling scheme:

1. listen to the Client;

2. neutralize his emotions using phrases of understanding;

“I understand you”, “Yes, I agree that it’s unpleasant ...”

3. clarify, if necessary, information using questions;

4. offer constructive solutions or make an alternative proposal.

There are 4 types of customer objections:

1. objections related to changes.

“Why do I need this”, “I don’t see the point in this”

In dealing with such an objection, the manager must explain to the Client that the risks are excluded, show the consequences if the situation continues, give examples of positive experience in using something for the first time.

“By purchasing a window with European fittings, you are guaranteed to be protected from drafts, additional adjustments of the sash pressure, jamming of the closing mechanism.”

2. price related objections.

"It is too expensive for me".

In the argumentation, the manager should pay attention to the additional benefit that the Client receives, you can compare the cost of the goods with the cost of any other not particularly necessary thing or divide the cost by a certain period of time.

“When you buy a window from our company, you get a window care kit as a gift, as well as the opportunity to use free adjustment of fittings”, “A beautiful new window in the kitchen will cost you only 300 rubles. in a day".

3. objections related to negative experiences.

"I heard you have a bad profile."

It is useful for the manager to clarify the information by asking questions to the Client, to show the Client that you understand him and acknowledge the facts of unpleasant events (in case they were in reality) and then offer an alternative solution.

“Yes indeed, we had a batch of defective profile, which we returned to the supplier. At the moment, we have received a new batch, have already manufactured and installed more than 30 windows, all Clients are satisfied.”

4. objections related to the decision.

“I need to think”, “I need to consult with my wife.”

In dealing with such objections, the manager can once again clarify what such a decision is connected with, make sure that the client has accepted and understood all the information, and also use the methods to complete the transaction.

“If we sign an agreement with you now, then at the end of the week you will be able to admire the new window in the kitchen.” "Only until the end of the month we have a discount on this product."

Stage 5 "Completion of the transaction"

Target: push the Client to the transaction and confirm the correctness of the decision made by him.

Before completing a deal (signing a contract), the manager needs to make sure that the Client is ready to make a deal.

This can be seen from the signals it shows:

positive feedback about a product or service;
The client expresses approval to the words of the manager (assents, nods his head, etc.);
directly says that he agrees;
asks clarifying questions.

Deal completion methods:

1. method of limiting conditions and time.

"If you sign the contract today, we give you a 20% window discount."

2. compliment method.

"You really made the right choice."

3. win-win alternative.

“Will you be booked in for a measurement on Tuesday or Wednesday?”

In conclusion, I would like to say that the effectiveness of sales depends on the skill of managers. The more methods and sales techniques a manager has, the more flexible and successful he is when interacting with the Client. The profession of a sales manager requires constant development and self-improvement of skills. We wish you success on the path of professional growth and increase in sales.