Однажды мне на глаза попалось исследование о том, какую цену предлагают наши конкуренты за те же самые услуги и работы, что и мы. И эти данные были неприятными: мы были заметно дороже. Чтобы сохранить заказы и удержать позиции, нам были нужны перемены.
Забегая вперед, скажу, что в итоге мы перестроили свою работу. Причем, не только понизив издержки, но и повысив зарплаты программистам. Как – читайте под катом.
Первым делом решили понять структуру трудозатрат в проекте. Все работы в проекте были разбиты на отдельные блоки. У каждого блока известна его оценка, est, которую проставляет ведущий разработчик, и потраченное программистом время, spent. Определили «скорость работы программиста» как отношение (сумма est) / (сумма spent), и посчитали этот показатель для одной команды на одном проекте. Получилась таблица:
В глаза бросается разброс по скоростям. Откуда он берется? Может быть, погрешность эксперимента? Сначала я подумал, что разным девелоперам достаются задания разной сложности. Поэтому я привел таблицу для одного проекта – где работы были похожи между собой. Также, выборка дана для одной команды, где у всех программистов был одинаковый доступ к информации о проекте, одинаковые возможности для коммуникаций и получения помощи от техлида и т. д. На всякий случай, аналогичные таблицы построили для других проектов и других команд, и убедились: разброс присутствует и там.
Как я потом убедился, такой большой разброс – нетривиальный факт для не-программистов. Чтобы подкрепить доказательную базу перед беседой с руководством, я решил почитать, что говорят на сей счет эксперты по разработке ПО. В книге С. Архипенкова нашел упоминание про разброс в производительности. Аналогично высказался и А. Орлов в книге Секреты управления программистами.
А в книге Джоэла Спольски нашел интересные данные об исследовании, проведенном Стэнли Айзенштатом, профессором из Йельского университета. На протяжении нескольких лет студентов просили сообщать, сколько времени они потратили на выполнение домашних заданий по программированию. Вот некоторые из результатов:
Приведенных выше примеров достаточно, чтобы утверждать: наблюдавшийся в наших проектах разброс по скоростям не является особенностью, и уже тем более ошибкой, ведения проектов в нашей компании. Это объективная особенность профессии программиста, с которой надо считаться.
Итак, вернемся к нашей задаче: сокращение расходов при ведении проектов. Из моей самой первой таблички следует, что разброс по скоростям был шестикратным. А разброс зарплат внутри этой команды (отношение максимальной ставки к минимальной) был около 2. Таким образом, если мы выдаем работу программисту N, мы заплатим за нее в 3 раза больше, чем в случае, когда выдаем ту же самую работу программисту #1.
Вывод напрашивается сам собой: чем больше доля сильных программистов в проекте, тем дешевле он будет сделан. Значит, надо нанимать новых сильных разработчиков, удерживать уже работающих опытных ребят. Причем, это не означает полный отказ от сотрудников уровня junior: во-первых, всегда есть простые задачи, которые кому-то надо делать, а во-вторых, перспективный junior со временем вырастет в middle’а.
Однако, одно дело – составить таблицу и сделать выводы для себя. Другое дело – донести идею до руководства и убедить его в своей правоте.
Как я сказал в самом начале статьи, действие разворачивалось на фоне конкурентной борьбы и снижения издержек (экономии). Обычно в такой ситуации в офисе речи не идет о повышении зарплат — начинается тотальная экономия (ну надо же как-то снижать цену?!).
Так что идея о повышении ставок + о поднятии зарплатной планки в вакансии о найме на работу выглядела, мягко говоря, неожиданно.
Давайте посмотрим, как оплачивается работа, скажем, каменщика на стройке. Его зарплата чаще всего пропорционально зависит от выработки: поработал в 2 раза быстрее, получил в 2 раза больше денег. Аналогично ситуация, скажем, у водителя маршрутки: быстрее ехал, больше пассажиров в единицу времени подобрал, больше денег собрал. Честно и справедливо (хотя и небезопасно).
Такой подход по умолчанию сидит в головах многих людей, не только менеджеров. Поэтому когда ПМ-неайтишник видит, что зарплата мидла на K% выше, чем у дева – он думает, что мидл работает примерно на K% быстрее. Значит, система линейна: 2 чел по $1000 = 1 чел по 2000. И совершенно непонятно, зачем делать упор на «сильных сотрудников». Тем более, что в работе с ними есть определенные «неудобства».
По моим наблюдениям, чем выше уровень программиста, тем больше требований он предъявляет к качеству того продукта, над которым работает. Если зеленый новичок доволен уже тем, что создал работающий фрагмент кода, который попал в продукт – то более опытные его коллеги задаются вопросами: почему мы используем эту технологию, а не другую? Что реально клевого реализовано в продукте? Чем мы лучше конкурентов? На практике, это выливается в то, что разработчик просит включить его в проект поинтереснее и высказывает недовольство, если ему хронически достается примитивная работа. Или отказывается строить код «быстренько из костылей», а требует себе время на нормальную разработку.
Иногда по ошибке такое поведение классифицируется как «звездная болезнь». И при такой формулировке действительно лучше работать с новичками, чем с опытными прогерами.
В конце концов, информация была донесена до руководства, а предложенные реформы были проведены: работаем практически только с сильными программистами. В итоге, мы получили следующее:
И дело не только в денежных показателях – по мере того, как ситуация разъяснялась руководителям среднего звена и топам, менялось и их отношение к разработчикам и профессии программиста.
Забегая вперед, скажу, что в итоге мы перестроили свою работу. Причем, не только понизив издержки, но и повысив зарплаты программистам. Как – читайте под катом.
Исследование
Внутренний анализ
Первым делом решили понять структуру трудозатрат в проекте. Все работы в проекте были разбиты на отдельные блоки. У каждого блока известна его оценка, 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%.
И дело не только в денежных показателях – по мере того, как ситуация разъяснялась руководителям среднего звена и топам, менялось и их отношение к разработчикам и профессии программиста.