Индульгенция — как избавиться от долгов по задачам

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

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

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

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

    Какие бывают долги


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

    Долги бывают официальные и неофициальные. Разница иногда в мелочах, но отношение у руководителей и кредиторов к статусу долга бывает сильно разное.

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

    Неофициальные – полученные по неформальным каналам. Хотя, иногда эти каналы сильнее и значимее официальных – зависит от кредитора. Коллега попросил помочь, или пользователь, или начальник, или команда проекта – кто угодно. Но долг нигде не записан, расписки нет.

    Чем плохи долги?


    Тем, что висят над душой. Ну, у меня так, по крайней мере. Особенно раздражают неформальные.

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

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

    У долгов есть такая странность – чем дольше он висит, тем сложнее приступить к его реализации. Задачу, поставленную только что, взять и сделать намного проще. А просрочку… Не знаю… Вроде как стрёмно немного, что ли. Как кружку офисную помыть от черного чайно-кофейного нагара, копившегося полгода. Ведь я испытывал трудности, в том числе душевные, когда эта задача перешла в разряд просроченных. Я эти трудности пережил, понес некоторые эмоциональные потери, научился жить с этим долгом, и что, вот так вдруг, возьму и избавлюсь от него? А все страдания были зря?

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

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

    НеИндульгенция


    Упомяну кратко, т.к. статья о другом – да, долги можно просто взять и сделать. Но это другая тема, не буду мешать всё в кучу. Моя задача – списать или отсрочить.

    Смена системы учета задач


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

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

    Делаю ход конем – разрабатываю систему управления задачами. Простенькую, за пару дней, «под себя». Через некоторое время находятся люди, которые выдвигают требования, как эту систему сделать хоть немного «для людей» — немного сопротивляюсь, но вношу доработки. И так, потихоньку, помаленьку, люди начинают к системе привыкать.

    Пришел очередной пешеход, или «звонилка» — отправляю в систему. Вроде, не буду решать задачу, пока не запишешь. А что со старыми задачами? Забылись, почти все. Люди новые-то задачи внести не могут, а тут еще старые. Тем более, что неформализованные задачи и найти-то сложно – в почте бардак, в столе – тем более. Я сам вносить старые задачи, естественно, не буду – у меня новые уже в очереди стоят.

    Долги полностью списываются, причем – под благовидным предлогом. Это же развитие, как никак.

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

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

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

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

    Однажды я таким способом вывел весь ИТ-отдел из-под штрафной системы, я про нее рассказывал – охватывала всё предприятие, обязывала исполнять поручения в срок, иначе отнимут кусок зарплаты. Хоть я ее и разработал, но ведь не для себя, и штрафы придумал не я. А программисты штрафов боялись.

    Тогда я создал в рамках той же КИС очередную систему управления задачами, конкретно для ИТ-отдела. Даже метаданные назвал безапелляционно – «ЗаявкаВИТОтдел», чтоб никому неповадно было присоседиться. Обосновал легко – поручения со штрафами годятся для бухгалтеров и менеджеров, но совсем плохи для программистов. А переделывать нельзя, вы что – у нас вся компания в этой каше варится, вдруг сломаем. Прокатило. Даже долги почти все списали – закрыли все поручения в старой системе с формулировкой «Перенесите задачу в новое место».

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

    Реструктуризация


    Отличие реструктуризации в том, что она почти всегда находится за пределами влияния – просто приходит сверху. Важно уметь ее использовать.

    Например, я работал на предприятии, которое меняло штатную структуру примерно раз в год. Изменения почти всегда были масштабными, а главное. Менялись не только названия и составы отделов, но и функции. То укрупнялись, то измельчались, то подразделения превращались в дивизионы, то дивизионы – в бизнес-единицы, и т.д.

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

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

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

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

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

    Интересна формулировка, с которой прибегают – «сними с меня задачи». Я объясняю – нельзя просто снять, надо на кого-то переставить. А человеку, естественно, по фигу – ну кто будет заморачиваться вопросом «на кого повесят мои долги»? Я говорю – иди, договорись с кредиторами, у них есть возможность переставить или отозвать задачу. Нет, ни в какую – побыстрее бы снять. Делать нечего – под админскими правами удаляю задачу. Если приходит кредитор ругаться – перенаправляю на бывшего должника.

    Кроссфункциональные проекты


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

    Вот сидит у меня программист, у него долг. Передо мной, перед заказчиками, перед командой. На носу Новый Год, и его затягивают в подготовку к корпоративу – петь и плясать будет. Я, вроде как, не имею права отказать, и нехотя соглашаюсь – разумеется, с условием, что всё это не будет отвлекать от работы. Ага, щас.

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

    Что делать? Из «проекта» уже не вытащишь – у него одна из главных ролей. Приходится списывать долги с него, и переносить их на «созаемщиков» — программистов, или на «поручителя» — себя. Ненавижу, блин, корпоративы.

    Смена начальника


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

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

    Перемещение кредитора


    Аналогично тому, как перемещаются должники при реструктуризации. Только сбегать надо уже мне – мол, ты теперь в новом подразделении, с новой должностью, целями, обязанностями. Чего нам с тобой старые задачи выполнять? Они ведь были созданы в уже несуществующем контексте.

    Как правило, соглашаются, потому что долго-то – штука двусторонняя. Я должен сделать, он должен проверить, принять, внедрить. Ему оно надо?

    Увольнение кредитора


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

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

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

    Обмен долгов


    Этим методом я пользовался часто. Суть проста – не принимаешь от кредитора новых задач, пока не закроешь старые. Обосновать можно по-разному. Например, сказать «блин, я тебе и так должен, не могу больше увеличивать обязательства». А можно придумать некое правило, вроде «не брать от одного отдела больше 10 задач одновременно». Логика понятна – любой дурак может устроить DDoS-атаку на ИТ-отдел, завалив его задачами, но при этом лишив автоматизации все остальные отделы. А так нельзя.

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

    Поручение от Большого Босса


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

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

    Намного лучше – самому предложить Большому Боссу решение какой-нибудь задачи. Возможно, это даже будет проект. Желательно, чтобы он был туманным, непонятным, с нечеткими границами и без критериев оценки. Вроде как «я попробую улучшить вот это».

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

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

    Новый проект по старой теме


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

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

    Вот эта фраза – «по-другому» — часто действует на людей магически. Чтобы в этом убедиться, посмотрите на историю любых реформ и изменений в России. Все давно знают, что «хотели как лучше, а получилось, как всегда», но всё равно верят, что будет «по-другому».

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

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

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

    Увольнение


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

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

    Хотя, каждый решает для себя сам, конечно.
    Поддержать автора
    Поделиться публикацией

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

      +9

      Это какой-то архаичный подход к управлению задачами.


      1. Зачем для учёта задач писать систему управления задачами? Да еще её и менять потом. Чем не устраивает Jira и её аналоги?


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


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



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

        0

        Жира — действительно стандарт де-факто, но она является универсальным решением. А у любого универсального есть две проблемы:


        1. one size does not fit all
        2. и как следствие — необходимость затачивать процесс под каждую бизнес-единицу. Само по себе это не плохо и не хорошо — это данность. Но скорость разработки этих процессов и их внедрения может оставлять желать лучшего. Тем более, что обычно на JIRA выделяется человек по остаточному принципу.

        Мне это напоминает историю внедрения SAP во многих компаниях. Компании делятся на две категории: которые после этого скатились в "дно" и умерли, и те — которые приспособились. У меня есть большое подозрение, что вторые вместо попыток реализовать свои процессы в SAP шли от обратного — меняли свои процессы ПОД SAP, чтобы засунуть их в его прокрустово ложе. Эффективность? Не, не слышал.

        +2

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

          0

          О каком успехе речь? Если о повышении в должности, то зачем повышать человека, который просто хочет делать свою работу хорошо? О повышении зп вдвое? Аналогично.


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

            0
            Мне кажется, вы зря противопоставляете, называя одних хорошими, а других — личностями. Я за то, чтобы быть хорошим человеком, но жонглировать софт-скиллами и обходить систему. В конце концов, система — не всегда хорошо.
              0

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


              В конце концов, система — не всегда хорошо.

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

            +2

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


            Кстати,


            что поставлены недавно, а всякая тухлая просрочка, «пожелание записано» и т.п.

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

              0
              Единственное что вижу ты статье это.
              Накопить задачи, забить болт на них, кто-то про них вспомнил. Искать оправдания.
                0

                Не всегда задачи копятся потому что исполнитель чудак на букву М. Есть объективные факторы, когда реально проблем больше, чем возможностей их решать, но тогда должна быть приоритизация. Откидываем ненужные задачи на дно беклога. И, да, если "ненужные" задачи вообще не фиксировать — это тоже не решение, т.к. зачастую бывает (по крайней мере если работаешь в поддержке или около нее), что несколько разных не связанных людей приходят с одной и той же проблематикой. Если не фиксировать, то потом даже не понять, что проблема более общая, чем кажется изначально.

                0
                Я говорю – иди, договорись с кредиторами, у них есть возможность переставить или отозвать задачу. Нет, ни в какую – побыстрее бы снять. Делать нечего – под админскими правами удаляю задачу.

                Интересные у вас бизнес-процессы… А кредиторы на такие ваши действия как реагируют?
                  0
                  а в двух следующих предложениях написано
                  0
                  Я со временем научился не браться сразу за задачу, через пол дня/день оказывается задача была не нужна или уже не нужна. Чтобы не забыть, сразу все записываю в task manager. Это касается не только работы, все записываю. Личные задачи в календарь телефона. Пробовал применять принцип GTD, из всего прижилось только правило 2х минут. Установил, чтобы чувствовать себя спокойней лучше о задачах меньше думать, придет время сделать и желательно сразу забыть. Иначе вся чушь висит в голове неделями.
                    0
                    Армейский принцип ПВО. Погоди Выполнять, Отменят.

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

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