Terms of Reference for revision: 10 rules and a little tediousness
If you go to foreign sites with the request “product requirements document”, you can find creative and convincing articles about the fact that the technical task (TK, PRD) has died. In part, we have to agree with this - when developing a product from scratch, prototyping looks much more interesting and more efficient than the volumes of customer records, sometimes very unprofessional. However, if we are talking about the finalization of the basic system, then it takes a completely different turn. We are faced with both refinement and customized development, so they ate the dog for TK if the cook doesn’t lie to us. In general, today - about the very classic technical tasks that are written to finalize the purchased and installed software. In short, about sore.
Before proceeding with the preparation of the process of creating the technical specifications, let's talk about the quadrilateral, which the contractor and the customer fall into when starting the project.
Requirements - the desired behavior of the system, as described by the customer or process holder, to be implemented. As a rule, requirements are formed on the basis of work experience, presentation of the correct behavior of the program. This is the key information for the developer (vendor), however, it is at the stage of collecting the requirements that the largest number of conflicts, errors, excessive requests and so on arise.
')
Resources - people, machines, inventory, development environment, time and money to be used in the process of implementing the requirements. Resources require precise planning and evaluation at the stage of approval of the technical task. Competent prioritization on the part of the customer and distribution of labor resources on the part of the vendor make it possible to avoid a deadline and minimize other risks.
Opportunities - in short, this is what a vendor (performer) can actually do. Consider the example of our RegionSoft CRM . The client buys the system and creates a technical assignment for revision: you need to create integration with the site and link events in CRM to the order number of the online store. This is a real-world requirement, we have the resource and the ability to do it. And still need to develop and tie to the CRM CMS, content management system site. Theoretically, we can do it, but we are not able to do it cheaply, and the client does not have the opportunity to pay us so much so that we can transfer human and time resources to the task. As a result, the customer refuses this requirement - and he doesn’t really need a CMS, everything is so good. But about the "greed" TK - later.
Restrictions - a set of obstacles that make the execution of tasks from TK difficult or impossible: budget, technology stack, licensing issues, legal prohibitions, hardware configurations, and so on.
Thus, all four entities are closely intertwined with each other and determine the success of the project as a whole. Consider each element and try to highlight the critical moments that need to be borne in mind when working on the terms of reference.
This is a very important internal corporate process, during which it turns out what the program wants (hereinafter we take CRM, but the methods work with other types of software) potential users. If you contact a large vendor like SAP or a system integrator, then with a high degree of probability you will be offered to use the services of a business consultant (he is a personal manager, he is also an account manager, he is "now your representative in our company"). In fact, in most cases, this is an ordinary well-trained salesman who has two tasks: to wind up the cost of the project and not let you off the hook.
He has been here for an hour and has not even touched a white marker board. He is not a true systems analyst.
Better than you and your employees, nobody knows your company. So, the collection and analysis of requirements - only your task, in which the vendor can help and direct, but in no case intervene in the process. Ask the developer about such implementations, specify what to look for and proceed. By the way, a good assistant can be your employee, who is well versed in the profile topic and roughly represents the software architecture and is familiar with the development process - he can act as an analyst and internal expert, close the process of creating TK and communicating with the vendor.
There is a very simple pattern of collecting requirements.
Once the requirements are collected, analyzed and agreed with the staff and management, you can begin to create the terms of reference. You can ask the vendor for the form or compose it yourself - in any case, there are a few iron rules, the observance of which will relieve you and your CRM supplier from headaches.
If we talk about the process of creating technical specifications, then there are several stages. Their successive passage leads the customer to the desired refinement. Here they are.
In general, the technical task can be created on the basis of the requirements of several levels that can intersect and cooperate in creating a project or not interact at all.
The level of business is the most global level at which complex and priority tasks are solved. This level includes integration, refinement and modeling of business processes, the development of new functional modules. As a rule, this is a resource-intensive development, with serious advice and close collaboration with the customer. For example, in due time in RegionSoft CRM such warehouse customization was warehouse accounting, cash and production. Gradually, the changes entered into the release, and later allowed to create a new product for wholesale, retail stores and hypermarkets - RegionSoft Retail .
User level or user groups. At this level, tasks are completed to refine the existing interface. For example, a user may want a window with the number and status of the last order or a custom report with a special grouping of data to appear when the cursor is placed on the client. Improvements at this level take less time, but they can be many - for example, several requirements from the marketing, logistics and technical support department.
Level of functionality It is often difficult to separate it from the previous one; a formal criterion works here - refinement is not at the level of displaying something in the interface, but at the level of refinement of the system logic. These include requirements for various kinds of sorting, integration with chat, telephony capabilities.
The level of service - in fact, the requirements of this level should be the first to get into the new assembly with fixes. These are tasks related to system response speed, high load operation, and security. Ideally, the vendor should not have such improvements - corporate software should not slow down, lose data, collapse forms and distribute access rights of the same level. But if the requirement has appeared, and it is not connected with the personal paranoia of the customer or problems on the hardware side, it is worth paying special attention to it.
The level of technology is the last in the list, but ahead of the rest in importance and complexity. These may be customer requirements related to the platform, operating system, or devices. For example, build request for MacOS. It is great if such requirements gradually grow into releases, but it’s necessary to have their fixes. It was from customer requests at this level that we built RegionSoft CRM for MacOS and added remote access using TRM technology as a temporary solution to a rare but existing request for a mobile version.
Anatomy of a technical task is simple, at least in the form of a skeleton. Mandatory parts of the technical assignment help the customer to focus on the problem and formulate the task correctly, and the contractor to understand what they want from him. By the way, about understanding. Of course, at the beginning of the post, we were a little hilarious, denying business consultants as a class. The point is this: each vendor has been working on the market for several years (we are not about one-day CRM), or even decades, which means it has a set of cases for almost every industry. Accordingly, engineers, programmers, and salespeople are familiar with the specifics of implementation in each type of company. But again, it is important to focus on your business.
For whom? In this section, you need to describe who will be the end user of refinement, what tasks and how often it is planned to be solved.
I will give an example. In one company, CRM was implemented, it was supposed to work on a fairly large data array (several tens of millions of records per month, several hundred thousand records per day). The head of the sales department requested a report on the unloading of these records at intervals of "daily". Naturally, such a report while simultaneously operating hundreds of users loaded the system - solutions were found to optimize the process. Already in the course of work, it turned out that the sales clerk was reinsured and only needed the report for the end of the month, and then it can be run on a schedule at night. Needless to say, time and money were wasted.
What for? Justification of the need for improvement and its place in the business process. This item is more needed by the customer, but it is useful for the vendor to know what other processes will be affected. Sometimes it helps to find an alternative solution.
What should do? The most informative unit - it describes the requirements, expectations from the system. And it is here that the very pearls, miracles and collisions occur that fit to send to the tower, and which well complicate life very much. There is one reason - the user does not know what he wants, what needs to be done. There is also a small sub-reason - the user cannot formulate requirements. And here the task of the developer (working group, analyst, if any) is to help formulate the need correctly, choose the appropriate requirement, enter the task in the context of the system. In the same block it is necessary to mention the expected result.
The specifications of the technical task are the terms, stages of implementation, responsible from all parties, the necessary contacts and so on. In fact, it is a set of important formal things that make a document a technical task. The technical task must be agreed and signed by the parties in order to avoid numerous changes in the course of development (they will still be, but in a smaller volume).
The technical assignment for revision should be the specification for revision , and not the 300-page description of CRM, which is necessary for the client. Before drawing up the requirements, you should carefully familiarize yourself with the system interface, its capabilities, documentation - most likely, the majority of the "helpers" are already in the basic package. The second step I would recommend is to pay attention to the built-in improvement tools (report designers, configurators, etc.) - perhaps the staff programmer can make the necessary changes (in many companies there are).
The technical task should not be greedy. Often, a business overestimates its capabilities or wants to get “everything at once”. This approach is not justified either in terms of money or in terms of business. A vendor, as a rule, does not exist for a couple of weeks (in the case of RegionSoft - 15 years), and you can turn to it after some time, when you really understand what is missing in CRM.
A vivid example of redundancy is literally from yesterday: a client bought an ERP from a well-known Russian company, thinking that once accounting works, then the ERP of this vendor will be good. ERP was not that not very by itself, but not very suitable business. But RegionSoft CRM with warehouse accounting and production is suitable. There is a solution: forget about ERP, cry, integrate 1C accounting with the new CRM and enjoy the convenient implementation. But the money pooled pity! And the client requires to integrate CRM with ERP. We did not do this, but why such a waste, why two relatively similar systems?
The terms of reference should be realistic and feasible - both in terms of requirements and in terms. Here it is important to listen to the vendor's opinion, since he knows exactly how long it will take for a particular task. Believe me, the developer is not profitable to take time and wind up the deadline - it is beneficial for him to complete as many projects as possible and do it well, so as not to get a blow to his reputation. As for realism, it is easy to avoid requests to finish CRM to the level of a collider control system: you should include in the requirements what you really need at the moment and in the foreseeable future.
For example, RegionSoft CRM is a desktop program, we do not have a browser client. It makes no sense to ask us to create a web application for one company, this is a major development, it is underway and is not a possible refinement for one company. No, of course, everything has its price, but again - in the general case, the requirement is impracticable.
It should not be confused with the situation when it comes to custom development and the idea and logic of the application work is changing fundamentally; in fact, the creation of a new software is sponsored. But that's another story.
The technical task should be detailed. It is necessary to specify all significant details of the future project: from the frequency of using the program to the wishes of the interface. The more detailed the requirements, the easier and faster the implementation and testing will be. Particular attention should be paid to the details if you work in a specific industry (medicine, insurance, banks) - a detailed statement of the nuances of the interaction between business and the program will provide an understanding of the task of the vendor and a quick adaptation of the system to your company.
Be sure to pay attention to the format of numbers, field names, the presence or absence of drop-down lists, the behavior of buttons and hints, data types. If the customer uses his own formulas that need to be put into the logic of the CRM operation ( for example, calculating dealer bonuses ), these formulas should be spelled out with a full transcript of their designations and calculation logic.
Yes, corporate software looks like this, and there are a lot of important details in it.
Terms of Reference should be unambiguous and accurate. Vague wording, implementation options, fuzzy requirements - all this is a way to a dead end. It happens that a client of good intentions writes several options for system behavior that are close, but not equivalent. In this case, he is sure that he helps, he tells the programmer, but in fact the developer has to understand what is needed, and he will choose how to do it himself, based on the system’s features and the stack of technologies used.
This year you can make a wish again. Only, please do not waste it on the fact that even I can not fulfill, such as clear business requirements!
The technical task should be written in human language. And this is important, no, IMPORTANT. I will highlight two situations where language problems lead to a delay in project implementation.
And yet - do not use editors such as Microsoft Visio and UML diagrams, if you do not understand them. What seems beautiful and business-like, in the opinion of the developer, is hellish confusion. If you want to insert a diagram or a picture - draw it with human methods, do not bother yourself, it will not help us, the developers.
The technical task should not be a complaint book. It is necessary to solve the problem, and not to describe it, paying attention to the fonts and forgetting about the description of the requirements. The TOR must contain not only the problem itself, but also its solution at the level of comprehension - then the developer will already solve it at the code level. Compare “the sales department is not planning well, it is losing numbers, we have been fighting for a year now” and “it is necessary to create a report that will keep the values of the plan and the fact of sales every month, in the context of groups of nomenclature” .
The technical task should be able to look to the future. Well, not quite it, but the people behind it. If it is known that soon there will be changes in business processes, this must be taken into account in order not to pay for the revision twice.
The technical task should not be bureaucratic. If you have at least once drafted this document, you probably felt how difficult it was to avoid the temptation to slip into the bureaucracy, bloat the introductory words, strict turns and describe each clause as an article of the Criminal Code (preferably with punishment to all for violation). Bureaucratic wordings mask an incomplete understanding of the goals of creating TK. Responsibility vendor spelled out in the contract, there is written a budget. You should not transfer these points to the technical task.
The terms of reference should be a technical assignment. It sounds paradoxical, but often, instead of TK, we read letters, complaints, contracts, re-written instructions for CRM or meeting minutes. Of course, it is impossible to work on such a document. In order not to get away from the form and content, use the old school trick: consider the term by words. Technical means that it dictates the refinement, the technique, is aimed at solving the problem by changing the software. That's about the task in the context of the software and need to talk. A task is a question, a problem, without advice, tips and preliminary assessments. Just a task statement.
In addition to these rules, there are a few things worth mentioning. We are talking about goals, plans and expectations - all those who leave who make the project successful, and the relationship between the vendor and the customer are almost friendly.
The technical task is necessary to write quickly , even if you are faced with the task of automating the processes of a cellular operator or a large hypermarket. This is due to the fact that technologies are developing at a tremendous speed, and even the system that you are implementing can survive a major release (and sometimes two) in six months or a year, and get new functionality. You may have to revise the need for improvements and start the process over.
Finally, he found the time to finish the TZ. But, alas, there are no developers left around to implement it.
The client does not know about the stack and technical limitations. And should not know - this is the task of the vendor, it is he who evaluates the work after drawing up the technical task. The customer should not delve into technology and ask each vendor whether the vendor can do this or that thing. Create a complex TOR and the developer will choose the appropriate architecture - often even better than you might think.
Estimate the budget and avoid unpleasant surprises - perhaps the number one joint task. You should not pull the vendor and require an approximate assessment of work from him (well, at least approximately, offhand, by eye, and like the others, well, in projects of this type, but from experience, well, so far, within the margin of error). A full budget assessment is possible only after reading, analyzing and final approval of the technical task. If your developer acts differently - get ready for the fact that the revision will cost at least two times more expensive.
Proceed from the objective need for changes and extensions - I wrote above that the developer does not disappear and is ready to make changes and additions to your requirements at any time. Therefore, don’t try to create a CRM / ERP dream right away, don’t ask the vendor for the “Everything works while I drink coffee” button - work in the system, define critical comments for you and start collecting requirements and drawing up the TOR.
You can write about technical tasks endlessly, this is a real generator of not only memes and fables, but also a headache. You can talk about priorities and design rules, about GOST 1989, which makes TK inhuman, IEEE standards, which are slightly better, about prototypes and TK that complement them. But in the end I would like to confine myself to one, the most important rule: the technical task is not a rule of law, not GOST and not a dogma, so if you can improve, improve, you can simplify, simplify, you can do it elegantly and make everyone like it. I am sure that no one after this will stick his nose in the TK and will not say that it is not written there. Or almost nobody.
Throughout December, we offer discounts on RegionSoft CRM and all our proprietary software. From December 1 to 15 - 15% and steep terms of installment and rental. We do not have -70% and -90%, because we keep the economically reasonable price for the license, and do not take it from the ceiling.
Verge of interaction
Before proceeding with the preparation of the process of creating the technical specifications, let's talk about the quadrilateral, which the contractor and the customer fall into when starting the project.
Requirements - the desired behavior of the system, as described by the customer or process holder, to be implemented. As a rule, requirements are formed on the basis of work experience, presentation of the correct behavior of the program. This is the key information for the developer (vendor), however, it is at the stage of collecting the requirements that the largest number of conflicts, errors, excessive requests and so on arise.
')
Resources - people, machines, inventory, development environment, time and money to be used in the process of implementing the requirements. Resources require precise planning and evaluation at the stage of approval of the technical task. Competent prioritization on the part of the customer and distribution of labor resources on the part of the vendor make it possible to avoid a deadline and minimize other risks.
Opportunities - in short, this is what a vendor (performer) can actually do. Consider the example of our RegionSoft CRM . The client buys the system and creates a technical assignment for revision: you need to create integration with the site and link events in CRM to the order number of the online store. This is a real-world requirement, we have the resource and the ability to do it. And still need to develop and tie to the CRM CMS, content management system site. Theoretically, we can do it, but we are not able to do it cheaply, and the client does not have the opportunity to pay us so much so that we can transfer human and time resources to the task. As a result, the customer refuses this requirement - and he doesn’t really need a CMS, everything is so good. But about the "greed" TK - later.
Restrictions - a set of obstacles that make the execution of tasks from TK difficult or impossible: budget, technology stack, licensing issues, legal prohibitions, hardware configurations, and so on.
Thus, all four entities are closely intertwined with each other and determine the success of the project as a whole. Consider each element and try to highlight the critical moments that need to be borne in mind when working on the terms of reference.
Collect and analyze requirements
This is a very important internal corporate process, during which it turns out what the program wants (hereinafter we take CRM, but the methods work with other types of software) potential users. If you contact a large vendor like SAP or a system integrator, then with a high degree of probability you will be offered to use the services of a business consultant (he is a personal manager, he is also an account manager, he is "now your representative in our company"). In fact, in most cases, this is an ordinary well-trained salesman who has two tasks: to wind up the cost of the project and not let you off the hook.
He has been here for an hour and has not even touched a white marker board. He is not a true systems analyst.
Better than you and your employees, nobody knows your company. So, the collection and analysis of requirements - only your task, in which the vendor can help and direct, but in no case intervene in the process. Ask the developer about such implementations, specify what to look for and proceed. By the way, a good assistant can be your employee, who is well versed in the profile topic and roughly represents the software architecture and is familiar with the development process - he can act as an analyst and internal expert, close the process of creating TK and communicating with the vendor.
There is a very simple pattern of collecting requirements.
- Create a working group of managers and experienced specialists in the departments that will use CRM. Tell us about the decision to be chosen, provide access to the demo version.
- Members of the working group should transmit information to employees and request their requests for a new program in a completely free form. If someone from the staff has never encountered such software and is not ready to talk in terms of future use, you should ask him to describe his periodic tasks, this is a universal approach.
- Then, each unit establishes what is not in CRM or what it does not correspond to, and aggregates the information.
- The working group analyzes the collected requirements, checks and eliminates intersections. For example, quite often the sales department and the marketing department order the same report, but the requirements may differ in the fields and entities, although the data behind them are the same. Accordingly, you need to come to a single form.
- The working group creates a list of requirements and prioritizes. At this stage, you can connect the vendor, since it is responsible for resources. For example, you can ask to create a custom report for RegionSoft CRM, or you can order integration with the site. These are completely different tasks in terms of time, priority is very important here.
Once the requirements are collected, analyzed and agreed with the staff and management, you can begin to create the terms of reference. You can ask the vendor for the form or compose it yourself - in any case, there are a few iron rules, the observance of which will relieve you and your CRM supplier from headaches.
Anatomy of a technical task
If we talk about the process of creating technical specifications, then there are several stages. Their successive passage leads the customer to the desired refinement. Here they are.
- Identification - identifying requirements, finding problems to solve.
- Analysis - analysis of requirements, the allocation of key needs, synthesis.
- Adaptation - assessment of requirements in the context of CRM capabilities and existing business processes.
- Documentation - a formal and detailed description of the requirements, coordination of TK.
- Communication with the vendor (developer) - an iterative interaction with the vendor about the improvements according to the compiled TK.
- Implementation - the work of the vendor to create the necessary functionality. It is better if the vendor is constantly in touch with the customer - so the output product will most closely match the customer's vision.
- Testing - testing the functionality of the vendor’s employees, internal experts of the client and end-users in order to determine the conformity of the revision and the terms of reference, the performance of the system with changes
In general, the technical task can be created on the basis of the requirements of several levels that can intersect and cooperate in creating a project or not interact at all.
The level of business is the most global level at which complex and priority tasks are solved. This level includes integration, refinement and modeling of business processes, the development of new functional modules. As a rule, this is a resource-intensive development, with serious advice and close collaboration with the customer. For example, in due time in RegionSoft CRM such warehouse customization was warehouse accounting, cash and production. Gradually, the changes entered into the release, and later allowed to create a new product for wholesale, retail stores and hypermarkets - RegionSoft Retail .
User level or user groups. At this level, tasks are completed to refine the existing interface. For example, a user may want a window with the number and status of the last order or a custom report with a special grouping of data to appear when the cursor is placed on the client. Improvements at this level take less time, but they can be many - for example, several requirements from the marketing, logistics and technical support department.
Level of functionality It is often difficult to separate it from the previous one; a formal criterion works here - refinement is not at the level of displaying something in the interface, but at the level of refinement of the system logic. These include requirements for various kinds of sorting, integration with chat, telephony capabilities.
The level of service - in fact, the requirements of this level should be the first to get into the new assembly with fixes. These are tasks related to system response speed, high load operation, and security. Ideally, the vendor should not have such improvements - corporate software should not slow down, lose data, collapse forms and distribute access rights of the same level. But if the requirement has appeared, and it is not connected with the personal paranoia of the customer or problems on the hardware side, it is worth paying special attention to it.
The level of technology is the last in the list, but ahead of the rest in importance and complexity. These may be customer requirements related to the platform, operating system, or devices. For example, build request for MacOS. It is great if such requirements gradually grow into releases, but it’s necessary to have their fixes. It was from customer requests at this level that we built RegionSoft CRM for MacOS and added remote access using TRM technology as a temporary solution to a rare but existing request for a mobile version.
Anatomy of a technical task is simple, at least in the form of a skeleton. Mandatory parts of the technical assignment help the customer to focus on the problem and formulate the task correctly, and the contractor to understand what they want from him. By the way, about understanding. Of course, at the beginning of the post, we were a little hilarious, denying business consultants as a class. The point is this: each vendor has been working on the market for several years (we are not about one-day CRM), or even decades, which means it has a set of cases for almost every industry. Accordingly, engineers, programmers, and salespeople are familiar with the specifics of implementation in each type of company. But again, it is important to focus on your business.
For whom? In this section, you need to describe who will be the end user of refinement, what tasks and how often it is planned to be solved.
I will give an example. In one company, CRM was implemented, it was supposed to work on a fairly large data array (several tens of millions of records per month, several hundred thousand records per day). The head of the sales department requested a report on the unloading of these records at intervals of "daily". Naturally, such a report while simultaneously operating hundreds of users loaded the system - solutions were found to optimize the process. Already in the course of work, it turned out that the sales clerk was reinsured and only needed the report for the end of the month, and then it can be run on a schedule at night. Needless to say, time and money were wasted.
What for? Justification of the need for improvement and its place in the business process. This item is more needed by the customer, but it is useful for the vendor to know what other processes will be affected. Sometimes it helps to find an alternative solution.
What should do? The most informative unit - it describes the requirements, expectations from the system. And it is here that the very pearls, miracles and collisions occur that fit to send to the tower, and which well complicate life very much. There is one reason - the user does not know what he wants, what needs to be done. There is also a small sub-reason - the user cannot formulate requirements. And here the task of the developer (working group, analyst, if any) is to help formulate the need correctly, choose the appropriate requirement, enter the task in the context of the system. In the same block it is necessary to mention the expected result.
The specifications of the technical task are the terms, stages of implementation, responsible from all parties, the necessary contacts and so on. In fact, it is a set of important formal things that make a document a technical task. The technical task must be agreed and signed by the parties in order to avoid numerous changes in the course of development (they will still be, but in a smaller volume).
Ideally, the terms of reference is drawn up with the active participation of the vendor, and its result is approximately the following structure:
- Description of the requirements of each mechanism and each functionality
- Description of the implementation of this functionality
- The cost of work on each of the stages separately
- The total cost of this technical task
- Terms of execution of works broken down by stages and indicating the order
- Description of installation and testing conditions
- Reservations on the exhaustive nature of the terms of reference and other conditions
10 rules written by developer tears
The technical assignment for revision should be the specification for revision , and not the 300-page description of CRM, which is necessary for the client. Before drawing up the requirements, you should carefully familiarize yourself with the system interface, its capabilities, documentation - most likely, the majority of the "helpers" are already in the basic package. The second step I would recommend is to pay attention to the built-in improvement tools (report designers, configurators, etc.) - perhaps the staff programmer can make the necessary changes (in many companies there are). The technical task should not be greedy. Often, a business overestimates its capabilities or wants to get “everything at once”. This approach is not justified either in terms of money or in terms of business. A vendor, as a rule, does not exist for a couple of weeks (in the case of RegionSoft - 15 years), and you can turn to it after some time, when you really understand what is missing in CRM.A vivid example of redundancy is literally from yesterday: a client bought an ERP from a well-known Russian company, thinking that once accounting works, then the ERP of this vendor will be good. ERP was not that not very by itself, but not very suitable business. But RegionSoft CRM with warehouse accounting and production is suitable. There is a solution: forget about ERP, cry, integrate 1C accounting with the new CRM and enjoy the convenient implementation. But the money pooled pity! And the client requires to integrate CRM with ERP. We did not do this, but why such a waste, why two relatively similar systems?
The terms of reference should be realistic and feasible - both in terms of requirements and in terms. Here it is important to listen to the vendor's opinion, since he knows exactly how long it will take for a particular task. Believe me, the developer is not profitable to take time and wind up the deadline - it is beneficial for him to complete as many projects as possible and do it well, so as not to get a blow to his reputation. As for realism, it is easy to avoid requests to finish CRM to the level of a collider control system: you should include in the requirements what you really need at the moment and in the foreseeable future.For example, RegionSoft CRM is a desktop program, we do not have a browser client. It makes no sense to ask us to create a web application for one company, this is a major development, it is underway and is not a possible refinement for one company. No, of course, everything has its price, but again - in the general case, the requirement is impracticable.
It should not be confused with the situation when it comes to custom development and the idea and logic of the application work is changing fundamentally; in fact, the creation of a new software is sponsored. But that's another story.
The technical task should be detailed. It is necessary to specify all significant details of the future project: from the frequency of using the program to the wishes of the interface. The more detailed the requirements, the easier and faster the implementation and testing will be. Particular attention should be paid to the details if you work in a specific industry (medicine, insurance, banks) - a detailed statement of the nuances of the interaction between business and the program will provide an understanding of the task of the vendor and a quick adaptation of the system to your company.Be sure to pay attention to the format of numbers, field names, the presence or absence of drop-down lists, the behavior of buttons and hints, data types. If the customer uses his own formulas that need to be put into the logic of the CRM operation ( for example, calculating dealer bonuses ), these formulas should be spelled out with a full transcript of their designations and calculation logic.
Yes, corporate software looks like this, and there are a lot of important details in it.
Terms of Reference should be unambiguous and accurate. Vague wording, implementation options, fuzzy requirements - all this is a way to a dead end. It happens that a client of good intentions writes several options for system behavior that are close, but not equivalent. In this case, he is sure that he helps, he tells the programmer, but in fact the developer has to understand what is needed, and he will choose how to do it himself, based on the system’s features and the stack of technologies used.This year you can make a wish again. Only, please do not waste it on the fact that even I can not fulfill, such as clear business requirements!
The technical task should be written in human language. And this is important, no, IMPORTANT. I will highlight two situations where language problems lead to a delay in project implementation.- The client is trying to demonstrate his technical literacy and makes constructions like: “implement the hint window in the calendar body with the ability to respond to the event call ...” instead of “a window should appear in the calendar in which the task can be marked as completed”. If you or your internal expert do not have the skills to write technical texts, do not google - write in ordinary words, we understand them.
- TK is full of grammatical errors. It is necessary not only to get rid of vague descriptions and metaphors ( from the real: “So that the computer doesn’t squeak, as if dying in convulsions” ), superfluous words, parasitic words. Check punctuation - often errors in it distort the meaning of the requirement. The project assignment is a document and the vocabulary in it should be appropriate, and literacy should be close to 100%.
And yet - do not use editors such as Microsoft Visio and UML diagrams, if you do not understand them. What seems beautiful and business-like, in the opinion of the developer, is hellish confusion. If you want to insert a diagram or a picture - draw it with human methods, do not bother yourself, it will not help us, the developers.
The technical task should not be a complaint book. It is necessary to solve the problem, and not to describe it, paying attention to the fonts and forgetting about the description of the requirements. The TOR must contain not only the problem itself, but also its solution at the level of comprehension - then the developer will already solve it at the code level. Compare “the sales department is not planning well, it is losing numbers, we have been fighting for a year now” and “it is necessary to create a report that will keep the values of the plan and the fact of sales every month, in the context of groups of nomenclature” . The technical task should be able to look to the future. Well, not quite it, but the people behind it. If it is known that soon there will be changes in business processes, this must be taken into account in order not to pay for the revision twice. The technical task should not be bureaucratic. If you have at least once drafted this document, you probably felt how difficult it was to avoid the temptation to slip into the bureaucracy, bloat the introductory words, strict turns and describe each clause as an article of the Criminal Code (preferably with punishment to all for violation). Bureaucratic wordings mask an incomplete understanding of the goals of creating TK. Responsibility vendor spelled out in the contract, there is written a budget. You should not transfer these points to the technical task. The terms of reference should be a technical assignment. It sounds paradoxical, but often, instead of TK, we read letters, complaints, contracts, re-written instructions for CRM or meeting minutes. Of course, it is impossible to work on such a document. In order not to get away from the form and content, use the old school trick: consider the term by words. Technical means that it dictates the refinement, the technique, is aimed at solving the problem by changing the software. That's about the task in the context of the software and need to talk. A task is a question, a problem, without advice, tips and preliminary assessments. Just a task statement.The commandments are over, now rebuke
In addition to these rules, there are a few things worth mentioning. We are talking about goals, plans and expectations - all those who leave who make the project successful, and the relationship between the vendor and the customer are almost friendly.
The technical task is necessary to write quickly , even if you are faced with the task of automating the processes of a cellular operator or a large hypermarket. This is due to the fact that technologies are developing at a tremendous speed, and even the system that you are implementing can survive a major release (and sometimes two) in six months or a year, and get new functionality. You may have to revise the need for improvements and start the process over.
Finally, he found the time to finish the TZ. But, alas, there are no developers left around to implement it.
The client does not know about the stack and technical limitations. And should not know - this is the task of the vendor, it is he who evaluates the work after drawing up the technical task. The customer should not delve into technology and ask each vendor whether the vendor can do this or that thing. Create a complex TOR and the developer will choose the appropriate architecture - often even better than you might think.
Estimate the budget and avoid unpleasant surprises - perhaps the number one joint task. You should not pull the vendor and require an approximate assessment of work from him (well, at least approximately, offhand, by eye, and like the others, well, in projects of this type, but from experience, well, so far, within the margin of error). A full budget assessment is possible only after reading, analyzing and final approval of the technical task. If your developer acts differently - get ready for the fact that the revision will cost at least two times more expensive.
Proceed from the objective need for changes and extensions - I wrote above that the developer does not disappear and is ready to make changes and additions to your requirements at any time. Therefore, don’t try to create a CRM / ERP dream right away, don’t ask the vendor for the “Everything works while I drink coffee” button - work in the system, define critical comments for you and start collecting requirements and drawing up the TOR.
You can write about technical tasks endlessly, this is a real generator of not only memes and fables, but also a headache. You can talk about priorities and design rules, about GOST 1989, which makes TK inhuman, IEEE standards, which are slightly better, about prototypes and TK that complement them. But in the end I would like to confine myself to one, the most important rule: the technical task is not a rule of law, not GOST and not a dogma, so if you can improve, improve, you can simplify, simplify, you can do it elegantly and make everyone like it. I am sure that no one after this will stick his nose in the TK and will not say that it is not written there. Or almost nobody.
Throughout December, we offer discounts on RegionSoft CRM and all our proprietary software. From December 1 to 15 - 15% and steep terms of installment and rental. We do not have -70% and -90%, because we keep the economically reasonable price for the license, and do not take it from the ceiling.
Well, if you need a CRM system (with or without refinement), then visit our website , there is a lot about CRM, its benefits and other corporate software.
And yes, we are always looking for partners who are ready to sell CRM and other products, refine and sell CRM, sell software and educate users. Income sharing is an honest and profitable partner. Show, tell, teach. Write to dealer@regionsoft.ru
Slides, slides. Comics are taken from http://www.modernanalyst.com/ and from Pinterest. If there is a better translation, we will be glad to add it to the post.
Source: https://habr.com/ru/post/306616/
All Articles