This article is based on personal experience of the developers of our company and will tell you how to analyze and evaluate the requirements specifications as well as provide the development results to the customer.

4 ways to evaluate the task in order not to miscalculate

1. Range of estimates «from and to». Used if it is impossible to give an accurate estimation, for example, the tasks to update greatly modified 1С configuration (when the changes where made not by the same programmer who transfers them), some design works which are connected with a long discussion with the users during development or involving a third party.

The range helps to determine the overall budget of 1С task. According to the results, the actual estimation is given. If it becomes clear that the actual costs may come out the initial range, it is immediately reported to the Client.

2. Inexact estimation, with reserve to change not the main parts of RS. Used if the Customer has a long negotiation of budgets inside company and the Client needs a particular price of development on the 1С right now (without additional costs).

Also used if there is a probability of some changes in the minority moments. How? the task is estimated as a general development, with reserve (determined separately) for discussion and modification or particular moments - according to the implementation results.

3. Estimation with small technical questions. Performed when, following the results of specifications, you have a clear and complete task description in terms of user part of the system.

At first, everything is specified except irrelevant for the user implementation moments (technical and fast variable). Then the general implementation is estimated with the risks of development complexity taking into account, for example, different technical methods to solve the same problem. The specified risks could be zero of you have already implemented all of this and you have a working example.

4. Estimation according to the strictly and completely described job (both business block and a part of technical implementation). Used when on the customer side there is own department of 1С development with its own standards. How? The business logic of job as is specified a whole (what does the user need this for, what we will get as a result, etc.), the technical architecture of 1С task is analysed and specified provided by the customer or our own implementation variant is offered and negotiated. This work is estimated as accurately as possible.

«Method of double reading» when analysing large and unintelligible RS

Requirements specification is not always written as clearly and logically as possible. This is especially common in the 1С industry. Sometimes the job is just too large, with illogical interrelations throughout the text. How to manage the analysis of such tasks in order to minimize the risk of unnecessary questions and the loss of questions associated with interrelations between different job objects? in fact, there is nothing complicated if to read the requirements specification two times setting the questions during the second reading.

First reading. Preparation of general structure (technical skeleton) of the task, checking the existence of used objects, opening the forms and modules to view the volume and complexity of the code.

Second reading with the addition of questions. Specification of particular moments for yourself. Selection of specific implementation methods. Setting the questions on the obscure moments. Modification of the idea of general mechanism structure. thinking through the complex moments of table joins, structures of registers.

Result
Thus, after the first job analysis (before specification of questions), it is possible to give the range of estimates or already the finished estimate if the questions are minor.

Advantages of double reading:

• Efficiency in the analysis of requirements specification with incorrect sequence of description (only in the end it becomes clear what was meant in the beginning).
• As a result – absence of unnecessary questions.
• In the second reading, knowing the general structure and idea of the whole task, it is possible to define more clearly implementation of some blocks so that they take into account the general mechanism.
• Also, the knowledge of general structure is important to define the moments not described in the requirements specification. That is, during the second reading you will already see clearly and note, for example, what is missing in the first block, what is used further in the second.

When and how to involve an expert in the work
1. If you have not enough knowledge to analyse or estimate the requirements specification in some area, it is better to get involved an expert. Find out who knows that and agree that he will help you. Or contact the head with the question to find an expert as an external consultant.

2. It would be nice to record the contacts of people competent in something you do not know. On occasion, you can help using this contact to someone from your colleagues.

How to know everything you need and do not seem stupid.

Basic principles to specify the jobs
When communicating with Customer, even it is the case of purely programming questions on 1С, not always everything is the most convenient and clear. Since everyone used to work in their way, you must be also able to build the correct working communications. here are a few recommendations on how to properly communicate with the Client at the initial stage so that in case of dispute it was easy to restore correspondence and recover mutual understanding.

1. Ways to ask the questions
1.1. Place the questions in the RS file and send it already my email – this is the most secure and right approach (if responds by mail are quick or the terms do not fall apart), since everything can be seen as once in a single file. The way is divided into the questions:

• In the notes (aside).
• Highlighted by another colour and font directly in the text.
• Revision method (Word). This file is attached in the total to the task of accounting system (for example, JIRA).

1.2 When there is no an individual file of requirements specification, record the questions in the letter body. In this case, place in the task of accounting system (for example, JIRA) all discussions. At least using the method «Copy» - «Paste» from letter.

1.3. Avoid the questions in Skype. correspondence in Skype can be rarely considered as a proof of arrangements with consultant (it is possible there both to edit and delete the text, the messages are not stored on the server). The messages in Skype are forgotten or, due to the absence of external server to store the messages, are lost. And you can just get on inconvenient time for the consultant and he, fluently reading the question, will understand it incorrectly.

Therefore, all the final discussions or question found out, for example, during the day record by the letter. Briefly describe the accepted decisions with introductory text, for example, «Replicate discussion in Skype by the letter». Also, the same text is copied in the accounting system (for example, JIRA) in the comments to the task.

1.4. Convert in text the voice questions over Skype and phone. in oral communication it is better in any case to record the arrangements and answers by the letter similar to the previous point. Also, the same text is copied in the accounting system (for example, JIRA) in the comment to the task.

1.5. Collect and classify all the information in a single file. For points 1.2, 1.3 and 1.4 it is better to copy the obtained texts of discussions in the text of requirements specification (for simplicity, for example, after the main text). So you can always send a file with all the information.

2. Principle of questioning – «90% and at once»
Try to see the ambiguities and ask the questions directly to the maximum. Finding all inconsistencies in the requirements specification is achieved by exercising the simulation in the mind of task technical implementation. This is more effective and convenient than asking a customer representative up to 10 times a day, getting on the moments when representative is away (they are people and also go to the toilet, are late, eat and even get sick).

3. Methods to resolve issues
3.1. Versions of your understanding together with qualifying questions. If it is appropriate, (it becomes clear during the first conversation with 1С consultant) in case of obscure wording in the requirements specification, it is possible to offer in the texts your own versions of task understanding. That is, «It is meant that or for all that… If the first, then the question is as follows:…”

3.2. Ask again – for reliability. If it is written that everything seems to be clear, but you are not sure, then it is better to ask: «Did I understand correctly that …?».

3.3 Delayed power of «hanging letter in mailbox». In addition to the above-mentioned disadvantages of questions in Skype and on the pone, there is such that a person get tired to talk and, thanks to subconsciousness’s good graces, resets all – that is, forgets what he wanted to say. But the letter hangs and waits for respond.

3.4. «Questions - in the evening, answer - in the morning». If sending the questions by email was delayed to the evening, it is better to send the letter directly in the evening, no to delay until the morning. Then in the morning the letter will be immediately seen on the other side. If you send the letter in the afternoon, then the day is already scheduled by that time and people can not find the time.

3.5. Take into account the probability of force majeure circumstances. Enter all the answers and clarity from Skype, letter and voice in the comments of accounting system (for example, JIRA). In case of force majeure you and you colleagues will be able to restore quickly all the information.

6 rules of accurate estimation of task complexity

How to minimize the probability of the estimation «at random»?

1. Estimation using PERT method. In our company 1С developers use the estimation according to the PERT method.
This estimation is given as follows:

1.1. Task subdivision and estimation in parts. The task is divided into the small blocks-subtasks which can be estimated as accurately as possible.

1.2. Forecasts of task solving – according to the optimism scale. For each block the optimistic, real and pessimistic estimate is calculated. If you are not the consultant for yourself and do not know everything perfectly, then the estimates, as least a little, will be different! (not counting the task like «adding attribute without adding to the form»).

1.3. Basic calculation. Next, according to the mathematical formulas, the estimate is calculated for the selected percentage probability of task completion.

Optimistic – this is the complexity that can be obtained if everything will be good. That is, you understood everything correctly and the sudden difficulties with implementation will not occur.

Real – this is the complexity that is usually obtained according to your experience: “most likely it is not so easy, but I will deal for a certain time, plus usually another question of implementation arises, so plus the time fir specification”.

Pessimistic – this is the complexity that can happen if everything will be bad. For example, if there is anything that is difficult to implement, then determine how long can run implementation at its maximum. If for some reason you have any questions, keep in mind that the answers will be the most unfortunate.

For quick estimation, you need to have a special finished Excel file in which all formulas are stored, and it only remains to enter subtasks and their estimates. Our template of estimation file consists of two pages:
a) On the first one the costs are recorded for analysis already performed for estimation, and the overall calculated figures are displayed according to the data of the second page, also the percentage of overall testing is calculated separately.
b) On the second page – the task parts and their estimates (optimistic, real and pessimistic) are entered in the table.

2. If the block is not clear and it is impossible to divide it:

2.1. Get involved an expert if you cannot estimate the block.
2.2. If there is no expert, this shall be reported to the head and the task is estimated by a wide range «from» and «to»

3. Approximate structuring - by points. Block for estimation is not the object as a whole with all its functionality (unless you can estimate it perfectly)! The points of blocks in the estimation are, for example, the form, scheduled job, new register, function, query, etc.

3.1. Example. That is, 1С development of report using ACS is divided into: query composition, filling the parameters from report form, remaining form, output of specifics in template, process to describe and attach external tables, design, etc.

3.2. Sort out the moments complex to implement. If there is any moment complex for you to implement, you must sort out it separately. For example, filling the certain column in report. Or it can be, for example, a separate analysis of certain thing in foreign code and a separate development according to the analysed functional.

4. Why subdivision is you friend? The more objects are estimated without subdivision, the worse estimate. In 90% of cases it means that the estimate is less than real complexity.

5. Analysis of requirements specification is also included in the estimation! According to our file, everything you spent for development estimation you record and include in the field «Analysis» on the first page.

6. Further everything is calculated for you the formulas in file. (For the calculation file it is necessary to define initially the percentage of completion probability within the estimate that you need).

How to report the development results

Often it is very important how you provide the results of your work. It is especially important when you start working with the customer.

What d you have to know about people as developer:

• People do not trust other people by default. So, they will be doubt that you have tested everything, finished everything and made everything at all that is necessary.
• Also people get irritated if they do not know or do not find anything, especially when it is something simple. And since people do not tend to blame themselves, they will subconsciously blame you as a developer of such «not intuitive interface».

6 development results which you should write to the Customer

1. If you made some decision during development (there was no consultant or specification was not essential), then this should be written in a letter in task delivering. For example: «when opening the processor, the field Organization is automatically filled from the user settings, since it is required for the further automatic filling».

2. If you have developed for your objects in 1С configuration a new interface or added menu item in the existing interface, you need to write about it without fail! Specifically: where added and what will appear there at the opening. The user should not look for what and where you have created.

3. if you have added something else that was not discussed at all, then again, it is necessary to write about this. For example, «In addition, when conducting document, there is a check for the fullness of attributes».
The customer will be pleased that you have thought about it, so let the additional positive emotions appear completely, during the first testing.

4. If it turned out that you did not thoroughly talked for some features, for example, the setting form, then you need to write on the basis of implementation results what can be configured there and how.

5. Description of testing process will protect against negativity. It is better to write 3-4 sentences how and what should be done to test your functionality. This will save you from unnecessary, though perhaps short negative like «I did not understand anything on the fly». Because the people will understand where to click, but a bad sense will remain.

6. Complete on the positive note. And the main thing! The phrase «if there will be any questions on the new functionality - just write. I will be pleased to answer» did not kill anybody, but the effect from it is awesome – the user is not nervous and, therefore, better understands the results of your work.

PS: Colleagues, write reviews and comments

Article author: Andrey Makarov, company Neti