Блог об IT бизнесе

Повидал несколько компаний, который абсолютно по разному относятся к тому, нанимать внешние компании для выполнения каких-то работ или пытаться все делать внутренними силами.

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

Вторая компания, наоборот, выносит постоянно какие-то проекты, задачи, направления во внешние фирмы.

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

А против, то что не всегда результат выходит желаемого качества, опыт не накапливается в компании и плюс дополнительные затраты.

Мои 2 цента по этому поводу. Как по мне, наймом со стороны пользоваться таки нужно, но делать это с умом.

Самое главное – это то, что никакая ключевая функция фирмы не должна выноситься из фирмы. Это правда очень стандартное и тривиальное замечание. Но капу чуть глубже, так как обычно проводят черту так – либо разработка ключевая (не выносим), либо не ключевая (выносим). Я бы проводил бы черту скорее по проектам/задачам. Например разработка следующей версии, которую ожидают самые ключевые заказчики – вещь ключевая и доверить это сторонней фирме как-то нехорошо. А вот например медленная и планомерная поддержка старых версий – вполне таки вещь, которая не так критична.

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

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

И четвертое – нельзя выносить то, что понадобиться завтра. Возвращаясь к тем самым багам в старой версии. В целом, знания связанные с исправлением этих ошибок будут дальше цениться все меньше и меньше. С другой стороны, если например компания собирается переходить с одной технологии на другую, то перенос проекта на новую технологию (даже если это не критичный сейчас проект), лучше таки делать внутри, так как ценность этих знаний как раз будет дальше возрастать.Что безусловно можно сделать, привлечь снаружи эксперта, который будет консультировать по особенностям технологии, но не более того.

Вот такие вот мысли.