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

Быть открытым и гибким для решений, на мой взгляд, имеет два аспекта. Первый, очевидно, связан с самим решением, например, с техническим решением и шагами, которые необходимы для достижения результата. Другой аспект связан с отношением людей, вовлеченных в работу над решением. Человек-деятель стремится сосредоточиться на первой стороне и упускает из виду второй. Это приводит к следующей триаде темных черт. Проблема с этими чертами заключается в том, что вы можете столкнуться с ними, даже если вы думаете, что достаточно умны, чтобы их избежать. Всё, конечно, ИМХО.

Влюбленность в решение


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

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

Как бы вы предотвратили увеличивающееся напряжение? Я думаю, следует помнить одно правило: людям не нравится, когда кто-то говорит им, что им нужно делать, и людям нравится работать над идеями, которые имеет отражение у них в душе. Так что вместо того, чтобы делиться решением, лучше стоит поделиться своим видением и отпустить своё решение. Люди найдут способ, которым они могут и хотят решить поставленную задачу.

Фокусировка на самом решении


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

Прежде всего, людям не нравятся перемены и они не любят делать что-то, что они не понимают и не согласны. В общем, это самая первая «стена», которую придётся сломать. К сожалению, простое представление фактов людям здесь не работает. Отношение, авторитет, время и способ говорить играют, может быть, ещё более важную роль в преодолении этой стены. Если с самого начала людям не нравится умная идея, они отрицают ее. Сложность в том, что чаще всего вы не услышите, что кто-то с вами не согласен. Вместо этого вас спросят, почему вы считаете эту идею важной. Если вы приметесь объяснить идею, вас, скорее всего, будут считать настойчивым и упёртым. Поэтому получается, что спорить не хотелось, но он возник сам собой, потому что вы начали объяснять важность решения. Кто-то спросил вас «Почему?», а означает «Я не согласен и не хочу», вы начали объяснять, потому что услышали «Почему?», но вы говорите, на самом деле, «Вы должны принять это, даже если вам не нравится». И причина такого странного диалога заключается в отрицании идеи в самом начале.

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

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

Перегрузка информацией


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

Например, вы планируете большие изменения в процессе разработки. Это включает изменения командах разработчиков и DevOps. Как деятельный человек, вы сделали оценку и подготовили «state of art» решение для этого. После этого вы хотите синхронизироваться с командами и представить им полное решение. Список вещей, которые следует сделать, включает в себя элементы, не относящиеся к конкретной команде, но ваша идея состоит в том, чтобы дать им общую видимость. Вместо этого вы, в конечном итоге, объясняете им, почему им это не нужно, но они видят этот пункт и зачем он, вообще, нужны. Вместо того, чтобы просто провести мозговой штурм идеи, вы заканчиваете разговор с напряжением и ощущением, что идея не поддерживается.

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

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

Заключение


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

Комментарии (14)


  1. Inanity
    13.01.2019 13:32
    +1

    Но другие люди не дают вам эти факты, им просто не нравится идея, или они не понимают ваших фактов, или они не готовы принять ваше решение в данный момент.
    Короче говоря, люди не хотят следовать вашему решению, не потому что оно неверно. Они просто не готовы принять его.
    -Почему? (Я не согласен и не хочу)
    -Вы должны принять это, даже если вам не нравится.
    Извините, но в инженерной среде это выглядит дико. Я могу понять, если такое случится в деятельности связанной с искусством, т.к. там субъективно всё. Но в инженерии такого подхода быть не может, это первое зло. Только факты, умение их находить, принимать и опровергать другими фактами. Как раз конструктивный спор разработчиков с таким подходом помогает определить наиболее оптимальное решение задачи.


    1. JustDont
      13.01.2019 14:35
      +2

      А в инженерной среде у вас, я так полагаю, работают не люди и не с людьми?

      «Такой подход» есть везде, где есть люди. Это есть у всех, включая и вас самих. Вопрос только в степени распространённости и выраженности. «Только фактами» вы, даже если искренне захотите и попробуете — решите далеко не всё (например, ставить табуляцию или пробел).


      1. Inanity
        13.01.2019 15:31

        Автор статьи явно об этом не говорил, но давайте отличать субъективное от объективного. Потому что табуляция с пробелами является субъективным восприятием, так же как и шрифт, цвет фона и т.д. Но технически никакой разницы нет, если только мы не пытаемся сэкономить < 2% объема репозитория из-за разницы табов и пробелов. И тем не менее есть много объективных причин и технических способов решать даже подобные субъективные проблемы. Толковая команда к этому естественно придёт, т.к. исход войны табов с пробелами — далеко не самоцель проекта.


        1. JustDont
          13.01.2019 15:39
          +3

          давайте отличать субъективное от объективного

          Давайте. И теперь я скажу, что подавляющее большинство проблем, которые решает отдельный взятый ИТ-работник умеренно высокого полёта — субъективные, выходящие на уровень «сделать так, чтоб людям понравилось» (начальнику ли, клиентам ли, владельцу бизнеса ли — не важно). Повышение доли голой объективщины (баги чинить и прочие «сетку тянуть») есть только на самом низком уровне, у тех людей, которых наняли не думать слишком глубоко, а руками делать то, что для них придумают другие.


        1. gecube
          13.01.2019 17:23
          +2

          Табы и пробелы — это жизненно важный вопрос. Как Вы не понимаете. Начать с того, что есть места, где это прям важно-важно (любые yaml, python код, makefile и сотни кейсов), вплоть до унификации кода (можно унифицировать насильно через линтеры). И точно речь не про экономию десятка байтов на каждом файле исходного кода
          Причем основной момент именно в том, чтобы все делали единым образом, а не сферический в вакууме диспут «что лучше»


          1. Inanity
            13.01.2019 17:44

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


      1. roscomtheend
        14.01.2019 14:43

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


        1. JustDont
          14.01.2019 14:51

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


          1. roscomtheend
            14.01.2019 16:19

            Тут тоже есть оценка — стоимость к профиту. Сичтать и считать на основании чего-то — разные подходы.


            1. JustDont
              14.01.2019 16:21

              Тут тоже есть оценка — стоимость к профиту.

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


    1. pavel_1406
      13.01.2019 17:50
      +2

      Извините, но в инженерной среде это выглядит дико.

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

      И взгляды на перечисленные критерии просто физически не могут быть одинаковыми, т.к. все люди разные. У каждого свой опыт, в соответствии со своим набором умений и требований к жизни. Кто-то видит главным — масштабируемость, кто-то надежность, кто-то дешевизну. Об этом и говорит автор, что «решение» это определенный набор комбинации критериев, которые не всегда могут быть одинаковые у членов коллектива. А всем не угодишь: основные ресурсы — время и деньги всегда ограничены.

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

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


      1. Inanity
        13.01.2019 18:25

        Сложно с вами не согласиться, но ограниченность ресурсов это первое, чем должна руководствоваться команда. Другое дело, что не всеми качествами проекта можно произвольно манипулировать. Можно некоторые вещи сделать на 20% надежнее за счёт денег, или на 5% технологичнее за счёт времени. Но, например, масштабируемость подкрутить иногда нельзя совсем, т.к. изменения слишком глобальны. Короче говоря, всё сложно. Deal with it.


        1. pavel_1406
          13.01.2019 18:35

          О чем и речь. А универсального решения как распорядиться ограниченными ресурсами нет. И если вы даже знаете объективно в силу опыта и умения прогнозировать какая в конкретном случае стратегия выигрышная — вы просто можете не суметь донести ее до коллектива.


  1. puyol_dev
    14.01.2019 20:12

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