Shmangni marrjen peng nga Zhvilluesit tuaj

peng100107Këtë fundjavë fillova një bisedë me një artiste lokale e cila ka ndihmuar shefin e saj në menaxhimin e disa aplikacioneve në internet që shefi i saj zotëron.

Biseda mori një kthesë dhe disa zbrazje vazhduan për pagimin e tarifave javore të zhvillimit pa parë ndonjë përparim me zhvilluesin me të cilin kanë punuar. Tani zhvilluesi dëshiron t'u kërkojë atyre një tarifë tjetër shumë të madhe për të përfunduar projektin, si dhe një tarifë mirëmbajtje javore për të mbuluar kërkesat e tjera. Përkeqësohet.

Zhvilluesi transferoi emrat e domain-it në mënyrë që të mund t'i menaxhonte ata. Zhvilluesi gjithashtu pret aplikacionin në llogarinë e tij të pritjes. Me pak fjalë, zhvilluesi tani po i mban peng.

Fatmirësisht, gruaja me të cilën po punoj kërkoi akses administrativ në të kaluarën për të redaktuar disa nga skedarët shabllonë për sitin. Zhvilluesi mund t'i siguronte asaj qasje të kufizuar, por ai nuk e bëri. Ai (me dembeli) i dha asaj hyrjen administrative në sit. Sonte kam përdorur atë qasje për të kopjuar të gjithë kodin për sitin. Unë gjithashtu kuptova se çfarë programi menaxhimi po përdorte ai dhe shkova në administratën e bazës së të dhënave ku isha në gjendje të eksportoja të dhënat e aplikacioneve dhe strukturat e tryezës. Whew

Pronari po planifikonte të zhvendoste faqet në emra të rinj domain pasi të kishte përfunduar zhvillimi. Kjo është e madhe sepse do të thotë që domenet aktuale mund të skadojnë në rast se ka një ndarje të zemëruar midis zhvilluesit dhe kompanisë. Unë e kam parë këtë të ndodhë më parë.

Disa këshilla nëse do të merrni një ekip zhvillimi të jashtëm:

  1. Regjistrimi i Domainit

    Regjistroni emrat e domain në emrin e kompanisë suaj. Nuk është keq të keni zhvilluesin tuaj si një Kontakt Teknik në llogari, por asnjehere transferoni pronësinë e domenit tek kushdo tjetër jashtë kompanisë tuaj.

  2. Pritja e aplikacionit ose faqes tuaj

    Greatshtë mirë që zhvilluesi juaj mund të ketë një kompani pritjeje dhe mund të presë faqen tuaj për ju, por mos e bëni. Në vend të kësaj, pyesni rekomandimet e tij se ku të organizoni aplikacionin. Shtë e vërtetë që zhvilluesit njihen me programin e menaxhimit, versionet dhe vendndodhjen e burimeve dhe kjo mund të ndihmojë që produkti juaj të kompletohet më shpejt. Kjo tha, megjithatë, zotëroni llogarinë e pritjes dhe shtoni zhvilluesin tuaj me hyrjen dhe hyrjen e tij. Në këtë mënyrë, mund të tërhiqni prizën sa herë që keni nevojë.

  3. Zotëro kodin

    Mos supozoni që e keni kodin, vendoseni me shkrim. Nëse nuk doni që zhvilluesi juaj të përdorë zgjidhjet që i keni paguar atij / asaj të zhvillohen diku tjetër, duhet të vendosni që në kohën e kontratës. Unë kam zhvilluar zgjidhje në këtë mënyrë por gjithashtu i kam zhvilluar ato kur mbaj të drejtat e kodit. Në rastin e fundit, unë negociova koston e aplikimit më të ulët në mënyrë që të kishte një nxitje për kompaninë të më jepte të drejta. Nëse nuk e keni mendjen që zhvilluesi juaj të përdorë kodin tuaj diku tjetër, atëherë nuk duhet të paguani një dollar më të lartë!

  4. Merrni një mendim të dytë!

    Nuk i lëndon ndjenjat e mia kur njerëzit më thonë se po marrin oferta ose po këshillohen me profesionistë të tjerë. Në fakt, unë e rekomandoj atë!

Përfundimi është që ju po paguani për talentin e zhvilluesit tuaj, por duhet të mbani kontrollin dhe pronësinë mbi idenë. Është i juaji. Ishe ti që investove në të, ti që rrezikove biznesin tënd dhe përfitimin për të ... dhe je ti që duhet ta mbash atë. Zhvilluesit mund të zëvendësohen dhe kjo nuk duhet të vërë kurrë në rrezik aplikimin tuaj, ose më keq - biznesin tuaj.

6 Comments

  1. 1

    Unë jam një zhvillues i aplikacioneve në internet dhe jam dakord me shumicën e pikave tuaja (ndoshta të gjitha), por do të doja një sqarim për numrin 3.

    Dyfishimi me shumicë i një faqeje ose aplikacioni i shitur një kompanie tjetër (ose më keq një konkurrent) është joetik dhe duhet të përcaktohet gjithmonë si i papranueshëm në kontratën tuaj. Megjithatë, unë kam zhvilluar zgjidhje novatore për problemet e zakonshme ndërsa punoj në projektin e një klienti që nuk ka të bëjë fare me biznesin e tyre të veçantë dhe nuk përfaqëson një pjesë të rëndësishme të zgjidhjes së përgjithshme.

    Shembull:
    Klienti dëshironte që kontrolli i nivelit të faqes dhe nivelit të fushës të lidhej me rolet e përdoruesve. Funksionaliteti "jashtë kutisë" për ASP.Net bën lejet e nivelit të dosjeve. Kështu që unë zgjerova lejet vendase për .Net dhe dorëzova zgjidhjen si pjesë e një aplikacioni të përgjithshëm ueb.

    Unë besoj se ata kanë të drejtë për të gjithë bazën e kodeve (siç përcaktohet në kontratë), por ndihem i justifikuar të përdor të njëjtën metodologji dhe copa kodi për të realizuar këtë shtrirje në projektet e ardhshme.

    Një tjetër rrudhë:
    Unë e bëra këtë ndërsa po punoja nga një kompani konsulente. A do të kishte të drejtë kompania konsulente, sipas mendimit tuaj, të kthehet dhe të kopjojë atë zgjidhje, duke e reklamuar si të tyren?

    • 2

      Jo ne te vertete,

      Unë mendoj se jemi dakord. Qëllimi im në këtë është të sigurohem që ju të keni kodin dhe mund të dilni nga dera me të. Nëse zhvilluesi juaj po përpilon kodin për ju dhe po e shtyn atë në faqen tuaj - ju nuk e keni kodin. Unë e kam parë këtë të ndodhë me gjithçka, duke filluar nga grafika, Flash, .NET, Java… çdo gjë që kërkon një skedar burimi dhe që del.

      Doug

  2. 3

    E shoh se nga vjen dhe ndërsa nuk jam dakord me gjithçka 100% (kam paralajmërime), kompanitë duhet ta kenë gjithmonë parasysh këtë.

    1. ABSOLUTISHT. Nuk mund ta theksoj këtë sa duhet. Unë kam punuar për një kompani të vogël që e bëri këtë dhe ndjeva një faj të madh për përfshirjen. Jam shumë i lumtur që arrita të dal prej andej. Konsumatorët duhet të mbajnë absolutisht kontrollin e domeneve të tyre. Nëse ata kanë dikë mjaft të zgjuar, mos i jepni zhvilluesit qasje në këtë. Nëse jo, sigurohuni që zhvilluesi të ketë një mënyrë që ju të ndryshoni informacionin/transferimin e domenit nëpërmjet një ndërfaqeje rishitësi të një lloji të paktën.

    2. Unë pjesërisht do të pajtohesha me këtë, por më pas varet nga situata. Nëse jeni duke vendosur një aplikacion të thjeshtë PHP dhe keni nevojë për një pritje me kosto të ulët, me çdo kusht, merrni një llogari LunarPages ose DreamHost ose diçka tjetër dhe hidheni atje. Jepni akses zhvilluesit. Sidoqoftë, pritja e përbashkët me kosto të ulët sigurisht që ka të metat e saj ... veçanërisht për gjëra më të mëdha. Por nëse jeni mjaftueshëm i madh për t'u shqetësuar për këtë, duhet të keni dikë teknik në staf që mund të merret me të. Shumë prej tyre padyshim që kanë të bëjnë me besimin. Sigurisht, vendosni diçka në një kontratë nëse mundeni për këtë lloj gjëje (kufizime dhe të tilla). Pritja e palëve të treta është e shkëlqyeshme nëse zhvilluesi nuk ka nevojë të bëjë ndonjë gjë të zbukuruar. E pranoj se jam i shqyer sepse është me të vërtetë një gjë e situatës. Kjo varet gjithashtu nga madhësia e sitit, grupi i teknologjive të përdorura. Nëse do të jetë e madhe, mendoni të punësoni një person në staf. Jo gjithmonë një opsion, por më i sigurt për gjëra të mëdha.

    3. Kjo është gjithashtu diçka që bëri kompania ime e mëparshme. Ju mund të largoheni, ata do t'ju jepnin HTML, imazhe etj…. por pa kod. Kodi ishte në thelb një shërbim me qira. Thënë kjo, ka posedim dhe zotërim. Unë kam bërë gjithmonë një shitje jo ekskluzive. Në thelb, unë duhet të jem në gjendje të ripërdor komponentët e mi. Unë nuk kam asnjë problem që klienti ta zotërojë atë, të bëjë çfarë të dojë me të dhe që dikush tjetër të punojë në të... por unë nuk do ta hipotekoj veten time dhe do të më duhet ta rishpik timonin çdo herë.

    4. Gjithmonë. Gjithmonë. Gjithmonë.

  3. 4

    Postim i bukur… bravo edhe pse nuk jam dakord me një artikull (#2):

    “Është mirë që zhvilluesi juaj mund të ketë një kompani pritëse dhe mund të presë faqen tuaj për ju, por mos e bëni atë.”

    Megjithëse e kuptoj logjikën që qëndron pas kësaj, mund të jetë kundërproduktive në disa raste të urdhërosh që projekti yt të strehohet diku tjetër. Nëse kompania që zhvillon faqen ose aplikacionin tuaj ka një platformë pritëse që ata preferojnë ta përdorin, shanset janë që do të jetë më efikase dhe produktive për ta që ta përdorin atë.

    Për më tepër, nga pikëpamja filozofike, nëse refuzoni të përdorni platformën e pritjes së zhvilluesit tuaj sepse nuk dëshironi të "mbaheni peng", atëherë kjo krijon një ton mosbesimi që në fillim. Nëse vërtet nuk i besoni mjaftueshëm zhvilluesit tuaj për të pritur me ta, atëherë a dëshironi vërtet të punoni me ta në radhë të parë?

    E di që ekzistojnë shumë histori horror për këtë lloj situate, por në përgjithësi unë do t'ju rekomandoja që të përqendroheni në gjetjen e një zhvilluesi të cilit i besoni. Mund të përdorni hostin e zhvilluesit tuaj dhe gjithsesi të mbroni veten duke kërkuar qasje administrative dhe duke bërë kopje rezervë.

    Përsëri, postim i mirë dhe informacion shumë i dobishëm.

    Thanks!
    Michael Reynolds

    • 5

      Hi Michael,

      Mund të tingëllojë si një çështje besimi, por nuk mendoj se është – është me të vërtetë një çështje kontrolli dhe përgjegjësie. Nëse do të investoni një shumë të konsiderueshme në zhvillimin e faqes tuaj të internetit, atëherë duhet të jeni të sigurt se mund të kontrolloni mjedisin e saj.

      Në biznes ndodhin gjëra që prishin marrëdhëniet dhe nuk duhet të jenë negative. Ndoshta zhvilluesi/firma juaj ka një klient shumë të madh dhe nuk mund t'ju përballojë kohën. Ndoshta ata ndryshojnë objektivat e biznesit. Ndonjëherë kompania e tyre pritëse mund të ketë probleme.

      Unë jam duke mbrojtur që ju të kontrolloni dhe të jeni përgjegjës për pritjen tuaj, në mënyrë që të mund të vareni nga zhvilluesi juaj për atë në të cilën ai është i shkëlqyeshëm – zhvillimi!

      E vlerësoj shtyrjen, Michael.

  4. 6

    Unë jam gjithashtu një zhvillues i aplikacioneve në internet dhe mendoj se ju keni goditur në kokë. Disa mendime:

    Unë mendoj se shumica e të gjithëve do të pajtoheshin (dhe ka bazuar në komentet më poshtë) #1 është absolut. Asnjëherë, kurrë mos e bëj atë. ndonjëherë. Në çdo rrethanë.

    Unë kam një pikëpamje të ndryshme për numrin 2 sesa ndoshta disa nga zhvilluesit e mi të tjerë: ne refuzojmë të presim produktin përfundimtar për klientët tanë (natyrisht, ne presim një server testimi për klientët që të testojnë produktin gjatë zhvillimit). Ne jemi të lumtur t'i ndihmojmë klientët të vendosen për ta pritur atë vetë ose për të gjetur një ofrues pritës. Ne thjesht nuk duam të hyjmë në biznesin e pritjes. Nëse kjo do të thotë të heqësh dorë nga puna, kështu qoftë. Ka shumë kompani të shkëlqyera pritëse ose firma infrastrukturore atje sesa mund ta ofrojnë këtë shërbim me një çmim shumë më të lirë. Ne inkurajojmë transportueshmërinë e punës sonë dhe do të bëjmë ç'të mundemi për të ndihmuar që ajo të strehohet, edhe nëse klienti ndërron ofruesin e pritjes vite më vonë.

    Për numrin 3, klientët tanë marrin të gjithë kodin burimor të produktit përfundimtar me një paralajmërim: për produktet e palëve të treta që përdoren në zgjidhje (të tilla si kontrollet e uebit nga Telerik ose Component One), ne mund t'i japim klientit dll-në e përpiluar për kontrolli i palës së tretë (të themi një rrjet). Marrëveshjet tona të licencimit me ato kompani të palëve të treta (të cilat ne i ofrojmë klientit) na ndalojnë të rishpërndajmë kodin burimor për ato lloj kontrollesh, sepse është pronë intelektuale e palëve të treta, jo e jona. Përdorimi i këtyre llojeve të produkteve kursen kohën e zhvillimit për klientin dhe është shumë më i lirë sesa ndërtimi i të njëjtit funksionalitet nga e para. Ne jemi të përgjegjshëm për këtë politikë përpara se të kryhet ndonjë punë. Sigurisht, nëse klienti dëshiron të paguajë për zhvillimin e kontrollit me porosi (në vend që të përdorë produktin e para-ndërtuar nga pala e tretë), ne ofrojmë kodin burimor për atë kontroll me porosi së bashku me gjithçka tjetër.

    Kur bëhet fjalë për ripërdorimin e kodit, ne jemi paraprakisht për faktin se mund të ripërdorim pjesë të kodit, përveç nëse ai është zhvilluar shprehimisht ekskluzivisht për përdorimin e klientit (të themi për një proces biznesi të pronarit) përpara se të kryhet ndonjë punë. Sigurisht, nëse klienti dëshiron të ketë kod ekskluziv të zhvilluar, ai është i disponueshëm për ta.

    Siç kanë thënë të tjerët, #4 rekomandohet gjithmonë. Gjithmonë!

    Regards,
    Tim Young

Çfarë mendoni ju?

Kjo faqe përdor Akismet për të reduktuar spamin. Mësoni se si përpunohet komenti juaj.