Undgå at blive taget som gidsel af dine udviklere

gidsler100107I weekenden startede jeg en samtale med en lokal kunstner, der har bistået sin chef med styringen af ​​et par webapplikationer, som hendes chef ejer.

Samtalen tog en drejning, og nogle udluftninger fortsatte med at betale ugentlige udviklingsgebyrer uden at se nogen fremskridt med den udvikler, de har arbejdet med. Nu vil udvikleren opkræve dem endnu et engangsbeløb for at gennemføre projektet samt et ugentligt vedligeholdelsesgebyr til dækning af andre anmodninger. Det bliver værre.

Udvikleren overførte domænenavnene, så han kunne administrere dem. Udvikleren er også vært for applikationen på sin hostingkonto. Kort sagt holder udvikleren dem nu som gidsler.

Heldigvis krævede den kvinde, jeg arbejder med, tidligere administrativ adgang til at redigere nogle af skabelonfilerne til webstedet. Udvikleren kunne have givet hende begrænset adgang, men det gjorde han ikke. Han (dovent) forsynede hende det administrative login til stedet. I aften brugte jeg denne adgang til at sikkerhedskopiere al koden til webstedet. Jeg fandt også ud af, hvilken styringssoftware han brugte, og vej til databaseadministrationen, hvor jeg var i stand til at eksportere både applikationsdata og tabelstrukturer. Whew.

Ejeren planlagde at flytte webstederne til nye domænenavne, når udviklingen var afsluttet. Det er enormt, fordi det betyder, at de nuværende domæner kan udløbe, hvis der er en vred adskillelse mellem udvikleren og virksomheden. Jeg har set dette ske før.

Nogle tip, hvis du vil få et outsourcet udviklingsteam:

  1. domæne Registrering

    Registrer dine domænenavne i din virksomheds navn. Det er ikke dårligt at have din udvikler som teknisk kontaktperson på kontoen, men aldrig overføre ejerskab af domænet til nogen uden for din virksomhed.

  2. Hosting din applikation eller dit websted

    Det er dejligt, at din udvikler måske har et hostingfirma og kan være vært for dit websted for dig, men gør det ikke. Spørg i stedet hans anbefalinger om, hvor applikationen skal være vært. Det er rigtigt, at udviklere bliver fortrolige med styringssoftwaren, versionerne og placeringen af ​​ressourcer, og det kan hjælpe dit produkt med at blive afsluttet hurtigere. Når det er sagt, skal du dog eje hostingkontoen og tilføje din udvikler med sit eget login og adgang. På denne måde kan du trække i stikket, når du har brug for det.

  3. Ej koden

    Antag ikke, at du ejer koden, skriv den skriftligt. Hvis du ikke vil have, at din udvikler bruger de løsninger, du betalte ham / hende for at udvikle andre steder, skal du beslutte det på tidspunktet for kontrakten. Jeg har udviklet løsninger på denne måde, men jeg har også udviklet dem, hvor jeg bevarer rettighederne til koden. I sidstnævnte tilfælde forhandlede jeg omkostningerne ved ansøgningen lavere, så der var et incitament for virksomheden til at give mig rettigheder. Hvis du ikke har noget imod din udvikler, der bruger din kode et andet sted, skal du ikke betale top dollar!

  4. Få en ny mening!

    Det skader ikke mine følelser, når folk fortæller mig, at de tager bud eller konsulterer med andre fagfolk. Faktisk anbefaler jeg det!

Bundlinjen er, at du betaler for din udviklers talent, men du skal bevare kontrol og ejerskab over ideen. Det er din. Det var dig, der investerede i det, du, der risikerede din forretning og rentabilitet for det ... og det er dig, der skal beholde det. Udviklere kan udskiftes, og det bør aldrig sætte din ansøgning, eller værre - din virksomhed i fare.

6 Kommentarer

  1. 1

    Jeg er en webapp-udvikler, og jeg er enig med de fleste af dine punkter (måske alle), men jeg vil gerne have en afklaring på nr. 3.

    Engroskopiering af et websted eller en applikation, der sælges til et andet firma (eller værre en konkurrent) er uetisk og bør altid angives som ikke acceptabelt i din kontrakt. Imidlertid har jeg udviklet innovative løsninger på almindelige problemer, mens jeg arbejder på en klients projekt, der ikke har noget at gøre med deres særlige biz, og det repræsenterer heller ikke en væsentlig del af den samlede løsning.

    Eksempel:
    Kundens ønskede sideniveau og kontrol på feltniveau bundet til brugerroller. Funktionen "out of the box" for ASP.Net har tilladelser på mappeniveau. Så jeg udvidede de oprindelige tilladelser til .Net og leverede løsningen som en del af en samlet webapplikation.

    Jeg tror, ​​at de har ret til hele kodebasen (som fastsat i kontrakten), men jeg føler mig berettiget til at bruge den samme metode og kodestykker til at udføre denne udvidelse på fremtidige projekter.

    En anden rynke:
    Jeg gjorde dette, mens jeg blev opdrættet af et konsulentfirma. Ville konsulentfirmaet have ret til efter din mening at gå tilbage og kopiere den løsning og markedsføre den som deres egen?

    • 2

      Ikke rigtig,

      Jeg tror, ​​vi er enige. Mit punkt i dette er at sikre, at du har koden og kan gå ud af døren med den. Hvis din udvikler samler kode til dig og skubber den ud til dit websted - har du ikke koden. Jeg har set dette ske med alt fra grafik, Flash, .NET, Java ... alt, hvad der kræver en kildefil og er udsendt.

      Doug

  2. 3

    Jeg kan se, hvor du kommer fra, og selvom jeg ikke er enig i alt 100% (jeg har advarsler), skal virksomheder altid huske dette.

    1. HELT. Kan ikke understrege dette nok. Jeg har arbejdet for et lille firma, der gjorde dette, og jeg følte knusende skyld over at være involveret. Jeg er så glad for, at jeg var i stand til at komme ud derfra. Kunder skal absolut beholde kontrollen med deres domæner. Hvis de har nogen kloge nok, skal du ikke give udvikleren adgang til dette. Hvis ikke, skal du sørge for, at udvikleren har en måde, hvorpå du kan ændre info / overføre domænet via en forhandlergrænseflade af en slags i det mindste.

    2. Jeg er delvist enig i dette, men så afhænger det af situationen. Hvis du implementerer en simpel PHP-app og har brug for billig hosting, skal du under alle omstændigheder få en LunarPages- eller DreamHost-konto eller noget og dumpe den der. Giv udvikleren adgang. Imidlertid har low-cost delt hosting bestemt sine ulemper ... især for større ting. Men hvis du er stor nok til at bekymre dig om det, skal du have nogen teknisk personale, der kan håndtere det. Meget af det handler naturligvis om tillid. Sikker som helvede lægge noget i en kontrakt, hvis du kan om denne slags ting (begrænsninger og sådan). Tredjeparts hosting er fantastisk, hvis udvikleren ikke behøver at gøre noget fancy. Jeg indrømmer, at jeg er revet, fordi det virkelig er en situation. Det afhænger også af størrelsen på webstedet, det anvendte udvalg af teknologier. Hvis det bliver stort, overvejer du at ansætte en person til personalet. Ikke altid en mulighed, men sikrere for store ting.

    3. Dette er også noget, min tidligere virksomhed gjorde. Du kunne gå, de ville give dig HTML, billeder osv ... men ingen kode. Koden var grundlæggende en lejet tjeneste. Når det er sagt, er der at eje og eje. Jeg har altid foretaget et ikke-eksklusivt salg. Dybest set skal jeg være i stand til at genbruge mine komponenter. Jeg har ikke noget problem med, at klienten ejer det, gør hvad de vil med det og får en anden til at arbejde på det ... men jeg vil ikke pantsætte mig selv og er nødt til at genopfinde hjulet hver gang.

    4. Altid. Altid. Altid.

  3. 4

    Dejligt indlæg ... godt klaret, selvom jeg er uenig i et punkt (nr. 2):

    "Det er dejligt, at din udvikler måske har et hostingfirma og kan være vært for dit websted for dig, men gør det ikke."

    Selvom jeg forstår logikken bag dette, kan det i nogle tilfælde være kontraproduktivt at kræve, at dit projekt er vært et andet sted. Hvis virksomheden, der udvikler dit websted eller din app, har en hostingplatform, som de foretrækker at bruge, er chancerne for, at det vil være mere effektivt og produktivt for dem at bruge det.

    Derudover set fra et filosofisk synspunkt, hvis du nægter at bruge din udviklers hostingplatform, fordi du ikke ønsker at blive ”holdt som gidsler”, sætter dette en tone af mistillid fra starten. Hvis du virkelig ikke stoler på din udvikler nok til at være vært for dem, så vil du virkelig arbejde sammen med dem i første omgang?

    Jeg ved, at der findes mange horrorhistorier om denne slags situation, men generelt vil jeg anbefale, at du fokuserer på at finde en udvikler, som du stoler på. Du kan bruge din udviklers hosting og stadig beskytte dig selv ved at anmode om administrativ adgang og lave dine egne sikkerhedskopier.

    Igen, godt indlæg og meget nyttige oplysninger.

    Tak!
    Michael Reynolds

    • 5

      Hej Michael,

      Det lyder måske som et tillidsproblem, men jeg tror ikke, det er det - det er virkelig et kontrol- og ansvarsproblem. Hvis du vil investere et betydeligt beløb i din webstedsudvikling, skal du være sikker på at du kan kontrollere dets miljø.

      Der sker ting i erhvervslivet, der bryder relationer, og de behøver ikke være negative. Måske får din udvikler / virksomhed en meget stor klient og har ikke råd til dig tiden. Måske skifter de forretningsmål. Nogle gange kan deres hostingfirma have problemer.

      Jeg går ind for, at du styrer og er ansvarlig for din hosting, så du kan stole på din udvikler for, hvad han er god til - at udvikle!

      Jeg sætter pris på push-back, Michael.

  4. 6

    Jeg er også en webapp-udvikler, og jeg tror, ​​du har ramt neglen på hovedet. Nogle tanker:

    Jeg tror de fleste alle er enige (og har baseret på kommentarerne nedenfor) nr. 1 er absolut. Aldrig nogensinde gøre det. Nogensinde. Under alle omstændigheder.

    Jeg har et andet syn på nr. 2 end måske nogle af mine andre udviklere: vi nægter at være vært for det endelige produkt for vores kunder (selvfølgelig er vi vært for en testserver, som klienter kan prøvekøre produktet under udviklingen). Vi hjælper gerne klienter med at blive oprettet til at være vært for dem selv eller finde en hostingudbyder. Vi ønsker simpelthen ikke at komme i gang med hosting. Hvis det betyder at vende arbejde væk, så være det. Der er mange gode hostingfirmaer eller infrastrukturfirmaer derude, end de kan levere denne service til en meget billigere pris. Vi tilskynder bærbarheden af ​​vores arbejde og vil gøre alt, hvad vi kan, for at hjælpe med at få det hostet, selvom klienten skifter hostingudbydere år ad gangen.

    For nr. 3 får vores kunder al kildekoden til det endelige produkt med én advarsel: For tredjepartsprodukter, der bruges i løsningen (såsom webkontroller fra Telerik eller Component One), kan vi give klienten den kompilerede dll til tredjepartskontrollen (sig et gitter). Vores licensaftaler med disse tredjepartsvirksomheder (som vi leverer til klienten) forbyder os at omfordele kildekoden til den type kontrol, fordi det er tredjeparternes intellektuelle ejendom, ikke vores. Brug af disse typer produkter sparer udviklingstid for klienten og er meget billigere end at opbygge den samme funktionalitet fra bunden. Vi er på forhånd med denne politik, før noget arbejde er udført. Selvfølgelig, hvis klienten ønsker at betale for udvikling af brugerdefineret kontrol (i stedet for at bruge det forudbyggede produkt fra tredjepart) leverer vi kildekoden til den brugerdefinerede kontrol sammen med alt andet.

    Når det kommer til genbrug af kode, er vi på forhånd opmærksom på det faktum, at vi kan genbruge dele af koden, medmindre den udtrykkeligt blev udviklet udelukkende til klientens brug (sig for en proprietær forretningsproces), før noget arbejde udføres. Hvis klienten selvfølgelig ønsker at få udviklet eksklusiv kode, er den tilgængelig for dem.

    Som andre har sagt, anbefales # 4 altid. Altid!

    Hilsen,
    Tim Young

Hvad mener du?

Dette websted bruger Akismet til at reducere spam. Lær, hvordan dine kommentardata behandles.