Что я вынес из опыта в ИТ

Привет, читатель!

Так получилось, что в своё время мне довелось радикально сменить область профессиональной деятельности — в связи с манифестацией психического заболевания перейти из ИТ в психологию. И сейчас, работая с клиентами-айтишниками, SMM-щиками, CEO-шниками и т.д., особенно начинающими, я порой ловлю себя на том, что помимо собственно психологической работы, мы занимаемся обсуждением вопросов, которые правильнее было бы отнести к области менеджмента / GTD.

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

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

Итак, приступим.

Часто люди задают вопросы вида “Я ничего не понимаю, подскажи, как сделать”. Нередко под этим на самом деле подразумевается “сделай за меня”. Такие вопросы бесят. Они формируют негативное отношение к вопрошающему, убивают всякое желание помогать ему.

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

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

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

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

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

Зачастую профессиональные задачи выполняются по какому-то более или менее постоянному шаблону: сотрудник саппорта заводит пользовательские учётки в системе, CEO-шник выгружает статистику просмотров, SMM-щик пишет дежурные посты в фейсбук — всё это деятельность, которую можно с достаточной степенью точности описать в виде какого-то алгоритма.

Проблема возникает там, где сотрудник (например, в силу небольшого опыта) не знает этих алгоритмов. В этом случае имеет смысл собрать топ X задач, которые встречаются чаще всего, и освоить их выполнение (да-да, речь идет о принципе Паретто).

В удалённых городах (например, в Магадане) у меня были, мягко говоря, не слишком квалифицированные кадры, и для того, чтобы человек как можно быстрее мог приносить пользу организации, я в течение первых нескольких недель обучал их выполнению именно самых распространенных в их зоне ответственности задач.

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

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

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

Всё это примеры игноририрования этого правила, которое включает в себя элементы проактивности и системного мышления. Об этом много сказано в контексте пользы оных качеств сотрудников для организации, но не так много — о пользе для самих работников. Между тем, способность посмотреть на задачу чуть шире, чем написано в ТЗ / сказано в распоряжении / заявлено клиентом может серьёзно упростить жизнь самому исполнителю. Хотя бы за счёт экономии на “переделках”.

Когда я работал в проектных продажах, я столкнулся с тем, что одно из решений моего портфеля плохо продаётся в т.ч. и потому, что никто в регионе толком не умеет с ним работать. Тогда решил записать несколько роликов на Ютубе по решению наиболее распространённых задач с помощью этой штуки. Это не входило в мои обязанности как регионального представителя вендора, но это было тем, что позволило несколько упростить дальнейшее продвижение данного решения.

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

Распространённый пример — сочетание прокрастинации и тревожности. Изначальный запрос обычно звучит в контексте “убрать прокрастинацию”, но гораздо быстрее с ним можно справиться, если посмотреть на человека в целом (учесть контекст) и понять, что конкретно в его случае озвученная проблема является простым следствием высокого уровня тревоги, и разбираться нужно, в первую очередь, с ним.

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

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

Чем же может быть полезно составление документации самому сотруднику? Оно позволяет радикально ускорить процесс обучения, сделать получаемые знания более глубокими и систематизированными.

Когда я пришел на свою первую серьёзную работу, я почти сразу организовал там внутреннюю корпоративную базу знаний (на Wiki-движке, но это не столь важно) и взял себе за правило писать KB-шники на любую ситуацию, с которой я не смог справиться сразу.

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

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

Для меня этот опыт стал возможностью систематизировать огромное количество материала, который мне пришлось изучить, структурировать собственное мышление и получить конструктивную обратную связь от коллег (“у тебя в базе написана фигня” или “делал по твоему мануалу, всё зашибись, спасибо”).

Поскольку одной из моих обязанностей был саппорт конечных пользователей (внутренних), я сделал KB-шники и для них. Это позволило мне закрывать тикеты гораздо быстрее — просто давая ссылку на соответствующий KB-шник в базе. Реально затрачиваемое на саппорт время существенно сократилось, и я смог сместить фокус своего внимания на инфраструктурные проекты.

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

Мне много раз приходилось видеть, как люди, неправильно понявшие какие-то методики из GTD, бросали идею списков дел, поскольку эти списки очень быстро разрастались до совершенно слонопотамных размеров, теряя всякую способность вносить структуру (ради чего они изначально создавались).

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

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

В системе обращений в HelpDesk, которую мне доводилось внедрять я поставил автоматическое закрытие тикета через полтора месяца после создания (уже после того, как обнаружил достаточно большое количество тикетов, время жизни которых было больше указанного срока). Заявки стали закрываться сами, и в большинстве случаев никто их не переоткрывал.

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

Принцип “удаления / сборки мусора по таймауту” я активно использую и в текущей работе (например, если клиент какую-то часть изначального запроса не упоминает в течение нескольких недель подряд, это повод узнать у него, так ли она актуальна), и в повседневной жизни (вещи, которыми я не пользовался более года, я без особого сожаления продаю / выбрасываю — в зависимости от ценности).

“Ты будешь чай или кофе?” — этим простым вопросом нейробиолог Антонио Дамасио подвешивал своих пациентов с нарушением функций орбитофронтальной коры, вгоняя их в бесконечный цикл анализа преимуществ и недостатков одного напитка перед другим.

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

Часто бывает так, что стоимость ошибки ниже стоимости исследования и анализа, который позволит эту ошибку не совершить. В этом случае отлично позволяет монетка или игральные кости. Просто оцените (привет оценке Ферми) примерный порядок стоимости принятия решения и сравните его с примерным порядком стоимости ошибки. Если величины получились относительно похожими (или даже стоимость решения вышла выше) — бросайте монетку / кубики.

В качестве примера могу привести компанию, которая очень долго выбирала систему для учёта основных средств (там свои заморочки, которые не позволяли использовать имеющийся SAP на полную мощность). Выбирала-выбирала идеальную, в итоге приехал аудитор и неплохо так наказал руководство за то, что этот самый учёт был поставлен совсем никак. Любая из рассматриваемых на тот момент альтернатив могла бы решить задачу на 80-90%, и этого было бы, вероятно, вполне достаточно.

И ещё про монетку: её можно использовать для активации мышления. Часто бывает так, что в, казалось бы совершенно непонятном для человека выборе, при приземлении монетки в голове проносится мысль “хоть бы орёл / решка”. Наряду с таблицами взвешенных альтернатив, монетка может служить эффективным средством для того, чтобы определить, чего же вы на самом деле хотите.

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

Будучи совсем “зелёным”, я понятия не имел о том, как подступиться к этой задаче. Решить её мне помог “механистический подход” — делать хоть что-то, а потом снова и снова смотреть на задачу в новых условиях.

В ИТ первым шагом может быть банальное гугление по ключевым словам в разных комбинациях (если вы не знаете, как правильно составить запрос, просто гуглите всё подряд, весьма вероятно, что вам повезёт, и вы сможете найти формулировку для следующей итерации).

В моём случае это было так: я наткнулся на пост какого-то чувака, которому срочно нужно было почистить несколько компов, и он делал это полной переустановкой системы, аргументируя, что так быстрее. Затем я начал гуглить на тему ускорения процесса переустановки ОС на рабочих местах. Дальше — узнал ключевые слова RIS / WDS, и задача из “неразрешимой” превратилась во вполне решаемую, а потом — и в решенную.

Если абстрагироваться от конкретного примера, то суть этого пункта можно уложить в простую метафору: снимайте сложность слоями, один за одним. Не знаете, как написать статью? Накидайте структуру. Или напишите введение. Или сделайте хоть что-нибудь. Посмотрите на задачу снова и снова сделайте ещё что-нибудь. Вполне вероятно, что через N итераций у вас сформируется некое представление о её решении.

Тут всё просто: сейчас есть огромное количество решений для автоматизации чуть менее, чем всего. Мы живём в то благословенное время, когда для того, чтобы автоматизировать что-то не обязательно быть программистом или системотехником.

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

Например, когда я работал в саппорте, много времени моего и, что гораздо хуже, других, зачастую более высокооплачиваемых, сотрудников уходило на то, чтобы выяснить программное окружение инцидента (какой браузер использовался, локально он использовался, через терминал, или это вообще был VDI, какой IP, какая версия ОС и т.д).

Небольшая доработка в софте, на котором крутился HelpDesk, которая съела у меня порядка 20 рабочих часов, позволила получать эту информацию в автоматическом режиме, сэкономив тем самым не одну сотню часов времени сотрудников.

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

Если вы хотите донести какую-то идею, одним из лучших способов сделать это является создание некоего минимально работающего прототипа. Когда мне нужно было уговорить внутреннего заказчика профинансировать разработку хитрого финансового отчёта, я просто рисовал его ручками в Экселе, а потом шел с этой красивой картинкой и говорил: “Хочешь такую штуку?”

Это гораздо более действенно, чем долго и нудно распинаться относительно преимуществ решения. Людям лениво вникать в абстракции, конкретика воспринимается гораздо проще.

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

Даже сейчас в своей работе с клиентами я стараюсь сначала дать им какой-то инструмент, который поможет справиться с той же депрессией и тревогой “здесь-и-сейчас”, и только потом, когда они убедятся, что это вообще работает, заключаю контракт на более длительные и глубокие методы работы.

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

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

Зачастую помогает решить эту проблему очень простой, я бы даже сказал “топорный”, приём: перед тем, как начать коммуникацию, обозначьте свои цели. “Иван Иванович, я пришел просить о повышении оплаты”, “Мария Сергеевна, я хочу поговорить с вами о повышении моих тарифов” и прочие подобные фразы могут существенно упростить коммуникацию для тех, для кого она является проблемой. Попробуйте.

Во времена работы в поддержке проектных продаж подобная практика позволяла мне входить контакт с представителями заказчика просто за счёт того, что они воспринимали это как искренность. Разумеется, она уместна не всегда и не везде, но когда я говорил “ребята, сейчас я попытаюсь вам продать то-то и то-то” суровые айтишники, которые считались абсолютно неконтактными, говорили: ну, давай, попробуй. А это уже лучше, чем “иди ты нафиг со своей фигнёй”.

Ещё раз хочу сказать, что я не претендую на универсальность этих советов. Более того, я сам прекрасно вижу ограниченность их применимости, но я очень надеюсь, для кого-то они окажутся если не столь же важными, как для меня, то хотя бы немного полезными.