Командная работа и авторитетный тимлидер
В позапрошлой записи о цыплятах речь шла о том, что не только в гиблых конторах, но и вполне успешных или стремящихся к тому, чтобы стать успешными (как я оценила нашу текущую компанию – проблем много, но рост есть, что радует и вселяет оптимизм) никуда не деться от ротации кадров – специалисты приходят и уходят, новички формируют команды и с этим часто связан тот факт, что некоторые организационно-профессиональные проблемы, которые уже были (не один раз!) решены в рамках нескольких устоявшихся команд при переформировании и укомплектации их новичками опять становятся актуальными, опять приходится тратить время на то, чтобы утрясти, кто в доме хозяин как решаются поставленные задачи, какой вес мнения тимлидера для конечного разработчика и как должен подходить к решению задачи тот специалист (новичок), у которого на это решение частично не хватает знаний, опыта или уверенности в себе, извиняюсь за длинное предложение.
В комментариях подняли интересный вопрос, актуальный не для всех вероятных читателей этого блога, скорее для тех, кто работает в софтверных или дизайнерских компаниях и где принята командная работа. Что такое хорошая, сработавшаяся команда, от чего зависит успешность командной работы, в какой степени зависит от авторитета и профессионального уровня тимлидера (team leader)? Вытаскивая из дискуссии:
На тему “скакунов и першеронов” — так правильно. Скакун — он всегда дорог, сложно управляем и так далее… И он действительно может очень многое. (только не тягать центнеры туда-сюда, туда-сюда, туда-сюда…)
Ему простор нужен.
А насчет всех “внутрикорпоративных передряг” и прочих переходных периодов — вот тут как раз выплывает такая вещь, как “команда”. Отношения к административному делению фирмы не имеет, кстати.
Команда — она сама по себе. Это неделимая единица. И команда, после того как сформирована, обычно не меняется (за исключением очень редких случаев).
Тимлидер в данном случае — это не просто мощный программер, который может (теоретически) управлять группой человек. Это именно тот человек, к которому прислушивается данная конкретная команда. Не более того. И он может даже не быть супер-программистом или супер-дизайнером, или кем-то еще. Он просто является сердцем команды, идейным двигателем и так далее…
Некоторые фирмы, которые построены таким образом, очень даже успешно работают на рынке (как пример — Ашманов и Со Товарищи). И очень часто — многие другие, обычно — не очень большие фирмы.
Кстати, очень многие авторы говорят о создании именно такой вот команды, в которой все всех как раз понимают, знают и уважают. Но — такая команда неудобна в управлении. Потому что она, опять же, неделима. И внутрикорпоративная ротация часто и идет как раз для того, чтобы такие вот команды не образовывались.
Зачем? Элементарно. Если нет команды, то при увольнении одного сотрудника не уйдут все остальные, да и сотрудники будут посмирнее. Не будут требовать себе “работать с тем-то или с тем-то”, ну и так далее. Попытка представить человека как что-то заменяемое часто и делает человека чем-то заменяемым — человек просто меняет фирму. И тогда и выплывают все бока с “незаменимых у нас нет” — так ведь говорят, кажется?во-первых, командное деление — прерогатива продуктовых компаний. проектоориентированные компании не имеют монолитных команд. есть пул разработчиков и пул проектов. это эффективнее. nothing personal, никакого масонского заговора, just business.
во-вторых, ни разу не видел тим лида, который был бы слабее подчиненных. разве что в аспектах. но никак в целом. все знакомые мне лиды люди с колоссальным опытом девелопменат. а успешные лиды — еще и с колоссальным опытом управления. именно это и дает им авторитет. хорощий человек — не профессия.
в-тетьих, было бы ошибкой думать, что при увольнении одного сотрудника начнется массовый исход. я пытался как-то сорвать команду полностью. я не был лидом, но разговоры подрывные вел, каюсь. никто. команда просто развалилась. даже если уходит тим лидер, не всегда уходит команда. а уж если девелопер уходит… отряд не заметил потери бойца, называется картина. это миф, нет в реальности такой единицы, как комнада. во всяком случае я не видел ни разу. это только во дворе каждый за каждого, в бизнесе каждый сам за себя.
Здесь я обещала рассказать о том, что на самом деле ситуации, когда харизматичные тимлидеры способны выдернуть из компании целую команду – эти ситуации абсолютно реальны и периодически случаются, и примеров живых этому не мало. Не всегда успешным оказывается результат такого выдёргивания, но факт остаётся фактом. Рассмотрим из жизни.
Не далее как 5 лет назад (надо же, сколько времени прошло) в одной очень большой компании, которая писала на запад и Америку софт, рисовала простенькие рекламные сайты и создавала большие веб-проекты на сложных самописных движках и помимо прочего оказывала ещё некоторое количество “сопутствующих” услуг (маркетинг, переводы) сформировалась одна такая команда – устойчивое подразделение, почти самодостаточная ячейка, ориентированная на веб-разработку. Два программера, дизайнер, менеджер (переводы на несколько языков и собссно общение с клиентами) и сам тот самый тимлидер, обеспечивающий команде клиентов, а клиентам – работающие проекты. Исторически сложилось так, что пришлось этому тимлидеру покинуть компанию и не только. Поскольку с клиентами отношения сложились сладкие, а компания в целом (как любая большая организация) уже напоминала динозавра с грандиозной бюрократической надстройкой – вы знаете, как большое количество менеджеров и вообще инстанций тормозит проведение любых оперативных работ, да и кормить их всех нужно, а кормятся бюрократы, как и везде, на реальном труде производителей (в данном случае конечные производители – те самые программеры и дизайнеры). В общем, посовещались на перекурах да компанейских пивных вечерах, и решили уйти, причём все вместе, сбросить со спины динозавра и быстро, красиво, эффективно и занедёшево стать самостоятельной IT-компанией.
По началу у них всё было достаточно красиво – в самом деле, клиенты были счастливы, проекты собирались быстро и никто не висел над душой, читая морали о “корпоративном духе” и блокируя одну разработку за другой по никому не известным причинам. Корпоративный боевой дух внедрять не было нужды, потому что – они же друзья, они же вместе! и значит и без моралей понимают ответственность каждого. Потом оказалось, что один из веб-программеров, который (в силу того, что команда-же – маленькая!) выполнял и функции сисадмина, периодически чрезмерно перегружен работой по настройке серверов/оборудования (а оборудование ещё просчитать, купить нужно – тоже ответственность) и на что-то у него времени меньше, или же приходится перегружаться работой больше, чем это было бы здраво, второй – которому досталось писать ядро одного серьёзного сервиса, не смог разделить свою работу на нескольких человек, просто не получалось у него, везде казалось – проще самому, вплоть до вёрстки интерфейса (на самом деле не все программеры собирают голимые интерфейсы. Врождённый вкус, основы html/css, понимание внутренней логики форм – где нужно элементы выделить, а где – подсветить строчки у табличных данных, и каким цветом это сделать), сложная математика (вот здесь, он говорил, я точно никому не смогу объяснить!) – нет, ну правда. Он работал по 14 часов и больше, и не две недели – много месяцев. Тот, который планировал вести менеджерскую работу и делать переводы на мультиязычные версии (+ переписка с забугорными клиентами) – ему пришлось взять на себя административные функции, компанию-то нужно было как-то создать и оформить юридически, т.е. – это и документооборот, и бухгалтерия, и офисные задачи, которые в организациях раньше выполнял завхоз (ну, или в современных компаниях – офисменеджер, так кажется?). А тут ещё и харизматичный лидер всё-таки занялся обустройством своей жизни на новом заграничном месте – тоже не копеешное дело – начались перебои то с клиентами, то с переводами денег, непонятки, недодоговорённости (раньше-то, при наличии здоровенного менеджерского штата, большинство проблем решали другие специалисты, вплоть до непростых финансовых операций), неоплаченные разработки и прочие печальные события.
Команда продержалась вместе не мало, могу признать. Но в том составе, в котором с таким оптимизмом была сформирована, всё-таки не выжила. Пример это печальный, в самом деле печальный, есть и напротив – успешные примеры, минимум три таких знаю и сейчас. Поэтому не стану недооценивать важность командной работы, умение управлять командой, слаженность внутри команды (как я и писала – если мне сотрудник говорит, что “не может работать с Васей, если можно – пусть мой эскиз верстает Петя или я буду рисовать интерфейсы для виндовз-приложений, которые собирает Стёпа, а не Саша…”), умение договариваться, идти на компромисы (если оно того стоит). И если в компании появляется харизматичный лидер, вокруг которого кублятся с восторгом новички – да, такой специалист (если он не просто душа пивной компании, а профи в своём направлении) достоен особого к нему отношения со стороны организаторов компании, ибо может вытянуть многие сложные вещи – и трудные проекты всё-таки собираются, и новички как-то значительно быстрее обучаются (точно говорю!).
спасибо за пост.
полностью согласен с тезисом о том, что умение находить компромисы есть неотемлимое качество любого руководителя.
Приманки – чем удержать сотрудника.
[...] темы “о цыплятах” и “командной работе” — разговор, затеянный в офисе одним из новичков [...]
Так уж повелшось, что люди не смогли далеко уйти от животных. И как стайным животным им еобходим лидер. Самая большая проблема для руководящего состава состоит в том, что страхом и наказаниями никого не удержать – есть свобода выбора – приходится искать альтрнативные методы.
к чему я веду – слаженная работа коллектива или групы зависит в первую очередь от авторитета лидера, а “компромисы” это просто один из инструментов – своего рода “пряник” – подчиненный доволен – его тоже послушали
Солидарен с Антоном, а соответственно и с автором статьи. Спасибо! Вполне интересная тема.