Шаблон договора на разработку сайта - в помощь фрилансеру

В помощь фрилансерам выкладываю шаблон договора для заключение контрактов на разработку сайтов.
Скачать шаблон договора можно по следующей ссылке: http://www.msmirnov.ru/public/ContractForSite.doc

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

Текст шаблона привожу ниже.

Договор № _______
на проведение работ по разработке интернет-сайта «___________».

г. ______________________                                                                            «__» __________ 20__ г.

___________________________________________________________, зарегистрирован(а) по адресу _________________________________________________________________, с одной стороны, и

_______________________________________________________________________________________________________________________________________________________, с другой стороны,

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

 1.                     ПРЕДМЕТ ДОГОВОРА

1.1.       Исполнитель по поручению Заказчика выполняет работы по разработке и внедрению интернет-сайта «______________» в объеме, определяемом Приложением №1 к настоящему Договору «Техническое задание», в сроки, предусмотренные Приложением №2 к настоящему Соглашению, «Календарный план».

2.                     ОБЯЗАННОСТИ ИСПОЛНИТЕЛЯ

Исполнитель обязуется:

2.1.       оказать услуги в соответствии с разделом 1 настоящего Договора;

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

3.                     ОБЯЗАННОСТИ ЗАКАЗЧИКА

Заказчик обязуется:

3.1.       оплатить оказанные услуги в размерах и в сроки, установленные настоящим Договором;

3.2.       выпустить приказ о формировании группы сопровождения проекта, ответственной за своевременное и правильное выполнение обязательств по настоящему Договору со стороны Заказчика. В данной группе определяется ответственный исполнитель. Список членов группы, копии приказа о назначении ответственного исполнителя передать Заказчику в течение 5 дней с даты подписания настоящего Договора.

3.3.       обеспечить согласование документов в сроки, определенные Календарным планом (Приложение №2 к настоящему Соглашению).

3.4.       при наличии согласованной Сторонами необходимости, обеспечить сотрудникам Исполнителя возможность оказания услуг в помещениях Заказчика не менее 10 (десяти) рабочих часов в сутки по рабочим дням и в выходные дни;

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

3.6.       Предоставлять по запросу сотрудников Исполнителя, выполняющих работы, необходимые данные, документы и материалы в согласованные сроки и в согласованном объеме.

4.                     СТОИМОСТЬ РАБОТ И ПОРЯДОК РАСЧЕТОВ

4.1.       Общая стоимость работ Исполнителя по настоящему Договору составляет ____________________ рублей.

4.2.       Заказчик выплачивает аванс в размере ________________ рублей в сроки определенные в Приложении № 2 к настоящему Договору, «График работ».

4.3.       Сумму, эквивалентную __________________ рублей, Заказчик оплачивает в сроки определенные в Приложении № 2 к настоящему Договору, «График работ».

4.4.       Дополнительные работы по проекту осуществляются из расчета ________ руб / чел.час. При этом исполнитель предоставляет перечень дополнительно выполненных работ с указанием даты их проведения и стоимости. Оплата дополнительных работ производится в течении _____ рабочих дней со дня предоставления перечня.

5.                     СРОКИ ОКАЗАНИЯ УСЛУГ

5.1.       Сроки работ определяются Приложением № 1 к настоящему Договору, «Календарный план».

5.2.       В случае задержки предоставления Заказчиком исходных данных (п. 3.6) срок действия Договора и сроки выполнения обязательств Исполнителем переносится на время задержки.

5.3.       Сроки оказания услуг могут быть изменены в процессе их оказания только по соглашению Сторон.

5.4.       При появлении новых деталей и обстоятельств, не указанных в Техническом задании, стоимость и время разработки проекта будет увеличено в соответствии с пунктом 4.4 настоящего Договора.

 6.                     ПОРЯДОК СДАЧИ-ПРИЕМКИ

6.1.       Исполнитель обязан своевременно оказать услуги.

6.2.       Оказанные по настоящему Договору услуги Заказчик принимает путем подписания Акта сдачи-приемки услуг, оформляемого в 2 (двух) экземплярах.

7.                     ОТВЕТСТВЕННОСТЬ СТОРОН

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

8.                     Гарантийные обязательства

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

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

8.3.       Под ошибкой понимается несоответствие документации функционалу программного обеспечения (ошибка в документации) либо систематическое невыполнение или некорректное выполнение функций программы (ошибка в коде), которое отвечает одному из критериев:

8.3.1. не соответствует документации на программное обеспечение;

8.3.2. явно присутствует (проявляется) в обслуживаемом программном обеспечении;

8.3.3. не является явным следствием одного или нескольких обстоятельств:

8.3.3.1.    ошибочного пользования программное обеспечение;

8.3.3.2.    несанкционированного изменения или дополнения ПО;

8.3.3.3.    сбоя смежного программного либо аппаратного обеспечения;

8.3.3.4.    недостаточности аппаратных или телекоммуникационных ресурсов;

8.3.3.5.    неисправности или изменения оборудования, на котором ПО установлено;

8.3.4. не является следствием изменения регламентов деловых процессов Заказчика.

8.4.       Гарантийный срок составляет ________ месяцев с даты подписания Сторонами Акта сдачи-приемки выполненных работ.

9.                     ИМУЩЕСТВЕННЫЕ ПРАВА

9.1.       Заказчику принадлежат исключительные имущественные права на разработанное по настоящему Договору программное обеспечение интернет-сайта «_______________________».

9.2.       Исключительные права Сторон и иных Правообладателей на программные средства, программное обеспечение и иные объекты интеллектуальной собственности, использованные при выполнении работ по настоящему Договору, сохраняются за соответствующими Сторонами и соответствующими Правообладателями.

10.                   ПРОЧИЕ УСЛОВИЯ

10.1.   Настоящий Договор вступает в силу с момента его подписания Сторонами и действует до выполнения ими принятых на себя обязательств.

10.2.   Договор в письменной форме. Письменная форма считается выполненной при наличии подписей уполномоченных лиц и оттисков печатей Сторон.

10.3.   Настоящий Договор составлен в двух экземплярах, имеющих одинаковую юридическую силу и по одному для каждой Стороны.

10.4.   Настоящий Договор может быть изменен либо дополнен на основании письменного соглашения Сторон.

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

11.                   ПРИЛОЖЕНИЯ

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

11.1.1.  Приложение № 1 - «Техническое задание»

11.1.2.  Приложение № 2 - «Календарный план»

12.                   ЮРИДИЧЕСКИЕ АДРЕСА И БАНКОВСКИЕ РЕКВИЗИТЫ СТОРОН

Заказчик:		Исполнитель:
«____» ___________ 20___ г.		«____»____________ 20___ г.

Приложение № 1

«ТЕХНИЧЕСКОЕ ЗАДАНИЕ»

Техническое задание включает в себя следующие пункты:

Приложение № 2

«КАЛЕНДАРНЫЙ ПЛАН »

№ этапа	Наименование этапа	Сроки выполнения работ	Стоимость Работ, руб.
Итого за работы:

* Примечание: Формы представления результатов работ, требования к их составу, содержанию и оформлению устанавливаются Руководителями проекта (п. 4.1 Договора) в рабочем порядке.

ОТ ЗАКАЗЧИКА  «____» ___________ 2011 г.		ОТ ИСПОЛНИТЕЛЯ «____»____________ 2011 г.

Работа со старыми DTS-пакетами MS SQL Server 2000 в MS SQL Server 2008

Недавно мне пришлось столкнуться с необходимостью работы с набором DTS-пакетов, созданных много лет назад в MS SQL Server 2000 и импортированных в SQL Server 2008.

Отказаться от их использования было нельзя - приложение было написано очень давно и задачи перехода на SSIS не стояло.

SQL Server 2008 обеспечивает корректную работу старых DTS-пакетов, но вот Management Studio 2008 не открывает DTS-пакеты для просмотра и редактирования, выдавая следуюшую ошибку:

"SQL Server 2000 DTS Designer components are required to edit DTS packages. Install the special Web download, “SQL Server 2000 DTS Designer Components” to use this feature. "


Microsoft предлагает скачать и установить SQL Server 2000 DTS Designer Components - см. здесь - (для этого надо будет скопировать 6 файлов (SEMSFC.DLL, SQLGUI.DLL, SQLSVC.DLL, SEMSFC.RLL, SQLGUI.RLL, и SQLSVC.RLL) из установки SQL Server 2000 в каталог с SQL Server 2008).

Однако, это  не решит проблему для случая SQL Server 2008 - после копирования файлов Server 2000 DTS Designer будет запускаться из Management Studio 2008, но корректно работать все равно не будет. Этот способ работает только для случая SQL Server 2005.

В SQL Server 2008 будет выдаваться следующая ошибка:

"Error Source : Microsoft Data Transformation Services (DTS) Package
Error Description : The DTS host failed to load or save the package properly."


В Microsoft пока не создали решения этой проблемы для SQL Server 2008, но есть один обходной вариант - пусть не очень удобный, но в случае необходимости он работает.

Следует поставить старый добрый SQL Server 2000 - причем не только сам Enterprise manager, а и ядро сервера - без инстанса работать с DTS-пакетами не получиться.
Причем, ставить нужно SQL Server 2000 SP3 или SP4. С SP2 работать не будет.

После этого необходимо сохранить DTS-пакеты из Management Studio 2008 на диск и открыть файлы на редактирование в Enterprise manager. Сам инстанс SQL 2000 при этом не понадобиться - Enterprise manager будет просто работать с файлами. Затем файлы необходимо опять импортировать в SQL Server 2008.

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

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

Какие вопросы задавать заказчику на первой встрече?

Я руковожу в основном продуктовой разработкой.

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

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

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

 Итак, вопросы.

1. Общие вопросы. 
• Как называется проект?
• Каковы цели реализации проекта?
• Каковы предпосылки (в том числе экономические), приводящие к инициации проекта?
• Как вы сможете понять, что проект успешен?
• Кто, кому и как будет сдавать проект?
• Каковы должны быть результаты проекта, по которым можно будет судить о степени его завершенности?
• Какие ограничения проекта существуют (по времени, по бюджету, по техническому обеспечению, оборудованию, доступу к информации и пр.)?
• Существуют ли какие-либо стандарты либо законодательные акты, которые необходимо соблюдать при работе над проектом?
• В каком виде предполагается последующая поддержка проекта?
  
2. Команда проекта. 
• Кто будет осуществлять руководство проектом со стороны заказчика?
• Обладает ли он достаточными полномочиями для этого?
• Кто ответственен за принятие ключевых решений со стороны заказчика?
• Кто обладает достаточными знаниями для формирования требований к проекту?
• Кто еще будет входить в состав проектной группы со стороны заказчика?
  
3. Влияние проекта.
• Кто будет затронут результатами внедрения проекта?
• Какие могут быть сложности или особые условия в процессе внедрения?
• Предполагается ли какая-либо миграция или одновременная работы с некими старыми системами?
• Предполагается ли обучение персонала как часть проекта?
• Кто будет пользователями проекта?
• При работе над проектом, либо при его внедрении - будут ли задействованы какие-либо сторонние организации либо ваши подразделения, не являющиеся непосредственными пользователями (например, поставщики либо получатели каких-либо данных)?
  
4. Риски
• Какова квалификация пользователей проекта?
• Будет ли обеспечен доступ в рабочую среду для проведения тестирования и раннего внедрения результатов проекта?
• Существуют ли сотрудники, на стороне заказчика, не заинтересованные в реализации проекта?

Visual Paradigm for UML

На днях мне довелось поработать с Visual Paradigm for UML 8.0.

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

Но, как мне показалось, что инструмент слегка перегружен. Тот же Enterprise Architect от Sparx мне показался более стройным и логичным что-ли.

К сожалению, не удалось толком сделать reverse engeneering базы MS SQL - нужного драйвера для Java в поставке не оказалось, а качать и устанавливать не хотелось.

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

Для меня эталоном удобства по работе с UML остается Rational XDE - очень удобный продукт времен Visual Studio 2003, который, к сожалению, не выпускается уже наверное лет 8. Очень жаль что IBM прекратила его поддержку - очень мощный и удобный был инструмент.

Китайский код

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


            string s = Request.QueryString["action"];
            // s may have "restore" or "remove" values

            switch (s[2])
            {
                case 's':
                case 'S':
                    ..............
                    break;

                case 'm':
                case 'M':
                    ..............
                    break;

            }

Как говорится, это было бы смешно, если бы не было так грустно……

Летний Аналитический Фестиваль-2011 (ЛАФ-2011)

Вчера я посетил наверное уже ставший традиционным Летний Аналитический Фестиваль-2011 (ЛАФ-2011), который как и в прошлом году проходил в Иваново и был посвящен системному анализу.

О ЛАФ-2010 я писал здесь и здесь.


Было приятно увидеть множество знакомых лиц с прошлого фестиваля.

Как и в прошлый раз фестиваль прошел в теплой непринужденной, я бы даже сказал дружеской, и вместе с тем, профессиональной обстановке.

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


Лично для себя я отметил следующие доклады:


1. Ирина Левенец "Управление ожиданиями в продуктовой разработке". На мой взгляд интереснейший доклад.

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

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

Поэтому, с течением времени уровень сервиса, который предоставляются заказчику, растет, но не смотря на это, недовольство заказчика тоже растет.

Соответственно, ценность сервиса для заказчика снижается.

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

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

- Поскольку ресурсы по разработке обычно ограничены, а множество клиентов генерирует поток запросов на изменение, необходимо выполнять сортировку новых требований.
Здесь Ирина привела интересный термин "Triage".

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

- Меньше обещать, больше делать. Т.е. если мы пообещаем заказчику сделать что-то например за неделю, и сделаем за неделю - это хорошо. А вот если мы пообещаем сделать за две недели, а сделаем за неделю - это будет просто отлично, заказчик будет счастлив.

- Если что-то не может быть сделано - так и сообщать заказчику. Не говорить, что может быть мы когда-то потом это сделаем.

- Вовлекать заказчиков в процесс сортировки требований. Это способствует повышению адекватности заказчиков.


2. Сергей Мартыненко "Варианты управления требованиями". Как и в прошлом году, у Сергей был очень интересный доклад.

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

- Плохие способы отбора требований в релиз:
    - Крик. Кто из заказчиков кричит громче, требования того реализуются быстрее.
    - Занудство. Кто из заказчиков настойчивее продвигает требования, требования того реализуются быстрее.
    - Зарплата. Кто из заказчиков получает большую зарплату, требования того реализуются быстрее (актуально в случае внутреннего заказчика).
    - Приоритет.

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

- Хороший способ распределения требований по релизам:

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


3. Денис Казика. "Внедрение ITIL/ITSM" Тоже довольно интересный доклад.

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

Для решения проблем были предприняты следующие шаги:

- Была внедрена система управления инцидентами (нечто типа внутренней системы баг-трекинга.) Все запросы в IT-подразделение могли теперь поступать только через нее (до внедрения этой системы ситуация была примерно такая, как говорил Сергей Мартыненко - кто громче кричит или у кого больше зарплата, того требования и реализуются быстрее). Для того, чтобы отучить сотрудников от старых привычек работы с IT-отделом, двери отдела даже пришлось запирать на две недели, чтобы никто из других отделов не мог попасть внутрь не соблюдая регламент.

- Были внедрены внутренние регламенты работы IT-подразделения.

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

- Была введена должность бизнес-аналитика.

Весь процесс занял примерно 2.5 года.


После всех преобразований:
- IT-подразделение стало бизнес-образующим.

- Исчезли конфликты между IT-подразделением и другими подразделенями.

- Бизнес компании стал более эффективным.


4. Алексей Киселев "Могут ли быть выгодны ошибки аналитика или история одного тендера".

Алексей рассказал о сложностях работы с государственными заказчиками и участия в государственных тендерах.

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

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

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

- Гос.заказчики не признают итеративную разработку. Только водопад.


Пожалуй, это были самые интересные для меня доклады.


К сожалению мне не удалось попасть на мастер класс Дмитрия Безуглова, но я надеюсь увидеть его как-нибудь позже.

Кроме того, не удалось побывать на интересном мастер-классе Ирины Векленко "Анализируй это: Жизнь как Проект", но я также надеюсь пообщаться с ней позже.

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


Я надеюсь, что в следующем году состоится ЛАФ-2012 и буду очень рад присутствовать на нем.

Хотелось бы поблагодарить всех организаторов и участников фестиваля за то, что они делают!


All you need is... ЛАФ!

Сложности распределенных команд и проектов

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

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

Еще хочу обратить внимание, что данные проблемы не являются не решаемыми.

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


1. Часовые пояса.
Большая разница во времени (например, 12 часов) существенно замедляет процесс разработки.

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

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

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

Можно, конечно, не задерживаться, а просто написать письмо, но это еще хуже.

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


2. Языковой барьер.
Де-факто инструментом общения сейчас является английский язык.

Писать и читать на нем все более или менее уже научились.

Намного сложнее слушать и быстро отвечать.

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

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

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



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



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


5. Демотивация.
Предыдущий пункт приводит к демотивации членов команд, так как они не чувствуют глубокой причастности к работе над проектом. Проект на становиться для них, что называется “своим”.

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


Зачастую бывает проще не задавать вопросов, нежели пытаться чего-то добиться. 


6. Сложности в соблюдении единого стиля разработки.
Это касается как стандартов кодирования, так и технических и архитектурных решений.


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



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


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