«Универсал» в команде разработки: польза или вред?

    image

    Всем привет! Меня зовут Людмила Макарова, я менеджер разработки в УБРиР и треть моей команды – «универсалы».

    Признайте: каждый Tech Lead мечтает о кросс-функциональности внутри своей команды. Ведь это так круто, когда один человек способен заменить трех, да еще и сделать это качественно, не сдвигая сроки. И, что немаловажно, это обеспечивает экономию ресурсов!
    Звучит очень заманчиво, но так ли это на самом деле? Давайте попробуем разобраться.

    Кто он, наш предвосхититель ожиданий?


    Под понятием «универсал» обычно понимают членов команды, сочетающих в себе больше одной роли, например, разработчик-аналитик.

    Взаимодействие команды и результат ее работы зависят от профессиональных и личностных качеств участников.

    По hard skills все ясно, а вот soft skills заслуживают особого внимания. Они помогают найти подход к сотруднику и направить его именно на ту задачу, на которой он будет максимально полезен.

    Существует много статей о всевозможных типах личностей представителей IT-индустрии. Опираясь на свой опыт, я бы поделила IT-универсалов на четыре категории:

    1. «Универсал – всемогущий»


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

    В чем сильны:

    • способны решать сложные задачи;
    • глубоко погружаются в проблему, «копают» и добиваются результата;
    • обладают пытливым умом.

    Но:

    • эмоционально лабильны;
    • слабо управляемы;
    • имеют свою непоколебимую точку зрения, которую очень сложно изменить;
    • сложно заставить сделать простое дело. Легкие задачи задевают самолюбие всемогущих.

    2. «Универсал – разберусь и сделаю»


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

    В чем сильны:

    • самостоятельны;
    • стрессоустойчивы;
    • компетентны во многих вопросах;
    • эрудированы – с ними всегда есть о чем поговорить.

    Но:

    • часто нарушают обязательства;
    • склонны все усложнять: решают таблицу умножения интегрированием по частям;
    • качество работы низкое, все получается с 2-3 раза;
    • постоянно сдвигают сроки, потому что на самом деле все оказывается не так-то и просто.

    3. «Универсал – ладно, давайте я, раз больше некому»


    Сотрудник неплохо разбирается в нескольких областях и имеет соответствующий опыт. Но ему не удается стать профессионалом ни в одной из них, потому что его часто используют в качестве спасательного круга, затыкая дыры по текущим задачам. Податлив, исполнителен, считает себя востребованным, однако таковым не является.

    Практический идеальный сотрудник. Скорее всего, у него есть направление, которое ему больше нравится, но из-за размытия компетенций развития не происходит. В результате человек рискует стать невостребованным и эмоционально выгоревшим.

    В чем сильны:

    • ответственны;
    • нацелены на результат;
    • спокойны;
    • полностью контролируемы.

    Но:

    • показывают средний результат из-за низкого уровня компетенций;
    • не могут решать сложные и абстрактные задачи.

    4. «Универсал – мастер своего дела»


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

    Хорошо знаком с архитектурой, выбирает метод технической реализации, тщательно анализируя влияние выбранного решения на текущую архитектуру. Скромен, не амбициозен.

    В чем сильны:

    • показывают высокое качество работы;
    • способны решить любую задачу;
    • очень работоспособны.

    Но:

    • нетерпимы к мнению других;
    • максималисты. Стараются все сделать правильно, а это увеличивает сроки разработки.

    Что имеем на практике?


    Посмотрим, как чаще всего объединяются роли и компетенции. За отправную точку возьмем стандартную команду разработки: PO, менеджер разработки (техлид), аналитики, программисты, тестировщики. Владельца продукта и техлида считать не будем. Первого – из-за отсутствия технических компетенций. Второй, если в команде проблемы, как раз должен уметь делать все.

    Наиболее распространенный вариант объединения/слияния/совмещения компетенций – разработчик-аналитик. Также очень часто встречаются аналитик-тестировщик и «три в одном».

    На примере своей команды покажу, в чем плюсы и минусы коллег-универсалов. В моей команде их треть, и я их очень люблю.

    От PO поступила срочная задача по внедрению новых тарифов в существующий продукт. В моей команде 4 аналитика. На тот момент один находился в отпуске, другой заболел, а остальные занимались реализацией стратегических задач. Если бы я выдернула их, это неизбежно сорвало бы сроки реализации. Остался единственный выход: использовать «секретное оружие» – универсала разработчика–аналитика, который владел нужной предметной областью. Назовем его Анатолий.

    Его тип личности – «универсал – разберусь и сделаю». Конечно, он долго пытался объяснить, что у него «полный бэклог своих задач», но моим волевым решением был отправлен на решение срочной задачи. И Анатолий справился! Он провел постановку и выполнил реализацию в срок, а заказчики остались довольны.

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

    Проблема заключалась в том, что многие скрытые моменты и подводные камни остались только в голове нашего универсала и не были перенесены на бумагу. Как позже объяснил Анатолий, он слишком торопился. Но наиболее вероятен вариант, что он наткнулся на проблемы уже при разработке и просто их обошел, нигде это не отразив.

    Была и другая ситуация. Сейчас у нас только один тестировщик, поэтому некоторые задачи приходится тестировать аналитикам, в том числе – универсалам. Поэтому один таск я отдала условному Федору – «универсалу – ладно, давайте я, раз больше некому».
    Федор – «три в одном», но по этой задаче уже был выделен разработчик. Значит, Феде надо было совместить в себе только аналитика и тестировщика.

    Требования собраны, спецификация передана в разработку, пришло время тестировать. Федор знает дорабатываемую систему «как свои пять пальцев» и досконально прорабатывал текущие требования. Поэтому он не стал утруждать себя написанием тестовых сценариев, а провел тестирование на то, «как система должна работать», потом – передал пользователям.
    Тест завершился, доработка ушла на пром. Позже выяснилось, что система не только приостанавливает проведение платежей на определенные балансовые счета, но и блокирует проведение платежей с очень редких внутренних счетов, которые не должны были участвовать в этом.

    Это случилось из-за того, что Федор не провел проверку на то, как «не должна работать система», не составил тест-план, чек-листы. Он решил сэкономить на сроках и положился на собственное чутьё.

    Как работаем с проблемами?


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

    1. По каждой задаче, вызвавшей сложности, я прошу заполнить унифицированную форму: карту ошибок, которая позволяет выявить этап, на котором произошла «просадка»:

    image

    2. После выявления узких мест, с каждым сотрудником, повлиявшим на проблему, проводится мозговой штурм «Что изменить?» (частные случаи мы не рассматриваем на ретро), по итогам которого рождаются конкретные действия (для каждого типа личности свои) со сроками.

    3. Мы ввели правила взаимодействия внутри команды. Например, договорились обязательно фиксировать всю информацию о ходе задачи в системе управления проектов. При изменении/выявлении артефактов в процессе разработки нужно отображать это в базе знаний и итоговой версии ТЗ.

    4. Контроль стал проводиться на каждом этапе (особенное внимание уделяется проблемным этапам в прошлом) и автоматически по результатам выполнения следующей задачи.

    5. Если результат по следующей задаче не изменился, то рассматриваемого универсала не ставлю в ту роль, с которой он плохо справляется. Стараюсь оценить его способность и желание к развитию компетенций в этой роли. Если не нахожу отклика, оставляю его в той роли, которая ему ближе.

    Что в итоге получилось?


    Процесс разработки стал прозрачнее. Уменьшился BUS-фактор. Члены команды, работая над ошибками, становятся более мотивированными, улучшают свою карму. Мы постепенно повышаем качество наших релизов.

    image

    Выводы


    У сотрудников-универсалов есть свои плюсы и минусы.

    Достоинства:

    • можно в любой момент закрыть провисающую задачу или разрешить срочный баг в короткие сроки;
    • комплексный подход при решении задачи: исполнитель смотрит на нее со стороны всех ролей;
    • универсалы могут практически все делать одинаково хорошо.

    Недостатки:

    • растет BUS-фактор;
    • размываются основные компетенции, присущие роли. Из-за этого снижается качество работы;
    • повышается вероятность сдвига сроков, т.к. отсутствует контроль по каждому этапу. Также возникают риски выращивания «звезды»: сотрудник уверен, что он лучше знает, что он – профи;
    • увеличивается риск профессионального выгорания;
    • много важной информации о проекте может остаться только «в голове» у сотрудника.

    Как видите, недостатков больше. Поэтому универсалами я пользуюсь только в том случае, если не хватает ресурсов, а задача достаточно срочная. Или человек обладает компетенциями, которых недостаточно у других, а на кону стоит качество.

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

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

    Желаю всем самоорганизующейся команды «универсалов–мастеров своего дела»!
    Поделиться публикацией

    Комментарии 55

      +6
      О, я универсал. Все задачи делаю одинаково плохо.
        +1

        Значит я не один такой :D

        +4
        Признайте: каждый Tech Lead мечтает о кросс-функциональности внутри своей команды.


        Признаюсь: нет. По опыту — любой «универсал» хуже любого «узкого спеца». Наелся, сорри.

        PS: да, пост читал.
          +4
          Статья по большей части не об универсалах, а об «универсалах».
            +4
            Как я понял из поста, универсал — это спасательный круг, которым пользуются, чтобы затыкать «дыры», а когда он (неизбежно) накосячит — ему устраивают «мозговой штурм». При условии, что узким специалистам еще и платят больше, у меня возникает лишь один вопрос: «Да кто на такое пойдет по собственному желанию?»

            Впрочем, выход есть! В статье, даже, неявно указана возможность разорвать порочный круг — нужно начать стабильно косячить в тех задачах, которые ты не хочешь делать и тогда тебя на них не поставят. Так, даже, можно стать обычным узким специалистом, которого никто и не подумает «засунуть» куда попало…
              0
              Инициатива наказуема. Если часто отзываешься на помощь и качественно решаешь проблемы, тебе садятся на шею, превращая тебя в универсальный спасательный круг, заставляя решать задачи, которые тебе неинтересны, и в которых ты разбираешься слабее, чем в своей основной специализации. Твоя основная специализация тебе интереснее, поэтому ты глубже в нее вникаешь.

              Но то, что за это меньше платят — неправда. В каких-то местах за это действительно платят. Но задачи от этого интереснее не становятся, и поэтому руки опускаются вообще что-либо делать с душой.
                +1
                Вы таки не поверите, но это одна из успешных методик избавления от ненужной лично для себя работы во многих отраслях. Именно косячить там где нет желания работать и вникать как всё происходит.
                  –1

                  Это определение отражает третий тип личности универсала, описанный в статье, но Вы отчасти правы — в условиях ограниченности ресурсов может трактоваться именно так, но в этом нет ничего предосудительного.
                  Как раз в статье я попыталась показать сильные и слабые стороны каждого типа, зная которые можно найти подход по эффективному совмещению ролей и выстраиванию процесса работы с человеком.


                  Универсал — это человек имеющий свою основную узкую специализацию и приобретённые дополнительные специализации в процессе своего опыта работы в компании.
                  И вовсе не обязательно, что работа универсала будет выполнена плохо.


                  И каждому узкому специалисту свойственно ошибаться, просто если заниматься работой, не свойственной для себя работой, то какие-то моменты могут быть упущены(под несвойственной подразумевается: писать ТЗ разработчику, который способен сам взаимодействовать с заказчиком, собрать, формализовать и понять требования заказчика ). Однако, при этом может получиться вполне нормальный продукт, но если бы соблюдалось разделение ролей, то с большей вероятностью, можно получить более высокий результат.


                  «Мозговой штурм» нужен для того, чтобы разобраться в причинах проблем, предложить идеи, как можно этого избежать, закрепить дальнейшие действия и как результат улучшить свою работу, а НЕ найти и наказать виноватых.


                  Универсалов нужно беречь и помогать им выявить слабые места и попытаться развить их или отказаться от использования такого «универсала». Обычно, истинные универсалы заинтересованы в своём развитии, тк бесспорно ценятся в команде выше.

                  +20

                  Простите, но вся статья полна менеджер коих ошибок, а обвиняет вы в них неких "универсалов" которых же сами и выдумали.
                  Всё кейсы происходят по одному сценарию:


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

                  Если вы реально хотите эту задачу сделанную хорошо, то как минимум должны разгрузить человека от других задач, как-то замотивировать делать то что он не хочет, оказать помощь/обучение если компетенции недостаточно и самое главное контролировать качество.
                  Т.е. Кто-то должен проверить что документация написана, тест листы составлены и т.п.
                  А сейчас вы ведёте себя как "эффектный менеджер", где все заслуги (выполнили в срок) ваши, а косяки они от разработчиков.

                    +6
                    Ну почему же, «как»? Это эффективный манагер и есть, по слогу видно, по профилю.
                      0

                      Сразу оговорюсь, что универсал не может быть новичком, это люди уровня мидл, сеньор, уже зарекомендовавшие себя в роли универсала. К таким специалистам очень высок уровень доверия.


                      Вероятно, Вы сформировали такое мнение, т.к., для того, чтобы показать недостатки в работе универсалов (о преимуществах итак всем известно), я привела примеры, в которых описала узкие места. О том, кого я понимаю под универсалами, я ответила в предыдущем комментарии.


                      Также, возможно не хватило вводных, поэтому поясню.


                      1. Безусловно, когда речь идёт о необходимости выполнения новой задачи, тем более срочной, остальные задачи сдвигаются и человек занимается новой задачей ( либо одним либо несколькими последовательными этапами, как универсал)
                      2. Задачи даются человеку только, если он обладает необходимыми компетенциями ( хорошо знаком с направлением, продуктом, ранее писал тз/кодил/тестировал по этому сервису/продукту)
                      3. Контроль качества по этапам присутствует. Но здесь речь идёт о том, что в силу особенностей типа личности, наличия необходимого инструментария, компетенций, может происходить «замалчивание нюансов» в тз, пренебрегание правилами, и т.д. Это может быть и узкого специалиста, но если один и тот же специалист выполняет всю задачу, риск выше.
                        Вчитываться в каждое тз, проверять чек-листы и ревьювить код не по силам техлиду из команды в 12 человек. Конечно, в серьезных проектах предлагаемое решение выносится на экспертный совет. Но при решении рутинных задач достаточно информации с митинга и репутации члена команды.

                      Также, отмечу, что успешный результат в двух приведённых примерах, это заслуга именно тех, кто работал над задачей и довёл ее до конца.

                        +1
                        не по силам техлиду из команды в 12 человек.

                        Делегирование ему тоже не под силу?

                          0

                          Проблемы «замалчивания нюансов» это не решает.
                          Позвольте спросить, а у Вас в команде есть отдельные ставки людей экспертов по аналитике и тестированию, досконально знающие все направления, продукты и сервисы, бизнес процесс в конце концов.


                          С кодревью все понятно, а остальное очень спорно.

                            0

                            Только по тестированию. Аналитиков в вашем понимании совмещают, наверное, программисты. Они (мы) получают бизнес-задачи на "человеческом" языке, часто с макетами или мокапами интерфейсов, ссылками на документацию к внешним API и т. п., проектируют модели (иногда в UML, но чаще сразу в коде), обращаясь к бизнесу за предметной экспертизой.

                      +16
                      , я прошу заполнить унифицированную форму: карту ошибок,

                      Увольнять...


                      Таких менеджеров "разработки".


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


                      И именно менеджер разобравшись в ходе выполнения (привлекая отзывы исполнителей) и связях должен определить причину ошибки.


                      Если менеджер совсем "деревянный" он может собрать общий "консилиум" для того чтобы совместным обсуждением исполнители сделали работу менеджера.
                      Но и в этом случае есть необходимость контролировать процесс для того чтобы это была действительно экспертиза, а не поиск крайнего.

                        –2

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


                        Эта карта заполняется именно теми, кто принимал участие в решении задачи. Она необходима для того, чтобы разобраться на каком этапе произошёл возможный косяк. И при совместном обсуждении перерождается в понимание истинной причины и того, что нужно усовершенствовать в следующий раз тому или иному человеку.
                        Если ошибка очень значительная и привела к простою ИС, то к обсуждению привлекаются другие эксперты.

                          +2

                          Давайте не перекладывать с больной головы на здоровую.


                          Ваш текст не допускает трактовки в которую вы пытаетесь его сейчас перевернуть.
                          Учитесь признавать свои ошибки.

                        +4
                        универсалами я пользуюсь только в том случае, если не хватает ресурсов, а задача достаточно срочная

                        треть моей команды – «универсалы»

                        нафиг так жить.
                          +5

                          Кажется, что вы путаете значение выражения "bus factor". В позитивном ключе оно должно звучать как "увеличили bus factor". Проверить легко — чтобы проект "встал" надо сбить автобусом "bus factor" участников.

                            0

                            Или "снизили влияние бас-факторас

                              –2

                              Под “bus фактором», я понимаю сосредоточение знаний, компетенций в голове у отдельно взятого специалиста. И глобальная цель -уменьшение этого фактора, так скажем, «расшивание компетенций».

                              +4
                              Еще одна «эффективная сова» на Хабр подтянулась.
                              Не надо затыкать дыры сотрудниками. Если образовалась дыра, это недоработка руководителя. На этапа анализа проекта надо было расчитать все риски и рассмотреть возможность найма дополнительного сотрудника.
                              А то затыкают дыры, а потом страдают: «Ой, у нас разработчики эмоционально выгорают, что делать?»
                                –7
                                Добро пожаловать в реальную жизнь, тут иногда случаются фейлы, всего не предусмотреть.
                                  +9
                                  За фейлы должен отвечать тот, на ком ответственность и административные ресурсы, кто этого не предусмотрел, а не тот, кто отозвался на помощь вопреки своим желаниям, и сделал хотя бы что-то, потому что без него бы вообще проект встал.
                                  –1

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

                                  +4
                                  Поэтому универсалами я пользуюсь только в том случае, если не хватает ресурсов, а задача достаточно срочная.

                                  т.е. систематически?
                                    0
                                    похоже, что да.
                                    0
                                    Наказать кого то хорошо, а с фейлом что делать?
                                    Если образовалась дыра, ее нужно закрыть, а уже потом думать, что можно сделать что бы такого не случилось.
                                      +1
                                      Наказать кого то хорошо, а с фейлом что делать?

                                      Наказывать надо не кого-то, а того, кто виноват в дыре. А не того, кто попытался заткнуть собой эту дыру. А если ответственный не может заткнуть дыру, значит его и увольнять.
                                        –1

                                        Как уже писала в комментариях выше, цель статьи иная. Не поиск виноватых и их наказание, а выявлении проблем и поиска их решения

                                          +1

                                          Выше решение и предложили: заменить ПМ на компетентного. Судя по посту и комментариям, такой ПМ тянет на дно всю команду.

                                      +4
                                      мой опыт в области разработки электроники и сопутствующих прошивок с софтом (порой сложным, веб, пк, мк, малинка, бд, бигдата и тд).
                                      Как обычно делают в области разработки электроники в России: «требуется программист с опытом монтажа плат и разработки софта и прошивок». Часто набирается весь штат таким образом. Порой до сотни человек. Следствия — сроки затягиваются, половина проектов в разы сложнее скетча ардуинки провальные. Но хорошо такой бизнес работет на аутсорс именно без сервиса внедрения и сопровождения. Многие заказчики прямым текстом и пишут что требуется эскизный проект, proof of concept и тд. Всё ок и по честноку. Зарплаты конечно же 40-70тр что правильно — кпд на сотрудника низкое, а ответственности за быдлокод и быдлоконструкции нет.
                                      Но нередко подобный подход и в тех фирмах которые потом продают и поддерживают свои проекты, многие так и живут т.к. часто это спец оборудование мелкими сериями или вообще разовое.
                                      Причины просты: «ты будешь балду пинать пока идут платы, собирают изделия и тд — вот и занимайся всем, сам же паяй чтоб лучше понять что где плохо сделал»

                                      Мы так же работали, как только стала появляться разделение труда на схемотехника, проектного менеджера, разработчика тестовой оснастки (не только юнит тесты, а ещё проверка и регулировка собранного изделия), разработка прошивок, разработка софта для ПК, разработка приложух для смартов, разработка для hightload и тд.
                                      Я заметил интересную особенность:
                                      1. мы перестали переключаться на совершенно разную деятельность, не нужно сегодня паять платы, завтра рисовать корпус в солидворксе, а потом кодить а потом согласовывать перечеть элементов и закупать его и тд. Высвободилось сразу около 30-40% времени. — рост быстродействия сразу 30-40%.
                                      2. Люди начали пересматривать свою деятельности и рефлексировать — поменялись подходы и каждый стал действовать более системно.
                                      3. Даже у тех кто рисует корпуса и платы начали появляться библиотеки, базы готовых решений, и не просто скопировал — вставил, они начали писать проги для того чтоб например лого в bmp сконвертировать в G-code для фрезера и тд. Т.е. во всю начал развиваться инструментарий.
                                      4. Повысилось качество — не получалось так что тот кто делает тесты для кода и тот кто делает реализацию кода один и тот же человек и он заблуждается одинаково в обоих случаях. В реальном мира аналогично — стало невозможно свалить на нерпопай, заряженую частицу и пр. т.к. тест сделанный другим человеком проходит а основная прошивка сбоит и тд.
                                      5. Люди стали использовать наработки друг друга, порой очень эффективно. Например чтоб вынести решение по оценочной стоимости железяки — стало достаточным скачать служебные утилитки железячника, схематехника, за десять минут получить BOMlist уже с импортом цен из веба и спросить программиста что покрывается его либами и наработками а что нет.
                                      6. оказалось что сборка одной платы совсем не одно и то же что 10 плат и совсем иной разговор для сотен и тысяч плат

                                      пунктов много, но результат — рост скорости разработки внедрения в производство минимум раз в 10, очень существенный рост зарплат, выше чем предложения по МСК и Питеру.
                                      Схема не работает при текучке кадров, бессмыслена для зарубежного аутсорса. И лучше всего работает только когда имеется под боком своё производство (свой продукт или свой сервис в случае ИТ).
                                      Вот такие вот контр-аргументы против фулстека и «универсалов» на основе моего опыта.
                                        +4
                                        Адам Смит вас поздравляет: вы пришли к разделению труда
                                          0

                                          Спасибо, что поделились своим мнением и привели аргументы. Было очень интересно читать Ваш пост, он описывает насущные проблемы.

                                          +1

                                          У вас для подобных задач отдельный флоу, раз не можете контролировать сроки по этапам? И с бас-фактором непонятно: чем больше универсалов, тем меньше вероятность того, что разработка встанет из-за того, что кто-то перестанет работать.


                                          Хотя вот с потерей информации согласен, когда сам себе постановщик задачи и исполнитель, и даже приемщик, то обычно не тратишь время на документирование нюансов и уж точно не ведёшь с собой диалога в джире :)


                                          А вообще, если вам часто приходится решать срочные задачи, отменяя планы, то, похоже, вы как менеджер, являетесь представителем заказчика в команде, а не членом команды, которому она делегировала управление.

                                            –1

                                            Отдельного флоу нет, все в рамках эджайла.


                                            Я всегда на стороне команды, прежде чем принимать решение о необходимости выполнения срочной задачи (если это не требование регулятора), с бизнесом обсуждается целесообразность, возможные альтернативы.
                                            Но мы все понимаем, какова степень влияния представителей бизнеса на команду разработки. Самое главное мы должны понимать для чего это делаем, если понимания нет, то находим контр аргументы для отказа бизнесу.


                                            Срочность и иногда внезапность задач у нас обусловлена двумя факторами: 1. Требованиями регулятора, 2. Требованиями бизнеса.


                                            Более срочная задача вытесняет менее срочные, происходит переприоритезация бэклога.

                                              +1
                                              Отдельного флоу нет, все в рамках эджайла.

                                              Если задачи у вас разбиваются на этапы, допустим "анализ", "разработка", "тестирование" и при физическом разделении ролей аналитика, разработчика и тестировщика сроки контролируются, то почему это не работает когда физического разделения нет?

                                                0

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

                                                  +1

                                                  Контроль сроков и соблюдение сроков — разные вещи. Ну и вы как менеджер должны учитывать такие риски. Хотя бы грубым умножением на 3. Сказал разработчик, что напишет за 8 часов, а тестами покроет за 4 часа и никогда раньше со сроками разработки не ошибался, а тестами никогда при вас не занимался, но вроде компетентен: разработку не трогайте, а на тесты 12 часов отводите и контролируйте, что, например, через 4 часов хотя бы один тест сделан, а через 6 — половина.

                                            +4
                                            В моей команде 4 аналитика. На тот момент один находился в отпуске, другой заболел, а остальные занимались реализацией стратегических задач. Если бы я выдернула их, это неизбежно сорвало бы сроки реализации. Остался единственный выход: использовать «секретное оружие» – универсала разработчика–аналитика

                                            Сейчас у нас только один тестировщик, поэтому некоторые задачи приходится тестировать аналитикам, в том числе – универсалам


                                            По ходу у вас универсалы как Вася на картинке
                                            И еще вопрос, вдруг я что-то не так понял. Сначала
                                            Что в итоге получилось?

                                            Процесс разработки стал прозрачнее. Уменьшился BUS-фактор

                                            после
                                            Недостатки:
                                            растет BUS-фактор;

                                            так растет или падает? По вашей же схеме ваши фейлы можно спихнуть покорным чувакам которые точно не огрызнутся «это не моя зона ответственности», так что по идее если кто-то из такой команды загрустит и ликвидируется каким-либо способом его работу можно спихнуть на кого угодно, а если не справится — значит он плохой разработчик
                                              –1

                                              Как уже писала выше, акцент был сделан на выявление недостатков и как с ними можно работать (т.к., преимущества универсалов известны), поэтому у Вас могло сложиться обманчивое впечатление.


                                              В разделе «Выводы» подведён итог в части + и — использования универсалов — это Общий вывод, а в разделе «что получилось», результаты конкретных действий по приведённым примерам.

                                                +2
                                                У вас противоречие — в одном месте BUS-фактор растет, через пару абзацев уже падает. Вот что мне хотелось узнать. Ну и «использования универсалов» звучит будто это не люди, а какие-то инструменты, типа «использование напильника». Мне кажется это показывает как вы к своей команде относитесь.
                                                А еще показательный отрывок статьи:
                                                Конечно, он долго пытался объяснить, что у него «полный бэклог своих задач», но моим волевым решением был отправлен на решение срочной задачи

                                                На мнение сотрудника, очевидно, был положен болт.
                                                Собственно, вы так и не ответили на вопрос — растет или падает BUS-фактор? Из ваших ответов я сделал вывод что вообще не влияет, все равно мнение сотрудника учитываться не будет, так что любую, даже непрофильную работу он все равно сделает
                                                  –1
                                                  1. Про bus фактор — если есть универсал, то он повышается. Для его снижения принимаются меры, общими словами описанные в соответствующем разделе статьи.
                                                  2. Посмотрите пожалуйста прошлые комментарии, кого я понимаю под универсалами, и под непрофильной = несвойственной работой.
                                                  3. Те цитаты, которые Вы приводите, всего лишь литературный оборот, не более. Повторюсь, что с появлением срочной задачи, другие задачи у сотрудника сдвигаются. Термин «использование универсалов » упоминается в контексте «использование ресурсов».
                                                  4. Не бывает неинтересных задач- работая над каждой задачей можно почерпнуть что-то новое. Есть отсутствие желания. Человек, желающий развивать свои компетенции может и хочет работать с любой задачей, даже с рутинной ( если Вы вкладываете такое понятие в «неинтересные»). К каждому сотруднику можно найти подход, зная его мотивацию.
                                                    +1
                                                    Повторюсь, что с появлением срочной задачи, другие задачи у сотрудника сдвигаются

                                                    И отрывок статьи
                                                    В моей команде 4 аналитика. На тот момент один находился в отпуске, другой заболел, а остальные занимались реализацией стратегических задач. Если бы я выдернула их, это неизбежно сорвало бы сроки реализации. Остался единственный выход: использовать «секретное оружие» – универсала разработчика–аналитика

                                                    Т.е. дернуть аналитиков для выполнения их работы в их зоне ответственности нельзя, но на занятого разработчика повесить их работу вполне норм? Шикарно
                                                    Термин «использование универсалов » упоминается в контексте «использование ресурсов».

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

                                                      Обоснование, чтобы выдернуть универсала разработчика приведено в том же куске статьи.


                                                      Мне искренне жаль, если моя статья Вас задела. Возможно, это связано с Вашим личным негативным опытом.
                                                      И я не вижу смысла Вас разубеждать искать скрытый подтекст, которого нет)

                                                      0
                                                      1. Бывает. Откуда новое, если одну и ту же задачу делаешь в сотый раз с небольшими изменениями? Ну, банальные CRUD страницы в админке веб-приложения. А менеджер на предложения написать за неделю их генератор и (в идеале) вообще забыть про этот тип задач говорит "у нас нет недели, они вчера нужны были для этой сущности".
                                                      +1
                                                      Мне кажется, что автор статьи просто не понимает что такое BUS-фактор, но очень хочет казаться «умным и прогрессивным».

                                                      От себя могу сказать, что надо бежать от такого «эффективного менеджера», причем быстро.
                                                      Это же надо придумать такое:
                                                      1. у разработчика есть полный бэклог задач
                                                      2. на его мнение и аргументы «положили болт», потому что «волевым решением..»
                                                      3. под принуждением волевым решением, он сделал не свой проект (и сдал его в срок)
                                                      4. устраиваем публичную порку «мозговым штурмом», потому что «снижается качество работы»
                                                      5. разработчики боятся послать такого менеджера «Члены команды, работая над ошибками, становятся более мотивированными, улучшают свою карму.»

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

                                                      Ужас одним словом!

                                                      Мне кажется, или все это напоминает «галеру»?
                                                  +1
                                                  Не пойму, при чем тут «универсалы». Замените это слово на «разработчик», и смысл статьи совершенно не изменится. Разработчик «всемогущий», разработчик «мастер» и прочее. Применимо абсолютно ко всем, а не только к отдельной категории разработчиков
                                                    0

                                                    Универсалы, это члены команды, занимающие в ней особое место. Вы правы, можно расписать эти типы и про аналитиков, и про разработчиков, и про тестировщиков. Цель данной статьи, попытаться раскрыть понятие универсалов, их категоризировать и показать их слабые и сильные стороны, описать возможные проблемы и предложить к обсуждению возможные варианты решений.

                                                    0

                                                    Типичная идея от "универсала" — это идея сервиса, который позволяет лежать перед телевизором на диване, вслух комментировать контент, иногда "угадывать", и очень иногда получать за это шмоньки.


                                                    Вот сидит такой Сергей Юрич Беляков в Таганроге с пивом перед телевизором, и тут, как обычно, реклама Лексус: чуть смуглая сексипозитивная азиаточка в белье, и роскошные интерьеры, и машина–огнемёт все дела. И отхлебнув очередной от пивчанского, Сергей Юрич, вспомнив встретившуюся утром спину дворничихи–узбечки, на привычной громкости говорит телевизору: 


                                                    — Алиса, ты передай там в "говнобанк–говноидей–точкаком", что если в этом вашем сраном суперлюксовом лексусе, в рекламе, автомобиль будет облизывать не потомок тамерлана, а белокурая дочь викингов — богиня снежной красоты, то продажи нах вырастут нах вашпемана, че они тупят, Алис, скажи. 


                                                    Делает следующий глоток пива. И ну его дальше телевизор смотреть. И проходит джва года. И приходит Белякову письмо: 


                                                    Уважаемый Сергей Юрич, трали–вали, мы из компании "говнобанк–говноидей–лтд". Лясем–трясем, так карты на стол уложились, вас таких расистов–Беляковых не одна тыща набралась. Да и лексус зачем–то акцентированно перекрасился в рекламе в кипельно–нордическую сторону, через полгода после того, как вы ляпнули что–то такое при её просмотре. И, черт побери, знаете, и продажи потом выросли ого–ого, как вы и говорили. И мы наняли юристов, кстати спасибо за ваши 500₽ доната в прошлом году. И юристы были так хороши, что заставили лексус поделиться дополученной от перекраса рекламы прибылью с говнобанком-говноидей, все дела. Вот ваши стодолларов, селяви, ждём новых прекрасных идей, аривидерчи, чао, бамбино. 


                                                    Внимание, знатоки, вопрос: А в обратную сторону это аналогично будет работать? Миллион Беляковых посоветует ерунду; на неё поведутся корпораты и перекрасят рекламу, и последняя явно приведёт к убыткам. Смогут ли корпораты отсудить у Беляковых по тридцатке? Спасибо за оффтоп

                                                      0
                                                      Очень черно-белое видение. «пользуюсь», «ресурсов» — вы себя слышите вообще? Я бы не хотел иметь в команде менеджера который «пользуется моим ресурсом».
                                                        +1
                                                        универсалы могут практически все делать одинаково хорошо
                                                        Разработчик-универсал это:
                                                        1) архитектор + (front- back- db-программист) + сисадмин(на 25% и более).
                                                        А не:
                                                        2) аналитик + разработчик + тестировщик + техпис + консультант пользователей +…
                                                        Примечание_1: не путаем отладку ПО с его тестированием.
                                                        Примечание_2: даже в рамках пп.1 невозможно одинакового, а главное глубокого знания всех областей.

                                                        Кстати:
                                                        Члены команды, работая над ошибками, становятся более мотивированными
                                                        очень интересные у Вас методы мотивации.
                                                          0
                                                          Тот о ком вы пишите называется еще Principal Developer.

                                                          Для затыкания дыр на короткий срок 3-6 месяцев компании обычно нанимают контракторов за 150-200 USD per hour, иначе начинают страдать текущие проекты.
                                                            0
                                                            Я хочу высказаться о вреде «узких» программистов.

                                                            По своей профессиональной деятельности, я как раз универсал.
                                                            Приходилось сталкиваться с веб-программистами, которые не могут себе настроить тестовый веб-сервер! Не могут определить правила по которым он будет работать… Элементарно сделать так, чтобы его приложение как-то работало. Возможно он должен был отдать на откуп неким другим «узким» специалистам настройку своего окружения… А теперь представте, что таких программистов у вас три, а это значит что при них должен быть минимум один человек который и будет только заниматься настройкой их «хотелок». И это не теория — это практика.
                                                            Еще пример. Надо как-то написать некую интеграцию ПО и сайта. А разработчик ПО недоступен. Кому отдать? веб-программисту? Он напишет скрипт, который будет запускаться через веб-сервер по крону. А как еще? Он по другому не умеет. Он не знает что есть еще shell («Это чё ваще? Фи, я таким не занимаюсь»).
                                                            Если отдать затыкающему дыру «универсалу», то ему надо: 1. Разобраться в коде, 2. Разобраться в модели данных, 3. Это повторить с другой стороны (изучить ПО), 4. Всё это успеть в сжатые строки (вы же в него верите, он быстрый и всё умеет).
                                                            А теперь представьте насколько должен быть человек обучаемым новому, понимать чужой код (это вообще фантастика).

                                                            Так что настоящий программист должен уметь практически всё с чем сталкивается, просто в одном он более всего умеет. Тогда его можно будет использовать как «узкого».
                                                              –1
                                                              Людмила Макарова, я менеджер разработки в УБРиР и треть моей команды – «универсалы»
                                                              Заметим, универсалы в кавычках.
                                                              Далее, агрегировав информацию об «универсалах» из статьи:
                                                              сложно заставить сделать простое дело. Легкие задачи задевают самолюбие всемогущих;
                                                              качество работы низкое, все получается с 2-3 раза;
                                                              постоянно сдвигают сроки, потому что на самом деле все оказывается не так-то и просто.
                                                              показывают средний результат из-за низкого уровня компетенций;
                                                              не могут решать сложные и абстрактные задачи;
                                                              нетерпимы к мнению других;
                                                              cтараются все сделать правильно, а это увеличивает сроки разработки.
                                                              Людмила, извините, только сейчас дошёл смысл статьи — Вы умница, я оценил!
                                                              Только сами не сломайтесь, успехов Вам!

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

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