Как общаться с заказчиками и договариваться о проектной работе

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

Введение

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

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

В п. 1. сравниваются затраты для каждого из трёх подходов. И говорится о формировании стоимости разработки.
В п. 2. рассматриваются нюансы общения с заказчиком и жизненный цикл проекта.
В п. 3. говорится, на что следует обращать внимание, общаясь с заказчиком и принимая решение о работе или об отказе от работы.
В п. 4. говорится о спорных ситуациях, путях их предотвращения и о том, что делать, когда они возникают.
В заключении подводится итог проведённой работы.
Доступно также видео доклада c конфенции @CocoaHeads.

1. Сколько стоит труд разработчика

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

1.1. Как прикинуть свою стоимость

Рассмотрим налогообложение наёмных сотрудников.
Все мы знаем, что у нас в стране существует налог на доходы физических лиц (НДФЛ), равный 13%. Однако не все знают, или делают вид, что не знают, что работодатель помимо 13% НДФЛ отчисляет ещё ряд взносов во внебюджетные фонды (пенсионный — ПФР, медицинского страхования — ФФОМС, социального страхования — ФСС). Подробнее тут.
• пенсионное страхование в ПФР 22% до 796 000 в год (менее 60 000 в месяц net) + 10% от суммы превышения;
• медицинское страхование в ФФОМС 5,1%;
• социальное страхование в ФСС 2,9% до 718 000 в год;
• взносы на страхование от несчастных случаев и профзаболеваний 0,2%-8,5%.
Нужно отметить, что дальнейшие подсчёты несколько упрощены. Существует огромное множество замечаний, «но», льготных видов деятельности, просто льгот. Например, для Сколково взносы в ПФР 14%, а в ФФОМС и ФСС вообще платить не нужно. Эти случаи не рассматриваются. Важно и другое замечание: рассматривается 100% белая зарплата.
Итак, стоимость наёмного сотрудника составляет:
<Зарплата gross> + <Отчисления ПФР> + <Отчисления ФФОМС> + <Отчисления ФСС> + <Страхование от несчастных случаев>
А на руки сотрудник получает
<Зарплата net> = <Зарплата gross> — 13% НДФЛ
Например, как наёмный работник, разработчик зарабатывает 100 000 рублей в месяц или 1,2 млн в год.
<Зарплата net> = 1 200 000
<Зарплата gross> = 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 рублей/год.

Мы определили, что себестоимость разработчика составляет чуть более 1,7 млн/год. ИП, заработав 1,7 млн, на руки получает
1,7 млн – 6% – (ПФР+ФОМС) – (1% от 1,7-0,3 млн) = 1,56 млн
В пересчёте на часы получится 895.
Расчёты для разных белых зарплат:

Теперь рассмотрим стоимость работ у студий разработки (отсюда):

Таким образом, разработка в успешных студиях стоит 1500-3200 рублей в час, а среднее значение составляет 2290 рублей. При этом существует нижний порог входа от 0,5 до 3 миллионов (среднее значение 1,28 млн). Правда, этот порог представлен для всего проекта (не всегда на одну платформу iOS). Тем не менее не всегда заказчику нужно много работы на большую сумму. Бывает весь проект будет стоить меньше миллиона. Или ему нужна только мобильная разработка. Случаи когда мобильная разработка дешевле миллиона вообще не редки.
Не ясно, что включено в эту стоимость. Ведь помимо разработки есть разработка ТЗ, управление, обсуждение, дизайн и издержки. Нередко заказчику предоставляют часть работ «в подарок», например, ТЗ. Понятно, что в таких случаях стоимость создания ТЗ размазывается по остальным работам. Кроме того, стоимость разных специалистов разная. В общем случае, нельзя сказать, что бэкенд, веб-фронтенд и мобильные фронтенды за час стоят одинаково. Тем не менее, даже если в эту стоимость закладывается управление и обсуждение, фрилансер сочетает в себе эти направления.
Есть и более дешёвые варианты. Стоимость часа работ в таких компаниях дешевле, но за дешевизной может скрываться невысокая квалификация или, что хуже, низкая квалификация, подаваемая и продаваемая под видом высокой.
В студиях обычно выделяется от 10% до 50% времени и денег на управление. Сочетая в себе эти 2 направления (а может, не только эти 2 направления), фрилансер может поднять свой ценник.
Здесь хотелось бы отметить ещё одно из преимуществ индивидуальных разработчиков перед студиями. Отсутствие сложной иерархии “разработчики – руководители – высшие директора”, нет испорченного телефона, нет звеньев, требующих дополнительной оплаты, нет бюрократии. Но есть прозрачность.
Кроме того, находясь с исполнителем в одном городе, заказчик имеет возможность встречаться с ним. Это – прекрасная возможность решить многие вопросы. Такой возможности нет у студий из других городов и стран СНГ. Не всегда удобно общаться электронным способом, живое общение это замечательно, а порой незаменимо. Например, когда заказчик хочет показать что-то на своём устройстве в режиме отладки.

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

Всё, на что вы тратите своё время:

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

Кроме того, нужно не забыть использование платных сервисов и ПО:

• github от 7$/месяц;
• Photoshop от 300 рублей/месяц;
• Illustrator 1500 рублей/месяц;
• Sketch 99$ навсегда.

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

• Аренда офиса, она же квартплата;
• Оплата интернета;
• Другое.

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

1.3. Что включать в стоимость не нужно

• Apple developer program 99$/год, если у вас есть собственные опубликованные приложения;
• Sketch, если он у вас уже есть;
• время, потраченное впустую с другими заказчиками;
• время на поиск заказчика.

2. Как себя вести исполнителю

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

С экономической точки зрения работа с фрилансерами выгодна. Но многие заказчики не работают с фрилансерами.

Разобравшись, почему так происходит, можно стать очень ценным исполнителем.
Заказчики из жизни и из интернета с негативным опытом работы с фрилансерами отмечают следующие черты:
• Лень, недисциплинированность, неумение управлять собственным временем, срыв сроков, прокрастинация;
• Потеря связи: выключенный телефон, отсутствие доступа к фрилансеру по email, skype, slack итд;
• Недоведение проекта до конца. Даже в ущерб оплате;
• Враньё, увиливание;
• Чрезмерные обещания. Клянутся сделать красиво и классно;
• Желание показаться лучше, чем на самом деле;
• Потопы в квартире, поездки в больницу, поминки бабушек, отключение интернета, смерть хомячков и прочие проблемы;
• Ведут себя как маленькие: обижаются, не признают вину, не предупреждают беды;
• Редко являются хорошими менеджерами;
• Доплата за любой чих;
• Делают не так, отказываются переделывать;
• Работа над несколькими проектами;
• Работают на постоянке, фрилансят по вечерам.
Дело в том, что экономическая сторона вопроса – не самая важная. Для заказчика гораздо важнее:
• Результативность;
• Ответственность;
• Честность;
• Зрелость;
• Гибкость;
• Сосредоточенность.
Проще говоря, заказчику нужен профессионал.

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

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

Общаясь с заказчиком, вы представляете собой руководителя, а не программиста. Разговаривать нужно на чистом языке, используя высокоуровневую лексику взамен жаргонизмам. Как говорил А. Н. Толстой, обращаться с языком кое-как — значит и мыслить кое-как: приблизительно, неточно, неверно. Заказчик может быть не в курсе ИТ-терминологии и может понять вас неверно или вообще не понять.

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

Проект может быть абсолютно новым, а может уже существовать в каком-то виде. Если вам предстоит поддерживать существующий код, ругать работу других программистов не профессионально. Особенно, когда вы уже согласились работать. Это выглядит, как оправдание собственного бессилия. При обсуждении нужно выяснить, что случилось с предыдущими работниками, почему от них отказались. Если проблема в том, что предыдущие исполнители неудовлетворительно выполняли работу, то нужно объяснить, что трудозатраты при работе с чужим грязным кодом сопоставимы с работой с нуля. В любом случае, работа с чужим кодом подразумевает период втягивания.
Если вы видите себя пользователем разрабатываемого продукта, вам понравился проект, обязательно выскажите свои соображения. Возможно, одна из ваших задумок уже записана у заказчика в списке на будущее. А может, она просто будет отмечена заказчиком, как хорошая идея. В любом случае вы продемонстрируете себя не просто как руки, готовые делать только то, что скажут, а как вовлечённый человек, и что вы на одной волне с заказчиком. Быть в теме проекта – ваш большой плюс.
Если вы не видите себя будущим пользователем сервиса, не стоит торопиться давать советы и тем более выступать с критикой. Однако вопросы целевой аудитории сервиса, какую проблему решает приложение всегда уместны.
Если заказчик чего-то не понимает, например, в силу слабых технических знаний, не нужно думать, что он глупый, плохой или что-то ещё. Заказчик обыкновенно – человек, сумевший построить свою жизнь так, что может нанять такого как вы. Ваша задача – коротко и ясно объяснять непонятные вещи. Если ученый не может объяснить, чем он занимается, уборщице, моющей пол в его лаборатории, значит, он сам не понимает, чем он занимается (приписывается Э. Резерфорду).
Если вы заметили, что заказчик хочет выбрать или выбрал неправильные технические решения, обязательно укажите на это и объясните, почему это решение неверное. При этом не забывайте, что последнее слово всегда остаётся за заказчиком.
В конце первой встречи целесообразно оставить заказчику свою контактную информацию. Часто на встречах присутствует несколько человек. А тот, с кем вы договорились о встрече может не быть тем, кто принимает решения. Лучше всего общаться с самыми главными, с теми, кто принимает решения. Если на встрече присутствует инвестор, передать ему свои контакты просто необходимо.
Если вам по каким-либо причинам не хочется браться за проект, нужно уметь отказываться и говорить “нет”. Это – очень нужное умение, отсутствием которого могут пользоваться упорные заказчики.
Не нужно браться за невыполнимые проекты. Следует разделять задачи, которые вы не делали, но можете сделать, от тех, которые вам выполнить в адекватный срок не под силу.

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

Чем больше нечёткости в требованиях, тем выше стоимость. Если вас просят оценить примерно, не стесняйтесь завышать оценку. Когда нечёткость будет разрешена, заказчику будет гораздо приятнее услышать меньшие сроки и стоимость, чем увеличенную на 30, 50, 200 процентов. Да и вообще, морально готовить заказчиков к дорогой работе часто бывает уместно.
Старайтесь внести как можно больше чёткости в понимание границ вашей работы. Если вы задаёте много вопросов до начала работ, чёткость появится и у вас, и у заказчика. Чем больше заказчик видит ваше понимание, тем выше его лояльность. Будет неприятно по ходу проекта вспомнить, что нужно ещё добавить пуш-уведомления, добавить метрики для маркетинга и кучу других мелочей.
Распространена проблема, когда заказчик и исполнитель не полностью понимают, чего они хотят друг от друга. Так называемый, разрыв ожиданий. Например, вы оценили только мобильный клиент, а заказчик, подумал, что в стоимость заложен ещё и бэкенд. Или заказчик хочет сделать регистрацию, думая об имени пользователя и пароле. А исполнитель думает об email и пароле. Или о регистрации через соц. сети. Чтобы снизить риск быть не понятым или не понять заказчика, бывает уместно перефразировать свои вопросы и ответы, убеждаясь, что все всё поняли правильно. Но поскольку всего не предусмотреть, в оценке исполнителя должен быть некоторый запас.
Если у заказчика нет чёткого понимания того, что он хочет, можно предложить ему зафиксировать некоторый объём работ, который оценивается весь. А дополнительный функционал будет оплачиваться по часам. Такая схема стимулирует заказчика напрячь свои силы в сторону конкретизации требований, и страхует исполнителя от бесплатной работы.
Нередки случаи, когда заказчик хочет внести изменения в задание, но остаться в рамках бюджета. Такие случаи включать в оценку не стоит. Потому что изменения бывают очень разные, и если пытаться застраховаться по максимуму, оценка стоимости будет заоблачной. Правильно фиксировать работы в договоре, а дополнительные доработки оценивать отдельно.
Бывает, ТЗ в явном виде отсутствует, и оценка формируется только по макетам дизайна. Бывает, что и макетов-то нет.

Вёрстка приложения занимает примерно половину времени от всей разработки, но в зависимости от сложности вёрстки, трудозатраты могут изменяться в любую сторону. И без макетов можно сильно не угадать в оценке. Кроме того, от дизайна пляшут и другие клиенты (Android, web), а также серверная разработка. В свою очередь дизайн пляшет от бизнес-требований и функциональных требований, т. е. от ТЗ. Отсюда вытекает необходимость наличия ТЗ. И чем на более ранней стадии находится проект, тем очевиднее необходимость в ТЗ. То есть, когда у сервиса нет ни сайта, ни дизайна, ничего, без ТЗ нельзя двигаться дальше. А когда, например, есть сайт, серверная часть, и требуется мобильное приложение, необходимость ТЗ уже не столь очевидна для заказчика. Но лучше короткое ТЗ, чем его полное отсутствие. Достаточно описать, что требуется от мобильного клиента и готово.
Написанием ТЗ может заниматься заказчик, а может исполнитель. Для исполнителя это работа оплачивается. И об этом нужно сразу же сказать. Что вы готовы написать ТЗ, скорректировать по требованиям заказчика, и это будет стоить денег.
При оценке проекта нужно задать вопросы по дизайну:
• анимации переходов между экранами;
• экраны-заглушки (для пустых списков);
• индикаторы загрузки;
• индикация сообщений об ошибках;

При этом, как бы внимательно вы ни оценивали проект, каким бы прозрачным он вам не казался, возьмите некоторый запас на непредвиденные случаи. Размер этого запаса составляет от 15 до 50 процентов и зависит от
• вашего понимания проекта;
• количества мест, с которыми вы не сталкивались ранее. На обзор существующих решений и изучение нужно заложить дополнительное время;
• стиля оценки и некоторых субъективных факторов. Например, вы можете потратить много времени на уточнение деталей и взять меньший запас, или же умножить трудозатраты на 1,5 и быть готовыми к любому повороту.

Пример:

Это – фрагмент дизайна. Нужно выбрать дату и время. Казалось бы, ничего трудного:
• время до 16 часов уже прошло, поэтому оно неактивно;
• время, которое можно выбрать, выделено чёрным шрифтом;
• выбранное время подсвечено оранжевым фоном и белым шрифтом.
Однако, оказалось, что список доступного времени нужно запрашивать у сервера. Для дней также бывают выходные или неактивные даты. Таким образом, задача по выбору даты оказалась не просто вёрсткой, но и скрыла в себе некоторую логику и работу с сетью.

Пример 2:

Это — тоже фрагмент дизайна. Есть сущность Задача (Task), нужно отобразить её атрибуты. С виду обычный список свойств некоторой сущности оказался динамически формируемым списком свойств, а не статическим набором. Кроме того, о некоторых атрибутах TaskAttribute я узнавал с большим опозданием (dontShowIfNull, dataType).

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

Важно понимать, что на некоторые части программы вам придётся уделить значительно больше времени, чем вы думали до начала проекта.
Отдельная песня – взаимодействие с чужим АПИ. Id типа Строка, передача параметров как multipart data, получение «json-строки» вместо json и прочие проблемы. Во избежание проблем с АПИ, очень полезно поинтересоваться о его работе на этапе оценивания проекта. Можно ли изменять выдачу под свои нужды, или АПИ изменяться не будет? Если будет изменяться, как нужно строить взаимодействие с серверным разработчиком: ставить задачи напрямую или через кого-то? Всё это влияет на время, требуемое для запуска обновления на боевом и тестовом серверах. И тут нужно сказать о простое.
Очень часто разработчикам клиентов приходится ждать разработчиков серверной части. Если такое случается в начале или середине проекта, нужно просто переключиться на другую задачу, например, вёрстку. Но когда такое случается в конце проекта, происходит простаивание.

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

Когда вам предлагают решить сложную задачу, с которой вы не сталкивались, вы имеете право предложить провести блиц-изучение проблемы за короткое время. За деньги, разумеется. По результатам вы сможете дать оценку или скорректировать требования или отказаться от работы, предоставив развёрнутую консультацию.
Если заказчика не устраивает стоимость работ, торговаться можно и нужно. Заказчик может сказать – дорого. И попросить сбросить цену. Но бывает это довольно редко, если он понимает ценность результата, и она выше названой цены. Если сейчас загрузка исполнителя низкая, или заказчик ой как хорош, то исполнителю придется взять на себя риск, срезать «подушку» и согласиться на цену ниже. Если загрузка высокая, или вы любите риск, можно сказать: «Нет, цена такая и только такая, ниже никак». Или можно поторговаться. Главное понимать, что если результаты вашей деятельности имеют ценность, то заказчик легко согласится на ваши условия, и еще будет уговаривать это сделать, иногда повышая цену. А если ценность того, чем вы занимаетесь, ниже названой цены и даже себестоимости, то заказчику стоит задуматься – зачем вообще это делать.
Но если заказчик хочет, чтобы вы сильно демпинговали, вежливо откажитесь: он ещё может к вам вернуться, когда поймёт, что ваша цена нормальная. Или не вернётся, видимо, из-за отсутствия денег. Не нужно цепляться за каждого встречного заказчика. Если заказчик вам не понравился по каким-либо другим причинам, о которых будет сказано ниже, то и в этом случае нужно суметь сказать твёрдое нет. Вообще, отказывать – полезное умение, которое лично у меня начало формироваться совсем недавно и продолжает формироваться с опытом.

2.5. Документы

До начала работ всегда важно соблюсти формальности: составить и подписать договор. Договор описывает отношения между заказчиком и исполнителем. В частности в нём указываются:
• Предмет договора;
• Срок выполнения работ;
• Порядок выполнения, сдачи и приёмки работ;
• Размер и порядок оплаты;
• Срок бесплатной поддержки;
• Ответственность сторон;
• Порядок досрочного расторжения;
• Конфиденциальность;
• Реквизиты сторон.
Наличие договора играет важнейшую роль в профилактике спорных ситуаций. Никто не любит формальности и бюрократию. В связи с этим ТЗ бывает сильно упрощено, а порой носит чисто формальный характер. И чем меньше вы задали вопросов при оценке проекта, чем меньше конкретики, чем меньше понимания каждого кусочка проекта у вас и у заказчика, тем больше проблем всплывёт во время реализации.
Договор должен содержать в качестве приложения техническое задание и дизайн. Техническое задание состоит как минимум из следующих пунктов:
• Состав работ;
• Требования к программному и аппаратному обеспечению;
• Функциональные требования;
Дизайн позволяет не допустить разрыва ожиданий по части интерфейса.

2.6. Предоплата

О предоплате нужно говорить как можно раньше. Желательно уже в первом телефонном разговоре обрисовать план ваших действий и подчеркнуть обязательность предоплаты. 50%. Эту информацию нельзя затаивать до встречи или на последний момент: вы рискуете потерять своё время впустую.
Откуда взялось это значение – 50%? Половина проекта – это та минимальная часть работы, которую вы выполните во что бы то ни стало. Я не могу представить, что должно произойти, чтобы вы не смогли этого сделать. Для исполнителя эта сумма достаточна, чтобы не остаться без денег, пока длится проект. Нельзя путать: предоплата – это не гарантия платёжеспособности заказчика, а деньги на обеспечение жизнедеятельности исполнителя.
Часто бывает, что исходный код находится на стороне заказчика, а сборки в iTunesConnect заказчика. Это означает, что по завершении работ исполнителю остаётся лишь надеяться на порядочность заказчика, и что он не будет задерживать выплату.
Бывает, что заказчик только к концу проекта начинает проверять работы и не спеша предъявлять претензии. То есть исполнитель уже готов получить оплату, а заказчик – нет. И это – дополнительный риск для исполнителя.
Есть схема, при которой роль администратора в iTC есть только у исполнителя. Тогда вы сообщаете пароль от учётной записи только после последней оплаты. Но если у заказчика уже есть приложения на этой учётной записи, то такая схема не уместна.
50% – это справедливая сумма для обеих сторон. Увеличение или уменьшение предоплаты – перестраховка. По моему опыту заказчик попытается уменьшить предоплату прежде всего, если у вас недостаточно опыта. Исполнитель имеет право увеличить размер предоплаты, если у него сложился негативный опыт с заказчиком. Например, исполнитель шёл навстречу в спорных ситуациях, а заказчик не платил вовремя. Значит, исполнитель зарекомендовал себя хорошо, а заказчик – плохо. И если он хочет работать с этим исполнителем, можно требовать 100% предоплату.
Иногда заказчик может сказать, что ему страшно отдавать 50% незнакомому человеку. Но ответственность ИП всем своим имуществом, а не уставным капиталом в 10 000 рублей как в случае в ООО, разбивает этот довод. Работая по-белому, по договору с ИП, заказчик рискует не более, чем работая со студией разработки.
В случае больших проектов, включающих серверную часть, дизайн и несколько клиентов, когда вам нужно собрать команду из нескольких человек, стоимость получается довольно высокой. В таких случаях уместно разбить проект на этапы и разделить платежи за каждый этап. Тогда каждый этап начинается с предоплаты и завершается основной оплатой.

2.7. Работа

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

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

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

2.8. Завершение проекта

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

3. Как отличить хорошего заказчика от плохого

Проверяйте заказчика «на вшивость». Если место встречи предлагают выбрать вам, договоритесь встретиться в хорошем кафе. Если заказчик готов платить сотни тысяч или миллионы рублей за разработку, он скорее всего заплатит и за ваши кофе и пирожок. На встрече вы проводите полноценную консультацию. Хороший заказчик понимает, что это не должно быть бесплатно, и оплачивает счёт.
Обговаривая предварительную оценку стоимости проекта, наберитесь смелости завысить оценку. На первых шагах обычно недостаточно данных для точной оценки, поэтому можно накинуть пару десятков процентов и даже больше, и посмотреть на реакцию заказчика. Когда ситуация проясняется, моя более точная оценка всегда уменьшается. Обычно снижение цены приятно для заказчика, особенно если он готовился к худшему.
Хороший заказчик приходит к вам с идеей и хочет узнать, сколько стоит её реализация. Плохой заказчик приходит с бюджетом и хочет в него уложиться. Такой заказчик может вести торг, обоснованный только отсутствием денег. Например, можно спросить, что нужно изменить в проекте для уменьшения стоимости. А можно тупо просить скидку 20%. Прижимистые заказчики как можно раньше хотят определить точную стоимость работ, несмотря на их нечёткость на начальном этапе.
Если на начальных этапах у вас возникают проблемы (обычно из-за денег), то дальше лучше не будет. Негативный опыт учит, чем дальше в лес, тем больше дров. Например, если заказчик задерживает предоплату, предлагает хитрые схемы оплаты, при этом форсирует начало работ, он скорее всего перестраховывается (проверяет вас) или у него просто нет денег. Следовательно и дальше можно ожидать недоверия или задержек по выплатам.
Если заказчик в ходе проекта обманул вас хотя бы однажды, в будущем с этим заказчиком иметь дел не стоит. Если были проблемы только с выплатами, то в будущем работать можно, но по 100% предоплате.
Обычно заказчика интересует срок выполнения работ и его стоимость. Реже заказчик интересуется стоимостью часа вашей работы. Ещё реже интересуется, сколько вы собираетесь зарабатывать в месяц. На этом вопросе можно прекращать разговаривать.
Я провёл мини-опрос среди своих коллег по вопросу хороших и плохих заказчиков. Почти все мы сходимся во мнении, что прямой заказчик лучше посредника. Почему? Во-первых, потому что посредник живёт за счёт своих посреднических услуг. Таким образом либо увеличивается нагрузка на бизнес конечного заказчика, либо ваша цена оказывается слишком высокой, и её просят уменьшить. Во-вторых, работая с посредником сложнее решать возникающие вопросы. Потому что посреднику нужно всё согласовывать с кем-то главным. Существует проблема испорченного телефона. Когда посредник неверно понимает или неверно доносит до исполнителя задачи, неверно истолковывает их приоритет. Ну и в-третьих, посреднику бывает неинтересно заниматься чуждым ему проектом.
Хороший заказчик умеет слушать и нередко больше слушает, чем предлагает. Такой заказчик может записывать отмеченные вами моменты. Потому что в технических вопросах экспертом выступает опытный исполнитель, а не заказчик. Хороший заказчик сам поинтересуется вашим мнением о том или ином техническом решении. Первая встреча может дать заказчику богатую пищу для размышлений, и заказчик может взять паузу на обдумывание. Хороший заказчик обязательно сообщит о своём решении, плохой заказчик может пропасть после первой встречи совсем или «всплыть» через месяц, хотя собирался ответить через несколько дней.
Заказчиков можно условно разделить на тех, кто вообще не знаком с ИТ, и тех, которые что-то да понимают. Кто лучше? В этом вопросе мнение коллег разделилось. Я считаю, что заказчиков с «ИТ-бэкграундом» стоит опасаться. Такие люди имеют свои представления о том, как нужно работать. При этом скорее всего их опыт поверхностный, потому что из ИТ они перешли в управление или куда-то ещё. Такие люди порой считают себя выше разработчиков, дороже разработчиков. От них можно услышать: «А почему так долго? Я бы на PHP за 2 часа сделал». Или «Я в институте писал на C++, мне кажется, тут будет нетрудно сделать». Такие заказчики порой предлагают вам свои «готовые» решения. Или им может казаться, что кругом полно типовых задач, которые практически бесплатно переделываются под нужды разных заказчиков. Например, был один интернет-магазин, значит, сделать любой другой будет быстро и дёшево.
Кто-то, напротив, предпочитает общаться с подкованными в ИТ людьми. Объясняя это тем, что таким заказчикам проще растолковать низкоуровневые проблемы. Или что такие люди задают меньше глупых вопросов.
Хороший вариант – работать с заказчиком, имеющим опыт в ИТ-проектах. Плохой или хороший. Заказчик с хорошим опытом понимает стоимость разработки и понимает величину доходов от успешного проекта. Заказчик с любым опытом понимает важность чётких формулировок, ясных целей, необходимость ТЗ.
Хороший заказчик может сам спросить о предоплате. А если и нет, то спокойно воспринимает информацию о ней. Хороший заказчик также, говоря об изменениях, первым подчёркивает, что изменения требует дополнительной оценки и оплаты. Плохой заказчик не только торгуется на этапе предоплаты, но и доп. работу не хочет оплачивать сразу. Например, просит включить стоимость доп. работ в следующий этап. Это – очень распространённый ход, целью которого является рассрочка и удерживание исполнителя на коротком поводке. Нет гарантий, что следующий этап не наступит никогда или будет проходить без вашего участия.
Хороший заказчик чётко видит и понимает свой проект, позитивно настроен. А там, где он видит нечёткости, старается вникнуть и разрешить нечёткость. Плохой заказчик плавает в своих требованиях, из-за чего может вносить изменения тех или иных частей проекта уже в процессе реализации.
Хороший заказчик смотрит предварительные результаты работ. Это позволяет устранить разрыв ожиданий на ранних стадиях. Плохой заказчик ждёт, когда будет готово всё, а потом заваливает претензиями.
Вспоминая своих заказчиков, отмечу, что и плохим, и хорошим заказчикам почти всегда присущи сразу несколько характерных черт. Но бывает, людям присущи одновременно и положительные, и отрицательные черты. Поэтому описанные выше положительные признаки нужно рассматривать не как гарантию на успех в работе, а как плюсы проекта при принятии решения о начале работы над ним или как преимущества над другими проектами, если вам нужно сделать выбор. Отрицательные черты также нужно рассматривать не как призыв к скорейшему разрыву отношений, а как тревожные звоночки, сигнализирующие о возможных рисках.
Более того, если заказчик – ваш знакомый или знакомый знакомого, то это – совсем другой разговор. По собственному опыту скажу, абсолютно всем моим заказчикам меня рекомендовали знакомые, прошлые заказчики и их знакомые. Можно ли им доверять, честные ли это люди – проверять исполнителю и лучше перестраховываться. Наличие позитивного опыта с заказчиком, совершенно не означает адекватность его партнёров и знакомых. Если заказчика привёл ваш знакомый, задайте своему знакомому несколько вопросов о заказчике. Кто он, чем занимается, как они общаются? Проявлял ли он себя с хорошей или плохой стороны?
 

4. Разрешение спорных ситуаций

Существуют 2 главные проблемы, составляющие суть споров:

1. неоплата и задержки при оплате;
2. определение объёма работ.

Первая проблема частично решается предоплатой. Обе проблемы практически полностью решаются договором. Договор описывает отношения между заказчиком и исполнителем и обязательно включает в себя 2 приложения: ТЗ и дизайн. Поэтому при наличии договора даже если возникают споры, их можно разрешить справедливо.
Никто не любит формальности, но и формалистов тоже никто не любит. Поэтому нужно быть гибким. Если заказчик решает что-то изменить по ходу реализации, то возникает спорная ситуация. Я, например, делаю так. Если работа, требующая изменений ещё не начата, я соглашаюсь внести изменения. Если же работа уже начата или сделана, то изменения требуют дополнительной работы, и тогда нужно писать доп. соглашение с ценой этой работы. В конце концов всё зависит от трудозатрат, требующихся для реализации изменений. Если работы мало, вы можете сделать её и бесплатно. Так вы заработаете несколько очков репутации в уступчивости, гибкости. Заработаете лояльность заказчика. Сегодня уступили вы – завтра можете просить уступить вам.
Что делать, если вам задерживают оплату? Юридически у вас есть договор с указанными сроками выполнения работ. Когда всё готово, заказчик должен подписать акт об их выполнении. Или предоставить свои претензии. Поэтому при составлении договора внимательно указывайте сроки. С одной стороны так, чтобы иметь небольшой запас, и, с другой стороны, чтобы вам не пришлось ждать оплаты несколько месяцев. Если же письменный договор составлен не был, то, во-первых, это нарушение ГК РФ, а, во-вторых, риск исполнителя остаться без денег или ждать их неопределённый срок.

Конечно, проблемы могут возникать и с наличием на руках подписанного заказчиком экземпляра. Заказчик может объявить о каких-то проблемах, например, серверная часть что-то не успевает сделать или существуют нетехнические проблемы (заведение аккаунта в iTC, продление Apple developer program, денежные проблемы, наконец). В таких случаях вы можете пойти навстречу заказчику и подождать. А можете просить оплату по договору, а доделки выполнить, когда будет возможность, бесплатно. Вопрос, сколько ждать. Будьте осторожнее: заказчик, почувствовав вашу слабость, вряд ли упустит возможность этим воспользоваться.
В общем случае, нужно стараться решать проблемы так, чтобы вы не выглядели как упрямый баран, но в то же время нельзя давать прогибать себя слишком сильно или слишком часто. Другими словами, нужно уметь договариваться.
Если для реализации какой-либо части проекта предполагается использовать готовые компоненты (например, чат или хранилище для медиа-файлов), принятие решения о выборе компонента необходимо согласовывать с заказчиком. Опять-таки предоставив ему консультацию в области существующих решений на рынке. Для проведения такой консультации исполнителю нужно будет провести ознакомление с такими решениями, узнать цены, ограничения и прочее. Исполнитель, не согласовавший свой выбор с заказчиком, берёт полную ответственность за возможные проблемы на себя.
Если вы взяли крупный проект, и люди, за работу которых вы отвечаете, не справляются, пропадают или срывают сроки, возникает спорная ситуация. Кто виноват и что делать? Если вы – человек ответственный, то вину берёте на себя. Потому что это вы набрали такую команду. Иногда приходится работать с меньшей выгодой или даже в убыток, но не потеряв репутацию и лицо. Сетовать на кого-то в таких ситуациях крайне непрофессионально. Порядочный человек всегда выполняет свои обязательства перед другими и не боится ответственности. При возникновении проблем с другой стороны (заказчик отказывается платить), вы также ответственны перед своими коллегами, потому что они договаривались с вами, а не с вашим заказчиком. Для того и берётся предоплата, вводятся этапы, чтобы свести к минимуму риски опростоволоситься перед коллегами.
 

Заключение

Индивидуальные разработчики могут зарабатывать больше, чем наёмные работники, при этом всё ещё оставаясь более дешёвыми исполнителями для заказчика. Поэтому заказчики нередко обращаются к фрилансерам. Но часто заказчикам куда важнее профессионализм исполнителя, чем возможность сэкономить.
Деятельность и зона ответственности такого разработчика уходит далеко за пределы только технической работы. Фрилансер материально ответственен за свои слова и принятые решения, которые закрепляются в договоре. Поэтому к своим решениям нужно подходить очень взвешенно. Семь раз отмерь – один отрежь.
Принятие решения о начале работ с заказчиком или отказ от сотрудничества – главное решение в каждой работе. Это решение должно быть хорошо взвешено. Не нужно бояться говорить “нет”. Лучше 2 недели простоя, чем 2 месяца геморроя. Приглядитесь получше к заказчику.
Если вы берётесь за работу, то отвечаете за результат не только деньгами, но и репутацией. Взялся за гуж – не говори, что не дюж.
Бумажки играют важную роль в отношениях между заказчиком и исполнителем. Особенно их роль возрастает при возникновении проблем. Серьёзность отношения к договору, приложениям к договору, ТЗ, акту о выполнении работ не зависит от степени близости с заказчиком. Будь то друг или человек из другого города. Эти документы вносят ясность не только в спорных ситуациях, не только оказывают профилактическое действие, но и просто упорядочивают процесс разработки.

Автор: POGlicier

Источник