Who makes the TOR?
The organization has a analyst. He agrees to draw up a document describing the requirements from the customer. But he doesn't want to write the TOR for the programmer.
The requirements for the TOR are to create a table that describes the types of fields, the input format, visibility at stages, notification texts, and the logic of changing data for some events. The analyst is well aware of the system's capabilities (we are talking about SharePoint).
The analyst reports that the programmer must compose the TOR. I am this programmer. And I think something went wrong.
3 answers
TZ-this stands for technical task. That is, this task is from one subject to another, from the boss to the subordinate, from the customer to the performer, etc. A programmer is a link in the production process that must receive a task before doing anything. If a programmer writes tasks for himself, this means that he is excluded from the production process, that is, he is not a participant in the production process, but is an independent unit external to the production process.
The task of the analyst is to analyze the production process and, based on his analysis, issue technical tasks or recommendations, if he himself is not authorized to issue technical tasks, but, for example, another authorized employee does it.
The description of the requirements from the customer is the work of the secretary, not the analyst.
For the analyst, the customer's requirements are just input data, based on which it should output output data, which are technical tasks. Roughly speaking, the work of an analyst is as follows. He should indicate: this is what the customer requires, and this is what needs to be done.
And for the programmer, TK is the input data, and the program is the output data.
Otherwise, the programmer will have to duplicate the analyst. And then why do you need such an analyst?!
In fact, in this case, the analyst removes from take all responsibility for your work, because if the final product does not suit the customer, the analyst will simply say that you wrote the wrong TOR. That is, he completely cut off the feedback with you and thus, rising up the chain from you to the customer to evaluate the result of the work and, for example, to assess what was done wrong, and at what stage, the analyst will no longer participate in this process of allocating responsibility.:)
As is the process of verifying the result of the work going on?
If the tasks go down from the top to the bottom, then the result is verified from the bottom to the top.
The result of the programmer's work is a program. Its correctness is checked with the technical task.
The result of the analyst's work is a technical task. Its correctness is checked against the customer's requirements.
Well, if the customer's requirements themselves are not correct or inadequate, then the customer has no one but himself you don't have to blame me.:)
And it is also useful sometimes to ask yourself the question - " WHY?". And these reasons are enough here.
For example, "Why should I resist drawing up the TOR..." - because I want to get this experience and move towards the analyst/architect, then gently rubbing the current analyst aside, build direct communication with the customer, do everything in the best way and do not forget to periodically cover your new role in front of management.
Or for example, why would a company need such an analyst, then also do everything without it, and then put the question "Why do we need such an analyst..." with an edge in front of the boss.
Or - "Why do I need all this..." - because you don't get paid for it and it's better not to do anything then. Then, most likely, it's time for you to look for a new job. Well, there are a couple of dozen different reasons for this, generally typical, situation.
As far as I know, it is usually done like this:
- The (Business) analyst collects requirements from the customer.
- A (Business) analyst writes a functional specification for the team. It describes how everything should work from the user's point of view - that is, a list of features. The functional specification can be in the format of use-cases or, if the team works on Scrum, user-story.
- A system analyst or techleader writes a technical specification. It describes how everything should be be implemented internally. Architecture, technologies, coding style, tools used.
- According to the technical specification, programmers, testers, system administrators, database administrators, and other technical fraternity work.
In general, writing technical documentation may or may not be part of your responsibilities. Usually, the higher the position, the more often you still have to document something. If you want to refuse, then you can argue your own the position is that you do not have the proper qualifications and cannot guarantee the quality of the product.
If you still have to write documentation, it can only be technical. Make sure that the functional specification is there, that it is complete, unambiguous, consistent. If you find any inaccuracies, go to the analyst and check in advance. Inaccuracies are a bug in the specification.
Determine who is the customer of the documentation, i.e. the person who evaluates its readiness and accepts the job. Most likely, it will be your analyst. Check the document with him until he says that he is satisfied with everything. Then let him sign that the document was accepted. Be sure to connect the tester who will work with you on this project to the process.