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