Рейтинг розробників або Срібна куля професора Ело

Рейтинг та грейд майже синоніми, точно також і ця стаття дуже близька до циклу попередніх, в ній точно також зачіпається питання «який розробник повинен отримувати більше?». І в той же час вона стоїть особливо і люба мені особливо, так як в ній, крім короткої характеристики родових недоліків існуючих систем грейдінга, є багато позитиву:

наводиться принципово інший підхід, за аналогією, а також з точок зору об'єктивності, мінімальності витрат і швидкості отримання результатів;
представлено практичне застосування підходу на базі аналізу до 10 тисяч профілів українських фрілансерів на oDesk і Elance (наскільки мені відомо, вперше) та їх виконаних проектів більш ніж на 100 млн. грн. за поточний і минулі роки;
дано приклад, як швидко і маловитратних (7 днів і 4 долари) створити вкрай невимогливий до ресурсів альфа-прототип, придатний для старту будь-якого стартапу, та наведено перелік придатних для цього інструментів;
показаний ряд графіків, що характеризують стан і динаміку української фріланс-розробки.

Гори, що породили мишей

Ряд існуючих систем грейдів, розглянутих в циклі статей, а також європейська e-CF 2.0 (нічим принципово, крім більшої складності, не відрізняється, по суті, від тієї ж російської) справедливо критикуються за нечіткість критеріїв (дещо осібно стоїть O * NET, що використовує статистичний підхід, але вартість її підтримки перевищує дохід всього українського фріланса).

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

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

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

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

Хелло, Ело!

Від проблем, пов'язаних з «прокрустовим ложем махрового суб'єктивізму», чимало страждали і шахові гросмейстери в XIX і XX століттях. Наприклад, на кращі турніри гросмейстерів відбирали виключно за симпатіями і суб'єктивну думку про силу шахістів організаторів. Навіть в матчах за звання чемпіона світу творилося повне неподобство. Той же геніальний Капабланка, будучи в ранзі чемпіона світу, довго уникав матчу з Алехіним, віддавши перевагу обламати старі зуби Ласкеру. Альохін згодом відплатив Капе тією ж монетою і навіть подвійно, назавжди позбавивши світ видовища «битви титанів».

У 50-х роках 20 століття професор Ело розробив систему рейтингів на статистичній основі, в якій лежало припущення, що сила гравця може бути виражена змінної, що підкоряється закону нормального розподілу.

Ця система стала основою для відбору гравців на найбільші і найпрестижніші шахові турніри і практично усунула проблеми, пов'язані з суб'єктивним добором гравців на турніри (читай, проекти), тобто виявилася дійсно «срібною кулею». Приміром, Карпов і Каспаров не змогли повторити трюки Капабланки і Альохіна і були змушені битися за звання чемпіона на протязі 7 років у 5-ти матчах.

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

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

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

Рейтинг чи сеанс магії з наступним викриттям

Якщо шахісти змагаються у кількості набраних очок, а в командних видах спортсмени борються за гол + пас або підбори, кидки і т.д., то за що конкурують розробники?

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

Однак поставимо себе на місце замовника, підшукувати для свого, до прикладу, веб-проекту виконавця хорошого середнього рівня. Хіба йому потрібно знати, скільки заробив виконавець, адже йому потрібно «лише» вибрати на тлі інших? Скаже йому щось сума в якості рейтингу? Навряд чи, оскільки йому доведеться вивчити списки тих, хто заробив більше і менше. Скаже йому щось вказівку "101 місце з 1000«? Також навряд чи, оскільки можливо, що 900 взагалі виконували раніше епізодичні, копійчані замовлення.

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

Для спроби вирішення можна було б виводити частку суми замовлень розробника в загальному обсязі, але при великому числі учасників не дуже то зручно мати рейтинг типу 0,00001%. Як варіант, ввести масштабування від порядку числа учасників рейтингу, тобто якщо тисячі, то множити відсоток частки на тисячу, якщо сотні - на сотню. Але це все одно не вирішує завдання співвіднесення значення рейтингу учасника з рештою без вивчення всього списку рейтингу.

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

При виконанні проекту в більшості випадків розробнику (як і замовнику проекту - від розробника) потрібно кілька технічних навичок. Приміром, PHP, MySQL, jQuery, HTML, CSS. Як визначити вагу кожного навику? Для цього є емпіричні правила Парето, його похідної ABC, гуглівського правила топ-5 і т.д.

Найбільш простим методом наближення буде призначення навичкам ваг в порядку, зворотному порядку вказівки. Тобто у наведеному прикладі PHP отримає 5 балів, CSS - 1 бал і, відповідно, при розрахунку рейтингу навик PHP «отримує з бюджету» 33,3% (5 з 15), а jQuery - 20%. Таким чином можна отримати рейтинг і по навичкам.

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

Можна зауважити, що така система обліку цілком застосовна всередині окремої компанії.

Далі наведено опис конкретної реалізації такого рейтингу в застосуванні до українських фрілансерам на oDesk і Elance.

7 днів і 4 долари на прототип для стартапу

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

На щастя, мене цікавила перевірка річного безкоштовного аккаунта на AWS, а також твіттеровскій 12-стовпчик bootstrap та можливості засобів візуалізації від Google. Придалися і сервіс Loginza і фейсбучное API для коментарів (переважний варіант з суміщенням коментарів Facebook, Google, ВКонтакте в єдиному блоці відкинутий за тимчасовими міркувань). З урахуванням вимог мінімалізму, високої гнучкості, скромних ресурсів хостингу і швидкості розробки був використаний примітивний php-шаблонізатором і база sqlite, тобто будь-яка CMS не підходила спочатку.

У підсумку за 7 днів (якщо бути точним, то і частини ночей) і 4 долари (витрачених на домен, який можна було спробувати отримати і безкоштовно в зоні org.ua ) вийшло «сируватий», але непогане, на мій смак, інтерактивне додаток до статті. Яке також може послужити і тестом для визначення «потужності» тріал-хостингу на базі AWS (попередні тести вселяють надію, що кілька десятків одночасних запитів не створять серйозних проблем, не дивлячись на досить слабкі, як для VPS, характеристики).

Варто додати, що у такого рішення є істотний резерв оптимізації у вигляді використання амазоновского CDN для статики та nginx `а перед Апачі (з власного досвіду це якщо і не срібна куля, то як мінімум бронзова у вигляді фронту досить навантажених веб-проектів ).

Ось лише мала частина матеріалів (природно, підготовлених в інші терміни) з цього «інтерактивного» додатка до статті :

Вже кінець

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

Щось подібне відчув і я після майже дворічної епопеї (яка стала чимось на зразок хобі) в пошуках найкращого (з точок зору об'єктивності, мінімуму витрат і максимуму швидкості) методу визначення рівня розробника. Очевидно, що запропонований метод не є абсолютним ідеалом, однак:

при уважному погляді очевидно, що користуються заслуженою популярністю зарплатні опитування на ДОУ є приватним, спрощеним випадком методу (з меншою частотою вибірки, меншим числом параметрів і рівнем достовірності). І це не реверанс, а висновок post factum. ДОУ йде вірною дорогою і виграє 5:0 у будь-який інший методики визначення ринкових зарплат;
даний метод може бути застосований в будь-якій компанії для складання динамічного внутрішнього рейтингу розробників;
його корисна практичність доведена, на думку автора, складанням рейтингу фрілансерів
може бути корисним і приклад дуже швидкої і маловитратної розробки альфа-прототипу стартапу з переліком використаних інструментів;
додаткова аналітика (побічний продукт) по структурі українського фріланса також, по моєму, цікава. Причому вперше, наскільки мені відомо, аналізуються інтегровані дані по oDesk і Elance.

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

І, як водиться при завершенні такої тривалої епопеї, слова подяки:

спільноті ДОУ і, особливо, всім, що висловили конструктивні критичні зауваження і підтримали своїм інтересом до теми;
ДОП, предоставившему без всякого диктату можливість і підтримку публікації циклу, а також персонально Максу Іщенко, як автору первісної постановки питання і як засновнику ресурсу, і Андрію Дегелеру, як уважному, лояльному до авторів і позитивно налаштованому головному редактору.

Опубліковано: 12/09/12 @ 09:37
Розділ Різне

SEO Блог