અમે અમારા ઉત્પાદનોના વિકાસ માટે વિચારો કેવી રીતે પસંદ કરીએ છીએ: વિક્રેતા સાંભળવા માટે સક્ષમ હોવા જોઈએ...

આ લેખમાં, હું અમારા ઉત્પાદનોની કાર્યક્ષમતાના વિકાસ માટે વિચારો પસંદ કરવાના મારા અનુભવને શેર કરીશ અને મુખ્ય વિકાસ વેક્ટરને કેવી રીતે રાખવું તે તમને કહીશ.

અમે ઓટોમેટેડ સેટલમેન્ટ સિસ્ટમ (ACS) - બિલિંગ વિકસાવી રહ્યા છીએ. મુદત
અમારા ઉત્પાદનનું જીવન 14 વર્ષ છે. આ સમય દરમિયાન, સિસ્ટમ ઔદ્યોગિક રેટરના પ્રથમ સંસ્કરણોથી મોડ્યુલર સંકુલમાં ગઈ છે જેમાં 18 ઉત્પાદનોનો સમાવેશ થાય છે જે એકબીજાના પૂરક છે. કાર્યક્રમો માટે દીર્ધાયુષ્યના સૌથી મહત્વપૂર્ણ પાસાઓમાંનું એક સતત વિકાસ છે. અને વિકાસ માટે વિચારોની જરૂર છે.

વિચારો

સ્ત્રોતો

ત્યાં 5 સ્ત્રોતો છે:

1. કોર્પોરેટ માહિતી પ્રણાલીઓના વિકાસકર્તાનો મુખ્ય મિત્ર છે ગ્રાહક. અને ક્લાયંટ એ નિર્ણય નિર્માતાઓ, પ્રોજેક્ટના પ્રાયોજકો, માલિકો અને પ્રક્રિયાઓના એક્ઝિક્યુટર્સ, ઇન-હાઉસ આઇટી નિષ્ણાતો, સામાન્ય વપરાશકર્તાઓ અને મોટી સંખ્યામાં લોકો કે જેઓ વિવિધ ડિગ્રીમાં રસ ધરાવતા હોય તેમની એક સામૂહિક છબી છે. અમારા માટે તે અગત્યનું છે કે ગ્રાહકના દરેક પ્રતિનિધિ સંભવિત રીતે વિચારોના સપ્લાયર છે. સૌથી ખરાબ કિસ્સામાં, અમને સિસ્ટમમાં સમસ્યાઓ વિશે માત્ર નકારાત્મક પ્રતિસાદ મળે છે. શ્રેષ્ઠ રીતે, ક્લાયન્ટની બાજુમાં એક વ્યક્તિ છે જે સુધારણા માટે વિચારોનો સતત સ્ત્રોત છે, ક્લાયન્ટની જરૂરિયાતો વિશે સંરચિત માહિતી પ્રદાન કરે છે.
2. અમારું વિક્રેતાઓ અને એકાઉન્ટ મેનેજર સુધારણા માટેના વિચારોનો બીજો સૌથી મહત્વપૂર્ણ સ્ત્રોત છે. તેઓ ઉદ્યોગના પ્રતિનિધિઓ સાથે ઘણો અને સક્રિય રીતે વાતચીત કરે છે, સંભવિત ગ્રાહકો પાસેથી બિલિંગ કાર્યક્ષમતા માટે પ્રથમ હાથની વિનંતીઓ મેળવે છે. વેપારીઓ અને ખાતાઓએ તેમની કાર્યક્ષમતામાં તમામ નોંધપાત્ર ફેરફારો અને સ્પર્ધકોના નવીનતમ સોફ્ટવેર અપડેટ્સથી વાકેફ હોવા જોઈએ, વિવિધ ઉકેલોના ફાયદા અને ગેરફાયદાને ન્યાયી ઠેરવવા સક્ષમ હોવા જોઈએ. અમારા આ કર્મચારીઓ જ સૌ પ્રથમ અનુભવે છે કે જો કેટલીક બિલિંગ સુવિધાઓ વાસ્તવિક ધોરણ બની જાય છે, જેના વિના સૉફ્ટવેરને સંપૂર્ણ ગણી શકાય નહીં.
3. ઉત્પાદન માલિક અમારા ટોચના મેનેજરોમાંથી એક છે અથવા ખૂબ જ અનુભવી પ્રોજેક્ટ મેનેજર છે. કંપનીના વ્યૂહાત્મક ધ્યેયોને ધ્યાનમાં રાખે છે અને તેમના અનુસાર ઉત્પાદન વિકાસ યોજનાઓને સમાયોજિત કરે છે.
4. આર્કિટેક્ટ, એક વ્યક્તિ જે પસંદ કરેલ / વપરાયેલ તકનીકી ઉકેલોની શક્યતાઓ અને મર્યાદાઓ અને ઉત્પાદન વિકાસ પર તેમની અસરને સમજે છે.
   વિકાસ અને પરીક્ષણ ટીમો. જે લોકો ઉત્પાદનના વિકાસમાં સીધા સંકળાયેલા છે.

હિટનું વર્ગીકરણ

અમે સ્રોતોમાંથી કાચો ડેટા પ્રાપ્ત કરીએ છીએ - પત્રો, ટિકિટો, મૌખિક વિનંતીઓ. બધા
અપીલ વર્ગીકૃત કરવામાં આવી છે:

• કન્સલ્ટિંગ અર્થ સાથે "તે કેવી રીતે કરવું?", "તે કેવી રીતે કાર્ય કરે છે?", "તે કેમ કામ કરતું નથી?", "મને સમજાતું નથી...". આ પ્રકારના કોલ્સ લેવલ 1 સપોર્ટ લાઇન પર જાય છે. પરામર્શને અન્ય પ્રકારની અપીલોમાં ફરીથી તાલીમ આપવી શક્ય છે.
• ઘટનાઓ "કામ કરતું નથી" અને "ભૂલ" ના અર્થ સાથે. 2 અને 3 સપોર્ટ લાઇન દ્વારા નિયંત્રિત. જો પેચને ઝડપથી ઠીક કરવા અને છોડવા માટે જરૂરી હોય, તો તેને સપોર્ટથી સીધા વિકાસમાં સ્થાનાંતરિત કરી શકાય છે. તેને બદલવાની વિનંતીમાં ફરીથી વર્ગીકૃત કરવું અને તેને બેકલોગમાં મોકલવું શક્ય છે.
• ફેરફારો અને વિકાસ માટેની વિનંતીઓ. સપોર્ટ લાઇનને બાયપાસ કરીને ઉત્પાદનના બેકલોગમાં પ્રવેશ કરો. પરંતુ તેમના માટે એક અલગ પ્રક્રિયા પ્રક્રિયા છે.

હિટ્સ પર આવા આંકડા છે - રિલીઝ થયા પછી તરત જ, હિટની સંખ્યા થોડા સમય માટે 10-15% વધે છે. જ્યારે મોટી સંખ્યામાં વપરાશકર્તાઓ સાથેનો નવો ક્લાયંટ અમારી ક્લાઉડ સેવાઓ પર આવે છે ત્યારે કૉલ્સના વિસ્ફોટ પણ થાય છે. લોકો નવી સૉફ્ટવેર સુવિધાઓનો ઉપયોગ કરવાનું શીખી રહ્યા છે, તેમને સલાહની જરૂર છે. એક નાનો ક્લાયંટ પણ, જ્યારે સિસ્ટમમાં કામ શરૂ કરે છે, ત્યારે દર મહિને 100 કલાકથી વધુની સલાહને સરળતાથી બાળી નાખે છે. તેથી, નવા ક્લાયંટને કનેક્ટ કરતી વખતે, અમે હંમેશા પ્રારંભિક પરામર્શ માટે સમય અનામત રાખીએ છીએ. ઘણીવાર આપણે કોઈ ચોક્કસ નિષ્ણાતને પણ સિંગલ કરીએ છીએ. ભાડાની કિંમત, અલબત્ત, આ મજૂરી ખર્ચને ચૂકવતી નથી, પરંતુ સમય જતાં પરિસ્થિતિનું સ્તર બંધ થાય છે. અનુકૂલનનો સમયગાળો, એક નિયમ તરીકે, 1 થી 3 મહિનાનો હોય છે, ત્યારબાદ પરામર્શની જરૂરિયાત નોંધપાત્ર રીતે ઓછી થાય છે.

પહેલાં, અમે કૉલ્સ સ્ટોર કરવા માટે સ્વ-લિખિત ઉકેલોનો ઉપયોગ કર્યો હતો. પરંતુ ધીમે ધીમે એટલાસિયન ઉત્પાદનો પર સ્વિચ કર્યું. પ્રથમ, ચપળતા પર કામ કરવાનું સરળ બનાવવા માટે વિકાસને સ્થાનાંતરિત કરવામાં આવ્યું હતું, પછી સપોર્ટ. હવે તમામ નિર્ણાયક પ્રક્રિયાઓ જીરા એસડીમાં રહે છે, ઉપરાંત તેઓને જીરા, વત્તા સંગમ માટે વિવિધ પ્લગિન્સ પ્રદાન કરવામાં આવે છે. સ્વ-લેખિત ઉકેલો ફક્ત કંપનીની પ્રવૃત્તિઓ માટે બિન-જટિલ પ્રક્રિયાઓ પર જ રહ્યા. તે બહાર આવ્યું છે કે અમારા કાર્યો હવે એન્ડ-ટુ-એન્ડ છે, તેઓ એક સિસ્ટમથી બીજી સિસ્ટમમાં જમ્પ કર્યા વિના સપોર્ટ અને ડેવલપમેન્ટ વચ્ચે ટ્રાન્સફર કરી શકાય છે.

આ બંડલમાંથી, અમે તમામ કાર્યો, આયોજિત અને વાસ્તવિક શ્રમ ખર્ચનો ડેટા મેળવી શકીએ છીએ, ગ્રાહકો માટે વિવિધ બિલિંગ વિકલ્પોનો ઉપયોગ કરી શકીએ છીએ અને આંતરિક જરૂરિયાતો માટે દસ્તાવેજીકરણ અને ક્લાયન્ટને રિપોર્ટ જનરેટ કરી શકીએ છીએ.

ફેરફાર વિનંતીઓ પર પ્રક્રિયા કરી રહ્યું છે

સામાન્ય રીતે, આ વિનંતીઓ સુવિધા આવશ્યકતાઓના સ્વરૂપમાં આવે છે. અમારા વિશ્લેષક વિનંતીનો અભ્યાસ કરે છે, સ્પષ્ટીકરણ અને ટોચના સ્તરના TOR જનરેટ કરે છે. સ્પષ્ટીકરણ અને TOR તે વ્યક્તિને સ્થાનાંતરિત કરે છે જેણે મંજૂરી માટે આ વિનંતી સબમિટ કરી છે - અમે ખાતરી કરવી જોઈએ કે અમે ગ્રાહક સાથે સમાન ભાષા બોલીએ છીએ.

ગ્રાહક તરફથી પુષ્ટિ મળ્યા પછી કે અમે એકબીજાને યોગ્ય રીતે સમજીએ છીએ, વિશ્લેષક ઉત્પાદન બેકલોગમાં વિનંતી દાખલ કરે છે.

પ્રોડક્ટ ફીચર મેનેજમેન્ટ

બેકલોગ ફેરફાર અને વિકાસ માટે પ્રાપ્ત વિનંતીઓ એકઠા કરે છે. દર છ મહિનામાં એકવાર, ટેકનિકલ કાઉન્સિલ, જેમાં ડિરેક્ટર, જાળવણી, વિકાસ, વેચાણના વડાઓ અને સિસ્ટમ આર્કિટેક્ટનો સમાવેશ થાય છે, મળે છે. ચર્ચાના ફોર્મેટમાં, કાઉન્સિલ બેકલોગમાંથી અરજીઓનું વિશ્લેષણ કરે છે અને પ્રાથમિકતા આપે છે અને આગામી પ્રકાશનમાં અમલીકરણ માટે 5 વિકાસ કાર્યો પર સંમત થાય છે.

વાસ્તવમાં, ટેક્નિકલ કાઉન્સિલ એપ્લીકેશનમાં નોંધાયેલી જરૂરિયાતોને ધ્યાનમાં લઈને ઉદ્યોગ અને બજારની જરૂરિયાતોને પ્રતિસાદ આપે છે. દરેક વસ્તુ જે ઓછી સુસંગત છે તે બેકલોગમાં રહે છે અને વિકાસ સુધી પહોંચતી નથી.

ફેરફારની વિનંતીઓ અને નાણાંનું વર્ગીકરણ

વિકાસ ખર્ચાળ છે. તેથી, અમે તરત જ તમને જણાવીશું કે જો કોઈ કર્મચારી તરફથી નહીં પણ ક્લાયન્ટ તરફથી ફેરફારની વિનંતી આવે તો અમારી પાસે કયા વિકલ્પો હોઈ શકે છે.

ફેરફારની વિનંતીઓ નીચે પ્રમાણે વર્ગીકૃત કરવામાં આવી છે: ઉદ્યોગ-વિશિષ્ટ જરૂરિયાતો અથવા એન્ટરપ્રાઇઝની વ્યક્તિગત લાક્ષણિકતાઓ; નવી કાર્યક્ષમતા અથવા નાના ફિક્સની નોંધપાત્ર રકમ. નાના સુધારાઓ અને વ્યક્તિગત વિનંતીઓ કોઈપણ ફ્રિલ વગર પ્રક્રિયા કરવામાં આવે છે. વ્યક્તિગત વિનંતીઓની ગણતરી કરવામાં આવે છે અને ચોક્કસ ક્લાયન્ટ માટે તેની સાથેના પ્રોજેક્ટ કાર્યના ભાગ રૂપે અમલ કરવામાં આવે છે.

જો આ મોટાપાયે ઉદ્યોગની જરૂરિયાત નથી અને કાર્યક્ષમતાની માત્રા મોટી છે, તો પછી મુખ્ય કાર્યક્ષમતા ઉપરાંત વેચવામાં આવશે તેવું નવું અલગ મોડ્યુલ વિકસાવવાનો નિર્ણય લઈ શકાય છે. જો ક્લાયન્ટ તરફથી આવી વિનંતી પ્રાપ્ત થાય, તો અમે મોડ્યુલ વિકસાવવાના ખર્ચને આવરી લઈ શકીએ છીએ, ક્લાયન્ટને મોડ્યુલ વિના મૂલ્યે અથવા આંશિક ચુકવણી સાથે પ્રદાન કરી શકીએ છીએ અને મોડ્યુલને વેચાણ માટે જાહેર ડોમેનમાં મૂકી શકીએ છીએ. આવી પરિસ્થિતિમાં, ક્લાયંટ પદ્ધતિસરના બોજનો ભાગ લે છે અને હકીકતમાં, મોડ્યુલનું પ્રાયોગિક અમલીકરણ કરે છે.

જો આ ઉદ્યોગની જંગી જરૂરિયાત છે, તો બેઝ પ્રોડક્ટમાં નવી કાર્યક્ષમતાને સમાવવાનો નિર્ણય લઈ શકાય છે. આ કિસ્સામાં ખર્ચ સંપૂર્ણપણે અમારા દ્વારા વહન કરવામાં આવે છે, અને નવી કાર્યક્ષમતા પ્રોગ્રામ્સના વર્તમાન સંસ્કરણમાં દેખાય છે.
જૂના ગ્રાહકોને અપડેટ આપવામાં આવે છે.

એવું પણ બની શકે છે કે ઘણા ગ્રાહકોને સમાન જરૂરિયાત હોય, પરંતુ તે સામૂહિક ઉત્પાદનને ખેંચી શકતું નથી. આ કિસ્સામાં, અમે આ ગ્રાહકોને સ્પષ્ટીકરણ મોકલી શકીએ છીએ અને તેમની વચ્ચે વિકાસ ખર્ચ શેર કરવાની ઑફર કરી શકીએ છીએ. અંતે, દરેક જીતે છે: ગ્રાહકોને ઓછા ખર્ચે કાર્યક્ષમતાનો અમલ મળે છે, અમે ઉત્પાદનને સમૃદ્ધ બનાવીએ છીએ, થોડા સમય પછી અન્ય બજાર સહભાગીઓ પણ તેમના ઉપયોગ માટે કાર્યક્ષમતા મેળવી શકે છે.

DevOps

વિકાસ દર વર્ષે બે મુખ્ય પ્રકાશનો તૈયાર કરે છે. દરેક પ્રકાશનમાં, ટેકનિકલ કાઉન્સિલ તરફથી પ્રાપ્ત 5 કાર્યોના અમલીકરણ માટે સમય અનામત છે. આમ, ટર્નઓવર પાછળ, અમે ઉત્પાદનના વિકાસ વિશે ક્યારેય ભૂલી શકતા નથી.

દરેક પ્રકાશન પરીક્ષણ અને દસ્તાવેજીકરણના યોગ્ય સેટમાંથી પસાર થાય છે. આગળ, આ પ્રકાશન અનુરૂપ ગ્રાહકના પરીક્ષણ વાતાવરણમાં ઇન્સ્ટોલ કરેલું છે, જે બદલામાં, બધું કાળજીપૂર્વક તપાસે છે, અને તે પછી જ પ્રકાશન ઉત્પાદનમાં સ્થાનાંતરિત થાય છે.

રિલીઝ સિસ્ટમ ઉપરાંત, ઝડપી બગ ફિક્સનું ફોર્મેટ છે જેથી કરીને ગ્રાહકો છ મહિના સુધી ભૂલો સાથે જીવી ન શકે. આ મધ્યવર્તી ફોર્મેટ તમને પ્રથમ પ્રાથમિકતાઓની ઘટનાઓનો ઝડપથી પ્રતિસાદ આપવા અને જણાવેલ SLA ને પરિપૂર્ણ કરવાની મંજૂરી આપશે.

ઉપરોક્ત તમામ બાબતો મુખ્યત્વે કોર્પોરેટ સેક્ટર અને ઓન-પ્રિમાઈસ સોલ્યુશન્સ માટે સાચી છે. SMB સેગમેન્ટ પર કેન્દ્રિત ક્લાઉડ સેવાઓ માટે, ગ્રાહકો માટે પ્રોડક્ટ ડેવલપમેન્ટમાં ભાગ લેવાની આવી કોઈ વિશાળ તકો નથી. SMB માટે લીઝ ફોર્મેટ પણ આનું સૂચન કરતું નથી. કોર્પોરેટ પક્ષ તરફથી સ્પષ્ટ જરૂરિયાતોના સ્વરૂપમાં ફેરફારની વિનંતીને બદલે, સેવા માટે માત્ર સામાન્ય પ્રતિસાદ અને શુભેચ્છાઓ છે. અમે સાંભળવાનો પ્રયાસ કરીએ છીએ, પરંતુ ઉત્પાદન વિશાળ છે અને એક ક્લાયન્ટની તેની જૂની ઐતિહાસિક સિસ્ટમમાંથી કંઈક પરિચિત લાવવાની ઇચ્છા સમગ્ર સિસ્ટમની વિકાસ વ્યૂહરચનાનો વિરોધાભાસ કરી શકે છે.

સોર્સ: www.habr.com