Не давайте тонуть проблемам процесса

    То, что имено проблемам процесса надо уделять максимальное внимание известно давным давно.
    К сожалению жизнь довольно сурова и очень часто мы сталкиваемся с ситуацией, когда найти выход из текущей ситуации в рамках правильного процесса просто не хватает времени. Надо резать здесь и сейчас, т.к. время не ждет.
    В последнее время стал замечать что очень многие люди не способны держать у себя в голове баланс между решением проблемы здесь и сейчас и решением ее в общем процессе. Т.е. иногда в разговорах люди говорят или или, что принципиально не верно. Да, иногда можно уступить высшим силам и заткнуть проблему здесь и сейчас, но главное в такой ситуации добиться решения и системном рассмотрении данной ситуации. Без этого исполнитель, который по своей доброте душевной дурости согласился заткнуть проблему руками, рискует превратиться в регулярного дыркозатыкателя. Если вас пробуют уговорить на такое, всегда держите в голове, что при забывчивом руководстве, это может превратиться в систему. Оно вам надо?
    Посему главное, это довести решение проблемы в общем процессе до логического завершения. И надо это в первую очередь исполнителю, т.к. в противном случае его по любому назначат крайним. Надо или выбить время на решение проблемы, или получить как можно более формальное подтверждение от руководства что данная проблема осознана и с ее риском будут работать высшие сферы. А до момента ее решения, так же формально зарегать регулярные оверхеды в рабочем времени на решение данной проблемы. Как показывает опыт наличие регулярного оверхеда вводит многих менеджеров в неблагодушное состояние и они пытаются его куда-то убрать. Но тут они сами себя держат, т.к. пока решения проблемы нету, риск остается и никуда ты этот оверхед не уберешь.
    Дико ненавижу недолюбливаю людей которые не понимают этой логики. Что если они соглашаются быть затычкой, то они на самом деле закладывают в общий процесс бомбу замедленного действия. При этом у данных индивидов есть привычка списывать потом катастрофу на их манагера, т.к. типа я ему сказал, а он не обратил внимания. Эгоцентризм данной позиции ужасен. Во первых надо все же понимать, что нормальный манагер, человек вменяемый и будучи ознакомлен с фактами предпримет усилия для решения проблемы. Ситуацию невменяемого манагера не берем, т.к. от них сразу надо увольняться, т.к. в Росии в ИТ не платят столько, чтобы терпеть манагера идиота. Важно донести критичность проблемы. Да возможно через жесткий разговор или письмо, но тем не менее надо. Т.к. один раз подойдя и сказав хнык, вы не донесли значимость проблемы. Не надо быть эгоцентриком считающим что каждое ваше слово услышано. Во первых сами потом пожалеете, во вторых это просто неверно. Тут конечно может быть другая крайность когда человек начнет делать из мухи слона и скандалить по любому поводу, но это уже вопрос к компетенции вас самих. Надо все же уметь грамотно видеть проблемы в собственной зоне ответственности. Если данное условие не выполнено, то все вышесказанное не имеет смысла.

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

    Средняя зарплата в IT

    120 000 ₽/мес.
    Средняя зарплата по всем IT-специализациям на основании 6 146 анкет, за 1-ое пол. 2021 года Узнать свою зарплату
    Реклама
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее

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

      0
      Позвольте добавить еще пару моментов:
        0
        … собственно, моменты, после не очень уместной привычки нажимать Ctrl-Enter для перевода строки в IM:
        1) Дружба дружбой, а служба службой — есть компания с определенным процессом и за выполнение работы по этому процессу вам платят деньги. В то же время на работе есть корефаны (и просто приятные люди). Так вот чем меньше задач будет решено «по-корефански» без процесса, тем крепче будет дружба и меньше будет болеть нижняя голова.
        2) В правиле 1 не стоит исходить на гуано — на каждый чих требовать формального письма, запроса в трекере и т.д. Практически у любого работника клавиатуры (если только не он-лайн занятость типа саппорта) есть время на мелкие вопросы.
        3) Все решения по процессу, сделанные по телефону / лично / через IM etc. должны быть зафиксированы в месте, где именно вам будет легче всего эти изменения найти (у меня это почта). Можно написать письмо самому себе. Возможно, в первый раз будет немного неудобно ставить в копию такого письма начальника, но это только в первый раз ;)
          0
          Я писал не про процесс в самой компании, как постановка задач и прочее, а про то как та или иная функциональность укладывается в общий процесс разработки.

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

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

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