SaaS
Ju publikoni çdo dy javë dhe shkruani për të dy herë në vit
Ekipet e softuerit nuk u mungojnë gjërat për të thënë. U mungon personi që i thotë, sepse shkrimi është gjithmonë detyra që shtyhet kur publikimi vonohet — dhe shtyhet sa herë, derisa postimi më i fundit i blogut të jetë njëmbëdhjetë muaj i vjetër dhe të thotë "prezantojmë".
Dështimi është strukturor, jo editorial
Çdo ekip e di se duhet të shkruajë më shumë. Inxhinierët dinë të shkruajnë; themeluesi dinë të shkruajnë; zakonisht dikush e shijon. Problemi është se shkrimi nuk ka afat të vetin, dhe çdo gjë pa afat humbet para çdo gjëje me afat, çdo dy javë, përgjithmonë.
Një plan furnizon afatin që mungon. Një vend me datë, me një temë dhe një shkrimtar të caktuar, është një zotim i marrë në një javë të qetë, i zbatuar në një javë që nuk është e qetë, dhe skica shfaqet qoftë e qoftë askush nuk e ka mbajtur mend. Aprovimi i saj merr minuta; shkrimi i saj nga e para merr një pasdite që nuk vjen kurrë.
Ky është gjithë argumenti. Nuk është se një model shkruan më mirë se ekipi juaj — nuk e bën. Është se një skicë që e redaktoni të martën ekziston, dhe një postim që kishit për të shkruar nuk ekziston.
Një rrugëtim është një plan që e keni shkruar tashmë
Shumica e gjashtë muajve është tashmë e vendosur. E dini përafërsisht çfarë publikohet në dy tremujorët e ardhshëm, cilat pjesë të produktit keqkuptohen, cilat integrimet ju kërkohen pa pushim dhe cilat pyetje mbërrijnë në mbështetje çdo javë.
Secili prej tyre është një temë. Rrugëpërmbledhja jep ritmin — një publikim bëhet një varg vendesh dhe jo një zë i vetëm në regjistrin e ndryshimeve — dhe mbështetja jep gjysmën e përhershme, sepse një pyetje e bërë njëzet herë në muaj është një shkrim që vlen të shkruhet një herë dhe të lidhet përgjithmonë.
Lini boshllëqe. Publikimet shtyhen, dhe një plan pa vende të lira e kthen një publikim të shtyrë në tre poste për një gjë që nuk ekziston ende. Një e katërta e vendeve të lëra bosh nuk është lëshim; është pjesa e planit që i mbijeton takimit me orarin tuaj real.
- 1BloguÇfarë u lëshua dhe pse ekziston. Së pari problemi, pastaj veçoritë.
- 2Facebook / InstagramVersioni me një fjali, për njerëzit që nuk do të hapin kurrë një regjistër ndryshimesh.
- 3BloguSi e përdori dikush në të vërtetë. Konkret, me pjesët e pakëndshme të lëna brenda.
- ·Nëse shtyhetVendet lëvizin me publikimin. Asgjë nuk njofton një gjë që nuk ekziston.
- 4BloguPyetja e mbështetjes që ky publikim përfundimisht i përgjigjet, e shkruar një herë.
Rrugëpërmbledhja cakton ritminMbështetja cakton temat
Regjistri juaj i ndryshimeve nuk është përmbajtje. Është një kupon.
Dy shkrimtarë, ndonjëherë tre
Ai që shpjegon produktin, dhe ai që flet për kompaninë
Këto janë me të vërtetë zëra të ndryshëm, dhe bashkimi i tyre prodhon atë banalitet të veçantë për të cilin njihen blogjet e softuerit — një post që nuk është as shpjegim teknik as rrëfim njerëzor i asgjëje.
Shkrimtari teknik
Shpjegon se çfarë bën një gjë, me saktësi, pa mbiemra. E di për çfarë është dhe për çfarë nuk është produkti juaj, dhe i lejohet ta thotë. Ky është shkrimtari postet e të cilit lidhen nga tiketet e mbështetjes.
Zëri i kompanisë
Shkruan për vendime, kompromise dhe për atë që po ndërtoni. I dobishëm në një mënyrë të vështirë për t'u matur dhe e dukshme në rekrutim, në takimet e shitjeve dhe në arsyen pse dikush zgjedh një shitës të vogël në vend të një të madhi.
Ajo që përgjigjet
Trajton komentet sipas politikës suaj. Përgjigjet për atë që mundet, shënon atë që nuk mundet dhe kurrë nuk spekulon për rrugëpërmbledhjen. Çdo gjë që i ngjan një incidenti mbështetje i kalohet menjëherë një personi.
Porta e miratimit po bën punë të vërtetë këtu
Për një furrë, një post i pameruar është një siklet i vogël. Për një kompani softueri është një barrë mbështetjeje, një kundërshtim shitjesh ose një angazhim që askush nuk e pranoi. Një skicë që përshkruan një kufizim pak më gabimisht do t'ju citohet nga një klient, dhe një skicë që përmend një datë do të trajtohet si premtim.
Prandaj ky është rasti ku piloti automatik meriton kujdesin më të madh. Një marrëveshje e arsyeshme është piloti automatik për vendet e shkurtra sociale që përsërisin diçka tashmë të publikuar, dhe miratimi për gjithçka që bën një pretendim për produktin. Çdo gjë për çmimin, kapacitetin ose datat duhet lexuar nga një person përgjithmonë, dhe ia vlen ta shkruani këtë në rregullat e shkrimtarit, që skicat e tillë të mbahen dhe të shënohen në vend që të radhiten.
Çfarë i tregon raporti një ekipi të vogël
I planifikuar kundrejt të publikuarit është numri që ka rëndësi, dhe për një ekip softueri zakonisht është i pakëndshëm në tremujorin e parë. Është gjithashtu e vetmja matje e sinqertë nëse shkrimi ka pushuar së humburi kundrejt publikimit përsëri.
Pritja ka më pak rëndësi sesa duket. Një shkrim teknik gjen publikun e vet gjatë muajve, jo ditëve, dhe vlerësimi i tij në javën e dytë do t'ju bëjë të tërhiqni shkrimet që do të funksiononin. Bilanci i temave është më i dobishëm herët: tregon nëse shkruani vetëm për atë që u lëshua, që është moda standarde e dështimit dhe arsyeja pse kaq shumë blogje softueri lexohen si një regjistër ndryshimesh me paragrafë.
Pjesa e sinqertë: nëse produkti juaj është me të vërtetë teknik, shkrimet më të thelluara kanë ende nevojë për një inxhinier për një pasdite. Ajo që ndryshon një plan është se ato pasdite planifikohen dhe tetëdhjetë për qind tjetër e shkrimit pushon së garuari me to.