We hope that the need for project documentation is already obvious. But often there are many questions related to the volume of these documents and their level of detail, and most importantly, who, at what time, and under what conditions should prepare these documents.
The cost of developing pre-project and project documentation can be a significant 10-20%. In this article, we will look at the main documents and tell you how you can save money while winning the quality of work.
Before starting a new project or restarting an existing one, it is highly desirable to combine the information you have in a single document. This document can be called a "Cover note". It does not have a standard format, because each company has its own volume of information and rules for its distribution (internal documents are confidential and only excerpts can be provided). What information should be included in the accompanying note:
As soon as you will generate a cover memo, you will be able to initiate contact with contractors if you plan to implement the project yourself, then you can skip this point.
Most likely, the contractor will send you a brief to prepare a commercial offer. This is a document containing many different questions. If you have collected information in an analytical note, you will only need to specify its section and copy the information for most items. This is often a formality, but it is necessary due to the fact that the contractor needs to document the first introductory steps for your project.
If the performer offers you an interview, don't refuse it.
This document is optional, but we recommend that you create the basis for it yourself. This is necessary so that the contractor can develop the technical task taking into account all your needs.
The format of this document is also quite free - just list the functionality, requirements, and restrictions in as much detail as possible. At this stage, it is extremely important to transfer information about the functionality of an existing project to this document, if you need to reproduce it. The performer may simply not know about its existence, and simply not include it in the estimate.
Often some points of your requirements will contradict each other. These contradictions should be discussed with the contractor and the document should be corrected so that it gets rid of such contradictions.
What information should be added to the functional requirements:
You “shook hands” with the contractor and moved on to development. This is the first document that you will be offered to pay for. If the cost fits into your budget, we recommend creating it.
This is a bit like psychotherapy - developing it will help you better understand your clients. If you are planning to implement a SCRUM/Agile project, it will be difficult to do without IT. We do not recommend that you take it on your own if you do not have the appropriate experience.
User story briefly describes:
The second document that you will be asked to pay for. The cost of developing a prototype is already palpable, and you can't refuse it (if the Studio allows you to do this, it should at least alert you).
A prototype of a site or mobile app is an interactive project framework that you can” walk through " by reproducing scenarios of interaction with the interface.
You need to develop a prototype for the following reasons:
You need to consider several important features of the prototype:
Should I work on usability at the prototype stage? In this case, there is no universal answer. The General advice is: if it is possible to do this within the framework of the prototype, then do it, but first agree on the presence of elements and General navigation logic. In this case, the ui / ux specialist will not be customized, and you can start the next work.
Sometimes it is much more effective to prepare a prototype for even a small functional upgrade than to do and then edit "live".
Can I develop a prototype myself to save money? Yes, if you have the time and experience. However, in this case, we recommend that you specify the format in which the prototype will be needed by the performer (they will need to make a number of changes to it to ensure its consistency with the technical task).
After the prototype is developed and approved, you can start writing the technical task. These works must be entrusted to the contractor or a third-party professional ( having previously agreed on the format and requirements for the TOR on the part of the contractor).
We recommend that the TOR be issued as an Appendix to the project development agreement.
Sections of the terms of reference should be strictly structured, and described as a General introductory and specific local task that the developer or their team needs to implement.
What should the TK contain?:
If the project is implemented using SCRUM, the TOR can be developed separately for each sprint. It will be updated with each sprint. However, in this case, you need a roadmap for further development of the project, so that the performer understands what he needs to take into account when designing the project architecture.
This also explains the answer to the question “what to do with your TK?” . In the process of implementing the project, you have to deviate from the TOR for various reasons, and so that by the time of delivery or if necessary, read the documentation for the project, you do not have to give up in confusion, we recommend updating this document at least weekly. The Customer is primarily interested in this, but it is not uncommon for this work to be taken over by a Manager on the performer's side.
Please note that, as a rule, integration is described in the TOR only from the project side. If another service does not have regular integration or it is not suitable for your tasks (for example, 1C enterprise), then all questions will remain on your side, because the performer will confirm the working integration by simply “running” the reference file. If you need to conduct development in parallel, do not delay it.
A small document that is often attached to the TOR. It describes the further development of the project (sometimes several scenarios) and the stages of their implementation. The document is " live” and requires updating after each stage of development.
This concludes our review. We wish you clear documents and successful projects.