Два мира или “инженерам есть, что сказать”. О различных типах сложных задач и процессах связанных с ними

    Я думаю руководители отделов IT департамента согласятся со мной, что иногда кажется, что мы находимся на границе двух миров, живущих по разным законам, в разных временных ритмах, а нам приходится жить в обоих этих мирах. И, если трансляцию “образа жизни” сверху вниз, от вышестоящих менеджеров до инженеров, мы, в силу своих должностных обязанностей, осуществляем регулярно, то вот в обратную сторону — увы…

    Поэтому этот пост о том, что я, как инженер, хочу сказать нашим дорогим менеджерам и тем, кто считает их “образ жизни” единственно верным. :)

    Планирование, диаграммы ганта, “следование процессу”, дисциплина, deadline, распорядок, “два раза не объясняю одно и тоже”, “не успел, значит плохо планировал”… — знакомые вещи? Это сущности и методы “мира менеджеров”. Понятно, что где-то больше, где-то меньше и вообще упрощение, но речь не об этом мире. Он безусловно важен. Его методы отлично работают во многих вещах. Но есть огромный пласт задач, где ничего из этого не работает, а работает совсем другое, подчас противоположное.

    Поясню свою мысль.

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

    Complex задача — это задача, состоящая из многих элементарных подзадач. Элементарных в том смысле, что результат известен, известны методы решения, количество ресурсов, которые они требуют и время на их выполнение. Сложность complex задачи заключается в том, что требуется, например, участие различных людей, специалистов, команд и их действия надо согласовывать, но каждое конкретное действие вполне понятно и предсказуемо. Хороший пример – строительство дома. И вот здесь отлично работают приемы “мира менеджеров”.

    Но когда мы говорим о difficult задаче, то это задача с неопределенным результатом, и эта неопределенность может быть вплоть до того, что непонятно, есть ли решение, а если есть, какое оно, сколько времени и ресурсов эта задача займет. Это исследование. В данном случае, речь не идет о создании термоядерного реактора, а о ежедневном в “мире инженера”.

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

    Конечно, «мир инженера» состоит не только из этого, есть здесь и complex составляющие, но это существенная его часть, или вы не совсем инженер.

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

    • инженеру нужно погрузиться в задачу. Он не может отвлекаться каждые 15 минут. Иногда, погружение может быть настолько всепоглощающим, что он может не спать или плохо спать, “страдать” задачей несколько дней или недель или месяцев. Это важное качество сильного инженера. Он не может успокоиться пока не решит. Ему нужно дать время, дать возможность сосредоточиться и, возможно, исключить на какое-то время из различных периодических процессов.
    • в данных условиях странно требовать от инженера, чтобы он строго жил по расписанию. И это понимают в НИИ (во всяком случае в том, где работал я), это понимают, например, на Физтехе – и там и там свободное посещение.
    • понятно, что слово “дисциплина” при решении задач такого типа здесь уже имеет другое значение. Это уже даже не дисциплина, а скорее страсть. Творческий процесс, мозговые штурмы, обсуждение, заинтересованность в результате – вот клей, заменяющий дисциплину при решении этого типа задач.
    • понятно, что все временные зависимости здесь так же существенно ослабевают, трудно вставить difficult задачу в строго регламентированный временной процесс
    • поощряется не то, как гладко (с соблюдением всех условностей и процедур) выполняется задача, а просто сам факт решения задачи. Слова, типа “вы задержались на 2 дня” здесь не должны применяться. Если сроки важны, то нужно просто определиться, в какой момент остановиться и не тратить больше ресурсов.
    • нельзя судить человека за то, что он не смог решить задачу. Даже у очень сильного специалиста ход мысли может пойти в др. сторону и он может потратить много лишнего времени. Во многом, решение подобных задач – это перебор вариантов, и не факт, что вы быстро выберете правильный.
    • если инженер застрял, нельзя оставлять его одного – нужна помощь или лидера или всей команды.

    Совсем другой мир, правда?

    Значит ли это, что совсем нельзя планировать? Нет не значит. Обычно, можно оценить вероятность выполнения и время, но это лишь вероятность и лишь оценка.

    Значит ли это, что в отделе должна царить анархия? Нет не значит. В отделе, конечно, должны соблюдаться процессы complex задач, которые есть в отделе и в которых участвует подразделение. И это задача руководителя суметь совместить эти два мира.

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

    Умение решать complex задачи более доступно. Здесь тоже важна склонность характера, но если эта склонность есть, то овладеть навыками не так сложно.

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

    Вот почему.

    • такой менеджер часто не понимает, а от того и не ценит людей, способных решать difficult задачи. А значит, у него не будет сильных инженеров.
    • менеджеру безусловно в общем случае приходится решать difficult задачи. Например, определяться с целями, или создавать работающие процессы. Это difficult задача. Беда в том, что менеджер может думать, что это просто, в силу того, что не видит глубины проблемы и создает цели и процессы “на лету”, но при детальном рассмотрении они не работают.

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

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

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

      +1
      нельзя судить человека за то, что он не смог решить задачу.

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

        0
        То, что вы описали — это банальная лень. У автора же речь о difficult задачах с неочевидными решениями, граничащими с research. Лично я усматриваю здесь очевидную разницу.
          0

          Т.е. боремся с Обломовщиной.

        +2

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


        Задача менеджеров — перевести эту difficult задачу в инженерные difficult задачи. Чем меньше менеджер способен комфортно работать с этими двумя неопределенностями, тем больше он пытается на своём уровне разбить все на компоненты и процедуры, выстроить дисциплину и жёсткие процессы. Удаётся не всегда.


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

          0
          Уверен что хорошему менеджеру нужно уметь решать difficult задачи тоже. Но что делать если не дано? Или должен быть еще один «менеджер» (работая сейчас в Европе, вижу что часто эту функцию выполяют архитекторы) или нужно уметь доверять и общаться с инженерами.
          0
          del
            +3
            По моим наблюдениями, высший менеджмент делится на 2 лагеря в зависимости от генезиса. Получившие гуманитарное образование, после курсов MBA начинают тяготеть ко всякой технократии и формализации типа бизнес-процессов, искусственного интеллекта, и проч. Вышедшие из технарей, наоборот — тяготеют исключительно к human-технологиям, считая, что «кадры решают все». Это закон маятника. А наиболее гениальный менеджер, это, наверное, тот, который смог совместить в нужной пропорции хьюман и техно.
              0
              Хороший комментарий :). Да, такое ощущение что в MBA (судя по тем с кем я общался) учат прежде всего хорошему тайм менеджменту, но в том то и штука что в случае исследований это плохо работает. Должны быть другие процессы, другая атмосфера,…
              Еще раз хочу сказать что это не значит что про время и деньги думать не надо. Конечно на уровне менеджмента это главная задача, но в мир инжеров это должно спускаться в другом виде.
                0
                На моем последнем месте работы все топы были гуманитарии — психологи, филологи, философы, и ни одного технаря, похоже, тенденция.
              +1

              Немного капитанский текст. Да, разумеется, есть задачи, в которых сложно спрогнозировать результат и/или сроки и/или возможные трудности — люди, которые этого не понимают, вряд ли могут чем-либо руководить, и ИТ тут не при чем — точно то же самое в любой другой области деятельности.


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


              Тут много что можно понаписать, но вот нового мало что можно сказать.

                +1
                Я написал этот текст не просто так. Это ответ на то что я вижу и видел в подходах коллег и следствие общения с ними. Ну вот не понимают они, что строительство дома и создание сетевой архитектуры с новыми (не создаваемыми раньше) решениями это разные вещи.
                Я понимаю что вот слова про «новые решения» пугают, но поверьте, это было не дорого и красиво.
                  +1

                  С одной стороны, я вас понимаю, а с другой — строительство дома — тоже ни разу не простой процесс, и там тоже много чего случается, что сложно прогнозируемо. Подрядчики банкротятся, администрация наезжает, еще что-нибудь. И грамотный менеджер это все решает, и сроки там тоже все время съезжают. И тут новая сетевая архитектура не сильно-то уникальна. И да, если это чистый R&D, где вообще плохо понятно, что делается — тогда да — а если это промышленная задача — там есть сроки и риски и управлением ими и все вот это. А чистый R&D должен вообще по-другому управляться, там обычно ограничиваются сроки и/или деньги.


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

                    +1
                    :)
                    Текст не о том какие мы хорошие а другие плохие. Текст про то что нужны разные подходы к разным задачам. Так же даются методы решать difficult задачи и пожелание менеджерам ценить людей способных решать эти задачи а не смотреть на них свысока.
                    Этим двум важным мирам нужно уметь ладить. Это как форма и содержание — и то и то важно
                +1
                — О, ты не спишь? Тут проектик есть, надо сдать с утра.
                — Погрузился, ть.
                  0
                  Я их буду называть английскими словами complex и difficult.

                  На языке родных осин это «сложный» (как антоним для «элементарный») и «трудный» (то есть требующий много труда).
                    +1
                    Просто слово сложный с русского именно так и переводится — complex/difficult.
                    Мы в этом слове не различаем эти нюансы. А английские термины отражают точно суть.
                    Но конечно термины это всего лишь термины.
                    Спасибо за комментарий.
                      +1
                      Рутинная работа грузчика в таких терминах «трудная» (требуется много труда), но в смысле, о котором говорит автор статьи, она complex, а не difficult.
                      +1
                      [оффтоп]
                      А чем термин «комплексная задача» хуже, чем «complex задача»?
                      А чем термин «сложная задача» хуже, чем «difficult задача»?
                      Очень неудобно читать. Постоянно «спотыкаешься» об эти слова.
                      [/оффтоп]

                      Здесь под термином «сложная задача» подразумевается некое исследование? Или это просто задача, срок выполнения которой сложно спрогнозировать, например, из-за отсутствия опыта решения таких задач?
                      В любом случае неплохо бы менеджеру со стороны инженера явно указать, что сроки могут уплыть, т.к. (подробное объяснение всех белых пятен). Но и в этом случае должна быть некая контрольная точка, в которой нужно определиться либо с уточнением сроков решения, либо с целесообразностью продолжения работы над задачей.
                        0
                        Здесь под термином «сложная задача» подразумевается некое исследование? Или это просто задача, срок выполнения которой сложно спрогнозировать, например, из-за отсутствия опыта решения таких задач?

                        Дак это одно и тоже в реальном мире: — эту задачу непонятно как решать и в какие сроки, а уж причина может быть любая — либо эту задачу никто не решал, или решил, но нам про это ничего не известно. Поэтому у нас нет известных хотябы примерно путей решения и оценок.
                        +2
                        Управление повседневной работой большого количества людей стало невозможно менеджерскими способами ни в какой виде. И качество работы может зависеть только от заинтересованности самого исполнителя. Проконтролировать со стороны это уже практически невозможно. Все что смогли выдумать это agile который просто постулирует что все члены команды работающей над проектом должны страстно желать сделать этот проект лучше.

                        На самом деле это касается не только инженеров, это касается всех работников. Даже самых простых кладовщиков или уборщиц. Если работник замотивирован выполнять некоторую работу то он справляется с ней лучше и сильно быстрее (в 2-3 раза) чем незамотивированный работник (если что это было проверено опытным путем еще в начале 20го века).

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

                          deadline, complex, difficult. Зачем? Вы же инженер, а не продавец или маркетолог.

                            0
                            В проектах нужно. Там все переплетается.

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

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