В книге поочередно описываются различные стадии менеджмента и мысли по переходу на эти стадии из программистов. Получается, что по факту интересна и применима только одна часть – твоя конкретная ступенька и следующая. Читать должностную инструкцию технического директора крупной корпорации в вакууме не особо полезно, когда ты только дорос до тимлида. Ну и субъективно карты, что эти главы написаны хуже. Но читать актуальные для себя части и главы по корпоративную культуру было интересно. Также книга добавляет пищи для размышлений при принятии решения оставаться в программистах или идти в менеджеры.
Hajm 371 sahifa
2017 yil
Kitob haqida
В этой книге технический директор и бывший вице-президент Goldman Sachs по технологиям Камиль Фурнье систематизировала свой опыт управления в IT-отрасли. Перед вами практическое руководство, из которого вы узнаете, как из инженера-программиста стать руководителем высшего звена. Автор описывает проблемы, с которыми сталкиваются менеджеры в IT-отраслях на разных ступенях карьеры, и предлагает решения.
Из этой книги можно выкинуть почти весь текст, оставив только заголовки и вопросы для самоконтроля, и она мало потеряет. Очень много рефлексии и раздумий, как нужно было бы поступить менеджеру в той или иной стандартной ситуации. Главы до 4 можно заменить словами «как я дошла до жизни такой». Самая ценная глава девятая, в ней содержание всей книги собрано в квинтэссенцию. К сожалению, этой книгой не заменить PMBoK, его знание (особенно раздела по этике) отлично решает все проблемы, с которыми столкнулась автор.
Она для тех, кто связан с IT. Кто только хочется войти в эту профессию, как руководство к действию ее воспринимать не стоит. Здесь нужен опыт и понимание работы изнутри. Чтобы правильно расставить приоритеты, скорректировать ошибки и разработать план действий. Для своей сферы медицинской подчерпнула общие методы управления и мотивации. Может, если решусь сменить вид деятельности к ней обращусь уже более прицельно.
Очередная книжка ради книжки. Да, автор вроде бы что-то знает, вроде бы даже понимает, о чем пишет. Но как же у нее всё плохо структурировано. Попадаются правильные мысли:
Быть хорошим руководителем — значит уметь правильно делегировать
Самые плохие микроменеджеры - те, кто постоянно запрашивает информацию, которую могут получить сами
Для себя, пожалуй, подчерпнул только пару момент для мотивации: 1. Расширять сеть контактов 2. Работать над софтами, в частности прокачивать навыки коммуникации.
Очень хорошая книга, позволяющая просмотреть различные этапы перехода от разработчика до руководителя. Книга очень интересна и полезна всем.
Izoh qoldiring
Я стала техническим руководителем группы (ведущим техническим специалистом) много лет назад. Сначала меня продвинули на должность старшего инженера, и я работала в небольшой команде других старших инженеров. Для меня стало сюрпризом, когда меня назначили руководителем группы, потому что я не была первой в своей группе ни по должности, ни по опыту. Оглядываясь назад, я вижу, что обладала несколькими преимуществами. Во-первых, я была больше чем просто хорошим программистом. Я обладала приличными коммуникативными навыками. Я могла писать понятные документы, делать презентации, не впадая в панику, беседовать с членами разных команд, находящимися на разных должностях, четко объясняя происходящее. Я также умела определять приоритеты, стремилась продвигать свою работу, самостоятельно решая, что должно было быть сделано. Наконец, я была готова собирать проекты по кусочкам и делать то необходимое, что обеспечивало прогресс. Однако я думаю, что решающим фактором в моем назначении было прагматическое соображение необходимости. Ведь должность технического руководителя
Возможно, самое краткое выражение сущности роли технического руководителя группы содержится в книге Патрика Куа «Разговор с техническими руководителями» (Talking with Tech Leads). Руководитель, отвечающий за работу команды программистов, проводит по крайней мере 30 % времени в написании кода вместе со своей группой
в программах, это тоже будет снижать способность работать на максимуме возможностей. Излишняя концентрация на разработке систем, свободных от дефектов, или насильственные меры, направленные исключительно на предотвращение ошибок путем замедления процессов разработки софта, зачастую имеют такие же негативные последствия, как и слишком быстрое движение вперед и выпуск ненадежного кода. Когда меры по снижению риска превращаются в недели ручной работы на контроле качества, медленную и излишнюю проверку кода, редкие релизы или растянутый процесс планирования, такой плотный контрольный процесс может позволить разработчикам не заниматься основным делом
Izohlar
5