Alex.Morozov
New member
Когда меня назначили CTO в небольшой продуктовой студии, я был уверен, что моя главная задача — это архитектура, код-ревью и найм. Про ставки я думал примерно так: есть зарплата разработчика, делим её на количество рабочих часов в месяце, вот и стоимость часа. Спустя полтора года, когда мы чуть не ушли в минус на крупном контракте, я понял, что эта арифметика была самой дорогой ошибкой моего первого года в роли.
Первое, что я сделал после разбора полётов, — сел и честно посчитал всё, что стоит за одним часом инженера. И знаете что? Зарплата там оказалась меньше половины. Сверху набегают налоги и взносы, оплачиваемые отпуска и больничные, техника, лицензии, доступы к облакам, рабочие места или коворкинг, обучение, а ещё время сеньоров на онбординг новичков и наставничество. Всё это никуда не исчезает, даже если конкретный клиент об этом не догадывается.
Второе открытие было ещё болезненнее: далеко не каждый рабочий час можно продать. Мы замерили две недели обычного спринта и выяснили, что чистого времени на задачи клиентов у команды около шестидесяти-семидесяти процентов. Остальное съедают планёрки, оценки, пресейл, внутренние созвоны, разбор инцидентов, ответы в чатах и постоянные переключения между задачами. Если считать стоимость часа от всех рабочих часов, вы автоматически дарите клиенту треть своего труда и даже не замечаете этого.
Дальше — математика, которую я теперь показываю каждому новому тимлиду. Допустим, разработчик получает на руки двести пятьдесят тысяч. С налогами, отпускными и рабочим местом для компании он стоит примерно четыреста пятьдесят тысяч в месяц. Продаваемых часов у него около ста десяти. Значит, себестоимость часа — порядка четырёх тысяч. Прибавляем маржу на риски, переделки, простой и развитие компании — и минимальная ставка выходит шесть-семь тысяч вместо трёх, которые мы когда-то стыдливо писали в коммерческом предложении.
Главные ошибки, которые я совершил сам и видел у коллег: гонка по самой низкой цене, скидки постоянным клиентам без пересмотра объёма работ, фиксированная цена без буфера на неопределённость, бесплатное участие руководителя в проекте и наивная вера в то, что загрузка будет сто процентов всегда. Ещё одна классика — считать время только программистов, забывая, что аналитика, дизайн, тестирование и управление проектом тоже чьи-то оплаченные часы.
Поэтому советую простой план. Заведите трекер и две-три недели честно фиксируйте, чем занята команда, включая встречи и переписку. Посчитайте реальную утилизацию, а затем выведите минимальную ставку, ниже которой работа превращается в благотворительность. Держите две цифры отдельно: внутреннюю себестоимость для управленческих решений и клиентскую ставку с маржой и риском. Пересматривайте обе раз в квартал, потому что зарплаты, налоги и рынок меняются быстрее, чем нам кажется. И обязательно предупреждайте клиентов о повышении ставок заранее, за месяц-полтора: со мной это ни разу не сработало плохо, а вот молчаливое терпение в убыток чуть не стоило нам компании.
А как у вас? Считаете ли вы себестоимость часа в своей команде или пока ориентируетесь на среднюю ставку по рынку? Поделитесь в комментариях формулой, которая реально работает у вас, — уверен, вместе мы соберём отличный чек-лист для всех, кто только заходит в роль CTO и не хочет учиться на своих ошибках!
Первое, что я сделал после разбора полётов, — сел и честно посчитал всё, что стоит за одним часом инженера. И знаете что? Зарплата там оказалась меньше половины. Сверху набегают налоги и взносы, оплачиваемые отпуска и больничные, техника, лицензии, доступы к облакам, рабочие места или коворкинг, обучение, а ещё время сеньоров на онбординг новичков и наставничество. Всё это никуда не исчезает, даже если конкретный клиент об этом не догадывается.
Второе открытие было ещё болезненнее: далеко не каждый рабочий час можно продать. Мы замерили две недели обычного спринта и выяснили, что чистого времени на задачи клиентов у команды около шестидесяти-семидесяти процентов. Остальное съедают планёрки, оценки, пресейл, внутренние созвоны, разбор инцидентов, ответы в чатах и постоянные переключения между задачами. Если считать стоимость часа от всех рабочих часов, вы автоматически дарите клиенту треть своего труда и даже не замечаете этого.
Дальше — математика, которую я теперь показываю каждому новому тимлиду. Допустим, разработчик получает на руки двести пятьдесят тысяч. С налогами, отпускными и рабочим местом для компании он стоит примерно четыреста пятьдесят тысяч в месяц. Продаваемых часов у него около ста десяти. Значит, себестоимость часа — порядка четырёх тысяч. Прибавляем маржу на риски, переделки, простой и развитие компании — и минимальная ставка выходит шесть-семь тысяч вместо трёх, которые мы когда-то стыдливо писали в коммерческом предложении.
Главные ошибки, которые я совершил сам и видел у коллег: гонка по самой низкой цене, скидки постоянным клиентам без пересмотра объёма работ, фиксированная цена без буфера на неопределённость, бесплатное участие руководителя в проекте и наивная вера в то, что загрузка будет сто процентов всегда. Ещё одна классика — считать время только программистов, забывая, что аналитика, дизайн, тестирование и управление проектом тоже чьи-то оплаченные часы.
Поэтому советую простой план. Заведите трекер и две-три недели честно фиксируйте, чем занята команда, включая встречи и переписку. Посчитайте реальную утилизацию, а затем выведите минимальную ставку, ниже которой работа превращается в благотворительность. Держите две цифры отдельно: внутреннюю себестоимость для управленческих решений и клиентскую ставку с маржой и риском. Пересматривайте обе раз в квартал, потому что зарплаты, налоги и рынок меняются быстрее, чем нам кажется. И обязательно предупреждайте клиентов о повышении ставок заранее, за месяц-полтора: со мной это ни разу не сработало плохо, а вот молчаливое терпение в убыток чуть не стоило нам компании.
А как у вас? Считаете ли вы себестоимость часа в своей команде или пока ориентируетесь на среднюю ставку по рынку? Поделитесь в комментариях формулой, которая реально работает у вас, — уверен, вместе мы соберём отличный чек-лист для всех, кто только заходит в роль CTO и не хочет учиться на своих ошибках!