company_banner

Осмысленность работы и эффективность

    Дмитрий Симонов, CTO и создатель канала «Техдирские заметки» решил по-осеннему да по-есенински удариться в глубокую философию взаимоотношений с командой. Как достигнуть истинной эффективности команды?




    Попробуем свести проблему к четырём базисных утверждениям. И, чур, не пугаться формулировок.


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


    2. Чтобы придать смысл деятельности, можно поставить ей цель. Если же не знать смысла деятельности и не ставить цель, любые переконфигурирования деятельности будут непонятны и, как следствие, неэффективны. Пример, старый бородатый анекдот «о перестановке столов в офисе по фэншую в разгар кризиса и перестановки кроватей в борделе 100 лет назад в этом же помещении». Например, можно бесконечно допиливать сферического коня в вакууме, если нет цели или смысла, очерченного сроками и бюджетом. Этот сферической конь никогда не поедет в продакшн. Возможна ситуация, что часть команды это как раз и устраивает — когда процесс важнее результата, так как процесс стабилен и даёт ощутимые «ништяки» в виде зарплаты, бонусов и премий. А вот допиленный конь, то есть завершённый проект вносит в жизнь команды кафкианскую неопределённость: «А что дальше?»


    Ещё более бородатый анекдот

    Молодой адвокат прибегает к своему отцу – старому адвокату и радостно говорит:
    – Отец! Я выиграл дело, которое ты вел 20 лет!
    Отец ему отвечает:
    – Дурак ты, сынок! Благодаря этому делу я вас 20 лет кормил...


    3. Каждого исполнителя нанятой команды нужно «знать в лицо»: понимать обстоятельства его личной жизни (ради чего он вообще пошёл на работу), а также его сильные стороны в профессиональном плане (какую ценность он привносит на работе). Например, если у сотрудника ипотека, то никакие стимулы кроме материальных, его скорее всего не интересуют. И если он классный девопс, использовать его в качестве разработчика веб-интерфейсов вообще не в тему будет.


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


    Получить эффективность команды можно только выменяв её на смысл их деятельности. Нет смысла, не будет и эффективности.


    А как вы достигаете эффективности команды?

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

    А как вы достигаете эффективности команды?

    • 37,2%Зарплата19
    • 13,7%Сложность проекта, как вызов7
    • 5,9%Грандиозность масштабность проекта3
    • 5,9%Свежий смузи, кофе и булочки в переговорной3
    • 21,6%Премии по результатам11
    • 15,7%Другое (в комментариях)8
    Southbridge
    Обеспечиваем стабильную работу highload-проектов

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

      0
      Я бы добавил еще один пункт, хорошо мотивирующий — премии по результатам.
        –2
        Готово. )
        +1
        1. Смысл всякой деятельности лежит вне её пределов

        Это хорошо сказано, но пример все портит. Потому что, предположим, 9999 не нужно никому, команда просто привыкла хорошо писать код. Что делать? «В следующий раз пишите хуже»? Будет ли хуже=быстрее? А если и быстрее было ни к чему?

        По мне, хороший пример: разработкой движет не прибыль от программного продукта, а привлечение инвестора. Или сокрытие основного вида деятельности — типа как «Компания по разработке 1С решений» имеет налоговые льготы. А основная деятельность — заправка картриджей и установка винды (но по бумагам — это «сопровождение инфраструктуры 1С»).

        2. Чтобы придать смысл деятельности, можно поставить ей цель.

        Но дальше по тексту написано, что у команды уже есть цель. Вне пределов, так сказать.

        3. Каждого исполнителя нанятой команды нужно «знать в лицо»

        Полная чушь.
        Предположим, у разраба А есть потребность в устройстве ребенка в детсад, а у разраба Б — в размещении проекта в Azure.
        Маленькая компания может влезть в личную жизнь всех разрабов (было бы желание), но дать-то сможет только деньги.
        Большая, очевидно, всех в лицо не узнает никогда. Но, в принципе, может предложить и корпоративный детсад, и участие в проекте на Azure.
          0

          Вот вам реальное приложение этого примера.
          Есть деталь, на детали есть отверстие, которое вытаскивает автомат под руководством оператора. На чертеже указано, что размер — 30 ±0.005мм. Это довольно жёсткий допуск. Оператор вынужден измерять каждую деталь и вносить поправку на износ инструмента. Если не не внести поправку два раза, из-за износа отверстие окажется меньше, чем допустимо. Приходит технолог, смотрит на это всё, уходит, возвращается с новым чертежом, выяснив, что такой жёсткий допуск — ошибка, для функционирования детали достаточно допуска ±0.012мм. Оператор теперь может внести поправку заранее с запасом и четыре раза не вносить её, экономя как свое время (которое может тратить на что-то ещё), так и время простоя автомата (потому что поправки во время работы не вносятся).
          Это не значит, что детали стали "хуже", это значит, что оператор перестал делать их точнее, чем нужно, тратя на это время. При этом, естественно, критерий качества результата обязан быть адекватным, а не от балды.

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

            Но автор внес поправки в текст и теперь пример выглядит еще глупее:

            Смысл всякой деятельности лежит вне её пределов

            надо разобраться, кто главный потребитель такой стабильности и насколько он ей доволен

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

            Вывод: смысл примера автора лежит вне пределов формулировки теоретического посыла и разобраться в причине он не может.
            0
            Большая, очевидно, всех в лицо не узнает никогда. Но, в принципе, может предложить и корпоративный детсад, и участие в проекте на Azure.

            Касательно Azure, как правило, наоборот.

            В маленькой могут сказать, мол, ок, раз твой азур решит наши проблемы, то давай, собери РоС на free tier или триальных кредитах, потом глянем, и если тема хорошая, то заведем и проплатим акк с личной карты фаундера)

            В большой, если азур не предусмотрен немногочисленной группой людей, имеющей монополию думать и решать, то никто заводить аккаунт в азур, подписывать NDA с майкрософтом, и создавать и утверждать политики безопасности по работе с азуром не будет ради перспективного девелопера, который хочет и видит в этом ценность. Максимум, скажут, на +$250 к зп, и на выходных тебе никто баловаться азуром не запрещает
              0
              Не стоит воспринимать пример так буквально.

              К тому же, описанный вами случай не совсем подходит под
              понимать обстоятельства его личной жизни (ради чего он вообще пошёл на работу)


              То есть, если разраб имеет вИдение и может обосновать необходимость, то это не подпадает под «личную жизнь» и «узнать в лицо», это его хард-скил.

              А вот в качестве «узнать в лицо» это что-то, типа хочу попробовать прыгнуть с парашюта и реализовать проект в Azure.

              (Но касательно хард-скилов, я считаю, что все примерно наоборот в больших и маленьких компаниях.)
              0
              предположим, 9999 не нужно никому, команда просто привыкла хорошо писать код. Что делать?


              Передать задачу другой более дешевой команде, например. А для рок-звёзд найти более подходящую задачу. Сова должна придумывать новые методики управления!
                0
                Вот. Объявить выговор, требовать объяснительную, уволить и нанять кучу вайтишников.

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

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

                А что если...
                основным потребителем оказывается сама команда? То есть, не хочет писать хуже, чтоб легче было поддерживать.
                Или руководитель компании? «Просто не терплю говнокод.»
                Или регулятор? «Я, как клиент, хотел бы подешевле, если у регулятора печать поставите, то мне вообще аптайм не нужен.» (Обычно, связано с покупкой/доработкой ПО, «согласно ГОСТа» для получения сертификата соответствия.)

                Есть ли тут вообще что выяснять? Есть ли хоть одна компания, которой такие кейсы не очевидны (клиент, который платит, не является заказчиком определенной фичи, но без нее не обойтись)? Детский сад.
              0

              Вы это кому пишите? PM'ам или линейному персоналу? Линейному персоналу бизнес-задачи могут быть интересны, но в область профессиональных интересов не входят. А вот повышение личной (и команды) продуктивности — входит.


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

                0
                Что есть эффективность?
                Не могли бы привести определение.
                Неясно, о чем разговор.

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

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