There are many ways to screw up a development project. Developer Anders Abel has put together anecdotes of the disruptors he's experienced on projects into a manual you can use if you want to screw up some software projects your company is doing. (Project managers don't have to worry, I'll write a follow-up article on how to deal with these tactics. Update: Countering "Project Sabotage" handbook )
The key to successfully sabotaging a project is to start with what is most important to the project, divert the developer's attention from the most important work, and drain the developer's energy. Use your imagination and creativity and don't miss any opportunity to pull the project to the brink of failure step by step.
The following introduces some major strategies, which must be carefully understood and studied.
1. Focus on fringe issues to prove you are knowledgeable
In a project, there are several key factors that make the project successful, and they have the highest priority. Followed by some important issues and some related issues. Most projects don't have enough time to address all priorities.
As a "knowledgeable" saboteur, you should focus on the most fringe issues that others often don't pay attention to - the most fringe issues, but at the same time don't ignore some of the issues related to these fringe issues, for example, you can ask other developers:
- Can you guarantee that there are no compatibility issues? Microsoft just released an OS patch KB12345. (It takes a lot of time to understand the impact of system patches on software, and it takes even more time to produce evidence)
- What happens if the user enters a number in the last name field?
- What changes do we need to make when the next generation of IE, Windows... is released?
Such questions are quite effective and can easily divert the attention of other developers. This requires a certain level of saboteur to ask questions that are difficult for technical experts to answer, and the best way is not to ask technically in-depth questions, but to ask questions that do not have suitable answers, so that they are not easily dismissed.
2. Ask questions for which you don't understand the answer, and insist on getting it.
For example, a question has an answer, but you can't understand it because you lack the necessary knowledge. For example, how HTTPS session security is achieved (the algorithm is famous). Encryption algorithms in terms of mathematics are quite complicated. Just mention the mathematical principles of the algorithm and ask some simple non-mathematical questions, which may drive the person you ask crazy.
3. Rejecting documents or meeting minutes
Documentation is your number one target for destruction, write as little documentation as possible. A record of a formal meeting a few months ago has the potential to stifle a lot of creativity. Avoid documentation as much as possible, and distort the facts and put the blame on others. The best way to prevent high-quality meeting minutes from being produced is to mostly ask for meeting minutes and then ignore some aspects (see below for how to ignore them).
4. Avoid clear decisions
A clear decision can create a lot of resistance to spoilers. The best way is when someone clearly says what to do and you start a vague discussion. Without a clear decision, developer productivity will plummet.
5. Ignore the tasks assigned to you The
best saboteurs should ignore all assigned tasks, as well as any related problems. If tasks are assigned without any documentation, then there's a good chance that, for example, you can say you've never heard of them.
6. Focus on other people's shortcomings
If your behavior above is found, you will have a hard time in the project. At this point, you need to defend, and the best way to do that is to focus on one of the other's small flaws. No downsides? Impossible, you will always find some. The fewer flaws a person has, the greater his perfectionism complex, and the more miserable he will be if you point out his flaws. Well, the focus of the problem will quickly shift away from you.
7. Meetings without an agenda or structure The
key to a productive meeting is to have structured discussions around an agenda. What you need to do is avoid the agenda. If a discussion is drawing to a close, it usually means a decision is imminent, in which case you should move the discussion quickly and avoid making a clear decision. Then, repeating the same trick in every meeting can be deadly on projects where time is precious.
8. Draining energy
Remember that the most critical factor in successfully sabotaging a project is diverting the developer's attention and draining the developer's energy at the most important points of the project. You can do these things in various ways.
Regardless, it's a tough fight! "Salute" to you!