There is an analyst in the organization. He agrees to draw up a document describing the requirements of the customer. But he does not want to write TZ for a programmer .

Requirements for the TOR - make a table where the types of fields, the input format, the visibility at the stages, the texts of the notifications and the logic for changing data on some events will be described. The analyst is well aware of the capabilities of the system (talking about SharePoint).

The analyst reports that the programmer should compile the TOR. I am this programmer . And I think something went wrong.

  • one
    what is written in your job descriptions is what you must do - Konst
  • I understand that Business Analyst collects requirements, and System Analyst adapts them for technical staff. Is it true to give the role of System Analytics software developer? The organization, by the way, is not small. Those. not a web studio of 5 people, where the combination of roles is inevitable. - Alexander Ulmaskulov
  • It happens and the programmer delegates such an honorable duty. can just talk to PM? - Konst
  • Just add, we are talking about the development within the company, within a single legal entity. - Alexander Ulmaskulov
  • one
    @Alexander Ulmaskulov Obviously, no one at work does not draw up technical tasks for himself. The technical task is what should be provided to the programmer. - Vlad from Moscow

3 answers 3

TZ - it stands for technical task . That is, this task is from one subject to another, from the head to the slave, from the customer to the performer, etc. A programmer is a link in the production process that must receive a task before doing something. If a programmer writes himself tasks, then 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 is not authorized to issue technical tasks, but, let's say, another authorized employee does it.

A description of customer requirements is the job of a secretary, not an analyst.

For an analyst, the customer’s requirements are just input data , on the basis of which he has to give the output data , which are the terms of reference. Roughly speaking, the work of the analyst is as follows. He must indicate: this is what the customer requires, and this is what needs to be done.

And for the programmer, the TOR is the input , and the program is the output .

Otherwise, the programmer will have to duplicate the analyst. Why then such an analyst is needed?

In fact, in this case, the analyst disclaims all responsibility for his work, because if the end product does not suit the customer, the analyst will simply say that you wrote the wrong TK. That is, he completely cut off the feedback with you, and thus, climbing up the chain from you to the customer, in order to evaluate the result of the work and, for example, assess what was done wrongly, as expected, and at what stage, in this process the analyst will no longer share the responsibility. :)

How does the verification process work?

If tasks go from top to bottom, then the verification of the result is made from bottom to top.

The result of the programmer is a program. Its correctness is verified with the technical task.

The result of the analyst's work is a technical task. Its correctness is verified with the requirements of the customer.

Well, if the customer's requirements are not in themselves correct or inadequate, then the customer will not have to blame anyone except himself. :)

    And sometimes it is useful for yourself sometimes to ask the question - "WHY?". And these are enough here.

    For example, "Why should I resist drawing up TZ ...", because I want to get this experience and move towards the analyst / architect, then gently rub the current analyst aside, build direct communication with the customer, do everything in the best way and do not forget from time to time to highlight their new role before the leadership.

    Or, for example, why does a company need such an analyst, then also do everything without him, and then put the question "Why do we need such an analyst ..." an edge to the boss.

    Or - "Why do I need all this ...", because you are not paid for it and it is better then to do nothing. Then, most likely, it's time for you to look for a new job. Well, there are a couple of dozen different why in this generally typical situation.

    • 3
      In almost every situation, “what and why am I doing?” Is a good question. ) - Nick Volynkin ♦
    • I believe that a programmer should do his job — write code. Pay for it. If a developer is writing a technical assignment, then this is already a blurring of roles. Again, there is an analyst in the organization. - Alexander Ulmaskulov September

    As far as I know, this is usually done like this:

    1. The (business) analyst collects customer requirements.
    2. The (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 is working on Scrum, user-story.
    3. The system analyst or technical engineer writes the technical specification. It describes how everything should be implemented inside. Architecture, technology, coding style, tools used.
    4. According to the technical specifications, programmers, testers, system administrators, database administrators and other technical fraternity work.

    In general, the writing of technical documentation may or may not be your responsibility. Usually, the higher the position, the more often you still have to document something. If you want to refuse, you can argue your position by the fact that you do not have the proper qualifications and cannot guarantee the quality of the product.

    If you still have to write documentation, then it can only be technical. Make sure that the functional specification is, that it is complete, unambiguous, consistent. If you find any inaccuracies go to the analyst and check in advance. Inaccuracies are a specification bug.

    Determine who is the customer of the documentation, i.e. a person who assesses her readiness and accepts work. Most likely, it will be your analyst. Verify the document with him until he says that everything suits him. Then let him sign that document accepted. Be sure to connect to the process tester who will work with you on this project.