Должен ли программист быть немножко «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. Я с безответственными и безынициативными работать так и не научился :)

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

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