SaaS
તમે દર બે અઠવાડિયે રિલીઝ કરો છો અને વર્ષે બે વાર તેના વિશે લખો છો
સોફ્ટવેર ટીમો પાસે કહેવા જેવી વસ્તુઓની અછત નથી. તેમની પાસે તે કહેનાર વ્યક્તિની અછત છે, કારણ કે રિલીઝ મોડી પડે ત્યારે લેખન એ હંમેશા એવું કામ હોય છે જે આગળ ધકેલાય છે — અને તે દર વખતે ધકેલાય છે, જ્યાં સુધી બ્લોગની સૌથી તાજી પોસ્ટ અગિયાર મહિના જૂની ન થઈ જાય અને તેમાં "રજૂઆત" ન લખાયેલું હોય.
નિષ્ફળતા માળખાકીય છે, સંપાદનની નહીં
દરેક ટીમ જાણે છે કે તેણે વધુ લખવું જોઈએ. એન્જિનિયરો લખી શકે છે; સ્થાપક લખી શકે છે; કોઈને તે ગમે છે એમ પણ બને. સમસ્યા એ છે કે લેખનની પોતાની કોઈ ડેડલાઈન નથી, અને ડેડલાઈન વગરની કોઈપણ વસ્તુ ડેડલાઈનવાળી કોઈપણ વસ્તુ સામે હારી જાય છે — દર બે અઠવાડિયે, હંમેશા.
યોજના ગુમ થયેલી ડેડલાઈન પૂરી પાડે છે. થીમ અને લેખક સાથે જોડાયેલી તારીખવાળી સ્લોટ એ શાંત અઠવાડિયે કરેલું વચન છે, જે બિનશાંત અઠવાડિયે લાગુ પડે છે, અને ડ્રાફ્ટ ત્યારે પણ દેખાય છે ભલે કોઈને યાદ હોય કે નહીં. તેને મંજૂર કરવામાં મિનિટો લાગે છે; તેને શૂન્યાતીથી લખવામાં એ બપોર લાગે છે જે ક્યારેય આવતું નથી.
આ જ આખી દલીલ છે. એ નથી કે મોડેલ તમારી ટીમ કરતાં સારું લખે છે — તે નથી લખતું. એ એ છે કે તમે મંગળવારે સંપાદિત કરેલો ડ્રાફ્ટ અસ્તિત્વમાં છે, અને તમે લખવાનો ઈરાદો રાખેલી પોસ્ટ અસ્તિત્વમાં નથી.
રોડમેપ એ યોજના છે જે તમે પહેલેથી લખી છે
છ મહિનામાંથી મોટા ભાગનું પહેલેથી નક્કી છે. તમને અંદાજે ખબર છે કે આગામી બે ત્રિમાસિકમાં શું રિલીઝ થશે, પ્રોડક્ટના કયા ભાગો ખોટા સમજાયા છે, કઈ ઈન્ટિગ્રેશન માટે તમને વારંવાર પૂછાય છે, અને સપોર્ટમાં દર અઠવાડિયે કઈ પ્રશ્નો આવે છે.
તેમાંથી દરેક એક થીમ છે. રોડમેપ લય પૂરી પાડે છે — એક રિલીઝ એક ચેન્જલોગ એન્ટ્રીને બદલે સ્લોટ્સની શ્રેણી બને છે — અને સપોર્ટ કાયમી (evergreen) અડધો ભાગ પૂરો પાડે છે, કારણ કે મહિને વીસ વાર પૂછાતો પ્રશ્ન એ એક વાર લખાયેલી અને હંમેશા લિંક થતી વસ્તુ છે.
જગ્યા ખાલી રાખો. રિલીઝ મોડી પડે છે, અને કોઈ ખાલી સ્લોટ વગરની યોજના મોડી પડેલી રિલીઝને હજુ અસ્તિત્વમાં ન હોય તેવી વસ્તુ વિશેની ત્રણ પોસ્ટ્સમાં ફેરવી દે છે. ચોથા ભાગના સ્લોટ્સ ખુલ્લા રાખવા એ ઢીલ નથી; તે યોજનાનો એ ભાગ છે જે તમારા વાસ્તવિક સમયપત્રક સાથેના સંઘર્ષમાં ટકી રહે છે.
- 1બ્લોગશું રિલીઝ થયું અને તે કેમ અસ્તિત્વમાં આવ્યું. પહેલા સમસ્યા, પછી ફીચર.
- 2Facebook / Instagramએક-વાક્યનું સંસ્કરણ, તેમના માટે જે ક્યારેય ચેન્જલોગ ખોલશે નહીં.
- 3બ્લોગકોઈએ ખરેખર તેનો ઉપયોગ કેવી રીતે કર્યો. મૂર્ત, અને અણઘડ ભાગો પણ છોડ્યા વગર.
- ·જો તે મોડી પડેસ્લોટ્સ રિલીઝ સાથે જ આવે છે. જે અસ્તિત્વમાં નથી તેની જાહેરાત કંઈપણ નથી કરતું.
- 4બ્લોગઆ રિલીઝ જે સપોર્ટ પ્રશ્નનો છેવટે જવાબ આપે છે, તે એક વાર લખાયેલો.
રોડમેપ લય નક્કી કરે છેસપોર્ટ વિષયો નક્કી કરે છે
તમારું ચેન્જલોગ કન્ટેન્ટ નથી. તે એક રસીદ છે.
બે લેખકો, ક્યારેક ત્રણ
એક જે પ્રોડક્ટ સમજાવે છે, અને એક જે કંપની વિશે વાત કરે છે
આ ખરેખર અલગ અવાજ છે, અને તેમને ભેગા કરવાથી એ ખાસ નીરસતા આવે છે જે સોફ્ટવેર બ્લોગ્સ માટે જાણીતી છે — એવી પોસ્ટ જે ન તો ટેકનિકલ સમજૂતી છે ન કોઈ વાતનું માનવીય વર્ણન.
ટેકનિકલ લેખક
કોઈ વસ્તુ શું કરે છે તે ચોક્કસપણે, વિશેષણો વગર સમજાવે છે. તમારી પ્રોડક્ટ શેના માટે છે અને શેના માટે નથી તે જાણે છે, અને તે કહેવાની પરવાનગી ધરાવે છે. જે લેખકની પોસ્ટ્સ સપોર્ટ ટિકિટ્સમાંથી લિંક થાય છે તે આ જ છે.
કંપનીનો અવાજ
નિર્ણયો, સમાધાનો અને તમે શું બનાવી રહ્યા છો તે વિશે લખે છે. માપવું મુશ્કેલ પણ ભરતી, વેચાણ મીટિંગ્સ અને કોઈ નાના વેન્ડરને મોટા કરતાં પસંદ કરવાના કારણમાં સ્પષ્ટ દેખાતી રીતે ઉપયોગી.
જવાબ આપનાર
તમારી નીતિ હેઠળના કોમેન્ટ્સ સંભાળે છે. જે શક્ય હોય તેનો જવાબ આપે છે, જે શક્ય ન હોય તે ચિહ્નિત કરે છે, અને રોડમેપ વિશે ક્યારેય અંદાજ નથી લગાવતું. સપોર્ટ ઘટના જેવું કંઈપણ તરત વ્યક્તિ પાસે જાય છે.
મંજૂરીનું ગેટ અહીં ખરેખર કામ કરે છે
બેકરી માટે બિનમંજૂર પોસ્ટ નાની શરમિંદગી છે. સોફ્ટવેર કંપની માટે તે સપોર્ટ બોજ, વેચાણ વિરોધ, અથવા એવી પ્રતિબદ્ધતા છે જેને કોઈએ સ્વીકારી નથી. મર્યાદાને થોડી ખોટી રીતે વર્ણન કરતો ડ્રાફ્ટ ગ્રાહક તમારા પર જ કહેશે, અને તારીખ સૂચવતો ડ્રાફ્ટ વચન ગણાશે.
એટલે આ એ કિસ્સો છે જ્યાં ઓટોપાયલટને સૌથી વધુ સાવધાની જોઈએ. વ્યાજબી ગોઠવણ એ છે કે પહેલેથી પ્રકાશિત વસ્તુનું પુનરાવર્તન કરતાં ટૂંકા સોશિયલ સ્લોટ્સ પર ઓટોપાયલટ, અને પ્રોડક્ટ વિશે દાવો કરતી દરેક વસ્તુ પર મંજૂરી. કિંમત, ક્ષમતા કે તારીખો વિશે કંઈપણ કાયમ વ્યક્તિ દ્વારા વંચાયું હોવું જોઈએ, અને તે લેખકના નિયમોમાં લખવું યોગ્ય છે જેથી આ પ્રકારના ડ્રાફ્ટ્સ કતારમાં જવાને બદલે રોકાઈને ચિહ્નિત થાય.
રિપોર્ટ નાની ટીમને શું કહે છે
આયોજિત વિરુદ્ધ પ્રકાશિત એ જ નંબર છે જે મહત્વ ધરાવે છે, અને સોફ્ટવેર ટીમ માટે તે સામાન્ય રીતે પહેલા ત્રિમાસમાં અસ્વસ્થ કરે છે. તે એ જ પ્રમાણભૂત માપ છે કે લેખન ફરી રિલીઝ સામે હારવાનું બંધ થયું છે કે નહીં.
પ્રતિભાવ દેખાય તેટલો મહત્વનો નથી. ટેકનિકલ લેખને પોતાનું પ્રેક્ષક મહિનાઓમાં મળે છે, દિવસોમાં નહીં, અને બીજા અઠવાડિયે તેનું મૂલ્યાંકન કરવાથી તમે એ લેખો પાછા ખેંચી લેશો જે કામ કરતા હોત. વિષય-સંતુલન શરૂમાં વધુ ઉપયોગી છે: તે બતાવે છે કે તમે ફક્ત જે રિલીઝ થયું તે વિશે જ લખો છો કે નહીં, જે પ્રમાણભૂત નિષ્ફળતાની રીત છે અને એ કારણ છે કે આટલા બધા સોફ્ટવેર બ્લોગ્સ ફકરાવાળા ચેન્જલોગ જેવા લાગે છે.
પ્રમાણભૂત વાત: જો તમારી પ્રોડક્ટ ખરેખર ટેકનિકલ હોય, તો સૌથી ઊંડા લેખોને હજી પણ એક બપોર એન્જિનિયરની જરૂર પડે છે. આયોજન જે બદલે છે તે એ કે એ બપોરના સમયપત્રકમાં આવે છે અને લેખનના બાકીના અસ્સી ટકા તેમની સાથે સ્પર્ધા કરવાનું બંધ કરે છે.