Фінансові розрахунки

Це постійне питання або спір, кому як зручніше, у відносинах розробника і замовника - це процес приймання-передачі робіт. Виникає він досить часто, через принципу довіряй, але перевіряй. На жаль в наш час у сфері IT існує досить великий відсоток шахрайства в Інтернет, починаючи від накрутки рейтингів і закінчуючи вимаганням грошей за те, щоб не залишати поганих відгуків не з того ні сього. І саме з цього, на даному етапі і відбувається найбільша кількість конфліктів і ось короткий, але основний перелік причин і проблем пов'язаних з цим:

· якість виконаної роботи не відповідає спочатку описаного в технічному завданні;

· замовник вважає, що він повинен був отримати більше послуг за вказаний бюджет;

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

Варто відзначити, що абсолютно в будь-яких договірних відносинах можна зіткнутися з недобросовісним відношенням як однієї, так і іншої сторони, саме для дозволу такого виду спорів існує суд.

«Радянський суд, найгуманніший суд у світі». (с) Віцин

IT проекти є не винятком. У будь-якого нормально сервісу, тепер є своя служба суду. Народна назва прижилася як «Арбітраж». Це третя сторона, яка не зацікавлена в результаті суперечки і може прийняти об'єктивне рішення, на основі наданих фактів.

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

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

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

Прозорість в ділових відносинах можна забезпечити тільки одним способом - заздалегідь обговорювати всі деталі договору і особливо підкреслити, що приймання та передача роботи буде вироблятися строго відповідно до технічного завдання. Також обумовлює, що в разі виникнення розбіжностей Арбітраж буде використовувати технічне завдання, як основний документ для прийняття рішення на користь замовника або розробника. Даний підхід виключає всі розбіжності і тема «хто правий, а хто винен» стає повністю вичерпаною і більш не буде вас турбувати, а головне позначиться на вашій репутації тільки позитивно.

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

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

Як перевіряти проект при здачі замовнику?

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

Тому заведіть собі правило, яке не можна порушувати ні за яких умов:

Читайте також:

<== попередня сторінка	\|	наступна сторінка ==>
Відгуків	\|	Провести повну звірку виконаної роботи відповідно до технічного завдання перед здачею проекту.

Не знайшли потрібну інформацію? Скористайтесь пошуком google:

Генерація сторінки за: 0.026 сек.