I develop business software and sometimes I want to shoot a sales force. Then I take myself in hand, I remember that it is these guys who bring money to the company, and the programmers actually hang on the costs. At this point, enlightenment comes: sellers have a different mindset, different skills, and, more often, a different education. And every day they have to contend with a bunch of customer objections from the series, “and one contractor from India promised to develop exactly the same system twice as fast and cheaper.”

The essence of the problem

Sales - the very beginning of the project and errors at this stage - the most terrible. You will not work out the client’s expectations or miss the estimates and the “ kamikaze path ” awaits you. Reload the budget - you will lose a client or he will have a feeling of deceit.
')
To sell software well it is necessary to have solid experience both in development (technologies, management and processes) and in sales. These competences are extremely difficult to combine in one person, and when they are combined, such a person is called a “company founder” or “executive director”. I know examples of companies in which the director conducts the initial processing of all development orders. Typically, the growth ceiling of such a company is 25-30 people, and the director is overloaded.

An alternative option is to delegate the assessment to the technical director (CTO). Usually, this is the second most congested person in the company. In addition, the technical director of the car and a small truck of other tasks. Carrying it on every pre sales is not an option. I am sincerely convinced that any non-trivial project can be developed only iteratively and only with prototypes. This approach is still difficult to accept for many clients in the CIS. Everyone wants to fix deadlines and budget on the bank. Unfortunately, this desire is not accompanied by a technical task, on the basis of which it would be possible to work. Although from the point of view of the client, of course, the task is set clearly and clearly .

This article is not exactly a script for sale in the usual sense of the word. Rather, an attempt to build a bridge between "technical" and "business" - thinking and help those who have difficulty with the presentation and defending an iterative approach to development.

First meeting / incoming request

On the clickable to increase the picture below the life cycle of the project, how I see it. Green flags indicate the stages for which the customer makes a prepayment. The exception is the “sign the act” stage. At this point, the client accepts the work and pays the rest.

In the article, I will use the term “project” and not “product”, even if we are talking about a startup or developing a boxed, replicable product, because “product” development involves working with an internal rather than an external customer.


Tasks:

1. weed out inadequate customers
2. prepare adequate for the fact that with high probability the work is long and will require at least partial immersion in the project
3. carry out the preparatory work, find out the current status of the project request existing materials
4. to give the client a rough estimate of terms, costs and technologies (without fail, this assessment only shows the order of terms and prices, is not final and may change in any direction)
5. present an iterative approach to the client and propose to work this way

Weed out inadequate customers

Inadequacy is a subjective concept. For me, the client is inadequate if he:

1. Hamit
2. does not listen and interrupts
3. questioning any arguments or trying to catch a lie
4. appeals with theses, like "my son-student friend wrote a program ..."

Any of these points suggests that effective communication will not work out, which means that the project will fail. It is necessary to refuse such a client, since there are many requests for software development.

Prepare adequate

Suppose our client is adequate. At this stage, it is necessary on the one hand to prepare it for difficult work, on the other - not to scare too much and stay on an optimistic note.

The lion's share of all projects in IT does not fit into the deadlines and budgets. Others do not even go to the release. The reasons I described in the article " cost-effective code ." Despite this, there are still plenty of Hindus who are not experienced contractors who neglect risk in our field. These unfortunate programmers are not able to correctly estimate the amount of work, but they are able to promise mountains of gold. It is difficult for an unqualified client to choose the right contractor. The client uses the terms "cost" and "term".

In order to better understand the customer’s feelings, choose the right words and convey your thoughts, you need to put yourself in his place.

Once I had to buy an iron. I went to a major home appliance store. I watched a whole shelf of irons. The cheapest cost 800 rubles, the most expensive - more than 20,000 rubles. I was at a loss, because in appearance all the irons seemed the same to me. I asked the sales assistant to tell me the difference. The girl began to talk about additional options, modes ... The wonderful voice of the saleswoman seemed to me a song ... in Chinese. I asked her to advise me what she would buy for herself, took this model and went home, thinking how difficult it was for my customers. After all, they need not just to choose from the existing “irons”, but to design and assemble their own “iron” with blackjack and everything else.

I can divide complex clients into two types:

1. i will tell you how to do your work
2. what do you do with me, you are programmers - and you do

The first will send you a bunch of useless documentation, stick to the use of certain technologies or processes, require some specific reports, because "someone told them." In this case, I have a clear position: if you know how to do better, go and do it yourself . In this matter, you need to be tough. Otherwise, the development team begin to push the govnokodit and engage in the cult of cargo. This reduces team motivation and leads the project straight to the cliff. By the way, when the project fails, the blame will be placed on the development team, arguing that “the incompetent contractor was caught and made the wrong technical decisions ”.

With the second type of clients, everything is simpler and more complicated at the same time. On the one hand, they do not bother you, on the other hand, they deprive you of feedback and there is a great risk that at the stage of putting the project you will be told that " we expected a completely different thing." What they expected they didn’t really know that it wasn’t a reason to include the idiot-style " client fool, be-be-be ".

To give the client a rough estimate of time, cost and technology

At this point we have in our hands all the existing documentation on the project and some information, verbally committed, during a meeting or a call. Unfortunately, this is still a very early pre-sales. It is advisable to avoid evaluation and sell prototyping, because at this stage it is still correct to say “guess”, and not “evaluate”. However, if I give some kind of plug, I need to use the “resource method” of counting:

1. A programmer possessing the qualifications necessary for my tasks is in the regions of Russia (not White Stone)
   60.000 - 120.000 rubles
2. QA - 30.000 - 80.000
3. Manager 40,000 - 80,000

Typical small teams might be:

Option 1

1. Team Lead (Senior Developer + Manager)
2. Developer
3. QA

Option 2

1. Developer
2. Developer
3. Manager (at the same time and testing)

Option 3 (advanced)

1. Team lead
2. Developer
3. Developer
4. Developer
5. QA
6. Ux
7. Account manager

There can be many variations, these are basic compositions. The cost of renting a similar team per month for Russian outsourcers varies in the range of 500,000 rubles + - 100,000. Typical designs last from 3 to 12 months.

We multiply half a million by from 3 to 12 and get from 1.5 to 6 million rubles.

It is at this stage that we have a space for negotiations.

On the one hand, the client had to by this time make up an idea for what he pays and what dangers await when he goes to a nephew student or a contractor from Calcutta. On the other hand, the price range is too large. At this moment, the magic term “prototyping” appears on the scene. By prototypes, I understand mockup'y, collected by Axure or similar software, preferably interactive.

Prototyping can be calculated using the fixed-price scheme: the customer pays for the concept (3-10 screens). After the concept is approved, the development of the remaining prototype screens is paid. I believe that the design should be done by one UX / BA-specialist, consulting with the "techie", so as not to draw something too difficult to implement (this is usually sinned in digital) or not suitable for the chosen development platform. If there is no such specialist, then it is necessary to get into the state or on a contract agreement.

With the prototypes on hand, it is already possible to calculate the project according to the fixed-price scheme, so beloved by the client. Or maybe it won't be necessary to do this anymore and T & M will do. When you sell prototyping, you say to the client: “let's reduce our common risks, before headlong into the pool of development, once again we will think it over and draw everything so that you can touch it” .

Prototyping Arguments

1. Based on, you can more accurately calculate the cost. On the basis of the prototypes, the client will receive an estimate, indicating the technological stack, the platform that was really considered, and not taken from the ceiling
2. Prototypes can be proclaimed and, even before development, understand whether it is convenient to use the system and whether some key requirements have been omitted. Usability is not an empty sound . A bad interface can be a bottleneck in a business process, therefore, a reason for declining revenue. If the interface allows the operator to make a mistake, it can lead to direct losses.
3. Fix errors at the prototyping stage much faster and cheaper than at the development stage
4. The prototype can be used as a means of verifying the work of a contractor, it is much clearer and clearer than the text, excuse in the style of " I understand the TK " will not work

After the approval of the prototypes, you can simultaneously draw the final visual design and begin development. I prefer Scrum for the development team and Kanban for support. The organization of the work of the team on Agile and the approval of visual design are beyond the scope of this article. I will dwell only on the fact that I recommend coordinating with the client several intermediate demonstrations and the processing of change requests . At these meetings, you need to talk about the work done and offer the client to check the fulfillment of the goals of the sprints. Thus, the stage of implementation and integration will begin before the delivery of the project, which will help not to delay the signing of the final acts and promptly respond to changes in the external situation. As they say, the appetite comes with eating and after the first or second demonstration, the client may want to expand the functionality and budget.