What should be the TK for Corporate IP?
Imagine that you have a corporate information system in the development of which 100 million rubles are invested annually. From the moment of introduction, the documentation on the system has evolved from one Technical Task for 600 pages to 300 Technical Tasks, each of which has an addition in the amount of from 1 to 10 pieces, and now it occupies 3 office cabinets and this is not the end ... Factory for the production Software regularly and rhythmically (at intervals of one month) releases a system update and documents changes.
The guys who developed the 34th GOST obviously did not expect that the case could take such a turn. And books on flexible development methodologies also do not give any recommendations on how to deal with this.
')
Everything that seemed to us not very important then, over time and on a scale, took on the form of a serious problem.
Terms of Reference for the EIS looked like systematized lists of requirements. Develop forms, create fields of a certain type, such a dimension and logic of formation ... An excellent document for a developer who quickly turns into a checklist of what needs to be done and checks what has been done.
This had one problem, if we compared the development of the KIS with the construction of a rocket, it looked like this, created the necessary details, and did not begin to assemble and attach them, as it was not said: a) what needs to be done, b) how need to collect.
When trying to launch such a rocket into space, it explodes, with the KIS the same:
“Customer: Guys, this is some kind of garbage, nothing works. Developers: We have everything according to the TZ . ”
The greater the scope of the KIS functional, the more analysts stuck in the details, and the more often they lost sight of the whole task.
Bottom line: The customer is unhappy and believes that we are bad Analysts ... and he is right.
The document is prepared for developers, and subscribed by the customer. All that it sets out "what fields to add, etc." does not interest him, he does not understand this and should not understand, he is interested in getting a working IT solution to his business problem. When the Customer signs the TK, he believes that he will receive the latter.
We have divided the TK template into two parts: the first for the Customer, the second for the Developers.
The first part of the TZ was developed by a Business Analyst with the Customer with the installation not to deny himself anything. At the exit of this flight of fancy, an ideal described and illustrated version of the Customer’s business transaction using an ICC. It consisted of a business scenario and system use scenarios (use cases).
Further, the dream of business descended on the mortal ground of opportunities of the KIS, where the System analyst, the Architect and the Main developer thought about how to make a fairy tale come true. From the horn, the second part of the TZ was born, which traced the business logic into the system requirements.
After the appearance of the second part and the confirmation by “Development” that everything will work as described in the first, the Customer signed the first part of the TZ and only it.
So, the answer was given to the question “How can we consider the underlying business logic behind the list of requirements to“ make, add ... ”?” .
Document number 1 (main TZ): Make the field number 1.
Document No. 2 (Supplement No. 1 to the TK): Make field No. 2.
Document No. 3 (Supplement No. 2 to the TZ): Make changes in field No. 1, make field No. 3.
Document â„–4 (Replaced RP in the direction, therefore, a new TK was created): Make changes in field No. 2 and field No. 3.
Document No. 5 (Supplement No. 1 to the new TZ): Make a change in field No. 3 and No. 1, make field No. 4.
Document No. 6 (New RP found the main TK, Addition No. 3 to the main TZ): Make a change in field No. 2 and field No. 4.
...
This is what a set of documentation on functionality represented. The new pattern of TK had all the chances to repeat the fate of its predecessor, choosing “rewrite the words in a song” as the solution. With each new change, the main TK corresponded.
Motive: we always have one actual document.
The problem was drawn. The customer began to be sad that, because of one new field, he had to re-read the entire document in order to put his signature on it. Imagine that one TZ on average is 40 pages, and a customer receives about 10 such documents per month (the same factory / rapid development ...).
They returned the additions to the TK and they began to indicate what we are changing to basically the TK or which new section we add to it. The customer agrees on an addition to the TK by 2-3 pages, and on its basis the main TK was updated. The output is the same single document that describes the current state of the IT solution.
An example of making changes to the main TK using the supplement
So we answered the second question “How among 20 found documents describing How did you modify the functionality for the last 5 years, understand its structure now?” .
To navigate through the terms of reference, we used the register of TZ, originally intended for reserving rooms for TK and indicating historical information:
They described the basic business process of the company (without fanaticism, large strokes) and inside, as necessary, detailed / divided the processes into procedures.
Each TK indicated:
5. in which business process the work is performed and
6. What procedure does it implement?
At the request of the business unit, determining which business process we will automate or refine, sorted the total pool and determined whether this new TK or addition to the existing one, what is already there and how it works.
Here is a solution for the last question “How to find in this volume of documents those that describe the work of a certain system functional?” .
One always up to date document. It is enough to read only it in order to understand how the business process is organized and its automation. To find the necessary TK in them there are tags in the form of the name of the KIS functional, business processes and procedures that it affects.
Share what TK you have, what tasks it has been set up for you and how it handles them.
UPD.
I recommend reading the comments on the article. Especially the comment branch habrahabr.ru/post/312538/#comment_9897642
It is well disclosed the first part of the article "Development of TK" (for corporate IP).
The guys who developed the 34th GOST obviously did not expect that the case could take such a turn. And books on flexible development methodologies also do not give any recommendations on how to deal with this.
')
Everything that seemed to us not very important then, over time and on a scale, took on the form of a serious problem.
- How to find in this volume of documents those that describe the work of a certain system functional?
- How out of 20 found documents describing How the functionality of the last 5 years was finalized, to understand its structure now?
- How can we consider the underlying business logic behind the list of “make, add ...” requirements?
Part number 1 "Development of TZ"
“Customer: Guys, this is some kind of garbage, nothing works.
Developers: We have done everything according to the TZ. "
Terms of Reference for the EIS looked like systematized lists of requirements. Develop forms, create fields of a certain type, such a dimension and logic of formation ... An excellent document for a developer who quickly turns into a checklist of what needs to be done and checks what has been done.
This had one problem, if we compared the development of the KIS with the construction of a rocket, it looked like this, created the necessary details, and did not begin to assemble and attach them, as it was not said: a) what needs to be done, b) how need to collect.
When trying to launch such a rocket into space, it explodes, with the KIS the same:
“Customer: Guys, this is some kind of garbage, nothing works. Developers: We have everything according to the TZ . ”
The greater the scope of the KIS functional, the more analysts stuck in the details, and the more often they lost sight of the whole task.
Bottom line: The customer is unhappy and believes that we are bad Analysts ... and he is right.
The document is prepared for developers, and subscribed by the customer. All that it sets out "what fields to add, etc." does not interest him, he does not understand this and should not understand, he is interested in getting a working IT solution to his business problem. When the Customer signs the TK, he believes that he will receive the latter.
I come to the director, I say:Arkady Raikin
- Who made the costume? Who did this? I will not do anything, I will not scream, I just want to look into his eyes.
It turns out a hundred people. I say:
- Guys, who sewed a suit?
They speak:
- We!
I say:
- Who are we"?
They speak:
- We have a narrow specialization. One sews a pocket, one - a scarlet, I personally sew buttons. Are there any complaints about buttons?
- Not! Stitched to death, not tear off! Who made the costume? Who instead of pants stitched my sleeves? Who, instead of sleeves, pinned my pants? Who did this?
They speak:
- Say thank you, that we have not sewn the sleeve to the codpiece.
Imagine? There are a hundred of them, and I am one. And all stand like buttons: to death. And I said:
- Hi guys! You are well settled!
We have divided the TK template into two parts: the first for the Customer, the second for the Developers.
The first part of the TZ was developed by a Business Analyst with the Customer with the installation not to deny himself anything. At the exit of this flight of fancy, an ideal described and illustrated version of the Customer’s business transaction using an ICC. It consisted of a business scenario and system use scenarios (use cases).
Further, the dream of business descended on the mortal ground of opportunities of the KIS, where the System analyst, the Architect and the Main developer thought about how to make a fairy tale come true. From the horn, the second part of the TZ was born, which traced the business logic into the system requirements.
After the appearance of the second part and the confirmation by “Development” that everything will work as described in the first, the Customer signed the first part of the TZ and only it.
Sample Business Scenario
Sample System Script
So, the answer was given to the question “How can we consider the underlying business logic behind the list of requirements to“ make, add ... ”?” .
Part number 2 "Amendments to the TK"
“Collect a general picture of the functional work from 20 documents (Puzzle 18+)”
Document number 1 (main TZ): Make the field number 1.
Document No. 2 (Supplement No. 1 to the TK): Make field No. 2.
Document No. 3 (Supplement No. 2 to the TZ): Make changes in field No. 1, make field No. 3.
Document â„–4 (Replaced RP in the direction, therefore, a new TK was created): Make changes in field No. 2 and field No. 3.
Document No. 5 (Supplement No. 1 to the new TZ): Make a change in field No. 3 and No. 1, make field No. 4.
Document No. 6 (New RP found the main TK, Addition No. 3 to the main TZ): Make a change in field No. 2 and field No. 4.
...
This is what a set of documentation on functionality represented. The new pattern of TK had all the chances to repeat the fate of its predecessor, choosing “rewrite the words in a song” as the solution. With each new change, the main TK corresponded.
Motive: we always have one actual document.
The problem was drawn. The customer began to be sad that, because of one new field, he had to re-read the entire document in order to put his signature on it. Imagine that one TZ on average is 40 pages, and a customer receives about 10 such documents per month (the same factory / rapid development ...).
They returned the additions to the TK and they began to indicate what we are changing to basically the TK or which new section we add to it. The customer agrees on an addition to the TK by 2-3 pages, and on its basis the main TK was updated. The output is the same single document that describes the current state of the IT solution.
An example of making changes to the main TK using the supplement
So we answered the second question “How among 20 found documents describing How did you modify the functionality for the last 5 years, understand its structure now?” .
Part number 3 "Navigating TZ"
To navigate through the terms of reference, we used the register of TZ, originally intended for reserving rooms for TK and indicating historical information:
- Divisions ordering the development
- The customer in the unit who formulated and set the task
- The project manager of our department who was responsible for implementing
- System analyst of a contractor who wrote TK for developers
They described the basic business process of the company (without fanaticism, large strokes) and inside, as necessary, detailed / divided the processes into procedures.
Each TK indicated:
5. in which business process the work is performed and
6. What procedure does it implement?
At the request of the business unit, determining which business process we will automate or refine, sorted the total pool and determined whether this new TK or addition to the existing one, what is already there and how it works.
Here is a solution for the last question “How to find in this volume of documents those that describe the work of a certain system functional?” .
What should be the technical assignment?
One always up to date document. It is enough to read only it in order to understand how the business process is organized and its automation. To find the necessary TK in them there are tags in the form of the name of the KIS functional, business processes and procedures that it affects.
Technical Reference Template
Share what TK you have, what tasks it has been set up for you and how it handles them.
What to read on the topic
- Use of use case scenarios in the development of TK
- What is Use Case and why are they needed?
- Alistair Cockburn's book "Writing Effective Use Cases" in Russian
- Technical task on the site
- Technical task on the site. Practice
- Description of the software development process in the company Nevlabs with an example of the TOR (posted on the company's website)
UPD.
I recommend reading the comments on the article. Especially the comment branch habrahabr.ru/post/312538/#comment_9897642
It is well disclosed the first part of the article "Development of TK" (for corporate IP).
Source: https://habr.com/ru/post/312538/
All Articles