Избягвайте да бъдете взети като заложник от своите разработчици

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

Разговорът се обърна и продължи да се изпуска за плащане на седмични такси за разработка, без да се види напредък с разработчика, с когото са работили. Сега разработчикът иска да им начисли още еднократна такса за завършване на проекта, както и седмична такса за поддръжка, за да покрие други заявки. Влошава се.

Разработчикът прехвърли имената на домейни, за да може да ги управлява. Разработчикът също така хоства приложението в своя хостинг акаунт. Накратко, разработчикът сега ги държи като заложници.

За щастие жената, с която работя, поиска административен достъп в миналото, за да редактира някои от файловете с шаблони за сайта. Разработчикът можеше да й предостави ограничен достъп, но той не го направи. Той (мързеливо) й предостави административното влизане в сайта. Тази вечер използвах този достъп за архивиране на целия код на сайта. Също така разбрах какъв софтуер за управление той използва и се насочих към администрацията на базата данни, където успях да експортирам данни и структури на таблици както на приложения. Ууу.

Собственикът планира да премести сайтовете към нови имена на домейни, след като разработката приключи. Това е огромно, защото означава, че настоящите домейни могат да изтекат в случай, че има гневна раздяла между разработчика и компанията. Виждал съм това да се случва и преди.

Няколко съвета, ако ще вземете външен екип за разработка:

  1. Регистрация на домейни

    Регистрирайте имената на домейните си в името на вашата компания. Не е лошо вашият разработчик да бъде технически контакт в акаунта, но никога прехвърлете собствеността върху домейна на някой извън вашата компания.

  2. Хостинг на вашето приложение или сайт

    Страхотно е, че вашият разработчик може да има хостинг компания и да хоства вашия сайт вместо вас, но не го правете. Вместо това попитайте неговите препоръки къде да хоствате приложението. Вярно е, че разработчиците се запознават със софтуера за управление, версиите и местоположението на ресурсите и това може да помогне на вашия продукт да бъде завършен по-рано. Това обаче каза, че притежавате хостинг акаунта и добавяте своя разработчик със собствени данни за вход и достъп. По този начин можете да издърпате щепсела, когато имате нужда.

  3. Притежавайте кодекса

    Не предполагайте, че притежавате кода, поставете го писмено. Ако не искате вашият разработчик да използва решенията, които сте му платили, да се развиват другаде, трябва да решите това по време на договора. Разработих решения по този начин, но ги разработих и там, където запазвам права върху кода. В последния случай договорих цената на заявлението по-ниско, за да има стимул за компанията да ми даде права. Ако нямате нищо против разработчика ви да използва кода ви на друго място, тогава не бива да плащате най-добрия долар!

  4. Получете второ мнение!

    Не боли чувствата ми, когато хората ми казват, че вземат оферти или се консултират с други професионалисти. Всъщност го препоръчвам!

Изводът е, че плащате за таланта на вашия разработчик, но трябва да запазите контрола и собствеността върху идеята. Твое е. Вие сте инвестирали в него, вие сте рискували своя бизнес и рентабилност за него ... и вие трябва да го запазите. Разработчиците могат да бъдат заменени и това никога не бива да излага вашето приложение или още по-лошо - на вашия бизнес, в риск.

6 Коментари

  1. 1

    Аз съм разработчик на уеб приложения и съм съгласен с повечето от точките ви (може би всички), но бих искал разяснение относно # 3.

    Дублирането на едро на сайт или приложение, продадено на друга компания (или по-лошо на конкурент), е неетично и винаги трябва да се определя като неприемливо във вашия договор. Разработих обаче иновативни решения на често срещани проблеми, докато работя по проект на клиент, който няма нищо общо с конкретния им бизнес, нито представлява значителна част от цялостното решение.

    Пример:
    Клиентът искаше контрол на ниво страница и ниво на поле, обвързан с потребителски роли. Функцията „извън кутията“ за ASP.Net прави разрешения на ниво папка. Затова разширих родните разрешения за .Net и доставих решението като част от цялостно уеб приложение.

    Вярвам, че те имат право на цялата кодова база (както е предвидено в договора), но се чувствам оправдано да използвам същата методология и парчета код, за да постигна това разширение за бъдещи проекти.

    Друга бръчка:
    Направих това, докато бях изгонен от консултантска компания. Би ли имало право консултантската компания според вас да се върне и да копира това решение, като го пусне на пазара?

    • 2

      Не точно,

      Мисля, че сме съгласни. Моят смисъл в това е да се уверя, че имате кода и можете да излезете с него. Ако вашият разработчик компилира код за вас и го изпраща на вашия сайт - вие нямате кода. Виждал съм това да се случва с всичко, от графики, Flash, .NET, Java ... всичко, което изисква изходен файл и се извежда.

      Дъг

  2. 3

    Виждам откъде идвате и макар да не съм съгласен с всичко на 100% (имам предупреждения), компаниите винаги трябва да имат предвид това.

    1. АБСОЛЮТНО. Не мога да подчертая това достатъчно. Работил съм в малка компания, която се е занимавала с това, и изпитвах смазваща вина, че съм замесен. Толкова се радвам, че успях да се измъкна оттам. Клиентите трябва абсолютно да запазят контрола върху своите домейни. Ако имат някой достатъчно разумен, не давайте на разработчика достъп до това. Ако не, уверете се, че разработчикът има начин да промените информацията / да прехвърлите домейна чрез някакъв вид интерфейс на дистрибутор.

    2. Отчасти бих се съгласил с това, но тогава това зависи от ситуацията. Ако внедрявате просто PHP приложение и се нуждаете от хостинг с ниска цена, вземете акаунт в LunarPages или DreamHost или нещо подобно и го зарежете там. Дайте достъп на разработчика. Въпреки това нискотарифният споделен хостинг със сигурност има своите недостатъци ... особено за по-големи неща. Но ако сте достатъчно големи, за да се притеснявате за това, трябва да имате някой технически персонал, който да се справи с това. Много от тях очевидно са свързани с доверието. Разбира се, че по дяволите сте сложили нещо в договор, ако можете за подобни неща (ограничения и подобни). Хостингът на трета страна е страхотен, ако разработчикът не трябва да прави нещо фантастично. Признавам, че съм разкъсан, защото наистина е нещо ситуативно. Това също зависи от размера на сайта, от масива на използваните технологии. Ако ще бъде голямо, обмисляйки да наемете човек на персонал. Не винаги е опция, но е по-безопасна за големи неща.

    3. Това също е нещо, което направи бившата ми компания. Можете да си тръгнете, те ще ви дадат HTML, изображения и т.н. .... но няма код. Кодът беше основно наета услуга. Като се има предвид, има притежание и притежание. Винаги съм правил не-ексклузивна продажба. По принцип трябва да мога да използвам отново компонентите си. Нямам проблем с това, че клиентът го притежава, прави каквото иска с него и някой друг работи по него ... но няма да се ипотекирам и ще трябва да преоткривам колелото всеки път.

    4. Винаги. Винаги. Винаги.

  3. 4

    Хубав пост ... браво, въпреки че не съм съгласен с един елемент (# 2):

    „Чудесно е, че вашият разработчик може да има хостинг компания и да може да хоства вашия сайт вместо вас, но не го правете.“

    Въпреки че разбирам логиката зад това, в някои случаи може да бъде контрапродуктивно да се наложи вашият проект да бъде хостван някъде другаде. Ако компанията, разработваща вашия сайт или приложение, има хостинг платформа, която те предпочитат да използват, има шанс да бъде по-ефективно и продуктивно за тях да ги използват.

    Освен това, от философска гледна точка, ако откажете да използвате хостинг платформата на разработчика си, защото не искате да бъдете „държани като заложници“, това създава тон на недоверие от самото начало. Ако наистина не се доверявате достатъчно на своя разработчик, за да хоствате с тях, тогава наистина ли искате първо да работите с тях?

    Знам, че съществуват много истории на ужасите за подобен род ситуации, но като цяло бих препоръчал да се съсредоточите върху намирането на разработчик, на когото имате доверие. Можете да използвате хостинга на вашия разработчик и въпреки това да се защитите, като поискате административен достъп и направите свои собствени резервни копия.

    Отново добър пост и много полезна информация.

    Благодаря!
    Майкъл Рейнолдс

    • 5

      Hi Майкъл,

      Може да звучи като проблем с доверието, но не мисля, че е - това наистина е въпрос на контрол и отговорност. Ако ще инвестирате значителна сума в разработката на вашия уеб сайт, трябва да сте сигурни, че можете да контролирате неговата среда.

      В бизнеса се случват неща, които прекъсват връзките и не е необходимо да бъдат отрицателни. Може би вашият разработчик / фирма получава много голям клиент и не може да ви позволи да отделите време. Може би те изместват бизнес целите. Понякога тяхната хостинг компания може да има проблеми.

      Застъпвам се да контролирате и да бъдете отговорни за хостинга си, за да можете да разчитате на вашия разработчик за това, в което той е страхотен - да разработва!

      Оценявам отблъскването, Майкъл.

  4. 6

    Аз също съм разработчик на уеб приложения и мисля, че сте ударили гвоздея. Някои мисли:

    Мисля, че повечето биха се съгласили (и въз основа на коментарите по-долу) # 1 е абсолютно. Никога, никога не го прави. Някога. При всякакви обстоятелства.

    Имам различно мнение за # 2, отколкото може би някои от моите колеги разработчици: отказваме да хостваме крайния продукт за нашите клиенти (разбира се, ние хостваме тестващ сървър за клиенти, които да тестват продукта по време на разработката). Щастливи сме да помогнем на клиентите да се настроят сами да го хостват или да намерят доставчик на хостинг услуги. Ние просто не искаме да се занимаваме с хостинг. Ако това означава да отклоните работата, така да бъде. Има много страхотни хостинг компании или инфраструктурни фирми, отколкото могат да предоставят тази услуга на много по-ниска цена. Ние насърчаваме преносимостта на нашата работа и ще направим всичко възможно, за да съдействаме за нейното хостване, дори ако клиентът смени доставчиците на хостинг години по-надолу.

    За # 3 нашите клиенти получават целия изходен код на крайния продукт с едно предупреждение: За продукти на трети страни, които се използват в решението (като уеб контроли от Telerik или Component One), можем да дадем на клиента компилираната dll за контрола на трета страна (да речем мрежа). Нашите лицензионни споразумения с тези трети страни компании (които предоставяме на клиента) ни забраняват да преразпределяме изходния код за този тип контроли, тъй като това е интелектуална собственост на третите страни, а не наша. Използването на тези видове продукти спестява време за разработка на клиента и е много по-евтино от изграждането на същата функционалност от нулата. Предварително се отнасяме към тази политика, преди да свършим каквато и да е работа. Разбира се, ако клиентът желае да плати за разработка на персонализиран контрол (вместо да използва готовия продукт от трета страна), ние предоставяме изходния код за този персонализиран контрол заедно с всичко останало.

    Що се отнася до повторното използване на кода, ние сме наясно с факта, че можем да използваме повторно части от кода, освен ако той не е изрично разработен изключително за клиентска употреба (да речем за собствен бизнес процес), преди да е свършена каквато и да е работа. Ако клиентът иска да има разработен изключителен код, разбира се, това му е на разположение.

    Както казаха други, # 4 винаги се препоръчва. Винаги!

    С уважение,
    Тим Йънг

Какво мислите?

Този сайт използва Akismet за намаляване на спама. Научете как се обработват данните за коментарите ви.