Как пасти котов. Наставление для программистов, руководящих другими программистами - Рейнвотер Дж.Ханк

Стоя в душе – думайте. Катаясь на велосипеде, прогуливаясь по парку, выделывая невообразимые трюки на роликах – думайте. Сталкиваясь с дилеммами, которые обусловлены принятыми проектными решениями, – думайте. Думать значительно полезнее, чем смотреть телевизор или бесцельно бродить по Сети, – пусть даже там 500 каналов, но на самом деле на них ничего не происходит, и то, что они как будто избавляют человека от необходимости мыслить, совершенно не здорово. Думайте напряженно, до изнеможения, а когда не останется сил – начинайте заново. Результат вас удивит.

Ну а теперь подумаем о том, как справляться с некоторыми типичными ситуациями.

Предположим, в вашем подчинении кот породы минималист, но при этом весьма профессиональный. Вы хотите поручить ему модернизацию продукта, который писал кто-то другой, но доработать который в контексте текущих коммерческих задач совершенно необходимо. Взглянув мельком на код, который вы собираетесь вменить ему в обязанность, он говорит: «Нет, это слишком сложно – код нужно переписать». Естественно, речь идет о коде, который писался два года и который уже сейчас приносит компании неплохие деньги. Ситуация осложняется тем, что человек, который этот код написал, у вас больше не работает и поэтому физически не может помочь новому сотруднику в нем разобраться. Итак, у вас два выхода. Первый: пасть под давлением минималиста, сделав его самым счастливым человеком, но загубив последний шанс сдать проект в срок. Второй: направить его на путь изучения существующей архитектуры и дать ему впоследствии возможность внести в нее весомый вклад. Поиграйте с его пристрастием к четкой архитектуре – попросите документировать существующий код с тем, чтобы в будущем, если позволит время, он смог бы переписать некоторые объекты, сделать их более удобными. Если он профессионал, не сомневайтесь – он обязательно разберется в том, что написал его предшественник. Не стесняйтесь использовать в своих целях дух соревновательности. С точки зрения минималиста все, что написал не он, – полная туфта. На самом деле вполне возможно, что он боится, будто не сможет разобраться в существующем коде, и просто не хочет в этом признаться. Всегда ищите скрытые мотивы, которыми руководствуются все без исключения представители рода человеческого. Поймите: программисты, не готовые признать, что их компетенции не хватит для решения поставленной задачи, очень любят выискивать своему бездействию высокоинтеллектуальные оправдания.

Как поступить с архитектором, который уверен, что созданные им объектные решения превосходят все созданное ранее, а вы, тем не менее, усматриваете в них некие слабые стороны? Не надо ему ничего говорить про врожденные недостатки решений – ничего не добьетесь, зато наживете себе врага. Лучше попросите его объяснить предполагаемый механизм функционирования всех динамичных элементов и построить несколько прототипов, или тестовых программ, которые смогли бы наглядно продемонстрировать действие заложенных в решении функций. Если он создаст эти прототипы и никаких проблем не возникнет, значит, возможно, вы были неправы, и изъянов в найденном решении нет. Если архитектура кажется вам слишком громоздкой и монолитной, попросите разбить ее на компоненты. Если окажется, что они прекрасно друг с другом работают, значит, архитектор вполне адекватно представляет себе, что он хочет. Если объекты излишне взаимосвязаны и взаимозависимы, это свидетельствует о пристрастии архитектора к усложнению, которое способно существенно удорожить сопровождение продукта. Что отличает высокопрофессионального архитектора? То, что он способен создать конструкцию, которую сможет обслуживать и расширять любой его последователь. Такая конструкция не рассыплется при первой же модернизации кода. На код при работе с архитектором нужно смотреть его глазами – даже если он слеп на один глаз и не видит другим.

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

Какие еще рекомендации я мог бы дать по поводу такого рода ситуаций межличностного общения? Есть твердое правило: прежде чем пытаться утвердить то или иное решение, используя свое положение руководителя, обязательно выслушайте человека и попробуйте его понять. В том, что касается конфронтации, программисты ничем не отличаются от остальных людей – они хотят, чтобы их выслушали. Как пишет в своей книге «The 7 Habits of Highly Effective People» Стивен Кави (Stephen Covey), «сначала старайтесь понять… и только после этого – быть понятым». Поиск консенсуса при принятии технических решений есть не что иное, как вид искусства, основывающийся на готовности выслушивать чужие идеи. Для того чтобы выстроить такую основу для взаимодействия с сотрудниками, требуется терпение, и проявлять его необходимо – хотя иногда нам кажется, что времени нет даже на конструирование, а насчет методов все вроде бы согласны. Вы можете так считать, но это не отменяет постановку задачи по достижению консенсуса[16]. О том, как достичь консенсуса, мы еще поговорим в главе 5, которая посвящена проведению проектных совещаний. Возможно, вы удивитесь, когда узнаете, что консенсус нельзя строить на основе компромисса.

И еще один пример, иллюстрирующий принцип «услышь, прежде чем судить». Некоторые языки программирования – и, в частности, Visual Basic (VB) – не предусматривают полноценных конструкторов объектов. Недавно я столкнулся с тем, как один художник с помощью события инициализации класса VB пытался организовать обращения к набору объекта со стороны (родительского) класса-потребителя[17]. Если объект VB не удается конкретизировать, перехватить ошибку становится очень трудно. Когда я спросил этого деятеля, почему для обработки подверженной ошибкам операции он выбрал упомянутое событие, в ответ он сообщил, что его решение изящно, понятно и не требует от вызывающего объекта подготовки обращения к интерфейсу. Я, естественно, посчитал, что надежная обработка ошибок значительно важнее любых попыток вылизать текст. Но промолчал. Ознакомившись с его аргументацией, я объяснил ему, с какими трудностями может столкнуться такой объект, и подкрепил свои соображения наглядным примером в коде. Если бы я сразу сказал что-нибудь вроде «это не есть правильно – разберись!», то не смог бы образумить его своим примером, и он так бы не понял, чего от него хотят. Повторюсь: если дать человеку возможность высказать его точку зрения, он в ответ проявит понимание к вашей позиции.

Как вы адаптируетесь

Из этой главы вы почерпнули множество новых идей. Возможно, вам немного не по себе от масштаба изменений, которые приходятся на долю руководителя на пути самосовершенствования. Не беспокойтесь. В конце концов, на 99 % люди до сих пор генетически идентичны обезьянам, а оставшийся процент сформировался далеко не сразу. Последующие главы, в которых раскрываются другие аспекты руководства и менеджмента, помогут вам адаптироваться, преодолеть трудности и достичь успеха.

Теперь повторим пройденный материал – благо основные принципы руководства должны обосноваться в вашей голове надолго.

• Вы должны уметь адаптироваться. Нарабатывая навыки руководства, человек должен приспосабливаться к новому для него социальному контексту. Вы – начальник, а потому ваши взаимоотношения с подчиненными должны серьезно измениться.

• Самосовершенствование важнее, чем имидж. Лидерство есть внутреннее качество человека, оно ни в коем случае не обусловливается внешними признаками. Оставаясь программистом, вы как руководитель должны работать над решением сложных проблем, предусматривающих анализ поведения подчиненных (и, конечно же, собственного поведения).

• Изучайте своих сотрудников. Станьте исследователем культуры и личностей программистов. Разберитесь, почему ваши подчиненные пишут код именно так, как пишут; подумайте, как использовать их положительные качества и улучшить положение вещей в неблагополучных с точки зрения производительности областях. Пасти котов – значит заставлять их двигаться в одном направлении. Это основная задача руководителя.