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

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

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

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

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

1. Выбирайте партнера.

   Это очень важно. Правильно выбирайте партнера. Ни красивые визитки, ни громкое название, ни наполеоновские планы ни о чем не говорят. Партнер должен быть на самом деле надежным. Даже если руководство фирмы партнера великолепно разбирается в технических деталях, для него необходимы знания и опыт в области руководства проектами, руководства коллективами и руководства фирмой. Иначе партнера нельзя считать умеющим создать и руководить стабильной фирмой с хорошим постоянным персоналом. Это даже важнее, чем финансовое положение партнера. Менеджмент - сложное и рискованное занятие, не стоит доверяться дилетантам, тем более не стоит доверяться дуракам. Даже если у Вас нет выбора, выбирайте партнера. Лучше отказаться от ненадежного проекта, чем потерять свои деньги.

   Если решено отказаться от работы с данным партнером возможны 2 варианта: 1. Отказаться от данного проекта и/или пересмотреть стратегию фирмы. 2. Найти подходящего партнера. Для этого надо сменить стратегию поиска и/или пересмотреть требования к самому партнеру. Рынок разделенных разработок широк. Основной сложностью является то, что потенциальные партнеры не могут найти друг друга. Это связано как с особенностями рынков в разных странах, как и с тем, что стратегии поиска не пересекаются из-за различий в секторах рынка в которых работают потенциальные партнеры.

2. У партнера должна быть соответствующая мотивация в успешном завершении проекта.

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

3. Работники фирмы партнера должны иметь соответствующую мотивацию в успешном завершении проекта.

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

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

4. Заменимость людей - миф.

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

5. Не надейтесь на то, что Вам удастся руководить процессами в фирме партнера.

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

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

   Практически всегда оплата по конечному результату лучше, чем почасовая. Участие в успехе всего проекта лучше, чем премия за выполнение какой-то его части. Доверие лучше, чем попытки командовать. Если вы выбрали людей, c которыми будете работать и считаете, что они чего-то стоят, то дайте им возможность взять на себя столько ответственности, сколько они смогут. Если у них это не получится, то любые попытки командовать из другой страны не помогут. Поэтому выбирайте людей и помогайте им учиться.

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

6. Вы должны хорошо ориентироваться в ситуации в той стране, с которой работаете.

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

7. Распределяйте риски.

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

В этом разделе собраны мысли по поводу самого процесса организации удаленной разработки.

1. Не стоит вообще расчитывать на работу on-line.

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

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

2. Возможность непосредственного общения очень важна.

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

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

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

   Общения по e-mail в принципе не достаточно для текущей работы. Необходимо как минимум общение по телефону.

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

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

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

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

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

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

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

   4. Очень помогает применение CASE ( НО только при наличии опыта использования у обеих сторон). Например обмен структурами классов гораздо продуктивнее, чем обмен заголовочными файлами. Часто имеет смысл посылка факсов, но это заведомо хуже соответствующих файлов CASE.
      

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

      Следует помнить, что CASE не являются серебряными пулями. Они не оправдают радужных надежд. Несоответствие между реальным процессом разработки и тем, который поддерживает CASE имеет самые разрушительные последствия. Те кто реально подходят к проблеме - выигрывают. Но не сказочно. В любом случае лучше не применять CASE, чем применять его не правильно.

   5. Необходим Software Configuration Management. Если обе стороны могут использовать и исправлять одни и те же файлы, необходимо еще и четко продуманная структура внесения изменений, чтобы слияние двух версий одного и того же файла было возможно. В случае невозможности одновременной обработки одного и того же файла могут возникнуть задержки с минимальной длительностью около суток.
      Ошибки в SCM могут стоить при удаленной разработке очень дорого.

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

4. Разработке процесса и документирования надо уделить особое внимание.

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

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

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

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

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

5. Необходимо выделить время и средства на обучение персонала и вхождения его в процесс.

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

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

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

6. По крайней мере один человек должен отвечать за сам процесс взаимодействия.

   Полезно периодически проверять качество процесса и проводить совещания. Особую ценность представляет информация об ошибках и критических ситуациях. Лучше поощрить за сообщение справедливой информации, чем наказать за саму ошибку. Это позволит эффективно работать в будущем.

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

7. Порядок обработки запросов.

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

   Арбитр не обязательно должен быть лидером группы. Главное, чтобы он был компетентен в данном вопросе и все знали, что с подобными запросами надо обращаться к нему. Например сисадмин может общаться с сисадмином. Все особенности графического интерфейса идут через дизайнера. Согласование моделей - через аналитиков. Главное чтобы информация была независимой и потоки не интерферировали.

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

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

   Кстати, время локализации ошибки обычно не меньше, чем сумма времени ее поиска (поиска наличия) и устранения.

8. Всегда есть конфиденциальная информация, которую не стоит сообщать немедленно.

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

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

9. При улучшении процесса важна определенность изменений.

   Изменения не должны быть минимальны. Лучше всего придерживаться правила - одно изменение за шаг. При этом шаг может полностью перевести на другой язык программирования.

   Изменения должны быть прежде всего контролируемы. Главное быть в состоянии локализовать последствия неверного шага и определить причину удачи/неудачи, а на основе анализа причин направление дальнейшего движения.

10. Проверку на практике лучше провести заранее.

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

11. Прямой обмен информацией между участниками проекта помогает объединить людей.

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

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

12. Интервал обоюдного присутствия.

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