„Baigta“ svetainė yra mitas: įtikinkite savo vadovą priežiūros reikalingumu

Santrauka

Dauguma mažų marketingo komandų paleidimą laiko finišo linija, tačiau veikianti svetainė yra nuolatinė atsakomybė: domenus reikia atnaujinti, hostingą – apmokėti, programinę įrangą – taisyti, o turinį – atnaujinti. Pasiūlymas netechniniam vadovui žlunga, kai jis pateikiamas kaip „daugiau svetainės darbų“, ir pavyksta, kai jis pateikiamas kaip pajamų ir reputacijos apsauga. Šiame straipsnyje aptariamas tikrasis nesėkmės scenarijus – svetainė, kuri tyliai nyksta po paleidimo – ir pateikiamas praktiškas pagrindimas priežiūros biudžetui, naudojant konkrečius pavyzdžius, susijusius su domeno registracija, saugumu ir matomumu paieškoje. Jame aptariamas mąstymo pokytis nuo projekto prie sistemos, konkrečios užduotys, kurios turi būti atliktos po paleidimo, ir pokalbis, kuris iš tikrųjų įtikina vadovą. Taip pat sužinosite, kodėl saugumo argumentas neturėtų prasidėti nuo hakerių ir kaip susieti priežiūrą su verslo rezultatais, o ne su techniniais darbais.

Jūsų vadovas ką tik paskelbė, kad svetainė „baigta“ – tad kodėl nuo šio žodžio skrandyje susitraukia gumulas?

Jūs tai jau patyrėte. Paleidote prieš keturias savaites, ir džiaugsmas beveik nesuslūgo. Tada ateina pirmasis redagavimo prašymas (kainų puslapyje yra klaida). Tada pardavėjas klausia, ar kas nors patikrino, kodėl svetainė dingo iš Google. Tada jūsų slaptažodžių tvarkyklė praneša apie prisijungimą, kurio nepripažįstate. Nieko nėra katastrofiškai sulūžę, ir tai yra problema: svetainė nyksta šimtu smulkių būdų, o jūsų vadovas vis dar tiki, kad projektas baigtas, nes niekas jam nesakė, kad veikianti svetainė reikalauja nuolatinio darbo.

Tai tikroji spraga. Svetainių kūrimo vadovai paprastai apima planavimą, informacijos architektūrą, wireframe'us, dizainą, turinį, programavimą, testavimą ir paleidimą. Tai ta pati spraga, dėl kurios žmonės praleidžia planavimo etapą, kurį praleidžia dauguma naujų svetainių savininkų, tik šįkart tai etapas po paleidimo. Priežiūra yra devintas, nematomas etapas, ir būtent jis lemia, ar jūsų svetainė lieka turtu, ar pamažu virsta našta.

Šios spragos kaina nematoma, kol netampa apčiuopiama: domenas, kuris nustoja galioti per produkto pristatymą, atsarginė kopija, kuri tyliai sugenda likus savaitei iki perkūrimo, forma, kuri mėnesį nieko nesurenka. Nė vienas iš šių dalykų nėra dramatiškas. Visi jie yra brangūs.

Kūrimo režimas ir veikimo režimas – skirtingi darbai

Galvokite apie savo svetainę taip, kaip galvotumėte apie jūsų valdomą nekilnojamąjį turtą. Pastato statyba yra projektas; jo eksploatacija – procesas. Nestatytumėte sandėlio ir niekada netikrintumėte stogo, neužsakytumėte atsargų ar nekeistumėte spynų, kai darbuotojas išeina. Svetainė elgiasi taip pat, tačiau skirtumas tarp projekto ir proceso prarandamas, nes statybinės medžiagos yra skaitmeninės, o išlaidos – mažos.

Šis skirtumas svarbus dėl vienos priežasties: jis keičia tai, ką jūsų vadovas tvirtina. Kūrimo režime tikslas yra „padaryti realybę“. Veikimo režime tikslas yra „išlaikyti patikimą“. Toliau pateikta lentelė yra versija, kurią naudoju su netechniniais suinteresuotaisiais subjektais, nes ji susieja kiekvieną dalyką, kuris atrodo „baigtas“, su tuo, ką jis iš tikrųjų reiškia svetainei veikiant.

Sritis	Ką vadovas mano, kad reiškia „baigta“	Ką „baigta“ iš tikrųjų reiškia
Domenas	Nusipirkome adresą, tad jis mūsų	Adresas registruotas tam tikram laikotarpiui; pagal ICANN proceso aprašymą, jūs pasirenkate pavadinimą, patikrinate prieinamumą per registratorių ir pateikiate kontaktinius duomenis. Šie duomenys nustato, kas gauna atnaujinimo pranešimus, todėl jie turi būti teisingi ir stebimi
Hostingas	Failai yra kažkur internete	IBM apibrėžia interneto prieglobą kaip jūsų svetainės failų saugojimą serveryje, kad jie būtų pasiekiami internete. Tas serveris yra pasikartojantis santykis su kaštais, ir kažkas turi žinoti, kaip į jį prisijungti
Programinė įranga	Paleidome naujausią versiją	Programinė įranga yra taisoma, papildiniai atnaujinami, integracijas reikia peržiūrėti. Visa tai vyksta po paleidimo, o ne prieš jį
Turinys	Tekstas buvo patvirtintas	Turinys yra pokalbis su jūsų rinka. Jis pasensta, kai keičiasi pasiūlymai, kainos, įrodymai ir produktų pavadinimai
Paieška	Google žino, kad egzistuojame	Paieškos variklius reikia iš naujo aplankyti; XML sitemap'us reikia papildyti naujais URL, robots.txt failai turi išlikti tikslūs, o techninis pagrindas turi išlikti sveikas

Šią lentelę galite skaityti dvejopai. Kaip darbų sąrašą – ji slegia. Kaip aprašymą, kas iš tikrųjų yra jūsų svetainė – sistema su jūsų valdomomis įvestimis – ji aiškina. Jūsų vadovas neklysta norėdamas užbaigtumo. Jie klysta dėl to, kaip atrodo užbaigtumas.

Čia yra ir no-code įspėjimas. Jei jūsų svetainė sukurta naudojant „drag-and-drop“ konstruktorių, platformos tiekėjas tvarko serverio kodą, tačiau jūsų turinys, prieigos ir integracijos vis tiek reikalauja priežiūros. No-code pašalina daug kūrimo darbų; jis nepašalina veikimo režimo darbų.

Paverskite priežiūrą kalendoriumi, o ne bauginančia istorija

Taigi nuo ko pradėti? Ne nuo dramatiško saugumo pristatymo. Pradėkite nuo konkrečiausios, mažiausiai emocijų keliančios pasikartojančios užduoties ir sukurkite aplink ją kalendorių.

Paimkite domeną. Įsivaizduokite, kad įkūrėjas jį užregistravo prieš penkerius metus su asmeniniu el. paštu. Registratoriaus valdymo skydelis yra už prisijungimo, kurį žino tik vienas žmogus. ICANN domeno registracijos procesas prasideda pasirinkus pavadinimą, patikrinant prieinamumą per registratorių ir pateikiant kontaktinę informaciją – ta kontaktinė informacija yra virvė, jungianti registratorių su realiu žmogumi. Jei kontaktinis el. paštas nėra stebimas, atnaujinimo pranešimas gali nukristi į niekieno neskaitytą pašto dėžutę. Sprendimas nėra technologinis pertvarkymas; tai eilutė skaičiuoklėje, bendras pašto dėžutės adresas ir kalendoriaus priminimas likus trims savaitėms iki atnaujinimo. Tai nuobodu. Būtent todėl tai puikus pirmasis punktas: tai įrodo, kad priežiūra sudaryta iš mažų, lengvai atliekamų užduočių.

Dabar imkitės hostingo. IBM paaiškinimas skamba paprastai – jūsų failai gyvena serveryje – tačiau kiekvienas serveris turi saugyklos limitus, pralaidumo kaštus ir prisijungimo duomenis. Jei žmogus, kuris nustatė hostingą, yra tas pats, kuris nustatė domeną, ir tas žmogus išėjo prieš šešis mėnesius, jums trūksta vieno prisijungimo iki užsidarymo nuosavoje svetainėje. Priežiūros sprendimas – perkelti visas paslaugas į vieną dokumentą, nurodyti, kas turi prieigą, ir suplanuoti metinį auditą. Jūs neprašote didelio biudžeto. Jūs prašote valandos per mėnesį, kad durys neatsirakintų.

Ta pati logika galioja bet kuriai paslaugai, nuo kurios priklausote: el. pašto sąrašams, mokėjimo procesoriams, formų įrankiams. Kiekviena jų turi prisijungimą, atsiskaitymo ciklą ir kažką, kas turėtų galėti jį atgauti, jei pirminis savininkas išeina. Sudėkite juos visus į vieną lentelę. Kalendoriaus pradžios grožis yra tas, kad ji apeina seną „tai techninė problema“ prieštaravimą. Atnaujinimų ir prieigų peržiūrų kalendorius yra projektų valdymo problema, ir kiekvienas netechninis vadovas supranta projektų valdymą.

Grėsmė, kuri nėra hakeris

Saugumo pokalbis paprastai žlunga, nes jis prasideda nuo netinkamo piktadario. „Esame nedidelė marketingo svetainė“, – sakote sau. „Niekas mūsų netyčia.“ Ir tikriausiai esate teisus – tačiau labiausiai tikėtina grėsmė nėra tikslingas hakeris. Tai aplaidumas.

UpGuard svetainių saugumo vadovas išvardija standartines priemones: atnaujinkite programinę įrangą, taikykite stiprų autentifikavimą, pvz., daugiafaktorį autentifikavimą, apribokite naudotojų teises, kurkite atsargines kopijas ir naudokite SSL/TLS šifravimą. Kad ir ką pastebėtumėte šiame sąraše, svarbi dalis yra veiksmažodžio laikas. Tai nuolatinės praktikos, o ne paleidimo dienos langeliai.

Padarykime tai konkrečiai. Daugelis vidaus komandų paveldi svetainę su vienu bendru administratoriaus prisijungimu, kurį naudoja visi: pardavimų komanda, marketingo praktikantas, laisvai samdomas darbuotojas, parašęs vieną tinklaraščio įrašą. Niekas nežino, kas buvo tas laisvai samdomas darbuotojas. UpGuard tai vadintų naudotojų teisių problema; jūs galite tai vadinti rizika, kurią jūsų vadovas jau supranta. Jei nežinote, kas gali prisijungti, nežinote, kas gali redaguoti pagrindinį puslapį, keisti kainas ar įdiegti tai, ko neturėtų būti. Sprendimas paprastas: iš naujo nustatykite slaptažodžius, sukurkite individualias paskyras ir pašalinkite prieigą, kai žmonės išeina. Tai ne saugumo projektas; tai saugumo kasdienybė.

Pateiksiu prieštaringą pasiūlymą: nepradėkite nuo saugumo, kai prašote biudžeto. Mažai komandai žodis „saugumas“ sukelia arba „mes neturime IT biudžeto“, arba „tai mums neatsitiks“. Veiksmą sukelia konkretus artimas įvykis: naršyklės įspėjimas dėl pasibaigusio SSL/TLS sertifikato, atsarginė kopija, kuri niekada nesuveikė, buvęs rangovas, kuris vis dar gali prisijungti. Naudokite šiuos konkrečius pavyzdžius, kad pagrįstumėte mėnesinį „svetainės sveikatos“ bloką. Jūs neparduodate baimės; jūs parduodate kompetenciją.

O jei dabar kuriate naują svetainę, no-code svetainės paleidimą su SEO ir saugumu nuo pirmos dienos jau aptarėme kitur – tačiau pirmosios dienos disciplina atsiperka tik tada, kai tampa dvylikto mėnesio disciplina.

Paieška jūsų nelaukia

Antroji svetainės nykimo priežastis yra tylesnė, nes ji vyksta už svetainės ribų. Paieškos sistemų optimizavimas nėra vienkartinis nustatymas. Skaitmeninės rinkodaros instituto vadovas SEO apibūdina kaip turinio, struktūros ir techninių elementų optimizavimą, siekiant pagerinti paieškos pozicijas, naudotojo patirtį ir prekės ženklo patikimumą. Žodis „optimizavimas“ reiškia pokyčius laikui bėgant, o ne baigtą būseną.

Realistiškas scenarijus: jūsų pardavimų vadovas klausia, kodėl konkurentas lenkia jus pagal jūsų paties produkto pavadinimą. Ištyrinėję randate, kad XML sitemap nebuvo atnaujintas nuo paleidimo, o robots.txt failas blokuoja dalį naujų puslapių. Abi šios techninės sąrankos užduotys pirmą dieną atrodė atliktos. Sprendimas – dešimties minučių mėnesinė peržiūra: pridėkite naujus URL prie sitemap, pateikite jį iš naujo ir patikrinkite, ar robots failas neslepia geriausio jūsų turinio. SEO rekomendacijų tyrimai taip pat nurodo HTTPS saugumą kaip techninio pagrindo dalį – o tai grįžta prie ką tik suplanuotų saugumo darbų.

Blogiausia paieškos nykimo dalis yra ta, kad ji progresuoja. Retai prarandate pozicijas per vieną dieną; prarandate vieną poziciją čia, kitą ten, kol konkurentas visiškai užima puslapio vietą. Paieška taip pat yra geriausias verslo argumentas priežiūrai, nes ji tiesiogiai susijusi su pajamomis. Svetainė, kuri nepalaiko savo paieškos infrastruktūros, nedingsta dramatiškai „hakerio“ būdu; ji tyliai perduoda klientus konkurentams, kurie palaiko savo techninę tvarką.

Kaip parduoti priežiūrą tam, kas pasirašo čekius

Tai atveda mus prie pokalbio, kurio vengėte. Turite paprašyti biudžeto ar bent jau laiko komandos kalendoriuje, ir jums reikia, kad vadovas atsakytų „taip“ nesiblaškydamas.

Pradėkite nuo pajamų apsaugos. Nesakykite „turime techninių skolų“ ar „turime atnaujinti savo CMS“. Sakykite: „svetainė yra parduotuvės vitrina, o vitrinos reikalauja nuolatinės priežiūros“. Naudokite anksčiau sudarytą priežiūros kalendorių kaip įrodymą: štai atnaujinimo datos, štai prieigų peržiūros, štai atsarginės kopijos testas, kurį atliekame kiekvieną mėnesį. Vadovo neprašoma jumis pasitikėti; jam parodoma jau veikianti sistema.

Tada duokite jiems pasirinkimą. Pateikite dvi ar tris pakopas: minimali priežiūra (domenas, hostingas, atsarginės kopijos, SSL), sveika priežiūra (pridėkite turinio atnaujinimus ir paieškos patikras) ir aktyvus augimas (pridėkite eksperimentus, nukreipimo puslapius ir specialią pagalbą). Kai sprendimą pateikiate kaip „kokio patikimumo lygio norite?“ vietoj „ar galime išleisti daugiau pinigų?“, vadovas renkasi rezultatą, o ne tvirtina technines išlaidas.

Vienas įspėjimas: vadovas vis tiek gali atsakyti „ne“. Jei taip atsitinka, imkitės dviejų didžiausių rizikų – paprastai prieigos kontrolės ir atsarginių kopijų patikros – ir vis tiek jas ištaisykite, kiek tik turite laiko. Jūs neignoruojate „ne“; jūs laimite laiko įrodyti, kad priežiūra duoda apčiuopiamą skirtumą. Tai ta pati logika, kaip ir klientų svetainių priežiūros brandos modelyje, net kai jūsų „klientas“ yra jūsų paties vidinis suinteresuotasis asmuo. Modelis perkelia svetainę nuo gaisrų prie sistemų ir veikia tiek dviejų žmonių marketingo komandoje, tiek agentūroje.

Baigtos svetainės nėra

Svetainė, kurią paleidote, nėra svetainė, kurią valdote. Ji keičiasi, nes keičiasi jūsų verslas, keičiasi programinė įranga, keičiasi ir pats internetas. Vienintelis tikras klausimas – ar valdysite tą pokytį sąmoningai, su mažu biudžetu ir kalendoriumi, ar atsitiktinai, virtinėje panikų.

Pradėkite nuo mažiausio konkretaus dalyko: vieno kalendoriaus priminimo, vieno bendro pašto dėžutės adreso, vienos paskyros peržiūros. Tie nepatrauklūs darbai nėra našta. Jie neleidžia svetainei, kurią taip sunkiai kūrėte, tyliai rūdyti po kapotu. Kai jūsų vadovas paklaus, kas toliau, nusišypsokite ir parodykite kalendorių. Tai tikrasis nuolatinis svetainės darbas.