Comments 53
А как же Getting real? Очень полезная книжица, почерпнул оттуда некоторые советы. Отрекомендовал в опроснике.
А вообще, не привык доверят списку книг, в котором 60% занимают работы двух авторов, попахивает неразборчивостью составителя.
А вообще, не привык доверят списку книг, в котором 60% занимают работы двух авторов, попахивает неразборчивостью составителя.
А что поделать, если Ленсиони и ДеМарко являюся специалистами мирового уровня и пишут мало, но в яблочко?
Для начинающих есть еще неплохая книга: «Как пасти котов» (Дж. Ханк Рейнвотер).
Не всем надо расти в тимлиды. Кто то растет в тимлиды, потом дальше в управление людьми, кто то в PM'ы, кто то в Tech Lead'ы и дальше в архитекторы.
Мне допустим тимлидом быть не нравилось, тратить кучу времени на звонки, переписку и заполнение табличек, когда техлидом можно больше времени заниматься разработкой, рефакторингом, инспекциями и менторингом. Зарплата при этом у этих позиций сопоставимая и из техлида можно расти в архитекторы. При этом техлид обычно не бегает как белка в колесе при авралах и отвечает только за себя и свои решения, в отличии от тимлидов :)
Мне допустим тимлидом быть не нравилось, тратить кучу времени на звонки, переписку и заполнение табличек, когда техлидом можно больше времени заниматься разработкой, рефакторингом, инспекциями и менторингом. Зарплата при этом у этих позиций сопоставимая и из техлида можно расти в архитекторы. При этом техлид обычно не бегает как белка в колесе при авралах и отвечает только за себя и свои решения, в отличии от тимлидов :)
Не всем надо расти в тимлиды.… Мне допустим тимлидом быть не нравилосьА узнали бы вы о том что это не ваше, если бы не попробовали?
техлиды, тимлиды, архитекторы, PM'ыТолько в больших конторах это разные люди.
А узнали бы вы о том что это не ваше, если бы не попробовали?
Вообще то меня изначально не тянуло руководить и отвечать за кого-то, у меня отец почти всю жизнь начальником работал и я представлял, что это такое. Так что я отказывался всегда, когда предлагали, но все равно пришлось поработать несколько месяцев пока штатный тимлид нашей комманды был в командировке. У нас кстати часто бывало, что тимлид не самый сильный разработчик в команде.
Только в больших конторах это разные люди.
Ну так я про них и говорю, у нас только в России было 1000+ разработчиков.
С другой стороны, не зависимо от того, будет чел тимлидом или нет, такие книги читать надо. Как минимум для того, чтобы разбираться в людях и компаниях. И понимать, как можно увеличить собственную эффективность.
Я бы добавил в эту коллекцию Дж. Ханк Рейнвотер «Как пасти котов» и книги Джоэла. Книга Фредерика Брукса немного устаревшей показалась, но в целом неплохо (первое издание этой книги 1975), для представления о том как создавали ПО 30 лет назад для разнообразия почитать можно, да и сейчас используют многие принципы тех далеких лет.
У вас не тим лид, а какая-то личинка ПМа. В то же время менеджмент — это совершенно не техническая специализация и совершенно не стоит тимлидов сажать в это прокрустово ложе насильно.
Все что я обычно требую от тим лидов — это соответствующие технические компетенции — он действительно должен быть лучшим в команде. Сделать сам или оценить чужую работу, неплохо бы уметь быть чуток дизайнером, что бы оценить работы, и совсем чуток ПМом что бы помочь ему в планировании.
Ответвенность же, коммуникации — это все равно зона ответственности ПМа или линейного менеджера. И его право, при возможности, делегировать эту часть на тимлида. Или не делегировать.
Все что я обычно требую от тим лидов — это соответствующие технические компетенции — он действительно должен быть лучшим в команде. Сделать сам или оценить чужую работу, неплохо бы уметь быть чуток дизайнером, что бы оценить работы, и совсем чуток ПМом что бы помочь ему в планировании.
Ответвенность же, коммуникации — это все равно зона ответственности ПМа или линейного менеджера. И его право, при возможности, делегировать эту часть на тимлида. Или не делегировать.
Соглашусь, тимлид как главный над программистами, product manager как человек который знает что мы делает и project manager как человек, который руководит процессом чтобы он таки завершился — это три совершенно разных компетенции. Безусловно, можно совмещать, и еще при этом программировать за троих — но это мало у кого получается и в целом не идет на пользу.
Я последние пять лет совмещаю должность project manager'а, тим лида, ночами иногда превращаюсь в программиста. И последние две роли мне совершенно не нравятся — но я вынужден их выполнять, потому что бюджет не позволят выделить отдельного человека ревьювить код и отслеживать общую архитектуру :(. Но если бы была такая возможность — я бы с удовольствием переложил эти почетные обязанности и сконцентрировался исключительно на тасовании задач в Jira и общении с людьми. А программирование было бы хобби :).
Я последние пять лет совмещаю должность project manager'а, тим лида, ночами иногда превращаюсь в программиста. И последние две роли мне совершенно не нравятся — но я вынужден их выполнять, потому что бюджет не позволят выделить отдельного человека ревьювить код и отслеживать общую архитектуру :(. Но если бы была такая возможность — я бы с удовольствием переложил эти почетные обязанности и сконцентрировался исключительно на тасовании задач в Jira и общении с людьми. А программирование было бы хобби :).
Надеюсь, вы не отождествляете управление проектами (в т.ч. софтверными) с «тасованием задач в Jira» ;-)
Нет, но это очень важная часть управления проектами.
Если совмещать позицию тимлида и ПМа, то да. Но ПМ совершенно не обязательно должен быть техническим специалистом, а без этого как он разберётся кому что поручить? А как потом проверять и контролировать? Это задача в большей степени тимлида (-ов).
Если стоит задача как можно коротко, но ёмко определить деятельность руководителя проектов, то я бы сказал, что это нахождение баланса между ограничениями проекта. А конкретных операций там вагон и маленькая тележка – полистайте PMBoK например.
Если стоит задача как можно коротко, но ёмко определить деятельность руководителя проектов, то я бы сказал, что это нахождение баланса между ограничениями проекта. А конкретных операций там вагон и маленькая тележка – полистайте PMBoK например.
Если стоит задача как можно коротко, но ёмко определить деятельность руководителя проектов, то я бы сказал, что это нахождение баланса между ограничениями проекта. А конкретных операций там вагон и маленькая тележка – полистайте PMBoK например.
При всем моем уважении, «тасование задач в jira» — это не операция. Это внешнее проявления использования инструмента. И этот инструмент при взаимодействии с сотрудниками позволяет делать очень много операций — планирование, отслеживание, анализ, управление наконец. Лично у меня результатом более половины операций как ПМ результатом является тасование задач в Jira :). И я стараюсь увеличить это значение — не люблю зоопарк. Вот недавно плагин Tempo нашел и купил — очень хорошая штука для анализа всего, что связано с объемом работ и посещаемостью. Теперь вот вокруг плагина Structure ползаю — говорят, с ним хорошо над планированием работать.
Элияху Голдрат. В частности «Критическая цепь»
Опрос некорректен — нет пункта «ничего пока не прочитал»
Ммм, 9 из 13 прочтены, 2 из 9 «настольные книги», за оставшиеся, спасибо — изучу. От себя добавлю:
Ф.И. Шарков, «Основы теории коммуникации» — мат. часть, после прочтения которой намного лучше понимаешь философию, психоанализ, социологию, маркетинг и экономику.
Так же дам совет, который редко сам встречал — ПМ'ам прочитать альтернативную «евангелие» по современной теории и практики маркетинга — Джим Лисински, «ZMOT», во первых не лишне знать и понимать, как же все таки продается то что мы разрабатываем, (а это очень полезно, но мало кто ценит эту пользу!), во вторых многие эффективные маркетинговые методики можно «позаимствовать», при управлении командой. (Как это делается, понимаешь изучив теорию коммуникаций).
Ф.И. Шарков, «Основы теории коммуникации» — мат. часть, после прочтения которой намного лучше понимаешь философию, психоанализ, социологию, маркетинг и экономику.
Так же дам совет, который редко сам встречал — ПМ'ам прочитать альтернативную «евангелие» по современной теории и практики маркетинга — Джим Лисински, «ZMOT», во первых не лишне знать и понимать, как же все таки продается то что мы разрабатываем, (а это очень полезно, но мало кто ценит эту пользу!), во вторых многие эффективные маркетинговые методики можно «позаимствовать», при управлении командой. (Как это делается, понимаешь изучив теорию коммуникаций).
Приведите ссылку на эту книгу, пожалуйста.
Поиск не помог…
Поиск не помог…
Джим Лесински (Jim Lecinski) «Zero Moment of Truth»
Живет в закладках — korden.ru/uploads/zmot_ru.pdf :)
неплохо бы почитать книги про управление того же Адизеса
по сути статьи: если взять специализацию (продуктовая или аутсорсинговая разработка), то специфика требований и необходимых знаний сильно будет разниться
по сути статьи: если взять специализацию (продуктовая или аутсорсинговая разработка), то специфика требований и необходимых знаний сильно будет разниться
Можно еще почитать А. М. Орлова Секреты управления программистами. Он тоже хорошо и легко пишет.
Когда ждать результатов опроса, или кнопки просмотра результата? Для новичка, хотелось бы посмотреть что читают в первую очередь.
Не совсем понравился Ваш стиль изложения. В таком коротком тексте слишком много «нужно» и «должен». Сейчас никто никому ничего не должен, и требования к тимлидам в каждой отдельно взятой фирме разные. Чтобы быть хорошим тимлидом достаточно иметь природный талант к управлению людьми, понимать все процессы разработки, уметь использовать лучшие стороны каждого члена команды. А так же желательно иметь представление о каждой технологии, которую использует команда, хотя бы на том уровне чтобы адекватно ставить задачи.
А все остальное приходит с опытом, и никак не с прочтением таких книг. Умный человек прочитав такие книги обязательно что-то для себя запомнит, а неумный будет расхаживать по офису и гордо рассказывать какой он крутой тимлид, ведь он прочитал все 13 книг из списка на хабре!
P.S. Я не против чтения такой литературы, я против навязывания людям мнения о том, что без прочтения таких книг вы не станете хорошим специалистом.
А все остальное приходит с опытом, и никак не с прочтением таких книг. Умный человек прочитав такие книги обязательно что-то для себя запомнит, а неумный будет расхаживать по офису и гордо рассказывать какой он крутой тимлид, ведь он прочитал все 13 книг из списка на хабре!
P.S. Я не против чтения такой литературы, я против навязывания людям мнения о том, что без прочтения таких книг вы не станете хорошим специалистом.
Не хотелось бы, чтобы сложилось именно такое мнение из-за статьи.
Но добавлю, что природный талант — это, конечно, хорошо, но речь как раз таки идет о том, как не будучи природженным менеджером прокачать немного скиллы. Естественно, специалист должен дружить с головой. Это необходимое, но не достаточное условие, чтобы стать хорошим менеджером.
Но добавлю, что природный талант — это, конечно, хорошо, но речь как раз таки идет о том, как не будучи природженным менеджером прокачать немного скиллы. Естественно, специалист должен дружить с головой. Это необходимое, но не достаточное условие, чтобы стать хорошим менеджером.
Огромное спасибо за подборку. Как раз недавно начал ощущать, что попадаю в эти 9 из 10 и задумался о чтении специальной литературы, но даже спросить не у кого было что именно лучше читать.
Steve McConnell — Software Estimation: Demystifying the Black Art. Сам пока не читал, но планирую в ближайшее время.
Макконел в своей книге в нескольких местах ссылается на «Мифический человеко-месяц». Кто читал ее — насколько актуальна она сегодня?
Я ее включил в список, т.к. на мой взгляд, есть вещи, которые до сих пор актуальны.
Например формула числа потенциальных взаимодействий вполне актуальна. Есть и другие.
Основные идеи вполне актуальны, а вот ссылки на конкретные случаи разработки ПО — изрядно устарели, нынче акценты не там ставятся.
По большей части — актуальна. Многие идеи, представленные в книге, касаются не конкретных методологий, технологий и т. п., а социальных взаимодействий.
Многие таблички и ссылки, конечно, устарели, но дают общую картину. И провести аналогии с современностью не слишком тяжело.
Многие таблички и ссылки, конечно, устарели, но дают общую картину. И провести аналогии с современностью не слишком тяжело.
А как iКона относится к тимлидерству и управлению проектами?
Вот еще есть такая книга: Ньютон Р. «Управление проектами от А до Я». Рекомендую для начинающих. Книга — как детальный план руководства небольшим проектом в различных его фазах, представляет собой очень полезный пример — можно прямо брать формы из книги и заполнять задачами и трудоемкостью из своего проекта. Много нужного и ничего лишнего.
Для «продвинутых» — Руководство к своду знаний по управлению проектами (PMBoK) — «Библия» менеджера проектов.
Обе, однако, не учитывают российскую специфику (что не удивительно :).
Для «продвинутых» — Руководство к своду знаний по управлению проектами (PMBoK) — «Библия» менеджера проектов.
Обе, однако, не учитывают российскую специфику (что не удивительно :).
UFO just landed and posted this here
Питер Друкер «Эффективный руководитель» — поможет понять, что проблема не в знании вами методик управления проектами, а в вас самих, какие вы есть.
Стивен Кови «7 навыков высокоэффективных людей» — поможет понять, где именно надо над собой работать.
Стивен Кови «7 навыков высокоэффективных людей» — поможет понять, где именно надо над собой работать.
Странно, что нет:
Русская модель управления. А. П. Прохоров. 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/
Русская модель управления. А. П. Прохоров. 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/
Sign up to leave a comment.
Книги для тимлидов и руководителей проектов