I. The client is not always right
I want to dispel one popular stereotype that sounds like "the client is always right." Some clients motivate this that they pay money and have the full right to ensure that any decision of them is considered the only correct one and does not require discussion. Unfortunately - this is not true. As a client, you are just as interested in a developed product as a developer is interested in your order. Either party has the full right to withdraw from the contract, if something does not suit. In this case, the client will have to look for other developers, the terms will increase, extra money will be spent, and so on. Are you interested in this? I'm sure not.
II. Work with documents
Everyone knows, but very few people do, but at each stage and step it is necessary to sign documents. I say this time and again. There must be a contract, list of works, technical assignment, invoice for payment, NDA, etc.
From my point of view, the contract should be drafted to protect not only the rights of the client, but also the rights of the developer, otherwise it comes to conflict with intelligent teams and the choice in favor of less adequate, and at the same time less professional teams.
I met different contracts, the most interesting observations from what I saw:
1) The contract under which the client has the right to unilaterally reduce the cost of work. In my practice there was such a case. We were lucky that the contract value was small, but due to the fact that on the side of the client was not the most professional manager - we were delayed with the provision of information and as a result, we broke the deadlines and had to return the prepayment (according to the contract, they reduced its value. Later I discussed with another lawyer - technically we could refuse to return)
2) The contract with unrealistic time-frame, but with a "tasty" price tag. Well, no comment here - a sane person does not want to fit into such a project, when he risks receiving a penalty. We refused this client.
3) The contract in which the rights to works performed remained with the developers. Remember - you pay for the fact that the product is developed FOR YOU. Then this company competed with outsourcers, who received money for writing code to a client.
III. Working on the product and TA
One of the first questions we are asked is "Do you have a brief to fill in?" or "In what format to send a technical assignment?" In different companies, the approaches are different, but most of the outsourcing companies do not think about who will use the product and how, shifting responsibility for unsuccessful product decisions to the client. Progress Engine went the other way - each project has its own product manager, which helps the client to understand what he wants, how and who will use this product. If we see that the client does not quite correctly formulate the requirements for the product - we will try to help him, starting from our experience and the experience of colleagues in the market. If the developers do not participate in the analysis of the product and do not criticize every incorrect decision of the client, then this is inefficient spending of the budget.
The ideal option before starting work is to order product analytics from those who specialize in this. The result will be:
1) Technical assignment is a description of what you get and according to which the developers will develop your project
2) Roadmap is a development planning
3) Project decomposition according to tasks with an approximate estimate of the cost of each stage (this will improve the planning of the development budget)
4) Interactive prototype with which you can probe your product
At the previous stage, we decided on the roadmap. Now it is important for us to build the development process in such a manner that it will be as efficient as possible. A couple of key points:
1) Ideally, you should have at least one person versed in the technological part of the project. Not necessarily it must be a cool developer, but he must have experience in project management and knowledge of the used technology stack.
2) You need to call on the developers, get status and give feedback weekly.
3) The developers should close the next development stage weekly or at most biweekly. The result will be a working product with predefined functions.
4) The entire code should be delivered to you regularly, for example, sent to your repository at GitHub
5) You should have at least 3 environments (to put it simply - servers).Development is an environment where the developers will work. Staging is an environment where you as a client will accept work. Production is a fighting environment to which your users have an access.
6) After the completion of each stage (sprint) you should have signed an act that you have no complaints against the developers, and they give you exclusive rights to the code.
V. TL; DR or final checklist
1) Choose developers, based not on the price, but on the quality of the services they provide. In some cases, it makes sense to work with them according to the time and material scheme (hourly payment) - you pay for the time they have developed only and you able to flexibly manage the amount of work.
2) Choose developers who will think with you about how users will use this product and advise how to improve it. The quality of advice determines the value of the developers.
3) Sign a framework contract protecting the interests of both parties.
4) Sign an annex to the framework contract in which the work, its cost and acceptance criteria are clearly defined.
5) Check that all rights to work performed belong to you and it is specified in the contract.
6) Break the work into stages, determine the cost of each stage.
7) Pay for work not on one-off sum basis, but for each stage. This will allow you to quickly change the developer in case of problems with him, and he will not relax knowing that he has all the money on the account and he can work relaxed.
8) Perform product research. At the output, you will receive TA, Roadmap, decomposition with preliminary cost and an interactive prototype.
9) All accounts created for the project must be owned by your company - mailboxes in your domain, payment from a corporate account, the management has access, if the responsible person on the side of the client decides to resign from job.
10) There should be weekly conference calls with developers who should let you know the status and report on the work done.
11) The developers should close the next stage of development in front of you weekly or biweekly. As a result, the code should be "uploaded" to your version control system.
12) There should be 3 environments - development, staging, production.
13) The entire code should be tested not only by developers, but also by you. It will be perfect, if automatic tests are written.
If you have doubts about your developers - Come to Progress Engine, where you can order:
1) Product analytics, which is useful when you have nothing but an idea and it is not clear how to implement it.
2) Building business and development processes
3) Independent code audit with indication of all possible problems
4) Development and support of projects (including with complex integrations and high loads)
And what is more, we have cookies :)