Evitați să vă luați ostatici de către dezvoltatorii dvs.

ostatic 100107În acest weekend am început o conversație cu un artist local care și-a asistat șeful cu gestionarea a câteva aplicații web pe care le deține șeful ei.

Conversația a luat o întorsătură și unele ventilații au continuat să plătească taxe de dezvoltare săptămânale fără a vedea progrese cu dezvoltatorul cu care au lucrat. Acum dezvoltatorul dorește să le perceapă o altă taxă forfetară pentru finalizarea proiectului, precum și o taxă săptămânală de întreținere pentru a acoperi alte cereri. Devine mai rău.

Dezvoltatorul a transferat numele de domeniu pentru a le putea gestiona. Dezvoltatorul găzduiește, de asemenea, aplicația pe contul său de găzduire. Pe scurt, dezvoltatorul îi ține acum ostatici.

Din fericire, femeia cu care lucrez a solicitat în trecut acces administrativ pentru a edita unele dintre fișierele șablon pentru site. Dezvoltatorul i-ar fi putut oferi acces limitat, dar el nu. El (leneș) i-a furnizat datele de conectare administrative la site. În seara asta am folosit acel acces pentru a copia tot codul site-ului. De asemenea, mi-am dat seama ce software de management folosea și m-am îndreptat spre administrarea bazei de date, unde am putut exporta atât datele aplicațiilor, cât și structurile de tabel. Vai.

Proprietarul plănuia să mute site-urile pe nume de domenii noi după finalizarea dezvoltării. Acest lucru este imens, deoarece înseamnă că domeniile actuale ar putea expira în cazul în care există o separare furioasă între dezvoltator și companie. Am mai văzut asta întâmplându-se.

Câteva sfaturi dacă veți obține o echipă de dezvoltare externalizată:

  1. Înregistrare domeniu

    Înregistrați-vă numele de domenii în numele companiei dvs. Nu este rău să aveți dezvoltatorul în calitate de contact tehnic în cont, dar nu transferați proprietatea asupra domeniului către oricine din afara companiei dvs.

  2. Găzduirea aplicației sau a site-ului dvs.

    Este minunat că dezvoltatorul dvs. ar putea avea o companie de găzduire și vă poate găzdui site-ul pentru dvs., dar nu o faceți. În schimb, cereți recomandările sale unde să găzduiască aplicația. Este adevărat că dezvoltatorii fac cunoștință cu software-ul de gestionare, versiunile și locația resurselor și care vă pot ajuta să vă finalizați produsul mai devreme. Acestea fiind spuse, totuși, dețineți contul de găzduire și adăugați dezvoltatorul cu propriile date de conectare și acces. În acest fel, puteți trage de priză ori de câte ori aveți nevoie.

  3. Dețineți codul

    Nu presupuneți că dețineți codul, puneți-l în scris. Dacă nu doriți ca dezvoltatorul dvs. să utilizeze soluțiile pe care i-ați plătit să le dezvolte în altă parte, trebuie să decideți acest lucru în momentul contractului. Am dezvoltat soluții în acest fel, dar le-am dezvoltat și acolo unde păstrez drepturile asupra codului. În acest din urmă caz, am negociat costul cererii mai mic, astfel încât compania să fie stimulată să-mi acorde drepturi. Dacă nu vă deranjează că dezvoltatorul dvs. folosește codul în altă parte, atunci nu ar trebui să plătiți dolarul cel mai mare!

  4. Ia o a doua opinie!

    Nu mă rănește sentimentele când oamenii îmi spun că fac oferte sau se consultă cu alți profesioniști. De fapt, o recomand!

Concluzia este că plătiți pentru talentul dezvoltatorului dvs., dar trebuie să păstrați controlul și proprietatea asupra ideii. Este al tau. Tu ai investit în asta, tu care ți-ai riscat afacerea și profitabilitatea pentru asta ... și tu trebuie să o păstrezi. Dezvoltatorii pot fi înlocuiți și acest lucru nu ar trebui niciodată să pună în pericol aplicația dvs. sau, mai rău - afacerea dvs.

4 Comentarii

  1. 1

    Sunt un dezvoltator de aplicații web și sunt de acord cu majoritatea punctelor dvs. (poate cu toate), dar aș dori o clarificare cu privire la numărul 3.

    Dublarea cu ridicata a unui site sau a unei aplicații vândute unei alte companii (sau, mai rău, unui concurent) nu este etică și ar trebui să fie întotdeauna stipulată ca neacceptabilă în contractul dumneavoastră. Cu toate acestea, am dezvoltat soluții inovatoare la probleme comune în timp ce lucrez la un proiect al unui client care nu are nimic de-a face cu afacerea lor particulară și nici nu reprezintă o parte semnificativă a soluției generale.

    Exemplu:
    Clientul a dorit controlul nivelului de pagină și al câmpului legat de rolurile utilizatorului. Funcționalitatea „din cutie” pentru ASP.Net oferă permisiuni la nivel de folder. Așa că am extins permisiunile native pentru .Net și am livrat soluția ca parte a unei aplicații web generale.

    Cred că au dreptul la întreaga bază de cod (așa cum este stipulat în contract), dar mă simt îndreptățit să folosesc aceeași metodologie și fragmente de cod pentru a realiza această extensie pe proiecte viitoare.

    O alta rid:
    Am făcut acest lucru în timp ce eram deținut de o companie de consultanță. Firma de consultanță ar avea dreptul, în opinia dumneavoastră, să se întoarcă și să copieze acea soluție, promovând-o ca pe a lor?

    • 2

      Nu chiar,

      Cred că suntem de acord. Ideea mea este să mă asigur că aveți codul și că puteți ieși pe ușă cu el. Dacă dezvoltatorul dvs. compila cod pentru dvs. și îl trimite pe site-ul dvs. - nu aveți codul. Am văzut că acest lucru se întâmplă cu orice, de la grafică, Flash, .NET, Java... orice care necesită un fișier sursă și este scos.

      Doug

  2. 3

    Văd de unde vii și, deși nu sunt de acord cu totul 100% (am avertismente), companiile ar trebui să țină mereu cont de asta.

    1. ABSOLUT. Nu pot sublinia asta suficient. Am lucrat pentru o companie mică care a făcut asta și m-am simțit vinovat de faptul că am fost implicat. Sunt atât de bucuros că am reușit să ies de acolo. Clienții ar trebui să păstreze absolut controlul asupra domeniilor lor. Dacă au pe cineva suficient de priceput, nu acordați acces dezvoltatorului la acest lucru. Dacă nu, asigurați-vă că dezvoltatorul are o modalitate de a schimba informațiile/transfera domeniul prin intermediul unei interfețe de reseller, cel puțin.

    2. Aș fi parțial de acord cu asta, dar apoi depinde de situație. Dacă implementați o aplicație PHP simplă și aveți nevoie de găzduire cu costuri reduse, prin toate mijloacele, obțineți un cont LunarPages sau DreamHost sau ceva și aruncați-l acolo. Oferiți acces dezvoltatorului. Cu toate acestea, găzduirea partajată la preț redus are cu siguranță dezavantajele sale... mai ales pentru lucruri mai mari. Dar dacă ești suficient de mare încât să-ți faci griji pentru asta, ar trebui să ai pe cineva tehnic în personal care se poate ocupa de asta. O mare parte este, evident, despre încredere. Sigur ca naiba pune ceva intr-un contract daca poti despre acest gen de lucruri (restrictii si altele). Găzduirea terță parte este grozavă dacă dezvoltatorul nu are nevoie să facă nimic elegant. Recunosc că sunt sfâșiat pentru că este într-adevăr o chestie situațională. Depinde și de dimensiunea site-ului, de gama de tehnologii utilizate. Dacă va fi mare, luând în considerare angajarea unei persoane din personal. Nu întotdeauna o opțiune, dar mai sigur pentru lucruri mari.

    3. Acesta este, de asemenea, ceva ce a făcut fosta mea companie. Ai putea pleca, ei ți-ar da HTML, imagini etc... dar fara cod. Codul era practic un serviciu închiriat. Acestea fiind spuse, există deținerea și deținerea. Întotdeauna am făcut o vânzare neexclusivă. Practic, trebuie să pot reutiliza componentele mele. Nu am nicio problemă cu clientul să-l dețină, să facă ceea ce vrea cu el și să pun pe altcineva să lucreze la el în continuare... dar nu mă voi ipoteca și trebuie să reinventez roata de fiecare dată.

    4. Întotdeauna. Mereu. Mereu.

  3. 4

    Bună postare... bine făcut, deși nu sunt de acord cu un articol (#2):

    „Este grozav că dezvoltatorul tău ar putea avea o companie de găzduire și poate găzdui site-ul tău pentru tine, dar nu o face.”

    Deși înțeleg logica din spatele acestui lucru, poate fi contraproductiv în unele cazuri să ordonați ca proiectul dvs. să fie găzduit în altă parte. Dacă compania care vă dezvoltă site-ul sau aplicația are o platformă de găzduire pe care preferă să o utilizeze, sunt șanse să fie mai eficient și mai productiv să o folosească.

    În plus, din punct de vedere filozofic, dacă refuzați să utilizați platforma de găzduire a dezvoltatorului dvs. pentru că nu doriți să fiți „ținut ostatic”, atunci acest lucru stabilește un ton de neîncredere de la început. Dacă într-adevăr nu aveți suficientă încredere în dezvoltatorul dvs. pentru a găzdui cu ei, atunci chiar doriți să lucrați cu ei în primul rând?

    Știu că există multe povești de groază despre acest tip de situație, dar, în general, aș recomanda să vă concentrați pe găsirea unui dezvoltator în care aveți încredere. Puteți utiliza găzduirea dezvoltatorului și vă puteți proteja în continuare solicitând acces administrativ și realizând propriile copii de siguranță.

    Din nou, postare bună și informații foarte utile.

    Multumesc!
    Michael Reynolds

    • 5

      Bună Michael,

      Poate suna ca o problemă de încredere, dar nu cred că este – este într-adevăr o problemă de control și responsabilitate. Dacă intenționați să investiți o sumă semnificativă în dezvoltarea site-ului dvs. web, atunci trebuie să fiți sigur că puteți controla mediul acestuia.

      În afaceri se întâmplă lucruri care rup relațiile și nu trebuie să fie negative. Poate că dezvoltatorul/firma dvs. primește un client foarte mare și nu vă poate permite timp. Poate că schimbă obiectivele de afaceri. Uneori, compania lor de găzduire poate avea probleme.

      Susțin ca tu să controlezi și să fii responsabil de găzduirea ta, astfel încât să poți depinde de dezvoltatorul tău pentru ceea ce se pricepe el: dezvoltarea!

      Apreciez respingerea, Michael.

  4. 6

    Sunt, de asemenea, un dezvoltator de aplicații web și cred că ai dat în cui. Cateva ganduri:

    Cred că majoritatea ar fi de acord (și pe baza comentariilor de mai jos) #1 este un absolut. Niciodată, niciodată. Vreodată. În orice împrejurare.

    Am o părere diferită de numărul 2 decât poate unii dintre colegii mei dezvoltatori: refuzăm să găzduim produsul final pentru clienții noștri (desigur, găzduim un server de testare pentru clienți pentru a testa produsul în timpul dezvoltării). Suntem bucuroși să ajutăm clienții să se configureze să îl găzduiască ei înșiși sau să găsească un furnizor de găzduire. Pur și simplu nu vrem să ne apucăm de găzduire. Dacă asta înseamnă să renunți la muncă, așa să fie. Există o mulțime de companii grozave de găzduire sau firme de infrastructură care pot oferi acest serviciu la un preț mult mai ieftin. Încurajăm portabilitatea muncii noastre și vom face tot ce putem pentru a ajuta la găzduirea acesteia, chiar dacă clientul schimbă furnizorul de găzduire de ani de zile.

    Pentru numărul 3, clienții noștri primesc tot codul sursă al produsului final cu o singură avertizare: pentru produsele terțe care sunt utilizate în soluție (cum ar fi controalele web de la Telerik sau Component One), putem oferi clientului dll-ul compilat pentru controlul terțului (să zicem o grilă). Acordurile noastre de licență cu acele companii terțe (pe care le oferim clientului) ne interzic să redistribuim codul sursă pentru aceste tipuri de controale, deoarece este proprietatea intelectuală a terților, nu a noastră. Utilizarea acestor tipuri de produse economisește timp de dezvoltare pentru client și este mult mai ieftină decât construirea aceleiași funcționalități de la zero. Suntem sinceri cu privire la această politică înainte de finalizarea oricărei lucrări. Desigur, dacă clientul dorește să plătească pentru dezvoltarea controlului personalizat (în loc să utilizeze produsul preconstruit de la o terță parte), oferim codul sursă pentru acel control personalizat împreună cu orice altceva.

    Când vine vorba de reutilizarea codului, suntem sinceri cu privire la faptul că putem reutiliza porțiuni din cod, cu excepția cazului în care acesta a fost dezvoltat în mod expres exclusiv pentru uzul clientului (să zicem pentru un proces de afaceri proprietar) înainte de finalizarea oricărei lucrări. Dacă clientul dorește să aibă un cod exclusiv dezvoltat, desigur, acesta este disponibil pentru el.

    După cum au spus alții, numărul 4 este întotdeauna recomandat. Mereu!

    Salutari,
    Tim Young

Ce părere ai?

Acest site folosește Akismet pentru a reduce spamul. Aflați cum sunt procesate datele despre comentarii.