Should a programmer be a bit of a “product manager”?

I would like to raise an interesting topic of the performance of someone else’s duties. Everybody knows the catch phrase "Do not stick your nose at someone else's question." Is it always true? In the most frequent interaction “task developer - developer” I would like to understand. At once I will make a reservation that the opinion is purely IMHO , and the purpose of the publication is to generalize the suggested assumption to a higher level of abstraction and to understand, as in others.

First of all, a number of background information that reflects my specificity:
')


1) Of the entire software development cycle, my job responsibilities include most of it. Only the development (writing code) I do not have to deal with directly. An analyst about how it is written here.
2) The developer receives all development applications in the form of tasks in JIRA.
3) The company has a matrix structure. Therefore, one developer can simultaneously work on different projects with different RPs.
4) Situations with not very tough business logic are being analyzed, most of the situations are revision tasks, formalized in a simple text format. It is clear that if a project is developed from scratch and implies a well-developed design stage, the output of which is full of flowcharts and other diagrams, then deviations to the side should already be separated into a separate process and competence .
5) This is a web development

So, during the work, countless tasks were set and tested in JIRA. And there were two main approaches to the solution.

My hut on the edge ..

The task is carried out strictly formally. No step to the left, no step to the right. What is written is done. It is not necessary to look at what happened, how it relates to the general functional piece.
At the exit: the tasks are re-opened several times, testing needs to be carried out again, precious time is lost, dissatisfaction with teamwork is growing.

Example. I will not give real life examples, so that someone suddenly does not identify himself by chance. If to simplify the ugliness, then the essence is. There is a modal window, which is closed with a cross and a button. Everything, there is nothing more on it. A problem is posed, they say the button is broken - it does not close. I repaired, the server was updated, we look, it turns out that the window has stopped closing by the cross. Should the developer have to click the cross? Formally, no. If there was a little “product manager” or tester, then yes.

What if?

But what if the developer approaches the task a little creatively and offers or immediately does something extra? It may take a little longer today, but in the long run it can turn out to be very profitable. In addition, it is not long to click the cross from the last example, because the solved function is only one - to close the window.
At the exit: the task may take more time, in the course of testing no obvious flaws will be found, the work will bring mutual satisfaction .

Example.
The task was “Add a mechanism to create a record of viewing an object when it is opened / downloaded”. The task is simple and clear, it does not provide any ambiguous interpretation. Did an experienced developer, he apparently had time. And he additionally made "the task of aggregating statistics is older than a month." Those. so that the table does not swell over time. Helpful? Yes. Anticipating future problems? Yes. Was it in the requirements? Not. Is it good? Rather yes than no.

Morality

Personally, my opinion is that there should be more communication. A couple of phrases can save a significant amount of time. And a look at the task / problem from the side can generate the desired change in the original formulation of the problem.

And what position do you hold? Waiting for interesting comments.