Страница:
Глава 10
Слова без песни
В целом разработка программных продуктов носит линейный характер. Это проявляется даже тогда, когда применяется итерационный процесс. В любом случае переход от одного этапа к другому логичен. Руководство процессом разработки, напротив, представляет собой нелинейную область деятельности. Вы постоянно вынуждены переходить от одной проблемной области к другой, причем решения, имеющие ценность в одной из таких областей, могут не иметь никакого смысла в любой другой. Таким образом, лучшее, что вы можете сделать, – это привлечь весь свой интеллектуальный ресурс к решению текущих проблем, не забывая при этом про конечную цель: вывести подчиненных из состояния хаоса и заставить их двигаться в одном направлении. Такую стратегию, наверное, можно обозначить как «жизнь над краем пропасти» – думаю, именно в таком состоянии вы проводите многие дни на работе.
Название данной главы выражает вот это самое состояние. Отчасти это перекличка с традицией композиторов эпохи романтизма, которые широко эксплуатировали жанр песни без слов (к таковым, в частности, относится Мендельсон). Мне кажется, из всего классического репертуара эти композиции – чуть ли не самые мелодичные. Смысл этой главы, по большому счету, в обратном: общая тема отсутствует, а отдельные партии довольно сложно назвать гармоничными. Может показаться, что в этой главе я собрал все темы, которые по тем или иным причинам не нашли отражения в предыдущих главах, – и это ощущение правильно. Впрочем, такую бессистемность можно обосновать и по-другому, более хитро – дело в том, что иногда наша работа производит впечатление совокупности ничем не связанных действий. Бывает, нам даже приходится разбираться с проблемами, способы решения которых в предыдущем опыте отсутствуют. Вот в этом направлении я и выстроил главу [104]. Надеюсь, вопросы, которые в ней поднимаются, внесут некоторую ясность в ваши обязанности.
Название данной главы выражает вот это самое состояние. Отчасти это перекличка с традицией композиторов эпохи романтизма, которые широко эксплуатировали жанр песни без слов (к таковым, в частности, относится Мендельсон). Мне кажется, из всего классического репертуара эти композиции – чуть ли не самые мелодичные. Смысл этой главы, по большому счету, в обратном: общая тема отсутствует, а отдельные партии довольно сложно назвать гармоничными. Может показаться, что в этой главе я собрал все темы, которые по тем или иным причинам не нашли отражения в предыдущих главах, – и это ощущение правильно. Впрочем, такую бессистемность можно обосновать и по-другому, более хитро – дело в том, что иногда наша работа производит впечатление совокупности ничем не связанных действий. Бывает, нам даже приходится разбираться с проблемами, способы решения которых в предыдущем опыте отсутствуют. Вот в этом направлении я и выстроил главу [104]. Надеюсь, вопросы, которые в ней поднимаются, внесут некоторую ясность в ваши обязанности.
Распределенная рабочая сила
Современная корпоративная культура зачастую не оставляет места для географической централизации групп разработчиков. Финансовые соображения, наличие выдающихся особо талантливых специалистов, равно как и традиции конкретной компании, – все это иногда приводит к тому, что ваши подчиненные, хотя и образуют единую группу, фактически работают в разных местах. Если сотрудники находятся в разных зданиях или даже в разных часовых поясах, обеспечить гармоничное сочетание сотрудничества с уединением, что является основным фактором продуктивной деятельности группы, не так-то просто
[105]. Если среди ваших подчиненных есть такие, которые один или два раза в неделю общаются с остальными на телеконференциях, вам не обойтись без специальных методов, позволяющих контролировать их продуктивность.
Если сотрудники находятся в разных зданиях или даже в разных часовых поясах, обеспечить гармоничное сочетание сотрудничества с уединением, что является основным фактором продуктивной деятельности группы, не так-то просто.
Если сотрудники находятся в разных зданиях или даже в разных часовых поясах, обеспечить гармоничное сочетание сотрудничества с уединением, что является основным фактором продуктивной деятельности группы, не так-то просто.
Суть проблемы
Если вам удается успешно сочетать сотрудничество с уединением, процесс разработки существенно упрощается.
• Уединение.Способность работать, не отвлекаясь на внешние раздражители, в условиях, допускающих абстрактное мышление.
• Сотрудничество.Обмен предложениями на очной встрече вплоть до выработки консенсуса во мнениях всей группы или нескольких программистов, работающих над решением одной задачи.
Группа, в которой удовлетворяются две вышеупомянутые потребности, способна работать крайне продуктивно. Для написания качественного кода необходим баланс между этими условиями.
В контексте распределенных групп, в которых одни сотрудники работают дома, другие трудятся в офисе вместе с остальными не связанными с ними функциональными обязанностями специалистами, третьи образуют более мелкие группы, также работающие удаленно, обеспечить сотрудничество и уединение довольно трудно. Одни специалисты, не испытывающие недостатка в уединении, будут лишены средств продуктивного сотрудничества. Другие могут, с одной стороны, испытывать нехватку уединения, а с другой – активно общаться с чужими с точки зрения выполняемых обязанностей людьми. Проблемы, которые возникают в подобных ситуациях, можно обобщенно сформулировать следующим образом.
• Решения, которые при условии географической централизации принимаются за считанные минуты, растягиваются на многие часы и даже дни.
• Непосредственная проверка деятельности и продуктивности персонала заменяется взаимодействием с сотрудниками по телефону и электронной почте. Таким образом, хрестоматийный принцип руководства «доверяй, но проверяй» не соблюдается.
• Техническое проектирование осуществляется в основном не в интерактивном режиме, а посредством документов. Документы же должны быть не средством, а результатом сотрудничества. Из-за ограничений по времени этап проектирования растягивается или вообще пропускается.
• Сотрудники группы лишены чувства работы в единой атмосфере. Возможности для выстраивания дружеских отношений отсутствуют.
• Виртуальное рабочее пространство формируется средствами электронной почты и службы мгновенной передачи сообщений. При всей своей полезности они не заменяют очного взаимодействия.
• Большую часть времени вы, руководитель, проводите с телефонной трубкой в руках.
Некоторые из вышеупомянутых проблем проявляют себя даже при условии географической централизации, однако руководитель, вынужденный координировать действия сотрудников, работающих в разных местах, сталкивается с ними в наихудших проявлениях.
• Уединение.Способность работать, не отвлекаясь на внешние раздражители, в условиях, допускающих абстрактное мышление.
• Сотрудничество.Обмен предложениями на очной встрече вплоть до выработки консенсуса во мнениях всей группы или нескольких программистов, работающих над решением одной задачи.
Группа, в которой удовлетворяются две вышеупомянутые потребности, способна работать крайне продуктивно. Для написания качественного кода необходим баланс между этими условиями.
В контексте распределенных групп, в которых одни сотрудники работают дома, другие трудятся в офисе вместе с остальными не связанными с ними функциональными обязанностями специалистами, третьи образуют более мелкие группы, также работающие удаленно, обеспечить сотрудничество и уединение довольно трудно. Одни специалисты, не испытывающие недостатка в уединении, будут лишены средств продуктивного сотрудничества. Другие могут, с одной стороны, испытывать нехватку уединения, а с другой – активно общаться с чужими с точки зрения выполняемых обязанностей людьми. Проблемы, которые возникают в подобных ситуациях, можно обобщенно сформулировать следующим образом.
• Решения, которые при условии географической централизации принимаются за считанные минуты, растягиваются на многие часы и даже дни.
• Непосредственная проверка деятельности и продуктивности персонала заменяется взаимодействием с сотрудниками по телефону и электронной почте. Таким образом, хрестоматийный принцип руководства «доверяй, но проверяй» не соблюдается.
• Техническое проектирование осуществляется в основном не в интерактивном режиме, а посредством документов. Документы же должны быть не средством, а результатом сотрудничества. Из-за ограничений по времени этап проектирования растягивается или вообще пропускается.
• Сотрудники группы лишены чувства работы в единой атмосфере. Возможности для выстраивания дружеских отношений отсутствуют.
• Виртуальное рабочее пространство формируется средствами электронной почты и службы мгновенной передачи сообщений. При всей своей полезности они не заменяют очного взаимодействия.
• Большую часть времени вы, руководитель, проводите с телефонной трубкой в руках.
Некоторые из вышеупомянутых проблем проявляют себя даже при условии географической централизации, однако руководитель, вынужденный координировать действия сотрудников, работающих в разных местах, сталкивается с ними в наихудших проявлениях.
Решение
Если провести централизацию нет никакой возможности, значит, придется адаптировать ваш стиль руководства к создавшимся условиям. Как я говорил в главе 1, адаптация – это тот навык, без которого руководителю программистов не обойтись. Рассмотрим, как он проявляется в некоторых аспектах деятельности руководителя в условиях распределенной группы.
Это невозможно без предварительного планирования проекта, позволяющего выделить в его рамках отдельные блоки, которые можно распределить между подчиненными с поправкой на недостаток сотрудничества.
Если вам не удастся четко сформулировать отдельные задания, на их уточнение уйдет гораздо больше времени, чем обычно, – просто в силу удаленности от сотрудников. Кроме того, вы должны спланировать деятельность персонала таким образом, чтобы результаты его работы легко стыковались. В таких условиях предпочтение нужно отдавать компонентной архитектуре – если, конечно, она вписывается в корпоративную стратегию. Конструирование программных продуктов, таким образом, должно походить на сборочный конвейер, на котором каждая деталь идеально стыкуется со всеми остальными. Хороший принцип, который неплохо было бы реализовать. Это вполне возможно, хотя и требует значительных усилий по части планирования и проектирования.
Вообще-то планирование, проводящееся на ранних этапах разработки любого проекта, предполагает очное взаимодействие. Иначе говоря, чтобы приступить к созданию проектного решения, по крайней мере один раз вам придется собрать всех сотрудников в одном месте. Это недешево, но временные затраты на проектирование по электронной почте или по телефону оказываются значительно серьезнее. Постарайтесь во время этого сеанса планирования решить две задачи: утвердить основы проектного решения и сделать первые шаги в направлении формирования команды. Полезно в этом смысле где-то раз в год выезжать вместе с сотрудниками на отдых в экзотические страны. Впрочем, вполне возможно, что, узнав цены на авиабилеты «туда и обратно», вы решите, что куда мудрее будет развернуть за те же деньги каналы для проведения видеоконференций или, например, заказать какую-нибудь хитрую систему, которая могла бы отображать электронное табло на одном мониторе и картинку нескольких групп на другом. Конечно, все подобные экономические вопросы нужно решать исходя из бюджета. В любом случае, пользуясь имеющимися у компании средствами, вы должны поощрять взаимодействие участников группы.
Естественно, в большинстве географически рассредоточенных групп электронная почта выступает в роли основного средства взаимодействия. Для менеджера в практическом смысле это означает, что на проверку новых писем приходится тратить значительную часть рабочего дня. Но ведь у вас много других административных обязанностей, а значит, нужно учиться отвечать на письма как можно быстрее. Попытайтесь ограничить переписку по электронной почте темами, которые можно адекватно выразить в письменной речи или на схемах. Все дискуссии следует проводить по телефону, а для решений, требующих документирования, вполне подойдет электронная почта.
Невзирая на все недостатки документно-ориентированного процесса проектирования, скорее всего, именно на нем вы остановите свой выбор. Кроме того, полезен в данном контексте метод проектирования по контракту, подразумевающий первоочередное (в самом начале периода проектирования) создание открытых интерфейсов объектов, с тем чтобы впоследствии их можно было без труда разработать. Этот метод полезен даже в условиях централизации группы, а уж если один разработчик трудится в Калифорнии, а другой – где-нибудь в Новой Англии, соглашение по части взаимодействия компонентов и их способности к взаимодействию выходит на первый план. Купите качественное программное обеспечение для совместной работы и задействуйте его в роли библиотеки документов. За рыночную нишу программных продуктов для совместной работы соревнуются несколько производителей, и это вам на руку – следите за их последними разработками [106].
Удаленный мониторинг персонала – дело ненадежное. Бывает, проходишь за спиной сотрудника, который вместо работы шатается по Сети, и спрашиваешь: «А почему не работаешь?!» Ну, он, конечно, отвечает: «Знал бы, что вы рядом, принялся бы за работу!» Ситуация, на первый взгляд, забавная, удачно характеризует особенности роли «виртуального шефа». В отсутствие начальника люди начинают валять дурака – это в природе человека. Как с этим бороться? Сравнительно эффективный мониторинг возможен только при наличии формального плана сдачи сотрудниками результатов и при условии тщательной проверки его выполнения. Структура распределения работ в данном случае должна быть мельче, чем обычно, – так вы сможете с большей уверенностью предотвращать отклонения от графика разработки проекта. Для выполнения контрольной функции вам опять же понадобятся телефон и электронная почта. Заставьте сотрудников присылать еженедельные отчеты (а в исключительных случаях – даже ежедневные).
Можно также обратиться к решению в духе Оруэлла – оснастить рабочие станции разработчиков программами дистанционного мониторинга, позволяющими в любой момент видеть их экран. Сами сотрудники, естественно, должны знать, что их компьютеры «прослушиваются», и если уж необходимость плотного слежения за каким-то деятелем назрела, это решение себя оправдывает. Правда, надо сказать, оно совсем не способствует укреплению доверительных отношений – скорее, напротив, вызывает негодование. Поэтому прежде чем прибегать к подобным мерам, хорошо подумайте – стоит ли.
Сравнительно эффективное отслеживание возможно только при наличии формального плана сдачи сотрудниками результатов и при условии тщательной проверки его выполнения.
Планирование
Во-первых, вы должны тщательно продумать вопрос распределения задач. Это невозможно без предварительного планирования проекта, позволяющего выделить в его рамках отдельные блоки, которые можно распределить между подчиненными с поправкой на недостаток сотрудничества. Конечно, лучше всего детально планировать все проекты, но в случае с распределенной группой эта проблема приобретает особую актуальность.Это невозможно без предварительного планирования проекта, позволяющего выделить в его рамках отдельные блоки, которые можно распределить между подчиненными с поправкой на недостаток сотрудничества.
Если вам не удастся четко сформулировать отдельные задания, на их уточнение уйдет гораздо больше времени, чем обычно, – просто в силу удаленности от сотрудников. Кроме того, вы должны спланировать деятельность персонала таким образом, чтобы результаты его работы легко стыковались. В таких условиях предпочтение нужно отдавать компонентной архитектуре – если, конечно, она вписывается в корпоративную стратегию. Конструирование программных продуктов, таким образом, должно походить на сборочный конвейер, на котором каждая деталь идеально стыкуется со всеми остальными. Хороший принцип, который неплохо было бы реализовать. Это вполне возможно, хотя и требует значительных усилий по части планирования и проектирования.
Вообще-то планирование, проводящееся на ранних этапах разработки любого проекта, предполагает очное взаимодействие. Иначе говоря, чтобы приступить к созданию проектного решения, по крайней мере один раз вам придется собрать всех сотрудников в одном месте. Это недешево, но временные затраты на проектирование по электронной почте или по телефону оказываются значительно серьезнее. Постарайтесь во время этого сеанса планирования решить две задачи: утвердить основы проектного решения и сделать первые шаги в направлении формирования команды. Полезно в этом смысле где-то раз в год выезжать вместе с сотрудниками на отдых в экзотические страны. Впрочем, вполне возможно, что, узнав цены на авиабилеты «туда и обратно», вы решите, что куда мудрее будет развернуть за те же деньги каналы для проведения видеоконференций или, например, заказать какую-нибудь хитрую систему, которая могла бы отображать электронное табло на одном мониторе и картинку нескольких групп на другом. Конечно, все подобные экономические вопросы нужно решать исходя из бюджета. В любом случае, пользуясь имеющимися у компании средствами, вы должны поощрять взаимодействие участников группы.
Взаимодействие
Большое человеческое спасибо Александру Грэму Беллу (Alexander Graham Bell)! Телефон значительно облегчил для нас двустороннюю связь в реальном времени. Правда, полагаю, что Белл воскликнул «Поди-ка сюда, Ватсон!», просто утомившись от своего аппарата и решив, что лучше переговорить с помощником с глазу на глаз. Если бы все ваши подчиненные находились в одно время в одном месте, планировать распорядок дня было бы гораздо проще. Тем не менее, если, конечно, вы не сводите все взаимодействие к общению по электронной почте, имейте в виду, что в условиях децентрализации группы телефон представляет собой заметную ценность. Если вы можете себе позволить организацию регулярных видеоконференций, качество взаимодействия, несомненно, повысится. Впрочем, далеко не все компании на это способны. При наличии канала с достаточной пропускной способностью можно разориться на веб-камеры и соответствующее программное обеспечение. Замечу, что с этими средствами мне не удалось добиться сколько-нибудь заметных успехов.Естественно, в большинстве географически рассредоточенных групп электронная почта выступает в роли основного средства взаимодействия. Для менеджера в практическом смысле это означает, что на проверку новых писем приходится тратить значительную часть рабочего дня. Но ведь у вас много других административных обязанностей, а значит, нужно учиться отвечать на письма как можно быстрее. Попытайтесь ограничить переписку по электронной почте темами, которые можно адекватно выразить в письменной речи или на схемах. Все дискуссии следует проводить по телефону, а для решений, требующих документирования, вполне подойдет электронная почта.
Невзирая на все недостатки документно-ориентированного процесса проектирования, скорее всего, именно на нем вы остановите свой выбор. Кроме того, полезен в данном контексте метод проектирования по контракту, подразумевающий первоочередное (в самом начале периода проектирования) создание открытых интерфейсов объектов, с тем чтобы впоследствии их можно было без труда разработать. Этот метод полезен даже в условиях централизации группы, а уж если один разработчик трудится в Калифорнии, а другой – где-нибудь в Новой Англии, соглашение по части взаимодействия компонентов и их способности к взаимодействию выходит на первый план. Купите качественное программное обеспечение для совместной работы и задействуйте его в роли библиотеки документов. За рыночную нишу программных продуктов для совместной работы соревнуются несколько производителей, и это вам на руку – следите за их последними разработками [106].
Проверка
В том что касается проверки результатов сотрудников децентрализованной группы, ваши обязанности весьма осложняются. Из-за разницы временных поясов вам, вероятнее всего, придется удлинить свой рабочий день. Такое решение – фактически единственный способ эффективной организации в данных условиях – требует от вас выносливости. Если вам приходится ежедневно проводить на работе по 12 часов, не забывайте о том, что вы живой человек, и кроме профессии в жизни есть еще кое-что. Рекомендую взять за правило при первой возможности делать перерывы и посвящать их личным делам – в противном случае вы вряд ли долго протянете.Удаленный мониторинг персонала – дело ненадежное. Бывает, проходишь за спиной сотрудника, который вместо работы шатается по Сети, и спрашиваешь: «А почему не работаешь?!» Ну, он, конечно, отвечает: «Знал бы, что вы рядом, принялся бы за работу!» Ситуация, на первый взгляд, забавная, удачно характеризует особенности роли «виртуального шефа». В отсутствие начальника люди начинают валять дурака – это в природе человека. Как с этим бороться? Сравнительно эффективный мониторинг возможен только при наличии формального плана сдачи сотрудниками результатов и при условии тщательной проверки его выполнения. Структура распределения работ в данном случае должна быть мельче, чем обычно, – так вы сможете с большей уверенностью предотвращать отклонения от графика разработки проекта. Для выполнения контрольной функции вам опять же понадобятся телефон и электронная почта. Заставьте сотрудников присылать еженедельные отчеты (а в исключительных случаях – даже ежедневные).
Можно также обратиться к решению в духе Оруэлла – оснастить рабочие станции разработчиков программами дистанционного мониторинга, позволяющими в любой момент видеть их экран. Сами сотрудники, естественно, должны знать, что их компьютеры «прослушиваются», и если уж необходимость плотного слежения за каким-то деятелем назрела, это решение себя оправдывает. Правда, надо сказать, оно совсем не способствует укреплению доверительных отношений – скорее, напротив, вызывает негодование. Поэтому прежде чем прибегать к подобным мерам, хорошо подумайте – стоит ли.
Сравнительно эффективное отслеживание возможно только при наличии формального плана сдачи сотрудниками результатов и при условии тщательной проверки его выполнения.
Личные контакты
Чем чаще вы будете посещать своих сотрудников в их привычных рабочих условиях, тем выше шансы на построение полноценной команды. Обозначая свое присутствие на рабочем месте, вы способствуете развитию у сотрудника чувства участия в коллективной деятельности и придаете вес своему лидерству в остальное время. На подобные визиты уходит много времени, да и не бесплатно это, однако таким способом вы сможете смягчить некоторые недостатки децентрализации.
Культурный фактор в менеджменте
Америка – настоящий плавильный котел народов мира; нет – точнее, наверное, будет сказать «культурный винегрет». И, надо заметить, программировать умеют не только американцы. Научиться руководить сотрудниками, относящими себя к разным национальностям и культурам, не так уж просто. Имея дело с неоднородным в культурном отношении персоналом, вы должны в первую очередь видоизменить привычные методы взаимодействия и мотивирования. Стремитесь к неофициальному общению с представителями иных народов – интересуйтесь их семейными обычаями и культурными традициями. Так вы сможете добиться от них большего рвения; кроме того, видя, что вы пытаетесь вникнуть в их особое миропонимание, программист, скажем, из России [где это?] сможет почувствовать свою ценность в команде.
Язык и культура
Работая с представителями разных культур, вы должны привести свою речь к определенному стандарту. С чужаками нельзя общаться так же, как с корешами из соседнего двора, – не выйдет! Структуры речи, общераспространенные разговорные стили и даже язык тела – во всех этих отношениях между разными культурами наблюдаются серьезные различия. Заставьте себя говорить медленнее – поймите, что факт употребления английского как второго языка еще не означает знания американского сленга, адекватного восприятия привычки к небрежному построению предложений и следования вашему ходу мысли, выраженному в словах. Даже британский английский в некоторых моментах существенно (и радикально!) отличается от американского
[107].
Нельзя общаться с чужаками так же, как с корешами из соседнего двора, – не выйдет!
Есть и другие культурные различия, которые иногда удивляют, а иногда кажутся достойными включения в стандартную корпоративную практику. Знаете ли вы, например, что среди филиппинцев публичное рукопожатие служит признаком дружбы? Когда индиец первый раз приходит в гости, он обязательно приносит подарок. Австралийская культура, на первый взгляд, во многом пересекается с американской, но знаете ли вы, в каких количествах австралийцы поедают овощную пасту? [108]А как насчет традиционных американских праздников? Уверяю вас: человек, родившийся в Бангалоре, в День благодарения будет, как обычно, работать. Вы должны выяснить все существующие различия и стать гражданином мира – усваивайте лучшие черты всех культур и включайте их в свой «джентльменский набор» лидера.
Нельзя общаться с чужаками так же, как с корешами из соседнего двора, – не выйдет!
Есть и другие культурные различия, которые иногда удивляют, а иногда кажутся достойными включения в стандартную корпоративную практику. Знаете ли вы, например, что среди филиппинцев публичное рукопожатие служит признаком дружбы? Когда индиец первый раз приходит в гости, он обязательно приносит подарок. Австралийская культура, на первый взгляд, во многом пересекается с американской, но знаете ли вы, в каких количествах австралийцы поедают овощную пасту? [108]А как насчет традиционных американских праздников? Уверяю вас: человек, родившийся в Бангалоре, в День благодарения будет, как обычно, работать. Вы должны выяснить все существующие различия и стать гражданином мира – усваивайте лучшие черты всех культур и включайте их в свой «джентльменский набор» лидера.
Мотивация чужаков и контроль над ними
Мотивация программистов деньгами среди стандартного набора американских приемов менеджмента является «наименьшим общим кратным». С другой стороны, имейте в виду, что деньги – это наименее эффективный способ построения командной атмосферы в многокультурной среде. Что же делать? Проанализировать все факторы, способные стимулировать к работе существующую команду или новых сотрудников, которых вы только собираетесь привлечь. По результатам недавнего опроса 100 наемных работников, не являющихся гражданами США, Дин Бетменг (Dene Bettmeng) делает следующие выводы:
Урок 1.Впоследствии выяснилось, что для телефонных интервью консультантам предоставили длиннющие шпаргалки с ответами на все мыслимые и немыслимые вопросы. Стоило мне спросить: «Какое средство моделирования данных вы предпочитаете?» – как абонент, выдержав паузу, переспрашивал: «Повторите, пожалуйста, вопрос – я не совсем понял, о чем речь». В это время он листал шпаргалки в поисках правильного ответа. Отыскав его, он отвечал: «Больше всего мне нравится ERStudio, но у него есть такие-то недостатки. ERWin – тоже ничего, он выгодно отличается тем-то и тем-то». Понимаете, дословно повторяя содержимое шпаргалок, они говорили все то, что я хотел услышать. Мне уже стало казаться, что группа будет состоять исключительно из гениев. Вскоре после начала работы над проектом я понял, как сильно ошибался.
Собственно, по мере продвижения проектов я получил еще несколько печальных уроков. Все мои неудачи происходили от того, что я совершенно не учитывал культурные факторы – я даже не предполагал, что в деле управления группами, состоящими из зарубежных специалистов, культурные факторы имеют какое-то значение.
Урок 2.Когда индиец кивает головой, он имеет в виду «нет», а не «да». Вы можете себе представить, как это сбивает с толку?! Ведь мы принимаем за аксиому, что кивок выражает согласие!
Урок 3.В большинстве случаев специалисты из Индии не препираются, не пытаются вас поправить и не подвергают сомнению авторитет начальства – по крайней мере публично. Таким образом, они согласятся со всем, что вы скажете, – пусть даже вы будете нести полную чушь. Некоторые из них после совещаний продолжают решать задачу по-своему, вне зависимости от того, что им сказали. Работая с индийцами, я возомнил себя великолепным лидером – ведь американские программисты ни за что не позволят достичь консенсуса так быстро и легко!
Урок 4.Как правило, если консультанты не понимали, что я им говорил, они даже не пытались дать об этом знать. Они несколько раз повторяли, что все мои предложения в высшей степени разумны, после чего продолжали кодировать так, как считали нужным.
Урок 5.Последняя индийская перепись населения зафиксировала в стране более 200 языков и диалектов. Поскольку все мои сотрудники приехали из разных регионов Индии (кстати сказать, друг друга они недолюбливали), между собой они общались исключительно на ломаном английском. Многочисленные улыбки и жесты отнюдь не способствовали преодолению взаимного непонимания.
Урок 6.Несмотря на то, что всех новоиспеченных сотрудников нам привело одно и то же агентство, все они работали на разные консалтинговые компании. Я платил за их услуги по 125 долларов в час, из которых самим исполнителям доставалось только от 15 до 55.
Но… все эти уроки я выучил слишком поздно. Лишь один из трех проектов был успешно завершен; остальные два постигла печальная судьба – немалые деньги оказались выброшенными. Ни за что больше не буду ввязываться в подобные авантюры.
«Многие сотрудники рассматривают в качестве основных преимуществ работы в американских компаниях корпоративную культуру и корпоративные правила, а также технологическую оснащенность. В частности, их привлекают перспективы карьерного роста, заработная плата и льготы, равно как и возможность изучать и применять новые технологии. Все эти люди считают, что работать в компании, расположенной в США, в целом предпочтительнее, чем в какой бы то ни было другой стране. Помимо вышеперечисленных преимуществ, они ценят политическую стабильность, напряженный ритм деятельности и командный дух» [109].Как и в любой команде, руководителю необходимо составить представление о своих разношерстных подчиненных – иначе он не сможет преуспеть в качестве лидера. Наличие в подведомственной группе представителей различных культур усложняет познание, но в то же время дает неоценимый (в зависимости от ситуации, положительный или отрицательный) личный опыт. Сталкиваясь с трудностями в поисках свежих американских талантов, мы обращаем внимание на заморских консультантов. Иной раз ставка на них себя оправдывает, но бывает и по-другому. В некоторых культурах споры с начальником (или даже уточнение его позиции) не поощряются. В результате начальник утверждается во мнении, что подчиненный понял, чего от него хотят, а в том, как жестоко ошибся, убеждается, когда уже слишком поздно. В этой области нужно соблюдать осторожность.
Кошачьи разборки
Иностранный легион
Мы решили как можно быстрее заполнить вакансии в трех проектах за счет привлечения 12 иностранных консультантов. Кандидаты ниже экспертного уровня нас не интересовали – по крайней мере, именно таким образом мы сформулировали свои требования. Как выяснилось, все специалисты, которых нам подобрали, приехали из Индии – страны, стремительно укрепляющей свои позиции по части квалификации программистов. Мне предстояло составить из них группы в соответствии со специальностями и приступить к работе над проектами. Я участвовал во всех интервью, отбирая кандидатов по специальности. К сожалению, все интервью проводились по телефону – тут-то я и получил первый урок. Естественно, осознать, какую головную боль я себе организовал, мне удалось лишь тогда, когда сформированные группы принялись за работу.Урок 1.Впоследствии выяснилось, что для телефонных интервью консультантам предоставили длиннющие шпаргалки с ответами на все мыслимые и немыслимые вопросы. Стоило мне спросить: «Какое средство моделирования данных вы предпочитаете?» – как абонент, выдержав паузу, переспрашивал: «Повторите, пожалуйста, вопрос – я не совсем понял, о чем речь». В это время он листал шпаргалки в поисках правильного ответа. Отыскав его, он отвечал: «Больше всего мне нравится ERStudio, но у него есть такие-то недостатки. ERWin – тоже ничего, он выгодно отличается тем-то и тем-то». Понимаете, дословно повторяя содержимое шпаргалок, они говорили все то, что я хотел услышать. Мне уже стало казаться, что группа будет состоять исключительно из гениев. Вскоре после начала работы над проектом я понял, как сильно ошибался.
Собственно, по мере продвижения проектов я получил еще несколько печальных уроков. Все мои неудачи происходили от того, что я совершенно не учитывал культурные факторы – я даже не предполагал, что в деле управления группами, состоящими из зарубежных специалистов, культурные факторы имеют какое-то значение.
Урок 2.Когда индиец кивает головой, он имеет в виду «нет», а не «да». Вы можете себе представить, как это сбивает с толку?! Ведь мы принимаем за аксиому, что кивок выражает согласие!
Урок 3.В большинстве случаев специалисты из Индии не препираются, не пытаются вас поправить и не подвергают сомнению авторитет начальства – по крайней мере публично. Таким образом, они согласятся со всем, что вы скажете, – пусть даже вы будете нести полную чушь. Некоторые из них после совещаний продолжают решать задачу по-своему, вне зависимости от того, что им сказали. Работая с индийцами, я возомнил себя великолепным лидером – ведь американские программисты ни за что не позволят достичь консенсуса так быстро и легко!
Урок 4.Как правило, если консультанты не понимали, что я им говорил, они даже не пытались дать об этом знать. Они несколько раз повторяли, что все мои предложения в высшей степени разумны, после чего продолжали кодировать так, как считали нужным.
Урок 5.Последняя индийская перепись населения зафиксировала в стране более 200 языков и диалектов. Поскольку все мои сотрудники приехали из разных регионов Индии (кстати сказать, друг друга они недолюбливали), между собой они общались исключительно на ломаном английском. Многочисленные улыбки и жесты отнюдь не способствовали преодолению взаимного непонимания.
Урок 6.Несмотря на то, что всех новоиспеченных сотрудников нам привело одно и то же агентство, все они работали на разные консалтинговые компании. Я платил за их услуги по 125 долларов в час, из которых самим исполнителям доставалось только от 15 до 55.
Но… все эти уроки я выучил слишком поздно. Лишь один из трех проектов был успешно завершен; остальные два постигла печальная судьба – немалые деньги оказались выброшенными. Ни за что больше не буду ввязываться в подобные авантюры.
Оценка методологий разработки программных средств
Раньше программирование считалось уделом инженеров и ученых, весьма далеких от суеты бизнес-центров. Нынче компьютерами пользуются все подряд, а употребление технологических достижений в коммерческих целях обязывает создавать качественные программные продукты вовремя и в рамках установленного бюджета. К последнему утверждению можно, конечно, относиться с иронией, но факт остается фактом: эпоха программ, разрабатывавшихся энтузиастами по собственным правилам, ушла в историю. Бизнес требует тщательности в разработке и внимания к практическому результату деятельности персонала. Здесь-то и начинается самое интересное. Практически все представители нашей индустрии, получившие какое-никакое признание, считают себя экспертами и норовят продать «уникальные» методологии разработки.
Со мной другая ситуация – я пытаюсь продать принцип эклектичности в методиках разработки. Задействуйте и совершенствуйте те методы, которые доказали свою практичность для вас лично, для группы и для компании. Создавайте собственные методы и приспосабливайте их для нужд своей организации – вне зависимости от того, что они собой представляют, суть должна быть одна: оперативная разработка качественного программного обеспечения. В следующих разделах я привожу обзор заметных школ разработки программных средств, причем основной акцент делаю на их концептуальной основе. Школы проектирования я обсуждать не собираюсь. Структурное программирование, объектно-ориентированное проектирование, эталоны проектирования – все эти течения в основном сфокусированы на деталях конструкции и значительно меньше внимания уделяют общей методологии разработки. Архитектурные проблемы (рассматриваемые в главе 6) также не получают в них достаточно глубокого развития. Итак, отступив от деталей, я собираюсь представить на ваш суд наиболее общий анализ ситуации.
Со мной другая ситуация – я пытаюсь продать принцип эклектичности в методиках разработки. Задействуйте и совершенствуйте те методы, которые доказали свою практичность для вас лично, для группы и для компании. Создавайте собственные методы и приспосабливайте их для нужд своей организации – вне зависимости от того, что они собой представляют, суть должна быть одна: оперативная разработка качественного программного обеспечения. В следующих разделах я привожу обзор заметных школ разработки программных средств, причем основной акцент делаю на их концептуальной основе. Школы проектирования я обсуждать не собираюсь. Структурное программирование, объектно-ориентированное проектирование, эталоны проектирования – все эти течения в основном сфокусированы на деталях конструкции и значительно меньше внимания уделяют общей методологии разработки. Архитектурные проблемы (рассматриваемые в главе 6) также не получают в них достаточно глубокого развития. Итак, отступив от деталей, я собираюсь представить на ваш суд наиболее общий анализ ситуации.