(UPD. Transferred to HabraHumor. Gentlemen, do not take everything so seriously :-))
What should the customer do when he starts a new project with the development team and wants to keep a long and vivid memory? Following the simple advice of this article, you can cause the most violent emotions in a matter of weeks, even among complete strangers.
Send the requirements in the Excel file, and screenshots of the errors - in Word
')
The developer - the happy owner of a working computer of the 2005 sample - will get a lot of fun trying to open a megabyte file, digging up all one hundred sheets of requirements in search of two lines of changes and increasing the scale of the file being viewed to view a screenshot. It is also advisable to make screenshots as non-informative as possible so that your pleasant correspondence does not end longer. You can also creatively approach the description of the problem, shown in the screenshot: the phrase “Look, please!” Works best (do not forget to be deadly offended by the answer “We looked!”).
Be creative when designing tables
In each of us lives an artist. Therefore, if your correspondence with the developer contains tables - be sure to color them! The more colors - the better, and do not hesitate to radical color solutions such as black letters on a red background. In no case do not explain what color carries the information, and what is only intended to tell the world about the amazing shade of your dog. Fonts, strikethrough and bold italics, as well as the width of the document about two screen widths, will also deliver a lot of pleasant minutes to the person reading the document.
Change requirements at least twice a week
This keeps the developer in good shape. At the same time, the requirements should be as inconsistent as possible, rely on entities that are unknown to the developer (tables or algorithms) and allow the greatest possible number of different interpretations. Oh yeah, answer the coquettish questions to the clarifying questions “Is there anything unclear? We all wrote.
Assign daylight testing and product deployment.
After all, nothing will please developers, as the news that vacations from May to September inclusive are canceled. A demonstrative discussion of your vacation plans also helps - it’s not for you to work, it’s up to you to issue a guideline.
Require the presence of developers in your office
The stages of the coordination of technical tasks, testing and implementation - a golden time in this matter, but other stages of the project can show the principle. Remember: at least half of the development team should be present at the customer’s office every day (it’s better to fix this requirement in the service agreement). What nonsense - "we need to work"? You can work with us, and in our office it is much more convenient for us every five minutes to pull you with questions like “well, when will you finally finish it?”. And in general, the developer should be visible - we pay for it!
Never order a badge for the developer.
If a developer comes to your office, let him feel that he is an unwelcome guest here! A few calls and half an hour of waiting until the pass order passes through the security system will set up the developer in a creative way. Ideally, in the course of these half an hour, the lady issuing the passes should go for lunch or just like that, then there is an opportunity to mark the developer for another hour.
Never feed a developer
If you have achieved a mandatory daily presence of a developer in your office, it's time to build on your success. In no case do not offer him tea / coffee, not to mention the more substantial food. It is recommended to put the teapot in front of the developer’s nose and make tea at least twice
at one o'clock (for this purpose it is better to appoint several people drinking tea in shifts). For the final demoralization of the enemy, ugh, the developer should sit next to him and eat a big sandwich. With meat. By adding. Do not worry, a well-educated developer will not pounce on you and beat the keyboard on the head while pulling out a sandwich from your hands.
Careful observance of these rules ensures that your development team will remember you for many, many years to come. We are forced, unfortunately, to warn that the observance of these rules does not guarantee the timely and high-quality execution of work for which, in fact, you have hired a team. Well, you can not get everything at once.