📜 ⬆️ ⬇️

So what is the "Technical Assignment"?

This text was created purely for the sake of the existence of a permanent link that the author himself, and all of you could safely send to your future customers, colleagues, relatives and friends in the form of a standardized answer to the question: "Do I need your TK and in general that this?"

As the saying goes, “instead of a thousand words,” because every time evangelism for 4-5 hours on Skype on this topic becomes already tedious, and the global tendency to slip the definition of the “Technical Task” for frank nonsense over the years has only increased.

image
Problem

')
The fact is that when there is a specific format, as well as a clear and intelligible definition of a term, then all the manipulations and substitutions for its own briefs, prototypes, invented questionnaires, descriptions, and just incoming requests look at least unprofessional Therefore, we begin with the scientific definition of our concept:

Technical task - the source document for the design of a technical object (product). The technical assignment establishes the main purpose of the object being developed, its technical characteristics, quality indicators and technical and economic requirements, the prescription for completing the necessary stages of creating documentation (design, technological, software, etc.) and its composition, as well as special requirements. The terms of reference is a legal document - as an application is included in the contract between the customer and the contractor for the design work and is its basis: determines the order and conditions of work, including the goal, objectives, principles, expected results and deadlines. That is, there must be objective criteria by which it can be determined whether a particular item is made or not. All changes, additions and clarifications of the terms of reference of TZ are surely agreed with the customer and approved by him. This is also necessary because if in the process of solving a design problem, inaccuracies or inaccuracies in the source data are detected, it becomes necessary to determine the degree of guilt of each of the parties to the development, the distribution of losses incurred in connection with this. Terms of reference, as a term in the field of information technology - is a legally significant document containing comprehensive information necessary for the formulation of tasks for developers to develop, implement or integrate a software product, information system, website, portal or other IT service.


We translate into clear language


1) Technical Specification - it sets the task. So it should go before the prototype, the sketch, the test, the design project, because any mindmap, data flow diagram, architecture is already a task, this is the answer to the question. But before the question itself has not yet been asked, is not formulated, and is not signed by all parties - any answer will be a priori wrong, isn't it? So, the beginning of any work on any project is the formulation of the problem, and not a convulsive search for the sketches of a dozen options for its solution.

2) Actually from the first paragraph it follows logically and the new one - the text of the TK itself must begin with the chapter “Goals and Objectives”, which clearly articulates what business goals this entire next attempt to increase the entropy in the world pursues. The aimless task, which does not solve any problems, does not achieve anything and is done “out of boredom” - is not officially considered a Technical Task, and from this moment on it has been in the status of “ordinary piece of paper”.

3) How can you understand whether the proposed design concept or an interactive prototype, or even a ready-to-use website, solves the above business task? Nothing can be done, we will have to return to the definition: “determines ... the expected results and deadlines. That is, there must be objective criteria by which it can be determined whether a given item is made or not. ” That is, TK without clear measurable indicators in rubles, seconds, ton-kilometers or degrees Celsius - can not be. A brief can, or a prototype, or even any absurd piece of paper, but not a Technical Specification.

From here we conclude that in this TZ there must necessarily be a chapter “Procedure for Acceptance and Evaluation”, when these same indicators are taken, measured, and the parties either shake hands or send a draft for rework.

4) Technical Specifications must necessarily be consistent with the customer’s overall business plan, with its business development strategy and analysis of the market segment. All this will allow to set the right goals, to derive exact metrics, which then adequately carry out the acceptance of the finished information product. The absence of a business plan at the customer automatically guarantees non-professional performance of the Technical Specification.

Does a studio outsource business goals and measurable business performance better than its owner? Obviously, no, which means that the correct TZ should be written by the representatives of the Customer, and not by the hired employees of the Contractor. It is absurd when the performer sets the task for himself, then he thinks out for himself how to evaluate it, and in the end he sets himself the final mark for the work done. Ideally, there should be no such “initiative”, although in practice this is the case everywhere, as a result of which, the Technical Assignment does not provide the necessary assistance to the project, too often being a fictitious document. Do not do it this way.

5) Each amendment to the finished TK should cost money. It is impossible to edit the “Constitution of your project” free of charge and endlessly just because one of the parties changed its mind, did not sleep, suddenly decided to save, etc. The price of each change in the TOR should also be clearly written in advance in the relevant chapter.

By the way, in theory, exactly the same way every edit in design or making changes to the list of pages or functions should have a clear price, which is paid in advance, before making this change. Personally, I propose to evaluate any editing of an approved TK at 30% of the total project budget, but you can do otherwise.

Is it worth mentioning that in the TOR it is just necessary to specify in advance the terms and the total budget for development, as well as a list of all existing resources and limitations? - No, it will be too obvious.

So: What are we doing? For what? How do we understand what we did? How much does each pivot cost? - the answers to all these questions written on a piece of paper are the “silver bullet” capable of pulling out even the most disastrous project.

test questions

And here I will list the answers to the most frequently asked questions from customers:
image

1) So, can there be an official GOST for writing Technical Specifications? - Yes, even a few.

2) And what, in the Technical Specification does not include the description of the necessary pages, the number of buttons, used libraries, guidelines, etc.? - There is no TK itself, but you can put all this in the Appendices, of course, by adjusting all this with the goals described above, limitations and ways to further evaluate the achieved result. Post at least all future content, at least a description of typical characters - but not instead of a clear statement of the problem, but after it.

3) So maybe it is not necessary for me? “Perhaps today thousands of sites are being made without TK at all, just as thousands of people in the world live beautifully, being blind from birth.” But if you want to see where you are moving at all, consciously make decisions and independently evaluate the results, then TK is not enough.

4) So you and Wikipedia write that TK is created by the customer. But I don \ 't know how I \ have no time \ just don’t want to do it myself. How to be? - Give the development of TZ to a third party who is quite familiar with your business, its objectives, target audience and needs, and at the same time thoroughly aware of all stages of web development. This third party will become a kind of “web notary”, that is, a guarantee that the contractor does not underestimate the indicators you need or delay the deadlines, and that the customer will set attainable metrics and will not subjectively evaluate the created product on the final acceptance, changing the previously recorded requirements.

5) And what if the TK is a legal document, then I can sue the outsourcer, not pay him, make him redo everything for the tenth time? - If the document is drafted correctly, the objectives and methodology for assessing their achievement are indicated; if the document is signed by the parties and mentioned in the Agreement (the Technical Specification itself is not an agreement), then of course you can. But with the usual brief, prototypes, art-creative-mock-up, the Safe transaction on FL is no longer.

6) I am told that work will be carried out on some kind of scram or ajaila; so archaic TK is no longer necessary for me. This is true? - Judge for yourself: they call you an incomprehensible word, clearly something concealer, and now, on the basis of an unfamiliar term, they propose to abandon a document that is legally competent and filled with goals and metrics. Agile himself doesn’t set any goals like “reach at least 10,000 visits by the end of the year”, or “reach more than 25 orders from the site in a month” —it can’t be set, it’s just a way of holding meetings and a new organization of careless employees. Think about it a few times: “But do they throw dust in your eyes?”. In fact, professional TK cannot damage any new-fashioned scrum, but it is necessary to help.

Source: https://habr.com/ru/post/300420/


All Articles