Використання відрядної оплати праці у web-студії

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

Не перераховуватиму перші системи нарахування оплати, т.к. вони більше схожі на офісний фріланс, що не дивно, тому що перші 1 - 1,5 роки ми брали замовлення в основному саме з фріланс. Потім стан справ змінився, і потрібно змінити підхід до зарплати. Остання модель, яку ми використовували, виглядала так:

У співробітника був фіксований мінімум (N рублів).
Усі завдання оцінювалися у бальній системі, залежно від складності та термінів. Як правило, 1 робочий день "коштував" 0,5 бала.
Співробітник мав план, який залежав від посади (m балів на місяць).
Якщо співробітник не виконував план, він отримував мінімальний фікс.
Якщо співробітник перевиконував план (за місяць набирав M балів), він отримував мінімальний фікс + премію, розраховану за формулою: (M-m) x Z, де Z — вартість одного перевиконаного бала.

Наприклад, у програміста Васі мінімальний фікс - 40 000 р., План - 8 балів, вартість перевиконаного бала - 4 000р. У місяці — 22 робочі дні, з яких 19 днів Вася робив проекти з оцінки 0,5 бала за 1 робочий день, а 3 дні правил баги. У такому разі зарплата Васі становитиме:

((19x0,5 + 3x0) - 8) х 4 000р. + 40 000 грн. = 46 000р.

Для наочності цифри взяті «зі стелі».

Такий підхід має ряд плюсів:

Васі вигідно робити проекти якіснішими, щоб потім не правити баги.
Скільки Вася напрацює, стільки й отримає.

Але є й низка мінусів:

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

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

Мета та завдання

Чесна заробітна плата. Найважливіше завдання. Співробітник повинен отримувати стільки тенге, скільки реально заробив.
Прозорість. При розрахунку зарплати в жодному разі не повинно бути ефекту чорної коробки.
Система має стимулювати співробітників підвищувати свою кваліфікацію.
Лояльність до студії загалом.
Прогнозування заробітної плати. Однією з «болячок» перших систем було таке: співробітник одного місяця міг зірвати куш, а в іншій — «смоктати лапу».
Кар'єрний ріст. Має бути чітке розуміння, коли і за яких умов людина може претендувати на підвищення.
Соцзмагання та порівняння довжини майстерності.

Теоретична модель

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

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

«Виходить щось на кшталт RPG: напрацював на 20 балів — отримай 3-й рівень та мінімальний фікс 15 000 р., напрацював на 100 — 10-й рівень та 30 000».

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

Проектні

Таким чином, проектні завдання оцінюються до реального виконання, а сапортні — за фактом виконання з розрахунку 0,5 балів за робочий день. У проектних можуть бути додані коефіцієнти (надбавки) за складність та проблеми у взаєморозумінні із замовником, а також діє бонус за швидкість.

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

Для розуміння розглянемо кілька прикладів.

Васі потрібно зробити сапортне завдання, яке він оцінив о 12 годині

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

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

Вася отримає: (100/8) * 0,5 * 1,05 (складність) * 1 (лояльність) * 1,17 (час) = 7,68 бала

У цьому випадку спочатку обчислюється стандартна кількість балів (100/8) * 0,5 = 6,25 і робиться поправка на складність та здачу раніше терміну. Т.к. клієнт проблем не доставляє, то коефіцієнт дорівнює одиниці.

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

Вася отримає: (100/8) * 0,5 * 1,05 (складність) * 1,15 (лояльність) * 0,8 (час) = 6,04 бала

Тут клієнт доставив Васі багато проблем при узгодженні, і Вася, засмутившись, наробив купу багів, тим самим зірвавши терміни дедлайн більш ніж на 20%. Хоча Вася й отримав надбавку і за складність, і за неадекватність замовника, зірваний дедлайн сильно зменшив кількість балів.

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

Вася отримає: (100/8) * 0,5 * 1 (складність) * 1,07 (лояльність) * 1 (час) = 6,69 бала

В цьому випадку для Васі немає жодної складності, замовник не дуже тиранить Васю, і Вася вклався в «запасні» 20% часу.

Від теорії до практики

Ще одна важлива проблема – зрив дедлайну понад 20%. Економічно логіка вірна: «Зірвав терміни? Отримуй штраф!» Але фактично людина і так морально виснажена цим проектом (дедлайни не просто так зриваються), а якщоце ще й позначиться на його зарплаті, то настрій на подальшу роботу буде нижчим за плінтус, а це студії невигідно.

Все не так погано

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

Крім того, ми вирішили, що кожен робочий день (незалежно від складності поточного проекту) оцінюватиметься у 0,5 бала, а якщо співробітник веде явно важкий проект, то після завершення проекту можна його стимулювати додатковою премією / вихідним / подарунком / грамотою та і т.д.

Залишається питання — як рахувати досвід нових співробітників, яких ми влаштовуємо до себе в компанію? Нечесно було б ставити їм «0», якщо людина вже досвідчена і готова вирішувати складні завдання. Ми вирішили піти найпростішим шляхом: після місяця випробувального терміну тих. директор чи арт-директор встановлюватимуть стартовий рівень нового співробітника, спираючись на свої суб'єктивні припущення.

Повертаючись до початкових завдань

Чесна заробітна плата. Завдання вирішено повністю та принципи збереглися.
Прозорість. Поки що жодний співробітник не мав проблем із розрахунком власної зарплати або схемами її нарахування.
Стимуляція підвищення кваліфікації. З'явилася пряма залежність між участю у складних проектах та отриманням бонусів.
Лояльність до студії загалом. Ми вирішили, що лояльність не повинна купуватись, і закрили це питання постійними спільними заходами.
Прогнозування заробітної плати. Див п.2
Кар'єрний ріст. Ми створили таблицю кар'єрного зростання. КоженСпівробітник бачить, скільки йому ще потрібно відпрацювати, щоб поставити питання про власне підвищення.
Соцзмагання. Петро хоче отримувати так само, як і Вася? Нехай попрацює позаурочно та швидко отримає Васин рівень.
Складність обчислень. Власне, складнощів не залишилося жодної. Співробітники заповнюють щодня табель обліку робочого часу (2 хвилини на день) і бачать, яку зарплату вони отримають наприкінці місяця, і чи буде «левів ап» мінімального фіксу.

Хотів би почути фідбек за запропонованою схемою. Як у ваших студіях працюють KPI?