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

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

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

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

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

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


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


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

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

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

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

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

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

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

Менеджеры как раз и должны взять на себя большой объем административной работы, освободив время тимлидов на работу с командой и управление рисками. А вот где учат менеджеров и почему они такие бестолковые в IT — это совершенно другой вопрос.
В нашем случае они как раз вышли из исполнителей, поэтому хорошо понимаю работу своих подчиненных :)
Спасибо за статью, актуальная тема.
Спасибо

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

Спасибо :)

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

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

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

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

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


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

Поучительно, спасибо
Спасибо за статью. Интересно и познавательно.
Спасибо!
К сожалению, к некоторым директорам подходит похожая фраза «как перестать все контролировать ничего не делать и начать работать в команде делать хоть что-нибудь». :-)
Годная статья

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


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


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

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


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

Только полноправные пользователи могут оставлять комментарии.
Войдите, пожалуйста.