Ознакомительная версия. Доступно 11 страниц из 55
подразделений, разных специальностей, которым пришлось научиться работать вместе. За год они стали хорошими коллегами и даже друзьями. Но как только проект начал подходить к завершению, они «разъехались» по своим подразделениям в противоположных концах здания. Другой проектной группе потребовалось это помещение, поэтому команда согласилась «переехать». Тем не менее им все еще нужно было прояснять некоторые моменты, поэтому члены команды продолжали работать совместно, но теперь уже не бок о бок.
На следующий день после того, как команда «переехала», простой вопрос от тестировщика в области автоматизации перерос в конфликт. Он спросил у другого тестировщика, как должна работать функция, которой они занимаются. Тот не знал ответа и предложил позвать дизайнеров, работающих в другом конце здания. Если бы дизайнеры ответили на вопрос, команда продолжила бы работать. Вместо этого тестировщик, который, видимо, не знал, к какому дизайнеру обратиться, написал письмо менеджеру по контролю качества. Тот написал письмо менеджеру по дизайну, который, в свою очередь, обратился к дизайнеру. Дизайнер разозлился. Он решил, что тестировщик тронулся головой, поскольку обратился к менеджеру. Дизайнер отправил грубое письмо тестировщику, который переслал его своему менеджеру, и в конце концов команде пришлось собраться для примирения в конференц-зале и разобраться с цепочкой сообщений. Неважно, что первоначальный вопрос был простым или даже тривиальным. Важно то, что всего двумя днями ранее тестировщик мог бы просто «через стол» задать вопрос дизайнеру напрямую, а затем они продолжили бы работать.
Это не означает, что размещение в едином пространстве – единственный способ организовать хорошее сотрудничество. Но это все-таки дает важное преимущество.
УПРАВЛЕНИЕ ДИСТАНЦИОННЫМ СОТРУДНИЧЕСТВОМ
Пожалуй, ни одна тема в технологических командах не обсуждается так же горячо, как удаленная работа. Она давно стала частью технического мира. Действительно, мыслительная деятельность идеально подходит для удаленной работы. Компьютеры и интернет предоставили нам инструменты для работы в любой точке мира, и многие работники дорожат этой свободой.
Налаживание хорошего сотрудничества с удаленными работниками сложнее, чем с рядом сидящими специалистами, и требует гораздо больше усилий. Часто одни члены команды работают удаленно, а другие совместно. Это создает несбалансированность информационных потоков, что может снизить эффективность удаленных работников. Когда сотрудники общаются друг с другом возле кулера с водой, обмениваясь информацией, которая может быть связана с проектом, а может нет, это создает канал связи, к которому удаленные работники не имеют доступа. И это создает дисбаланс.
При планировании участия удаленных работников в команде важно уделять особое внимание вещам, которые могут создать несбалансированную связь, которые препятствуют реальному общению. Как минимум, разница в часовых поясах, в которых работают члены команды, должна быть незначительна, чтобы люди бодрствовали в одно и то же время. А для выстраивания доверительных социальных взаимоотношений, которые делают возможным сотрудничество, члены команды должны регулярно видеться друг с другом, как минимум раз в несколько месяцев.
УПРАВЛЕНИЕ АУТСОРСИНГОВЫМИ И ОФШОРНЫМИ КОМАНДАМИ
Начиная с конца 1980-х годов мы наблюдаем рост использования аутсорсинговых и оффшорных ИТ-услуг. Аутсорсинговые компании выступают с, казалось бы, привлекательным предложением: используя их недорогие услуги в области ИТ и разработке программного обеспечения, компании получают возможность избежать необходимости самостоятельного управления этими нестратегическими бизнес-функциями, передав их высококлассным экспертам и сосредоточившись на своих основных компетенциях.
Как мы надеемся, мы уже совершенно ясно дали понять, что ИТ и разработка программного обеспечения теперь должны рассматриваться в качестве основной бизнес-функции, а также стать основной компетенцией для каждой фирмы любого размера. В проектах и программах, в которых неопределенность играет существенную роль, компании все больше уходят от ИТ-аутсорсинга. С недавних пор мы заметили нарастающую тенденцию развития ИТ-услуг внутри организации[71].
Аутсорсинг часто ассоциируется с офшорингом, практикой переноса рабочей деятельности в другие части мира для оптимизации в сфере найма, стоимости и графика. Многие организации размещают основные бизнес-подразделения, продажи и маркетинг в штаб-квартирах в крупных городах и создают инженерные центры за много тысяч миль от них.
Аутсорсинг и офшоринг создают схожие проблемы. Оба тактических приема порождают команды работников, которые отделены от покупателей и акционеров и не способны к автономному обучению. Это также приводит к трудностям в построении хорошего сотрудничества с коллегами по бизнесу и невозможности самостоятельно установить двусторонний разговор с рынком.
Конечно, существуют технологические проекты, для которых подходит аутсорсинг. Проекты с низким уровнем неопределенности (что строить и что будет работать) отлично подойдут для аутсорсинговых и офшорных команд. Один из методов такого типа работы – использование двухкомпонентного agile-подхода.
При таком подходе два компонента действуют скоординированно. Первый – это зона эксперимента. Команда использует все приемы подхода «почувствовать и отреагировать», описанные в этой книге, чтобы протестировать какие-то вещи, обладающие высокой степенью неопределенности, и выяснить, какое решение подходит лучше всего. Затем решение может быть передано ко второму структурному компоненту – компоненту производства, и уже «рабочая» команда реализует это решение более эффективным способом. Эта схема лучше всего подойдет для ситуаций, не требующих передачи документов, технических характеристик или контрактов, а подразумевающих передачу рабочего прототипа, который был одобрен в качестве заключительного варианта.
Преимущество двухкомпонентной agile-разработки состоит в том, что она позволяет одной команде оперативно выявлять потребности рынка, а другой – работать более размеренными темпами для обеспечения масштабирования. Однако сложно скоординировать такую работу хорошо. Существует риск возродить старые проблемы сборочного конвейера: оперативная информация может несвоевременно возвращаться к команде разработчиков, что снизит потенциал возможных изменений. Также происходит изоляция производственного компонента, что лишает его возможности получать предпросмотр перспективы.
Поэтому, если вы используете двухкомпонентный agile-подход, очень важно задать некоторые параметры. Этот подход должен обеспечивать быстрый отклик между производственными системами и экспериментом и позволять всей системе оперативно выполнять итерации в ответ на обратную связь. Если участники производственного компонента считают, что они берут ответственность за реализацию функций только единожды, система работать не будет. Наконец, необходим способ обеспечения прозрачности обоих участков работы, чтобы можно было наладить сотрудничество между ними.
РЕТРОСПЕКТИВНЫЕ ОЦЕНКИ
Одним из наиболее ценных методов улучшения командного процесса является ретроспективное совещание, на которое периодически (обычно каждые две-три недели) собираются члены команды, чтобы обсудить и улучшить рабочий процесс. Существует множество способов проводить такие совещания, но самое главное – это применять методы подхода «почувствовать и отреагировать» к самой команде. Что работает? Что не работает? Что мы можем изменить, чтобы улучшить положение дел?
Другими словами, члены команды рассматривают свой рабочий процесс, как и свои усилия по производству продукта, в качестве объекта для непрерывного улучшения. Мы часто советуем командам начинать с минимально жизнеспособного процесса и использовать ретрооценки и непрерывную обратную связь (как внутри, так и за пределами команды), а также экспериментировать
Ознакомительная версия. Доступно 11 страниц из 55
