Cine este răspunzător de update?

Plecând de la discuția de aici dar nelimitându-ne la WordPress: cum procedați cu actualizările diverselor părți din aplicație? Începând de la bibliotecile simple (gen jQuery) terminând cu framework-uri (Laravel, Zend etc) sau cu CMS-uri (indiferent că-i WP, Drupal, Magento etc).

De-a lungul timpului am încercat să fac actualizările gratuit la WP și plugin-uri dar am plugin-uri care sunt predispuse la a strica chestii (WPML sau ACF) și am ceva rețineri să mă înham la a face update gratuit - cred că aș avea nevoie de cel puțin o zi pentru a actualiza toate site-urile făcute până acum și pentru a trece printr-o verificare sumară.

A doua variantă ar fi să încasez o sumă pentru mentenanță, dar suma ar fi prea mică pentru timpul necesar operațiunilor de mai sus și rezolvarea problemelor ce ar putea să se ivească.

A treia variantă ar fi să le las așa cum sunt și să rezolv probleme doar dacă apar în timp, pe principiul if ain’t broken, don’t fix it.

1 Like

eu cred ca updateul inseamna timp cheltuit, deci bani; poate fi necesar doar daca adaugi functionalitati noi, iar atunci oferta de pret va include si aducerea la zi

1 Like

Teoretic, da. Practic, fiind vorba de WP, mai bine faci update-urile, că nu vrei să te trezești cu bube de securitate. Evident, pe bani. Dacă ai clienți care nu vor să plătească update-urile, atunci aia e, vor veni la tine să le repari chestii și atunci o să coste mai mult.

Cumva aici apar costurile neprevăzute cu WP-ul - pe partea de mentenanță. E mai ieftin și mai rapid să faci un site în WP, dar mai scump pe termen lung, sau cel puțin așa ar trebui să fie.

Păi da, dar chestia e alta: dacă ceva nu merge bine cine va fi de vină în ochii clientului? WordPress sau ce am făcut eu?

Exact, ii costa pe ei, pt ca ei au nevoie de update.

Se poate spune si ca nu ei au ales acea solutie tehnica, dar e un argument usor de demontat, pr ca un cod manual e sigur mai buggy, doar ca mai putin expus.

Păi aici ai două probleme:

  1. Clientul trebuie să înțeleagă ce e WP-ul și să-și asume faptul că plătește mai puțin inițial (versus un CMS custom). Și e treaba ta să-l faci să înțeleagă asta, că tu-i oferi soluția tehnică.

  2. Clientul trebuie să înțeleagă faptul că tu i-ai livrat un produs și a plătit pentru asta. Da, e normal să repari eventualele buguri descoperite în X săptămâni de la predare, dar de aici și până la a face mentenanță cu update-uri și tot ce presupune asta e cale lungă. E tot treaba ta ca ofertant de soluție să faci asta.

Important e să înțeleagă că tu le livrezi un produs și nu un serviciu. Atâta vreme cât la momentul livrării îi este clar că nu poate să-ți dea mail săptămânal și să te roage să-i mai modifici ceva sau să-i încarci conținut nu o să se te considere un webmaster ca să aibă pretenții de lucruri gratis de la tine.

Și, da, codul manual poate e mai buggy uneori, dar adevărul e că la un site de prezentare sau ceva platforme foarte simple nu văd cum ai putea să dai greș și să fie mai nasol decât cu un codebase ca WP.

4 Likes

Intrebare: clientul iti cere un un wordpress? sau tu i-l dai?

Pentru ca daca ti-l cere, e clar ca isi asuma anumite elemente: cum ar fi nevoia de update-uri de securitate dese, intrarea intr-o zona des frecventata de catre spammeri/searcher de exploit-uri etc si atunci el trebuie sa isi evalueze riscurile vs plata ameliorarea/inlaturarea lor.

Daca nu il cere, atunci nu este in carca lui sa “fii stiut despre ce trebuia sa se astepte”.

Orice ar fi situatia (wordpress, software custom) ar trebui sa existe o perioada limitata (de un an/doi) in care update-urile de securitate sa intre automat in contract (si puse in suma initiala).

p.s: Cine ar lua o masina de spalat vase fara garantie?