DevRain Solutions
Компания
32,30
рейтинг
19 декабря 2012 в 03:16

Разное → Книги для тимлидов и руководителей проектов

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

В отечественном IT я часто наблюдаю следующую картину: тимлидом часто становился лучший (?) разработчик из команды (aka 23-летний сеньор). А чтобы стать руководителем проекта (project manager) иногда достаточно просто знать английский и «павэрпойнт» на уровне пользователя. Это реалии отечественного аутсорсинга и с этим нужно как-то жить.

В итоге часто получается как-то так:
Потому что на десять сеньоров по статистике девять тупят.

Чтобы стать хорошим тимлидом, нужно перелопатить очень большое количество бизнес кейсов, побывать в шкуре не только разработчика, но и product owner и владельца бизнеса. Но как это сделать обычному разработчику? Вот здесь и приходит на помощь специализированная литература. Понятно, что реального опыта она не добавит, но первоначальный бекграунд дать может.

Я никогда не видел книг по управлению проектами или персоналом на столах разработчиков. Но, на мой взгляд, каждый специалист уровня «мидл» должен читать подобного рода литературу. И да, инициатива на этом этапе должна исходить больше от компании (или действующего тимлида), т.е. разработчик еще вряд ли серьезно задумывается о будущей карьере менеджера.

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

  1. Том ДеМарко. Deadline. Роман об управлении проектами.
  2. Том Демарко и Тимоти Листер. Человеческий фактор. Успешные проекты и команды.
  3. Том Демарко, Тимоти Листер. Балдеющие от адреналина и зомбированные шаблонами. Паттерны поведения проектных команд.
  4. Том ДеМарко, Тимоти Листер. Вальсируя с Медведями: управление рисками в проектах по разработке программного обеспечения.
  5. Патрик Ленсиони. Пять пороков команды. Притчи о лидерстве.
  6. Патрик Ленсиони. Пять искушений руководителя: притчи о лидерстве.
  7. Патрик Ленсиони. Три признака унылой работы. История со смыслом для менеджеров (и их подчиненных).
  8. Патрик Ленсиони. Смерть от совещаний.
  9. Джейсон Фрайд, Дэвид Хайнемайер Хенссон. Rework. Бизнес без предрассудков.
  10. Фредерик Брукс. Мифический человеко-месяц, или Как создаются программные системы.
  11. Джеффри Янг и Уильям Саймон. iКона. Стив Джобс.
  12. Кармин Галло. iПрезентация. Уроки убеждения от лидера Apple Стива Джобса.
  13. Джоэл Спольски. Джоэл о программировании.

Кроме технической литературы желательно почитать что-то по психологии (философии), HR, финансам и рискам, а также биографии успешных людей. Я ни в коем случае не претендую на 100% завершенность этого списка, поэтому попрошу в комментариях поделиться своими рекомендациями и отзывами.

Спасибо за внимание!

P.S. В качестве эксперимента сделал небольшой опросник на тему «Какие книги вы прочитали?». Просьба потратить 30 секунд на заполнение, а я, в свою очередь, через некоторое время выложу результаты опроса.
Автор: @sashaeve
DevRain Solutions
рейтинг 32,30
Компания прекратила активность на сайте

Комментарии (52)

  • +5
    А как же Getting real? Очень полезная книжица, почерпнул оттуда некоторые советы. Отрекомендовал в опроснике.
    А вообще, не привык доверят списку книг, в котором 60% занимают работы двух авторов, попахивает неразборчивостью составителя.
    • +3
      А что поделать, если Ленсиони и ДеМарко являюся специалистами мирового уровня и пишут мало, но в яблочко?
      • +1
        Как насчет выбрать лучшие их три-четыре книги, не вставляя восемь?

        А вообще, пост был бы супер-полезен для меня, но увы, еще вчера был тимлидом в молодой команде в интересном высоко-нагруженном проекте, а сегодня уже нет
        • +1
          что случилось?
        • 0
          Я тоже думал, какие 2-3 книги Ленсиони выбрать, но понял, что они все одинаково хорошие. Да и сами книги достаточно небольшие — можно часа за полтора-два справиться с одной.
      • +3
        Психбольница в руках пациентов?)
  • +5
    Для начинающих есть еще неплохая книга: «Как пасти котов» (Дж. Ханк Рейнвотер).
    • +2
      Уже была локальная дискуссия на эту тему, но повторюсь:
      Вы не могли бы кратко описать, что именно вам понравилось в этой книге?
      • +2
        Книга не очень? Думал тоже ее почитать.
        • +1
          Такую литературу я обычно читаю с карандашом — делаю пометки, чтобы ещё раз просмотреть интересные идеи.
          Здесь у меня не осталось ничего.

          Я уже и не помню точно, что же было в этой книге. Осталось только ощущение разочарования.

          Читал отзывы схожие с моим. Поэтому всегда спрашиваю людей, которым она понравилась, чтобы они хоть пару строчек черканули.
          • 0
            Классификация, скажем так, психотипов программистов в принципе для определённого базиса вполне сойдёт.
  • +5
    Не всем надо расти в тимлиды. Кто то растет в тимлиды, потом дальше в управление людьми, кто то в PM'ы, кто то в Tech Lead'ы и дальше в архитекторы.
    Мне допустим тимлидом быть не нравилось, тратить кучу времени на звонки, переписку и заполнение табличек, когда техлидом можно больше времени заниматься разработкой, рефакторингом, инспекциями и менторингом. Зарплата при этом у этих позиций сопоставимая и из техлида можно расти в архитекторы. При этом техлид обычно не бегает как белка в колесе при авралах и отвечает только за себя и свои решения, в отличии от тимлидов :)
    • +2
      Не всем надо расти в тимлиды.… Мне допустим тимлидом быть не нравилось
      А узнали бы вы о том что это не ваше, если бы не попробовали?

      техлиды, тимлиды, архитекторы, PM'ы
      Только в больших конторах это разные люди.
      • 0
        А узнали бы вы о том что это не ваше, если бы не попробовали?

        Вообще то меня изначально не тянуло руководить и отвечать за кого-то, у меня отец почти всю жизнь начальником работал и я представлял, что это такое. Так что я отказывался всегда, когда предлагали, но все равно пришлось поработать несколько месяцев пока штатный тимлид нашей комманды был в командировке. У нас кстати часто бывало, что тимлид не самый сильный разработчик в команде.

        Только в больших конторах это разные люди.

        Ну так я про них и говорю, у нас только в России было 1000+ разработчиков.
    • 0
      С другой стороны, не зависимо от того, будет чел тимлидом или нет, такие книги читать надо. Как минимум для того, чтобы разбираться в людях и компаниях. И понимать, как можно увеличить собственную эффективность.
  • +1
    Я бы добавил в эту коллекцию Дж. Ханк Рейнвотер «Как пасти котов» и книги Джоэла. Книга Фредерика Брукса немного устаревшей показалась, но в целом неплохо (первое издание этой книги 1975), для представления о том как создавали ПО 30 лет назад для разнообразия почитать можно, да и сейчас используют многие принципы тех далеких лет.
    • +1
      «Как пасти котов» — читал, но в итоге в этой книге прекрасно только название, в сухом остатке практически ничего.

      Джоэл прекрасный писатель, но в каждой статье он обсасывает только одну-две идеи.
  • +14
    У вас не тим лид, а какая-то личинка ПМа. В то же время менеджмент — это совершенно не техническая специализация и совершенно не стоит тимлидов сажать в это прокрустово ложе насильно.

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

    Ответвенность же, коммуникации — это все равно зона ответственности ПМа или линейного менеджера. И его право, при возможности, делегировать эту часть на тимлида. Или не делегировать.
    • +1
      Соглашусь, тимлид как главный над программистами, product manager как человек который знает что мы делает и project manager как человек, который руководит процессом чтобы он таки завершился — это три совершенно разных компетенции. Безусловно, можно совмещать, и еще при этом программировать за троих — но это мало у кого получается и в целом не идет на пользу.

      Я последние пять лет совмещаю должность project manager'а, тим лида, ночами иногда превращаюсь в программиста. И последние две роли мне совершенно не нравятся — но я вынужден их выполнять, потому что бюджет не позволят выделить отдельного человека ревьювить код и отслеживать общую архитектуру :(. Но если бы была такая возможность — я бы с удовольствием переложил эти почетные обязанности и сконцентрировался исключительно на тасовании задач в Jira и общении с людьми. А программирование было бы хобби :).
      • 0
        Надеюсь, вы не отождествляете управление проектами (в т.ч. софтверными) с «тасованием задач в Jira» ;-)
        • 0
          Нет, но это очень важная часть управления проектами.
          • 0
            Если совмещать позицию тимлида и ПМа, то да. Но ПМ совершенно не обязательно должен быть техническим специалистом, а без этого как он разберётся кому что поручить? А как потом проверять и контролировать? Это задача в большей степени тимлида (-ов).

            Если стоит задача как можно коротко, но ёмко определить деятельность руководителя проектов, то я бы сказал, что это нахождение баланса между ограничениями проекта. А конкретных операций там вагон и маленькая тележка – полистайте PMBoK например.
            • 0
              Если стоит задача как можно коротко, но ёмко определить деятельность руководителя проектов, то я бы сказал, что это нахождение баланса между ограничениями проекта. А конкретных операций там вагон и маленькая тележка – полистайте PMBoK например.


              При всем моем уважении, «тасование задач в jira» — это не операция. Это внешнее проявления использования инструмента. И этот инструмент при взаимодействии с сотрудниками позволяет делать очень много операций — планирование, отслеживание, анализ, управление наконец. Лично у меня результатом более половины операций как ПМ результатом является тасование задач в Jira :). И я стараюсь увеличить это значение — не люблю зоопарк. Вот недавно плагин Tempo нашел и купил — очень хорошая штука для анализа всего, что связано с объемом работ и посещаемостью. Теперь вот вокруг плагина Structure ползаю — говорят, с ним хорошо над планированием работать.
  • +5
    Элияху Голдрат. В частности «Критическая цепь»
  • 0
    Опрос некорректен — нет пункта «ничего пока не прочитал»
  • 0
    Ммм, 9 из 13 прочтены, 2 из 9 «настольные книги», за оставшиеся, спасибо — изучу. От себя добавлю:

    Ф.И. Шарков, «Основы теории коммуникации» — мат. часть, после прочтения которой намного лучше понимаешь философию, психоанализ, социологию, маркетинг и экономику.

    Так же дам совет, который редко сам встречал — ПМ'ам прочитать альтернативную «евангелие» по современной теории и практики маркетинга — Джим Лисински, «ZMOT», во первых не лишне знать и понимать, как же все таки продается то что мы разрабатываем, (а это очень полезно, но мало кто ценит эту пользу!), во вторых многие эффективные маркетинговые методики можно «позаимствовать», при управлении командой. (Как это делается, понимаешь изучив теорию коммуникаций).
    • 0
      Приведите ссылку на эту книгу, пожалуйста.
      Поиск не помог…
      • +3
        Джим Лесински (Jim Lecinski) «Zero Moment of Truth»
        • 0
          Спасибо
      • +1
        Живет в закладках — korden.ru/uploads/zmot_ru.pdf :)
  • 0
    неплохо бы почитать книги про управление того же Адизеса
    по сути статьи: если взять специализацию (продуктовая или аутсорсинговая разработка), то специфика требований и необходимых знаний сильно будет разниться
  • +2
    Можно еще почитать А. М. Орлова Секреты управления программистами. Он тоже хорошо и легко пишет.
    • 0
      Огромное спасибо за рекомендацию и ссылки!
      «Не мешайте мне работать!» — это не хуже Джобса, только про «наших» со всей нашей спецификой управления проектами и персоналом.
      «Черную книгу» прочитать пока не успел, в плане на выходные :-)
  • +1
    Когда ждать результатов опроса, или кнопки просмотра результата? Для новичка, хотелось бы посмотреть что читают в первую очередь.
    • +1
      Думаю, через 1-2 дня выложу.
  • +2
    Не совсем понравился Ваш стиль изложения. В таком коротком тексте слишком много «нужно» и «должен». Сейчас никто никому ничего не должен, и требования к тимлидам в каждой отдельно взятой фирме разные. Чтобы быть хорошим тимлидом достаточно иметь природный талант к управлению людьми, понимать все процессы разработки, уметь использовать лучшие стороны каждого члена команды. А так же желательно иметь представление о каждой технологии, которую использует команда, хотя бы на том уровне чтобы адекватно ставить задачи.

    А все остальное приходит с опытом, и никак не с прочтением таких книг. Умный человек прочитав такие книги обязательно что-то для себя запомнит, а неумный будет расхаживать по офису и гордо рассказывать какой он крутой тимлид, ведь он прочитал все 13 книг из списка на хабре!

    P.S. Я не против чтения такой литературы, я против навязывания людям мнения о том, что без прочтения таких книг вы не станете хорошим специалистом.
    • 0
      Не хотелось бы, чтобы сложилось именно такое мнение из-за статьи.

      Но добавлю, что природный талант — это, конечно, хорошо, но речь как раз таки идет о том, как не будучи природженным менеджером прокачать немного скиллы. Естественно, специалист должен дружить с головой. Это необходимое, но не достаточное условие, чтобы стать хорошим менеджером.
  • +1
    Огромное спасибо за подборку. Как раз недавно начал ощущать, что попадаю в эти 9 из 10 и задумался о чтении специальной литературы, но даже спросить не у кого было что именно лучше читать.
  • +3
    Steve McConnell — Software Estimation: Demystifying the Black Art. Сам пока не читал, но планирую в ближайшее время.
    • 0
      Отличная книга, только тяжело читается из-за большого обилия таблиц и статистических данных. Но такова уж специфика оценки, без этого никак.
  • 0
    Макконел в своей книге в нескольких местах ссылается на «Мифический человеко-месяц». Кто читал ее — насколько актуальна она сегодня?
    • +1
      Я ее включил в список, т.к. на мой взгляд, есть вещи, которые до сих пор актуальны.
    • +1
      Например формула числа потенциальных взаимодействий вполне актуальна. Есть и другие.
    • +3
      Основные идеи вполне актуальны, а вот ссылки на конкретные случаи разработки ПО — изрядно устарели, нынче акценты не там ставятся.
    • +1
      По большей части — актуальна. Многие идеи, представленные в книге, касаются не конкретных методологий, технологий и т. п., а социальных взаимодействий.
      Многие таблички и ссылки, конечно, устарели, но дают общую картину. И провести аналогии с современностью не слишком тяжело.
  • +1
    А как iКона относится к тимлидерству и управлению проектами?
    • +1
      Напрямую — нет, но она хорошо описывает взлеты и падения как конкретных людей, так и компаний в целом.
  • +1
    Вот еще есть такая книга: Ньютон Р. «Управление проектами от А до Я». Рекомендую для начинающих. Книга — как детальный план руководства небольшим проектом в различных его фазах, представляет собой очень полезный пример — можно прямо брать формы из книги и заполнять задачами и трудоемкостью из своего проекта. Много нужного и ничего лишнего.
    Для «продвинутых» — Руководство к своду знаний по управлению проектами (PMBoK) — «Библия» менеджера проектов.
    Обе, однако, не учитывают российскую специфику (что не удивительно :).
  • +1
    Книга Макконела Rapid Development — одна из лучших, что я читал в этой сфере. Покрыты практически все области менеджмента проектов. Также существует более краткая версия с основными выдержками, без глубокого пояснения — Software Project Survival Guide.
  • +1
    Питер Друкер «Эффективный руководитель» — поможет понять, что проблема не в знании вами методик управления проектами, а в вас самих, какие вы есть.
    Стивен Кови «7 навыков высокоэффективных людей» — поможет понять, где именно надо над собой работать.
  • +1
    Странно, что нет:
    Русская модель управления. А. П. Прохоров. www.ozon.ru/context/detail/id/2804377/
    Жизнь внутри пузыря. Как менеджеру выжить в инвестируемом проекте. Игорь Ашманов. www.ozon.ru/context/detail/id/3799358/
    Тестирование Дот Ком, или Пособие по жестокому обращению с багами в интернет-стартапах. Роман Савин. www.ozon.ru/context/detail/id/3128208/
    Искусство управления IT-проектами. Скотт Беркун. www.ozon.ru/context/detail/id/4759145/
    Доставляя счастье. От нуля до миллиарда: история создания выдающейся компании из первых рук. Тони Шей. www.ozon.ru/context/detail/id/6298288/

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

Самое читаемое Разное