Расширять свою команду или дать проект на аутсорс

После освежения в памяти книги Тома Демарко «Deadline» сели моделировать такие кейсы. У нас есть 5 программистов и несколько проектов, которые нужно сделать срочно. Своими силами не успеваем, что же делать — набирать новых или отдать избыточную работу на аутсорс?

Исходные данные


Имеем сработавшуюся команду из 5 разработчиков.

Моделируем два кейса:
  1. Набираем 3 новых разработчиков к себе в штат;
  2. Связываемся с внештатной командой из 3 человек.

Под катом оцениваем прирост в стоимости и производительности через полгода и год для обоих кейсов.

Учитываем, что ввод новых людей в курс дела займёт 6 недель, и при этом их производительность будет расти от 50% до 100% и плюс к этому они отвлекают старых членов команды. То есть получаем яму в производительности. После того как они сработаются, берём накапливающийся коэффициент производительности 1.01. То есть командный эффект будет влиять от недели к неделе на 1%. Также учитываем трату времени на коммуникации в командах: чем больше в них людей, тем больше тратится времени.

В случае привлечения удалённых разработчиков учитываем, что с нашей стороны потребуется тратить дополнительно 35 часов в неделю на консультации, SCRUM-митинги, демонстрации, code-review. А также учтена отсрочка начала работ на 4 недели для подготовки ТЗ и прочей документации, понятной чужим людям.

Стоимость штатных программистов возьмём из расчёта $15/час, а удалённых — $25/час

Результат


Результат через 6 месяцев Результат через 1 год
+3 разработчика в штат
Стоимость разработки +60% +60%
Выполненная работа +12% +22%
+3 разработчика на аутсорсе
Стоимость разработки +85% +92%
Выполненая работа +25% +29%

Вывод из этого всего мы сделали такой: внештатники в краткосрочной перспективе помогут ускорить разработку. И за полгода со старта проекта сделают на 13% больше работы, чем расширенная собственная команда. Однако обойдётся это недёшево. И если проектов на год и больше, то дешевле расширить собственную команду.

При расширении своего штата полученная «яма» в производительности компенсируется примерно за полгода — то есть новые сотрудники начнут себя окупать.

Разумеется, все цифры варьируются и зависят от множества факторов. Поэтому попробуйте сами составить табличку в Excel, и я буду благодарен, если поделитесь своими наблюдениями!
Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 26

    0
    Стоимость штатных программистов возьмём из расчёта $15/час, а удалённых — $25/час

    Почему удаленные так дорого?
      +6
      Тоже удивило. по моим скромным подсчетам, если на белую, штатники обходятся дороже внештатников. Кроме того, не идет в рассчет оборудование рабочего места.

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

      Вообще, есть некоторые подозрения, что рассчеты взяты с потолка и в качестве моделей взяты «сферические программисты в вакууме»

      Кроме того, если совещания и митинги так сильно влияют на производительность, может ну их в жопу, эти митинги.
        0
        750р/час — такой ценник нам выкатывали некоторые региональные компании. Достаточно крупные и опытные.
        Конечно, они прожимаются до 600-650р, но мы предпочли рассматривать пессимистичный вариант. )
          0
          Может стоило поискать тех, кто будет работать за туже цену что и штатники? Вы же своих считаете профессионалами, почему другие будут хуже?
            +1
            Можно и дешевле, но это скорее всего будут фрилансеры-разгвоздяи, а не компания, которая нам выделит гарантированное количество ресурсов и менеджера, который их пасёт. Нам нужен именно такой вариант.
            +1
            Могие хорошие фрилансеры готовы работать за 500р в час.

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

            Некоторые компании выкатывают ценник в 1500р/час, и часто работают в них далеко не профессионалы.

            Если Ваш аргумент в споре «компания vs фрилансер» будет, что с компаниями заключается договоры и меньше шансов просрать сроки и получить на выходе плохой продукт, то это — тоже мф, т.к. нередко бывает так, что компании аутсорсеры затягивают выпуск, если вдруг неправильно рассчитали сроки, а то и вообще заворачивают продукт и кормят Вас завтраками.
              +1
              Для нас аргумент — это конечные цифры ) Как быстро мы сможем произвести продукты и сколько это будет стоить.
              У нас к аутсорсерам требования — чтобы это была компания и чтобы к выделенной нам команде был приставлен PM. Такого уровня компании с Урала или Украины выкатывают ценник $20-25 в час.
                0
                «чтобы это была компания» — специфичное для Вас и предвзятое требование. Хороших ПМ-ов много и среди фрилансеров, а большинство из них будут набирать Вам команду таким образом, что расчетная стоимость будет ниже ожидаемой, т.к. есть работы, которые можно вести параллельно и которые не требуют обширных знаний в предмете.

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

                PS: Не думайте, что я встал в оппозицию и пытаюсь Вас очернить или оскорбить, просто я сам отношусь к категории «фрилансеры готовые работать за 500р в час», и сталкиваюсь с таким предвзятым отношением сплошь и рядом.
          0
          По ощущениям вывод правильный, но расчёты не очень понятны.
          Вообще здесь разумнее в виде графика результат представить.
          На первый взгляд ажется, что не учтено, что у новичка зарплата может быть меньше, а потом с достижением результатов она растёт. И непонятно, насколько сильно новичок отвлекает имеющихся разработчиков.
          Кроме того, аутсорс бывает дешевле внутренней разработки, в этом иногда его смысл — сделать быстро и дёшево и «занять нишу на рынке». А потом сделать нормально и отмыться от подпорченной репутации ;)
            0
            Мы приняли за факт, что новобранцы пару недель отвлекают каждого члена команды по 1 часу в день. При соотношении 5 старых / 3 новых — мне кажется, правдоподобно.

            «Быстро и дёшево занять» — это отличная мысль! Именно к этому мы и пришли: возьмём аутсорсеров для изготовления полнофункционального прототипа (без дизайна), а потом своими силами интегрируем с нашей общей системой.
              +2
              А Вас не смутило, что ту вообще пытаются приписать некоторую численную характеристику производительности программиста?

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

              Вот индусам проще — они меряют «объем» кол-вом строк кода, а как мерять тем, кто отказался от «индийской» системы счисления?

                –1
                Наверное лучше вообще и не оценивать объемы работ и производительноть (все равно будут ошибки!), тогда наступит всеобщее счастье ;-)
                  0
                  Но надо ж это как-то оценить. Обычно при оценке 1 п.с. — это сила одного «эталонного» программиста, для каждого рассуждения этот программист свой. Типа «Вася сделал бы эту работу за месяц, а если его клонировать, то два Васи управятся за три недели».
                  Ну и эффект от аутсорса/новичков обычно измеряют с конкретным Васей. Так что коэффициенты тут довольно случайны. Интересны соотношения (что больше).
                    0
                    А как иначе Вы предлагаете рассчитывать количество программистских ресурсов для разработки проекта в поставленные сроки?
                    Сколько людей нужно, чтобы за время N выполнить проект объёмом X?
                      0
                      Ну во-первых «объем X» — не совсем корректное определение.

                      Я бы заменил его на «Множество задач X»

                      Далее все задачи рабиваются на подзадачи, и дробление идет до такого уровня, когда каждая задача умещается в спринт с юнит-тестами и запасом по времени в 10-20%

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

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

                      Рассчет очень простой — если время спринта, скажем 2 недели, у нас 6 работников и 18 таких спринтов, то следовательно нам понадобится 6 недель на то, чтобы закончить проект.

                      Т. к. есть негласное правило, что «как бы мы не планировали, треть срока все равно просрем», то прибавим еще 2 недели и получим 8 недель.

                      Это для проектов «с нуля»

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

                      К чему приводит введение новых людей в проект, который уже в разработке, почитайте у Брукса — нет смысла цитировать здесь классиков.

                  0
                  Вопрос спорный. Можно спокойно пересчитать и в другую сторону.

                  Хотелось бы реальных примеров, а не просто того, что автор прикинул на бумаге.
                    +1
                    Ага, можно. Поэтому я и призываю повторить наш эксперимент, чтобы сравнить. )

                    Напомню, что у Демарко звучала следующая мысль относительно этих моделей. Менеджер принимает решения, основываясь на своём опыте. Но далеко не всегда он это может объективно обосновать перед другими людьми.
                    Например, всем понятно, что новые люди в штате только замедлят работу. Но НАСКОЛЬКО? Сколько денег мы потеряем от этого? Насколько имено упадёт производительность?
                    В таких случаях математическая модель с использованием объективных и субъективных входных данных очень сильно помогает прогнозировать последствия таких решений.
                      +2
                      И ещё сильно зависит от того, что за людей набрали и с чем приходится работать. Ведь можно нанять 3 середничка, которые не знают конкретный фреймворк, используемый для разработки (не будем брать ситуацию с собственным фреймворком для простоты). Можно нанять тех-же середнячков с крепкой базой и опытом работы с конкретным фреймворком. Втянутся они быстро и если опыт разработки у них достаточно обширный, 6 недель на втягивание однозначно много. Ну и есть профи, которые стоят подороже, знают фреймворк и их опыт позволяет довольно быстро влиться в работу. В каждом из случаев расчётные величины отличаются, и существенно.

                      У меня был опыт, я устроился в компанию — у них свой фреймворк-cms корпоративного уровня, много модулей, все проекты масштабные (автоматизация управления предприятиями — электронный документо-оборот всего лишь модуль системы), большие магазины с филиалами (учёт, бухгалтерия, склады) ну и подобное. Через неделю я уже влился в работу в полную силу и более-менее орентировался в системе самостоятельно. Спрашивал конечно, но час в день точно не убивался на это. Главный разработчик системы сильно был удивлён, когда я за неделю въехал во всё что нужно было и самостоятельно разбирался в системе, делая задания на равне со всеми.

                      Так что тут всё весьма не однозначно.
                        0
                        З.Ы. А ещё за первый месяц я нашел в системе 4 достаточно нетривиальных бага и сделал к ним патчи :)
                        +3
                        Учитывая свой опыт руководства, Я пришел только к одному верному математическому выражению:

                        — «Если работник пашет, то работодатель в прибыли».

                        А вопрос «Как заставить работника правильно пахать?» — будет всегда математически не предсказуем.
                      +1
                      пардонте, а какая разница между 3-мя «внештатиками» и 3 штатными новичками, которых просто посадили в соседнюю комнату?(если подход к новеньким будет как в случае с аутсорсом)
                      Выходит, явный выигрыш в цене и те же показатели в производительности?
                        0
                        А еще есть важный момент — если штатник через полгода возьмет, да и свалит — все придется начинать сначала.

                        Это тоже риск.
                          0
                          Точно так же может свалить и внештатник, это одна из причин, почему топикстартер одним из условий обозначил работу с компанией-аутсорсером – это компенсирует некоторые риски для компании, а некоторые другие риски переносит на аутсорсера.

                          По факту же «сваливания» работника — риск не может быть компенсирован ни внутри компании, ни со стороны аутсорсера, но в случае с аутсорсером – риск переносится на него.
                            0
                            Да, я ровно про это же говорю — компания-аутсорсер нас страхует от этого в некоторой степени. Если аутсорсер грамотный и если ревизии кода проводятся — то восстановить потерю он сможет быстрее.
                          0
                          К сожалению, кейсы с такими проектами нельзя рассматривать, поскольку в программировании слишком много неформализуемого. На больших проектах это можно сгладить и усреднить, но на проектах 5-10 человек на полгода — практически нереально. Такие проекты могут рождаться быстро и эффективно, а могут в муках и мертвыми.
                          Если же говорить не о настоящих разработках, а о кодерстве, то можно и средние цифры выводить и планы строить, но такие кейсы надо привязывать к географии, рассматривать варианты как работы по фрилансу с командой, чтобы избежать микроменеджмента, так и аутсорсинга в другую компанию.

                          Когда появляются такие задачи, самое главное — оценить, что для вас важнее — управлять проектом или максимально заработать. Стратегически правильнее — управлять проектом, если он — единичный всплеск. Если же такие проекты идут косяком, надо расти.
                            0
                            По-моему тут без расчетов сразу понятно, что в краткосрочной перспективе — аутсорс, а в долгосрочной — своя команда, хотя бы смотря по ценам.

                            Only users with full accounts can post comments. Log in, please.