Чи коштовний аутсорсинг у довгостроковій перспективі? Чи шкодить це якість коду? [зачинено]

Мені відомо, що компанія, яка володіє інтелектуальною власністю на гідний програмний продукт і приносить чудовий дохід від ліцензування щорічно. Однак директор (нетехнічний) скаржиться на витрати на утримання групи розробників, оскільки вона значно харчується націнки на прибуток, і розглядає можливість аутсорсингу розробки конкретних модулів для інших країн, які стягують плату за меншою ставкою.

Особисто я не думаю, що це буде економічно вигіднішим рішенням у довгостроковій перспективі. Це може призвести до поломки комунікацій, коли виникають проблеми, крім того, технічні характеристики повинні бути герметичними для води, що в будь-якому разі може зайняти більше часу. На мою думку, при роботі в командах ключове спілкування - чи існує ефективний спосіб зробити цю роботу?

Я впевнений, що хтось має приклад цього роботи, але я цього не бачив.

Я працював у компанії Fortune 500 протягом багатьох років, де вони надавали перевагу багато розвитку. Я не маю жодного прикладу тогочасного проекту, який коштував сторонніми компаніями, коштував менше, ніж якби ми це робили самі (власні).

Хоча рівень їх програмування був меншим, ніж у нас, ми витрачали в 3 рази більше часу на керування командою, яка перебуває на аутсорсингу, ніж це для внутрішніх команд. Це поверх додаткового часу, необхідного для детальніших вимог, ніж потребує наша внутрішня команда, та додаткового часу, необхідного для забезпечення якості, оскільки код ніколи не був близьким до правильності.

Ви можете швидко, можна дешево, або добре. У вас не може бути всіх трьох, і я можу стверджувати, що навіть два з трьох можуть бути розтяжкою.

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

Програмне забезпечення, яке здійснює аутсорсинг своєї розробки програмного забезпечення, вже не є програмною компанією. Я заперечую, що будь-який зароблений прибуток буде короткочасним, адже ви створюєте свою власну конкуренцію. Як тільки вони зрозуміють, що вони знають продукт краще за вас, то вони також зрозуміють, що вони вам більше не потрібні.

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

Однак якщо ви можете знайти надійну компанію, якій можете довіряти (тобто ви бачили / чули про них хороші речі від інших людей), можливо, це варто.

Режисер хоче замінити деяких своїх досвідчених місцевих розробників людьми в далекій країні, чия експертиза він не компетентний судити, які взагалі не мають досвіду роботи з кодом і які не можуть бути безпосередньо під наглядом або під керівництвом тих, хто це знає кодекс.

Я два рази переживав це. В обох випадках недорогі іноземні фірми не змогли вчасно доставити належну якість. Коли місцеві розробники почули, що робота прямує за кордон, вони знайшли інші робочі місця, а не чекати, коли вони будуть зайвими. У міру продовження крововиливів у експертизу графіки ковзали, критичні помилки не виправлялися, клієнти розгнівалися і перейшли на конкурентів, і врешті обидві компанії згорнулися.

Були також дивні проблеми із спілкуванням, очікуваннями та культурою. Наприклад, іноземна команда не перевіряла багато коду або не відповідала на електронне повідомлення негайно. Виявилося, що місцевий ІТ-менеджер отримав бонус за зменшення витрат, тому він мав весь офіс на низькошвидкісному інтернет-з'єднанні. В інший раз тестери QA третього світу звичайно містили кілька диких різних помилок у одному звіті про помилки; їх керівник побоювався вичерпати кількість помилок.

Деякі команди в недорогих місцях добре. Як я чую, у Пекіна, здається, в Пекіні є дуже компетентна команда. Але вони вже мали багаторічний досвід роботи з людьми з усього світу по телекомунікації, перш ніж вони почали це робити, а люди в Пекіні - це співробітники Red Hat, а не фірма-аутсорсинг.

Так - ви отримуєте те, за що платите.

На мій досвід, якщо ваші потреби ринку та розвитку не є настільки простомими, їх можна легко пояснити електронною поштою будь-якому розробнику з можливим мовним бар'єром і настільки мертвим простим, що навіть розробник, який не дуже інвестує в компанію, все ще може досягти успіху при створенні якісного продукту, так, ваш продукт постраждає .

Я працював у компанії, де у нас була велика місцева команда з розвитку, і наш продукт постраждав просто тому, що команда менеджменту вклала більше грошей та зусиль у продажі. Оскільки стільки зусиль було вилито на продажі, виявилося, що ми робимо «чудово» - але це означало отримувати дохід, ми повинні були продовжувати вливати гроші та ресурси в процес продажу.

У нас була віддалена команда, але ми повністю інтегрували їх у компанію, і вони брали участь на тому ж рівні, що і наші місцеві команди. Це єдиний спосіб роботи . Я був для них керівником місцевої команди, і ми регулярно виїжджали на роботу з ними. Ми дарували їм сорочки та куртки компанії, як місцеві команди. Зрештою, це врахувало нас 20-30%. Якщо ви складете систему, яка намагається скоротити витрати на більш ніж це, ваш продукт постраждає відповідно.

Якщо ви працюєте з якісною командою аутсорсингу, а керівництво готове спілкуватися та виконувати критерії прийняття.

Тоді вартість буде приблизно такою ж швидкістю, як і внутрішньо розроблений продукт.

Ви також можете отримати таку ж якість, якщо пощастить.

Я, можливо, трохи упереджений, тому що моя компанія утримує штатних розробників, і не передавала жодних розробників. Я підозрюю, що досвід, який ми мали з партнерами по інтеграції, які передали розвиток, мав щось спільне з цим рішенням.

На мій досвід, аутсорсинг проекту є найкращим рішенням, коли намагаються отримати кращі націнки.

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

Моя думка з цього приводу полягає в тому, що якщо ви думаєте про те, щоб спробувати змінити зміни в маржинальному аутсорсингу, ви, можливо, кинете свої інвестиції. Якщо ви подумаєте над цим, успіх продукту - це справа в тому, що вони працюють як слід, тому якщо ви поміняєте команду розробників, речі можуть стати некрасивими.

Добре сплановане / зроблене програмне забезпечення з відкритим кодом може бути вашою відповіддю, оскільки це може бути дуже прибутковим, а підтримка дещо делегується спільноті, але рецепту успіху немає. Найкраща порада, яку я можу дати, - це рекомендувати кілька розмов про те, що насправді є відкритим кодом та його шенагіганами:

• "Як почати проект з відкритим кодом" від Джеремі Растона (BT) http://vimeo.com/856110
• Кріс ДіБона (Google) "Open Source is Magic" http://www.youtube.com/watch?v=hmZyyBVbkOQ
• "Двигуни спільноти" Джоно Бекона (Canonical) http://www.youtube.com/watch?v=zKOrWubmzAY
• "Проекти з відкритим кодом та отруйні люди" Бен Коллінз-Суссман та Брайан Фіцпатрик (Google) http://www.youtube.com/watch?v=ZSFDm3UYkeE
• "Що для мене? Вигоди від відкритого коду пошуку" Бен Коллінз-Суссман та Брайан Фіцпатрик (Google) http://www.youtube.com/watch?v=ZtYJoatnHb8&feature=related

А можливо також:

• "Як вибрати модель бізнесу" від Roan Lavery (FreeAgent) http://vimeo.com/5588154

Справа з відкритим кодом, на мою думку, полягає в тому, щоб будувати щось цінне і цікаве не тільки для вас, але і для всіх, сила відкритого коду лежить у громадах.

Крім того, якщо ваш начальник / компанія неохоче відкриває програмне забезпечення, просто виділіть специфіку вашої власної ділової логіки та ноу-хау. Отже, що б ви робили:

1. Насичуйте проект із відкритим кодом зі своїми ресурсами
2. Рости громаду
3. ???
4. Прибуток =)

Так, я серйозно, і "???" включає в себе те, що коли-небудь стратегії, які ви хочете здійснювати після того, як ви наберете достатньо інтересу. Завдяки сьогоднішнім інструментам, таким як Github і twitter, ви можете поширити слово легше, але пам’ятайте, що ваше перше враження має бути досить цікавим.

Якщо ви насправді не хочете відкритого коду ( який ви повинні зрозуміти як бізнес-модель, перш ніж впровадити його, якщо ви хочете досягти успіху ), ви завжди можете запустити його як послугу, для цього перевірте відео Carsonified, але це означає ціле багато іншого для вашої компанії.

Зрештою, бути відкритим кодом або запустити його як послугу - це способи зробити проект довготривалим.

Я не пам’ятаю автора цієї цитати, але вона потрапляє в цвях.

" Нещільно з'єднані команди, які працюють разом над щільно з'єднаними компонентами, не вдається. Неминуче "

Аутсорсинг = слабко поєднані команди.

Спроба зменшити витрати шляхом географічного розподілу робіт на взаємозалежні компоненти завжди не вдається.

З іншого боку, виходячи з мого досвіду, переміщення цілої частини портфоліо програмного забезпечення може спрацювати, це означає, що він може бути розроблений в хорошій якості зі зниженими витратами.