Як спілкуватися із замовниками і домовлятися про проектній роботі

Я займаюся розробкою мобільного статус ІП ось уже півтора року. За цей час довелося попрацювати з різними людьми. Після одного прикрого випадку, я вирішив, що мені необхідно посилити навички спілкування з замовниками та відстоювання своїх інтересів. Я спробував зібрати свій досвід і досвід своїх колег. У результаті вийшло щось на зразок методичних вказівок для фрілансерів. Початківців і не тільки.

Введення
Коли виникає необхідність створення якого-небудь сервісу взагалі або мобільного додатку зокрема, у замовника є три підходи до реалізації своєї ідеї:
  • Створення юр. особи і наймання працівників в штат (відповідно до ТК РФ);
  • Замовлення робіт у студії розробки;
  • Замовлення робіт у фрілансерів (індивідуальних підприємців).
В п. 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 напрями), фрілансер може підняти свій цінник.
Тут хотілося б відзначити ще одна з переваг індивідуальних розробників перед студіями. Відсутність складної ієрархії «розробники – керівники вищих директора», ні зіпсованого телефону, немає ланок, що потребують додаткової оплати, немає бюрократії. Але є прозорість.
Крім того, перебуваючи з виконавцем в одному місті, замовник має можливість зустрічатися з ним. Це – прекрасна можливість вирішити багато питань. Такої можливості немає у студій з інших міст і країн СНД. Не завжди зручно спілкуватися електронним способом, живе спілкування це чудово, а часом незамінне. Наприклад, коли замовник хоче показати щось на своєму пристрої в режимі налагодження.
Приклад:Замовник стверджує, що у нього «гальмує» додаток. Я перевірив на iPhone 5 – гальм немає. На зустрічі виявилося, що під гальмами замовник мав на увазі довге завантаження списковой структури, а не лаги під час перегляду.

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. Яку лексику
Спілкуючись із замовником, ви являєте собою керівника, а не програміста. Розмовляти потрібно чистою мовою, використовуючи високорівневу лексику натомість жаргонизмам. Як говорив А. Н. Толстой, звертатися з язиком сяк — означає мислити абияк: приблизно, неточно, неправильно. Замовник може бути не в курсі ІТ-термінології і може зрозуміти вас невірно або взагалі не зрозуміти.



Приклад:Спілкуючись із замовником, він використовував термін MVP. Я думав, це Model-View-Presenter і дивувався, навіщо він лізе в проектування. Через 2 хвилини я запитав, що таке MVP. «Minimum viable product» — відповів замовник. Тобто продукт з мінімумом необхідних функцій.

2.3. Знайомство з замовником та проектом
Проект може бути абсолютно новим, а може вже існувати в якомусь вигляді. Якщо вам належить підтримувати існуючий код, лаяти роботу інших програмістів не професійно. Особливо, коли ви вже погодилися працювати. Це виглядає, як виправдання власного безсилля. При обговоренні потрібно з'ясувати, що сталося з попередніми працівниками, чому від них відмовилися. Якщо проблема в тому, що попередні виконавці незадовільно виконували роботу, то потрібно пояснити, що трудовитрати при роботі з чужим брудним кодом порівнянні з роботою з нуля. У будь-якому випадку, робота з чужим кодом увазі період втягування.
Якщо ви бачите себе користувачем розроблюваного продукту, вам сподобався проект, обов'язково висловіть свої міркування. Можливо, одна з ваших задумів вже записана у замовника в списку на майбутнє. А може, вона просто буде відзначена замовником, як хороша ідея. У будь-якому випадку ви продемонструєте себе не просто як руки, готові робити тільки те, що скажуть, а як залучений людина, і що ви на одній хвилі з замовником. Бути в темі проекту – ваш великий плюс.
Якщо ви не бачите себе майбутнім користувачем сервісу, не варто поспішати давати поради і тим більше виступати з критикою. Однак питання цільової аудиторії сервісу, яку проблему вирішує додаток завжди доречні.
Якщо замовник чогось не розуміє, наприклад, в силу слабких технічних знань, не потрібно думати, що він дурний, поганий або щось ще. Замовник звичайно – людина, який зумів побудувати своє життя так, що може найняти такого як ви. Ваше завдання – коротко і ясно пояснювати незрозумілі речі. Якщо вчений не може пояснити, чим він займається, прибиральниці, митиме підлогу в його лабораторії, значить, він сам не розуміє, чим він займається (приписується Е. Резерфорду).
Якщо ви помітили, що замовник хоче вибрати або вибрав неправильні технічні рішення, обов'язково вкажіть на це і поясніть, чому це рішення неправильне. При цьому не забувайте, що останнє слово завжди залишається за замовником.
В кінці першої зустрічі доцільно залишити замовнику свою контактну інформацію. Часто на зустрічах присутні кілька осіб. А той, з ким ви домовилися про зустріч може не бути тим, хто приймає рішення. Найкраще спілкуватися з найголовнішими, з тими, хто приймає рішення. Якщо на зустрічі присутній інвестор, передати йому свої контакти просто необхідно.
Якщо вам з якихось причин не хочеться братися за проект, потрібно вміти відмовлятися і говорити «ні». Це – дуже потрібне вміння, відсутністю якого можуть користуватися постійні замовники.
Не треба братися за нездійсненні проекти. Слід розділяти завдання, які ви не робили, але можете зробити, від тих, які вам виконати в адекватний термін не під силу.
Два приклади:Ви не працювали з веб-сокетами. Цієї технології багато років, вона обкатана, тому ви знайдете відповідну бібліотеку і вивчіть роботу з нею. Просто на огляд існуючих рішень і вивчення потрібно закласти додатковий час. Або вам запропонували розробити двомірну або тривимірну гру. Якщо у вас немає відповідного досвіду, на реалізацію такого завдання піде так багато часу, що краще відразу звернутися до ігрового розробника.

2.4. Оцінка часу і грошей
Чим більше нечіткості у вимогах, тим вище вартість. Якщо вас просять оцінити приблизно, не соромтеся завищувати оцінку. Коли нечіткість буде вирішено, замовникові буде набагато приємніше почути менші терміни і вартість, ніж збільшену на 30, 50, 200 відсотків. Та й взагалі, морально готувати замовників до дорогої роботі часто буває доречно.
Намагайтеся внести якомога більше чіткості у розуміння меж вашої роботи. Якщо ви ставите багато питань до початку робіт, чіткість з'явиться і у вас, і у замовника. Чим більше замовник бачить ваше розуміння, тим вище його лояльність. Буде неприємно по ходу проекту згадати, що потрібно ще додати пуш-повідомлення, додати метрики для маркетингу і купу інших дрібниць.
Поширена проблема, коли замовник і виконавець не повністю розуміють, чого вони хочуть один від одного. Так званий розрив очікувань. Наприклад, ви оцінили тільки мобільний клієнт, а замовник, подумав, що вартість закладений ще і бекенд. Або замовник хоче зробити реєстрацію, думаючи про ім'я користувача та пароль. А виконавець думає про email і пароль. Або про реєстрацію через соц. мережі. Щоб знизити ризик бути не зрозумілим або не зрозуміти замовника, буває доречно перефразувати свої запитання та відповіді, переконуючись, що всі все зрозуміли правильно. Але оскільки всього не передбачити, в оцінці виконавця повинен бути певний запас.
Якщо у замовника немає чіткого розуміння того, що він хоче, можна запропонувати йому зафіксувати певний обсяг робіт, який оцінюється весь. А додатковий функціонал буде оплачуватися по годинах. Така схема стимулює замовника напружити свої сили в бік конкретизації вимог, і страхує виконавця від безкоштовної роботи.
Нерідкі випадки, коли замовник хоче внести зміни в завдання, але залишитися в рамках бюджету. Такі випадки включати в оцінку не варто. Тому що зміни бувають дуже різні, і якщо намагатися застрахуватися по максимуму, оцінка вартості буде захмарною. Правильно фіксувати роботи у договорі, а додаткові доопрацювання оцінювати окремо.
Буває, ТЗ в явному вигляді відсутня, і оцінка формується тільки за макетів дизайну. Буває, що і макетів-то немає.
Приклад:Я робив клієнт для програми лояльності одного торгового центру з одним замовником. Коли їм знадобилося аналогічний додаток для іншого ТЦ, мене попросили дати оцінку для випадку, коли зміниться тільки користувальницький інтерфейс: зміняться фони, розташування кнопок, іконки. В цьому випадку не було ні ТЗ, ні макета.
Але це рідкісний випадок, коли потрібно виконати 2 майже однакові роботи. Тому дизайн повинен бути обов'язково.

Верстка програми займає приблизно половину часу від усієї розробки, але залежно від складності верстки, трудовитрати можуть бути змінені в будь-яку сторону. І без макетів можна сильно не вгадати в оцінці. Крім того, від дизайну танцюють і інші клієнти (Android, web), а також серверна розробка. У свою чергу дизайн танцює від бізнес-вимог і функціональних вимог, тобто від ТЗ. Звідси випливає необхідність наявності ТЗ. І чим на більш ранній стадії знаходиться проект, тим очевиднішою необхідність в ТЗ. Тобто, коли у сервісу немає ні сайту, ні дизайну, нічого, без ТЗ не можна рухатися далі. А коли, наприклад, є сайт, серверна частина, і потрібен мобільний додаток, необхідність ТЗ вже не настільки очевидна для замовника. Але краще коротке ТЗ, ніж його повна відсутність. Досить описати, що потрібно від мобільного клієнта і готово.
Написанням ТЗ може займатися замовник, а виконавець може. Для виконавця це робота оплачується. І про це треба відразу ж сказати. Що ви готові написати ТЗ, скорегувати по вимогам замовника, і це буде коштувати грошей.
При оцінці проекту слід задати питання по дизайну:
• анімації переходів між екранами;
• екрани-заглушки (для порожніх списків);
• індикатори завантаження;
• індикація повідомлень про помилки;

При цьому, як би уважно ви не оцінювали проект, яким би прозорим він вам не здавався, візьміть деякий запас на непередбачені випадки. Розмір цього запасу становить від 15 до 50 відсотків і залежить від
• вашого розуміння проекту;
• кількості місць, з якими ви не стикалися раніше. На огляд існуючих рішень і вивчення потрібно закласти додатковий час;
• стилю оцінки та деяких суб'єктивних факторів. Наприклад, ви можете витратити багато часу на уточнення деталей і взяти менший запас, або ж помножити трудовитрати на 1,5 і бути готовими до будь-якого повороту.
Приклад:
Це – фрагмент дизайну. Потрібно вибрати дату і час. Здавалося б, нічого складного:
• час до 16 годин вже пройшло, тому воно неактивне;
• час, який можна вибрати, виділено чорним шрифтом;
• вибране час підсвічується жовтогарячим і білим шрифтом.
Однак, виявилося, що список доступного часу потрібно запитувати у сервера. Для днів також бувають вихідні або неактивні дати. Таким чином, завдання з вибором дати виявилася не просто версткою, але і сховала в собі деяку логіку і роботу з мережею.

Приклад 2:

Це — теж фрагмент дизайну. Сутність Завдання (Task), потрібно відобразити її атрибути. З вигляду звичайний список властивостей деякої сутності виявився динамічно формується списком властивостей, а не статичним набором. Крім того, про деякі атрибути TaskAttribute я дізнавався з великим запізненням (dontShowIfNull, dataType).



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

Важливо розуміти, що деякі частини програми вам доведеться приділити значно більше часу, ніж ви думали до початку проекту.
Окрема пісня – взаємодія з чужим АПІ. Id типу Рядок, передача параметрів як multipart data, отримання «json-рядки» замість json та інші проблеми. Щоб уникнути проблем з АПІ, дуже корисно поцікавитися про його роботу на етапі оцінювання проекту. Можна змінювати видачу під свої потреби, або АПІ змінюватися не буде? Якщо буде змінюватися, як потрібно будувати взаємодію з серверним розробником: ставити завдання безпосередньо або через кого-то? Все це впливає на час, необхідний для запуску оновлення на бойовому та тестовому серверах. І тут треба сказати про просте.
Дуже часто розробникам клієнтів доводиться чекати розробників серверної частини. Якщо таке трапляється на початку або середині проекту, потрібно просто переключитися на іншу задачу, наприклад, верстку. Але коли таке трапляється в кінці проекту, відбувається простоювання.
Приклад:Потрібно реалізувати пуш-повідомлення. iOS-розробник створює сертифікати, розповідає про openssl для конвертації сертифікатів в потрібний формат, замовляє метод для поновлення сертифіката, замовляє payload і реалізує обробку payload. І після цього може початися процес очікування.

Простий не повинен бути безкоштовним. Про це потрібно говорити. Можна запропонувати замовнику піти назустріч і здійснити оплату, не чекаючи завершення серверних робіт. Коли все буде готово, виконавець доробить безкоштовно.
Ще один приклад:Замовник хоче реалізувати деякий функціонал, що вимагає роботи і на сервері, і на клієнті. Клієнт готовий, а сервер немає. Можна запропонувати випустити додаток, не чекаючи сервера. А той функціонал додати в оновленні.

Коли вам пропонують вирішити складну задачу, з якою ви не стикалися, ви маєте право запропонувати провести бліц-вивчення проблеми за короткий час. За гроші, зрозуміло. За результатами ви зможете дати оцінку або скорегувати вимоги або відмовитися від роботи, надавши розгорнуту консультацію.
Якщо замовника не влаштовує вартість робіт, торгуватися можна і потрібно. Замовник може сказати – дорого. І попросити скинути ціну. Але це буває досить рідко, якщо він розуміє цінність результату, і вона вище названої ціни. Якщо зараз завантаження виконавця низька, або замовник ой як хороший, то виконавцю доведеться взяти на себе ризик, зрізати «подушку» і погодитися на ціну нижче. Якщо завантаження висока, або ви любите ризик, можна сказати: «Ні, ціна така і тільки така, нижче ніяк». Чи можна поторгуватися. Головне розуміти, що якщо результати вашої діяльності мають цінність, то замовник легко погодиться на ваші умови, і ще буде вмовляти це зробити, іноді підвищуючи ціну. А якщо цінність того, чим ви займаєтеся, нижче названої ціни і навіть собівартості, то замовнику варто задуматися – навіщо взагалі це робити.
Але якщо замовник хоче, щоб ви сильно демпінгували, ввічливо відмовтеся: він ще може повернутися, коли зрозуміє, що ваша ціна нормальна. Чи не повернеться, мабуть, з-за відсутності грошей. Не потрібно чіплятися за кожного зустрічного замовника. Якщо замовник вам не сподобався з якихось інших причин, про які буде сказано нижче, то і в цьому випадку потрібно зуміти сказати тверде ні. Взагалі, відмовляти – корисне вміння, яке особисто у мене почало формуватися зовсім недавно і продовжує формуватися з досвідом.

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++, мені здається, тут буде неважко зробити». Такі замовники часом пропонують вам свої «готові» рішення. Або їм може здаватися, що навколо повно типових завдань, які практично безкоштовно переробляються під потреби різних замовників. Наприклад, був один інтернет-магазин, значить, зробити будь-який інший буде швидко і дешево.
Хтось, навпаки, вважає за краще спілкуватися з підкованими в IT людьми. Пояснюючи це тим, що таким замовникам простіше розтлумачити низькорівневі проблеми. Або що такі люди задають менше дурних питань.
Хороший варіант – працювати з замовником, що мають досвід в ІТ-проектах. Поганий чи хороший. Замовник з хорошим досвідом розуміє вартість розробки і розуміє величину доходів від успішного проекту. Замовник з будь-яким досвідом розуміє важливість чітких формулювань, ясних цілей, необхідність ТЗ.
Хороший замовник може сам запитати про передоплату. А якщо і ні, то спокійно сприймає інформацію про неї. Хороший замовник також, говорячи про зміни, першим підкреслює, що зміни вимагає додаткової оцінки і оплати. Поганий замовник не лише торгується на етапі передоплати, але і дод. роботу не хоче оплачувати відразу. Наприклад, просить включити вартість дод. робіт в наступний етап. Це – дуже поширений хід, метою якого є розстрочення та утримання виконавця на короткому повідку. Немає гарантій, що наступний етап не настане ніколи або буде проходити без вашої участі.
Хороший замовник чітко бачить і розуміє свій проект, позитивно налаштований. А там, де він бачить нечіткості, намагається вникнути і дозволити нечіткість. Поганий замовник плаває у своїх вимогах, із-за чого може вносити зміни тих чи інших частин проекту вже в процесі реалізації.
Хороший замовник дивиться попередні результати робіт. Це дозволяє усунути розрив очікувань на ранніх стадіях. Поганий замовник чекає, коли буде готове все, а потім завалює претензіями.
Згадуючи своїх замовників, зазначу, що і поганим і хорошим замовникам майже завжди притаманні відразу кілька характерних рис. Але буває, що людям притаманні одночасно і позитивні, і негативні риси. Тому описані вище позитивні ознаки потрібно розглядати не як гарантію на успіх в роботі, а як плюси проекту при прийнятті рішення про початок роботи над ним або як переваги над іншими проектами, якщо вам потрібно зробити вибір. Негативні риси також потрібно розглядати не як заклик до якнайшвидшого розриву відносин, а як тривожні дзвіночки, які сигналізують про можливі ризики.
Більш того, якщо замовник – ваш знайомий чи знайомий знайомого, то це – зовсім інша розмова. З власного досвіду скажу, абсолютно всім моїм замовникам мене рекомендували знайомі, колишні замовники та їх знайомі. Чи можна їм довіряти, чесні це люди – перевіряти виконавцю і краще перестраховуватися. Наявність позитивного досвіду з замовником, зовсім не означає адекватність його партнерів і знайомих. Якщо замовника привів ваш знайомий, задайте своєму знайомому кілька питань про замовника. Хто він, чим займається, як вони спілкуються? Виявив він себе з гарної або поганої сторони?

4. Дозвіл спірних ситуацій
Існує 2 головні проблеми, складові суть суперечок:
  1. неоплата і затримки при оплаті;
  2. визначення обсягу робіт.
Перша проблема частково вирішується передоплатою. Обидві проблеми практично повністю вирішуються договором. Договір описує відносини між замовником і виконавцем і обов'язково включає в себе 2 програми: ТЗ і дизайн. Тому при наявності договору навіть якщо виникають спори, їх можна вирішити справедливо.
Ніхто не любить формальності, але і формалістів теж ніхто не любить. Тому потрібно бути гнучким. Якщо замовник вирішує щось змінити по ходу реалізації, то виникає спірна ситуація. Я, наприклад, роблю так. Якщо робота, що вимагає змін ще не розпочато, я погоджуюся внести зміни. Якщо ж робота вже розпочата або зроблена, то зміни вимагають додаткової роботи, і тоді треба писати дод. угода з ціною цієї роботи. Зрештою все залежить від трудовитрат, необхідних для реалізації змін. Якщо роботи мало, ви можете зробити її і безкоштовно. Так ви заробите кілька очок репутації в поступливості, гнучкості. Заробите лояльність замовника. Сьогодні поступилися ви – завтра можете просити поступитися вам.
Що робити, якщо вам затримують оплату? Юридично у вас є договір з зазначеними термінами виконання робіт. Коли все готово, замовник повинен підписати акт про їх виконання. Або надати свої претензії. Тому при складанні договору уважно вказуйте терміни. З одного боку так, щоб мати невеликий запас, і, з іншого боку, щоб вам не довелося чекати оплати кілька місяців. Якщо ж письмовий договір складений не був, то, по-перше, це порушення ЦК РФ, а, по-друге, ризик виконавця залишитися без грошей або чекати їх невизначений термін.
Приклад:Замовник надіслав мені договір на підпис по електронній пошті. Я розпечатав договір, підписав його, відсканував і відправив назад. Отримав передоплату, розпочав роботу. А отримати підписаний примірник замовника забув. Замовник теж забув або зробив вигляд, що забув. До кінця проекту з боку замовника окреслилися деякі проблеми, що вимагають відстрочки закриття проекту. І мені довелося чекати, поки замовник дозволив свої проблеми.
Висновок: починати роботу до одержання передоплати – величезний ризик втратити час і залишитися без грошей, але не можна забувати і про підписання договору: він визначає терміни оплати.

Звичайно, проблеми можуть виникати і з наявністю на руках підписаного замовником примірника. Замовник може оголосити про якісь проблеми, наприклад, серверна частина щось не встигає зробити або існують нетехнічні проблеми (заклад аккаунта в iTC, продовження Apple developer program, грошові проблеми, нарешті). У таких випадках ви можете піти назустріч замовнику і почекати. А можете просити оплату за договором, а доробки виконати, коли буде можливість, безкоштовно. Питання, скільки чекати. Будьте обережніше: замовник, відчувши вашу слабкість, навряд чи упустить можливість цим скористатися.
В загальному випадку, потрібно намагатися вирішувати проблеми так, щоб ви не виглядали як впертий баран, але в той же час не можна давати прогинати себе занадто сильно або занадто часто. Іншими словами, потрібно вміти домовлятися.
Якщо для реалізації якої-небудь частини проекту передбачається використовувати готові компоненти (наприклад, чат або сховище для медіа-файлів), прийняття рішення про вибір компонента необхідно погоджувати з замовником. Знову-таки надавши йому консультацію в області існуючих рішень на ринку. Для проведення такої консультації виконавцю потрібно буде провести ознайомлення з такими рішеннями, довідатися про ціни, обмеження та інше. Виконавець, не узгодив свій вибір з замовником, бере повну відповідальність за можливі проблеми на себе.
Якщо ви взяли великий проект і люди, за роботу яких ви відповідаєте, не справляються, пропадають або зривають терміни, виникає спірна ситуація. Хто винен і що робити? Якщо ви – людина відповідальна, то провину берете на себе. Бо це ви набрали таку команду. Іноді доводиться працювати з меншою вигодою або навіть в збиток, але не втративши репутацію і особа. Нарікати на кого-то в таких ситуаціях вкрай непрофесійно. Порядна людина завжди виконує свої зобов'язання перед іншими і не боїться відповідальності. При виникненні проблем з іншого боку, (замовник відмовляється платити), ви також відповідальні перед своїми колегами, тому що вони домовлялися з вами, а не з вашим замовником. Для того і береться передоплата, вводяться етапи, щоб звести до мінімуму ризики осоромилися перед колегами.

Висновок
Індивідуальні розробники можуть заробляти більше, ніж наймані працівники, при цьому все ще залишаючись більш дешевими виконавцями для замовника. Тому замовники нерідко звертаються до фрілансерам. Але часто замовникам куди важливіше професіоналізм виконавця, ніж можливість заощадити.
Діяльність і зона відповідальності такого розробника йде далеко за межі тільки технічної роботи. Фрілансер матеріально відповідальною за свої слова і прийняті рішення, які закріплюються в договорі. Тому до своїх рішень потрібно підходити дуже виважено. Сім разів відміряй – один відріж.
Ухвалення рішення про початок робіт із замовником або відмова від співробітництва – головне рішення в кожній роботі. Це рішення повинно бути добре зважено. Не треба боятися говорити «ні». Краще 2 тижні простою, ніж 2 місяці геморою. Придивіться краще до замовника.
Якщо ви беретеся за роботу, то відповідаєте за результат не тільки грошима, але і репутацією. Взявся за гуж – не кажи, що не дуж.
Папірці відіграють важливу роль у відносинах між замовником і виконавцем. Особливо їх роль зростає при виникненні проблем. Серйозність відношення до договору, додатків до договору, ТЗ, акта про виконання робіт не залежить від ступеня близькості з замовником. Будь то друг або людина з іншого міста. Ці документи вносять ясність не тільки в спірних ситуаціях, не тільки надають профілактичну дію, але і просто упорядковують процес розробки.
ПосиланняПро податки www.malyi-biznes.ru/nalogi-ooo/;
Кількість годин в році www.consultant.ru/law/ref/calendar/proizvodstvennye/;
Вартість робіт у студій www.cossa.ru/155/122567/;
Погляд з-за кордону www.raywenderlich.com/122835/freelance-software-development-tips;
Про вимір годинами www.e-xecutive.ru/management/itforbusiness/1947865-it-dlya-biznesa-pochemu-it-budzhety-nelzya-izmeryat-chasami;
Про недоліки фрілансерів www.the-village.ru/village/business/management/214825-kak-rabotat-s-frilanserami.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.