Как управлять котиками книга
Как пасти котов. Наставление для программистов, руководящих другими программистами
Посоветуйте книгу друзьям! Друзьям – скидка 10%, вам – рубли
Эта и ещё 2 книги за 299 ₽
«Как пасти котов» – это книга о лидерстве и руководстве, о том, как первое совмещать со вторым. Это, если хотите, словарь трудных случаев управления IT-проектами. Программист подобен кошке, которая гуляет сама по себе. Так уж исторически сложилось. Именно поэтому так непросто быть руководителем команды программистов. Даже если вы еще месяц назад были блестящим и дисциплинированным программистом и вдруг оказались в роли менеджера, вряд ли вы знаете, с чего надо начать, какой выбрать стиль руководства, как нанимать и увольнять сотрудников, проводить совещания, добиваться своевременного выполнения задач. В таком случае без этой книги вам не обойтись. А может быть, вы – опытный менеджер, желающий пересмотреть свои принципы лидерства? Тогда, опять же, эта книга для вас. Вне зависимости от возраста, пола и социального статуса, она поможет вам укрепить свои позиции в роли лидера программистов. Материал изложен довольно компактно и легко укладывается в голове. Стоя в книжном магазине и раздумывая, что же купить, задайте себе один простой вопрос: «Нужно ли мне совершенствовать свои лидерские навыки?» Полагаю, вы ответите: «Да», – а значит, данная книга окажется для вас небесполезной.
Имейте в виду, что невежество очень опасно. Самое страшное – это когда человек упорствует в своем невежестве, выдавая его за принцип; такое поведение иначе как глупостью не назовешь.
Имейте в виду, что невежество очень опасно. Самое страшное – это когда человек упорствует в своем невежестве, выдавая его за принцип; такое поведение иначе как глупостью не назовешь.
(Про многозадачность) Если бы у нас вместо мозгов были микропроцессоры, в которых при «прерывании» предусматривается сохранение состояния системы, параллельное исполнение многочисленных заданий не составляло бы для нас такой проблемы. Мы можем сколь угодно хвастаться способностью делать несколько дел одновременно, однако, как правило, качество исполнения каждого из них оставляет желать лучшего.
(Про многозадачность) Если бы у нас вместо мозгов были микропроцессоры, в которых при «прерывании» предусматривается сохранение состояния системы, параллельное исполнение многочисленных заданий не составляло бы для нас такой проблемы. Мы можем сколь угодно хвастаться способностью делать несколько дел одновременно, однако, как правило, качество исполнения каждого из них оставляет желать лучшего.
Книги нужны не только для того, чтобы украшать полки или произвести впечатление на ваших друзей. Хорошие книги – это жизненные откровения. Научитесь определять, кто из авторов обращается непосредственно к вам, и слушайте то, что он пытается до вас донести.
Книги нужны не только для того, чтобы украшать полки или произвести впечатление на ваших друзей. Хорошие книги – это жизненные откровения. Научитесь определять, кто из авторов обращается непосредственно к вам, и слушайте то, что он пытается до вас донести.
Программирование не ограничивается написанием кода, оно также предполагает обеспечение его реального функционирования.
Программирование не ограничивается написанием кода, оно также предполагает обеспечение его реального функционирования.
Как пасти котов. Наставление для программистов, руководящих другими программистами
Скачать книгу
О книге «Как пасти котов. Наставление для программистов, руководящих другими программистами»
Можно хорошо разбираться в том, что ты делаешь, но это не гарантирует того, что ты сможешь стать хорошим руководителем. Мало понимать, что именно нужно делать, нужно уметь общаться с людьми, выстраивать отношения с сотрудниками, понимать друг друга. Книга Дж. Ханка Рейнвотера предназначена для программистов, которые стали руководителями и должны управлять другими программистами. Автор говорит о том, что программист напоминает кошку, которая гуляет сама по себе, и к ней ещё нужно найти подход. А если это группа таких программистов, то задача усложняется.
В книге советы, которые проверены автором на собственном опыте. Это не теория, а то, что может пригодиться на практике. Здесь рассмотрено, как привыкать к роли руководителя, какие изменения нужно принять. Показано, что сначала нужно научиться руководить самим собой, а потом уже управлять другими. Автор даёт рекомендации, как стать тем, за кем люди будут охотно идти, чьи слова будут слушать, как привести команду к успеху. Книга поможет выбрать стиль руководства, понять, как нанимать и увольнять сотрудников, проводить совещания и многое другое. Есть главы о закате и восходе лидера, об ошибках, которые можно совершить, и советы, как этого избежать.
Книга даёт понимание, что все люди разные, и прежде всего нужно искать подход к человеку и только потом говорить о том, что требуется сделать. Грамотный контроль, умение построить отношения с подчинёнными и своим начальством, эффективность работы команды – всё это рассмотрено в книге с учётом специфики IT-сферы. Книга будет полезна тем программистам, которые недавно стали менеджерами и ещё не знают, что делать. Также в ней могут найти полезное менеджеры, работающие в других сферах.
На нашем сайте вы можете скачать книгу «Как пасти котов. Наставление для программистов, руководящих другими программистами» Дж. Ханк Рейнвотер бесплатно и без регистрации в формате fb2, rtf, epub, pdf, txt, читать книгу онлайн или купить книгу в интернет-магазине.
Мнение читателей
Автор в очень дружелюбной манере рассказывает о том, как стать хорошим менеджером, оставаясь при этом увлеченным специалистом
Разбор типичных личностей, дополненный опытом автора и забавными историями из жизни делают книгу легкой, но интересной
Книга посвящена тому как организовать работу в коллективе, руководить людьми, развить лидерские качества, проблемам взаимоотношений
Как управлять котиками книга
Как пасти котов. Наставление для программистов, руководящих другими программистами
Herding Cats: A Primer for Programmers Who Lead Programmers
© Перевод на русский язык ООО Издательство «Питер», 2008
© Издание на русском языке, оформление ООО Издательство «Питер», 2016
© Серия «Библиотека программиста», 2016
Посвящается Дэвиду, моему любимому сыну, – память о тебе меня неизменно вдохновляет.
Жаль, что тебя нет, и я никогда больше не увижу, как ты смеешься…
Прочитав замечательную книгу Хэнка, в которой он рассказывает о выпасе котов, я вспомнил то время (а было это… ну очень давно), когда из программиста меня перевели в менеджеры. Подобно вам, читатели, я был в высшей степени самоуверенным программистом-аналитиком. Я специализировался на языке PLI и базах данных IMS DB/DC. Прибавить к этому понемногу Ramis, FOCUS, Easytrieve Plus, Datacom/IDEAL, CICS, VSAM – и получится вполне сформировавшийся программист, пишущий для мэйнфреймов. Сегодняшние кодировщики могут с полным правом относить эти технологии к древней истории, но, смею вас уверить, в те времена по крайней мере некоторые из них были очень даже ничего!
Подобно Хэнку, я сначала взял на себя неофициальные обязанности координатора и наставника своих коллег – в основном, молодых сотрудников. Впоследствии эти полномочия были закреплены за мной уже формально. Таким образом, я начал сочетать полную ставку программиста-аналитика с полноценным руководством. После этого мне открылись как положительные, так и отрицательные стороны менеджмента. Помню, собрались мы – я и еще несколько таких же менеджеров – как-то раз на совещание с начальником. Начальник говорил о том, какие у него на наш счет большие ожидания, о необходимости повышать нашу квалификацию как руководителей. Одна из моих коллег в ответной речи выразила крайне распространенную среди молодых менеджеров позицию. Она заявила, что могла бы стать значительно лучше как руководитель, будь у нее в подчинении более приемлемый персонал.
Не всегда понятно, почему некоторые вещи крепко оседают в памяти на долгие годы, и как раз ее фразу я никак не могу забыть. Полагаю, будь в нашем распоряжении тогда учебник вроде того, что написал Хэнк, переход к менеджерским обязанностям прошел бы значительно менее болезненно. В конце концов, кто мы такие были? Программисты, которым поручили координировать деятельность других программистов. В результате былые приятельские отношения испарились – будто их никогда и не было. Мне совершенно не хотелось менять свое отношение к коллегам, но без этого контролировать их поведение я не мог. Мы остались друзьями, но эти отношения перешли на другой уровень, что ли, и назад пути уже не было.
Сегодня, по прошествии многих лет, я счастлив, что в роли лидера команды разработчиков, руководителя проектов, руководителя группы, руководителя отдела и директора мне приходится координировать действия более чем 200 людей. За счет посещения разного рода курсов и семинаров мне удалось усовершенствовать навыки руководителя. Наконец, слава богу, что пользу от чтения книг по менеджменту я осознал довольно рано. В конце концов, личность в сегодняшних условиях – это опыт плюс прочитанная литература.
Мой опыт перехода из программистов в руководители позволяет в полной мере оценить предложения, высказанные Хэнком в его книге. Его стараниями любой специалист, находящийся в аналогичном положении, может рассчитывать на существенную помощь. Уже в первой главе Хэнк попадает в десятку утверждением: «то, что делаешь ты, не обязательно буду делать я». В самом деле, не с этим ли связаны все те разочарования, которые мы испытываем в период адаптации к роли руководителя? Если вы принимаете эту проблему близко к сердцу, поверьте мне – Хэнк поможет вам преодолеть подобного рода затруднения.
Попробую перефразировать мою бывшую коллегу: заниматься менеджментом было бы значительно проще, если бы все подчиненные были как две капли воды похожи на своего начальника. К счастью, это не так. Люди руководствуются разными мотивами, у них разный уровень знаний, и понять, что движет тем или иным деятелем, не так-то просто. Различия не превозносят одного человека над другим – просто все мы разные. Что делает руководитель? Он координирует и ведет всех этих «котов», которые гуляют сами по себе. Понимать, как коты себя ведут и как общаются между собой, совершенно необходимо – иначе эффективного лидерства не получится.
Вспоминается мой разговор с начальником о трудностях, причиной которых стал еще один руководитель из числа бывших программистов. Начальник тогда заявил мне буквально следующее: «Том, пока я сижу на этом месте, никто из программистов больше не станет менеджером!» Где-то через год, во время моего отчета перед новым начальником, мы принялись обсуждать одного из технических руководителей, которому удалось добиться поразительных успехов по части организации и мотивирования своих сотрудников. Этот начальник резюмировал свои соображения так: «Том, я думаю, что впредь всех руководителей нам следует набирать из числа технарей».
Эти диаметрально противоположные точки зрения лишний раз доказывают, что нет двух совершенно одинаковых людей. У всех разные таланты, способности, желания и наклонности. Вы, помимо других, должны разобраться в собственных достоинствах и недостатках (см. главу 2) и задействовать свои навыки таким образом, чтобы обеспечить успешную деятельность группы в целом (см. главу 3). Программисты, которым приходится впервые брать на себя обязанности по руководству другими программистами, обнаруживают себя на перекрестье профессий. Некоторые на постоянной основе переходят к менеджерской деятельности. Другие склоняются к программированию, поскольку в этой области от них больше толку. Остальных устраивает промежуточная позиция между руководителем и кодировщиком.
Если оставить в этой книге только три первые главы, а все остальное выкинуть, все равно ее стоило бы прочесть (ее объем, конечно, сильно бы уменьшился). Однако и остальные главы тоже весьма интересны, поскольку Хэнк рассматривает в них чрезвычайно актуальные для молодых руководителей вопросы.
С одной стороны, он говорит о том, что теперь у вас есть формальные административные обязанности. Навыки руководства людьми в контексте успешной деятельности компании очень важны, но, с другой стороны, именно административные вопросы обеспечивают плавное вращение коммерческого маховика. Вам предстоит постоянно заниматься поиском информации и составлять рецензии на выполненные задания. В рамках подведомственной группы вы находитесь на вершине иерархии управления. Лишь за счет дисциплины и самоорганизации люди справляются с административными функциями. Если эти качества в вашем характере отсутствуют, вы станете слабым звеном административного механизма, и ваш собственный начальник будет вынужден постоянно вас подталкивать. Скажите спасибо Хэнку за объяснение стандартной роли администратора – это объяснение помогает понять, что такое же бремя несут многие ваши коллеги.
Глава 5, посвященная проведению совещаний, затрагивает очевидно недооцененный комплекс приемов. Сама постановка вопроса о продуманной организации совещаний заслуживает уважения. Случалось ли вам посещать совещания, не преследующие конкретной цели и никем не управляемые? (Вероятно, этот вопрос лучше переформулировать так: «Каков процент посещенных вами совещаний, которые проводились подобным образом?») Если случалось, теперь вы знаете, почему так происходит: на этих совещаниях никто не проявил активной руководящей позиции. Если вам удастся при проведении совещаний взять на себя лидерство, сделав их тем самым более продуктивными и сориентированными на конкретные задачи, скажите спасибо Хэнку.
Дж. Х. Рейнвотер «Как пасти котов»: породы программистов и особенности их разведения
Об управлении людьми в целом на сегодняшний день сказано уже немало (по мнению многих, более чем достаточно). Об управлении программистами с учетом специфики их задач, организации работы и внутренних отношений в команде – в разы меньше. Любая попытка обобщить и проанализировать свой опыт от человека, который варился в IT-среде и как разработчик, и как управленец, имеет особую ценность для тех, кто готовится пройти тем же путем и ломает голову, как приложить общеуправленческие теории к программистским реалиям.
Дж. Ханк Рейнвотер, программист старой закалки, относится к числу людей, которые знают все топкие места в роли технического лидера наперечет, потому что сами в них плавали. Его книга «Как пасти котов» подкупает своей предметностью: здесь описываются конкретные, хорошо всем знакомые ситуации, разбираются по косточкам разные составляющие и условия работы команды, даже приводятся авторские технологические решения (к сожалению, уже устаревшие). В небольшом цикле статей мы планируем осветить все, что нам показалось наиболее полезным и актуальным в книге – от типологии сотрудников до рекомендаций по общению с другими командами.
Начать стоит с резонного вопроса: почему, собственно, коты? Сам автор в качестве пояснения ссылается на цитату Элен Алман, которая проводит эту аналогию в своей книге Close to the Machine:
«Один из моих знакомых руководителей проектами однажды сравнил процесс управления программистами с выпасом котов. Он хотел сказать, что песики, преданно заглядывающие в глаза, нам совершенно не нужны. Хорошего программиста нужно ценить вместе со всеми его странностями. С другой стороны, всех этих хороших программистов нужно каким-то образом заставлять двигаться в одном направлении».
Программистов роднит с котами, прежде всего, то, что ни те, ни другие не имеют врожденной склонности сбиваться в стаи. Они предпочитают гулять сами по себе, и сложившаяся в IT-сфере культура долгое время поощряла такой тип поведения (или, по крайней мере, никак ему не препятствовала). Соответственно, перед техническим руководителем стоит вдвойне сложная задача: чтобы организовать одиночек в более-менее сплоченную группу, не попирая их индивидуальность, скорее всего, придется оттачивать и свои собственные навыки работы с людьми.
Рейнвотер определяет свою целевую аудиторию следующим образом: новички в управлении (вчерашние разработчики, получившие руководящую должность), руководители небольших команд (до десяти человек), работающих над несколькими проектами, из малого или среднего бизнеса. Для более крупных масштабов некоторые техники уже не подойдут, а более опытные технические лидеры уже, вероятно, многое вывели для себя сами. Книга призвана помочь руководителю в самый острый переходный период и подготовить к грядущим переменам.
Если смотреть широко, управленец-новичок сталкивается с двумя крупными проблемами: новая должность коренным образом трансформирует механизмы его взаимодействия, во-первых, с людьми, во-вторых, с процессами. О втором мы подробно будет говорить позже, но об одной распространенной одной ошибке следует упомянуть сразу.
Очень многие не могут смириться с тем, что им придется отдать часть своих задач, связанных с написанием кода, причем чем сильнее программист, тем сильнее это чувство протеста. Усугубляет ситуацию еще и новое ощущение ответственности за весь код, который производит команда. В итоге, вместо того чтобы перераспределять время и отдавать часы административной работе, руководитель с головой уходит в заботы о технической стороне проектов – сам делает все обзоры, дотошно проверяет оформление, а то и переписывает неудачные фрагменты. Самые упорные пренебрегают всеми остальными обязанностями, не связанными напрямую с кодом, и это заканчивается катастрофой. Более трезвомыслящие превращаются в оборотней: днем руководитель, ночью программист, и это кончается выгоранием.
По этой причине первое, что предстоит сделать техническому лидеру – осознать и принять неизбежность изменений в структуре работы и настроиться на довольно длительный период «ломки». Автор оценивает срок адаптации примерно в шесть месяцев – только к этому времени большинство привыкает к новой роли и начинает комфортно себя в ней чувствовать. Утешаться можно тем, что определение «технический» – не пустой звук: тот, кто ведет за собой разработчиков, просто не может позволить себе совсем отойти от работы с технологиями, так что опасаться, что управленческая деятельность ее вытеснит, не приходится.
Теперь перейдем ко второму источнику изменений – работе с людьми. В позиции лидера программисту приходится не только ладить с членами команды, но и, говоря грубо, использовать их как ресурс – выявлять, кто на что способен, и направлять эти способности туда, где они нужнее всего. Таким образом, задача распадается на две части: нужно уметь разбираться в людях и уметь с ними общаться.
Чтобы помочь читателю с первым пунктом, Рейнвотер предлагает классификацию «пород» IT-котов, которую выстроил исходя из собственного опыта и наблюдений. Его список пород обобщает регулярно встречающиеся типы разработчиков с яркими отличительными особенностями, сильными и слабыми сторонами. Как и любую другую, эту классификацию не стоит воспринимать как абсолютный эталон – в дикой природе типы часто смешиваются и перекрещиваются, бывают выражены более и менее ярко. Тем не менее, это полезная отправная точка для анализа интеллектуальных и личностных характеристик своих программистов.
Породы автор разделяет на три группы: распространенные (попадаются чаще всего), редкие (попадаются от случая к случаю) и дворняги (в своем исходном виде несут меньше ценности, чем общая масса).
Распространенные породы
Любимец большинства руководителей. Сосредотачивается на общей структуре кода, идет от анализа и абстрактных построений к реализации конкретных решений под них в коде. Сильная сторона – генерирует удачные идеи, иногда может вести проект в одиночку, от замысла до конечного вида (хотя отдельные особи теряют интерес после того, как общая структура намечена и отдают «ремесленную» работу разработчикам низшего уровня). Слабая сторона – нередко выдает путаный, малопонятный код со странными конструкциями, который слушается только хозяина и с большим трудом поддается поддержке со стороны.
Получает искреннее удовольствие от самого процесса программирования, стремится к хорошему результату. К стратегическому планированию обычно равнодушен, код пишет по наитию, не слишком задумываясь над общей логикой. На коротких дистанциях это не слишком вредит и на качество работы конструктивиста можно положиться. Когда проект разрастается, недостаток внутренней логики обычно начинает сказываться и в ход идут «заплаточные» решения – напоминаем, конструктивист очень нацелен на результат. Отлично работает в связке с архитектором. Документирует неохотно («все и так понятно»), но при должной настойчивости руководителя – вполне добротно.
Тоже познал радость написания кода, но его стихия – поиск неожиданных, изящных решений для реализации заданных требований. С логикой и организацией, как правило, проблем не возникает. Основной недостаток – излишняя любовь к искусству и экспериментированию, которая побуждает растягивать простые задачи и срывать сроки. Имеет некоторое сходство и с архитектором, и с конструктивистом, но обычно выделяется ярким индивидуальным стилем программирования.
Рассматривает разработку ПО как виртуальный аналог сборки «железа» со всеми вытекающими последствиями. Очень любит прилаживать одно к другому, собирать разрозненные модули в сложную структуру так, чтобы все работало, находить в построенной системе место для решений от третьих сторон. Навыки, безусловно, полезные, но есть дать инженеру увлечься, сложность может превратиться для него в самоцель. Чрезмерное усложнение и недостаточная гибкость продуктов – два уязвимых места этой породы.
В противовес художникам, рассматривает программирование как точную науку – старается во всем следовать фундаментальным принципам и избегать «отсебятины». Очень педантичен, стремится довести код до совершенства и добиться корректной работы в любых условиях, часто в ущерб практическим соображениям. Как и инженер, склонен излишне все усложнять. Зато когда дело доходит до по-настоящему сложных задач, требующих скрупулезности и багажа знаний, ему цены нет.
Ставит скорость превыше всего, включая и качество кода. Пренебрегает мелочами вроде комментирования, корректного оформления, следования принятым регламентам. На первый взгляд, выдает неплохой, вполне рабочий результат, но глубокое тестирование выявляет массу проблем. Как ни печально, эта порода культивирована самими руководителями: лихачи чаще всего получаются из молодых программистов, которым внушают ложные приоритеты и которые боятся не соответствовать ожиданиям.
Редкие породы
В современной терминологии волшебника обычно называют рок-звездой. Берется за сложнейшие задачи и справляется, находит революционные пути решения проблем, делает все в срок и качественно. Даже с сопровождением его кода особых трудностей обычно не возникает. В общем, все вроде бы замечательно, но техническому лидеру нужно держать ухо востро в двух отношениях. Во-первых, нельзя допускать излишней зависимости от волшебника – вся команда, включая руководителя, рискует превратиться в подтанцовку для одного сотрудника. Во-вторых, нужно быть готовым к тому, что в один прекрасный день волшебник вас все-таки разочарует – стабильно творить чудеса не может никто. К такой возможности нужно относиться спокойно и иметь запасной план.
Пишет на удивление функциональный код очень скромных объемов. Все стройно выглядит, четко выстроено и недвусмысленно сообщает о своем назначении. Эта порода очень капризна в выборе задач и проектов; минималист будет больше других бороться за право устанавливать область приложения своих способностей. Слабое место – сопровождение. Изо всех сил сопротивляется необходимости вносить правки в свой код (не говоря уж о чужом) – ему просто неинтересно возиться с частностями, когда основное уже сделано.
Отличается конкретным мышлением, компенсирует свои сложности с абстракциями любовью к аналогиям. На совещаниях уловить ход его мысли бывает тяжеловато, но суть дела он схватывает быстро. Как правило, пишет хороший, удобный для поддержки код, но в некоторых случаях непонимание абстракция может его тормозить. Бывает и такое, что аналогии подводят, особенно если аналогист выделяет из всех какую-то одну любимую, которую пытается натянуть на все подряд. Уравновесить недостатки аналогиста можно, поставив его в пару с архитектором – они либо поубивают друг друга, либо создадут нечто выдающееся.
Любит эффектные трюки и постоянно находится в погоне за технологическими новинками, которые их поставляют. Никакой реальной отдачи от этого увлечения, по сути, нет: трюкач не умеет мыслить прагматически, фактическая ценность той или иной технологии для конечного продукта и пользователя остается для него скрытой. Этого сотрудника нужно будет постоянно контролировать и перенаправлять его энтузиазм на первоочередные задачи.
Дворняги
Рейнвотер выделяет дворняг в отдельную категорию как котов с какими-то очевидными изъянами, перевесом слабых сторон относительно сильных. Но он не призывает избавляться от них не глядя. Многие из дворняг вполне поддаются дрессировке и могут постепенно переквалифицироваться в другие породы. Ниже мы приводим прогнозы и рекомендации для разных типов.
Главный поставщик небрежного, неряшливого кода. Часто перескакивает со стиля на стиль. Как и лихач, приносит в жертву оформление и следование принятым в команде соглашениям, но, в отличие от лихача, не может оправдаться даже высокой скоростью работы. Именно его код иногда приходится переписывать с нуля – настолько изнурительно и ресурсозатратно в нем разбираться.
Разгильдяйство бывает острым и хроническим. Если оно напало на сотрудника внезапно, возможно, это объясняется проблемами личного характера. Если же это обычное для него состояние, стоит задуматься, имеет ли смысл тратить время на переобучение. Основной критерий здесь – желание и готовность разгильдяя прилагать усилия. Разгильдяй, который в целом получает удовольствие от своей работы, при должном внимании со стороны руководителя или наставника вполне может реабилитироваться и освоить более эффективные методы работы.
Подолгу не может взяться за задачу, не знает, с чего начать, гоняется за спецификациями в отчаянной надежде, что они внесут какую-то ясность. Как не сложно догадаться, нерешительность тормоза происходит от неуверенности в себе. Действовать здесь нужно основываясь на том, откуда появилась эта неуверенность. Если разработчик с треском проваливался в прошлом и теперь панически боится неудач, пусть у него будет возможность проявить себя хотя бы в небольших и несложных задачах, чтобы этот страх постепенно ушел. Если дело в неопытности, то со временем и известной поддержкой команды все, вероятно, нормализуется само собой. Если же подобная нерешительность – просто свойство характера, проще всего дать бедняге образец, который поможет ему выбрать стиль и взяться за работу.
Любителю не хватает знаний, зато мотивации обычно – хоть отбавляй. У этой разновидности дворняг больше всего шансов выбиться в хорошие разработчики. Однако за их прогрессом нужно пристально следить – оценивать способности, фиксировать достижения, которые дают основания отправить их на более ответственные задачи. Не следует также слишком завышать ожидания: многие выдыхаются, столкнувшись с трудностями или неизбежной рутиной в работе программиста. Вообще говоря, у любителей есть и свои плюсы – в первую очередь, пресловутый свежий, незашоренный взгляд, хотя дожидаться, пока они наступят на все грабли и постигнут прописные истины, временами бывает утомительно.
Производит впечатление попросту туповатого. Обычно такие достаются новому руководителю в наследство от старого, история их водворения в команде остается загадкой. Сделать для таких что-то сложно – разработка требует постоянного самосовершенствования, которое они просто не потянут. Если профан сам осознает свой уровень и не отличается неадекватными амбициями, можно попробовать пристроить его в отдел тестирования – иногда низкие способности не мешают людям исправно находить баги. С теми же, кто о своей недалекости даже не догадывается, лучше вообще не иметь дела.
Ядерная смесь инженера, разгильдяя и не слишком талантливого художника. Код, который он пишет – неудобоваримый винегрет из разных стилей и модулей. В отличие от продуктов разгильдяйского труда, это код с претензией на талантливость – с виду может показаться, что в нем даже что-то есть, пока не попробуешь запустить. Главный вопрос человека, читающего код эклектика: «Что он имел в виду?». Чтобы исправить положение, необходимо сначала понять, действительно ли эта путаница является результатом каких-то исканий или же перед вами попытка разгильдяя замести следы. Доброкачественным эклектикам приносят большую пользу систематические обзоры кода.
Наконец, есть еще одна порода, которая стоит особняком от остальных во всех смыслах – это ковбой или волк-одиночка. Кошачьи повадки доходят у него до высшей степени. В своем ремесле ковбой, как правило, очень хорош (иначе ему просто не удержаться на месте), в командной работе – абсолютно безнадежен. Его отличает решимость играть только по своим правилам: брать проекты, которые ему интересны, и никакие другие, использовать те средства, какие захочет, считаться исключительно со своими планами и так далее. С ковбоями есть только один путь: раз и навсегда уяснить, что частью команды они не станут, и решить, достаточно ли вы их цените, чтобы мириться с их своеобразными повадками. В общем и целом, ковбои незаменимы в двух случаях: критические, с виду безвыходные ситуации и обособленные проекты, которые будут сопровождать сторонние специалисты.
Итак, мы перечислили те породы, с которыми автору доводилось встречаться чаще всего. К этой классификации, однако, следует дать несколько примечаний:
Пример №1
Ситуация: у вас есть объемная кодовая, которую нужно модернизировать под текущие потребности компании, и разработчик-минималист, который видит ее впервые в жизни. Разработчик заявляет, что код нужно переписывать с нуля – все чересчур сложно, но вы на это пойти не можете: на продукт уже затрачено немало ресурса. Что делать?
Решение: немного изменить задачу. Минималист любит четкость, испытывает слабость к работе с архитектурой – подкупите его несколькими не слишком затратными и явно ущербными объектов или функций, дайте свободу реконструировать их на свое усмотрение в будущем. Попросите изучить и задокументировать код в том числе и для этой цели. В итоге, минималист будет вынужден выполнить то, от чего открещивался – разобраться в чудом коде, чтобы перейти к более интересному занятию.
Пример №2
Ситуация: вы расходитесь во мнениях с архитектором по поводу реализованного им решения. Вам представляется, что какие-то вещи сделаны не оптимальным образом, он не видит никаких проблем.
Решение: у архитекторов обычно есть некое собственное видение структуры – целостное и непротиворечивое, но не очевидное для стороннего наблюдателя. Если взглянуть на дело его глазами не получается, не ведите умозрительных споров, а лучше организуйте более предметное обсуждение. Допустим, попросите архитектора подробно расписать механизм действия, в идеале – рабочий прототип или нехитрую демо-версию. Это быстро вскроет все недочеты реализации, если они есть, или же покажет вашу неправоту. Аналогичным образом, если код кажется вам слишком громоздким и монолитным, предложите разбить его на компоненты – если на работу системы это никак не повлияет, значит, все в порядке.
На этом мы завершим первую часть цикла. Дальше нас ждет разбор таких тем, как неизбежное зло технических совещаний, по каким сценариям лидеры обычно идут к провалу или успеху, проблемы, которые навалятся на нового руководителя сразу же и многое другое.