Должен ли программист быть немножко «product manager-ом»?

Хотелось бы поднять интересную довольно-таки тему исполнения чужих обязанностей. Всем хорошо известна крылатая фраза «Не суй свой нос в чужой вопрос». А всегда ли это верно? В самом частом взаимодействии «постановщик задач — разработчик» я и хотел бы разобраться. Сразу оговорюсь, что мнение сугубо IMHO, а цель публикации обобщить высказанное предположение на более высокий уровень абстракции и понять, а как у других.

Перво-наперво, ряд вводной информации, которая отразит мою специфику:



1) Из всего цикла разработки программного обеспечения в мои должностные обязанности входит бОльшая его часть. Только разработкой (написанием кода) мне непосредственно и не приходится заниматься. Аналитик примерно как написано здесь.
2) Все постановки на разработку разработчик получает в виде задач в JIRA.
3) В компании матричная структура. Поэтому один разработчик может одновременно работать над разными проектами с разными РП
4) Разбираются ситуации с не очень жесткой бизнес-логикой, большая часть ситуаций — это задачи на доработку, формализованные в простом текстовом формате. Понятно, что если проект разрабатывается с нуля и подразумевает проработанный этап проектирования, на выходе которого полно блок-схем и прочих диаграмм, то отступления в сторону уже должны быть выделены в отдельный процесс и компетенцию.
5) Речь идёт про web-разработку

Так вот, за время работы было поставлено и оттестировано бесчисленное количество задач в JIRA. И обнаружилось два основных подхода к решению.

Моя хата с краю..

Задача выполняется сугубо формально. Ни шага влево, ни шага вправо. Что написано, то и сделано. Смотреть на то, что получилось, как это связано с общим функциональном куском, необязательно.
На выходе: задачи открываются заново по несколько раз, тестирование нужно осуществлять повторно, теряется драгоценное время, недовольство совместной работой растёт.

Пример. Реальных примеров из жизни приводить не буду, дабы кто-нибудь вдруг не идентифицировал себя случайно. Если до безобразия упростить, то суть такая. Есть модальное окно, которое закрывается крестиком и кнопочкой. Всё, больше на нём ничего нет. Ставится задачка, мол сломалась кнопка — не закрывается. Починил, сервер обновили, смотрим, оказывается по крестику окно перестало закрываться. Должен ли был разработчик прощёлкнуть ещё и крестик? Формально нет. Если б был немножко «product manager-ом» или тестировщиком, то да.

А что если?

А что если разработчик подойдёт к задаче немного творчески и предложит или сразу сделает что-то дополнительно? Это может занять чуть больше времени сегодня, но в долгосрочной перспективе может очень выгодно обернуться. Дополнительно прощёлкать крестик из прошлого примера недолго, ведь решаемая функция одна — закрыть окно.
На выходе: задача может занять больше времени, в ходе тестирования не будет обнаружено откровенных недоработок, работа принесёт взаимное удовлетворение.

Пример.
Была задача «Добавить механизм создания записи о просмотре объекта при его открытии/скачивании». Задача проста и понятна, никакого двоякого толкования не предусматривает. Делал опытный разработчик, у него, видимо, было время. И он дополнительно сделал «задачу агрегации статистики давнее, чем месяц». Т.е. чтобы таблица не разбухала со временем. Полезно? Да. Предвосхитило будущие проблемы? Да. Было в требованиях? Нет. Хорошо ли это? Скорее да, чем нет.

Мораль

Лично моё мнение, что должно быть больше коммуникации. Пара фраз могут сэкономить значительное количество времени. А взгляд на задачу/проблему со стороны может сгенерить нужное изменение в исходную постановку задачи.

А какой позиции придерживаетесь вы? Жду интересных комментариев.