Автоматизация трёх гвоздей

Пока я работал программистом, все было хорошо.

Когда я стал руководителем программистов, появились определенные трудности, но их удалось преодолеть.

Когда меня поставили руководить стратегическими изменениями, все стало плохо. Я начал упускать.

Трудности с задачами

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

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

Исполнять чужие задачи – просто. Исполнять задачи, поставленные самому себе, еще проще.

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

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

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

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

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

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

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

Задачи, как инструмент управления, работали ненадежно. Конечно, можно было просто продолжать их записывать, отслеживать исполнение и бесконечно переносить сроки, а потом сказать, что я сделал все, что мог. Но я был руководителем проекта изменений, и хотел добиться результата.

Итак, проблема. Задачи плохо исполняются, если они не обязательные. В моем случае они были не обязательные в квадрате. Во-первых, поставлены не непосредственным руководителем. Во-вторых, не относятся к текущей деятельности.

Пришлось срочно изобретать какое-нибудь решение.

Я один такой?

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

Маркерами служили фразы вроде «Так, я вспомнил, мы же хотели сделать…», или «Ну, этот вопрос надо отдельно обсуждать…», «Я уже три года говорю, что надо сделать…», «Кстати, а почему до сих пор…», «Погоди, мы вроде давно решили, что ты…» и т.д.

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

1. Не было формализованной задачи;
2. Вопросы касались изменений.

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

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

Если задача записывалась в блокнот, то успешно забывалась. Большие корпоративные блокноты – вообще забавный способ вести задачи. Записал то, что сегодня сказали, перевернул страницу, и уже никогда к ней не вернешься.

Когда подобные задачи начали ставить через информационную систему, исполнительская дисциплина несколько подросла, но лишь формально. Если человеку ставили задачу «Проанализировать вопрос о…», то результатом выполнения была фраза «Проанализировал вопрос», и тому подобное.

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

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

Три гвоздя

От того, что проблема общая, и стало еще интереснее. Начал более пристально наблюдать. Хоть большинство подобных вопросов и не решались, но были исключения. Нужно было понять, какие методы работают, а какие – нет.

Где-то случайно встретил анекдот про три гвоздя. Процитирую:

Советские времена. Съезд управленцев по обмену опытом. У самого передового председателя-управленца спрашивают: — А как вам удается столько всего успевать? Тот отвечает: — Очень просто! Методом трех гвоздей. У меня над столом вбиты три гвоздя. Когда ко мне приходит распоряжение или запрос — я его пишу на листочке и вешаю на гвоздь. И ничего не делаю. Когда приходит первое напоминание — перевешиваю на второй гвоздь. После второго напоминания — на третий. И только после третьего напоминания — приступаю к выполнению. Однако, мало какие распоряжения доходят до третьего гвоздя.

Шутка шуткой, но на деле именно так и происходило. Вопрос подвешивается, или задача ставится – и тишина. Если руководитель вспомнит, и снова поднимет вопрос, услышит в ответ «да, занимаемся, еще не готово», успокоится и забудет. Если еще раз вспомнит, то все повторится.

Получается, проблема состоит из двух частей:

1. Вспомнить, а точнее – не забыть;
2. Проявить настойчивость – дойти до третьего гвоздя и дальше.

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

Были и люди с хорошей памятью, но с недостатком настойчивости. Или избытком стеснительности. Один раз скажут, второй раз напомнят, а потом… Неудобно как-то. Может, сам все помнит и сделает? Что я буду, как дурачок, ходить и переспрашивать?

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

Задачи и вопросы

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

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

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

Но девушка была настойчивая и обязательная, поэтому принялась выписывать эти вопросы на бумажку и таскать ее с собой на совещания. И озвучивать при каждом удобном случае.

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

Получается довольно простой алгоритм:

1. Задачи и вопросы – отдельно;
2. Задачи живут своей жизнью;
3. Вопросы всегда собраны в одном месте, под рукой;
4. Надо ритмично, регулярно эти вопросы озвучивать;
5. И тогда все получится.

Вот с этой милой женщины я и решил взять пример. Мне нужно было решить аналогичную задачу.

Первые попытки

Сначала я тоже пробовал использовать блокнот или бумажку, но быстро бросил.

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

Во-вторых, мне показалось неудобно держать задачи и вопросы в разных местах. Одно – в компьютере, второе – на бумажке.

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

Решил поискать инструменты в системе. В те времена это был доработанный 1С:Документооборот. Там есть такая функция – «Поставить на контроль». С виду – то, что надо. Берешь любой объект, ставишь на контроль, указываешь срок (самому себе). Можно написать комментарий для себя. Срок подходит, вылезает уведомление, заходишь, вспоминаешь, пишешь человеку письмо или сообщение.

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

Еще пробовал через аутлук, но там еще хуже, чем на бумажке и в 1С. В итоге сделал простенькую автоматизацию.

Автоматизация

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

Идея с постановкой на контроль любого объекта мне понравилась, и я ее тоже реализовал.

Но была небольшая проблема – в какие объекты записывать эти свои вопросы для контроля? В задачи? Кому? Самому себе? Мешать будут, в общем списке задач.

В итоге создал простецкий объект, который так и назвал – «Вопросы для контроля».

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

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

Теперь по каждому контролируемому вопросу собиралась вся история перевешивания с гвоздя на гвоздь.

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

Чтобы не пропустить точки контроля, сделал простенькую формочку, собирающую все точки на одном экране.

По каждому объекту отображается последняя контрольная точка со своим сроком. Также, есть ссылка на предыдущие контрольные точки. Расцветка простая:

1. Зеленый – все хорошо, срок контроля еще не пришел;
2. Красный – срок уже вышел;
3. Фиолетовый – холостой контроль, когда срок не установлен и задача не записана.

Собственно, все. Что у меня на контроле, как я этим пользуюсь, какие задачи и сроки себе ставлю – видно только мне. Ну и начал пользоваться.

Результаты

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

Были некоторые отличия во фразах и текстах, которыми мы пользовались при напоминании. Так у меня под рукой была вся история контроля, то я добавлял «вообще, вопрос висит уже месяц» и «в прошлый раз ты сказал…», ну или «ты уже 3 раза подряд одно и то же говоришь». Метрики, в общем. Сколько преодолено гвоздей, когда, и при каких обстоятельствах.

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

Потом поняли, что я что-то задумал или какой-то хитростью пользуюсь, и начали сопротивляться. Вероятно, полагали, что не дойдет до третьего гвоздя, просто настырный какой-то попался.

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

Неохота было объяснять, что проблема трех гвоздей решается очень просто. Может, вы тоже решите ее таким же способом? Или у вас нет такой проблемы?

 

Да, этот функционал теперь есть в Flowcon.