Voorkom dat uw ontwikkelaars gegijzeld worden

gijzelaar100107Dit weekend ben ik een gesprek begonnen met een lokale kunstenaar die haar baas heeft geholpen met het beheer van een aantal webapplicaties die haar baas bezit.

Het gesprek nam een ​​wending en er ging wat lucht in over het betalen van wekelijkse ontwikkelingsvergoedingen zonder enige vooruitgang te zien bij de ontwikkelaar waarmee ze samenwerkten. Nu wil de ontwikkelaar hen nog een forfaitair bedrag in rekening brengen om het project te voltooien, evenals een wekelijkse onderhoudsvergoeding om andere verzoeken te dekken. Het wordt erger.

De ontwikkelaar heeft de domeinnamen overgedragen zodat hij ze kon beheren. De ontwikkelaar host de applicatie ook op zijn hostingaccount. Kortom, de ontwikkelaar houdt ze nu gegijzeld.

Gelukkig eiste de vrouw met wie ik werk in het verleden beheerderstoegang om enkele sjabloonbestanden voor de site te bewerken. De ontwikkelaar had haar beperkte toegang kunnen verlenen, maar dat deed hij niet. Hij gaf haar (lui) de administratieve login op de site. Vanavond heb ik die toegang gebruikt om een ​​back-up te maken van alle code voor de site. Ik ontdekte ook welke beheersoftware hij gebruikte en begaf me naar de databasebeheerder waar ik zowel de gegevens van applicaties als de tabelstructuren kon exporteren. Oef.

De eigenaar was van plan om de sites naar nieuwe domeinnamen te verhuizen zodra de ontwikkeling was voltooid. Dat is enorm, want het betekent dat de huidige domeinen kunnen vervallen in het geval dat er een boze scheiding is tussen de ontwikkelaar en het bedrijf. Ik heb dit eerder zien gebeuren.

Enkele tips als u een uitbesteed ontwikkelteam gaat krijgen:

  1. Domeinregistratie

    Registreer uw domeinnamen op de naam van uw bedrijf. Het is niet slecht om uw ontwikkelaar als technisch contactpersoon op het account te hebben, maar nooit het eigendom van het domein overdragen aan iemand buiten uw bedrijf.

  2. Uw applicatie of site hosten

    Het is geweldig dat uw ontwikkelaar mogelijk een hostingbedrijf heeft en uw site voor u kan hosten, maar doe het niet. Vraag in plaats daarvan aan zijn aanbevelingen waar u de toepassing wilt hosten. Het is waar dat ontwikkelaars vertrouwd raken met de beheersoftware, versies en locatie van bronnen, waardoor uw product sneller kan worden voltooid. Dat gezegd hebbende, bezit echter het hostingaccount en voeg uw ontwikkelaar toe met zijn eigen login en toegang. Op deze manier kun je de stekker eruit trekken wanneer dat nodig is.

  3. Bezit de code

    Ga er niet vanuit dat u de eigenaar bent van de code, maar schrijf deze op. Als u niet wilt dat uw ontwikkelaar de oplossingen gebruikt die u hem / haar hebt betaald om elders te ontwikkelen, moet u dat op het moment van het contract beslissen. Ik heb op deze manier oplossingen ontwikkeld, maar ik heb ze ook ontwikkeld waarbij ik rechten op de code behoud. In het laatste geval heb ik de kosten van de applicatie lager onderhandeld, zodat er een prikkel was voor het bedrijf om mij rechten te geven. Als je het niet erg vindt dat je ontwikkelaar je code ergens anders gebruikt, dan zou je geen topdollar moeten betalen!

  4. Krijg een second opinion!

    Het doet me geen pijn als mensen me vertellen dat ze biedingen aannemen of overleggen met andere professionals. Ik raad het zelfs aan!

Het komt erop neer dat u betaalt voor het talent van uw ontwikkelaar, maar dat u de controle en eigendom over het idee moet behouden. Het is van jou. Jij was het die erin investeerde, jij hebt je bedrijf en winstgevendheid ervoor op het spel gezet… en jij zou het moeten houden. Ontwikkelaars kunnen worden vervangen en dat mag uw toepassing, of erger nog - uw bedrijf, nooit in gevaar brengen.

6 reacties

  1. 1

    Ik ben een webapp-ontwikkelaar en ik ben het eens met de meeste van uw punten (misschien wel allemaal), maar ik zou graag een toelichting willen op punt 3.

    Het dupliceren op grote schaal van een site of applicatie die aan een ander bedrijf (of erger nog, een concurrent) is verkocht, is onethisch en moet altijd als niet-aanvaardbaar worden vermeld in uw contract. Ik heb echter innovatieve oplossingen ontwikkeld voor veelvoorkomende problemen tijdens het werken aan het project van een klant dat niets te maken heeft met hun specifieke business, noch vertegenwoordigt het een significant deel van de algehele oplossing.

    Voorbeeld:
    Klant wilde paginaniveau- en veldniveaubesturing gekoppeld aan gebruikersrollen. De "out of the box" -functionaliteit voor ASP.Net heeft machtigingen op mapniveau. Dus heb ik de native permissies voor .Net uitgebreid en de oplossing geleverd als onderdeel van een algemene webapplicatie.

    Ik geloof dat ze recht hebben op de volledige codebase (zoals bepaald in het contract), maar ik voel me gerechtvaardigd om dezelfde methodologie en stukjes code te gebruiken om deze uitbreiding voor toekomstige projecten te realiseren.

    Nog een rimpel:
    Ik deed dit terwijl ik werd uitbesteed door een adviesbureau. Zou het adviesbureau naar uw mening het recht hebben om terug te gaan en die oplossing te kopiëren en deze als hun eigen op de markt te brengen?

    • 2

      Niet echt,

      Ik denk dat we het eens zijn. Mijn punt hierbij is om ervoor te zorgen dat je de code hebt en ermee de deur uit kunt lopen. Als uw ontwikkelaar code voor u compileert en deze naar uw site pusht, heeft u de code niet. Ik heb dit met alles zien gebeuren, van afbeeldingen, Flash, .NET, Java ... alles wat een bronbestand vereist en wordt uitgevoerd.

      Doug

  2. 3

    Ik zie waar je vandaan komt en hoewel ik het niet 100% eens ben met alles (ik heb kanttekeningen), moeten bedrijven dit altijd in gedachten houden.

    1. ABSOLUUT. Ik kan dit niet genoeg benadrukken. Ik heb voor een klein bedrijf gewerkt dat dit deed en ik voelde me verpletterend schuldig omdat ik erbij betrokken was. Ik ben zo blij dat ik daar weg kon komen. Klanten moeten absoluut de controle over hun domeinen behouden. Als ze iemand hebben die slim genoeg is, geef de ontwikkelaar hier dan geen toegang toe. Als dit niet het geval is, zorg er dan voor dat de ontwikkelaar een manier voor u heeft om informatie te wijzigen / het domein over te dragen via een of andere wederverkoperinterface.

    2. Ik ben het hier gedeeltelijk mee eens, maar het hangt af van de situatie. Als je een eenvoudige PHP-app implementeert en goedkope hosting nodig hebt, zorg dan dat je een LunarPages- of DreamHost-account of zoiets hebt en dump het daar. Geef de ontwikkelaar toegang. Goedkope shared hosting heeft echter zeker zijn nadelen… vooral voor grotere dingen. Maar als je groot genoeg bent om je daar zorgen over te maken, moet je iemand technisch in dienst hebben die ermee om kan gaan. Veel gaat natuurlijk over vertrouwen. Zeker als je kunt, leg je iets in een contract over dit soort dingen (beperkingen en dergelijke). Hosting door derden is geweldig als de ontwikkelaar niets speciaals hoeft te doen. Ik geef toe dat ik verscheurd ben, want het is echt een situationeel iets. Het hangt ook af van de grootte van de site, de reeks gebruikte technologieën. Als het groot wordt, overweeg dan om iemand in dienst te nemen. Niet altijd een optie, maar veiliger voor grote spullen.

    3. Dit is ook iets wat mijn vorige bedrijf deed. Je zou kunnen vertrekken, ze zouden je de HTML, afbeeldingen enz. Geven. maar geen code. De code was in feite een gehuurde dienst. Dat gezegd hebbende, er is bezit en bezit. Ik heb altijd een niet-exclusieve verkoop gedaan. In principe moet ik mijn componenten opnieuw kunnen gebruiken. Ik heb er geen probleem mee dat de klant het bezit, ermee doet wat ze willen en dat iemand anders er langs de lijn aan werkt ... maar ik ga mezelf geen hypotheek geven en moet elke keer het wiel opnieuw uitvinden.

    4. Altijd. Altijd. Altijd.

  3. 4

    Leuke post ... goed gedaan, hoewel ik het niet eens ben met één item (# 2):

    "Het is geweldig dat uw ontwikkelaar misschien een hostingbedrijf heeft en uw site voor u kan hosten, maar doe het niet."

    Hoewel ik de logica hierachter begrijp, kan het in sommige gevallen contraproductief zijn om te verplichten dat uw project ergens anders wordt gehost. Als het bedrijf dat uw site of app ontwikkelt, een hostingplatform heeft dat ze het liefst gebruiken, is de kans groot dat het efficiënter en productiever voor hen zal zijn om het te gebruiken.

    Bovendien, vanuit filosofisch standpunt, als u weigert het hostingplatform van uw ontwikkelaar te gebruiken omdat u niet "gegijzeld" wilt worden, dan zet dit vanaf het begin een toon van wantrouwen in. Als je je ontwikkelaar echt niet genoeg vertrouwt om bij hen te hosten, wil je dan in de eerste plaats echt met hen samenwerken?

    Ik weet dat er veel horrorverhalen bestaan ​​over dit soort situaties, maar over het algemeen zou ik je aanraden om je te concentreren op het vinden van een ontwikkelaar die je vertrouwt. U kunt de hosting van uw ontwikkelaar gebruiken en uzelf toch beschermen door beheerderstoegang aan te vragen en uw eigen back-ups te maken.

    Nogmaals, goede post en zeer nuttige informatie.

    Bedankt!
    Michael Reynolds

    • 5

      Hi Michael,

      Het klinkt misschien als een vertrouwenskwestie, maar ik denk van niet - het is echt een kwestie van controle en verantwoordelijkheid. Als u een aanzienlijk bedrag in de ontwikkeling van uw website gaat investeren, moet u er zeker van zijn dat u de omgeving kunt beheersen.

      Er gebeuren dingen in het bedrijfsleven die relaties verbreken en ze hoeven niet negatief te zijn. Misschien krijgt uw ontwikkelaar / bedrijf een zeer grote klant en kan u de tijd niet betalen. Misschien verschuiven ze zakelijke doelstellingen. Soms kan hun hostingbedrijf problemen hebben.

      Ik pleit ervoor dat jij de controle hebt over en verantwoordelijk bent voor je hosting, zodat je op je ontwikkelaar kunt vertrouwen voor datgene waar hij goed in is: ontwikkelen!

      Ik waardeer de push-back, Michael.

  4. 6

    Ik ben ook een webapp-ontwikkelaar en ik denk dat je de spijker op zijn kop hebt geslagen. Sommige gedachten:

    Ik denk dat bijna iedereen het ermee eens is (en heeft op basis van de onderstaande opmerkingen) # 1 absoluut. Doe het nooit. Ooit. Onder elke omstandigheid.

    Ik heb een andere kijk op # 2 dan misschien sommige van mijn mede-ontwikkelaars: we weigeren het eindproduct voor onze klanten te hosten (natuurlijk hosten we een testserver voor klanten om het product tijdens de ontwikkeling te testen). We helpen klanten graag om het zelf te hosten of om een ​​hostingprovider te vinden. We willen gewoon niet met hosting bezig zijn. Als dat betekent dat u uw werk moet afwijzen, het zij zo. Er zijn veel geweldige hostingbedrijven of infrastructuurbedrijven die deze service tegen een veel lagere prijs kunnen bieden. We moedigen de draagbaarheid van ons werk aan en zullen er alles aan doen om te helpen het gehost te krijgen, zelfs als de klant jaren later van hostingprovider verandert.

    Voor # 3 krijgen onze klanten alle broncode van het eindproduct met één voorbehoud: voor producten van derden die in de oplossing worden gebruikt (zoals webbesturingen van Telerik of Component One), kunnen we de klant de gecompileerde dll geven voor de controle door derden (zeg maar een raster). Onze licentieovereenkomsten met die externe bedrijven (die we aan de klant verstrekken) verbieden ons om de broncode voor dat soort controles te herdistribueren, omdat dit het intellectuele eigendom van de derde partij is, niet de onze. Het gebruik van dit soort producten bespaart de klant ontwikkeltijd en is veel goedkoper dan dezelfde functionaliteit helemaal opnieuw bouwen. We zijn vooraf over dit beleid voordat er werk wordt verricht. Als de klant wil betalen voor de ontwikkeling van aangepaste besturingselementen (in plaats van het vooraf gebouwde product van de derde partij te gebruiken), leveren we natuurlijk de broncode voor die aangepaste besturing, samen met al het andere.

    Als het gaat om hergebruik van code, zijn we openhartig over het feit dat we delen van de code mogen hergebruiken, tenzij deze uitdrukkelijk exclusief is ontwikkeld voor gebruik door de klant (bijvoorbeeld voor een bedrijfseigen bedrijfsproces) voordat er werk wordt verricht. Als de klant natuurlijk exclusieve code wil laten ontwikkelen, staat die voor hem ter beschikking.

    Zoals anderen al hebben gezegd, wordt # 4 altijd aanbevolen. Altijd!

    Met vriendelijke groet,
    Tim Young

Wat denk je?

Deze site gebruikt Akismet om spam te verminderen. Ontdek hoe uw reactiegegevens worden verwerkt.