Как стать автором
Обновить

Комментарии 12

Как вы пришли к тому, что нужно 5 человек минимум в команде? По-моему, двух хватит, разве нет? И почему бы с них не спросить, если это ваши сотрудники, у которых есть обязательства. Не обязательно же сразу увольнять человека.

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

Как вы пришли к тому, что нужно 5 человек минимум в команде? По-моему, двух хватит, разве нет?

Здесь пример конкретно относится к DevOps специализации. Чтобы обеспечить бесперебойную работу инфраструктуры, потребуется 5 человек. 4 человека, чтобы покрыть всю неделю при посменном графике (если бы он такой был) и 5-ый человек на отпуска/болезни и периодические увольнения кого-либо из команды. Здесь же нужно учитывать, что они должны быть доступны 24/7. Если организовывать такую структуру при 2-х человек, скорее всего, они у вас сгорят за считанные месяцы и вам придется искать новых ребят.

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

Спросить можно. Но что вы им скажите? У вас в этом месяце не будет премии? Сколько эта премия? Сопоставима ли она с тем, сколько у вас был простой? Как правило нет. Увольнять никто не предлагает, но и спросить с ребят по полной не получится.

Минусов маловато.

Аутсорсер может просрать всё.

Это почти всегда дороже чем нанять свою комманду.

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

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

Ну а плюсы очевидны на маленьких проектах.

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

Статья рекламная настолько (или понимание темы отсуствует настолько), что по другому быть не может. По линку на опрос первый же вопрос "Готовы ли вы отдать свою инфраструктуру на аутсорс?" Варианты ответов:

  • Да, я не вижу ничего страшного в аутсорсе, за ним будущее

  • Другое

Сразу вспомнился известный анекдот про

  • Да, не возражаю.

  • Нет, не возражаю

Аутсорсер может просрать всё. 

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

Это почти всегда дороже чем нанять свою комманду.

А вот тут не соглашусь. Если,

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

То ценник при работе со своей командой будет значительно дороже (речь опять же про DevOps исключительно), нежели с аутсорсом.

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

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

Здесь могу лишь сказать, что вы сталкивались с плохим аутсорсом.

Ну а плюсы очевидны на маленьких проектах.

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

Речь опять же про разработчиков, а не про DevOps.

Как правило найм сотрудника занимает 10X его заработной платы

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

Это откуда такие цифры? Можно адекватные пруфы?

Сам найм стоит порядка 3X. Если опять же учитывать изменение перформинга команды на период адаптации, то выйдет 8-10X. Почитать можно тут.

Вообще похоже на рекламную пропаганду. Работал как то в аутсорсинге, там была методичка для бизнесменов: как плохи свои итшники и как хорошо аутсорсинг. Так что с такой статьёй вам надо не на хабр а на бизнес фм. Тут все воспринимают аутсорсинг так как он того заслуживает.

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

Вот я специально написал про «адекватный» пруф. Статья на хабре от эйчара (простихоспади) одной средненькой конторы, да ещё и приём на работу с авиабилетами и квартирой у них может и 10Х.
Так что это вы врёте чтоб запугать бизнес искать своих — чтобы брали аутсорсинг.

Так что это вы врёте чтоб запугать бизнес искать своих — чтобы брали аутсорсинг.

Никто никому не врет, а просто делимся опытом.

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

Это неизвестно не бизнесу, а автору статьи. У оутсорса (если только речь не о прототипах на коленке для проверки идей) вагон недостатков. Например:

  • незнание разработиками производственного окружения, для которого разрабатывается проект

  • отсутствие контроля качества кода со стороны заказчика

  • огромные пробемы с продолжением разработки при смене оутсорсера или переходе на собственную команду

  • зависимость заказчика от финансового положения оутсорсера и его аппетитов

  • проблемы с отладкой невоспроизводимых на стороне разработчика ошибок

Это неизвестно не бизнесу, а автору статьи. У оутсорса (если только речь не о прототипах на коленке для проверки идей) вагон недостатков. Например:

* незнание разработиками производственного окружения, для которого разрабатывается проект

* отсутствие контроля качества кода со стороны заказчика

* огромные пробемы с продолжением разработки при смене оутсорсера или переходе на собственную команду

* зависимость заказчика от финансового положения оутсорсера и его аппетитов

* проблемы с отладкой невоспроизводимых на стороне разработчика ошибок

Опять же это плохой аутсорс, который не думает как правильно построить процессы и как работать с клиентом. Первый пункт относится непосредственно к инфраструктуре и он вполне решаем. 2,3 пункт относятся к разработке, за них ничего не могу сказать. 4 пункт - опять же плохой аутсорс, договор подписывается на берег и не меняется в процессе. 5 - опять к разработке.

Первый пункт относится непосредственно к инфраструктуре и он вполне решаем.

Неверно. Оутсорс пишет для всех подряд, и его разработчики физически не имеют времени и возможности изучать производственное окружение всех заказчиков.

2,3 пункт относятся к разработке, за них ничего не могу сказать.

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

4 пункт — опять же плохой аутсорс, договор подписывается на берег и не меняется в процессе.

Вы не совсем поняли, что я имел в виду. Разумеется, договор подписывается на берегу. Но это хорошо, пока заказчику потом ничего не нужно развивать. А вот если потом у заказчика появляются новые пожелания, вот тут начинается цирк. Почему я и писал выше, что для прототипа и т.п. одноразовых проектов, где в первую очередь важны время и цена, оутсорс оправдан. А вот для долговременной разработки — нет, не оправдан.

5 — опять к разработке.

У меня такое впечатление, что вы отмахиваетесь от проблем с разработкой, как от чего-то маловажного. Это неверно. Если у вас есть проблемы с разработкой, они потом вылезут в проблемах со всем остальным.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий