The success of a software project can be judged by two characteristics: a) quality; b) delivery time. If one of these characteristics is unsatisfactory, several interesting questions arise:
- How conscientiously does the developer perform their duties?
- How competent is the developer?
If a project manager doesn’t have a technical background, it’s very easy to end up in a situation where you’re sort of no longer a project manager, but a rack for the developer to hang noodles on your ears.
I propose a relatively simple method for getting answers to these questions: ask the programmer to document the project’s current technical debt. One workday should be allocated for this. Why that much time? That much time is needed for two things: a) to make it clear that the task is serious; b) enough time to go over the whole project once more and describe everything in detail.
As a result, there may be several situations.
A good scenario is when the developer is simply bursting with ideas about what could be redone in this project: improve the model, refactor, write tests. What matters here is that the developer isn’t just throwing around buzzwords, but has a concrete plan for which places need what done. Let’s not forget that they were given more than five minutes. With a developer like that, you can and should continue the conversation about understanding the project’s mistakes and learning lessons.
A bad scenario is an empty report (or a report with template items like “refactor”, “write unit tests” and no specifics). An empty report will be submitted by an idiot, a lazybones, or a person incapable of critically assessing objective reality, incapable of reflection. It’s unclear how such a person ended up on your project. That person needs to be shown the door.
Project managers, no thanks necessary.