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

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

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

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

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

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

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

• Большую часть времени вы, руководитель, проводите с телефонной трубкой в руках.

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

<p>Решение</p>

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

Планирование

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

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

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

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

Взаимодействие
Перейти на страницу:

Похожие книги

Основы программирования в Linux
Основы программирования в Linux

В четвертом издании популярного руководства даны основы программирования в операционной системе Linux. Рассмотрены: использование библиотек C/C++ и стан­дартных средств разработки, организация системных вызовов, файловый ввод/вывод, взаимодействие процессов, программирование средствами командной оболочки, создание графических пользовательских интерфейсов с помощью инструментальных средств GTK+ или Qt, применение сокетов и др. Описана компиляция программ, их компоновка c библиотеками и работа с терминальным вводом/выводом. Даны приемы написания приложений в средах GNOME® и KDE®, хранения данных с использованием СУБД MySQL® и отладки программ. Книга хорошо структурирована, что делает обучение легким и быстрым. Для начинающих Linux-программистов

Нейл Мэтью , Ричард Стоунс , Татьяна Коротяева

ОС и Сети / Программирование / Книги по IT
97 этюдов для архитекторов программных систем
97 этюдов для архитекторов программных систем

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

Билл де Ора , Майкл Хайгард , Нил Форд

Программирование, программы, базы данных / Базы данных / Программирование / Книги по IT
Программист-прагматик. Путь от подмастерья к мастеру
Программист-прагматик. Путь от подмастерья к мастеру

Находясь на переднем крае программирования, книга "Программист-прагматик. Путь от подмастерья к мастеру" абстрагируется от всевозрастающей специализации и технических тонкостей разработки программ на современном уровне, чтобы исследовать суть процесса – требования к работоспособной и поддерживаемой программе, приводящей пользователей в восторг. Книга охватывает различные темы – от личной ответственности и карьерного роста до архитектурных методик, придающих программам гибкость и простоту в адаптации и повторном использовании.Прочитав эту книгу, вы научитесь:Бороться с недостатками программного обеспечения;Избегать ловушек, связанных с дублированием знания;Создавать гибкие, динамичные и адаптируемые программы;Избегать программирования в расчете на совпадение;Защищать вашу программу при помощи контрактов, утверждений и исключений;Собирать реальные требования;Осуществлять безжалостное и эффективное тестирование;Приводить в восторг ваших пользователей;Формировать команды из программистов-прагматиков и с помощью автоматизации делать ваши разработки более точными.

А. Алексашин , Дэвид Томас , Эндрю Хант

Программирование / Книги по IT