Pazite, da vas razvijalci ne bodo vzeli za talca

talca100107Ta konec tedna sem začel pogovor z lokalno umetnico, ki svojemu šefu pomaga pri upravljanju nekaj spletnih aplikacij, ki jih ima njen šef.

Pogovor se je obrnil in nekaj odzračevanja se je nadaljevalo glede plačevanja tedenskih razvojnih prispevkov, ne da bi videli napredek pri razvijalcu, s katerim so sodelovali. Zdaj jim mora razvijalec zaračunati še en pavšal za dokončanje projekta in tedensko strošek vzdrževanja za kritje drugih zahtev. Vse slabše je.

Razvijalec je domenska imena prenesel, da jih je lahko upravljal. Razvijalec aplikacijo gosti tudi na svojem računu za gostovanje. Skratka, razvijalec jih zdaj drži za talce.

Na srečo je ženska, s katero sodelujem, v preteklosti zahtevala skrbniški dostop za urejanje nekaterih datotek predlog za spletno mesto. Razvijalec bi ji lahko omogočil omejen dostop, vendar je ni. Na spletno mesto ji je (lenobno) priskrbel skrbniško prijavo. Nocoj sem uporabil ta dostop za varnostno kopiranje celotne kode spletnega mesta. Prav tako sem ugotovil, katero programsko opremo za upravljanje uporablja, in se odpravil do administracije baz podatkov, kjer sem lahko izvozil podatke aplikacij in strukture tabel. Uf.

Lastnik je načrtoval selitev spletnih mest na nova domenska imena po zaključku razvoja. To je ogromno, ker pomeni, da lahko trenutne domene potečejo v primeru, da se med razvijalcem in podjetjem pojavi jezna ločitev. To sem že videl.

Nekaj ​​nasvetov, če želite dobiti zunanjo razvojno skupino:

  1. Registracija domen

    Imena svojih domen registrirajte v imenu svojega podjetja. Ni slabo, če je vaš razvijalec kot tehnični stik na računu, ampak nikoli prenos lastništva domene na koga zunaj vašega podjetja.

  2. Gostovanje vaše aplikacije ali spletnega mesta

    Super je, da ima vaš razvijalec morda gostiteljsko podjetje in lahko gosti vaše spletno mesto namesto vas, vendar tega ne storite. Namesto tega vprašajte njegova priporočila, kje naj gosti aplikacijo. Res je, da se razvijalci seznanijo s programsko opremo za upravljanje, različicami in lokacijo virov, kar lahko pripomore k hitrejšemu dokončanju vašega izdelka. Kljub temu pa si lastite račun za gostovanje in dodajte svojega razvijalca z lastno prijavo in dostopom. Na ta način lahko povlečete vtič, kadar koli želite.

  3. Lastnik kodeksa

    Ne domnevajte, da ste lastnik kode, dajte jo pisno. Če ne želite, da vaš razvijalec uporablja rešitve, za katere ste mu plačali, da jih razvija drugje, se morate za to odločiti v času pogodbe. Na ta način sem razvil rešitve, vendar sem jih razvil tudi tam, kjer imam pravice do kode. V slednjem primeru sem se dogovoril za nižjo ceno prijave, tako da je podjetje spodbudilo, da mi podeli pravice. Če vas moti, da vaš razvijalec kode uporablja drugje, potem ne bi smeli plačevati najvišjih dolarjev!

  4. Pridobite drugo mnenje!

    Mojih občutkov ne boli, ko mi ljudje rečejo, da dajejo ponudbe ali se posvetujejo z drugimi strokovnjaki. Pravzaprav priporočam!

Bistvo je, da plačujete za talent razvijalca, vendar morate ohraniti nadzor in lastništvo nad idejo. Tvoje je. V to ste vlagali vi, ki ste tvegali svoje podjetje in donosnost zanj ... in vi bi ga morali obdržati. Razvijalce je mogoče zamenjati in to nikoli ne sme ogrožati vaše aplikacije ali, kar je še huje - vašega podjetja.

6 Komentarji

  1. 1

    Jaz sem razvijalec spletnih aplikacij in se strinjam z večino vaših točk (morda vsemi), vendar bi rad pojasnil št. 3.

    Podvajanje spletnega mesta ali aplikacije, prodane drugemu podjetju (ali še slabšemu konkurentu), je neetično in bi moralo biti v vaši pogodbi vedno določeno kot nesprejemljivo. Vendar sem med delom na naročnikovem projektu razvil inovativne rešitve za pogoste težave, ki nimajo nič skupnega z njihovim poslom, niti ne predstavlja pomembnega dela celotne rešitve.

    primer:
    Naročnik je želel nadzor ravni strani in nivoja polja, vezan na uporabniške vloge. Funkcija »out of the box« za ASP.Net omogoča dovoljenja na ravni map. Zato sem podaljšal izvorna dovoljenja za .Net in rešitev ponudil kot del splošne spletne aplikacije.

    Verjamem, da so upravičeni do celotne zbirke kod (kot je določeno v pogodbi), vendar se mi zdi upravičeno, da uporabim isto metodologijo in dele kode za to razširitev na prihodnje projekte.

    Še ena guba:
    To sem storil, ko me je svetovalno podjetje rešilo. Bi imelo svetovalno podjetje po vašem mnenju pravico, da se vrne in kopira to rešitev in jo trži kot svojo?

    • 2

      Sploh

      Mislim, da se strinjava. Moja točka pri tem je zagotoviti, da imate kodo in lahko z njo stopite skozi vrata. Če vaš razvijalec za vas sestavlja kodo in jo potiska na vaše spletno mesto - kode nimate. Videl sem, da se to dogaja z vsem, od grafike, Flash, .NET, Java ... vsega, kar zahteva izvorno datoteko in je izpisano.

      Doug

  2. 3

    Vidim, od kod prihajate, in čeprav se ne strinjam z vsem 100-odstotno (imam opozorila), bi morala podjetja to vedno imeti v mislih.

    1. absolutno. Tega ne morem dovolj poudariti. Delal sem v majhnem podjetju, ki je to storilo, in čutil sem občutek krivde zaradi vpletenosti. Tako sem vesela, da sem lahko od tam. Stranke bi morale popolnoma ohraniti nadzor nad svojimi domenami. Če imajo koga dovolj pametnega, razvijalcu ne omogočite dostopa do tega. V nasprotnem primeru se prepričajte, da ima razvijalec način, da vsaj spremenite informacije / prenesete domeno prek neke vrste vmesnika prodajalca.

    2. Delno bi se strinjal s tem, potem pa je to odvisno od situacije. Če uvajate preprosto PHP-aplikacijo in potrebujete poceni gostovanje, vsekakor dobite račun LunarPages ali DreamHost ali kaj podobnega in ga tja odložite. Omogočite razvijalcu dostop. Vendar ima poceni gostovanje v skupni rabi zagotovo svoje pomanjkljivosti ... zlasti pri večjih stvareh. Če pa ste dovolj veliki, da vas skrbi, bi morali imeti nekoga tehničnega uslužbenca, ki bi se lahko lotil tega. Veliko gre očitno za zaupanje. Seveda je hudič dal kaj v pogodbo, če lahko o takšnih stvareh (omejitve in podobno). Gostovanje tretjih oseb je super, če razvijalcu ni treba narediti ničesar modnega. Priznam, da sem raztrgana, ker gre res za situacijsko stvar. Odvisno je tudi od velikosti spletnega mesta in vrste uporabljenih tehnologij. Če bo veliko, razmislite o najemu osebe v osebju. Ni vedno možnost, vendar je varnejša za velike stvari.

    3. To je storilo tudi moje nekdanje podjetje. Lahko odidete, dali bi vam HTML, slike itd. vendar brez kode. Koda je bila v bistvu zakupljena storitev. Glede na to obstaja lastništvo in lastništvo. Vedno sem prodajal neizključno. V bistvu moram biti sposoben ponovno uporabiti svoje komponente. Nimam težav s tem, da bi ga stranka imela v lasti, da bi delala, kar hoče z njo, in da bi nekdo drug delal po njej ... toda ne bom se zastavil in moral bom vsakič znova izumiti kolo.

    4. Vedno. Nenehno. Nenehno.

  3. 4

    Lepa objava ... dobro opravljeno, čeprav se ne strinjam z enim elementom (# 2):

    "Super je, da ima vaš razvijalec morda gostiteljsko podjetje in lahko gosti vaše spletno mesto namesto vas, vendar tega ne storite."

    Čeprav razumem logiko tega, je lahko v nekaterih primerih kontraproduktivno, če bi zahtevali, da vaš projekt gosti nekje drugje. Če ima podjetje, ki razvija vaše spletno mesto ali aplikacijo, gostovalno platformo, ki jo raje uporablja, je verjetno, da bo zanje učinkovitejše in bolj produktivno.

    Poleg tega s filozofskega stališča, če zavrnete uporabo platforme za gostovanje vašega razvijalca, ker ne želite biti »talec«, potem to že od samega začetka daje ton nezaupanja. Če resnično ne zaupate svojemu razvijalcu, da bi lahko gostoval pri njih, ali resnično sploh želite sodelovati z njimi?

    Vem, da o tovrstnih situacijah obstaja veliko grozljivih zgodb, vendar bi na splošno priporočal, da se osredotočite na iskanje razvijalca, ki mu zaupate. Uporabite lahko gostovanje razvijalca in se še vedno zaščitite tako, da zahtevate skrbniški dostop in ustvarite lastne varnostne kopije.

    Spet dobra objava in zelo koristne informacije.

    Hvala!
    Michael Reynolds

    • 5

      Živijo Michael,

      Morda se sliši kot vprašanje zaupanja, vendar mislim, da ni - to je res vprašanje nadzora in odgovornosti. Če boste v razvoj spletnega mesta vložili velik znesek, morate biti prepričani, da lahko nadzirate njegovo okolje.

      V poslu se dogajajo stvari, ki prekinjajo odnose in ni nujno, da so negativne. Morda vaš razvijalec / podjetje dobi zelo veliko stranko in si ne more privoščiti časa. Morda spremenijo poslovne cilje. Včasih ima lahko njihovo gostiteljsko podjetje težave.

      Zagovarjam, da nadzirate in odgovarjate za svoje gostovanje, tako da boste lahko odvisni od svojega razvijalca, v čem je odličen - v razvoju!

      Cenim povratni udarec, Michael.

  4. 6

    Sem tudi razvijalec spletnih aplikacij in mislim, da ste zadeli žebelj. Nekaj ​​misli:

    Mislim, da bi se večina vseh strinjala (in je na podlagi komentarjev spodaj) # 1 absolutno. Nikoli, nikoli tega ne naredi. Kdaj. V nobenem primeru.

    Drugače se strinjam s številko 2 kot morda nekateri moji kolegi razvijalci: nočemo gostiti končnega izdelka za naše stranke (seveda imamo gostiteljski strežnik za preskušanje strank, ki med razvojem preizkusijo izdelek). Z veseljem pomagamo strankam, da se pripravijo za samostojno gostovanje ali najdejo ponudnika gostovanja. Preprosto ne želimo sodelovati pri gostovanju. Če to pomeni, da delo zavrnemo, naj bo tako. Obstaja veliko odličnih družb za gostovanje ali infrastrukturnih podjetij, kot jih lahko nudi ta storitev po veliko nižji ceni. Spodbujamo prenosljivost našega dela in bomo storili vse, kar je v naši moči, da bomo lahko pomagali pri njegovem gostovanju, tudi če stranka leta zamenja ponudnika gostovanja.

    Za # 3 naše stranke dobijo vso izvorno kodo končnega izdelka z enim opozorilom: Za izdelke tretjih oseb, ki se uporabljajo v rešitvi (na primer spletne kontrole Telerik ali Component One), lahko stranki damo sestavljeni dll nadzor tretje osebe (recimo mreža). Naši licenčni sporazumi s temi tretjimi podjetji (ki jih zagotavljamo stranki) nam prepovedujejo, da ne distribuiramo izvorne kode za takšen nadzor, ker gre za intelektualno lastnino tretjih oseb, ne pa za našo. Uporaba teh vrst izdelkov naročniku prihrani čas za razvoj in je veliko cenejša kot gradnja enake funkcionalnosti iz nič. Pred začetkom kakršnega koli dela smo vnaprej v tej politiki. Seveda, če želi stranka plačati za razvoj nadzora po meri (namesto da uporablja vnaprej zgrajen izdelek tretje osebe), skupaj z vsem ostalim zagotovimo izvorno kodo za ta nadzor po meri.

    Pri ponovni uporabi kode vnaprej vemo, da lahko del kode ponovno uporabimo, razen če je bila izrecno razvita izključno za strankino uporabo (recimo za lastniški poslovni postopek), preden je opravljeno kakršno koli delo. Če želi stranka seveda razviti ekskluzivno kodo, ji je ta na voljo.

    Kot so rekli že drugi, je vedno priporočljiva številka 4. Nenehno!

    S spoštovanjem,
    Tim Young

Kaj menite?

Ta stran uporablja Akismet za zmanjšanje nezaželene pošte. Preberite, kako se vaš komentar obravnava.