A strange case in the management of a project. What position to take?

Question

The issue is related to project management, where this was the best (perhaps only) way to expose my doubt before the situation. I agree that it was a little long, but I found no other way to focus on the same.

Come on:

The company is seeing a new project (it is a medium-sized system), and in meetings the following happened:

Two programmers and an analyst were assigned to this project, in which case the analyst has less experience than the two programmers (that would be me and another). In a given agenda, were being discussed the technologies to be used and how would be the layers, architectures, etc.... of this system. The analyst made some suggestions. The other programmer (this one with more experience than me) soon interfered with technical arguments showing that it would not be a good choice and in that the analyst not accepting, the meeting passed around 40 min more than expected.

In new meetings the programmer brought documentation and more explanations suggesting an architecture model and other points as well, such as GIT flow, etc... that would be good and predicted the whole project (in this part I realized that really were good suggestions) and the analyst again reluctant, where strangely without any technical arguments got approval from the project manager who presented the new project. A week later this programmer received an oral warning (nothing formal, but before the team) about him being hindering the project with his positions, etc...

Today, after about four months, the system has an architecture proposed by the analyst with business rules a little in a designated layer in PHP, and a little in Angularjs. The system was made using Angularjs. The angular itself has a part for routing, but even so there are some pages in PHP because the analyst found it "easier" to do.

In production is being used a DBMS and in development another DBMS (another choice of analyst). Each developer has a different version of the database modeling, where a file . sql is sent for the task and none of these have access to the system running completely and much less to the base modeling, because everything is independent and focused only to the analyst.

All technical decision-making today is focused only by this analyst and although errors of up to R $ 1,000.00 in commissions have appeared (parts of the system is already in use, because it is an internal system)and the focus of management continues to give all technical relevance to this. As well as all the more complex implementations, of the kind that would be interesting opinions, team decisions, debates, etc., this does it all by itself. The other day seeing this programmer again correcting an error on a screen, the analyst just sort of "threw it in the face" saying that he was the analyst and that he made all the decisions that would be that way and that’s it.

Given the context described above, and taking into account that financially the company pays (R$) reasonably, comes to me the following points:

1. I need opinions, feedback, criticism, praise, suggestions, ways of thinking, etc.... in general about this context.

2. Is it worth investing a career in a company that has such a development sector? (Today there are only three medium projects in the company, counting on this)

In my opinion the situation is bizarre to say the least, but I would like opinions and experiences focusing on a position to be taken in the face of the situation. These two points I have mentioned are important.

OBS: It is right that it is not 100% say according to the rules here, but being the life time of this doubt limited, the considerations are valid, or suddenly a "vacuum" until someone with greater experience read this question.

Answer 1

In my view, there are simple and complicated answers, because the thing ta kinda subjective there. But, I will try to be objective.

1 - What you want in life, remains what you want independent of a particular project.

Here’s the thing, face to face, about staying in the project or not. Focus on what you want, if you want to continue, continue, if you don’t want to start looking for another one. This will involve if you are learning something, if you are in need of money and a lot of personal things, just look outside the project and think about what you want.

2 - A tribe cannot have 3 chiefs.

Young man, in a very direct way, if the power of decision belongs to the analyst, then the decision belongs to the analyst and that’s it. I’m not saying that you have to agree, I’m saying that in everything in life, a decision has to be made and in companies, the roles are there. What you can do is already being done, show other views, but in the end the person who has the power of decision can simply decide not to do it, this is not necessarily an affront or something bad, he has the responsibility and can decide, you may disagree, but if you decide to stay on the project, you have to accept that your suggestions will not always be accepted and that it is part of professional life to accept well the decision of others. That doesn’t apply to ethical aspects, if you’re asked to steal, it’s still theft even if it’s your boss or analyst. If you’re out of ethics, then look for a better place.

3 - Your truth is not always the truth.

Often, we are so focused on our view of the problem that we forget to look fondly at the vision of others and some people have a tendency to lose focus on what is important and end up focusing simply on winning the discussion. In my view, if you are still trying to convince the Analyst (who has already decided) about architecture, you are either doing it wrong or you are wasting the time of the project discussing something that has already been decided, has 4 months of operation and that will lead nowhere because it is very unlikely a refactoring of this size in a project that is in production for 4 months. So, my advice is to rethink your position that might actually be getting in the way and not helping. This doesn’t stop you from continuing to talk or proposing other improvements, just change the focus, or change the approach. If you’re so frustrated because you’re never heard of, you’re still doing what you’re doing?

4 - The old case of numbers.

Do you have any metrics to say whether what has been adopted is good or bad? does the system have bugs? security flaws? how many bugs occur in testing? How many go into production? Instead take sporadic emails about issues or amounts unduly paid for bugs, define your software and operation process and start tracking the numbers. Track the features with the most problems and qualify what types of flaws are generating the problems, with numbers it becomes easier to decide for definitive solutions and not make it a witch hunt, when you have this type of report, take a solution first to be tested the place of raising the culprit. You all know whose fault it is, even if it’s yours or the analyst’s, it doesn’t matter and it won’t improve your lives or your software.

5 - Functional software is the primary measure of progress. That phrase is not mine and I myself often had to repeat it to myself not to strangle some client. I have a technique technique and as such, I like to do technical things well done, I do not like seemingly wrong paths. It accumulates technical output and goes against what’s in my veins. But the world isn’t perfect, nor will your software be, and if you can’t get it into production, in fact, you’ve failed a lot more than if you do it differently than you think. What I mean is that the system is working, so you have to start balancing things between technical preciousness and customer satisfaction. So, a much more important question after 4 months is: Is your customer satisfied with the software? If yes, wonder, improve it. If not, find the why, otherwise, regardless of the architecture and all the brilliance that can be proposed, you will fail.

If you use an agile software process, then read: http://www.manifestoagil.com.br/

And put a little more of those values in your life.