Компания
29,18
рейтинг
10 ноября 2010 в 12:40

Разное → Об экономии денег в проекте

Однажды мне на глаза попалось исследование о том, какую цену предлагают наши конкуренты за те же самые услуги и работы, что и мы. И эти данные были неприятными: мы были заметно дороже. Чтобы сохранить заказы и удержать позиции, нам были нужны перемены.

Забегая вперед, скажу, что в итоге мы перестроили свою работу. Причем, не только понизив издержки, но и повысив зарплаты программистам. Как – читайте под катом.


Исследование


Внутренний анализ

Первым делом решили понять структуру трудозатрат в проекте. Все работы в проекте были разбиты на отдельные блоки. У каждого блока известна его оценка, est, которую проставляет ведущий разработчик, и потраченное программистом время, spent. Определили «скорость работы программиста» как отношение (сумма est) / (сумма spent), и посчитали этот показатель для одной команды на одном проекте. Получилась таблица:
Разработчик «Скорость»
1 1,61
2 1,55
N-1 0,31
N 0,26

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

Данные из внешних источников

Как я потом убедился, такой большой разброс – нетривиальный факт для не-программистов. Чтобы подкрепить доказательную базу перед беседой с руководством, я решил почитать, что говорят на сей счет эксперты по разработке ПО. В книге С. Архипенкова нашел упоминание про разброс в производительности. Аналогично высказался и А. Орлов в книге Секреты управления программистами.
А в книге Джоэла Спольски нашел интересные данные об исследовании, проведенном Стэнли Айзенштатом, профессором из Йельского университета. На протяжении нескольких лет студентов просили сообщать, сколько времени они потратили на выполнение домашних заданий по программированию. Вот некоторые из результатов:
Проект Среднее Минимум Максимум Отклонение
COMPRESS00 33,83 11,58 77,00 14,51
COMPRESS99 27,47 6,67 69,50 13,62
TEX00 21,22 6,00 75,00 12,11

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

Рецепт

Итак, вернемся к нашей задаче: сокращение расходов при ведении проектов. Из моей самой первой таблички следует, что разброс по скоростям был шестикратным. А разброс зарплат внутри этой команды (отношение максимальной ставки к минимальной) был около 2. Таким образом, если мы выдаем работу программисту N, мы заплатим за нее в 3 раза больше, чем в случае, когда выдаем ту же самую работу программисту #1.
Вывод напрашивается сам собой: чем больше доля сильных программистов в проекте, тем дешевле он будет сделан. Значит, надо нанимать новых сильных разработчиков, удерживать уже работающих опытных ребят. Причем, это не означает полный отказ от сотрудников уровня junior: во-первых, всегда есть простые задачи, которые кому-то надо делать, а во-вторых, перспективный junior со временем вырастет в middle’а.
Однако, одно дело – составить таблицу и сделать выводы для себя. Другое дело – донести идею до руководства и убедить его в своей правоте.

Почему сложно убедить руководство работать с более дорогими программистами?


Психологический барьер

Как я сказал в самом начале статьи, действие разворачивалось на фоне конкурентной борьбы и снижения издержек (экономии). Обычно в такой ситуации в офисе речи не идет о повышении зарплат — начинается тотальная экономия (ну надо же как-то снижать цену?!).

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

Поверхностный взгляд на проблему

Давайте посмотрим, как оплачивается работа, скажем, каменщика на стройке. Его зарплата чаще всего пропорционально зависит от выработки: поработал в 2 раза быстрее, получил в 2 раза больше денег. Аналогично ситуация, скажем, у водителя маршрутки: быстрее ехал, больше пассажиров в единицу времени подобрал, больше денег собрал. Честно и справедливо (хотя и небезопасно).

Такой подход по умолчанию сидит в головах многих людей, не только менеджеров. Поэтому когда ПМ-неайтишник видит, что зарплата мидла на K% выше, чем у дева – он думает, что мидл работает примерно на K% быстрее. Значит, система линейна: 2 чел по $1000 = 1 чел по 2000. И совершенно непонятно, зачем делать упор на «сильных сотрудников». Тем более, что в работе с ними есть определенные «неудобства».

«Звездная болезнь»

По моим наблюдениям, чем выше уровень программиста, тем больше требований он предъявляет к качеству того продукта, над которым работает. Если зеленый новичок доволен уже тем, что создал работающий фрагмент кода, который попал в продукт – то более опытные его коллеги задаются вопросами: почему мы используем эту технологию, а не другую? Что реально клевого реализовано в продукте? Чем мы лучше конкурентов? На практике, это выливается в то, что разработчик просит включить его в проект поинтереснее и высказывает недовольство, если ему хронически достается примитивная работа. Или отказывается строить код «быстренько из костылей», а требует себе время на нормальную разработку.

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

Что же получилось в итоге?


В конце концов, информация была донесена до руководства, а предложенные реформы были проведены: работаем практически только с сильными программистами. В итоге, мы получили следующее:
  • средняя ЗП сильных программистов в коллективе выросла более чем на 50%;
  • средние затраты на блок работ снизились на 50%.

И дело не только в денежных показателях – по мере того, как ситуация разъяснялась руководителям среднего звена и топам, менялось и их отношение к разработчикам и профессии программиста.
Автор: @BashStalk
Competentum
рейтинг 29,18
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Комментарии (41)

  • НЛО прилетело и опубликовало эту надпись здесь
    • +1
      На момент событий, описанных в статье, работал руководителем группы программистов.
      • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        а сейчас?
        • +1
          рук отдела
  • +1
    Спасибо за опыт, давно было подобное ощущение, но до исследования все руки не доходили.

    Вы пробовали анализировать корреляцию «продуктивности» специалиста с годами работы в должности, годами работы в компании или какими-то другими факторами?
    • +1
      Кхе… знал бы прикуп — жил бы в Сочи :) Четкого ответа у меня нет. Есть наблюдения. Скорость освоения информации — этот параметр заметен уже через пару месяцев совместной работы. Если параметр высокий — то выход на высокую «продуктивность» в проекте получается довольно быстро. Если же скорость освоения информации низка — то события в проекте и в мире технологий будут происходить быстрее, чем человек подстроится под них… в таком печальном случае, скорее всего, человек неправильно выбрал профессию.

      • +1
        К вопросу о том, в чем причина разброса в продуктивности — покопался в книге Джоэла Спольски, на 95-й странице нашел абзац:
        «Пятнадцатилетний опыт программирования убедил меня в том, что все лучшие программисты способны легко разбираться сразу с несколькими уровнями абстракции. По отношению к программированию это означает, что у них нет проблем с рекурсией… или со сложными алгоритмами… Я пришел к выводу, что понимание указателей — это не квалификация, а способность. „
  • +2
    > У каждого блока известна его оценка, est, которую проставляет ведущий разработчик, и потраченное программистом время, spent.

    смущает немного такая оценка. не могу сейчас четко сформулировать, но что-то тут не то.

    ведь разработчики работают во взаимодействии друг с другом. а значит, еще важна структура команды… как-то так.
    • 0
      В описанном примере точная оценка и не нужна: даже если погрешность оценки 50%, шестикратный разброс в скорости такая погрешность не объяснит.

      А вообще, повышение точности оценки, а также целесообразность получения такой точной оценки — тема для отдельной статьи.
  • 0
    Спасибо, интересно очень
  • +17
    >> работаем практически только с сильными программистами.

    То есть вы уволили часть программистов. Почему об этом не написано прямо?
    Тогда вся статья свелась бы к одному предложению: «уволили тех, кто работает меньше, сэкономили 100%, половину сэкономленных средств отдали тем, кто остался».
    • +10
      Оставшиеся в радостном испуге начали нажимать на кнопки еще активнее.
    • 0
      Я не сомневаюсь, что статья для некоторых читателей Хабра очевидна. Ну а теперь попробуйте объяснить то же самое не-программисту. И Вы услышите вопросы: а чем программисты такие особенные? почему все профессии как профессии, а программисты вечно ворчат о своей уникальности? ))) Вот статья о том, как я искал эти аргументы, и почему не так просто их донести.

      • НЛО прилетело и опубликовало эту надпись здесь
        • +1
          Значит, мне придется Вас разочаровать: оплата каменщика чаще всего именно сдельная. Это действительно приводит к халтуре. Качество формально проверяется, но халтура остается. К счастью, несущие конструкции в крупных зданиях не держатся на кладке.
        • +1
          Возвращаясь к теме оценки «скорости» программиста. На моей практике, сотрудник, который сначала пишет «костыли», а потом дорабатывает изначально неверно написанный код, тратит в сумме больше времени, чем сотрудник, который сразу пишет правильно.
          • НЛО прилетело и опубликовало эту надпись здесь
        • +1
          В идеале считается, что качество кладки не зависит от каменщика, вернее что оно не ниже требуемого ТЗ, СНиПами и т. п. В строительстве качество обычно легко можно проверить на соответствие требованиям, да и сами требования чётко формализованы (например, статическая или динамическая нагрузка) и квалификация (а значит и сдельная зарплата) каменщика напрямую зависит от скорости работы. Качество кода же или архитектуры субъективное понятие, практически не формализуемое, да и ситуативное, в одном случае важно оптимизация производительности, в других сложность расширения функционала.
  • 0
    Думается, что прозрачная и понятная система формирования оплаты будет еще и хорошей мотивацией служить, что в свою очередь тоже будет влиять на результат.
    • +1
      ошибочный подход к мотивации в интеллектуальной деятельности
      • 0
        Я всего лишь говорил о том, что мотивации прибавится от того, когда понимаешь как оценивается твоя результативность и что ее вообще оценивают. А не так во многих компаниях прибавляют зарплату всем примерно одинаково. Я это писал не с позиции менеджера, а как разработчик. С позиции, что для опытных разработчиков такая оценка их труда принесла реальную прибавку к зарплате, и уверен, что это не могло не повлиять на мотивацию.
        • +1
          Награда губительная для творчества
          habrahabr.ru/blogs/arbeit/69569/
          • +1
            Отсутствие награды ещё более губительно.
            • +1
              Понятное дело, что вознаграждение должно быть. Дело в деталях:
              1) бывает стабильно высокая зарплата,
              2) бывает агрессивная система финансовой мотивации (низкая ЗП — высокие бонусы по достижении бизнес результата).

              Речь идет о том, что для творчества 1-й подход лучше, чем 2-й.
  • 0
    Рекомендую почитать Элию Голдратта, начните с книги «Цель». Очень интересно, каких результатов вы сможете достичь применяя теорию ограничений.
  • 0
    процент от проекта ключевым сотрудникам в разы увеличивает производительность и качество продукта

    производительность ведь может падать даже у сильных работников и совсем по разным причинам не касающихся работы
    а вот когда он имеет в месяц 10000 рэ а все остальное это процент с проектов, то тут хочешь не хочешь а работать надо будет ежедневно в тонусе
    • +4
      Лучше паспорт забирать. А выдавать только в случае успешного окончания проекта.
  • +1
    А качество кода как учитывать? Я сейчас даже не о багах, а о той же масштабируемости.
    Лично сталкивался с прораммистами, которые именно очеь-очень быстро лепили всё из костылей — и оно даже кое-как работало.
    А потом через месяц нужно что-то сбоку прикрутить, и понимаешь, что нужно всё выкинуть и написать с нуля.
    • 0
      Думаю кадры должен подбирать человек, который владеет знаниями и идеями архитектуры и в период вникания нового человека (ведущего разработчика) смотреть за качеством и за тем, как человек понимает/перенимает стиль и идею. Думаю если не запускать первый месяц-полтора проект — можно держать в голове решения и оценивать/корректировать их.
      • +1
        Отчасти верно, конечно.
        Но есть такие люди, это просто склад мышления такой — быстрее, примитивнее, «в лоб» и на отъе*ись. Даже если стоять за спиной с палкой и тыкать пальцем в шаблоны, помогает лишь частично. Всё равно качество не дотягивает до уровня вдумчивых и аккуратных коллег. И стоит через какое-то время ослабить контроль — идёт неизбежный откат к старому.
        Но если взять по ним узкий статистический срез, не видя всей картины — они нередко чемпионы по скорости.
        • 0
          Ну, если они дают на выходе рабочий и вменяемый код, то такие работники полезны, когда поджимают сроки. Примитивный код часто имеет свои преимущества (читабельность, скорость работы), а шаблоны — не законы, а рекомендации, их применение везде и всюду тоже не всегда полезно. Так что надо не стоять над ними с палкой, а подбирать им соответствующую работу. В конце концов, одноразовый код типа write only (когда не важны ни скорость работы, ни удобство поддержки и расширения, лишь бы работал) тоже часто бывает нужен.
  • 0
    Угу, есть такое. Поэтому статистику лучше считать по окончании проекта (ну или хотя бы за длительный интервал времени, чтобы снизить роль стат флуктуаций).
  • –1
    извините, не совсем понял математику.
    вы осуществили декомпозицию задачи на равные блоки.
    вы вручили блоки с разной специализацией (где-то ближе к ядру, где-то ближе к gui) соответственно талантам программистов — как бы вроде бы исходя из критерия «специалист K сделает блок со спецификой X быстрее других в команде»
    так что ли?
    какие ещё детали и методы?

    просто в статье только и видно, что «лид-программер щёлкает плоские блоки толпами и быстро, так что ядро оставили нубам». это заставляет думать, что вы не смогли донести и раскрыть метод.
    • 0
      наверное, я не очень понял ваш вопрос.

      Вообще, речь шла о том, что нубов в команде должно быть поменьше.
  • –1
    ]]] Давайте посмотрим, как оплачивается работа, скажем, каменщика на стройке. Его зарплата чаще всего
    ]]] пропорционально зависит от выработки: поработал в 2 раза быстрее, получил в 2 раза больше денег.
    Опять старая ошибка. Аналогично и программированию, объём результата не пропорционален пользе.
    Если каменщик выложит высокую стену (больше сколько-то рядов) пока не затвердеет предыдущее, на следующий день стену надо сносить и делать заново, ибо она уедет.
    Программист аналогично, если он написал за час 10кб кода то за 2 часа он мог спланировать приложение лучше и написать 5 килобайт кода которые работают в 10 раз быстрее и которые поддерживать в 30 раз дешевле, и на исправление багов в котором уйдёт в 50 раз меньше времени (а значит и денег)
    • +1
      Думаю, качество кода тоже проверяется. А вот подход, когда оплата идет _только_ за качество (и неважно, сколько времени займет разработка, пусть весь мир подождет), приводит к плохим последствиям. Если продолжать аналогию с каменщиками — то вы на стадии котлована отдали миллион за квартиру, чтобы через 1.5-2 года въехать в нее, а пока снимаете, и платите ого-го сколько в месяц. И вот проходят два года, вы приезжаете… а там по прежнему котлован. Но видели б вы этот котлован! Стеночки гладенькие, на дне — ни одного окурка, само дно по уровню выровнено…
      • 0
        Это само собой, ибо есть простая формула где время = деньги, но есть и порог целесообразности. Не выгодно строить дом 100 лет, но в тоже время за месяц дом хороший не построишь. (А плохой не продашь Дорого)

        Я лишь призываю более широко смотреть на продуктивность и на эффективность, эти вещи связаны конечно, но это ни в коем случае не одно и тоже. (Уж слишком часто я встречаюсь с таким заблуждением.)
  • 0
    Автор, а вы бы еще привели наглядную статистику, сколько было народу, сколько они получали (в процентном отношении от самой маленькой з/п). До и после сокращения.
    • 0
      Поддерживаю интерес к вопросу

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разное