?

Log in

No account? Create an account

serge_gorshkov


Сергей Горшков - о бизнесе в сфере ИТ

о семантической интеграции, программировании, управлении...


Previous Entry Share Next Entry
Сколько стоит час работы программиста?
serge_gorshkov

Недавно прочитал в «Русском Репортере» статью о тайм-бэнкинге. Идея состоит в том, что люди разных профессий обмениваются услугами, при этом стоимость часа работы у людей любых профессий считается одинаковой. То есть, если сантехник меняет вам трубы, а вы готовите его детей к экзамену по математике, вы должны ему ровно столько же часов занятий, сколько он потратил на замену труб. Получается практическое воплощение идеи «каждому по потребностям, от каждого по способностям».

Для всех ИТ-компаний стоимость часа работ является актуальным и больным вопросом. Мы интуитивно считаем, что наши работы стоят дороже, чем, скажем, услуги парикмахера; однако на практике часто получается наоборот. Среди наших клиентов на этот счет также существуют полярные мнения.

Короче говоря, стоимость часа в сфере услуг крайне сложно обосновать фактически, и в итоге она определяется скорее балансом спроса и предложения, а также самооценкой того, кто эти услуги оказывает. Дальше я постараюсь проанализировать факторы, влияющие на стоимость услуг по разработке программных продуктов, а также доказать, что, выражаясь языком народной мудрости, «кроилово ведет к попадалову».

Итак, во-первых, говорить нужно о двух ипостасях стоимости часа: себестоимости, то есть той сумме, которую компания прямо или косвенно тратит на обеспечение работы программиста, и отпускной цены, которую за этот час платит клиент. Разность между ними составляет, понятное дело, прибыль компании, а также формирует фонд, из которого компания финансирует свое развитие. Интуитивно кажется, что в случае дорогих услуг (например, в элитной парикмахерской) прибыль может быть очень существенной. В конце поста я привожу детальный расчет себестоимости и отпускной цены труда программиста для нашей компании; пока скажу лишь, что «чистая» себестоимость труда самого программиста (без учета других сотрудников, задействованных в проекте) составляет 670 рублей за час, а отпускная цена равна 1500-2000 рублям за час. При этом фактическая норма чистой прибыли, заложенная в отпускной цене, равна 20% (подробности ниже).

А сейчас предлагаю пофилософствовать на тему того, как может изменяться отпускная цена, и каким образом поставщик и заказчик услуг должны прийти к соглашению о цене. Все мои рассуждения имеют смысл только для рынка разработки (или внедрения) корпоративного ПО под заказ, и относятся только к тому компоненту стоимости ПО, который отражает выполняемые работы.

Понятно, что и Заказчик, и Подрядчик преследуют свою коммерческую выгоду. Если основываться на идеях Маркса, то получится, что программист своим трудом создает прибавочную стоимость, которая позволяет его хозяину-эксплуататору (компании-Подрядчику) получить прибыль. Пусть Подрядчик продает труд программиста, выраженный в его результате – программном продукте, Заказчику за сумму X. Подрядчик тратит на выполнение работ сумму Y, которая меньше X, и таким образом получает прибыль, равную X-Y. Программист приложит усилия, за которые получит некую сумму, являющуюся функцией от Y, и в результате его трудов будет создана та самая прибавочная стоимость, которая будет слагаемым в значении (X-Y), и обеспечит прибыль Подрядчику.

С позиций теории Адама Смита, ценность программного продукта для Заказчика (назовем ее Z) должна определяться исходя из того, какое количество труда своих сотрудников он сэкономит в результате его использования (зная стоимость этого труда и планируемый срок окупаемости, нетрудно рассчитать предельную цену, которую Заказчик будет готов заплатить за продукт).

Понятно, что если Z < X, то Заказчик просто не будет заказывать продукт. А если Z > X, то Заказчик сэкономит деньги, и фактически получит прибыль сверх запланированной. На практике та цена, на которой сойдутся Заказчик и Подрядчик, лежит где-то между X и Z, и зависит от качества менеджерских усилий с обеих сторон (а также от сроков, бренда, конкуренции и т.п.).

Цену разработки, устанавливаемую для Заказчика (X), логичнее рассматривать с точки зрения теории предельной полезности. Поскольку на рынке разработки корпоративного ПО, при его текущем состоянии, спрос существенно превышает предложение, редкость услуги существенно влияет на ее стоимость. Она является тем фактором, который двигает цену сделки от значения X вверх к Z. Конечно, ни одному Заказчику не захочется переплачивать за продукт, который «объективно» (то есть с позиций марксистской теории, которая на интуитивном уровне крепко сидит у многих из нас в мозгах) этих денег не стоит. Экономный Заказчик попробует найти поставщика, который сделает то же самое, но подешевле. Такой подход ведет к ситуации, которая сейчас сложилась на рынке разработки сайтов: заборы пестрят объявлениями о создании сайтов за 3000 руб. и меньше, то есть себестоимость труда разработчика потенциально стремится к нулю (как и стоимость производимых ими продуктов). Это очень усложняет жизнь тем, кто делает сайты за более адекватные деньги.

Теперь обратимся к нашей практике. В 2006-2008 годах, выходя на рынок с новым продуктом (CRM), мы установили минимальную цену на услуги по его доработке, поскольку испытывали необходимость в наборе первоначального количества клиентов. Затем, в 2009-2010 годах, мы сохраняли невысокие цены, стремясь расширить долю рынка за счет тех клиентов, которым при иных условиях CRM-система с индивидуальной доработкой была бы просто не по карману (конкурировали с отсутствием потребления). Эта политика принесла свои плоды в плане количества внедрений, но с экономической точки зрения привела к необходимости экономить на программистах, а именно – максимизировать количество разработчиков (для удовлетворения растущего спроса) при минимизации их стоимости. Естественно, это не могло не сказаться на качестве персонала. Наряду с действительно хорошими программистами (которые работают у нас и по сей день), в компанию приходило множество людей, которые обладали нужными техническими навыками, но по тем или иным причинам не могли (иногда и не хотели) эффективно работать. В результате получалось следующее:

  • Программисты не укладывались в запланированные сроки выполнения заданий, рассчитанные на их более «организованных» коллег.
  • Продажи совершались опережающими темпами, благодаря невысоким ценам; в результате образовывалась очередь заданий и неудовлетворенные клиенты, ждущие своей очереди.
  • Клиенты, чьи проекты за небольшие деньги попали не самым лучшим программистам, также были недовольны качеством работ.
  • Даже после завершения таких проектов приходилось тратить лишние ресурсы (деньги и время) на их поддержку. При качественной реализации проекта с самого начала таких проблем бы не возникало.

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

Возникает вопрос, куда двигаться дальше. Как я уже говорил, основная проблема рынка разработки ПО – это недостаток квалифицированных кадров. Проще говоря, мы не можем наращивать количество хороших разработчиков, потому что их физически очень мало, их не получается даже перекупить (об этом я как-нибудь напишу отдельный пост). Следовательно, мы ограничены тем производственным ресурсом (N*154 часа в месяц), который имеется в нашем распоряжении, с небольшим плюс-минусом. С экономической точки зрения это означает, что потолок доходности нашего бизнеса по разработке ПО известен, и мы не можем рассчитывать на его увеличение (что для любого бизнеса звучит просто ужасно). Точнее, могли бы – путем дальнейшего повышения цены, путешествия вверх по кривой зависимости количества заказов от цены за час. Другая возможность обеспечить развитие бизнеса – вкладываться в разработку собственных проектов (например, тиражных решений, то есть продавать не рабочие часы, а лицензии), у которых принципиально иная экономика, и соотношение между вложениями и прибылью. Для этого, опять же, необходимо сократить число коммерческих заказов, чтобы высвободить разработчиков, а сделать это можно только путем дальнейшего повышения цен.
Такой путь чреват потерей репутации (ведь придется как-то объяснить новое повышение цен и существующим клиентам), поэтому мы по нему не идем. Пока не идем.

Выводы? Главный вывод состоит в следующем: оценивать стоимость услуги нужно с позиций ее ценности для заказчика, а не себестоимости. Кроме того, покупая услугу, надо быть готовым к тому, что зависимость качества от цены имеет нелинейный характер. То есть, небольшое повышение качества услуги может привести к серьезному повышению ее стоимости. А дальше уже дело каждого конкретного Заказчика – решить, нужно ли ему это качество, или он готов повысить свои будущие риски ради экономии.

В заключение поста хочу поздравить всех, кто работает, с Праздником Труда – 1 мая :)


Приложение

А теперь вернемся к началу, и попробуем рассчитать себестоимость и отпускную цену труда программиста. Стартовым компонентом себестоимости является, конечно же, зарплата. Предположим, что программист получает «на руки» 50 т.р. в месяц. С учетом налоговой нагрузки, при использовании льготного налогового режима, затраты для предприятия на его зарплату составят 71 т.р. Все-все-все затраты на офис, уборщиц, бухгалтера, электричество, амортизацию оборудования не превышают 10 т.р. в месяц на сотрудника (по крайней мере у нас). Сложив ее с предыдущим результатом, и немного округлив, получим сумму в 80 т.р. Теперь разделим ее на 154 часа (да, у нас 7-часовой рабочий день), получим цифру 520 рублей в час. Можно ли «накрутить» на нее прибыль, и продавать по такой цене час клиенту? Конечно же, нет. То есть, когда-то совсем давно мы пробовали так делать, а потом удивлялись убыткам… поясню, почему.

Во-первых, нельзя думать, что все 154 рабочих часа будут проданы клиентам. Понятно, что при заключении сделки с клиентом стоимость, так или иначе, формируется исходя из оценки количества часов, которые будут затрачены на выполнение работы. Кстати, многие заказчики придерживаются точки зрения, что они платят за результат работ, а не за часы; на эту тему будет отдельный пост. Но, повторюсь, подрядчик в любом случае закладывает на выполнение работ какое-то количество часов. Теоретически, часы закладываются «с запасом», но на практике часто получается, что фактическая трудоемкость превышает расчетную:

  • менеджеры сделали скидку заказчику, чтобы предложить наиболее выгодную цену,
  • программист отчего-то работал медленнее, чем предполагалось,
  • при оценке не были учтены какие-то факторы, и недооценена трудоемкость,
  • программист, скорее всего, работает не 100% рабочего времени – сколько-то у него уходит на чай, разговоры с коллегами и личные дела (это, конечно, печально, но свести данное слагаемое к нулю не получится никогда).

А еще есть процесс отладки и устранения ошибок, который может занять больше времени, чем сама разработка. В общем, по моим наблюдениям, среднестатистической является ситуация, когда из 154 рабочих часов в месяц заказчик реально платит за 120 (и то, достижение такого показателя стоит серьезных управленческих усилий). Соответственно, цену приходится «масштабировать» - получаем себестоимость уже 670 рублей за час.

Мы учли труд программистов и «технического» персонала (бухгалтеры, уборщицы и т.д.), но есть и другие участники процесса, которые «обслуживают» программиста. Как минимум, это менеджер по продажам, руководитель проекта и/или постановщик задач, а также тестировщик. Клиент будет удивлен, если в смете стоимости проекта менеджерские усилия и затраты на тестирование будут указаны отдельной строкой. Проще всего включить их в стоимость часа программиста, что на практике и делается. Предположим, что каждый из перечисленных сотрудников обеспечивает работой (или обслуживает) четырех программистов. Округлим число этих специалистов до двух, положим им такую же зарплату, как программисту, и в результате нехитрых вычислений получим «добавку» к стоимости часа в размере 260 рублей. Итого – наша себестоимость составила 930 рублей за час.

Наконец-то мы можем перейти к вопросу наценки. Предположим, нас устроит чистая прибыль в 20% (да еще 15% налога мы уплатим с разницы между доходами и расходами). Получается, что час работы программиста можно продать клиенту за 1150 рублей. Скрестить пальцы и надеяться, что не будет таких проектов, где клиент с нами не расплатится, что не нужно тратиться на найм новых сотрудников (первые несколько месяцев они не приносят прибыли, то есть их нужно финансировать за счет компании), не нужно развивать собственные проекты и решения… Поскольку понятно, что так не бывает, мы устанавливаем эффективную отпускную цену часа равной 1500 рублям. На самом деле, по разным видам работ она колеблется: в техподдержке цена может быть меньше, а в разработке – выше, поскольку участие менеджера, проектировщика, тестировщика в процессе создания нового продукта гораздо более существенны, чем в процессе поддержки существующего.



  • 1
какой-же супер-классный текст!!! )))
мои мысли, почти дословно

И даже про процент утилизации времени я согласен - считаю так же 120 часов, из 160, это хороший результат.

отлично!

Что бы я обсудил в рамках поста:
1. оценку пользы, которую проект принесет клиенту, в виде съэкономленных человеко-часов, заработанной прибыли или уменьшенных убытков. В подавляющем большинстве проектов, с которыми я сталкивался, оценить их ROI невозможно, или практически невозможно достоверно. Как делаете такую оценку?

2. Я бы обсудил пути повышения доходности (обдумываю их сейчас):
Повышение стоимости за счет бренда, или специализации, или выхода на другой рынок
Снижение себестоимости за счет системы работы, и переноса ресурсов в менее дорогие регионы
Уменьшение трудозатрат (соотношения часов оплаченных/к часам фактически затраченным)
Техподдержка - как высокомаржинальный продукт
И, таки, создание и продажа собственного продукта

Спасибо за комплимент посту :)

1. Оценка пользы для клиента. Это душераздирающий вопрос! Но в некоторых случаях действительно можно посчитать что-то вещественное. Например, довольно часто в нашей практике попадается ситуация, когда система автоматически генерирует счета и акты выполненных работ по итогам месяца. У заказчика есть клиенты, с ними заключены абонентские договоры, по которым они ежемесячно платят какую-то сумму (она может быть фиксированной, или зависеть от объема оказанных услуг). До внедрения системы этим занимался бухгалтер, который тратил на выставление документов, предположим, 4 рабочих дня. Пусть они стоят компании 10 т.р. После внедрения документы генерируются за минуту. Таким образом, компания экономит минимум 10 т.р. в месяц (на самом деле - больше, потому что мы еще снижаем таким образом количество ошибок при выставлении документов).
Кое-что можно посчитать в случае автоматизации работы менеджеров по продажам. Например, система может автоматизировать e-mail и SMS-рассылки клиентам при срабатывании определенных условий - также можно посчитать, сколько времени на этом экономит менеджер. В отдельных отраслевых решениях (по наружной рекламе, интернет-рекламе) мы автоматизировали процесс составления КП, тут экономия времени менеджера может получиться очень существенной.
Но все это, конечно, оставляет за скобками главные плюсы автоматизации бизнес-процессов: повышение отказоустойчивости, прозрачности, возможности анализа и коррекции процессов.

2. Что касается повышения доходности, то тут соглашусь почти со всем:
- Раскрутка бренда, и, как следствие, движение в более дорогие сегменты рынка - это нормальный и естественный путь развития, тем более при ограниченности производственных ресурсов. Только надо следить за тем, чтобы не оказаться в ситуации полного отсутствия клиентов при экономическом кризисе, или появлении более шустрых и дешевых, но адекватных конкурентов. Следить путем постоянного создания новых продуктов в бюджетном сегменте, и постепенного их проталкивания вверх. Тогда линейка продуктов и услуг будет диверсифицирована по ценовым категориям и целевой аудитории.
- Перенос производства в менее дорогие регионы - это просто мечта! У одного нашего конкурента производственный офис расположен в Костанае, в Казахстане. Там, действительно, зарплаты ниже в разы. Но вот что за кадров они там находят - даже не представляю. У нас есть практика работы с удаленщиками из небольших городов, из самых разных регионов России - как правило, это хорошие специалисты, которые не могут оттуда уехать, поскольку привязаны семьей или еще какими-нибудь обстоятельствами. Таких людей трудно находить. В свое время, года три назад, когда мы тяготели к экстенсивному пути развития, была такая практика: собирали резюме программистов из какого-нибудь города, назначали кучу собеседований с интервалом в час, я туда ехал и со всеми общался... Кое-кто из найденных таким способом людей работает с нами до сих пор, но в целом этот метод тоже имеет свои ограничения. Удаленщики плохо поддаются контролю, им сложнее прививать новые методы работы, доводить до них технологические новшества. Практически нереально использовать в одном проекте и удаленщиков, и полноценных сотрудников, поэтому удаленщикам полностью "сливаются" только не критичные проекты.

не влезло все в один коммент, продолжаю.

- Повышение соотношения часов оплаченных/к часам фактически затраченным. Вот тут не соглашусь. Это как-то нехорошо по отношению к клиенту :) Думающий клиент (а таких немало) обязательно это заметит, и всем будет неприятно. Хотя, встречается и такая практика - например, когда в абонентскую плату включается определенное количество часов, которые клиент вряд ли выберет работами.
- Техподдержка! Это вообще мега-больная тема. Весь последний год я веду упорную борьбу за повышение рентабельности техподдержки, которая год назад была на нуле. На эту тему у меня запланирован доклад на конференции http://dump-it.ru/ в конце мая, ну и будет соответствующий пост. В качестве анонса - за прошедший год мы повысили среднюю выработку на специалиста (то есть число рабочих часов, которые оплачивает клиент) в 2,5 раза.
- Создание собственного продукта. Мы, собственно, этим и занимаемся, но при продаже продуктов в сфере автоматизации бизнеса покупка коробки для клиента смысла не имеет. Неизбежно приходится оказывать какой-то объем услуг по внедрению и индивидуальной доработке, а поскольку наш производственный ресурс ограничен - это ограничивает и продажи продукта. Отсюда возникает мысль создать такой продукт, который не будет требовать доработки. Тут очень помогает модель SaaS (аренда приложений): в качестве продукта можно привести в пример Мегаплан. Вроде бы все хорошо, но у них продажи ограничивает другой фактор: на самом деле, любой клиент, работая с таким продуктом, просто мечтает в нем что-нибудь улучшить. Не имея такой возможности, он рано или поздно придет к тому, что "хотелки" достигнут критической массы, и сделают использование продукта бессмысленным - тогда клиент от него откажется. Выход из этого парадокса известен, и его эффективность доказана мировыми гигантами, такими, как SalesForce: нужно массово продавать коробочный продукт за небольшие деньги, и оказывать услуги по его индивидуализации - за большие деньги. Причем, чем серьезнее доработка, тем больше стоит час (а не меньше, скидки за опт тут не применимы!). Это позволит и развивать клиентскую базу, и сохранить максимальную прибыль.

Средняя норма в США 1800 рублей, в России 600 рублей, как уже я где-то писал.
Вы стремитесь логично продавать по американским нормам, нормальное желание продавца обосновать цену.

По факту очень дорого обходятся работники 670р, где-то косяки с эффективностью или Вы "завышаете" в пару раз )))

Да вроде весь расчет показан. Конечно, зарплата программиста сильно зависит от региона. Это я считал для Екатеринбурга, в Москве получится больше, а в других городах в основном - поменьше. На эту тему недавно было исследование у портала Superjob: http://it-eburg.com/text/article/obzor_zarplat_ekaterinburgskii_programmist_poluchaet/

Можно, конечно, экономить на выплате зарплаты в конверте, это личный выбор каждого предпринимателя... Можно пытаться продавать клиенту "липовые" часы. Можно попробовать повышать дисциплину у программистов.
Только все это, по моему мнению, ведет к подрыву основ бизнеса.

Мое мнение, нужно увеличивать выработку каждого программиста, даешь пятилетку за 2 года!
В фильме соц сеть хорошо показано, как цукерберг подбирал программистов, кто быстрее сделает задание.

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

вранье!
Из Москвы выписывать пробовали? и там нету? Ну из Калифорнии? Из Гугла переманите?

ах, у вас денег нет. Упс. а говорили что проблема не в деньгах.
упс!

Это, к сожалению, демагогия.
Предположим, мы переманили разработчика из Москвы, на зарплату 100 т.р. Смотрим текст поста выше. Можно грубо прикинуть, что стоимость часа для клиента после этого перевалит за 2000. Кстати, в Москве, насколько я знаю, такие цены действительно имеют место. К сожалению, таких денег здесь нам просто никто платить не будет, ни за какие работы.

Так что проблема не в том, что у нас нет денег, а в том, что выше определенного уровня цен нет спроса. Или, точнее, там находится другой сегмент рынка с другими правилами (крупные заказчики, что почти автоматически означает пилёж бюджетов и откаты - а этим мы не занимаемся).

Ну прикупили дорого программиста - толку-то от него здесь, если в нашей глубинке ни один клиент не готов оплачивать его услуги по реальной стоимости. Это уже психологический фактор: "ну и что, что этот программист из Гугла, что он быстро и качественно сделает, всё равно не верим, что он столько стоит, давайте лучше помедленнее, но чтоб подешевле". Вот и выходит, что как только програмист начинает стоить дорого, он уезжает в Москву и дальше - просто потому что здесь на его крутость спроса нет. Это как одежду от кутюрье в деревне продавать - да, она может так и стоит, сколько на ценнике, но всё равно никто ее тут не купит.

Так что программист нужен строго определенного уровня цены и качества, не больше и не меньше. :) А это уже сужает выбор.

средняя немецкая цена за час продажи тушки - 75-150 евро, расходы на тушку и обслугу-рабочее место - 45-60. эффективное время для консультантов - 0.3-0.5, для сидящих на окладе - в лучшем случае 0.3.
но - консультантов нужно учить, это тоже денег стоит.

да, вот еще - уже упоминал выше.
вопрос - я понимаю, что Россия - страна победившего индивидуализма. Но, вроде как, проекты одиночками не ведутся. Есть либо позиции в проекте, либо роли в команде. И это оказывает куда большее влияние на результат.
и зачастую куда важнее, как работает человек в команде, нежели его личный оконечный стек в голове.

Отвечу заодно на этот комментарий и на тот, что был выше, насчет командной работы.
У нас есть два технологических процесса: разработка и поддержка. В поддержке командной работе вообще нет места. Так как задания небольшие - каждый делает свое. Максимум, что может случиться - это обсуждение между двумя программистами, если выполняемые ими задания могут как-то повлиять друг на друга.
Разработка, в свою очередь, тоже делится на два процесса: фундаментальная (создание базовых версий продуктов) и коммерческая (создание версий продуктов под конкретных клиентов). Первая занимает 5%, вторая - 95% времени разработчиков. В случае коммерческой разработки, как правило, тоже одно задание выполняет один человек (отличие от поддержки только в том, что задания длинные, по нескольку недель). Случаются и исключения, но тогда работа заранее каким-то понятным образом делится между двумя разработчиками.
Фундаментальная разработка - 5% - это единственная у нас ситуация, когда возможна по-настоящему командная работа. То есть, в ней задействованы много людей, присутствует процесс управления проектом (в описанных выше ситуациях его в общем и нет - есть только предпроектное исследование и составление ТЗ до разработки, а также тестирование и приемка после нее), используются всякие инструментальные средства совместной разработки и т.п.
Но фундаментальная разработка не описывается экономикой, про которую пост. Расчет стоимости часа для фундаментальной разработки нас, конечно, интересует, но во вторую очередь, поскольку клиенту эти деньги не выставляются.
А для поддержки и коммерческой разработки фактор командности работы на расчеты не влияет.

Саулюс Бернотайтис

Думаю, что ест смысл предложить заказчику разработчиков серьезного ПО или проекта забрать к "в лодку". заказчик покрывает чистую себестоимость, или какую-то ее часть, разработчики что-то делают за свой счет (как вариант - за свой счет делают все) и берут на себя доработку все дальнейшее обслуживание проекта. И получаеют заранее оговоренный процент от оборота/дохода/прибыли или еще какой-то конкретной и внешне четко отслеживаемой величины. Минус такого подхода, что вначале денег будет мало, а плюс - что будет постоянный доход. И тогда дело будет развивать и тащить проекты в обслуживании. И люди будут подбираться и обучаться на дальнейшее обслуживание проекта. А кто вырастит, тот пойдет в разработчики. Для меня, как заказчика, такой подход идеален - все айти от начала до конца и на протяжении всего проекта осуществляет "одни руки". И за это я был готов отдать до 7-10 процентов прибили. Учитывая, что это интернет лотереи мирового масштаба, то доход "айти" через год составил бы от 1-2 до 20 -30 млн. долларов в год. И мне кажется, что это очень перспективная позиция - иметь свой штат айтишников становиться все сложнее и сложнее - проще все "айти" передать на обслуживание сторонней фирме. За процент или фиксированную оплату.
С уваженинем,
Бернотайтис Саулюс
9154352935@mail.ru

Re: Саулюс Бернотайтис

Ну, это у вас не столько передача ИТ сторонней фирме (аутсорсинг), сколько бизнес-партнерство. Наверное, разные разработчики по-разному относятся к таким предложениям, а про нас могу сказать точно: мы на них не соглашаемся (хотя иногда предложения поступают). Наш бизнес - это собственно разработка ПО. У него своя экономика, которая нами рассчитана, и свои риски. Брать на себя долю чужих рисков, входить в сторонние проекты - нам совершенно не интересно, поскольку это может деформировать и разрушить нашу компанию.
А еще есть чудесная тема переманивания сотрудников, которая почти неизбежно возникает при таких проектах (примеры видел не раз). В какой-то момент инвестору начинает казаться, что менеджмент ИТ-компании ему только мешает, и он начинает переманивать программистов из ИТ-компании, таким образом, ее разрушая. И в конечном счете разрушает весь продукт и всю систему разработки - но это инвестор понимает только через полгода-год, когда выясняется, что у него с разработчиком накопились серьезные противоречия, а разрешать их некому.

  • 1