Я думаю многие фрилансеры попадали в ситуацию, когда в качестве заказчика выступает некий представитель крупной компании, занимающий высокую должность. Обычно он не имеет отношения к программированию и, если повезет, может четко сформулировать что ему требуется. На общение с вами у него в лучшем случае есть 1 час в неделю, и то не каждую.
С такими заказчиками напрямую я стараюсь не работать, т.к. для того чтобы сделать продукт который им понравится часто нужно быть телепатом.
В этот раз я подумал, что мне повезло. Заказчик выделил ИТ специалиста, который должен был вникать в мою работу и разрешать спорные моменты. При этом сам заказчик хотел участвовать во всех важных решениях и просил ставить его в копию писем.
Готовый результат нужен был через 4 месяца. Примерно на середине этого срока нужно было принять важное решение по поводу работы одной из функций продукта. Я отписал подробное письмо с описанием всех проблем и возможных способов решения, ИТ специалист все это изучил и одобрил, заказчик промолчал. За несколько дней до окончания срока заказчик тестировал очередную демку и остался не доволен этой функциональностью, а на переделывание уже нужна не 1 неделя.
Я нашел старое письмо и отправил его заказчику, указав, что существующее решение было одобрено с их стороны (ИТ специалист). Но заказчик остался крайне не доволен, т.к. он обещал бета версию клиентам и откладывать ее нельзя.

Кто как решает подобные ситуации?
Я теперь решил составлять все важные письма для заказчика по принципу резюме. В начале идет очень краткое описание проблемы и ее последствия без указания технических деталей. При этом активно используются красные и жирные шрифты
Далее обязательное требование черкнуть в ответ пару строчек со стороны заказчика, например "Ок".
А в конце письма подробное описание с техническими деталями для ИТ специалистов.
Пока опробовать не успел, но надеюсь поможет

Здравствуйте, ILva_, Вы писали:

IL_>Я думаю многие фрилансеры попадали в ситуацию, когда в качестве заказчика выступает некий представитель крупной компании, занимающий высокую должность. Обычно он не имеет отношения к программированию и, если повезет, может четко сформулировать что ему требуется. На общение с вами у него в лучшем случае есть 1 час в неделю, и то не каждую.
IL_>С такими заказчиками напрямую я стараюсь не работать, т.к. для того чтобы сделать продукт который им понравится часто нужно быть телепатом.
IL_>В этот раз я подумал, что мне повезло. Заказчик выделил ИТ специалиста, который должен был вникать в мою работу и разрешать спорные моменты. При этом сам заказчик хотел участвовать во всех важных решениях и просил ставить его в копию писем.
IL_>Готовый результат нужен был через 4 месяца. Примерно на середине этого срока нужно было принять важное решение по поводу работы одной из функций продукта. Я отписал подробное письмо с описанием всех проблем и возможных способов решения, ИТ специалист все это изучил и одобрил, заказчик промолчал. За несколько дней до окончания срока заказчик тестировал очередную демку и остался не доволен этой функциональностью, а на переделывание уже нужна не 1 неделя.
IL_>Я нашел старое письмо и отправил его заказчику, указав, что существующее решение было одобрено с их стороны (ИТ специалист). Но заказчик остался крайне не доволен, т.к. он обещал бета версию клиентам и откладывать ее нельзя.

IL_>Кто как решает подобные ситуации?
IL_>Я теперь решил составлять все важные письма для заказчика по принципу резюме. В начале идет очень краткое описание проблемы и ее последствия без указания технических деталей. При этом активно используются красные и жирные шрифты
IL_>Далее обязательное требование черкнуть в ответ пару строчек со стороны заказчика, например "Ок".
IL_>А в конце письма подробное описание с техническими деталями для ИТ специалистов.
IL_>Пока опробовать не успел, но надеюсь поможет

Мало ли что он не доволен.
Теперь соснуть что ли у него, чтобы он остался доволен?

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

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

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

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

Здравствуйте, ILva_, Вы писали:

IL_>Я думаю многие фрилансеры попадали в ситуацию, когда в качестве заказчика выступает некий представитель крупной компании, занимающий высокую должность. Обычно он не имеет отношения к программированию и, если повезет, может четко сформулировать что ему требуется. На общение с вами у него в лучшем случае есть 1 час в неделю, и то не каждую.
IL_>С такими заказчиками напрямую я стараюсь не работать, т.к. для того чтобы сделать продукт который им понравится часто нужно быть телепатом.
IL_>В этот раз я подумал, что мне повезло. Заказчик выделил ИТ специалиста, который должен был вникать в мою работу и разрешать спорные моменты. При этом сам заказчик хотел участвовать во всех важных решениях и просил ставить его в копию писем.
IL_>Готовый результат нужен был через 4 месяца. Примерно на середине этого срока нужно было принять важное решение по поводу работы одной из функций продукта. Я отписал подробное письмо с описанием всех проблем и возможных способов решения, ИТ специалист все это изучил и одобрил, заказчик промолчал. За несколько дней до окончания срока заказчик тестировал очередную демку и остался не доволен этой функциональностью, а на переделывание уже нужна не 1 неделя.

IL_>Я нашел старое письмо и отправил его заказчику, указав, что существующее решение было одобрено с их стороны (ИТ специалист). Но заказчик остался крайне не доволен, т.к. он обещал бета версию клиентам и откладывать ее нельзя.

IL_>Кто как решает подобные ситуации?

С самого начала нужно определить, кому принадлежит решающее слово в проекте (в твоем случае заказчику, а не ИТ-специалисту).

Иначе возможны проблемы. Например, один мой знакомый фрилансер здесь, в Голландии, работал над проектом в оффисе заказчика. Когда программа была готова, заказчик отказался ее оплачивать, потому что человек, которые давал ему задание, якобы не имел права этого делать (фрилансер потом получил деньги через суд).

Техническое задание в письменной форме должно быть одобрено заказчиком (при помощи email, например). Только после этого можно начинать работу.

Хотя это тоже не всегда помогает. Например, четыре года назад я работал над одним проектом. Заказчик попросил написать программу на основе сдельной оплаты. Я согласился (как потом выяснилось, это была ошибка, нужно было договариваться о почасовой оплате). Я составил подробное функциональное описание программы, которое было с заказчиком согласовано и им одобрено. За день до сдачи проекта заказчик посмотрел на программу и потребовал добавить функциональность, которой не было в документации. Когда я сказал о том, что мы об этом не договаривались, мне ответили, что "ты как профессионал должен знать, что это само собой разумеется". Я отказался делать это бесплатно, и они заплатили мне только 75% от обещанного (сначала я хотел подать на них в суд, но мой адвокат сказал, что выигранная сумма только покроет судебные издержки и я не стал этого делать).

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

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

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

Правильно, ничего не делать до получения подтверждения.

IL_>А в конце письма подробное описание с техническими деталями для ИТ специалистов.
IL_>Пока опробовать не успел, но надеюсь поможет

Здравствуйте, ILva_, Вы писали:

IL_>Я думаю многие фрилансеры попадали в ситуацию, когда в качестве заказчика выступает некий представитель крупной компании, занимающий высокую должность. Обычно он не имеет отношения к программированию и, если повезет, может четко сформулировать что ему требуется. На общение с вами у него в лучшем случае есть 1 час в неделю, и то не каждую.
IL_>С такими заказчиками напрямую я стараюсь не работать, т.к. для того чтобы сделать продукт который им понравится часто нужно быть телепатом.
IL_>В этот раз я подумал, что мне повезло. Заказчик выделил ИТ специалиста, который должен был вникать в мою работу и разрешать спорные моменты. При этом сам заказчик хотел участвовать во всех важных решениях и просил ставить его в копию писем.
IL_>Готовый результат нужен был через 4 месяца. Примерно на середине этого срока нужно было принять важное решение по поводу работы одной из функций продукта. Я отписал подробное письмо с описанием всех проблем и возможных способов решения, ИТ специалист все это изучил и одобрил, заказчик промолчал. За несколько дней до окончания срока заказчик тестировал очередную демку и остался не доволен этой функциональностью, а на переделывание уже нужна не 1 неделя.

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

IL_>Я нашел старое письмо и отправил его заказчику, указав, что существующее решение было одобрено с их стороны (ИТ специалист). Но заказчик остался крайне не доволен, т.к. он обещал бета версию клиентам и откладывать ее нельзя.

Ну, тогда лишь можно предложить заказчику разделить оставшуюся и новую функциональность на 3 РАВНЫЕ группы — обязано быть(без этого система не имеет смысла), должно быть (без этого хоть как-то, но можно работать) и желательно, чтобы было. И реализовывать функции в соответствии с приоритетностью. Собственно, так нужно было с самого начала делать, ну да чего уж теперь-то...
И как-то с деньгами за допфункционал надо вопрос утрясать.

IL_>Кто как решает подобные ситуации?
IL_>Я теперь решил составлять все важные письма для заказчика по принципу резюме. В начале идет очень краткое описание проблемы и ее последствия без указания технических деталей. При этом активно используются красные и жирные шрифты
IL_>Далее обязательное требование черкнуть в ответ пару строчек со стороны заказчика, например "Ок".
IL_>А в конце письма подробное описание с техническими деталями для ИТ специалистов.
IL_>Пока опробовать не успел, но надеюсь поможет

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

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

Здравствуйте, Flying Dutchman, Вы писали:

FD>Я отказался делать это бесплатно, и они заплатили мне только 75% от обещанного (сначала я хотел подать на них в суд, но мой адвокат сказал, что выигранная сумма только покроет судебные издержки и я не стал этого делать).

Не сходится. Разве судебные издержки оплачивает не проигравшая сторона ? Стало быть ты без рисков должен был получить свои причитающиеся 25%. Или ты что-то недоговариваешь.

Здравствуйте, IID, Вы писали:

IID>Здравствуйте, Flying Dutchman, Вы писали:

FD>>Я отказался делать это бесплатно, и они заплатили мне только 75% от обещанного (сначала я хотел подать на них в суд, но мой адвокат сказал, что выигранная сумма только покроет судебные издержки и я не стал этого делать).

IID>Не сходится. Разве судебные издержки оплачивает не проигравшая сторона ? Стало быть ты без рисков должен был получить свои причитающиеся 25%. Или ты что-то недоговариваешь.

Имелись в виду расходы на адвоката (мой адвокат был из недорогих и брал 150 евро в час). Эти расходы должен оплачивать я сам. Сумма иска была около 2600 евро, и после судебного процесса от нее мало что-либо осталось бы.

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

Здравствуйте, nvb, Вы писали:

nvb>То ли вы смутно описали ситуацию, то ли я ее не понял, но... Правильно ли будет сделать из ваших слов вывод, что первые 2 месяца с заказчиком контактов почти не было, да и после было не особенно много? Тогда ничего странного здесь нет, нечему удивляться. Раздувание требований к продукту в процессе его создания происходит всегда, это один из основных рисков в разработке ПО, и лучше это раздувание размазать по всему сроку создания, а не откладывать на последний момент.

Почти так. Заказчик смотрел демку каждые 2 недели и писал свой фитбек типа это нравится, а это нет. Почти все претензии были к интерфейсу. Продукт разрабатывался от UI к модели данных, поэтому реальная база данных была подключена лишь на последнем месяце (м.б в этом была моя ошибка). Именно на реальных данных всплыла проблема, которая была предсказана и описана ранее. Причем заказчик заметил ее не сразу, а только спустя пару недель.

nvb>Вы пытаетесь заменить коммуникацию неким процессным подходом. Это кажется очень заманчивым и легким, но редко приводит к успеху. В лучшем случае можно прикрыть этим свою задницу при возникновении проблем. То, что вы написали — необходимо, но далеко не достаточно. Вам-то нужно, чтобы заказчик остался доволен, чтобы еще проектов подкидывал. Или я ошибаюсь?

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

nvb>Письма — это лишь письменная фиксация разговора, хотя они, да, обязательны. Контактировать с заказчиком надо чаще, вот и все.
nvb>А обязательное требование — красным шрифтом в конце письма — ответить, они проигнорируют. Все равно придется звонить и напоминать. Так что не заморачивайтесь с форматом. Просто позвоните ИТ-специалисту и убедитесь, что ваше письмо прочтено и понято. Можно позвонить 10 раз, пока не убедитесь.
nvb>Ну и что еще можно посоветовать. Потребуйте от заказчика сделать канал внесения изменений — единственным. Либо босс полностью доверяет своему техническому специалисту и вы принимаете изменения только от этого специалиста, либо пускай назначает другого. Письмо от специалиста со словом "да" означает полное и окончательное одобрение, и это ключевое положение должно быть явно подтверждено заказчиком в письменном виде. То, что у его босса появились новые идеи в процессе — проблема их специалиста, а не ваша. И если их специалист эти идеи прошляпил — лишится денег он, а не вы.

Быть сильно навязчивым тоже не хочется, тем более была уверенность что голос ИТ специалиста имеет значение. Видимо этот момент надо было обговаривать более детально.

Здравствуйте, Evgolas, Вы писали:

E>Мало ли что он не доволен.
E>Теперь соснуть что ли у него, чтобы он остался доволен?

Это я не умею, только программировать

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

E>Тогда да, правильно, обращайтесь с ним как с ребенком или идиотом.
E>Пишите письма большими буквами, краный цвет и подчеркивание.
E>Пишите простые фразы не больше 5 слов (как для дегенерата), чтобы он смог их осилить.

E>И требуете от него в обязательном порядке ответ.

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

Здравствуйте, ILva_, Вы писали:

nvb>>То ли вы смутно описали ситуацию, то ли я ее не понял, но... Правильно ли будет сделать из ваших слов вывод, что первые 2 месяца с заказчиком контактов почти не было, да и после было не особенно много? Тогда ничего странного здесь нет, нечему удивляться. Раздувание требований к продукту в процессе его создания происходит всегда, это один из основных рисков в разработке ПО, и лучше это раздувание размазать по всему сроку создания, а не откладывать на последний момент.

IL_>Почти так. Заказчик смотрел демку каждые 2 недели и писал свой фитбек типа это нравится, а это нет. Почти все претензии были к интерфейсу. Продукт разрабатывался от UI к модели данных, поэтому реальная база данных была подключена лишь на последнем месяце (м.б в этом была моя ошибка). Именно на реальных данных всплыла проблема, которая была предсказана и описана ранее. Причем заказчик заметил ее не сразу, а только спустя пару недель.

А, ну это тоже в некотором роде классика — отсутствие явного соглашения с заказчиком по спецификации потоков данных. Листер, ДеМарко "Deadline" — посмотрите, если будет время.

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

IL_>Быть сильно навязчивым тоже не хочется, тем более была уверенность что голос ИТ специалиста имеет значение. Видимо этот момент надо было обговаривать более детально.

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

Здравствуйте, Flying Dutchman, Вы писали:

FD>Здравствуйте, IID, Вы писали:

IID>>Здравствуйте, Flying Dutchman, Вы писали:

FD>>>Я отказался делать это бесплатно, и они заплатили мне только 75% от обещанного (сначала я хотел подать на них в суд, но мой адвокат сказал, что выигранная сумма только покроет судебные издержки и я не стал этого делать).

IID>>Не сходится. Разве судебные издержки оплачивает не проигравшая сторона ? Стало быть ты без рисков должен был получить свои причитающиеся 25%. Или ты что-то недоговариваешь.

FD>Имелись в виду расходы на адвоката (мой адвокат был из недорогих и брал 150 евро в час). Эти расходы должен оплачивать я сам. Сумма иска была около 2600 евро, и после судебного процесса от нее мало что-либо осталось бы.

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


Погодите. А что мешало повесить на проигравшую сторону все свои издержки + moral damages?

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

Что-то я впервые слышу про резюме с красными жирными цветами.
Этот стиль широко известен, как "бразильянский".

Относиться и платить Вам будут, как бразильянке.

Здравствуйте, ILva_, Вы писали:

IL_>Кто как решает подобные ситуации?

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

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

Здравствуйте, ILva_, Вы писали:

IL_>Я думаю многие фрилансеры попадали в ситуацию, когда в качестве заказчика выступает некий представитель крупной компании, занимающий высокую должность. Обычно он не имеет отношения к программированию и, если повезет, может четко сформулировать что ему требуется. На общение с вами у него в лучшем случае есть 1 час в неделю, и то не каждую.
IL_>С такими заказчиками напрямую я стараюсь не работать, т.к. для того чтобы сделать продукт который им понравится часто нужно быть телепатом.
IL_>В этот раз я подумал, что мне повезло. Заказчик выделил ИТ специалиста, который должен был вникать в мою работу и разрешать спорные моменты. При этом сам заказчик хотел участвовать во всех важных решениях и просил ставить его в копию писем.
IL_>Готовый результат нужен был через 4 месяца. Примерно на середине этого срока нужно было принять важное решение по поводу работы одной из функций продукта. Я отписал подробное письмо с описанием всех проблем и возможных способов решения, ИТ специалист все это изучил и одобрил, заказчик промолчал. За несколько дней до окончания срока заказчик тестировал очередную демку и остался не доволен этой функциональностью, а на переделывание уже нужна не 1 неделя.
IL_>Я нашел старое письмо и отправил его заказчику, указав, что существующее решение было одобрено с их стороны (ИТ специалист). Но заказчик остался крайне не доволен, т.к. он обещал бета версию клиентам и откладывать ее нельзя.

IL_>Кто как решает подобные ситуации?
IL_>Я теперь решил составлять все важные письма для заказчика по принципу резюме. В начале идет очень краткое описание проблемы и ее последствия без указания технических деталей. При этом активно используются красные и жирные шрифты
IL_>Далее обязательное требование черкнуть в ответ пару строчек со стороны заказчика, например "Ок".
IL_>А в конце письма подробное описание с техническими деталями для ИТ специалистов.
IL_>Пока опробовать не успел, но надеюсь поможет

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

Здравствуйте, senglory, Вы писали:

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


S>Погодите. А что мешало повесить на проигравшую сторону все свои издержки + moral damages?

Затраты на моего адвоката не оплачиваются проигравшей стороной.

Здравствуйте, Flying Dutchman, Вы писали:

FD>Здравствуйте, senglory, Вы писали:

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


S>>Погодите. А что мешало повесить на проигравшую сторону все свои издержки + moral damages?

FD>Затраты на моего адвоката не оплачиваются проигравшей стороной.

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

Здравствуйте, senglory, Вы писали:

FD>>Затраты на моего адвоката не оплачиваются проигравшей стороной.
S>Ну и что? Вчиняешь ему иск за моральный ущерб в 10 раз выше материаотного и вперед. В конце концов, должен же весь этот hassle оплачиваться.
Российские сказки про Запад для Западной Европы сказками и остаются.

Здравствуйте, sluge, Вы писали:

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

Это как — исключительно с советом директоров и CIO / CEO / CFO?