Вы когда-нибудь задумывались, откуда берутся срочные задачи? Вроде, они как-то сами по себе возникают, объективно, из ниоткуда. Срочность рассматривается, как объективное свойство задачи, которое и анализировать-то смысла нет.
Вот просто есть на свете срочные задачи, и всё тут. Как бывает плохая погода, пробки и дурное настроение начальника. Я тоже так всегда думал, пока не познакомился с чудесным человеком, который всё мне объяснил. С тех пор я смотрю на срочные задачи иначе, потому что понимаю причину их возникновения.
Причина проста: если задача срочная, то кто-то, где-то, что-то профакапил.
Если вы принесли срочную задачу, то профакапили либо вы, либо кто-то до вас. Помните об этом, и не прикрывайтесь срочностью задачи. Если разберутся, все равно узнают, что профакапили именно вы. В этом нет ничего постыдного – мы все так делаем.
А если не узнают, то вы и дальше будете факапить, превращая нормальные задачи в срочные. Например, держать у себя запросы на оценку, анализ, проектирование целый месяц, а потом выдавать программисту/аналитику, как «а-а-а-а надо срочно оценить, клиент важный, давай подпрыгивай и беги». Один раз прокатит, вам поверят, и вы продолжите факапить – чего нет-то, раз прокатило.
Системный факап задач и превращение их в срочные – это уже плохо, потому что вы становитесь токсичным, вредным и неприятным человеком. А вы не хотите таким быть.
Если срочную задачу принесли вам, спросите реальный срок ее возникновения. Этим вы поможете, в первую очередь, тому, кто принёс задачу. Ну и себе немного – хотя бы чувства вины испытывать не будете за то, что у вас – срочная задача, и есть риск не успеть.
Иногда и спрашивать не надо, если постановку прислали по электропочте – посмотрите на даты писем или вложенных файлов.
Есть еще одна поганая ловушка, создающая срочные задачи. Допустим, вам дали задачу. Вы считаете, что будете ее делать сами. Сами, так сами – пофиг тогда на срочность, вы сам хозяин своего времени. Сидите, ждете себе спокойненько момента, когда можно будет начать выполнение задачи, и вот он уже подходит… Бац!
Что-то изменилось, и задача передается другому человеку. Она тут же становится мегасрочной. У вас весь контекст задачи в голове, а новому человеку надо погружаться, что еще более усиливает нервозность ситуации. Лучше не создавать таких ситуаций, не прижиматься к сроку выполнения, и начинать делать раньше.
Причину срочности можно найти у любой задачи. Упал сервер с 1С на заводе, и надо срочно чинить? Профакапил сисадмин, который не настроил резервный сервер. Сисадмин подавал заявку на резервный сервер, а ИТ-директор не подписал? Виноват ИТ-директор, он — причина срочности. Не оплатил финдир, потому что из бюджета выбились? Виноват ИТ-директор, который криво ведет бюджет. Директор компании запретил покупать «всю эту чушь для айтишников»? Виноват он.
Понятно, что нет смысла директору предъявлять. Он просто не поймет, т.к. никогда не слышал про управление рисками. Главное в другом — не надо переживать и чувствовать вину за решение срочной задачи. Сисадмин устраняет не собственный факап, ему не за что стыдиться. Сисадмин устраняет ошибку директора. Он спасает директора и его чертову тупорылую компанию. Сисадмин — Спаситель.
Как и любой человек, решающий срочную задачу, профакапленную кем-то другим. Вы — Спаситель, блин. А он — злодей. Не наоборот.
Любой автор факапа этот факт скрывает, пытаясь вывернуть всё так, что виновата лошадь. А лошадь не виновата. Хорошо бы, чтобы все это понимали, и вскрывали причины возникновения срочных задач. Но так не будет никогда, поэтому хоть вам спокойнее будет, дорогой Спаситель.
Каждый раз, когда вам прилетает срочная задача, постарайтесь увидеть факапщика. И скажите ему об этом, если иерархия позволяет. Пусть знает.
Ну и вот вам хорошая картинка Дорофеева на эту тему:
Вот просто есть на свете срочные задачи, и всё тут. Как бывает плохая погода, пробки и дурное настроение начальника. Я тоже так всегда думал, пока не познакомился с чудесным человеком, который всё мне объяснил. С тех пор я смотрю на срочные задачи иначе, потому что понимаю причину их возникновения.
Причина проста: если задача срочная, то кто-то, где-то, что-то профакапил.
Если вы принесли срочную задачу, то профакапили либо вы, либо кто-то до вас. Помните об этом, и не прикрывайтесь срочностью задачи. Если разберутся, все равно узнают, что профакапили именно вы. В этом нет ничего постыдного – мы все так делаем.
А если не узнают, то вы и дальше будете факапить, превращая нормальные задачи в срочные. Например, держать у себя запросы на оценку, анализ, проектирование целый месяц, а потом выдавать программисту/аналитику, как «а-а-а-а надо срочно оценить, клиент важный, давай подпрыгивай и беги». Один раз прокатит, вам поверят, и вы продолжите факапить – чего нет-то, раз прокатило.
Системный факап задач и превращение их в срочные – это уже плохо, потому что вы становитесь токсичным, вредным и неприятным человеком. А вы не хотите таким быть.
Если срочную задачу принесли вам, спросите реальный срок ее возникновения. Этим вы поможете, в первую очередь, тому, кто принёс задачу. Ну и себе немного – хотя бы чувства вины испытывать не будете за то, что у вас – срочная задача, и есть риск не успеть.
Иногда и спрашивать не надо, если постановку прислали по электропочте – посмотрите на даты писем или вложенных файлов.
Есть еще одна поганая ловушка, создающая срочные задачи. Допустим, вам дали задачу. Вы считаете, что будете ее делать сами. Сами, так сами – пофиг тогда на срочность, вы сам хозяин своего времени. Сидите, ждете себе спокойненько момента, когда можно будет начать выполнение задачи, и вот он уже подходит… Бац!
Что-то изменилось, и задача передается другому человеку. Она тут же становится мегасрочной. У вас весь контекст задачи в голове, а новому человеку надо погружаться, что еще более усиливает нервозность ситуации. Лучше не создавать таких ситуаций, не прижиматься к сроку выполнения, и начинать делать раньше.
Причину срочности можно найти у любой задачи. Упал сервер с 1С на заводе, и надо срочно чинить? Профакапил сисадмин, который не настроил резервный сервер. Сисадмин подавал заявку на резервный сервер, а ИТ-директор не подписал? Виноват ИТ-директор, он — причина срочности. Не оплатил финдир, потому что из бюджета выбились? Виноват ИТ-директор, который криво ведет бюджет. Директор компании запретил покупать «всю эту чушь для айтишников»? Виноват он.
Понятно, что нет смысла директору предъявлять. Он просто не поймет, т.к. никогда не слышал про управление рисками. Главное в другом — не надо переживать и чувствовать вину за решение срочной задачи. Сисадмин устраняет не собственный факап, ему не за что стыдиться. Сисадмин устраняет ошибку директора. Он спасает директора и его чертову тупорылую компанию. Сисадмин — Спаситель.
Как и любой человек, решающий срочную задачу, профакапленную кем-то другим. Вы — Спаситель, блин. А он — злодей. Не наоборот.
Любой автор факапа этот факт скрывает, пытаясь вывернуть всё так, что виновата лошадь. А лошадь не виновата. Хорошо бы, чтобы все это понимали, и вскрывали причины возникновения срочных задач. Но так не будет никогда, поэтому хоть вам спокойнее будет, дорогой Спаситель.
Каждый раз, когда вам прилетает срочная задача, постарайтесь увидеть факапщика. И скажите ему об этом, если иерархия позволяет. Пусть знает.
Ну и вот вам хорошая картинка Дорофеева на эту тему:
