I develop software for business and sometimes I want to shoot the sales department. Then I pull myself together, recall that it is these guys who bring money to the company, and programmers, in fact, hang on costs. At this point, enlightenment comes: sellers have different thinking, different skills and, most often, a different education. And every day they have to deal with a bunch of objections of clients 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

The sale is the very beginning of the project and the mistakes at this stage are the worst. Do not work out the client’s expectations or miss the mark and the kamikaze path awaits you . Relocate the budget - you will lose the client or he will have a feeling of deception.

To sell software well, you need to have solid experience both in development (technologies, management and processes), and in sales. These competencies are extremely difficult to combine in one person, and when they are combined, such a person is called the “founder of the company” or “executive director”. I know examples of companies in which the director carries out 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 is to delegate the assessment to the CTO. Usually, this is the second most congested person in the company. In addition, the technical director has a wagon and a small cart for other tasks. Carrying it to 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 customers in the CIS. Everyone wants to fix the time and budget on the shore. Unfortunately, this desire is not accompanied by a technical task, on the basis of which one could work. Although from the point of view of the client, of course, the task is set clearly and clearly .

This article is not quite 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 presenting and upholding an iterative approach to development.

First meeting / incoming request

In the clickable image to enlarge the image below, the life cycle of the project as I see it. Green flags indicate the stages for which the customer makes an advance payment. An exception is the stage of “signing the act”. At this point, the client accepts the work and pays the remainder.

In the article I will use the term “project” rather than “product”, even if we are talking about a startup or developing a boxed, replicated 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 will be long and will require at least partial immersion in the project
3. carry out preparatory work, find out the current status of the project, request existing materials
4. give the client a rough assessment of the timing, cost and technology (be sure to specify that such an assessment shows only the order of terms and prices, is not final and may change in any direction)
5. present an iterative approach to the client and offer to work that way

Weed out inadequate customers

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

1. rude
2. does not listen and interrupts
3. questions any argument or tries to convict in a lie
4. appeals theses, like "I have a friend, a student son wrote a program ..."

Any of these points indicates that it will not work to build effective communication, which means that the project will fail. It is worth abandoning such a client, since there are many requests for software development.

Prepare adequate

Suppose our customer is adequate. At this stage, you need to prepare him for difficult work on the one hand, and not to scare him too much and stay on an optimistic note on the other.

The lion's share of all projects in IT does not fit into the timelines and budgets. Others do not even go out. The reasons I described in the article " cost-effective code ." Despite this, there are still enough Indians in our industry who are not experienced contractors who neglect risks. These unfortunate programmers are not able to correctly assess the amount of work, but they are able to promise the golden mountains. It is difficult for a non-qualified client to choose the right contractor. The client uses the terms “cost” and “term”.

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

Once I needed to buy an iron. I went to one major home appliance store. A whole shelf of irons was looking at me. 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 explain the difference to me. The girl began to tell something about additional options, modes ... The saleswoman’s marvelous voice 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 clients. After all, they need not only 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 are you bothering me, you are programmers - you do

The former will send you a bunch of useless documentation, insist on 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 begins to push govnokody and engage in the cult of cargo. This reduces motivation in the team and leads the project directly to the cliff. By the way, when the project fails, the blame will be laid on the development team, arguing that "the contractor was not competent and got the wrong technical decisions ."

With the second type of clients, everything is simpler and more complex at the same time. On the one hand, they don’t interfere with you, on the other hand, they are depriving you of feedback and there is a great risk that they will say to you “ we expected a completely different thing” at the stage of the project completion . What they expected, they really do not know, is not a reason to include a fool in the style of "the client is himself a fool, be-be-be-be ."

Give the customer a rough estimate of the timing, cost and technology

At this point, we have on hand all the existing project documentation and some information verbally delivered during a meeting or call. Unfortunately, this is still 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 you give some kind of plug, you still need to, I use the "resource method" of counting:

1. A programmer with the necessary qualifications for my tasks costs 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 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 projects last from 3 to 12 months.

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

It is at this stage that we have space for negotiations

On the one hand, the client had to make an idea at this point for what he was paying and what dangers awaited when contacting a nephew student or contractor from Calcutta. On the other hand, the price range is too large. At that moment, the magical term “prototyping” appears on the scene . By prototypes, I mean mockups assembled with Axure or similar software, preferably interactive.

Prototyping can be calculated according to the fixed-price scheme: the client 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, in consultation with the "techie", so as not to draw something that is too difficult to implement (this is usually done in digital) or not suitable for the chosen development platform. If there is no such specialist, then it is necessary to have a staff or contract.

With prototypes on hand, you can already calculate the project according to the fixed-price scheme so beloved by the client. Or maybe you don’t have to do this anymore and T&M will do. When you sell prototyping you tell the client:“Let's reduce our overall risks before rushing headlong into the development pool, we will think it over carefully and draw it again so that you can touch it . ”

Prototyping Arguments

1. Based on this, you can more accurately calculate the cost. Based on prototypes, the client will receive an estimate indicating the technological stack, the platform that was actually considered, but not taken from the ceiling
2. Prototypes can be clicked on and even before development it is possible to understand whether it is convenient to use the system and if some key requirements are missing. Ease of use - not an empty phrase . A poor interface can become a bottleneck in a business process, and therefore a reason for lower revenue. If the interface allows the operator to make a mistake, this can lead to direct losses.
3. Correcting errors at the prototyping stage is much faster and cheaper than at the development stage
4. The prototype - can be used as a means of verifying the work of the contractor, it is much clearer and more understandable than the text, an excuse in the style of “ I understand TK ” will not work

After approving the prototypes, you can simultaneously draw the final visual design and begin development. I prefer Scrum for the development team and Kanban for support. Agile team organization and visual design approval are beyond the scope of this article. I will only dwell on the fact that I recommend coordinating with the client several intermediate demos and the process of processing change requests. At these meetings, it is necessary to talk about the work done and invite the client to check the fulfillment of sprint goals himself. Thus, the implementation and integration phase will begin before the project is completed, which will help not to delay the signing of final acts and respond quickly 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.