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



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

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



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

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

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

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

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

    А что если?

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

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

    Мораль

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

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

    Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

    Какой вы выработали принцип работы со своими задачами?
    Всем ли стоит высказывать свои предложения (пожалуйста, отвечайте, если на предыдущий вопрос был выбран второй ответ)
    Поделиться публикацией
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 16
      +2
      Вникнуть в проблему, предусмотреть последствия и предложить улучшения/решения однозначно нужно.
      Заниматься улучшениями, доработками «втихоря» не стоит. Потому что эти «улучшения» могут оказаться никому не нужны.
      ИМХО, главное — правильная налаженная коммуникация.
        0
        Если следовать практикам DDD — то обязательно.
          0
          К сожалению в Enterprise'е инициатива очень часто наказуема. Т.к. менеджмент на столько боится на себя брать отвественность хоть за какое-нибудь изменения дизайна или функциональности (пусть даже это намного лучше), что потом очень часто достается программисту — т.к. он всегда оказывается крайним.
          Было несколько раз, когда наша команда делала по другому, иногда даже говорили спасибо за это, но всегда добавляли — что бы в следущий раз советывались. Но сколько мы не пытались советываться — ответ от менеджера была всегда один — делаем так как написано в спецификации.

          Такой уж этот кровавый энтерпрайс.
          Недавно на хабре было несколько интересных статей о том, как работают процессы в финансовой сфере в NY.
            +1
            Было несколько раз, когда наша команда делала по другому, иногда даже говорили спасибо за это, но всегда добавляли — что бы в следущий раз советывались. Но сколько мы не пытались советываться — ответ от менеджера была всегда один — делаем так как написано в спецификации.


            Как я Вас понимаю!!! Только нам спасибо не говорили, а вежливо просили оставить вариант как в требованиях!
            Зато когда они поняли свою ошибку и пришил за доработками (а у нас-то уже готовый код был) слупили с них по полной :)
            0
            Да, как написали тут выше, инициативный разработчик — это хорошо. Но хорошему разработчику нужно хорошее понимающее начальство.
              0
              по поводу вашего первого примера — а почему тестировщик не смог «прощелкать» и кнопку, и крестик и поставить соответствующую задачу сразу? я думал, что тестировщики должны проверять за программистами, а не наоборот.
                0
                Изначально (сразу) было сломано только одно. После починки сломалось другое.
                Тестировщик-то конечно и проверял;)
                0
                Есть пара нюансов:
                — нужно именно предлагать, а не делать по-своему без обсуждений (бывали грустные прецеденты);
                — если идеи, предлагаемые разработчиком, постоянно отвергаются (к сожалению, не всегда разработчик хорошо понимает предметную область), это явно демотивируют.

                Тем не менее, я всецело за — преимущества чаще перевешивают недостатки.
                  0
                  (бывали грустные прецеденты);

                  а можно первому пункту пример привести, если его приемлемо разглашать?
                    0
                    Из своей практики могу только о своих ошибках говорить (именно архитектурных). А вот о чужих архитектурных ошибках очень интересно и познавательно рассказывает Сергей Мартыненко. На прошлом DevConf 2013 его небольшой доклад был одним из интереснейших, по крайней мере для меня!!!

                  0
                  ИМХО 2 подхода:
                  1. Есть умные люди, кто расписывает все (разрабы) и отдает это кодерам, которым думать можно только в рамках текущей задачи (в каком порядке массив заполнить и т.п. мелочи) = Разрабы получают Х денег, но их мало, кодеров много, но они получают меньше Х
                  2. ПМ расписывает задачи «вольным стилем», а разрабы уже вникают каждый в свою задачу и реализовывают сами — разрабов больше, но меньше цикл разработки.
                    0
                    У вас как на практике встречалось? Оба варианта?
                      0
                      Да.
                      Первый вариант — это большие проекты: инхаус разрабы + фрилансеры-кодеры на оутсорсе/подрядчики
                      Второй вариант — обычно небольшой коллектив/группа работающий/ая над проектом. Часто это проект-стартап или просто нечто что имеет непонятные ТЗ/исследования и т.п.
                    0
                    В упоминаемой проблеме есть два аспекта — инициатива и ответственность. В статье разбирается только один аспект, связанный с инициативой: «Нужно ли и можно ли разработчикам проявлять инициативу?»

                    Однозначного ответа на этот вопрос нет. Большинству разработчиков комфортнее работать в условиях, когда все решения уже приняты заранее и при случае можно свалить ответственность на тех, кто ставил задачу, дескать сами виноваты. Но встречаются и такие, которые хотят проявить инициативу, но им не дают, потому что ответственность за принятые решения несет кто-то другой. То, что кажется разработчику лучше, удобнее и полезнее, совершенно не обязательно окажется приемлемо для конечного заказчика.

                    На мой взгляд, без инициативы невозможен профессиональный рост. Но, как следствие связи инициативы и ответственности, рост происходит тогда, когда вместе с проявлением инициативы вы берете на себя и ответственность за то, что делаете. Безответственная инициатива обычно приносит больше вреда чем пользы.
                      0
                      Очень хороший комментарий. Спасибо. В команде лучше иметь и тех, и тех сотрудников. И тогда менеджеру станет проще работать.
                      0
                      Ну да. Только менеджер должен понимать кто перед ним и задачи ставить соответствующие.
                      p.s. Я с безответственными и безынициативными работать так и не научился :)

                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                      Самое читаемое