Наставление для программистов, руководящих другими программистами

Информация о книге

Дж. Ханк Рейнвотер. Как пасти котов

 Наставление для программистов, руководящих другими программистами

 

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

 Вот как сказал сам автор о своей книге: «вашей мысленной архитектуре предстоит пройти серьезные преобразования. Унаследовав навыки менеджера, вы должны будете перегрузить типичные параметры мышления новыми типами и значениями – то есть, грубо говоря, испытать полиморфизм собственного характера. За счет этого вы инкапсулируете в своем программистском мозгу совершенно новый вид искусства – искусство лидерства и руководства».

 Безусловно, книга очень интересная, и читается легко. По замыслу автора, она предназначена для тех людей, которые из программистов выросли в руководителей программистов (группы внедрения, небольшой компании, управление проектом и пр.). Основной акцент делается на отношение людей в команде, на умение делегировать задачи подчиненным, контроль этих задач и роли лидера в коллективе.

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

 В начале книги автор выделяет несколько психотипов программистов, давая им "причудливые" названия. Весьма забавно, прочитайте. Я когда читал, вспоминал много знакомых программистов, которые подходили под эти психотипы. К сожалению, по всей книге они не прослеживаются, хотя такое обещание в начале было. Да и сами разделы, главы и пр., сгуппированы не очень удачно, местами все перемешивается (или мне так показалось?)

 Я немного перекомпановал наиболее интересный материал и постарался выделить главное. Оригинальный текст максимально сохранен.

 О технологиях

 

«Да, технологии важно, но все дело в тех, кто их реализует. Технология "волшебной пули" или "золотого молотка" (как бы вы ее ни назвали) не может решить бизнес-проблем, это делают люди"

 

«Учитесь организовывать сотрудничество технологии и бизнеса; при этом не забывайте, что доминирующую роль в этом союзе играет именно бизнес»

 Это действительно важно помнить. Мне известны много случаев увлечения новой технологией там, где бизнесу это совершенно не нужно. Как результат, излишне потраченные ресурсы.

 

"Исследователи, специализирующиеся в области построения техническое архитектуры, указывают на то, что огромное количество проектов приложений заканчиваются неудачей именно из-за пренебрежения архитектурными вопросами. В результате выполнения таких проектов, как правило, получаются «прямолинейные» системы. Их последующая адаптация к изменяющимся коммерческим требованиям осуществляется с большими трудностями, поскольку предполагает выделение значительных временных, трудовых и интеллектуальных ресурсов"

Важно помнить, что архитектурные ошибки на начальном этапе увеличивают раски провала проекта, или, как минимум, неожиданные проблемы.

Какие виды рисков? Во-первых, риску ухудшения позиций компании на рынке, возникающему, когда в существующий продукт вследствие конкуренции приходится вносить новые непредусмотренные изначально черты; риску неумеренного усложнения процесса сопровождения продуктов, возникающему вследствие жесткой взаимозависимости компонентов-подсистем или негибкости их конфигурации. Еще один вид рисков заключается в неоправданной сложности продукта на верхних уровнях архитектуры. Это обстоятельство чрезвычайно усложняет задачу кодировщиков, не принимавших участия в процессе создания системы, но вынужденных выискивать способы исправления базовых компонентов. Все перечисленные проблемы имеют непосредственное отношение к временным и финансовым затратам, которые ваш начальник, естественно, желает сократить.

Важное замечание о том, как нужно стремиться к удачной архитектуре:

Создание архитектуры – это активный творческий процесс, который отнюдь не ограничивается сидением за клавиатурой, фиксацией коммерческих требований и реализацией компонентов, которые способны эти требования удовлетворить, в коде. В процессе работы над архитектурой вам придется абстрагироваться от своих механистических обязанностей и максимально углубиться в задачу, которую предстоит решить. Спору нет – во многих случаях решение оказывается вполне механистическим, то есть чисто программным. И тем не менее, если вы не разберетесь в задачах, стоящих перед своей компанией, обеспечить продуктам длительное и продуктивное существование вам, скорее всего, не удастся. Марк и Лора Сьюелл (Marc & Laura Sewell) в своей работе о роли архитекторов перечисляют ряд важнейших действий, которые должны предшествовать составлению любого проектного плана. С точки зрения этих авторов, любой архитектор должен:

 • в совершенстве владеть искусством выслушивания, опрашивания и наблюдения;

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

 • получить стратегическое представление о деятельности предприятия клиента, не ограничиваясь тактическим или рабочим обзором его деятельности;

• иметь комплексные познания в технологической области – для того чтобы при разработке архитектурного плана суметь учесть все без исключения варианты стратегических решений;

• наладить конструктивное взаимодействие с клиентом и специалистом, ответственным за конструирование;

• уяснить видение вопроса клиентом и согласованное с ним проектное решение, следить за их неукоснительным соблюдением.

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

Простые, понятные, но важные замечания к проектным ограничениям:

Проектные ограничения – это те факторы, которые необходимо учитывать с самого начала процесса разработки программного продукта. Они выражают ряд вопросов, на которые любая архитектура должна отвечать. Частично эти вопросы перечислены ниже.

 • Сможет ли система предоставить пользователю комфортные условия работы и функционировать согласно его ожиданиям?

 • Может ли система функционировать в соответствии с проектным решением, предусматривает ли она модификацию и сопровождение по мере изменения коммерческих потребностей и технологии?

  • Какой бы продукт ни создавался, в течение нескольких последующих лет его ожидают значительные изменения, причем предпосылки для осуществления этих изменений должны закладываться в фундамент проекта.

 • Достаточна ли компетентность персонала для сопровождения систем, построенных на основе новых технологий? Если в конструировании применяются старые технологии, насколько они перспективны с точки зрения продолжительности использования системы?

В этом мире существует огромное количество технологий и методик. И с каждым днем их становится все больше. За всем угнаться невозможно. Поэтому:

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

 О балансе между чистотой (идеальным причесыванием кода, интерфейса, алгоритмов и пр) и практичностью

Предмет многолетних споров, возникающих практически на каждом проекте. Не знаю как Вам, но для меня это проблема, которую приходится обсуждать с сотрудниками регулярно:

Поиск равновесия между чистотой и практичностью – трудное дело для человека, влюбленного в программирование. Концепция «хорошего программного обеспечения нужно в меру», возможно, впервые открытая Microsoft, имеет свои достоинства. Вы можете тратить очень много времени, добиваясь чистоты кода в ущерб практичности. Что действительно нужно, так это удобство эксплуатации программного обеспечения, и практичность больше соответствует этой цели, чем чистота. Конечно, чистота может быть полезной, но какой ценой? Я не говорю о создании неряшливого или непродуманного кода, я имею в виду программное обеспечение, которое может дополняться и расширяться не только его создателем, но и другими программистами. Проблема чистоты кода состоит в том, что она подобна красоте – ее воспринимают глазами. Вашим глазам постоянно нужно носить очки практичности.

О делегировании задач

Классика передачи задач:

 «Классическая управленческая ловушка для начальника, вышедшего из программистов, касается распределения заданий. Вы понимаете, каким образом реализовать определенное решение, а обучение членов команды, которые вовсе не обязательно видят это решение, требует времени. Здесь применима старая китайская поговорка: «Дайте человеку рыбу, и он будет сыт один день; научите его ловить рыбу, и он будет сыт всю жизнь». Если бы все стали столь же сообразительны, как вы, было бы вам проще работать? Возможно. Потратьте время на обучение сейчас, и вы сэкономите его потом, поскольку ваши сотрудники научатся решать проблемы без вашей помощи. Тогда вы сможете эффективно распределять задания, а не давать объяснения».

Пожалуй, каждый начинающий руководитель задумывался о такой проблеме:

 «Руководитель призван обеспечить решение задачи силами своих подчиненных. Первое, что должен сделать лидер, – это создать условия для полноценного делегирования. Как начальнику вам следует оценивать свою производительность объемом работы, которую выполняет ваш коллектив"

«Не соблазняйтесь непосредственным удовольствием от кодирования; лучше поразмыслите, как помочь остальным получать это удовольствие под вашим руководством»

 «Объяснив подчиненным, какая задача перед ними стоит, заставьте их ее решить»

«Чувствуете ли вы ревность и страх, когда смотрите на действительно хороший код, который написан не вами? Это вопрос-ловушка. Если вы гордитесь тем, что делаете, то вполне нормально чувствовать легкую ревность при виде чего-то, что сделано кем-то лучше. Под маской этой ревности обычно скрывается страх, что вас перехитрили или, что хуже, кто-то достиг чего-то, чего вы даже не в силах понять. Этот вид внутреннего эмоционального состояния «невовлеченности» часто поражает целые отделы. Осознайте эти ощущения и их причину и двигайтесь дальше. Ваша работа – качественно и в срок завершить проект, поэтому используйте все, что может помочь вам в этом»

А следующую цитату я испытывал не раз на собственном опыте:

«Не забывайте и о хрестоматийном правиле, согласно которому введение в проект новых сотрудников на завершающих стадиях разработки только оттягивает срок его сдачи. Делегировать можно задачи, но не темпы их решения»

Замечательная аналогия:

«В ходе выполнения проекта от начальных стадий к завершающим у лидера нередко появляется ощущение стрельбы по движущейся мишени – вот почему для него так важен опыт. Если бы лидеры разработки программных продуктов могли тренироваться в стрельбе по движущимся мишеням на стрельбище, было бы просто здорово. К сожалению, практиковаться нам приходится в реальных условиях – иначе вряд ли мы срывали бы сроки. Чем больше вы будете тренироваться, тем совершеннее станут ваши навыки. Делегирование – это лучший помощник в деле стрельбы по мишеням. Стоит вам попытаться сбить их все самостоятельно (то есть поддаться соблазну мелочной опеки), патроны кончатся раньше времени»

 О планировании

«Основные причины разрастания рамок проекта: это, во-первых, недостаточный анализ подробностей, и, во-вторых, излишне оптимистические оценки длительности конструирования программных продуктов. Чем больше опыта вы наработаете в деле выявления подобных деталей, тем точнее вы сможете оценить время работы над проектом и тем больше вы будете убеждаться в том, что разрастание рамок проекта происходит в результате недоработок специалистов, отвечающих за планирование»

А ниже просто аксиома, как много народу обжигалось!:

«Когда программисты берутся за оценку объема кода реализации какой-либо функции, результаты неизменно оказываются заниженными. Этому есть множество возможных объяснений. В этом контексте следует понимать, что их оптимизм есть относительно прогнозируемая функция состояния проекта»

А вот золотые слова:

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

Красиво сказано:

«Старайтесь только не пасть жертвой консультанта, оставившего вас, выражаясь словами Черчилля, лицом к лицу с загадкой, которая завернута в головоломку, а головоломка – в ребус»

Надо учиться расставлять приоритеты и "дожимать" задачи до конца:

«Вместо того чтобы скверно делать множество дел, сконцентрируйтесь на нескольких задачах, но доведите их решения до совершенства. Многозадачность – свойство микропроцессоров, но никак не людей»

Полезная цитата о коммуникациях внутри проекта и полноте формулирования требований:

«Одна из основных ваших задач в процессе взаимодействия с другими группами заключается в том, чтобы обеспечить своевременное получение бизнес-требований в как можно более завершенном состоянии. Разбухание области действия, как известно, начинается со скверно определенных требований. Ситуация ухудшается, когда программисты, столкнувшись с плохим описанием продукта, начинают фантазировать, и с этого момента разрастание области действия уже практически невозможно контролировать»

 Ох уж эти переработки! Как знакомо это любому it-специалисту. Относиться к переработкам можно по-разному, как собственно, и происходит на самом деле. Лично мое мнение, что надо с этим бороться. Переработки возможны, но только как форс-мажор, а не как норма жизни!

«Не путайте преданность с плохим планированием. Большинство менеджеров работают больше стандартных 40 часов в неделю. При этом переработка не всегда свидетельствует о том, что руководитель предан своей деятельности. Вполне возможно, он просто не слишком организованный человек, не справляющийся со своими обязанностями в разумное время. Кроме того, если вы пренебрегаете личной жизнью и ставите работу во главу угла, вполне вероятно, что в легенде вы предстанете отъявленным фанатиком. Работая больше, чем требуется, вы вольно или невольно заставляете окружающих вас людей также стремиться к увеличению своего рабочего времени. Иногда это действительно необходимо. Однако, делая из этого привычку, имейте в виду, что ваши лидерские качества развиты недостаточно и ваш персонал страдает»

 Все мы сталкивались с ситуацией, когда работу хочется (или требуется) сделать как модно быстрее. Причины тому могут быть разными: неудачное планирование, изменения в требованиях при неизменных сроках, излишняя "инициатива" порсонала по созданию идеальной программы и пр. Вот как автор удачно сравнивает процесс разработки программного обеспечения с марафоном:

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

«Неудачный результат простителен, а вот недостаточные усилия – это смертный грех»

 

«Сформулируйте план-минимум – дайте каждому небольшое, не слишком важное задание и предоставьте возможность справиться с ним самостоятельно. Чем большую независимость в работе они будут проявлять, чем меньше им будет требоваться ваше непосредственное наблюдение, тем сильнее вы будете им доверять и тем более востребованными они себя почувствуют. Повторюсь – на выстраивание доверительных отношений уходит время, но, поверьте мне, результаты того стоят»

 

«Пока вы не обдумаете, не взвесите и не обоснуете каждое коммерческое требование, на комплексное понимание проблемы не рассчитывайте. Наивно надеяться на то, что сотрудники, прочитав спецификацию продукта, все сразу поймут и создадут реализацию именно такой, как требуется. Только выстроив для себя подробный план реализации от начала до конца, вы сможете руководить процессом и отслеживать его.

Практичные рекомендации по выявлению требований:

Требования кто-то формулирует – значит, очевидно, они поддаются пониманию. Это своеобразная трактовка известного высказывания о том, что если есть воля, значит, есть и выход – правда, «волю» здесь следует понимать как исследование вопроса вплоть до его полного понимания. План анализа проблемы можно изложить следующим образом.

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

 2. Сопоставьте требования с известными методиками реализации и выявите те части функциональности, для реализации которых потребуются новые разработки.

3. Набросайте предварительный план макетирования проектов – он поможет выявить среди требуемых свойств неизвестные.

 4. Составьте на основе документации с требованиями контрольный список, который, в свою очередь, послужит исходной точкой для формулирования задач. Так вы сможете привязать каждое требование к набору задач и тем самым гарантировать реализацию свойства.

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

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

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

«Некоторые считают, что необходимым условием успешности проекта является следование заданному процессу. Те, кто придерживается такого мнения, тратят уйму энергии на проверку его соблюдения. Человек, твердо убежденный в том, что именно в процессе вся суть, может очень долго не обращать внимания на несоответствие между практикой следования процессу и его исходом. Методология гибкости рассматривает процесс разработки как опыт сотрудничества и взаимодействия между программистом и заказчиком. Эта позиция, иногда трактуемая исключительно как методологическая тенденция, как мне кажется, являет собой единственный способ обуздать трудный процесс создания качественных программных средств»

 Вопросы управления командой разработчиков

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

«Если попробовать свести функции управления к нескольким четким и удобоваримым принципам, получится, что руководитель:

 • расставляет приоритеты и борется с раздражителями (фокусируется на поставленных задачах);

 • совершенствует свои навыки в области руководства проектами и прорабатывает все их детали;

 • пресекает низкое качество кодирования, пока оно не пустило в проекте корни;

 • стремясь по достоинству оценивать технологические новинки, учится быстро усваивать неизвестную информацию;

 • благоразумно относится к кадровому обеспечению и понимает, что именно от людей зависит конечный успех проекта»

«Менеджеры иногда погрязают в хитросплетениях своей работы; лидеры, напротив, всегда стремятся разработать новые приемы, позволяющие подчиненным брать все более высокие планки»

 

«Я глубоко убежден, что удобное рабочее место является предпосылкой успешной, продуктивной работы. Вы прекрасно знаете, что неупорядоченный код существенно затрудняет процесс разработки и сопровождения программного продукта; аналогичным образом неприбранный рабочий стол доставляет руководителям немало неприятностей. Под «неприбранностью» я в данном случае имею в виду бессистемность в деле организации ваших повседневных задач, которая произрастает от неверного управления информационным потоком».

 

«Варьируйте задания, перераспределяйте их между сотрудниками ежедневно или еженедельно – для этого у вас есть все возможности. Многие усматривают в разнообразии смысл жизни; по моему мнению, программистам разнообразие совершенно необходимо – оно помогает выводить наши мозги «на пик формы»

 

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

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

 

 «Некоторые начальники – я имею в виду тех, кто находится выше вас в руководящей иерархии – предъявляют к своим подчиненным чрезмерно высокие требования, но при этом не удосуживаются посвящать их в подробности своих замыслов»

«Обязательно уточняйте, что от вас хотят. Если ваш начальник темнит относительно того, чего он от вас ожидает, поднажмите на него, заставьте четко сформулировать требования. Без четко определенных исходных данных добиться успеха в области конструирования программных средств невозможно. Организованность в этом процессе есть лучший способ избежать ситуаций, при которых первая версия продукта оказывается для остальных подразделений компании неожиданным и нежелательным сюрпризом»

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

«В основном различия между проектом, организованным по принципу Алисы в Стране Чудес, и проектом, который имеет шанс увенчаться созданием качественного продукта, кроются в деталях. За этапом определения следуют этапы специфицирования, проектирования, макетирования и многие другие итеративные процессы, формирующие очертания процесса в целом. Все эти процессы можно отнести к разработке, однако следует иметь в виду, что цикл разработки выводится исходя из контекста различных мелких элементов проекта»

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

«Для того чтобы программисты достигали в своей деятельности серьезных успехов, у них должна быть возможность, с одной стороны, некоторое время поработать в коллективе, с другой – пораскинуть мозгами в полном одиночестве»

«Дипломатия – это искусство выслушивать, прежде чем говорить, думать, прежде чем предлагать, и постоянно искать консенсус»

«Кейперс Джонс (Capers Jones) в своей книге «Applied Software Measurement» утверждает, что наиболее успешные компании, работающие в сфере разработки программного обеспечения, отличаются шестью общими характеристиками.

 1. Они проводят точные измерения продуктивности и качества программных продуктов.

 2. Они тщательно планируют и оценивают программные продукты.

 3. У них работают квалифицированные менеджеры и технические специалисты.

 4. У них адекватные организационные структуры.

 5. Они пользуются наиболее эффективными методами и инструментами разработки программного обеспечения.

 6. Их сотрудники работают в достойных условиях»

Эффективный мониторинг подобен непрекращающемуся критическому обзору кода – он также предполагает контроль за соответствием проектному решению и стандартам кодирования. Чем дольше вы будете затягивать проведение обзора, тем больше задач вам придется решать, – а если откладывать процесс слишком долго, у вас просто не останется времени на то, чтобы разобраться в запутанном коде.

 

Любую трудную задачу следует рассматривать как возможность для дальнейшего развития, а отнюдь не как очередной повод «сжать кулаки»

 

О контроле работы программистов

«Заходите к своим программистам каждый день или звоните им и проверяйте, как идут дела. Когда они привыкнут ждать этих ежедневных встреч, произойдут две вещи: они никогда не будут знать, когда вы появитесь, и, таким образом, постараются быть в «постоянной готовности», а вы сможете оценить их ежедневный прогресс и соответствующим образом подстроить под него свой график работы. При этом обе стороны прекрасно понимают, что происходит, однако приятно притворяться, что никто ничего не замечает».

«Обнаруживается, что конечная реализация блестящей идеи не так хороша, как хотелось бы, или, еще хуже, что идея-то отнюдь не блестящая»

«В попытках исцелить молодых и неопытных программистов проявляйте такт. Упираются рогом? Ради бога – пусть некоторое время поучатся на собственных ошибках; при этом не забывайте регулярно показывать им правильное направление. Естественно, прежде чем допустить их код до компиляции, предложите свои коррективы. Мы, программисты (впрочем, как и все человеческие существа), имеем обыкновение совершать ошибки, лицезреть их последствия и только после этого искать лучшие пути достижения тех же целей – так мы учимся»

«Старайтесь, чтобы в ходе цикла разработки программисты-новички занимались тестированием не меньше, чем кодированием. Это позволит им перенять ценный опыт своих более квалифицированных собратьев»

 

«Наличие группы тестирования, сотрудники которой также ответственны за развертывание, есть необходимое условие достижения успеха. Тестеры должны быть вашими лучшими друзьями. Именно они помогают выпускать качественные продукты; они же составляют первую линию защиты от некачественных графических пользовательских интерфейсов»

«Смысл критических обзоров кода состоит в донесении вашего опыта до менее бывалых подчиненных. Критические обзоры – это вам не контрольные работы в школе, за которые в дневник ставят оценки, а потом напротив них свои подписи ставят родители. Скорее их можно сравнить с университетскими семинарами, на которых проницательные студенты стремятся выявить наилучшие идеи и забраковать неудачные. Сотрудники, демонстрирующие неспособность учиться на критике, вряд ли смогут долго оставаться в нашей профессии. Быть может, такой подход покажется вам слишком жестким, но если не вывести теоретические основы разработки на практический уровень, будет страдать качество конечного продукта»

«Комментарии должны разъяснять, почему код написан именно так и никак иначе, и как этого удалось достичь – причем основной упор следует делать на раскрытии вопроса «почему?». О том как разработчик достиг поставленной задачи, свидетельствует сам код; в то же время комментарии помогают проследить ход мыслей разработчика во время разработки модуля»

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

Некачественная или случайная архитектура приводит к таким последствиям:

 • сверхтрудное сопровождение и низкая оперативность (а следовательно, финансовые потери) при введении новых свойств;

 • нежелание программистов заниматься сопровождением кода вследствие чрезмерной усложненности системы и неуверенности относительно первоочередных действий при исправлении ошибок и введении новых свойств;

 • размывание кода из-за лавинообразного роста числа объектов, за счет чего при увеличении размера исполняемых файлов сокращается производительность.

 

Ниже перечислены последствия неадекватного проектирования:

 • из-за несоблюдения стандартов создается впечатление, что все объекты создавались разными программистами;

 • модификация в одном месте приводит к нарушению в нескольких других;

 • вследствие многократного дублирования кода для изменения любой функции требуется найти и также изменить все ее экземпляры.

Поймите, других людей вам не исправить. Это очевидное, на первый взгляд, обстоятельство очень помогает в процессе взаимодействия с окружающими.

Ну вот, к примеру, классическая ситуация – цикл разработки подходит к концу, как вдруг выясняется, что один из ваших сотрудников забыл выполнить данное ему задание. Если времени в обрез, а вокруг никого, кому это задание можно было бы перепоручить, вы, скорее всего, не удержитесь и возьметесь за него сами. Скажете, это простительное исключение? Может быть, но имейте в виду – действуя подобным образом, вы приучаете своих подчиненных к тому, что за невыполненную работу никаких взысканий не последует – вы просто сами все доделаете. Хорошо ли это? Думайте сами.

Перечислю некоторые методики проверки.

 • Ежедневно наведывайтесь к своим подчиненным и интересуйтесь, как у них идут дела. Если личный контакт не представляется возможным, воспользуйтесь телефоном или, на крайний случай, электронной почтой.

 • С регулярностью в несколько дней тестируйте готовые модули кода. Эта деятельность роднит вас с тестерами, но вы должны воспринимать ее как свою первоочередную обязанность.

 • Регулярно пробуйте интегрировать компоненты в целостную систему и проверяйте архитектуру на стройность. Здесь придется «поиграть» с кодом. Так вы сможете выявлять ошибки, допущенные при конструировании, и держаться в курсе методов, которыми ваши программисты решают поставленные перед ними задачи.

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

 • Тех участников группы разработчиков, которым удалось быстро расправиться со своими задачами, следует привлекать к тестированию результатов труда остальных. Делать это нужно с осторожностью, допускать высказывания типа «тестирование – это не мое дело» нельзя. Программирование не ограничивается написанием кода, оно также предполагает обеспечение его реального функционирования.

 • Требуйте от программистов документировать все новые модули кода и составляйте из этих отчетов сопроводительную документацию для отдела тестирования. Тем самым вы дадите возможность себе и своим подчиненным оценивать ход процесса и соответствие заданным требованиям.

«Допускать высказывания типа «тестирование – это не мое дело» нельзя. Программирование не ограничивается написанием кода, оно также предполагает обеспечение его реального функционирования»

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

 Про совещания

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

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

 • Программисты склонны проектировать лишь те функции, которые они могут или хотят разрабатывать.

 • У некоторых программистов могут быть планы, отличные от ваших; трудно выявляемые, такие бунтари способны привести к саботажу совещаний.

 • Единодушная поддержка сотрудниками высказанных вами идей (если только они не объективно гениальны) наводит на грустные размышления.

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

«Совещания, не должны представлять собой арену для выражения недовольства»

 

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

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

«Фиксируйте на бумаге основные моменты совещания (или поручите эту функцию одному из своих сотрудников); не забывайте также и о том, что после окончания совещания вы должны как можно быстрее отправить всем его участникам стенограмму с четкими указаниями к действию»

«Согласно Вебстеру (Webster), одним из аспектов профессионализма является «последовательное, методичное проведение каких-либо действий». Так и в нашем случае. Последовательность в деле проведения совещаний в конечном итоге приведет вас к успеху. Дискуссии на совещаниях следует поощрять, поскольку на их основе рождаются идеи. Ваша компетенция – еще один аспект профессионализма – в ходе дискуссий, призванных перетекать в конкретные действия, должна быть очевидной»

 О компетенциях сотрудников

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

 • Формированием группы должен заниматься только ее руководитель. В этом отношении он должен пользоваться полным доверием своего начальника.

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

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

«Один из вариантов оценки продуктивности сотрудника (либо на бумаге, либо в электронном виде) предполагает еженедельный сбор информации о результатах его работы. Если вы ведете личные дела, отмечайте в них успехи и затруднения каждого работника. В частности, в этих документах следует указывать адрес электронной почты сотрудника, динамику соблюдения или, напротив, нарушения им сроков сдачи работ, участие в выработке проектных решений, предложения по решению проблем»

Опубликовать в Facebook
Опубликовать в Google Plus
Опубликовать в LiveJournal
Опубликовать в Одноклассники

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *