У любого сотрудника есть долги. Как правило, чем выше должность, тем больше этот багаж. Речь, конечно, не о долгах по кредитам, а о невыполненных задачах, обязательствах, проектах, обещаниях и т.д.
Некоторые даже считают, что чем выше долги, тем лучше. Как-то встречал в вакансии Студии Артемия Лебедева такую фразу (не дословно) – не стоит к нам приходить, если вы можете передать дела на старом месте меньше, чем за полгода. Вроде как, большие долги – это повод для гордости.
Мне такое, к сожалению, не подходит. Я долги не люблю. И достаточно давно заприметил несколько методов, позволяющих от них либо избавляться, либо откладывать выплаты без накопления процентов.
Несколько лет испытывал методы сам, и наблюдал, как подобную практику нарабатывают другие – осознанно, или неосознанно. Общее название – Индульгенция.
Какие бывают долги
В первую очередь – нерешенные задачи. Не те, что поставлены недавно, а всякая тухлая просрочка, «пожелание записано» и т.п. Во вторую – цели и показатели, к которым я, по разным причинам, вдруг должен стремиться. В третью – буксующие проекты, в которые когда-то ввязался, или ввязали, но по разным причинам они никак не могут закончиться.
Долги бывают официальные и неофициальные. Разница иногда в мелочах, но отношение у руководителей и кредиторов к статусу долга бывает сильно разное.
Официальные – это обретенные, так сказать, по официальным каналам. Служебная записка, внесенная в систему задача, обращение, поручение, вписывание вашей фамилии в устав проекта, автограф под листом ознакомления с системой мотивации и т.д.
Неофициальные – полученные по неформальным каналам. Хотя, иногда эти каналы сильнее и значимее официальных – зависит от кредитора. Коллега попросил помочь, или пользователь, или начальник, или команда проекта – кто угодно. Но долг нигде не записан, расписки нет.
Чем плохи долги?
Тем, что висят над душой. Ну, у меня так, по крайней мере. Особенно раздражают неформальные.
С формальными, как правило, всё проще – там есть процесс, этапы, сроки, контроль, штрафные санкции, изменение приоритетов. Например, начальник, видя, что у меня протухшая задача, может поднять ее приоритет до максимума, чтобы самому не обрести долг. А может, собака такая, держать эту задачу в запасе, чтобы тыкать меня в нее носом.
Неформальные хуже тем, что у них нет рамок и правил. Вот пообещал я человеку, что сделаю какую-то доработку, или посмотрю его код, а срок, естественно, не назвал. А он не спросил – ведь по-человечески попросил, а не поручение поставил. А у меня, кроме его неформальной задачи, полно формальных, за которые я стопудово могу отхватить. Его задача будет болтаться всегда в конце, пока меня не замучает совесть.
У долгов есть такая странность – чем дольше он висит, тем сложнее приступить к его реализации. Задачу, поставленную только что, взять и сделать намного проще. А просрочку… Не знаю… Вроде как стрёмно немного, что ли. Как кружку офисную помыть от черного чайно-кофейного нагара, копившегося полгода. Ведь я испытывал трудности, в том числе душевные, когда эта задача перешла в разряд просроченных. Я эти трудности пережил, понес некоторые эмоциональные потери, научился жить с этим долгом, и что, вот так вдруг, возьму и избавлюсь от него? А все страдания были зря?
Резюмируя, главная проблема долгов, на мой взгляд – душевные переживания от их наличия. Будто какой-то потенциал, камень висит, который оттягивает часть энергии и не дает эффективно работать.
Бывает, даже с людьми неудобно разговаривать. Вот надо мне что-то от Васи, начальника снабжения – у меня проект, и нужна его консультация, поддержка или реальная помощь. А я Васе должен задачу, причем – неформально. Я, скорее всего, к Васе не пойду. Максимум напишу электронное письмо, потому что стыдно в глаза смотреть.
НеИндульгенция
Упомяну кратко, т.к. статья о другом – да, долги можно просто взять и сделать. Но это другая тема, не буду мешать всё в кучу. Моя задача – списать или отсрочить.
Смена системы учета задач
Это – мой любимый способ, я его применял несколько раз, даже в рамках одного предприятия. Любимый потому, что я, как программист или руководитель программистов, мог его реализовать полностью самостоятельно, даже не спрашивая ничьего разрешения.
Итак, есть у нас, например, задачи в неформализованном виде – письма, звонки, бумажки, служебные записки и т.д. Мало того, что работать с этим ворохом неудобно, так еще и долги копятся, как Вавилонская башня – управлять-то задачами невозможно.
Делаю ход конем – разрабатываю систему управления задачами. Простенькую, за пару дней, «под себя». Через некоторое время находятся люди, которые выдвигают требования, как эту систему сделать хоть немного «для людей» — немного сопротивляюсь, но вношу доработки. И так, потихоньку, помаленьку, люди начинают к системе привыкать.
Пришел очередной пешеход, или «звонилка» — отправляю в систему. Вроде, не буду решать задачу, пока не запишешь. А что со старыми задачами? Забылись, почти все. Люди новые-то задачи внести не могут, а тут еще старые. Тем более, что неформализованные задачи и найти-то сложно – в почте бардак, в столе – тем более. Я сам вносить старые задачи, естественно, не буду – у меня новые уже в очереди стоят.
Долги полностью списываются, причем – под благовидным предлогом. Это же развитие, как никак.
Но в новой системе долги снова накопились. Подождав немного, пока станет невыносимо стыдно за них, я начинаю разработку новой системы. Точнее, система-то остается старой – это КИС предприятия, но я пишу новую логику, на новых метаданных, с новыми процессами.
Обосновать не проблема. Я тут почитал книжку, я тут послушал семинар, я тут посмотрел практику эффективных команд, я тут подумал, я тут прикинул, я тут заметил – с любой из этих фраз можно начинать разработку новой системы. Она, конечно, будет лучше прежней.
Обосновать, почему нельзя модифицировать старую систему, для программиста не составит труда – конечно, если обосновать надо не программистам, а обычным пользователям, даже наделенным властью. Банально – деньги. Разработка системы управления задачами с нуля стоит дешевле, чем модификация существующей. Ведь в старой уже куча задач, всякие там вспомогательные поля, таблицы, рассчитанные на старый процесс. Придется городить сложный огород по переносу, конвертации данных, которые в процессе можно еще и потерять.
Намного проще, опять же, за пару дней сделать новую систему. И снова не переносить туда данные, потому что метаданные не совпадают, а на конвертацию надо много времени тратить. И опять никому неохота переносить старые задачи. А мне – тем более.
Однажды я таким способом вывел весь ИТ-отдел из-под штрафной системы, я про нее рассказывал – охватывала всё предприятие, обязывала исполнять поручения в срок, иначе отнимут кусок зарплаты. Хоть я ее и разработал, но ведь не для себя, и штрафы придумал не я. А программисты штрафов боялись.
Тогда я создал в рамках той же КИС очередную систему управления задачами, конкретно для ИТ-отдела. Даже метаданные назвал безапелляционно – «ЗаявкаВИТОтдел», чтоб никому неповадно было присоседиться. Обосновал легко – поручения со штрафами годятся для бухгалтеров и менеджеров, но совсем плохи для программистов. А переделывать нельзя, вы что – у нас вся компания в этой каше варится, вдруг сломаем. Прокатило. Даже долги почти все списали – закрыли все поручения в старой системе с формулировкой «Перенесите задачу в новое место».
Впоследствии я наблюдал странный эффект – даже когда система задач полностью «для себя», и записываю туда только я, и вдруг решаю переехать на другую – ни фига неохота переносить задачи. Так и остаются гнить в старой.
Реструктуризация
Отличие реструктуризации в том, что она почти всегда находится за пределами влияния – просто приходит сверху. Важно уметь ее использовать.
Например, я работал на предприятии, которое меняло штатную структуру примерно раз в год. Изменения почти всегда были масштабными, а главное. Менялись не только названия и составы отделов, но и функции. То укрупнялись, то измельчались, то подразделения превращались в дивизионы, то дивизионы – в бизнес-единицы, и т.д.
Главное перед такой трансформацией – обезличить задачи, сделать их не своими, а задачами подразделения. Вчера я был должен человеку что-то сделать, сегодня ему должен отдел, завтра – пф… Никто не должен. Нет отдела больше. Есть бизнес-единица, а она – ни фига не отдел, в ней собраны несколько разных функций, у нее другие цели, она вообще хорзасчетная, а не центр затрат.
Что интересно – кредитор-то ведь тоже под реструктуризацию попадет. И, скорее всего, сам забудет про выданные задачи. Получается взаимная индульгенция.
Если задачи обезличить нельзя, то надо выбрать подходящий момент, чтобы их списать – те самые несколько дней неразберихи, когда никому нет дела до старых долгов, лишь бы как-то устаканилась новая окружающая среда. Подойти, по-человечески поговорить, и простить друг другу всю эту просрочку.
Сам я этим методом не пользовался, т.к., к сожалению, реструктуризация ИТ-отдела коснулась лишь однажды – админа забрали в подчинение к безопасникам. Правда, ненадолго, потом вернули, когда узнали, что админом еще и управлять надо.
Но как пользуются другие – видел многократно, и даже помогал списывать долги в техническом плане. Прибегает какой-нибудь снабженец, и говорит, что он больше не снабженец. Хотя все знают, что он по-прежнему снабженец. Просто раньше он сидел в отделе снабжения, а теперь – в бизнес-единице из пяти человек, среди которых один продавец, один конструктор, один снабженец, один руководитель и один инженер. Заниматься будем тем же, только заказчик другой – не вся компания, а один продавец.
Интересна формулировка, с которой прибегают – «сними с меня задачи». Я объясняю – нельзя просто снять, надо на кого-то переставить. А человеку, естественно, по фигу – ну кто будет заморачиваться вопросом «на кого повесят мои долги»? Я говорю – иди, договорись с кредиторами, у них есть возможность переставить или отозвать задачу. Нет, ни в какую – побыстрее бы снять. Делать нечего – под админскими правами удаляю задачу. Если приходит кредитор ругаться – перенаправляю на бывшего должника.
Кроссфункциональные проекты
Кроссфункциональные – это когда проект выполняется людьми из разных отделов. Чего греха таить, обычно это – какая-нибудь дурь, вроде постановки мюзикла, внутреннего обучения и прочей самодеятельности. Как привыкли люди со школы и института, что выступление за факультет дает поблажку во время сессии, так и тащат этот шаблон на работу.
Вот сидит у меня программист, у него долг. Передо мной, перед заказчиками, перед командой. На носу Новый Год, и его затягивают в подготовку к корпоративу – петь и плясать будет. Я, вроде как, не имею права отказать, и нехотя соглашаюсь – разумеется, с условием, что всё это не будет отвлекать от работы. Ага, щас.
Одну-две репетиции проводят после работы, но сталкиваются с низкой посещаемостью – кому охота задерживаться? Переносят в рабочее время. Чем ближе корпоратив, тем чаще и продолжительнее становятся репетиции. Программист не успевает работать, долги копятся – в плюс к имевшимся ранее.
Что делать? Из «проекта» уже не вытащишь – у него одна из главных ролей. Приходится списывать долги с него, и переносить их на «созаемщиков» — программистов, или на «поручителя» — себя. Ненавижу, блин, корпоративы.
Смена начальника
О, это просто шикарный повод для индульгенции. Новые начальники, как правило, не любят брать на себя долги предшественников, особенно если произошла не рокировка, а увольнение и прием извне. Формально новый босс, вроде, должен пересмотреть все старые задачи, определить их важность и приоритет, но оно ему надо?
Как правило, он поступает проще – или выкидывает старую задачу, или присваивает ей новый срок исполнения, что автоматически переводит долго из разряда просроченных во вполне себе свежие. Этим стоит пользоваться, подталкивая начальника к правильному решению. Сказать, например, что предшественник был терпилой, плохим управленцем, потому так всё и запустил.
Перемещение кредитора
Аналогично тому, как перемещаются должники при реструктуризации. Только сбегать надо уже мне – мол, ты теперь в новом подразделении, с новой должностью, целями, обязанностями. Чего нам с тобой старые задачи выполнять? Они ведь были созданы в уже несуществующем контексте.
Как правило, соглашаются, потому что долго-то – штука двусторонняя. Я должен сделать, он должен проверить, принять, внедрить. Ему оно надо?
Увольнение кредитора
Тут главное – успеть. Как только узнал, что человек уже на отработке – выбери подходящий момент. Их два – начало и конец. В начале у человека, как правило, эйфория, ведь он «покидает это болото». Под хорошее настроение с радостью спишет долги, т.к., по его мнению, он делает хуже компании, из которой уходит – это ему в радость.
Потом, почти всегда, идет период странной активности. С человека снялся избыточный потенциал ответственности, и он, собака, начинает, наконец, работать эффективно. Его уже не мучают сроки, последствия, интриги и взаимосвязи – просто делает, и всё. В этот момент лучше не соваться.
А в последние пару дней на человека накатывает депрессия. Он начинает думать, что поступил неверно. Эйфория уходит, он узнаёт много фактов о новом месте работы, на которые не обращал внимания, когда собеседовался. А тут, на старом месте, вроде всё наладилось – хотя, мы понимаем, что наладилось как раз потому, что он уже на отработке. Тут и можно подойти за списанием долгов – человеку уже просто пофигу.
Обмен долгов
Этим методом я пользовался часто. Суть проста – не принимаешь от кредитора новых задач, пока не закроешь старые. Обосновать можно по-разному. Например, сказать «блин, я тебе и так должен, не могу больше увеличивать обязательства». А можно придумать некое правило, вроде «не брать от одного отдела больше 10 задач одновременно». Логика понятна – любой дурак может устроить DDoS-атаку на ИТ-отдел, завалив его задачами, но при этом лишив автоматизации все остальные отделы. А так нельзя.
Посыл один и тот же – сними старую задачу, тогда возьму новую. Как правило, соглашаются, потому что новая задача – она прям щас, она горит, ее надо делать. А старая – раз уж умудрилась стать старой – не особо и нужна. Ее можно списать, что кредиторы и делают.
Поручение от Большого Босса
Тоже крутой метод. Правда, он, в основном, дает отсрочку, а не списывает долги. Но, при должном усердии, можно отсрочить на несколько лет.
Итак, нужен контакт с Большим Боссом. Лучше, конечно, если это будет собственник, или, на худой конец, директор. Он может поставить задачу сам, но это так себе вариант, потому что у такой задачи будет срок, и размахивать ею, как флагом, долго не получится.
Намного лучше – самому предложить Большому Боссу решение какой-нибудь задачи. Возможно, это даже будет проект. Желательно, чтобы он был туманным, непонятным, с нечеткими границами и без критериев оценки. Вроде как «я попробую улучшить вот это».
Тут важно формулировки подбирать. Большому Боссу говорим – «я попробую, я постараюсь, но не гарантирую результат». Вроде как, вы ему помочь хотите. Задача-то, по сути, ваша, а не его – он лишь одобрил и поддержал.
А всем остальным говорим – «у меня задача от Большого Босса, важная и срочная». Проверять вряд ли будут – если босс действительно Большой. В этом главная фишка. Такие задачи почти всегда неформальные, не регистрируются ни в какой системе, не контролируются на совещаниях. Но все понимают, что эти задачи Есть. И не посмеют лишний раз приставать со своими глупостями.
Новый проект по старой теме
Это метод для избавления от затянувшихся, лежачих проектов. На внутренней автоматизации прокатывал.
Суть проста – надо обосновать, что старый проект зашел в тупик, там заложена неправильная архитектура, замысел кривой, не в ту сторону пошли, границы не очертили, и вообще всё сделали неправильно. Надо по-другому.
Вот эта фраза – «по-другому» — часто действует на людей магически. Чтобы в этом убедиться, посмотрите на историю любых реформ и изменений в России. Все давно знают, что «хотели как лучше, а получилось, как всегда», но всё равно верят, что будет «по-другому».
У лежачих проектов есть преимущество – они достали всех, и должников, и кредиторов. Обязательства, пусть и неформальные, есть и у исполнителя, и у заказчика проекта. И избавиться от них рады все. Но никто не решается взять на себя инициативу.
Вот тут и можно себя проявить. Только не с бухты-барахты, на ровном месте, а с обоснованием. Вышла новая версия платформы, или ПО, или технологии появились, которые решают ключевые задачи проекта красивее. Пусть мы и потратили тысячу человеко/часов, но на завершение потратим больше, чем на реализацию с нуля на новой платформе. Наплести всегда можно. И не обязательно убеждать – нужны не аргументы, а отмазка. Причем, не вам, а всем – перед начальством.
А у вас руки всё равно чисты. Если что, коллеги покажут пальцем на вас – он решил прекратить проект. А вы – на них, мол, я только предложил, а они поддержали, согласовали и с радостью бросили проект. А я только предложил, как идею.
Увольнение
Это, пожалуй, самый естественный и часто применяемый способ получения индульгенции. Зачастую – вынужденный, т.е. увольнение случается по причине слишком больших долгов, которые уже буквально не дают дышать.
Но, как по мне, увольнение – все-таки запасной, крайний вариант. Лучше работать упреждающе, теми методами, которые предложил я – плюс к тем, которые уже знаете вы. Применяя индульгенцию я, например, комфортно проработал 6 лет в компании, где средний срок жизни руководителя был равен одному году. Причем, ушел я сам, безо всяких на то внутренних для компании причин.
Хотя, каждый решает для себя сам, конечно.
Как то сумбурно текст зашел.
Есть классический советский «метод трех гвоздей» — для работы с непрерывным потоком задач из разных источников.
Еще есть очень важный, можно даже сказать необходимый навык — говорить «нет».
Еще есть масса техник распределять задачи, согласовывая со всеми заинтересованных в задачах сторонах приоритет задач и сроки их выполнения.
Так то давно известны best practices что для тех кому задачи прилетают, что для тех, кто эти задачи ставит. И те кто копит на работе такие вот «долги», — это безответственные сотрудники, которым ни в коем случае нельзя доверять. Из тех, каждый чих и пых которых приходится контролировать. Опасный балласт.
Э, Брат, ЭТО Высший пилотаж. Метод трех гвоздей не катит. Что бы говорить НЕТ, надо обосновать. Чтобы юзверь сидел на попе ровно и не выёживался, надо знать больше него. Или, как говорил Нитше,:»Нужно иметь от природы легкую душу или облегченную, искусством и знанием»
(1) точно. Лучшая практика — это когда вам сделают именно то что вы просили именно тогда когда вам это меньше всего нужно. Все что можно сказать это «Спасибо, конечно…»
(2)
Ницше
С каких пор программисты передают дела дольше чем главные бухгалтера?
(2)
Если мы свертываем широкую тему офисных нахватов до темы взаимодействия 1С программиста с окружающей средой, то во-первых 1С программист обязан знать программу и предметную область намного глубже пользователя. У 1С-ника — предметная область — это бизнес, так что или 1Сник — эксперт в области технологий, которые использует бизнес, либо он плохой одинэсник.
Дальше, область деятельности одинэсника можно условно разбить на три «площадки» — 1. Поддержка работы программ, выполнение различных регламентных работ. 2.Консультации пользователей. 3.Разработка нового функционала и развертывание новых программ.
От первой части никуда не деться, основная польза 1С программиста когда он выполняет работы по части 3. Соответственно, нужно минимизировать до нуля вторую часть. Достигается это за счет разработки пользовательских инструкций и введение в корпоративную культуру практики, когда неопытный пользователь , обращается за консультацией к продвинутому пользователю, а непосредственный начальник организует обучение нового пользователя, как правильно выполнять операции в программе и что одинэсник занят решением важных задач для конторы в целом и нефик его отвлекать по мелочам.
Кое-какие свои мысли по этой части, с примером практической реализации я изложил вэтой публикации
Прочёл, спасибо за изложенные мысли — есть интересные.
Хочу добавить, что для себя выделяю «говорить НЕТ» и «продавать НЕТ».
«Говорить нет» — жёстко и обоснованно отказывать (заказчик недоволен, но проглатывает).
«Продавать НЕТ» — убеждать, что не решая эту задачу мы получим больше, чем завязнем в её реализации и прогадаем в итоге.
(Более предпочтительно, но реже удаётся на практике)
(6) Я думаю, автор не ставил целью свернуть всю тему к программистам 1С.
(8) Я из статьи как раз понял, что Иван Белокаменцев рассуждает про «офисный нахват» в самом широком смысле, просто tusv в комментарии (2) использовал слово «юзверь», чем сразу сузил контекст.
У нас в свое время был введен в оборот термин — «офисный нахват» или «нахват» — это когда сотрудник работу работает, у него есть четко очерченный круг обязанностей и зона ответственности, и за выполнение этих обязанностей ему платят зарплату и начисляют премии. А тут его руководство отлавливает и нахватывает абсолютно левой задачей, которая не входит в круг его обязанностей и при этом его работу никто не отменял. Ну и за срыв такого нахвата обязательно начислят штраф, а за успешное и своевременное выполнение не начислят штраф.
Что касается задач, которые в рамках должностных обязанностей, то их тупо надо делать согласуя с руководством сроки, или как тут в коментах хорошо написал Igorro82IT (7) — «продавать начальству нет». С нахватами все не просто и гораздо опаснее (нахваты запросто могут быть и политическим инструментом). Если в конторе такие нахваты сотрудников поставлены на поток, то это зло неизбежное и надо их грамотно структурировать и правильно готовить.
(6)
Как то особо не увлекаюсь словом НЕТ.-
1. Хелп — деск
2. Нет хелп деска — заведите
3 Если не помогает, то. Вопрос принят — ответ думаю. А думаю я регулярно и основательно, особенно по утрам с рождения:)
(5) а чего главбуху передавать? Программиста 1С?
Не увидел приемлемых способов «как избавиться от долгов»…
Да и тема раскрыта как будто шуточно…
Ежедневно мы работаем, закрываем часть вопросов… Называть вопросы, задачи — «долгами» как-то режет слух…