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