• Советы начинающему тим лиду

    Posted on April 13th, 2009 Александр Орлов 13 comments

    Недавно Алистер Коберн опубликовал советы тим лиду, который выдвинулся из программеров. Советы собрала группа экспертов на April 2009 SLC Agile round table. На мой взгляд, одна из лучших подборок, про что нужно знать начинающим менеджерам.

    Что интересно, что слово “Agile” там употребляется только в названии круглого стола. :) Сама суть – абсолютно грамотные менеджерские советы. С удовлетворением заметил, что многие из этих тем мы покрывали на “Как стать менеджером в ИТ” и “Пути самурая”. :)

    • The Problem Space is Different – Delegation is Key…
    • I have a VP who was a Kernel Development, and he has never let go of it – so I deal with it by giving him what he wants, makes sure he gets lots of credit, and keep the rest for myself.
    • The hardest thing is simply listening to people.
    • In almost any high-skill arena, taking the top performers and making them coaches/managers is almost always a disaster.
    • Paul Graham: “what do you call a really technical person with strong people skills? Boss”.
    • Whatever their job is, help them be better at it.
    • You are now a junior person in a brand new career that you never were trained for – and keep in mind that the medium you are working in is PEOPLE.
    • As someone who has come from the coding arena, you understand the basic drama of building code – that’s invaluable.
    • Make time to stay involved with the stuff you love. Understand the difference between being interrupt-driven and being task-driven – find a way to find some time in the day to focus on a single task for a while.
    • See the “eMyth Revisited” – talks about the mindsets that people have.
    • Managing up is critical – help your team look as good as possible to the rest of organization, protect your team.
    • See if the person wants to be a manager :-) My company has a technical career track.
    • See Behind Closed Doors – the purpose of management is to organize purposefully.
    • Use one-on-one’s, help them to keep moving forward.
    • I had to move into a leadership role a year ago – keep a level head – you’re a parent to your team.
    • As a manager, you’re the guy on the Curling team with the broom – sweeping the snow out from in front of the stone… You don’t want to be in your face with all the details, but here to remove obstacles. “Be A Shit Shield” – the worst managers I’ve ever had were “Perfect Shit Conductors”.
    • Remove impediments – manage from the outside in – the difference between teaching adults and kids is that kids often listen – there are two different ways to teach – hot stove – or keeping people upright, then letting them fall at the right time.
    • How can we make it acceptable to promote the people who may not be the top technical performers?!?
    • People will bring you their issues with teammates – it will help to give your people some training in how to deal with those issues themselves.
    • YOU ARE THE ABSTRACTION LAYER – you provide the Bubble of Happiness.
    • If you can teach someone else – What does a good mgr do? What does a good mgr avoid? What does a good mgr know?
    • Make sure that you are not on the critical path (since you may have been a lead coder before).
    • It’s my job to make you better than American Express needs, and when that happens, I’ll help you find another job – and she did!
    • What your team needs from you is selling up.
     

    13 responses to “Советы начинающему тим лиду”

    1. Leonid Edelman

      Очень дельные советы.

      К слову – меня вот занимает вопрос: почему программисты, которые становятся менеджерами, никогда – ну, или почти никогда – не изучают собственно менеджмент? Ведь все ключевые темы – лидерство, мотивация, команды, организационное поведение и т.п. – давно и небезуспешно изучаются.

    2. У меня по этому поводу сложилось свое мнение. Что на начальном этапе на менеджера обычно оказывается сразу слишком большое давление. И первое, что попадает под “личное сокращение” – это время на учебу. А потом так и привыкают.

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

    3. Leonid Edelman

      Да, это все верно.. но ведь и книги гуру от программирования как правило (по моему личному впечатлению) не пестрят ссылками на иследования в области менеджмента, но основаны больше на обобщении личного опыта. Такое ощущение, что у программистов как сообщества сложилась определенная культура, которая отрицает наличие какой-либо общности между программированием и другими видами деятельности.. постоянно подчеркивается “уникальность” программирования, даже можно встретить утверждения о программировании как “высшей форме творчества”. Хотя, по моему скромному мнению, управление коллективом программистов или программным проектом в сущности мало отличается от похожей деятельности в любой другой творческой области. Разработка любых продуктов и устройств, проектирование, архитектура и т.п. Не зря известная IDEO, помимо индустриального дизайна, весьма активно занималась веб-дизайном.

    4. Какие именно гуру имеются в виду? Йордон, МакКоннел, Демарко и Листер, да и тот же Джоэл Спольски – чем не основы менеджмента для программистов?

    5. 2 Leonid. Могу точно сказать, что в моем случае управление программистами резко отличалось от управления ремонтниками квартир. :)

      Но вообще по поводу исследований менеджмента – у тех же Демарко с Листером процитировано довольно много исследований продуктивности команд и пр., и пр.

      Да, и этот пост – тоже про общеменеджерские практики. Которые озвучены гурами от программного менеджмента.

    6. Leonid Edelman

      Ну, про ремонтников квартир я ничего не говорил.. хотя, вот вопрос. Представьте, что Вам надо управлять командой ремонтников.. элитных. И стоят задачи:
      1. Успеть в срок
      2. Уложиться в бюджет
      3. Обеспечить качество (гарантию на все работы лет на 5 хотя бы)
      4. И чтобы все было “красиво”
      5. И ещё у Вас нет времени торчать круглосуточно на обьекте и проверять каждый шаг..
      6. А ещё Вы знаете, что Ваши ремонтники – во всяком случае, некоторые из них – в свободное время кто огранкой камней развлекается, кто пытается в 3DStudio работать, кто гравюры рисует (это не шутка – я такого ремонтника реально знал)
      7. И работаете Вы с ними не один раз, а постоянно – только обьекты меняются
      А если это, скажем, не ремонтники, а например реставраторы?
      Так ли уж сильно будет отличаться управление такой командой от управления командой программистов? :)

    7. Leonid Edelman

      Я с большим уважением отношусь ко всем перечисленным уважаемым авторам (от себя бы ещё обязательно добавил Коберна). И я нимало не сомневаюсь в действенности менеджерских практик, озвученных вышеназванными гуру. Меня, собственно, интересуют две темы:
      1) Чем вообще программный менеджмент, или менеджмент для программистов, отличается от менеджмента вообще, и почему для его изложения требуются какие-то свои, особенные гуру? И знаете ли Вы ещё какую-нибудь индустрию, сообщество представителей которой считало, что ими надо как-то по-особому управлять?
      Ещё раз – я не пытаюсь сравнивать программный проект с проектом ремонта квартиры. Сравнивать надо все-таки сравнимое; программный проект – это почти всегда проект разработки нового продукта, и значит управление им надо сравнивать с управлением разработкой нового продукта в какой-либо другой области – это может быть автомобилестроение, микроэлектроника, авиакосмос, фармацевтика и т.п. И, лично я не вижу особой разницы, за исключением чисто экономических факторов, влияющих на тот или иной выбор.
      2) Почему, соответственно, круг публикаций на тему программного менеджмента и круг публикаций на тему менеджмента выглядят очень слабопересекающимися? Неужели нечему друг у друга поучиться?
      Да, я согласен, есть ссылки. Я специально взял с полки несколько книжек и пролистал. Да, у Йордана есть ссылки на некоторые публикации не из программной области. Да, у Демарко и Листера тоже есть такие ссылки. И у Коберна есть. Вот у Спольски, извините, списка литературы вообще нет (?). Но в общей массе на такие ссылки приходится, по грубой оценке, 10-20% от всех ссылок. Все остальное – ссылки на публикации, связанные с программированием.

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

    8. @Leonid
      <>

      imho, с возникновением индустрии ПО возникли новые проблемы менеджмента. Если в материальном производстве главным является правильно поставленный процесс, с легко заменяемыми работниками и минимальной долей творчества на этапе собственно производства, то разработка ПО – это, возможно, первый случай массового применения мозгов в качестве основного средства производства во всём производственном цикле.

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

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

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

      Поэтому, мне кажется, айтишники в большинстве и относятся со скепсисом к “научному менеджменту”.

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

      Ни в одном ВУЗе подходящих мне специальностей и курсов не было – тратить два-три года на “фундаментальную” (читай – безнадёжно устаревшую) науку желания не было.

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

      Посматривал одно время в сторону MBA, но это вообще кот в мешке, причём за немалые деньги. (Пытливый программистский ум в поисках информации наверняка наткнётся на одну из книг Минцберга, вроде Managers Not MBA’s, и на MBA окончательно поставит крест).

      В общем, единственным способом оказалось самообразование, а также накопление и обобщение собственного опыта.

      И тут результаты такие: ни один из купленных учебников MBA по менеджменту не был дочитан до конца. Толстый талмуд “Управление программными проектами: достижение оптимального качества при минимуме затрат” третий год пылится на полке. А книги перечисленных выше гуру (плюс книги по лидерству, кстати) читаются, перечитываются, цитируются – потому что они дают прямые и понятные ответы на вопросы “что делать прямо сейчас” и “к чему стремиться”.

    9. Leonid Edelman

      @Greesha
      А я уже сказал раза два, что не сравниваю программирование с производством. (Хотя даже на производстве – опыт Тойоты показывает, что если дать работникам возможность и стимул думать и принимать решения, а не быть просто винтиками, это может дать компании существенные выйгрыши). Я сравниваю программирование с разработкой Продуктов – т.е. новых моделей автомобилей, самолетов, электроники, микросхем и прочего железа; а так же с индустриальным дизайном; и ещё с многими другими процессами, выходом которых является нечто уникальное и в которых сильно задействованы интеллетуальные ресурсы. И сравнивая, единственное существенное различие, которое я вижу – это цена ошибки: исправить ошибку в автомобиле гораздо дороже, чем исправить её в программе, что накладывает существенные требования к построению процессов. По сути, процессы разработки софта – это идеал любых разработчиков; любой дизайнер автомобилей, наверное, мечтает о возможности быстро и дешево воплотить любую свою идею в работающее что-то, что можно проверить. Почему и распространяется компьютерное моделирование.

      Касательно образования: я заканчиваю обучение на MBA от школы бизнеса Гренобля (совместная программа с АНХ). Не скажу, что нечего покритиковать – есть чего; но в целом, мне понравилось – полезные связи, дельные материалы и довольно трезвые взгляды на менеджмент.

    10. Я бы согласился с Леонидом. Управлять творческими коллективами акромя программистов не довелось. (Не считая моих ремонтников. Но этим бы творцам их творикулы бы поотрывать. :) Там была сделана ошибка на этапе найма.)

      Тем не менее, надо признать, что многие обще-менеджерские вещи (да хоть вот перечисленные выше) срабатывают и с программистами тоже. (У Джоэла Спольски, кстати, тоже встречаются ссылки на обще-менеджерские книги: http://www.joelonsoftware.com/articles/FogCreekMBACurriculum.html)

      Почему превозносится именно управление программистами? Сложно сказать. Думаю, именно потому, то оно противопоставляется управление производством, как верно описал Greesha. Если же сравнивать с разработкой продуктов, то разницы может и не оказаться. :)

    11. Интересно, а как вы переводите последнее? Я имею в виду вот это:

      “What your team needs from you is selling up.”

      У меня есть предположение (менеджер должен “продавать” разработчиков, в том числе и вышестоящему начальству, то есть добиваться, чтобы на труд разработчиков был надлежащий спрос и за этот труд давалась подходящая цена); но интересен ваш вариант перевода.

    12. 2 undebugger. Я бы перевел именно как продажу наверх, то есть начальству.

    13. “Use one-on-one’s…” – а можно раскрыть эту тему поподробнее?

      Скажем, что это за зверь вообще – one-on-one (1×1)? Если, допустим, менеджер и подчиненный что-то обсуждают в аське – это 1×1 или нет? а если обсуждают по телефону? А если разговаривают лицом-к-лицу (face to face), но, скажем, в опен-спейсе, где рядом сидят и все слышат другие коллеги – это тянет на 1×1 или нет? А если подчиненный заскочил на секунду в кабинет менеджера и обменялся парой слов “как дела? – да все окей” – это уже 1×1 или нет еще?

      А как, к примеру, организовывать 1×1 – по-случаю (“я позвал тебя, чтобы сообщить пре(не)приятнейшее известие…”) или регулярно? если регулярно, то как часто – ежедневно? раз в неделю? в месяц? в год??? Устраивать ли 1×1 только между менеджером и непосредственными подчиненными или “через ступеньки” менеджерской лестницы (“вассал моего вассала…”)?

      А вообще, стоит ли овчинка выделки? какая такая особенная польза от 1×1, в чем они могут быть эффективнее к примеру общения по емэйл или по аське?

      Представим, к примеру, менеджера с восемью подчиненными. Если он еженедельно тратит на 1×1 с каждым, скажем, по часу, то получается, на это у него уходит целый день в неделю – 20 процентов всего рабочего времени менеджера… неслабо, а? а какая от этого может быть польза? не лучше ли было бы это время потратить на что-нибудь другое?

    Leave a reply

    You must be logged in to post a comment.