Corporate trolling - 3, or delivery of work without unnecessary worries
In the previous articles ( first , second ), we walked fluently and in a playful way through examples of the opposition that the staff of the customer provide us at various stages of the project. Today, the subject of consideration will be the delivery of work, and we will come to this stage fully armed so that not a single troll will break through. It turned out a lot of letters, but I hope it is worth it.
Delivery of the results of work is one of the most dramatic stages of the project. Man-months spent on developing, debugging, testing and implementing your solution should not be wasted. If delivery of work is entrusted to you, then your role in the team is very significant, and the trust of the management is great, even if the supervisors have never said this to you. Screwing up on the delivery of work sometimes means the end of your brilliant career. So it is better not to do this.
The process of acceptance tests should be strictly formalized. Everyone understands that at the end of this process a protocol should appear and an act on the basis of which an order is issued to transfer the system to trial or commercial operation. The act is also a formal reason for invoicing the payment for the next stage of the project.
')
In this article, I am without unnecessary jokes (what a joke here!) And as consistently as possible (well, for a blog, of course) I will describe the process of putting the design work. Of course, many things to experienced colleagues will seem obvious. Let be. But less experienced colleagues or those who wish to try on the responsible role of the person who gives in on themselves will find this publication useful and informative.
You have no idea how many people are interested in your failure! Someone wants to prove his innocence about your mental abilities, someone wants to delay the deadlines, someone dreams of penalties, someone needs a new rubber on BMW ... In such cases, a troll-killer will be promoted to the commission (see the first post ). At this stage, there are three directions trolling, which have to deal:
And now we will consider what we need in order to avoid the described troubles during the delivery of works.
The MIP document, or the test program and methodology, in my opinion, is more important than even the TK. The quality of this document depends on half, if not two-thirds of the success of the test.
Requirements for the content of the document are described in section 2.14 of GOST RD 50-34.698-90 , also known as Desktop Recorder Standard. What this document should contain:
Based on the tests of the PMP, you must prepare a test report. The protocol will be a document confirming that your system is executed in accordance with the TK, about which a corresponding entry is made in the act. Do not trust the preparation of the protocol to anyone else, if you do not want to have a pale appearance before the commission. Typically, the protocol is a copy-paste from the PMI, so its preparation will not take you long.
The test report consists of a common part, a table of tests and a list of comments.
The table in which the test results are entered may consist of the following columns:
Without it, you can not. Only in this way can you catch all the roughness in the tests, identify tests, stealing time and tests, the results of which are dubious. Remember that the visual component must be flawless. Try to score in the system data that looks natural and similar to what the client is dealing with. Make sure that usernames and other fields do not contain profanity (a favorite joke of implementers and programmers). These "jokes" sometimes act on the commission as a red rag on a bull.
Do not be afraid to rewrite the PMI from scratch. Once we took the time and rebuilt the tests instead of rewriting them. As a result, we just reassured ourselves, without changing the overall pitiful picture. For that, and ogrebli.
If you take two, drive tests together. Invite colleagues, let them carp at pretending to be a commission. The time spent on these games will eventually allow all of you to get money from a satisfied customer.
The optimal team for delivery is a couple of implementer (or programmer) and a business analyst (consultant).
Implementer (programmer):
Analyst (consultant):
This team will allow you to implement a technique that can be called "microphone transmission". If a programmer suddenly stepped on a bug, the consultant can give him a smack and quickly sway the customer, indignant at someone's curved hands. The effect will be like a circus. The customer will laugh to himself and immediately think that he is not a clown and his hands will be straighter.
In the same way, if the consultant says something stupid, and the customer frowns in response, the programmer can, with an offended innocence face, demonstrate the next feature of the system and then the customer will feel sympathy for him, because he will understand who the real pro is and who the clown is in his tie.
In especially tense moments, you can make a friendly skirmish, thereby defusing the situation and diverting the attention of the audience from the not quite correct operation of the system.
No wonder Western “IT Evangelicals” like to work in pairs.
When you have started the test, do not dare to climb into the system immediately! Try to go through the entire formal part first. Check the codes of the documentation, media, open the TK, put the User Manual on the table. Walk through the non-functional requirements. Windows OS - tick. Supported browser versions - one, two, three, tick. Development language, architecture, database, and you never know what is written in the TZ! Everything needs to be shown in the documentation. At least there is just one sentence, it must be there! Do not neglect this bureaucracy, the trolls just waiting for this. You want to get in the protocol that “the Contractor has not demonstrated that the java language is a high-level cross-platform language. Requirements TK 1.2.3 and 3.2.1 are not met? But this is not invented insanity, it is life itself.
When you're done with the formal side of things, don't be in a hurry to get into the system! The next group of tests is to turn on the monitor and show the desktop, the icons and run the program (if the launch needs to be tested). Login to the system with the wrong password, check mark, login with correct one - again check mark, check mark, check mark. Menu - Eka Nevidal! The main form, a list of something. Check mark.
When it comes to pressing the buttons in the system, the commission will get tired and hungry. And on the first day you will be able to skip, for example, basic reference books and basic functions. And the next day, leave backup, administration, and even some nonsense.
They will, you can be sure. There is no system to which there would be no comments. Your task is to make the customer divide all comments into critical and non-critical. The first must be corrected for successful transfer to trial operation. The second can be corrected during trial operation. Accordingly, it is better that the first ones do not exist at all, or only those that are easy to fix.
When the customer makes a comment, you fix its wording in the protocol. Be sure to speak the words you recorded, make sure you understand each other. It will be better if during the tests the recorder will work. Try to make the wording of the comment be constructive, that is, it was clear what needs to be done so that the comment is removed. The words “all”, “nothing”, “each”, “any”, as well as immeasurable quality assessments “bad”, “slow”, “too fast”, etc. in the remark should not be! If "the system is slow", then the "requested form should be displayed within 5 seconds" should be written. If “the symbols on the diagram are poorly distinguishable,” then it should be written “to increase the symbols on the diagram to 18 points”. And so on.
Concretization will allow minimizing the possibility of unreasonable dragging of one or another comment to the critical rank. The customer may argue that processing the request in 6 seconds is unacceptable for him, and in 5 seconds - just right. Let it appear in the protocol! But something tells me that it will not appear. Or the remark will be recognized as noncritical.
All comments deemed critical are recorded in the act: “The Commission decided that the system complies with the TK and recommends its acceptance into trial operation under the conditions of working out the following remarks: ...” At the same time, it is better not to include a list of non-critical comments directly. There are usually a lot of them and they can scare the responsible officer who signs. If the customer is worried that you will not work out non-critical comments, calm him down with the help of the “Trial Operation Technique” document, which is strongly recommended to prepare. There, you should describe in simple and accessible form how the trial operation will take place, how the found bugs will be worked out and how the trial operation magazine will be filled in, which is the guarantor of painless termination of OE, putting the system into commercial operation and champagne salute due to the end of the project.
When you understand that the tests go unsatisfactorily, the system is ugly buggy, and the customer has already exhausted the stock of curses, no need to give up! The caravan should continue to go forward, there will be a new release, new trials. And even if the project is overwhelmed, there is nothing terrible for you. In the conditions of an acute shortage of intelligent performers, you will quickly find a job, especially since I would not work at your place in a company that allows such situations.
In order not to waste time in disembodied quarrels, I would recommend to use the tactic of "beat your own, so that others would be afraid." Start with the customer to scold "these Krivorukov programmers", "greedy guide", and when the intensity of emotions decreases, ask the customer to collect a maximum of the bugs of "this bug" to show these bad people what they are.
Then the active employees of the customer led by the troll-killer will begin to collect bugs and happily fill the protocol with hundreds of comments. In fact, for their own money, they will conduct you high-level functional testing, which, judging by the test results, your developers have not been honored.
For good, described ugly situation should not be at all. But the project business sometimes differs by strange fluctuations, when the first prototype is tried to be handed over as a full-fledged system, the administration lies to the subordinates and to itself, everyone around them is doing a good face on a bad game and assure each other of mandatory and indispensable success.
The second advice in such a situation would be, as I said, to immediately resign from an office that allows such “jambs”. Because by all standards, a true professional should not spoil his reputation in this way.
So, colleagues, I’m in a hurry to complete the trilogy about corporate trolls, which you don’t need to fear, but respect and even in some way love, as they don’t let lazy monkeys in IT business fall from overeating from trees, keep us in good shape and even bring some interest in insanely boring, but much-needed design work.
UPD from 06/23/2011 . The user igendo adds in the comments that it would be nice to approve the forms of official project documents at the stage of concluding an agreement.
I quote:
I will add that it helps a lot when the forms of acts, protocols and other formal documents are fixed in the contract. So that there is no need to pre-coordinate them, renegotiate and redo \ re-sign in the middle of the project.
From myself, I can also add that in very very heavy and large-scale projects it is customary to draw up a project charter, a document about the deeper meaning of which you can talk for hours. There, among other things, you can discuss the forms of project documents, and procedures for monitoring the progress of the project, and high-level business problems. But this, again, is a topic for another post.
User LJ ryzhij_papa Adds that there is a practice of ranking comments on the degree of their influence on the business, the ranking method is also entered in the PMI.
I quote:
It is necessary to formally describe what is the comments of a critical, high, medium and low priority. The description is done in terms of business. If we exaggerate, then this is so: a critical priority in the loss of $ 1000, high if $ 100, medium when the staff is in soap, but we don’t have losses, low - there may be cases of slight insanity at 5-6 years of life with such a bug ...
Delivery of the results of work is one of the most dramatic stages of the project. Man-months spent on developing, debugging, testing and implementing your solution should not be wasted. If delivery of work is entrusted to you, then your role in the team is very significant, and the trust of the management is great, even if the supervisors have never said this to you. Screwing up on the delivery of work sometimes means the end of your brilliant career. So it is better not to do this.
The process of acceptance tests should be strictly formalized. Everyone understands that at the end of this process a protocol should appear and an act on the basis of which an order is issued to transfer the system to trial or commercial operation. The act is also a formal reason for invoicing the payment for the next stage of the project.
')
In this article, I am without unnecessary jokes (what a joke here!) And as consistently as possible (well, for a blog, of course) I will describe the process of putting the design work. Of course, many things to experienced colleagues will seem obvious. Let be. But less experienced colleagues or those who wish to try on the responsible role of the person who gives in on themselves will find this publication useful and informative.
Trolling directions during testing
You have no idea how many people are interested in your failure! Someone wants to prove his innocence about your mental abilities, someone wants to delay the deadlines, someone dreams of penalties, someone needs a new rubber on BMW ... In such cases, a troll-killer will be promoted to the commission (see the first post ). At this stage, there are three directions trolling, which have to deal:
- Formal acceptance. The troll pokes in the TZ, where it says something like this: "the system must have a client-server architecture." You need to show how the item closes. Did you forget to include the line “The system has a client-server architecture” in the explanatory note to the technical project or, with a fright, could not find it. Spend time, comb through all sections of TZ and find the necessary lines.
- Errors in the tests. When formulating tests, avoid the possibility of intentional misinterpretation. For example, you write, "The operator selects any user from the list of users." The troll will select from the list of the system user or admin, under which the tests will not work. Or you write "Properties of all objects displayed." The troll pokes into the object whose properties are not displayed. And you meant "all the required objects", but the train left, and you get a terrible remark "The properties of all objects are not displayed."
- "Extremely Important Notes." When the guns of the main battle died down, the analysis of comments on critical and non-critical begins. Critical will you have a bone in the throat, they interfere with the signing of the act. Therefore, the troll will try to make every remark critical. All the existing pathos is included, authoritative comrades nodding their heads, and other circus with horses are attracted.
And now we will consider what we need in order to avoid the described troubles during the delivery of works.
Program and test methods
The MIP document, or the test program and methodology, in my opinion, is more important than even the TK. The quality of this document depends on half, if not two-thirds of the success of the test.
Requirements for the content of the document are described in section 2.14 of GOST RD 50-34.698-90 , also known as Desktop Recorder Standard. What this document should contain:
- Full formal part in accordance with GOST (object and purpose of tests, volumes and test conditions, etc.). As a result, after reading these sections, any member of the commission, even if he has not participated in the project so far, must understand what his personal role is in all of this.
- Checking the completeness of everything and everything - documentation, disks, the number of copies transmitted, etc. Accordingly, all of this must be physically present for testing. The goal is to close the formal requirements of the TZ and the contract in terms of delivery.
- A description of exactly how tests are performed. Will you feed real data from physical sensors to the system or will you slip test files or an emulator? The system will manage the real object or just look at the logs, where is it written that she did this and that? Does the user have to sit solemnly in the control room, or can one be limited to a laptop in the office?
- High-level system tests. Detail may be different, depending on the customer. There are common tests, and tests with step by step instructions. The purpose of tests is simple: when the last test is passed, you must close all the functional requirements of the TOR, and also note the fact that the operational documents contain the required information (that is, they are fit for work).
- Test script Tests should be in the order you need to minimize test times and unnecessary questions. For example, if you check the reception, transfer and dismissal of an employee in the personnel program, then let the script be just that - you take someone to work, then you transfer him, then you fire him, so that you have to start a new employee each time and spend for this time. Or another example. In one of the tests, you should check the backup and restore system. If the tests go several days in a row, it would be wiser to schedule a backup test at the end of the first day. Then would not have to wait until the end of a long procedure. A recovery can be scheduled for the penultimate day. Before recovery, you can do cruel tests, such as emergency shutdown emulation, loss of logs and critical files (if you need to experience it, of course). Now this seems obvious, but read the real documents to make sure that this is obviously not for everyone!
Test report
Based on the tests of the PMP, you must prepare a test report. The protocol will be a document confirming that your system is executed in accordance with the TK, about which a corresponding entry is made in the act. Do not trust the preparation of the protocol to anyone else, if you do not want to have a pale appearance before the commission. Typically, the protocol is a copy-paste from the PMI, so its preparation will not take you long.
The test report consists of a common part, a table of tests and a list of comments.
The table in which the test results are entered may consist of the following columns:
- Through number (in a format convenient to you). For example, Test_Number. Step Number.
- Operator actions. What the operator does in order to get the result. Ensure that the wording excludes a malicious misinterpretation.
- Expected Result. In simple words, the described result of the operator's actions that can be checked (touch, see, smell). For example: "The green light on the top panel was lit", "A new user appeared in the list of users", "A warning about incorrectly entered password was displayed on the screen", "A Y entry appeared in the X system log". Ensure that the wording is as specific as possible and excludes malicious misinterpretation. Remember also about the words that are the food base for trolls: "any", "each", "all", "no", etc.
- A documentation item (for example, User Manual), which gives a detailed description of the actions performed or closes the non-functional TK requirement. The presence of this item will kill two birds with one stone. First, you will document that everything you need is reflected in the project documentation. Secondly, you do not have to describe in detail the operator’s actions, since (attention!) Employees who meet the technical design requirements are admitted to the tests, in which you wrote that they should take such courses and be familiar with the operational documents.
- Item or points TK, closed at this step. The sum of the column should give all (just everything, not just functional!) TK requirements. That is why the protocol will contain “stupid tests” to check the completeness of the documentation, that the program is written in java and the Oracle DBMS database is relational (we poke our finger in the appropriate section of the documentation).
- Commission decision. It is necessary to insist on the following decisions: “Passed”, “Passed with remarks”, “Not passed”, “Not tested”. There should be no other entries. The entry “Not tested” is made for tests that the commission did not want to conduct or it is physically impossible to conduct them at the time of the tests. For example, they decided not to pull out the cluster node from the outlet. It is better that there are no such records in the protocol, so that there is no unnecessary opportunity for trolling.
- Comments If the test is passed with comments, there should be a number of notes. All comments are recorded in the annex to the protocol in free form. You can specify the number of the test, during which there were comments. For more you just do not have enough time. If the decision of the commission "passed", try not to write anything in the column "Comments"
dress rehearsal
Without it, you can not. Only in this way can you catch all the roughness in the tests, identify tests, stealing time and tests, the results of which are dubious. Remember that the visual component must be flawless. Try to score in the system data that looks natural and similar to what the client is dealing with. Make sure that usernames and other fields do not contain profanity (a favorite joke of implementers and programmers). These "jokes" sometimes act on the commission as a red rag on a bull.
Do not be afraid to rewrite the PMI from scratch. Once we took the time and rebuilt the tests instead of rewriting them. As a result, we just reassured ourselves, without changing the overall pitiful picture. For that, and ogrebli.
If you take two, drive tests together. Invite colleagues, let them carp at pretending to be a commission. The time spent on these games will eventually allow all of you to get money from a satisfied customer.
Effective duet
The optimal team for delivery is a couple of implementer (or programmer) and a business analyst (consultant).
Implementer (programmer):
- works with the system, demonstrating masterly mastery of the interface
- answers technical questions
Analyst (consultant):
- talking about the system with the customer, talking
- answers common questions
- keeps a record
- kicks the implementer (programmer) under the table
This team will allow you to implement a technique that can be called "microphone transmission". If a programmer suddenly stepped on a bug, the consultant can give him a smack and quickly sway the customer, indignant at someone's curved hands. The effect will be like a circus. The customer will laugh to himself and immediately think that he is not a clown and his hands will be straighter.
In the same way, if the consultant says something stupid, and the customer frowns in response, the programmer can, with an offended innocence face, demonstrate the next feature of the system and then the customer will feel sympathy for him, because he will understand who the real pro is and who the clown is in his tie.
In especially tense moments, you can make a friendly skirmish, thereby defusing the situation and diverting the attention of the audience from the not quite correct operation of the system.
No wonder Western “IT Evangelicals” like to work in pairs.
The process has begun!
When you have started the test, do not dare to climb into the system immediately! Try to go through the entire formal part first. Check the codes of the documentation, media, open the TK, put the User Manual on the table. Walk through the non-functional requirements. Windows OS - tick. Supported browser versions - one, two, three, tick. Development language, architecture, database, and you never know what is written in the TZ! Everything needs to be shown in the documentation. At least there is just one sentence, it must be there! Do not neglect this bureaucracy, the trolls just waiting for this. You want to get in the protocol that “the Contractor has not demonstrated that the java language is a high-level cross-platform language. Requirements TK 1.2.3 and 3.2.1 are not met? But this is not invented insanity, it is life itself.
When you're done with the formal side of things, don't be in a hurry to get into the system! The next group of tests is to turn on the monitor and show the desktop, the icons and run the program (if the launch needs to be tested). Login to the system with the wrong password, check mark, login with correct one - again check mark, check mark, check mark. Menu - Eka Nevidal! The main form, a list of something. Check mark.
When it comes to pressing the buttons in the system, the commission will get tired and hungry. And on the first day you will be able to skip, for example, basic reference books and basic functions. And the next day, leave backup, administration, and even some nonsense.
Remarks
They will, you can be sure. There is no system to which there would be no comments. Your task is to make the customer divide all comments into critical and non-critical. The first must be corrected for successful transfer to trial operation. The second can be corrected during trial operation. Accordingly, it is better that the first ones do not exist at all, or only those that are easy to fix.
When the customer makes a comment, you fix its wording in the protocol. Be sure to speak the words you recorded, make sure you understand each other. It will be better if during the tests the recorder will work. Try to make the wording of the comment be constructive, that is, it was clear what needs to be done so that the comment is removed. The words “all”, “nothing”, “each”, “any”, as well as immeasurable quality assessments “bad”, “slow”, “too fast”, etc. in the remark should not be! If "the system is slow", then the "requested form should be displayed within 5 seconds" should be written. If “the symbols on the diagram are poorly distinguishable,” then it should be written “to increase the symbols on the diagram to 18 points”. And so on.
Concretization will allow minimizing the possibility of unreasonable dragging of one or another comment to the critical rank. The customer may argue that processing the request in 6 seconds is unacceptable for him, and in 5 seconds - just right. Let it appear in the protocol! But something tells me that it will not appear. Or the remark will be recognized as noncritical.
All comments deemed critical are recorded in the act: “The Commission decided that the system complies with the TK and recommends its acceptance into trial operation under the conditions of working out the following remarks: ...” At the same time, it is better not to include a list of non-critical comments directly. There are usually a lot of them and they can scare the responsible officer who signs. If the customer is worried that you will not work out non-critical comments, calm him down with the help of the “Trial Operation Technique” document, which is strongly recommended to prepare. There, you should describe in simple and accessible form how the trial operation will take place, how the found bugs will be worked out and how the trial operation magazine will be filled in, which is the guarantor of painless termination of OE, putting the system into commercial operation and champagne salute due to the end of the project.
What to do if all is lost
When you understand that the tests go unsatisfactorily, the system is ugly buggy, and the customer has already exhausted the stock of curses, no need to give up! The caravan should continue to go forward, there will be a new release, new trials. And even if the project is overwhelmed, there is nothing terrible for you. In the conditions of an acute shortage of intelligent performers, you will quickly find a job, especially since I would not work at your place in a company that allows such situations.
In order not to waste time in disembodied quarrels, I would recommend to use the tactic of "beat your own, so that others would be afraid." Start with the customer to scold "these Krivorukov programmers", "greedy guide", and when the intensity of emotions decreases, ask the customer to collect a maximum of the bugs of "this bug" to show these bad people what they are.
Then the active employees of the customer led by the troll-killer will begin to collect bugs and happily fill the protocol with hundreds of comments. In fact, for their own money, they will conduct you high-level functional testing, which, judging by the test results, your developers have not been honored.
For good, described ugly situation should not be at all. But the project business sometimes differs by strange fluctuations, when the first prototype is tried to be handed over as a full-fledged system, the administration lies to the subordinates and to itself, everyone around them is doing a good face on a bad game and assure each other of mandatory and indispensable success.
The second advice in such a situation would be, as I said, to immediately resign from an office that allows such “jambs”. Because by all standards, a true professional should not spoil his reputation in this way.
Conclusion
So, colleagues, I’m in a hurry to complete the trilogy about corporate trolls, which you don’t need to fear, but respect and even in some way love, as they don’t let lazy monkeys in IT business fall from overeating from trees, keep us in good shape and even bring some interest in insanely boring, but much-needed design work.
UPD from 06/23/2011 . The user igendo adds in the comments that it would be nice to approve the forms of official project documents at the stage of concluding an agreement.
I quote:
I will add that it helps a lot when the forms of acts, protocols and other formal documents are fixed in the contract. So that there is no need to pre-coordinate them, renegotiate and redo \ re-sign in the middle of the project.
From myself, I can also add that in very very heavy and large-scale projects it is customary to draw up a project charter, a document about the deeper meaning of which you can talk for hours. There, among other things, you can discuss the forms of project documents, and procedures for monitoring the progress of the project, and high-level business problems. But this, again, is a topic for another post.
User LJ ryzhij_papa Adds that there is a practice of ranking comments on the degree of their influence on the business, the ranking method is also entered in the PMI.
I quote:
It is necessary to formally describe what is the comments of a critical, high, medium and low priority. The description is done in terms of business. If we exaggerate, then this is so: a critical priority in the loss of $ 1000, high if $ 100, medium when the staff is in soap, but we don’t have losses, low - there may be cases of slight insanity at 5-6 years of life with such a bug ...
Source: https://habr.com/ru/post/122237/
All Articles