У меня опыт в IT с прошлого века, 27 лет. Начинал программистом, когда во многих компаниях ещё не было системных аналитиков и проджект-менеджеров. Кто-то из команды должен был разговаривать с заказчиками. Чаще всего этим кем-то был я.
Потом стал тимлидом — одновременно программировал и управлял. Со временем меня «засосало» в управленческую деятельность. Максимум руководил 60 людьми.
Расскажу об ошибках, которые совершил за это время, и о своих выводах.
Дисклеймер: статья написана для блога Minervasoft на основе интервью с Юрием Куприяновым, автором телеграм-канала «Системный сдвиг».
Minervasoft разрабатывает софт для управления знаниями и обучением. Бизнес внедряет его, чтобы сотрудникам было проще пользоваться инструкциями, легче искать информацию и принимать сложные решения. В итоге экономит не только время команды, но и деньги.
Ошибка №1: Делать всё самому
Есть 2 типа руководителей: с зонтиком и с воронкой.
Руководитель с зонтиком защищает команду от всего, что падает сверху. Срочные задачи от топов, внезапные просьбы от смежных отделов, административная возня — всё это по-максимуму не попадает в команду. Руководитель с воронкой всё делает наоборот.
У меня практически всегда руководители были зонтиками, я научился так взаимодействовать со своей командой. Когда понимаешь, что что-то нерелевантное валится сверху, и думаешь: не буду пускать в команду, сам как-нибудь...
И второй аспект: когда у тебя большой опыт, ты многое умеешь. Всем помогаешь, за всё берёшься. Видишь, как люди работают над задачей, понимаешь: блин, да я лучше сделаю. И закрываешь всё сам. А это проблема.
Работал я как-то в образовательном проекте. Сверху спустилась задача — нужно было отвечать на обращения пользователей, делать материалы для рассылок. Поток большой. Раньше этим никто не занимался.
У меня техническая команда. Никто не хочет заниматься коммуникацией либо не может. Но делать что-то надо.
Спросил у команды, кто может это сделать. Один человек вызвался, что-то написал. Я понял, что это нельзя никому показывать.
Начал заниматься сам.
В какой-то момент обнаружил вот что: процессы, которые должен настраивать, как-то там идут, а я сижу, отписываю ответы. Понял: что-то не то делаю.
Начал работать с таймером, смотреть, какая работа сколько времени отнимает. Это вообще хорошее упражнение. Так я узнал, что на эту задачу у меня может уходить и 2, и 5 часов в день. Мда.
Проблему решил так: нашёл людей с коммуникационными навыками, которые стали этим заниматься. Они были не в моей команде.
А глобально я понял, что, если задачу нужно делать с какой-то периодичностью, важно создавать под неё структуру. Находить людей или обучать своих. Но, конечно, не заниматься всем самому. Так ничего не получится.
Ошибка №2: Поверил чужой оценке команды
Как-то один хороший человек мне сказал: «Возьми этих ребят, хорошая команда, классно работают». А потом оказалось, что не все работают хорошо.
Я трепетно отношусь к найму. Всегда с пристальным вниманием отбираю людей. После таких осечек понял, что к готовым командам нужно относиться так же, как если ты бы сам нанимал этих людей.
Со временем определил, на что нужно смотреть при найме:
1. «Горящие глаза» и интерес, как бы банально это ни звучало. В проектах, которыми я руководил, был жёсткий ритм, работать нужно было много и быстро. Поэтому без интереса тут никак.
Была ситуация: приходит человек, уставший. Говорит, что работал в стартапе, ничего не получилось, сейчас ищет просто хорошую работу за деньги.
Благодарен, что тот человек говорил честно. Я объяснил ему, что у нас и есть атмосфера стартапа. Поговорили, разошлись мирно — у него на руках уже был оффер в стабильную компанию.
2. Может подробно объяснить, чем занимался на прошлой работе. Если не может, вот варианты, почему:
— Человек врёт или приукрашивает свой опыт.
— Человек до конца не понимал, чем занимался. Значит, ему неинтересно глубоко погружаться в тему, это аукнется в будущем.
— Человек не испытывает интереса к работе.
В общем, подозрительно.
3. Задаёт вопросы. Если человек не задаёт вопросы, это может стать проблемой в будущем. Ему, опять же, либо неинтересно, чем он будет заниматься, либо он боится показаться некомпетентным, глупым или слабым.
Но в работе, как правило, есть проблемы. А такой человек будет скрывать их до последнего, «заметать всё под ковёр». Если будет зомби-апокалипсис — он никогда не расскажет, что его укусил зомби. Будет молчать, пока не мутирует и всех не покусает. Не надо так.
4. Анализирует провалы. Люблю спрашивать не про успешные проекты, а про неудачные. О том, почему провалились.
Если человек отвечает что-то вроде «это не я, это от меня ничего не зависело» — это странно.
Хороший ответ такой: «Делал вот это. Внешние факторы были такие. Эти смог погасить, эти не смог, закончилось вот так». Тогда интересно, наверное, человека стоит рассмотреть.
Ошибка №3: Давал слишком сложные задачи сразу
Бывают ситуации, когда человек не справляется с работой. Я считаю, что люди базово хотят работать и довольно честные. И если у них что-то не получается, у них есть на это причины. Как правило, это так.
Иногда бывает, что у человека есть какой-то блокер. Например, ему неоткуда взять нужную информацию. Или его задачи завязаны на других людях, которые затягивают выполнение.
А иногда человек просто не знает, как ему сделать работу. Тут ему надо помочь.
У нас был советский учёный Лев Выготский. Автор теории ближней зоны развития. Один из его тезисов звучит так:
— Ты не можешь дать человеку задачу, сильно превышающую его текущие возможности.
Если у человека что-то не получается, нужно дать задачу поменьше, более понятную.
Например, системный аналитик мне как-то сказала, что в её документации что-то не так, и она не может понять, что именно. Я предложил оформлять таблицей то, что она делала текстом. Пару недель так поработали, и стало лучше.
Таким набором шагов за пару месяцев можно научить человека нормально работать. А если сказать просто «пиши хорошо», то ничего не понятно — что конкретно-то делать?
Если хочу, чтобы человек делал хорошо, и вижу, что делает не очень — первая мысль: надо научить. Разбить на шаги и последовательно выдавать.
Если поговорил, он начал делать, результат появился — супер. А если «да-да-да», а потом человек ничего не делает — три таких попытки, а потом нужен серьёзный разговор.
Ошибка №4: Тянул с увольнением проблемных сотрудников
Иногда бывает, что человек действительно не хочет работать. Саботирует задачи, приходит, чтобы просто отсидеть время и получить деньги.
Таких людей надо максимально быстро выявлять и с ними прощаться. Чем раньше, тем лучше. Иначе он остаётся и показывает другим в коллективе, что так работать можно и ничего за это не будет.
Когда ты становишься руководителем, ты уже не можешь быть для всех хорошим. Увольнение — это тяжёлый поступок. Но нужно уметь делать такие вещи. Не быть мягким хозяином, который не хочет мучить собаку и отрубает ей хвост по кусочкам.
Как-то я работал в стартапе. Один человек отвечал за эксперимент. У него довольно долго не получалось написать программу. Когда спрашивал, как дела с этой задачей, реагировал так, как будто я его критикую. От помощи отказывался. Обещал, что вот-вот, ещё чуть-чуть и покажет готовую программу. Но результатов нет одну неделю, вторую. Так месяца 2 всё это тянулось. И я понял, что нужно действовать жёстко.
В России сложно сотрудника уволить официально. Я подумал и решил, что выплатить человеку 1-2 оклада будет дешевле, чем делать это через формальную процедуру. Занёс руки на клавиатуру, чтобы поставить встречу с человеком, предложить ему такую «мировую».
И тут он пишет:
— Юр, хочу с тобой поговорить, наверное, увольняться буду. Что-то у меня не складывается.
Вот так и закончилась ситуация. Кто виноват? Наверное, оба. Я, может, вовремя не настоял на увольнении или не создал атмосферу, чтобы можно было спокойно поделиться неудачами. И человек, который закрылся и думал, что успеет.
Я сам таким был, когда работал фрилансером. Очень страшно сказать начальнику или клиенту, что что-то не так идёт, что-то не можешь сделать. Надо это преодолевать — лучше как можно раньше сигнализировать о проблемах.
Скорее всего, помогут. Это зависит от атмосферы. Может, наоборот, утопят. Но в компаниях, где лучше помалкивать до последнего, лучше и не работать. Для здоровья полезнее.
Ошибка №5: Распылил команду по разным проектам
Тот же стартап. На 6-8 человек было порядка 6 проектов. Каждый занимался чем-то одним.
Так работали, результатов не было. В один момент понял, что нужно что-то менять. Решил так. Один месяц — один проект. Всё всё бросают и идут делать что-то одно.
Накинулись на проект, который полгода не могли сделать — после первого мозгового штурма придумали решение. Как в волейболе: один подал, другой ударил. Команда сработала.
То, что не двигалось полгода, сделали MVP за две недели. И в каждом проекте были результаты после такого подхода.
MVP — тестовая версия товара, услуги или сервиса с минимальным набором функций.
Доходило до странного. В команде был «железячник» — парень, который паял схемы на специальной аппаратуре. Он не понимал, зачем ему участвовать в обсуждениях проекта, но я настоял.
Так он тоже давал ценные советы. Оказывается, интересовался программированием.
Вообще я понял, что в командах, как правило, есть больше компетенций, чем я думаю. Кто-то чем-то интересуется, что-то подскажет. Когда выковыриваешь людей из своих норок и говоришь «давайте накинемся на проблему» — может получиться интересный результат.
Ошибка №6: Не общался с подчинёнными
В определённый момент ты уже физически не можешь общаться с каждым исполнителем, потому что их становится слишком много. Тогда ты назначаешь их руководителей и общаешься только с ними.
Но это не совсем правильно. Чем дальше ты от реальной работы, тем меньше понимаешь, что там вообще происходит. Начальники, которые у тебя в подчинении, могут не рассказывать о проблемах.
Поэтому важно иногда, как говорят японцы, ходить в «гэмба» — туда, где происходит работа. Ходить физически, в офисы, кабинеты. Пообщаться, позадавать вопросы, посмотреть, в каком состоянии люди. Иногда это видно невербально — человек грустный сидит или в стороне. Тогда стараешься подходить, аккуратно узнавать, в чём причина.
Вот такие ошибки-выводы. Главное, что я понял: руководитель — это учитель. Твоя задача не показать, какой ты крутой, а помочь людям стать лучше. Маленькими шагами, без рывков. И создать такую атмосферу, чтобы все проблемы всплывали быстро, а не лежали под ковром. Остальное уже детали.
Minervasoft разрабатывает софт для управления знаниями и обучением. С нашим ПО новички в компаниях быстрее обучаются, а опытные сотрудники тратят меньше времени на поиск информации.
В Minerva Knowledge можно загружать любые файлы и регламенты, создавать статьи всей командой в совместном редакторе, быстро находить знания с помощью умного поиска и анализировать эффективность статей.
Помощник с искусственным интеллектом Minerva Copilot встраивается в любую систему компании и подсказывает ответы на основе статей из базы знаний. Он также учитывает контекст и оставляет ссылки на источники. В итоге сотрудник быстро получает корректный ответ и решает любую задачу в несколько кликов.
А ещё в Minerva Knowledge можно безболезненно переехать из Confluence.
Попробовать продукты Minervsaoft
В нашем блоге в Telegram выходят другие статьи про спорные вопросы в найме, менеджменте и планировании. Подпишитесь, чтобы не пропустить.