Disclamer: Эта серия постов - полный копипаст с моего канала. Всего постов будет семь. Перечитывая и перепубликуя их здесь, я понимаю, что серия не ровная - какие-то посты мне нравятся больше, какие-то сильно меньше. Интересно посмотреть как они зайдут/не зайдут вам.
Предыдущий пост → Думай как топ
Если я сталкиваюсь с большой рутинной задачей, то в какой-то момент я начинаю материться и думать [последовательность важна] - как не делать эту задачу второй, третий, четвертый итд раз.
Ответ - не делать вообще, делегировать или автоматизировать. Самый классный способ, но сложнореализуемый «не делать». Делегировать - тоже очень круто, но что если у вас такой возможности нет?
Остается автоматизация. Но как освободить себя от процессов с помощью технических или математических методов, если вы не программист или вам недоступны специальные инструменты.
Я стараюсь трактовать автоматизацию широко - главное найти способ освободить себя от процессов, хотя бы частично. Если вы много отвечаете на однотипные вопросы коллег, то можно провести обучение или написать понятный гайдлайн. Создаете однотипные документы - проинвестируйте время в шаблоны. Если обрабатываете большие массивы данных в таблицах, то научитесь делать лукап и условное форматирование. Часто обращаетесь к определенным файлам - переименуйте их так, чтобы быстро находить глобальным поиском [поставьте PowerToys на Windows 10 и будет у вас аналог Spotlight на MacOS].
Ищите любой способ не делать рутинные задачи дважды, для этого совсем не обязательно быть разработчиком или гуру экселя.
Мои примеры очень простых автоматизаций
- Я проверяю большое количество технической документации. Если документ подготовлен неверно, то его нужно отправить на реворк с комментариями, что не так. Комментарии обязательны, при этом 90% ошибок - однотипные [чеклист тоже есть, но кто его читает?]
Эта операция может быть легко автоматизирована с помощью небольшого скрипта, и когда-нибудь так и будет. Но я решила не ждать, так как довольно быстро добесилась писать одни и те же фразы по 20 раз в день. В итоге я создала txt файл с короткими описаниями ошибок и теперь просто «набираю» комментарий с помощью этих кусочков. Если при этом еще пользоваться буфером обмена, то становится гораздо легче, в первую очередь морально.
- Одна из моих обязанностей на работе - консультировать коллег по крепежу. Вопросы, за редким исключением, однотипные, их много, и они в мессендерже. Удовольствие то еще - сплошные переключения и обезьянка, бьющая в тарелки, в голове. Читать документацию никто не хочет, потому что всегда легче спросить. Да и если человек готов почитать документ, то ему нужна ссылка. А как получить ссылку - спросить.
Идеальное решение этого вопроса - чатбот. Но, разрабатывать внутреннего под такую задачу невыгодно, а использовать внешнего нельзя из-за безопасности данных.
В общем, дальше все было как всегда - добесилась, психанула и решила сделать альфа версию бота. Проанализировала все вопросы за последние 3 месяца, выбрала 10 наиболее важных и частых, написала ответы в одном сообщении со всеми необходимыми ссылками, запостила в общую группу и сохранила сообщение так, чтобы оно было под рукой [в пределах двух кликов].
Теперь, если я получаю вопрос, я просто пересылаю это сообщение и внизу дописываю «see p.5». Кайфую нереально. У этого решения оказался еще один сайдэффект - люди так или иначе, пробегают глазами все сообщение и находят там другую полезную информацию для себя. По ощущениям, вопросы задавать стали реже.
Последнее по автоматизации...
Если вы придумали решение, затрагивающее других людей, то будьте готовы к тому, что его придется продавать. Терпеливо объяснять, почему это надо, и настойчиво формировать новые привычки у других людей. Это бывает больно, дорого и часто неожиданно.
Бывало ли такое, что потратили кучу времени и написали классную документацию, но ей никто не пользуется и не поддерживает? Вот это оно.
Почему так получается? Когда мы создаем решение для своей команды или коллег, мы забываем выяснить их потребности и делаем так, как нам кажется будет лучше. А потом неизбежно сталкиваемся с кучей возражений, которые необходимо отрабатывать.
Чем лучше вы узнаете потребности своей команды, перед тем как что-то предлагать, тем легче будет отработать возражения и продать свое решение. Очевидно, правда?
Выше я рассказала, как сделала ручную версию бота с частыми вопросами. Но не рассказала, что было до этого. А до этого была страничка в вики, большая обучающая презентация [на которую я потратила месяц], несколько ознакомительных сессий. Ничего не сработало - мне не удалось «продать» эти решения, как бы я в них не верила и не вкладывалась.
В итоге, я смирилась с тем, что потребность моих коллег - это задать конкретный вопрос и в течение получаса получить на него ответ. У них нет потребности узнать все и сразу, у них нет времени читать большой и подробный документ, часто им даже не требуется понимать бэкграунд [что спорно, но факт]. Следующим шагом надо было выяснить, а что именно их интересует. Для этого я сделала выборку вопросов и тем по следующим критериям: частота, последствия, если на вопрос не ответить вовремя, и ценность сейчас и в ближайшем будущем [например я добавила ответ на вопрос, который сегодня не так актуален, но будет актуален через месяц]. Последний шаг - понятный интерфейс. Такое решение было намного легче продать, но приходила я к нему мучительно и долго.
Любое решение надо продавать. А продажа - это не только само предложение, но и выяснение потребностей и отработка возражений.
Следующий пост → Качество и достаточность
Как альтернатива Powertoys для поиска Search Everything (особенно версия 1.5, которая сейчас в альфе) - люто годная программа. Качественный и богатый функциональностью на поиск софт.
По пункту 2. Перестал так действовать уже лет 10 как.
На все тупые вопросы в первый раз отвечу по-минимуму и отошлю в документацию. В следующий раз не отвечу, а отошлю читать документацию сразу. По каким-то более тонким нюансам или содержательным вопросам, разумеется отвечу.
По-моему, работать голосовым дубликатом документации - это плохо для всех. Работодатель уже заплатил за создание документации и теперь повторно платит за то, чтобы эту документацию зачитывали. Зачитывающий документацию тратит время своей жизни на что-то более бессодержательное или неприятное (с таким же успехом можно копать лопатой море). Запрашивающий информацию никогда её не запомнит, и если отвечающий заболеет или уволится - он не сможет выполнять свою работу.
"Читать документацию никто не хочет, потому что всегда легче спросить" - вот именно поэтому надо сделать так, чтобы легче было "прочитать документацию", чем "спросить". По личному опыту, документация обычно содержит нужные данные, но в абсолютно неприемлемой для меня форме. Поэтому я по документации, с которой приходится работать делаю себе конспекты, из которых мне легче добыть информацию, чем "спросить" или "прочитать документацию".
Вот да. Составил подробный алгоритм (на языке ДРАКОН - просто было интересно) как организовать типовое мероприятие в нашей работе. Но им никто пользоваться не стал.
Стоило узнать почему. Боюсь, что сделал его чрезмерно подробным и для всех ролей сразу (и делопроизводитель, и управляющий). Это и отпугнуло. Легче просто спросить у других коллег, кто уже делал это.
Тут все глубже...что бы пользовались надо продать, что бы продать надо понять потребность, потребность задавать вопросы и делать безусловно то что сказали, так проще, думать больно и не приятно.
Я с машиностроительного предприятия, у меня есть куча документации, красивой, хорошей, полной, но ее никто не читает, даже в автоматизированном виде. Все работает на "Он/она так сказали и мы стали делать". Вопрос - ответ, инструкция к безусловному действию, зачем знать как надо было если "Он/она так сказали и мы стали делать". И так будет всегда, люди не готовы быстро решать задачи с многими неизвестными, люди не готовы решать задачи даже с одной неизвестной, если ты в коллективе всегда можно спросить и переложить решение задачи на соседа, хуже когда последствия от решения тоже удается переложить. Все примеры Кати закрывают истинную потребность, поэтому работают без палки.