Как Общаться С Клиентами И Вести Переговоры По Проекту

Я занимаюсь мобильной разработкой как индивидуальный предприниматель уже полтора года.

За это время мне приходилось работать с разными людьми.

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

Я постарался собрать свой опыт и опыт своих коллег.

В результате получается что-то вроде руководства для фрилансеров.

Новички и многое другое.

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

• Создание юридических лиц и прием на работу работников (в соответствии с ТК РФ);
• Заказ работы у студии разработки;
• Заказ работ у фрилансеров (индивидуальных предпринимателей).

И это говорит о формировании затрат на разработку.

В разделе 2 рассматриваются нюансы общения с заказчиком и жизненный цикл проекта.

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

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

В заключении подводятся итоги проделанной работы.

Так же доступно видео репортаж с конференции @CocoaHeads. 1. Сколько стоит работа разработчика? Заказчика интересуют сроки и стоимость выполнения работ. Так уж получилось, что стоимость разработки измеряется часами.

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

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

Другими словами, вам необходимо определить стоимость застройщика.

1.1. Как оценить свою стоимость

Все мы знаем, что в нашей стране существует подоходный налог с населения (НДФЛ), равный 13%.

Однако не все знают или делают вид, что не знают, что помимо НДФЛ по ставке 13% работодатель делает ряд отчислений во внебюджетные фонды (пенсия - ПФР, медицинское страхование - ФФОМС, социальное страхование - ФСС).

).

Подробнее здесь .

• пенсионное страхование в ПФР 22% до 796 000 в год (менее 60 000 в месяц нетто) + 10% от суммы превышения; • медицинское страхование в Федеральном фонде обязательного медицинского страхования 5,1%; • социальное страхование в Фонде социального страхования 2,9% до 718 000 в год; • взносы на страхование от несчастных случаев и профессиональных заболеваний 0,2%-8,5%.

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

Есть огромное количество комментариев, «но», льготных мероприятий, просто выгод. Например, для «Сколково» отчисления в Пенсионный фонд РФ составляют 14%, а в ФФОМС и ФСС платить вообще не нужно.

Эти случаи не рассматриваются.

Еще важное замечание: считается 100% белая зарплата.

Итак, затраты на одного работника составляют: + + + + И работник получает на руки = - 13% НДФЛ Например, будучи наемным работником, разработчик зарабатывает 100 000 рублей в месяц или 1,2 миллиона в год. = 1,200,000 = 1,200,000 / 0.87 = 1,379,310 = 796,000*0.22+(1,200,000/0.87-796,000)*0.1 = 233,451 = 1,200,000 / 0.87 * 0.051 = 70,344 = 718,000 * 0.029 = 20,822 = 1,200,000 / 0.87* 0.002 = 2,758 Стоимость такого застройщика в год составляет 1 379 310 + 233 451 + 70 344 + 20 822 + 2758 = 1 706 687 Это не все.

Работник имеет множество прав согласно трудовому законодательству и доброте работодателя:

1. Отпуск.

   28 дней в году;

2. Награды;
3. Минимум двойная зарплата за работу в выходные и праздничные дни;
4. Оплата больничного листа.

   Обычно при потере заработной платы;

5. Добровольное медицинское страхование;
6. Компенсация обедов;
7. Компенсация командировочных;
8. Компенсация (частичная или полная) стоимости проживания.

   Актуально для арендаторов;

9. Компенсация за занятия спортом

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

Тогда за 28 дней отпуска работник получит чуть меньше 1 зарплаты.

Если немного округлить расчеты, то можно сказать, что работая год сотрудником за 1,2 млн, стоимость разработчика составляет 1,7 млн.

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

Они учитывают, что работник может болеть за счет работодателя.

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

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

Для расчета стоимости часа разработки вам необходимо узнать количество рабочих часов в году .

В 2016 году их 1974. Отнимите 28 дней отпуска – 28*8=224 часа.

Тогда стоимость часа работы сотрудника составит 1 706 687 / (1974 – 224) = 1 706 687/1750 = 975 Теперь рассмотрим упрощенную систему налогообложения для индивидуальных предпринимателей.

Налоговые взносы и взносы индивидуального предпринимателя:

1. Налог на прибыль 6% + 1% для доходов, превышающих 300 000 в год;
2. Взнос в Пенсионный фонд России 19 356,48 руб.

   /год;

3. Взнос в ФФОМС составляет 3 796,85 руб.

   /год.

При этом существует нижний порог входа от 0,5 до 3 миллионов (среднее значение 1,28 миллиона).

Правда, этот порог представлен для всего проекта (не всегда для одной iOS-платформы).

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

Иногда весь проект будет стоить меньше миллиона.

Или ему нужна только мобильная разработка.

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

Непонятно, что входит в эту цену.

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

Часто заказчику дарят часть работы, например, техническое задание.

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

Кроме того, стоимость услуг разных специалистов разная.

В целом нельзя сказать, что бэкенд, веб-интерфейс и мобильный интерфейс стоят одинаково в час.

Однако даже если в эту цену входит менеджмент и обсуждение, фрилансер совмещает эти направления.

Есть и более дешевые варианты.

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

Студии обычно выделяют менеджменту от 10% до 50% своего времени и денег.

Объединив эти 2 направления (а может и не только эти 2 направления), фрилансер может поднять себе ценник.

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

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

Но есть прозрачность.

Кроме того, находясь в одном городе с подрядчиком, заказчик имеет возможность встретиться с ним.

Это прекрасная возможность решить многие вопросы.

Студии из других городов и стран СНГ такой возможности не имеют. Не всегда удобно общаться в электронном виде; живое общение – это прекрасно, а иногда и незаменимо.

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

Пример: Клиент утверждает, что его приложение тормозит. Проверил на айфоне 5 - тормозов нет. На встрече выяснилось, что под «тормозами» заказчик имел в виду долгую загрузку структуры списка, а не зависания при прокрутке.

1.2. Что включить в стоимость

• разработка программного обеспечения;
• консультирование в этой области (беседы и дискуссии);
• написание технического задания;
• время, потраченное на оценку;
• время создания приложения в AppStore, поддержка в iTC;
• создание скриншотов;
• время на создание аккаунтов в различных системах;
• время добавлять устройства в TestFlight, HockeyApp и т. д.;
• другие расходы.

• github от 7$/мес;
• Фотошоп от 300 руб/мес;
• Иллюстратор 1500 руб/мес;
• Нарисуйте 99 долларов навсегда.

Не забывайте о своем рабочем месте.

Компьютер и устройства для тестирования также стоят денег.

Эти расходы не были учтены при расчете стоимости часа разработчика.

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

Есть и другие статьи расходов:

• Аренда офиса, также известная как аренда;
• Интернет-оплата;
• Другой.

Это может быть аренда, коммунальные услуги, телефонная связь и многое другое.

Данные расходы также включены в стоимость услуг.

Стоит ли включать такие расходы в стоимость вашей работы – решать вам.

Всем известно, что аренда офиса и стоимость Интернета для юридических лиц.

лица высокие.

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

При этом прибыль исполнителя выше.

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

1.3. Что не должно быть включено в стоимость?

• Программа Apple для разработчиков — 99 долларов в год, если у вас есть собственные опубликованные приложения;
• Эскиз, если он у вас уже есть;
• время, потраченное впустую с другими клиентами;
• пора искать клиента.

2.1. Не повторяйте чужих ошибок

Но многие заказчики не работают с фрилансерами.

Поняв, почему это происходит, вы сможете стать очень ценным исполнителем.

Заказчики из реальной жизни и Интернета, имеющие негативный опыт работы с фрилансерами, отмечают следующие черты: • Лень, недисциплинированность, неумение управлять своим временем, срыв сроков, прокрастинация; • Потеря связи: выключен телефон, отсутствие доступа к фрилансеру по электронной почте, Skype, Slack и т.п.

; • Неспособность завершить проект. Даже за счет оплаты; • Ложь, уклончивость; • Чрезмерные обещания.

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

Дело в том, что экономическая сторона вопроса не является самой важной.

Для заказчика гораздо важнее: • Эффективность; • Ответственность; • Честность; • Зрелость; • Гибкость; • Фокус.

Проще говоря, заказчику нужен профессионал.

И юридический статус исполнителя играет меньшую роль.

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

2.2. Какую лексику использовать

Как говорил А.

Н.

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

Клиент может быть не знаком с ИТ-терминологией и может неправильно вас понять или вообще не понять.

Пример: В общении с заказчиком он использовал термин MVP. Я подумал, что это Model-View-Presenter, и задался вопросом, почему он занялся дизайном.

Через 2 минуты я спросил, что такое MVP. «Минимально жизнеспособный продукт», — ответил заказчик.

То есть продукт с минимумом необходимых функций.

2.3. Знакомство с заказчиком и проектом

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

Особенно, когда ты уже согласился работать.

Это похоже на оправдание собственного бессилия.

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

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

В любом случае работа с чужим кодом предполагает обучение.

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

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

А может быть, заказчик просто отметит это как хорошую идею.

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

Быть в теме проекта – ваш большой плюс.

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

Однако вопросы целевой аудитории сервиса о том, какую проблему решает приложение, всегда уместны.

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

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

Ваша задача — коротко и ясно объяснить непонятные вещи.

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

Резерфорду).

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

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

По окончании первой встречи желательно оставить клиенту свои контактные данные.

Часто на собраниях присутствуют несколько человек.

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

Лучше всего общаться с самыми важными, с теми, кто принимает решения.

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

Если по каким-то причинам вы не хотите браться за проект, нужно уметь отказаться и сказать «нет».

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

Не нужно браться за невыполнимые проекты.

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

Два примера: Вы не работали с вебсокетами.

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

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

Или вас попросили разработать 2D или 3D игру.

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

2.4. Оценка времени и денег

Если вас просят приблизительно оценить, не стесняйтесь завышать оценку.

Когда неясность будет устранена, заказчику будет гораздо приятнее услышать о сокращении сроков и стоимости, чем об увеличении на 30, 50, 200 процентов.

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

Постарайтесь как можно яснее обозначить границы своей работы.

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

Чем больше клиент видит ваше понимание, тем выше его лояльность.

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

Распространенная проблема – когда заказчик и подрядчик не до конца понимают, чего хотят друг от друга.

Так называемый разрыв ожиданий.

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

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

А исполнитель думает об электронной почте и пароле.

Или о регистрации через соцсети.

сети.

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

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

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

А дополнительный функционал будет оплачиваться почасово.

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

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

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

Правильно зафиксировать работу в договоре, а дополнительные доработки оценить отдельно.

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

Бывает, что макетов нет. Пример: Сделал клиентом программы лояльности одного торгового центра с одним покупателем.

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

При этом не было ни технического задания, ни макета.

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

Поэтому дизайн обязателен.

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

А без макетов можно допустить большую ошибку в оценке.

Кроме того, этот дизайн также принесет пользу другим клиентам (Android, веб), а также разработке серверов.

В свою очередь, дизайн танцует от требований бизнеса и функциональных требований, т. е.

от технических характеристик.

Это подразумевает необходимость технических характеристик.

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

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

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

Но краткое техническое описание лучше, чем его полное отсутствие.

Достаточно описать, что требуется от мобильного клиента и все готово.

Написание технического задания может производиться как заказчиком, так и подрядчиком.

Для исполнителя эта работа оплачивается.

И об этом нужно сказать сразу.

Что вы готовы написать техническое задание, корректировать его под требования заказчика, а это будет стоить денег.

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

Размер этого резерва колеблется от 15 до 50 процентов и зависит от • ваше понимание проекта; • количество мест, с которыми вы раньше не сталкивались.

Необходимо выделить дополнительное время для рассмотрения существующих решений и исследований; • стиль оценки и некоторые субъективные факторы.

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

Пример:



Это фрагмент дизайна.

Вам необходимо выбрать дату и время.

Казалось бы, ничего сложного: • время до 16:00 уже прошло, поэтому он неактивен; • время, которое можно выбрать, выделено черным цветом; • выбранное время выделяется оранжевым фоном и белым шрифтом.

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

Дни также имеют выходные или неактивные даты.

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

Пример 2:



Это тоже фрагмент дизайна.

Есть сущность Task, нужно отобразить ее атрибуты.

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

Кроме того, о некоторых TaskAttributes я узнал очень поздно (dontShowIfNull, dataType).

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

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

Отдельный вопрос — взаимодействие с чужим API. Идентификатор типа String, передача параметров в виде составных данных, получение «строки json» вместо json и другие проблемы.

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

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

И здесь нужно поговорить о чем-то простом.

Очень часто разработчикам клиентских программ приходится ждать разработчиков серверной части.

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

Но когда это происходит в конце проекта, наступает время простоя.

Пример: Нам нужно реализовать push-уведомления.

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

И после этого может начаться процесс ожидания.

Время простоя не должно быть бесплатным.

Нам нужно поговорить об этом.

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

Когда все будет готово, подрядчик выполнит работы бесплатно.

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

Клиент готов, а сервер нет. Вы можете предложить выпустить приложение, не дожидаясь сервера.

И эта функциональность будет добавлена в обновлении.

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

За деньги, конечно.

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

Если заказчика не устраивает стоимость работ, можно и нужно вести торг.

Заказчик может сказать – дорого.

И попросить снизить цену.

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

Если загруженность подрядчика сейчас низкая или заказчик очень хороший, то подрядчику придется пойти на риск, отрезать «подушку» и согласиться на меньшую цену.

Если нагрузка большая или вы любите риск, можно сказать: «Нет, цена такая и только такая, ниже некуда».

Или можно торговаться.

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

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

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

Или не вернётся, видимо из-за нехватки денег.

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

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

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

2.5. Документация

В договоре описываются взаимоотношения между заказчиком и подрядчиком.

В частности, там говорится: • Предмет договора; • Крайний срок; • Порядок выполнения, сдачи и приемки работ; • Сумма и порядок оплаты; • Период бесплатной поддержки; • Ответственность сторон; • Процедура досрочного расторжения; • Конфиденциальность; • Сведения о сторонах.

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

Никто не любит формальности и бюрократию.

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

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

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

Техническая спецификация состоит как минимум из следующих пунктов: • Объем работ; • Требования к программному и аппаратному обеспечению; • Функциональные требования; Дизайн позволяет нам предотвратить разрыв в ожиданиях относительно интерфейса.

2.6. Предварительная оплата

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

50%.

Эту информацию нельзя скрыть до встречи или в последний момент: вы рискуете зря потратить время.

Откуда взялось это значение в 50%? Половина проекта — это минимальная часть работы, которую вы выполните несмотря ни на что.

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

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

Часто бывает, что исходный код находится на стороне заказчика, а сборки — в iTunesConnect заказчика.

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

Бывает, что заказчик только под конец проекта начинает проверять работу и потихоньку предъявлять претензии.

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

Существует схема, при которой роль администратора в iTC принадлежит только исполнителю.

Тогда вы предоставляете пароль от своего аккаунта только после последнего платежа.

Но если у клиента уже есть заявки на этот аккаунт, то такая схема не подходит. 50% — это справедливая сумма для обеих сторон.

Увеличение или уменьшение предоплаты является перестраховкой.

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

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

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

Это значит, что подрядчик зарекомендовал себя хорошо, а заказчик зарекомендовал себя плохо.

И если он захочет работать с этим исполнителем, то может потребовать 100% предоплату.

Иногда клиент может сказать, что боится отдать 50% незнакомому человеку.

Но ответственность ИП всем своим имуществом, а не уставным капиталом в 10 000 рублей, как в случае с ООО, разбивает этот аргумент. Работая в «белке», по договору с ИП, заказчик рискует не больше, чем при работе со студией разработки.

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

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

Далее каждый этап начинается с предоплаты и заканчивается основным платежом.

2.7. Работа

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

Это обязательное требование.

Заказчик обычно хочет видеть, что процесс идет, и хочет понять, когда произойдет завершение.

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

Клиент должен быть уведомлен о любой чрезвычайной ситуации:

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

  Если вы столкнулись с проблемой и застряли

• Jetking Fraud - Это Студенты, Которые Не Обратили Внимания

  19 Oct, 24

• Уровень Удовлетворенности Работой Миллениалов Достиг 10-Летнего Максимума

  19 Oct, 24

• Может Ли Природа Быть Неестественной?

  19 Oct, 24

• Microsoft Не Для Интернет-Пользователей И Не О Выгодах Партнёров (Полусонные Впечатления С Riw)

  19 Oct, 24

• Генератор Персонажей Dragon Age

  19 Oct, 24

• Прямая Трансляция Конференции По Безопасной Разработке Программного Обеспечения

  19 Oct, 24

• Время Жизни Статических Ip-Адресов В Windows Azure

  19 Oct, 24

• Парковка Для Людей!

  19 Oct, 24

• Пробуем Работать С Подписками Wap-Click

  19 Oct, 24

• Убойная Комбинация Nscache И Uinib

  19 Oct, 24