Как пасти котов. Наставление для программистов, руководящих другими программистами
Шрифт:
Резюме
Итак, я упомянул о некоторых областях взаимоотношений с начальством, на которые вам надлежит обратить особое внимание. Основная ваша цель, по-моему, должна состоять в том, чтобы наладить с боссом конструктивное взаимодействие, от которого выиграют обе стороны. Ниже я привожу краткий перечень наиболее важных моментов этой стороны вашей деятельности.
• Войдите в положение начальницы – она в своей работе подвергается серьезному давлению. Первой реакцией на ее замечания должно быть согласие, однако если у вас есть разумные и обоснованные предложения, выскажите их.
• Честность в суждениях в любом случае предпочтительнее нереалистичных обещаний – пусть даже она иногда приводит к не слишком приятным последствиям.
• Помогайте начальнице в вопросах планирования. Настаивайте на необходимости
• Если вам нечего противопоставить замечаниям начальницы, признайте поражение. Не стоит вешать ей лапшу на уши в попытках замаскировать собственные огрехи.
• Будьте готовы к непредвиденным изменениям – чем лучше вы будете осведомлены, тем проще будет с ними столкнуться. Иногда неожиданные решения исходят от начальства, в иных случаях – обусловливаются внешними факторами. Тщательная подготовка есть залог ваших успехов [103] .
103
Это «переработка» известного высказывания Пастера (Pasteur): «шанс приходит только к тем, кто к нему готов». Авторство парафраза принадлежит не мне – впервые я его услышал в детстве из уст отца.
• Следите за признаками инерции в самом себе и в начальнице. Если она отрицает очевидную потребность в изменениях, старайтесь спасти положение, пока не поздно.
Чтобы окончательно закрыть тему взаимоотношений с начальницей, скажу еще одну вещь. Обращайтесь с ней так, как хотели бы, чтобы обращались с вами. Это золотое правило, которое, хоть и ассоциируется с воскресной школой, работает во всех сферах человеческой деятельности.
Конец уже близко
Не карьеры, а книги. Следующая глава будет последней. В ней рассматриваются самые разные вопросы, которым в предыдущих главах было уделено недостаточно внимания или которые вообще не упоминались. Материал книги я решил структурировать по тематическому принципу – в соответствии с различными областями деятельности, с которыми менеджеру приходится сталкиваться каждый божий день. Следующая же глава, по большому счету, бессистемна. В ней вы, в частности, познакомитесь с необычными для руководителя программистов проблемами, выходящими за рамки повседневной деятельности.
Глава 10
Слова без песни
В целом разработка программных продуктов носит линейный характер. Это проявляется даже тогда, когда применяется итерационный процесс. В любом случае переход от одного этапа к другому логичен. Руководство процессом разработки, напротив, представляет собой нелинейную область деятельности. Вы постоянно вынуждены переходить от одной проблемной области к другой, причем решения, имеющие ценность в одной из таких областей, могут не иметь никакого смысла в любой другой. Таким образом, лучшее, что вы можете сделать, – это привлечь весь свой интеллектуальный ресурс к решению текущих проблем, не забывая при этом про конечную цель: вывести подчиненных из состояния хаоса и заставить их двигаться в одном направлении. Такую стратегию, наверное, можно обозначить как «жизнь над краем пропасти» – думаю, именно в таком состоянии вы проводите многие дни на работе.
Название данной главы выражает вот это самое состояние. Отчасти это перекличка с традицией композиторов эпохи романтизма, которые широко эксплуатировали жанр песни без слов (к таковым, в частности, относится Мендельсон). Мне кажется, из всего классического репертуара эти композиции – чуть ли не самые мелодичные. Смысл этой главы, по большому счету, в обратном: общая тема отсутствует, а отдельные партии довольно сложно назвать гармоничными. Может показаться, что в этой главе я собрал все темы, которые по тем или иным причинам не нашли отражения в предыдущих главах, – и это ощущение правильно. Впрочем, такую бессистемность можно обосновать и по-другому, более хитро – дело в том, что иногда наша работа производит впечатление совокупности ничем не связанных действий. Бывает, нам даже приходится разбираться с проблемами, способы решения которых в предыдущем опыте отсутствуют. Вот в этом направлении я и выстроил главу [104] . Надеюсь, вопросы, которые в ней поднимаются, внесут некоторую ясность в ваши обязанности.
104
Помимо
всего прочего, я опасался, что глава под названием «Разное» не вызовет должного читательского интереса.Распределенная рабочая сила
Современная корпоративная культура зачастую не оставляет места для географической централизации групп разработчиков. Финансовые соображения, наличие выдающихся особо талантливых специалистов, равно как и традиции конкретной компании, – все это иногда приводит к тому, что ваши подчиненные, хотя и образуют единую группу, фактически работают в разных местах. Если сотрудники находятся в разных зданиях или даже в разных часовых поясах, обеспечить гармоничное сочетание сотрудничества с уединением, что является основным фактором продуктивной деятельности группы, не так-то просто [105] . Если среди ваших подчиненных есть такие, которые один или два раза в неделю общаются с остальными на телеконференциях, вам не обойтись без специальных методов, позволяющих контролировать их продуктивность.
105
О сотрудничестве и уединении мы говорили в главе 4.
Если сотрудники находятся в разных зданиях или даже в разных часовых поясах, обеспечить гармоничное сочетание сотрудничества с уединением, что является основным фактором продуктивной деятельности группы, не так-то просто.
Суть проблемы
Если вам удается успешно сочетать сотрудничество с уединением, процесс разработки существенно упрощается.
• Уединение. Способность работать, не отвлекаясь на внешние раздражители, в условиях, допускающих абстрактное мышление.
• Сотрудничество. Обмен предложениями на очной встрече вплоть до выработки консенсуса во мнениях всей группы или нескольких программистов, работающих над решением одной задачи.
Группа, в которой удовлетворяются две вышеупомянутые потребности, способна работать крайне продуктивно. Для написания качественного кода необходим баланс между этими условиями.
В контексте распределенных групп, в которых одни сотрудники работают дома, другие трудятся в офисе вместе с остальными не связанными с ними функциональными обязанностями специалистами, третьи образуют более мелкие группы, также работающие удаленно, обеспечить сотрудничество и уединение довольно трудно. Одни специалисты, не испытывающие недостатка в уединении, будут лишены средств продуктивного сотрудничества. Другие могут, с одной стороны, испытывать нехватку уединения, а с другой – активно общаться с чужими с точки зрения выполняемых обязанностей людьми. Проблемы, которые возникают в подобных ситуациях, можно обобщенно сформулировать следующим образом.
• Решения, которые при условии географической централизации принимаются за считанные минуты, растягиваются на многие часы и даже дни.
• Непосредственная проверка деятельности и продуктивности персонала заменяется взаимодействием с сотрудниками по телефону и электронной почте. Таким образом, хрестоматийный принцип руководства «доверяй, но проверяй» не соблюдается.
• Техническое проектирование осуществляется в основном не в интерактивном режиме, а посредством документов. Документы же должны быть не средством, а результатом сотрудничества. Из-за ограничений по времени этап проектирования растягивается или вообще пропускается.
• Сотрудники группы лишены чувства работы в единой атмосфере. Возможности для выстраивания дружеских отношений отсутствуют.
• Виртуальное рабочее пространство формируется средствами электронной почты и службы мгновенной передачи сообщений. При всей своей полезности они не заменяют очного взаимодействия.
• Большую часть времени вы, руководитель, проводите с телефонной трубкой в руках.
Некоторые из вышеупомянутых проблем проявляют себя даже при условии географической централизации, однако руководитель, вынужденный координировать действия сотрудников, работающих в разных местах, сталкивается с ними в наихудших проявлениях.