Как стать автором
Обновить

Директор по здравому смыслу: как перестать все контролировать и начать работать в команде

Время на прочтение7 мин
Количество просмотров37K
Всего голосов 88: ↑85 и ↓3+82
Комментарии55

Комментарии 55

Спасибо за статью. Выводы ожидаемые и правильные для вашей ситуации. Управлять нужно работой, а не людьми. В связи с этим основной вопрос: а как вы визуализируете поток всей работы?

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

А можно поинтересоваться кому нужно управлять работой, а не людьми? И второй вопрос, считаете ли вы работу производством?

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

Работу разделяю на производство продукта и дальнейшее его развитие (поддержку).

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


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


Я ни в коем случаю не "наезжаю", я просто имел опыт работы в разных компаниях с разным управлением и просто хочу понять некоторые, неясные мне вещи. Возможно, я просто не понял вас в контексте терминов.

Хорошая статья. Спасибо, что поделились опытом.
Спасибо!
Присоединяюсь, приятно читать статью, написанную хорошим языком. Вижу очепятку «с которым Вы работает», поправьте пожалуйста.
Спасибо за статью. Вопрос:
Таким образом, вместо того, чтобы получать одну двадцатую времени директора, человек получает постоянный чат, и видит, что происходит во всех отделах. Всем гораздо понятнее, что происходит, есть общая картина происходящего. И гораздо меньше неожиданностей, меньше хаоса и, соответсвенно, меньше стресса.

В этом чате строго регламентированые сообщения, которые появляются в запланированное время? Или там просто ребята по определенной теме общаются? Во втором случае «меньше хаоса» как-то не срабатывает…
Спасибо. Общение свободное, но это все равно меньшее хаоса, чем когда никто ничего не понимает. Правда у нас вообще вся работа построена на чатах (подробнее можно посмотреть вот тут: www.itsumma.ru/blog/kak-my-ispolzuem-telegram-v-tekhpodderzhke), поэтому все привыкли к такому режиму.
НЛО прилетело и опубликовало эту надпись здесь
Решения об изменении структуры приходят когда по старому жить уже просто нельзя. Когда становится понятно, что теперь действительно надо что-то менять, то приходится думать, как перераспределить нагрузку.

Как именно это сделать, заранее, конечно, неизвестно. Но поскольку мы никогда не нанимали людей на должность менеджера, то мы исходили из того, кто у нас есть, а не из того, как правильно строить структуру. Перебирали варианты, ставили человека на роль менеджера, и если получалось хорошо, он там оставался, если, по разным причинам, не получалось — пробовали другие варианты. И так постепенно сложилась структура, которая есть сейчас.
Могу конечно ошибаться но вот эти ребята (при условии что они не вышли из тех кто ниже) всегда казались мне лишним звеном усложняющим коммуникации при любом размере компании.
image
Личный опыт показал что у них проблемы и с теми кто выше и с теми кто ниже. И как правило они не разбираются ни в тех вопросах что решают люди выше ни в тех что решают люди ниже. Исключение этого звена частенько помогает. По сути тимлид ведь и есть менеджер, и достаточно просто не нагружать его программистской работой. Для этого есть разработчики. А тимлид и сам будет себя переодически нагружать чтобы не выпадать из контекста. Но он хотя бы может понять и директоров по разработке и рзработчиков.
вот эти ребята (при условии что они не вышли из тех кто ниже) всегда казались мне лишним звеном усложняющим коммуникации при любом размере компании.

Не одному вам так кажется ;) Есть правда мнение, что дело не в системе управления, а в банальном отсутствии компетенции у «этих ребят». Тимлид — тоже не железный. На Хайлоаде заметил интересный тренд: все без исключения ищут тимлидов, дескать на рынке их нет, нужно выращивать внутри, чтобы пропитались культурой компании. Это все так, но сложно одному человеку и разрабокту тащить и отчеты строить и коммуникацию вести.

Менеджеры как раз и должны взять на себя большой объем административной работы, освободив время тимлидов на работу с командой и управление рисками. А вот где учат менеджеров и почему они такие бестолковые в IT — это совершенно другой вопрос.
НЛО прилетело и опубликовало эту надпись здесь
Нет, не получается. Тимлид — зам. менедежера по технической.
НЛО прилетело и опубликовало эту надпись здесь
Очень большой опыт работы менеджером среднего звена. Самая неблагодарная работа. И сверху и снизу думают, что ты — лишнее звено. Верхи, потому что не видят и забыли, как много свободного времени им дарит мидл на творчество и биз, изолируя его от оперативного контроля и работы с «низами». При этом получают удобного «козла отпущения». Из за того, что тезнического квалика у таких манагеров нет, они не могут уйти вниз, даже если хотят. Низы этим тоже пользуются по полной. Вообщем проклятая работа, часто. Расстрельная должность и низкооплачиваемая. Единственный выход таким мидлам (часто) это слать топов нахер и уходить в самостоятельное плавание. (Конечно тех топов, кто не понимает)
В нашем случае они как раз вышли из исполнителей, поэтому хорошо понимаю работу своих подчиненных :)
Спасибо за статью, актуальная тема.
Спасибо

Спасибо за доклад на хайлоаде, но со временем родился такой вопрос:
Вы всех руководителей сами выращивали или кого-то брали со стороны?
Каков примерный процент руководителей со стороны и по каким параметрам/принципам Вы их подбирали?

Спасибо :)

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

Если человеку не интересно, и он сам не хочет ничего менять, как-то специально его мотивировать довольно тяжело и непонятно зачем.
Развиваться можно и как специалист, да и работу легче найти. Менеджер это повышение относительно сеньора? Больше в деньгах?
Да, в деньгах тоже. Главное помнить, что это совсем другая работа :)
что предлагаете делать с людьми которые не хотят\не могут заниматься другой работой, но по развитию превосходят «сеньоров»?
Если человека все устраивает, и не хочет заниматься другой работой, то заставлять нет смысла. У нас есть пример, когда исполнитель стал управляющим (директором, по сути), но оказалось, что это совсем не его, пытался делать все сам, очень много работал. Выгорел и вообще ушёл от нас на год, но потом вернулся простым исполнителем — отлично сейчас работает.
Как поддерживаете квалификацию менеджеров, чтобы они не отстали от технологий и своих подчиненных?
Дельная статья.
А тимлиды управляют или все же являются лидерами процесса? По классике, две роли: эксперт-лидер и менеджер в одном человеке не так часто встречаются. Если я правильно Вас понял, тимлиды скорее выполняли роль экспертов, чем менеджеров, но в этом случае их надо поместить на одном уровне с командой, так как они определяют правильное решение и лидируют его, но не являются транслирующим звеном. А коммуникации менеджер-команда все равно идут напрямую…
Тимлиды одновременно являются и исполнителями, и менеджерами. Коммуникации иногда идут напрямую, а иногда через тимлида, в зависимости от задачи.
Работают за двоих или по пол-дня в каждой должности?
Основная проблема: где взять менеджера? Сначала я пытался взять лучшего исполнителя и проапгрейдить его до менеджера

Ох как мне не нравится, когда руководители считают, что функции менеджера может взять один из сотрудников. Архитектором стать может, но менеджером — увы, нет. Приходится из-за этого бодаться с руководством.

Ну, в целом «один из» вполне может, почему нет. Тут ошибка скорее в представлении, что лучшим менеджером станет именно лучший технический специалист. А это, на самом деле, довольно сильно различающиеся и области деятельности и характеры работы.
Спасибо за статью, очень интересно!
Только извините, какое это отношение имеет к highload?
На этом Хайлоаде была целая менеджерская секция.
Highload проекты же кто-то разрабатывает и поддерживает, значит кто-то руководит теми, кто разрабатывает и поддерживает :)
а как несколько программистов превратились в админов?
Сначала мы занимались больше разработкой, но потом поддержка стала нашим основным направлением. Мы даже собирались вообще закрыть разработку, но отдел довольно внезапно ожил, и сейчас там работает 25 человек и планируем взять еще.

“Очень важно, чтобы человек понимал, как вы оцениваете его работу. Правильно ли он сделал и что можно сделать лучше. Надо и хвалить и ругать. Если ругать, то так, чтобы было понятно, как сделать лучше. Так у человека есть понятная система координат, и он понимает, что от него хотят и почему."


Отлить в бронзе и повесить каждому руководителю на стене кабинета.

Спасибо за статью. Интересно и познавательно.
Спасибо!
НЛО прилетело и опубликовало эту надпись здесь

спасибо за интересную статью.


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


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

У нас в фирме такое практикуется. Раз в квартал есть "стратегическое совещание", где определяется курс компании на следующий квартал, как в плане разработки, так и вообще (например внимание каким партнерам нужно уделить в первую очередь).


Делаем свой SaaS продукт

Наверное потому же, что и "Менеджер" вместо "Управляющий". Тоже наверное в свое время кто-то сильно возмущался когда использовали это слово да и кучу других...

Угу, а через некоторое время это слово ещё и склонять начнут и даже использовать множественное число: «сэйлзы».
А почему админы находятся в одном отделе с менеджерами по работе с клиентами? Админы по идее — это разработка, а менеджеры по работе с клиентами (аккаунты) — это должно относиться больше к сэйлзам.
все наши менеджеры выросли внутри компании.

Довольно популярная стратегия, причины ее выбора понятны.
Но так ли они хороша? (Пусть менеджеров со стороны искать сложнее, да и где на них учат?)


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


А в долгосрочной перспективе это будет давать какой эффект?
Вероятно, в значительной части менеджеров, уже негативный.
Т.к. менеджер так и продолжит принимать решения, исходя из задачи удержаться на своем месте (причем, "здесь и сейчас", т.е., в краткосрочной перспективе), а не исходя из долгосрочных интересов компании/продукта (не говоря уж об интересах разработчиков и других "исполнителей").


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


Однако, что получалось на деле:


  1. Текучка в компании составляла внушительные 25% в год при стабильной численности (± несколько человек), измеряемой в нескольких сотнях.
    (Кстати, многое указывало на то, что такой вровень текучки — запланирован и управляем.
    Например то, что текучка была равномерной — каждые неделю-две уходило и приходило одинаковое количество сотрудников.
    Или то, что регулярно принималось небольшое пополнение со студенческих курсов, а общая не менялась).
  2. Состав менеджеров практически не менялся — старые никуда не уходили, новых практически не появлялось (количество проектов в активной фазе примерно одно и то же, поэтому если возник один проект за все время, то и выдвинули только одного менеджера).
  3. Итак, что имеем:
    • Устоявшийся сплоченный костяк менеджеров, ранее выращенных из коллектива, и новый коллектив, постоянно обновляемый с лютым уровнем текучки.
      Естественно, какого-то особого взаимопонимания между менеджерами и "исполнителями" не было.
    • Более того, выдвинутые в менеджеры, изначально по большей работали не на позициях разработчиков или автотестировщиков (или хотя бы аналитиков).
      В основном в менеджеры выдвигались сотрудники с позиций ручного тестирования, т.е., имевшие такой характер работы, когда нужно было проверять тест-кейсы почти как пользователь, не задумываясь, что происходит под капотом той или иной нажимаемой кнопки (и, соответственно, не имея представления об объемах и сложности работы, а главное, о том, что объемы/сложность могут быть разные, хотя кнопки выглядят одинаково).
      И в представлении таких новоприбывших менеджеров разработка состояла в равномерной и быстрой выдаче новых реализованных тест-кейсов.
    • В итоге вся политика менеджеров сводилась к "загнать лошадей", лишь бы выдать "здесь и сейчас" новую порцию фич.
      При этом какого-либо этапа восстановления перед новыми скачками не предусматривалось.
      Видимо, в том числе с этим и был связан лютый уровень текучки среди исполнителей.

Собственно хотелось высказаться насчет тезиса "все наши менеджеры выросли внутри компании" — какие тут могут быть подводные камни.

Или вообще сказать: «Жень, ты какую-то ерунду говоришь, давай ты подумаешь еще день, а потом снова обсудим».
Это, возможно, самое главное. К сожалению, не всякий руководитель способен принять это и задуматься, когда ему снизу говорят, что он ерунду придумал.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий