Страница:
Правила вам известны. Если бы вы их не знали, объяснить ваше продвижение по ступенькам административной лестницы было бы довольно трудно. Смысл критических обзоров кода состоит в донесении вашего опыта до менее бывалых подчиненных. Критические обзоры – это вам не контрольные работы в школе, за которые в дневник ставят оценки, а потом напротив них свои подписи ставят родители. Скорее их можно сравнить с университетскими семинарами, на которых проницательные студенты стремятся выявить наилучшие идеи и забраковать неудачные. Сотрудники, демонстрирующие неспособность учиться на критике, вряд ли смогут долго оставаться в нашей профессии. Быть может, такой подход покажется вам слишком жестким, но если не вывести теоретические основы разработки на практический уровень, будет страдать качество конечного продукта.
Наиболее распространенные нарушения
Скорый суд и неотвратимость наказания
Философия в действии
Конкретный пример философии в действии – Леонардо да Винчи
Ложка дегтя
Перспективы
Что дальше
Глава 7
Обличие тьмы
Негативные эталоны в менеджменте
Наиболее распространенные нарушения
В своем кратком обзоре основных принципов проектирования я акцентирую ваше внимание на трех аспектах: стандартах, связности и взаимозависимости. Рассмотрим соответствующие нарушения.
Соглашение по именованию. Следуют ли ему ваши подчиненные? Возможно ли, взглянув на имя переменной, с уверенностью судить о ее области действия? Отлаживать код, в котором для определения области действия предположительно неверного параметра приходится тратить по полчаса, невероятно трудно. Бывает и так, что имена процедур настолько длинны, что наводят на мысль о бесполезности или даже вредности введения длинных имен файлов в Windows. Быть может, они, напротив, настолько коротки, что для расшифровки имен подпрограмм приходится прибегать к словарю? Между этими крайностями нужно найти баланс – кто знает, может быть, для этого вам придется провести урок грамматики и объяснить своим подчиненным, чем глагол отличается от существительного. Я понимаю, что префикс «get» в именах подпрограмм, извлекающих данные, утомляет; но его наличие безусловно свидетельствует о том, что они что-то извлекают. То же самое можно сказать о префиксе «set». Простота во многих случаях – синоним практичности.
Комментарии должны разъяснять, почему код написан именно так и никак иначе, и как этого удалось достичь – причем основной упор следует делать на раскрытии вопроса «почему?». О том как разработчик достиг поставленной задачи, свидетельствует сам код; в то же время комментарии помогают проследить ход мыслей разработчика во время разработки модуля.
Соглашение по именованию и комментарии к коду предоставляют нам возможность употреблять в процессе написания кода единый язык. Не позволяйте своим подчиненным прибегать к «технологии безмолвия». Заставьте их должным образом расставлять комментарии и присваивать имена. Далеко не всегда разработчики отказываются от комментариев из-за спешки – иногда они сами плохо понимают, что сделали (например, скопировав готовый код из библиотеки и понадеявшись на авось). Бывает, они копируют комментарии, сделанные автором библиотеки, к которой они обращаются. Это много о чем говорит. Конечно, в основном про комментарии забывают из-за неуверенности в результате или из-за элементарной лени. Несколькими пометками в коде ситуацию не исправить. Такие явления зачастую означают значительно более серьезную проблему, с которой столкнулся кодировщик и решать которую нужно на более высоком административном уровне.
Среди прочих распространенных нарушений стандартов – применение подпрограмм с несколькими точками выхода, а также введение ненавистного оператора GoTo. (Программистам VB эту привычку можно простить – благо в NET операторы Try, Catch и Finally включены в библиотеку.) Еще один распространенный недочет – регулярное отсутствие обработки ошибок. Некоторые убежденные в своей непогрешимости кодировщики считают обработку ошибок пустой тратой времени. Действительно, в некоторых случаях перехватить ошибку вверху цепочки вызовов вполне достаточно; в то же время неумение выявлять потенциальные источники ошибок свидетельствует об отсутствии у кодировщика навыков стратегического мышления.
Возвращаясь к перечню отличительных черт различных пород программистов, приведенному в главе 1, замечу, что с его помощью удобно выявлять и другие нарушения, допускаемые вашими подчиненными. Этот список можно продолжать бесконечно в зависимости от конкретного кадрового обеспечения [73]. Я лишь хочу заметить, что, исполняя роль кодового полицейского, вы обязаны фиксировать имена тех, кто нарушает правила.
Есть ли возможность по результатам анализа кода составить диаграмму блоков, демонстрирующую иерархии объектов? Выглядят ли отношения на такой диаграмме логичными, или же стрелки, напротив, расставлены бессвязно? Можно ли определить родословную объектов? При проведении критического обзора кода без таких вопросов не обойтись. Ваша задача – выявить слабые места и добиться их усиления. Не пытайтесь, впрочем, править код самостоятельно – ведь когда сроки поджимают, появляется искушение сделать все самому. Не забывайте, что, доверив исправление проблем сотрудникам группы, вы добьетесь гораздо более серьезного результата. Этот процесс, конечно, может затянуться, но вы ведь понимаете: если нет времени решить задачу сразу и правильно, то времени на то, чтобы переделать результат, тем более не останется.
Нарушение стандартов
Везде ли проставлены комментарии? Сможет ли с их помощью новичок, не знакомый со структурой данного модуля, в нем разобраться? Предположим, вы пытаетесь проследить последовательность исправления ошибки, – можно ли это сделать по комментариям? Комментарии должны разъяснять, почему код написан именно так и никак иначе, и как этого удалось достичь – причем основной упор следует делать на раскрытии вопроса «почему?». О том как разработчик достиг поставленной задачи, свидетельствует сам код; в то же время комментарии помогают проследить ход мыслей разработчика во время разработки модуля. Для того чтобы продолжить чье-то начинание, вы должны знать, почему ваш предшественник пошел именно тем путем, которым пошел. В этом вам помогут комментарии.Соглашение по именованию. Следуют ли ему ваши подчиненные? Возможно ли, взглянув на имя переменной, с уверенностью судить о ее области действия? Отлаживать код, в котором для определения области действия предположительно неверного параметра приходится тратить по полчаса, невероятно трудно. Бывает и так, что имена процедур настолько длинны, что наводят на мысль о бесполезности или даже вредности введения длинных имен файлов в Windows. Быть может, они, напротив, настолько коротки, что для расшифровки имен подпрограмм приходится прибегать к словарю? Между этими крайностями нужно найти баланс – кто знает, может быть, для этого вам придется провести урок грамматики и объяснить своим подчиненным, чем глагол отличается от существительного. Я понимаю, что префикс «get» в именах подпрограмм, извлекающих данные, утомляет; но его наличие безусловно свидетельствует о том, что они что-то извлекают. То же самое можно сказать о префиксе «set». Простота во многих случаях – синоним практичности.
Комментарии должны разъяснять, почему код написан именно так и никак иначе, и как этого удалось достичь – причем основной упор следует делать на раскрытии вопроса «почему?». О том как разработчик достиг поставленной задачи, свидетельствует сам код; в то же время комментарии помогают проследить ход мыслей разработчика во время разработки модуля.
Соглашение по именованию и комментарии к коду предоставляют нам возможность употреблять в процессе написания кода единый язык. Не позволяйте своим подчиненным прибегать к «технологии безмолвия». Заставьте их должным образом расставлять комментарии и присваивать имена. Далеко не всегда разработчики отказываются от комментариев из-за спешки – иногда они сами плохо понимают, что сделали (например, скопировав готовый код из библиотеки и понадеявшись на авось). Бывает, они копируют комментарии, сделанные автором библиотеки, к которой они обращаются. Это много о чем говорит. Конечно, в основном про комментарии забывают из-за неуверенности в результате или из-за элементарной лени. Несколькими пометками в коде ситуацию не исправить. Такие явления зачастую означают значительно более серьезную проблему, с которой столкнулся кодировщик и решать которую нужно на более высоком административном уровне.
Среди прочих распространенных нарушений стандартов – применение подпрограмм с несколькими точками выхода, а также введение ненавистного оператора GoTo. (Программистам VB эту привычку можно простить – благо в NET операторы Try, Catch и Finally включены в библиотеку.) Еще один распространенный недочет – регулярное отсутствие обработки ошибок. Некоторые убежденные в своей непогрешимости кодировщики считают обработку ошибок пустой тратой времени. Действительно, в некоторых случаях перехватить ошибку вверху цепочки вызовов вполне достаточно; в то же время неумение выявлять потенциальные источники ошибок свидетельствует об отсутствии у кодировщика навыков стратегического мышления.
Возвращаясь к перечню отличительных черт различных пород программистов, приведенному в главе 1, замечу, что с его помощью удобно выявлять и другие нарушения, допускаемые вашими подчиненными. Этот список можно продолжать бесконечно в зависимости от конкретного кадрового обеспечения [73]. Я лишь хочу заметить, что, исполняя роль кодового полицейского, вы обязаны фиксировать имена тех, кто нарушает правила.
Слабая связность и сильная взаимозависимость
Слабая связность и сильная взаимозависимость – две области нарушений, которые допустимо рассматривать совместно, поскольку наличие одного предполагает наличие другого. Имеет ли в процедурах место обширное ветвление? Сильную взаимозависимость между процедурами обычно называют ветвлением по входу-выходу. При высокой степени ветвления по выходу функционирование процедуры предполагает обращение к множеству других процедур, что, естественно, нежелательно. Ветвление по входу, напротив, оказывает положительное воздействие, так как свидетельствует о строгой инкапсуляции. Общую оценку серьезности нарушений по части связности и взаимозависимости можно дать исходя из степени несоответствия основным объектно-ориентированным принципам.Есть ли возможность по результатам анализа кода составить диаграмму блоков, демонстрирующую иерархии объектов? Выглядят ли отношения на такой диаграмме логичными, или же стрелки, напротив, расставлены бессвязно? Можно ли определить родословную объектов? При проведении критического обзора кода без таких вопросов не обойтись. Ваша задача – выявить слабые места и добиться их усиления. Не пытайтесь, впрочем, править код самостоятельно – ведь когда сроки поджимают, появляется искушение сделать все самому. Не забывайте, что, доверив исправление проблем сотрудникам группы, вы добьетесь гораздо более серьезного результата. Этот процесс, конечно, может затянуться, но вы ведь понимаете: если нет времени решить задачу сразу и правильно, то времени на то, чтобы переделать результат, тем более не останется.
Скорый суд и неотвратимость наказания
Заметив нарушения, вы должны приостановить процесс кодирования, пока нарушители не исправят ситуацию. Чем дольше нарушения будут игнорироваться, тем выше вероятность того, что код придется отправить прямиком на помойку
[74]. Когда разработчики обнаруживают халтуру своих коллег, они невольно опускаются до того же уровня – это человеческая природа, ничего не поделаешь. Если владение оружием предполагает употребление обоих рук, то грамотное проведение критических обзоров кода требует пресечения деятельности нарушителей за счет авторитета руководителя.
Писать и читать материалы о критических обзорах кода не составляет труда; на практике же все оказывается значительно сложнее. Всем нам известны факторы, влияющие на качество кода и превращающие процесс сопровождения в хроническую головную боль. Новички в деле руководства и лидерства нередко испытывают сложности, пытаясь перенести теоретические представления о своих действиях в практическую плоскость. Сопротивление происходит от неуверенности в своих лидерских качествах, и технические навыки, какими бы впечатляющими они ни были, в данном случае отходят на второй план. Одно дело обсуждать проблемы кодирования в компании приятелей, и совсем другое – решать их с позиции руководителя. Если все сотрудники осознают слабости кода, они ожидают проявления вашей инициативы. Попытайтесь предвидеть трудности и внушить себе необходимость адекватного реагирования на них. О том, что нужно делать при выявлении проблем, я рассказал предостаточно. Имейте в виду, что прочтения этих строк совершенно недостаточно для превращения нужно в сделаю. Чтобы это случилось, что-то должно измениться в вашем характере. Именно об этом я и намерен поговорить в оставшихся разделах главы.
Писать и читать материалы о критических обзорах кода не составляет труда; на практике же все оказывается значительно сложнее. Всем нам известны факторы, влияющие на качество кода и превращающие процесс сопровождения в хроническую головную боль. Новички в деле руководства и лидерства нередко испытывают сложности, пытаясь перенести теоретические представления о своих действиях в практическую плоскость. Сопротивление происходит от неуверенности в своих лидерских качествах, и технические навыки, какими бы впечатляющими они ни были, в данном случае отходят на второй план. Одно дело обсуждать проблемы кодирования в компании приятелей, и совсем другое – решать их с позиции руководителя. Если все сотрудники осознают слабости кода, они ожидают проявления вашей инициативы. Попытайтесь предвидеть трудности и внушить себе необходимость адекватного реагирования на них. О том, что нужно делать при выявлении проблем, я рассказал предостаточно. Имейте в виду, что прочтения этих строк совершенно недостаточно для превращения нужно в сделаю. Чтобы это случилось, что-то должно измениться в вашем характере. Именно об этом я и намерен поговорить в оставшихся разделах главы.
Философия в действии
Философия без практики бесполезна. Видение и действие должны сочетаться гармонично, как рука и перчатка. Иначе говоря, действуйте по своим убеждениям. Многие люди, не исключая программистов и руководителей, знают, как нужно делать, но тем не менее не делают этого. Существует ли верный метод экстраполяции теоретических знаний на практику, способный предотвратить разрушительные последствия бездействия? Никакого секрета здесь нет – скорее, возможен некий диалог, способный убедить вас слезть с койки (то есть отказаться от праздности) и приступить к действию. Быть может, перечисление последствий бездействия, исходя из сформулированных в этой главе принципов, вам поможет.
Делайте то, что считаете нужным.
Некачественная или случайная архитектура приводит к таким последствиям:
• сверхтрудное сопровождение и низкая оперативность (а следовательно, финансовые потери) при введении новых свойств;
• нежелание программистов заниматься сопровождением кода вследствие чрезмерной усложненности системы и неуверенности относительно первоочередных действий при исправлении ошибок и введении новых свойств;
• размывание кода из-за лавинообразного роста числа объектов, за счет чего при увеличении размера исполняемых файлов сокращается производительность.
Ниже перечислены последствия неадекватного проектирования:
• из-за несоблюдения стандартов создается впечатление, что все объекты создавались разными программистами;
• модификация в одном месте приводит к нарушению в нескольких других;
• вследствие многократного дублирования кода для изменения любой функции требуется найти и также изменить все ее экземпляры.
Любой из этих списков можно было бы продолжить, но, держу пари, страху я на вас нагнал уже предостаточно. Надеюсь, вы серьезно напуганы и готовы сделать все, чтобы перечисленные неприятности вас миновали. Может, это и так, но вот я, например, предпочел бы еще пораскинуть мозгами. В конце концов, в мире полно людей с благими намерениями, которые, тем не менее, либо действуют строго противоположным образом, либо вообще ничего не делают.
Делайте то, что считаете нужным.
Некачественная или случайная архитектура приводит к таким последствиям:
• сверхтрудное сопровождение и низкая оперативность (а следовательно, финансовые потери) при введении новых свойств;
• нежелание программистов заниматься сопровождением кода вследствие чрезмерной усложненности системы и неуверенности относительно первоочередных действий при исправлении ошибок и введении новых свойств;
• размывание кода из-за лавинообразного роста числа объектов, за счет чего при увеличении размера исполняемых файлов сокращается производительность.
Ниже перечислены последствия неадекватного проектирования:
• из-за несоблюдения стандартов создается впечатление, что все объекты создавались разными программистами;
• модификация в одном месте приводит к нарушению в нескольких других;
• вследствие многократного дублирования кода для изменения любой функции требуется найти и также изменить все ее экземпляры.
Любой из этих списков можно было бы продолжить, но, держу пари, страху я на вас нагнал уже предостаточно. Надеюсь, вы серьезно напуганы и готовы сделать все, чтобы перечисленные неприятности вас миновали. Может, это и так, но вот я, например, предпочел бы еще пораскинуть мозгами. В конце концов, в мире полно людей с благими намерениями, которые, тем не менее, либо действуют строго противоположным образом, либо вообще ничего не делают.
Конкретный пример философии в действии – Леонардо да Винчи
Я не большой поклонник школы позитивного мышления и все-таки несколько лет назад меня заинтересовала книга о Леонардо да Винчи. Ее автор вознамерился научить читателя мыслить как Леонардо. Поскольку Леонардо широко известен, позволю себе называть его просто по имени. Билл Гейтс истратил кучу денег (которые он предварительно выкачал из нас за свои программы) на оригиналы дневников Леонардо. Этим все сказано. Леонардо был невероятно умен. Если вы всерьез заинтересуетесь его биографией (а для этого мало прочитать единственную книжку из серии «помоги себе сам»), то быстро поймете, что его творческий гений направлялся жизненной философией. Эту самую философию Майкл Гелб (Michael Gelb) вкратце сформулировал следующим образом
[75].
• Неизменно любознательный взгляд на жизнь и сильнейшее стремление к постоянному обучению.
• Привычка проверять знания через опыт, настойчивость и готовность учиться на ошибках.
• Последовательное совершенствование восприятия действительности органами чувств (в особенности, зрением) как средство обогащения жизненной практики.
• Готовность к восприятию неясностей, парадоксальных явлений и неопределенности.
• Уравновешивание науки и искусства, логики и воображения. Мышление «всем интеллектом».
• Воспитание изящества в движениях, «двуправорукости», физического здоровья и поведения.
• Признание и понимание взаимосвязи между всеми вещами и явлениями. Системное мышление.
Думаю, из Леонардо вышел бы добротный программный архитектор. То что он был замечательным художником и инженером, не вызывает сомнений. Принципы, которым он следовал, достойны всяческого уважения – они стимулируют творческое мышление и являют собой прекрасный пример для подражания.
Влияние Леонардо на современную ему технологию впечатляет. Трудно себе представить, как один человек смог выдумать все те изобретения, которые он набросал в своих дневниках, а частично и реализовал. Очевидно, в этом ему помогла его жизненная философия. Что делает ее такой действенной? Уверен, что ни одна из ее составляющих не сыграла такой роли, как сбалансированное сочетание различных векторов его мышления.
Взять, например, его тягу к знаниям в сочетании с терпимостью к неопределенности. Убежденный в том, что опыт – лучший учитель, он постоянно совершенствовал свои воззрения с тем, чтобы улучшить наблюдательность. Леонардо воспитал целую плеяду последователей, уделяя значительное время оценке их достижений. Быть может, он был первым, кто пользовался принципом системного мышления – а ведь это именно то, к чему мы, специалисты по проектированию программных продуктов, неизменно стремимся. Этот принцип предполагает следование установленному плану вплоть до его окончательной реализации. Он имеет непосредственное отношение к тому, о чем я уже говорил, – к комплексной проверке архитектуры, предваряющей ее исполнение в виде подсистем-компонентов.
Из иных творений Леонардо мы обнаруживаем, что он был человеком, чрезвычайно крепким физически. Он не позволял телу тормозить работу ума. Быть может, это слишком личное, но подумайте: готовы ли ваши чресла к решению задачи, поставленной интеллектом? Если нет, придется вам поработать над физической формой, совершенствуя попутно мозговые кондиции. Вы и только вы способны понять, что в вашей рабочей деятельности препятствует следованию здоровой философии.
Крайне рекомендую на досуге почитать Леонардо – надеюсь, это поможет вам на практике проводить в жизнь стройную систему деятельности. Вполне возможно, побудить вас к действию смогут биографии современных лидеров нашей индустрии [76]. Полезно также ознакомиться с историями успеха деятелей других отраслей экономики. Удивительно, но факт: они в своей деятельности сталкиваются с теми же проблемами, что и мы. Короче говоря, биографическая литература – это неплохой выбор для чтения перед сном. По крайней мере, она поможет вам отдохнуть от повседневного чтения трудов по ADO 2.1, MTS MSMQ, VB, ASP, HTML 4.0 – видимо, их авторы считают, что заумная аббревиатура на корешке завлекает покупателя [77]. Кто знает, быть может, биография Джуди Гарланд (Judy Garland) напомнит вам, что как программист, руководящий другими программистами, вы не в Канзас-Сити.
• Неизменно любознательный взгляд на жизнь и сильнейшее стремление к постоянному обучению.
• Привычка проверять знания через опыт, настойчивость и готовность учиться на ошибках.
• Последовательное совершенствование восприятия действительности органами чувств (в особенности, зрением) как средство обогащения жизненной практики.
• Готовность к восприятию неясностей, парадоксальных явлений и неопределенности.
• Уравновешивание науки и искусства, логики и воображения. Мышление «всем интеллектом».
• Воспитание изящества в движениях, «двуправорукости», физического здоровья и поведения.
• Признание и понимание взаимосвязи между всеми вещами и явлениями. Системное мышление.
Думаю, из Леонардо вышел бы добротный программный архитектор. То что он был замечательным художником и инженером, не вызывает сомнений. Принципы, которым он следовал, достойны всяческого уважения – они стимулируют творческое мышление и являют собой прекрасный пример для подражания.
Влияние Леонардо на современную ему технологию впечатляет. Трудно себе представить, как один человек смог выдумать все те изобретения, которые он набросал в своих дневниках, а частично и реализовал. Очевидно, в этом ему помогла его жизненная философия. Что делает ее такой действенной? Уверен, что ни одна из ее составляющих не сыграла такой роли, как сбалансированное сочетание различных векторов его мышления.
Взять, например, его тягу к знаниям в сочетании с терпимостью к неопределенности. Убежденный в том, что опыт – лучший учитель, он постоянно совершенствовал свои воззрения с тем, чтобы улучшить наблюдательность. Леонардо воспитал целую плеяду последователей, уделяя значительное время оценке их достижений. Быть может, он был первым, кто пользовался принципом системного мышления – а ведь это именно то, к чему мы, специалисты по проектированию программных продуктов, неизменно стремимся. Этот принцип предполагает следование установленному плану вплоть до его окончательной реализации. Он имеет непосредственное отношение к тому, о чем я уже говорил, – к комплексной проверке архитектуры, предваряющей ее исполнение в виде подсистем-компонентов.
Из иных творений Леонардо мы обнаруживаем, что он был человеком, чрезвычайно крепким физически. Он не позволял телу тормозить работу ума. Быть может, это слишком личное, но подумайте: готовы ли ваши чресла к решению задачи, поставленной интеллектом? Если нет, придется вам поработать над физической формой, совершенствуя попутно мозговые кондиции. Вы и только вы способны понять, что в вашей рабочей деятельности препятствует следованию здоровой философии.
Крайне рекомендую на досуге почитать Леонардо – надеюсь, это поможет вам на практике проводить в жизнь стройную систему деятельности. Вполне возможно, побудить вас к действию смогут биографии современных лидеров нашей индустрии [76]. Полезно также ознакомиться с историями успеха деятелей других отраслей экономики. Удивительно, но факт: они в своей деятельности сталкиваются с теми же проблемами, что и мы. Короче говоря, биографическая литература – это неплохой выбор для чтения перед сном. По крайней мере, она поможет вам отдохнуть от повседневного чтения трудов по ADO 2.1, MTS MSMQ, VB, ASP, HTML 4.0 – видимо, их авторы считают, что заумная аббревиатура на корешке завлекает покупателя [77]. Кто знает, быть может, биография Джуди Гарланд (Judy Garland) напомнит вам, что как программист, руководящий другими программистами, вы не в Канзас-Сити.
Ложка дегтя
Умирая, Леонардо понимал, что труд его жизни остался незаконченным. Это жестокая реальность. Тем не менее я призываю вас стремиться к самосовершенствованию и, руководствуясь полюбившимися философскими воззрениями, каждую неделю делать немного больше полезных дел. Между знанием и действием в нашей рабочей действительности огромная пропасть. Это своеобразное состязание между эпистемологией и онтологией. Факт тот, что изначально мы предрасположены к бездействию; однако, в конце концов, происходит что-то, что заставляет нас воскликнуть: «Хватит с меня этих проблем в коде!» – и наконец сделать что-нибудь стоящее.
Перспективы
Давайте абстрагируемся от подробностей и оценим результаты вашей деятельности в роли технического лидера – довольны ли вы теми продуктами, которые появились на свет при вашем участии? Ниже я делаю краткий обзор вопросов, которые мы затрагивали в этой главе. Надеюсь, этот перечень поможет вам адекватно оценить степень своей полезности в области технического лидерства.
• Удается ли вам последовательно играть роль технического лидера? Я совершенно не хочу сказать, что ваши идеи всегда должны быть на порядок лучше чужих, – просто ваши обязанности иные, к ним относятся отбор наиболее удачных идей и их практическая реализация.
• Предполагают ли варианты архитектуры ваших продуктов расширяемость и удобство сопровождения? Ответ на этот вопрос можно получить лишь тогда, когда первая версия продукта уже выпущена на рынок, а вы принялись за оценку ресурсов, требующихся для производства второй версии.
• Смогли ли вы за счет своих проектных решений обеспечить возможность многократного использования компонентов? Может ли любой сотрудник вашей группы взять модуль, разработанный другим сотрудником, и успешно справиться с его сопровождением или расширением функциональности? Ответы на эти вопросы свидетельствуют о ваших достижениях по части организации и руководства проектной деятельностью.
• Как вы обращаетесь с выявленными недостатками кода – устраняете их сразу на стадии разработки или ведете журнал фрагментов кода, требующих переработки?
• Способствует ли здоровая критика действий ваших подчиненных повышению их квалификации?
• Что вы предпочитаете – умные разговоры или практические действия? Помните ли вы, что нереализованные философствования бесполезны?
Руководствуясь принципами самоконтроля, вы должны регулярно задаваться этими вопросами. И не забывайте на них отвечать. Техническое лидерство взращивается на почве знания и питается готовностью учиться на собственных ошибках – в конечном итоге такая практика обязательно увенчается успехом.
Техническое лидерство взращивается на почве знания и питается готовностью учиться на собственных ошибках – в конечном итоге такая практика обязательно увенчается успехом.
• Удается ли вам последовательно играть роль технического лидера? Я совершенно не хочу сказать, что ваши идеи всегда должны быть на порядок лучше чужих, – просто ваши обязанности иные, к ним относятся отбор наиболее удачных идей и их практическая реализация.
• Предполагают ли варианты архитектуры ваших продуктов расширяемость и удобство сопровождения? Ответ на этот вопрос можно получить лишь тогда, когда первая версия продукта уже выпущена на рынок, а вы принялись за оценку ресурсов, требующихся для производства второй версии.
• Смогли ли вы за счет своих проектных решений обеспечить возможность многократного использования компонентов? Может ли любой сотрудник вашей группы взять модуль, разработанный другим сотрудником, и успешно справиться с его сопровождением или расширением функциональности? Ответы на эти вопросы свидетельствуют о ваших достижениях по части организации и руководства проектной деятельностью.
• Как вы обращаетесь с выявленными недостатками кода – устраняете их сразу на стадии разработки или ведете журнал фрагментов кода, требующих переработки?
• Способствует ли здоровая критика действий ваших подчиненных повышению их квалификации?
• Что вы предпочитаете – умные разговоры или практические действия? Помните ли вы, что нереализованные философствования бесполезны?
Руководствуясь принципами самоконтроля, вы должны регулярно задаваться этими вопросами. И не забывайте на них отвечать. Техническое лидерство взращивается на почве знания и питается готовностью учиться на собственных ошибках – в конечном итоге такая практика обязательно увенчается успехом.
Техническое лидерство взращивается на почве знания и питается готовностью учиться на собственных ошибках – в конечном итоге такая практика обязательно увенчается успехом.
Что дальше
Проводить философские воззрения в жизнь не так уж просто. В следующей главе, в которой мы поговорим об обратной стороне лидерства, у вас еще будет возможность поразмышлять о последствиях неверной философии лидера. Даже удивительно, сколько неприятностей способны доставить люди, руководствующиеся неподходящими философскими концепциями. Однако они, по крайней мере, уяснили, как превращать теорию в практику. Повторюсь – оценивать свои лидерские качества нужно по результатам каждодневной практической деятельности, ведомой внутренними убеждениями.
Глава 7
Закат лидера
Йода говорил: «Остерегайтесь темной стороны». Это предупреждение применимо и к нашей деятельности – у лидерства тоже есть обратная сторона. Иначе говоря, если отказаться от лексикона научной фантастики, лидерство бывает неэффективным и разрушительным. Судя по моему опыту, темными (то есть не излучающими свет, за которым могли бы следовать окружающие) личностями люди становятся благодаря стилю руководства, который просто не создает почву для развития лидерских качеств. Результатом неадекватных руководящих действий становится закат лидерства, который может повлиять как на вас, так и (что хуже) на вашего шефа. Подобный стиль руководства, оказывая воздействие на суждения, незаметно разъедает даже самых сильных лидеров. В результате эффективность лидерства сходит «на нет» из-за неадекватного стиля руководства.
Во всех предыдущих главах я исходил из вашей способности отказаться от действий, приводящих к неэффективному руководству, и проводить в жизнь методики, обеспечивающие истинное лидерство. Впрочем, некоторые люди неспособны к изменениям, и воспринимать их следует как поддержанный автомобиль – в состоянии «как есть», без гарантии и без возврата потраченных средств. Полагаю, что вы не относитесь к этой категории, – в противном случае, столкнувшись с тем, что я ставлю под сомнение обыденные представления о руководстве и лидерстве, вы просто забросили бы чтение. В то же время в определенной степени упрямство и нежелание меняться присутствует во всех людях – естественно, эти качества мешают должному исполнению нами своих обязанностей. По мнению Йоды, адептами «темной стороны» становятся те, кто пребывает во власти страха. Может, он и прав. Мне действительно кажется, что страх совершить ошибку – это одно из проявлений негатива, о котором пойдет речь в этой главе. Вы должны уяснить для себя, что страх ошибиться можно преодолеть и маскировать его непродуктивным стилем руководства совершенно не обязательно.
Во всех предыдущих главах я исходил из вашей способности отказаться от действий, приводящих к неэффективному руководству, и проводить в жизнь методики, обеспечивающие истинное лидерство. Впрочем, некоторые люди неспособны к изменениям, и воспринимать их следует как поддержанный автомобиль – в состоянии «как есть», без гарантии и без возврата потраченных средств. Полагаю, что вы не относитесь к этой категории, – в противном случае, столкнувшись с тем, что я ставлю под сомнение обыденные представления о руководстве и лидерстве, вы просто забросили бы чтение. В то же время в определенной степени упрямство и нежелание меняться присутствует во всех людях – естественно, эти качества мешают должному исполнению нами своих обязанностей. По мнению Йоды, адептами «темной стороны» становятся те, кто пребывает во власти страха. Может, он и прав. Мне действительно кажется, что страх совершить ошибку – это одно из проявлений негатива, о котором пойдет речь в этой главе. Вы должны уяснить для себя, что страх ошибиться можно преодолеть и маскировать его непродуктивным стилем руководства совершенно не обязательно.
Обличие тьмы
Страх порождает самые что ни на есть темные явления. Примером тому – дьявольский период правления Гитлера. Благородная сама по себе немецкая концепция «лидера» (der Purer) превратилась в кошмар западной цивилизации. Эти зловещие страницы истории наталкивают меня на вывод: лидерство, если оно носит разрушительный характер, чревато страшными последствиями для окружающих. Аналогичным образом (хотя и в несколько более скромном масштабе), если группа разработчиков по вине своего лидера пойдет по неверному пути, следует ждать снижения производительности, ухудшения качества выпускаемых данной компанией программных продуктов и неспособности сотрудников достигать намеченных целей. Есть одна древнееврейская пословица (может быть, вы ее слышали), которая звучит примерно так: «недальновидность правителей губит людей». Вот что случается с теми, кто теряет нить руководства. Среди подчиненных начинается анархия, но ведь, как я говорил в главе 1, руководитель должен стремиться к тому, чтобы сотрудники его рабочей группы двигались в одном направлении. Именно поэтому я считаю лидерство основной темой этой книги. Когда лидер поддается дурным веяниям, он перестает быть таковым.
Получив представление об извращенных стратегиях лидерства, которые я описываю в этой главе, вы должны сопоставить их с собственной административной деятельностью и попытаться найти общие черты. За этим нужно следить – перенимая негативные элементы таких стилей, вы снижаете свой профессиональный уровень. Как известно, сформулированная проблема наполовину решена. Вторая половина требует больших усилий, но, надеюсь, осознание пагубности неверной стратегии руководства и ее отрицательного влияния на подчиненных вас мобилизует. В таком случае вы сможете с решимостью перейти к действиям по решению проблемы, то есть скорректировать свои действия в роли руководителя. Полагаю, на это у вас хватит сил – в противном случае вы вряд ли добрались бы до этих строк. Прислушайтесь ко мне – в конце концов, мне самому каждый день приходится бороться с обратной стороной лидерства.
Получив представление об извращенных стратегиях лидерства, которые я описываю в этой главе, вы должны сопоставить их с собственной административной деятельностью и попытаться найти общие черты. За этим нужно следить – перенимая негативные элементы таких стилей, вы снижаете свой профессиональный уровень. Как известно, сформулированная проблема наполовину решена. Вторая половина требует больших усилий, но, надеюсь, осознание пагубности неверной стратегии руководства и ее отрицательного влияния на подчиненных вас мобилизует. В таком случае вы сможете с решимостью перейти к действиям по решению проблемы, то есть скорректировать свои действия в роли руководителя. Полагаю, на это у вас хватит сил – в противном случае вы вряд ли добрались бы до этих строк. Прислушайтесь ко мне – в конце концов, мне самому каждый день приходится бороться с обратной стороной лидерства.
Негативные эталоны в менеджменте
Полагаю, знакомясь с материалом главы 1, вы изрядно позабавились по поводу описания различных типов программистов. В этой главе я обращаюсь к аналогичной схеме повествования, хотя на этот раз она вряд ли доставит вам соизмеримое удовольствие. Итак, вам предстоит ознакомиться с негативными эталонами в психологии – благо о том, что они собой представляют в области проектирования, у вас уже есть некоторое представление. Назначение негативных эталонов – показать, как не стоит себя вести. Если среди перечисленных черт вы обнаружите сходство с собственной моделью поведения, попытайтесь ее скорректировать. Начальников следует остерегаться и быть осторожным в оценках. Быть может, это слегка упрощенный совет, но пока что он вполне достаточен. В контексте проблем, которые обсуждаются в этой главе, мы еще успеем поговорить о преодолении трудностей и корректирующих стратегиях.
Многие руководители, которым, по идее, следует стремиться к приобретению лидерских качеств, на деле демонстрируют в своем поведении смесь стилей. Об этих стилях, которые проявляются с той или иной силой, и пойдет речь. Анализируя порочные стили руководства, я не утверждаю, что они олицетворяют абсолютное зло, я вообще стараюсь воздерживаться от моральных оценок. Значительно важнее другое: по тем или иным причинам отдельные руководители перенимают отрицательные качества деструктивных стилей руководства. Они со всей очевидностью проявляются в рабочей среде и снижают качество лидера. Знание перечисленных ниже негативных эталонов не означает, что вы должны наставлять на путь истинный всех, кто им следует, – ваша цель в том, чтобы выявлять соответствующие типы людей и уметь с ними общаться. С другой стороны, вы должны подавлять эти качества в самом себе. Вся эта книга преследует одну цель – направить вас на путь лидерства. Поймите, других людей вам не исправить. Это очевидное, на первый взгляд, обстоятельство очень помогает в процессе взаимодействия с окружающими.
Многие руководители, которым, по идее, следует стремиться к приобретению лидерских качеств, на деле демонстрируют в своем поведении смесь стилей. Об этих стилях, которые проявляются с той или иной силой, и пойдет речь. Анализируя порочные стили руководства, я не утверждаю, что они олицетворяют абсолютное зло, я вообще стараюсь воздерживаться от моральных оценок. Значительно важнее другое: по тем или иным причинам отдельные руководители перенимают отрицательные качества деструктивных стилей руководства. Они со всей очевидностью проявляются в рабочей среде и снижают качество лидера. Знание перечисленных ниже негативных эталонов не означает, что вы должны наставлять на путь истинный всех, кто им следует, – ваша цель в том, чтобы выявлять соответствующие типы людей и уметь с ними общаться. С другой стороны, вы должны подавлять эти качества в самом себе. Вся эта книга преследует одну цель – направить вас на путь лидерства. Поймите, других людей вам не исправить. Это очевидное, на первый взгляд, обстоятельство очень помогает в процессе взаимодействия с окружающими.