ਅਸੀਂ ਆਪਣੇ ਉਤਪਾਦਾਂ ਦੇ ਵਿਕਾਸ ਲਈ ਵਿਚਾਰਾਂ ਦੀ ਚੋਣ ਕਿਵੇਂ ਕਰਦੇ ਹਾਂ: ਵਿਕਰੇਤਾ ਨੂੰ ਸੁਣਨ ਦੇ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ...

ਇਸ ਲੇਖ ਵਿੱਚ, ਮੈਂ ਆਪਣੇ ਉਤਪਾਦਾਂ ਦੀ ਕਾਰਜਕੁਸ਼ਲਤਾ ਨੂੰ ਵਿਕਸਤ ਕਰਨ ਲਈ ਵਿਚਾਰਾਂ ਦੀ ਚੋਣ ਕਰਨ ਵਿੱਚ ਆਪਣਾ ਅਨੁਭਵ ਸਾਂਝਾ ਕਰਾਂਗਾ ਅਤੇ ਤੁਹਾਨੂੰ ਦੱਸਾਂਗਾ ਕਿ ਵਿਕਾਸ ਦੇ ਮੁੱਖ ਵੈਕਟਰਾਂ ਨੂੰ ਕਿਵੇਂ ਬਣਾਈ ਰੱਖਣਾ ਹੈ।

ਅਸੀਂ ਇੱਕ ਆਟੋਮੇਟਿਡ ਸੈਟਲਮੈਂਟ ਸਿਸਟਮ (ACP) - ਬਿਲਿੰਗ ਵਿਕਸਿਤ ਕਰ ਰਹੇ ਹਾਂ। ਮਿਆਦ
ਸਾਡੇ ਉਤਪਾਦ ਦੀ ਉਮਰ 14 ਸਾਲ ਹੈ. ਇਸ ਸਮੇਂ ਦੌਰਾਨ, ਸਿਸਟਮ ਇੱਕ ਉਦਯੋਗਿਕ ਟੈਰਿਫ ਪ੍ਰਣਾਲੀ ਦੇ ਪਹਿਲੇ ਸੰਸਕਰਣਾਂ ਤੋਂ ਇੱਕ ਮਾਡਯੂਲਰ ਕੰਪਲੈਕਸ ਵਿੱਚ ਵਿਕਸਤ ਹੋਇਆ ਹੈ ਜਿਸ ਵਿੱਚ 18 ਉਤਪਾਦ ਸ਼ਾਮਲ ਹਨ ਜੋ ਇੱਕ ਦੂਜੇ ਦੇ ਪੂਰਕ ਹਨ। ਪ੍ਰੋਗਰਾਮਾਂ ਲਈ ਲੰਬੀ ਉਮਰ ਦੇ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਪਹਿਲੂਆਂ ਵਿੱਚੋਂ ਇੱਕ ਨਿਰੰਤਰ ਵਿਕਾਸ ਹੈ। ਅਤੇ ਵਿਕਾਸ ਲਈ ਵਿਚਾਰਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

Идеи

ਸਰੋਤ

ਇੱਥੇ 5 ਸਰੋਤ ਹਨ:

1. ਇੱਕ ਕਾਰਪੋਰੇਟ ਸੂਚਨਾ ਸਿਸਟਮ ਡਿਵੈਲਪਰ ਦਾ ਮੁੱਖ ਦੋਸਤ ਹੈ ਗਾਹਕ. ਅਤੇ ਕਲਾਇੰਟ ਫੈਸਲੇ ਲੈਣ ਵਾਲਿਆਂ, ਪ੍ਰੋਜੈਕਟ ਸਪਾਂਸਰਾਂ, ਮਾਲਕਾਂ ਅਤੇ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੇ ਸੰਚਾਲਕਾਂ, ਅੰਦਰੂਨੀ IT ਮਾਹਰਾਂ, ਆਮ ਉਪਭੋਗਤਾਵਾਂ ਅਤੇ ਵੱਖ-ਵੱਖ ਡਿਗਰੀਆਂ ਤੱਕ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਦਿਲਚਸਪੀ ਰੱਖਣ ਵਾਲੇ ਵਿਅਕਤੀਆਂ ਦਾ ਇੱਕ ਸਮੂਹਿਕ ਚਿੱਤਰ ਹੈ। ਇਹ ਸਾਡੇ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ ਗਾਹਕ ਦਾ ਹਰੇਕ ਪ੍ਰਤੀਨਿਧੀ ਸੰਭਾਵੀ ਤੌਰ 'ਤੇ ਵਿਚਾਰਾਂ ਦਾ ਸਪਲਾਇਰ ਹੈ। ਸਭ ਤੋਂ ਮਾੜੀ ਸਥਿਤੀ ਵਿੱਚ, ਅਸੀਂ ਸਿਸਟਮ ਵਿੱਚ ਸਮੱਸਿਆਵਾਂ ਬਾਰੇ ਸਿਰਫ ਨਕਾਰਾਤਮਕ ਫੀਡਬੈਕ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਾਂ। ਸਭ ਤੋਂ ਵਧੀਆ ਸਥਿਤੀ ਵਿੱਚ, ਗਾਹਕ ਦੇ ਪਾਸੇ ਇੱਕ ਵਿਅਕਤੀ ਹੁੰਦਾ ਹੈ ਜੋ ਸੁਧਾਰ ਲਈ ਵਿਚਾਰਾਂ ਦਾ ਨਿਰੰਤਰ ਸਰੋਤ ਹੁੰਦਾ ਹੈ, ਗਾਹਕ ਦੀਆਂ ਲੋੜਾਂ ਬਾਰੇ ਢਾਂਚਾਗਤ ਜਾਣਕਾਰੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।
2. ਸਾਡਾ ਵਿਕਰੇਤਾ ਅਤੇ ਖਾਤਾ ਪ੍ਰਬੰਧਕ ਸੁਧਾਰ ਲਈ ਵਿਚਾਰਾਂ ਦਾ ਦੂਜਾ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਸਰੋਤ ਹਨ। ਉਹ ਉਦਯੋਗ ਦੇ ਨੁਮਾਇੰਦਿਆਂ ਨਾਲ ਸਰਗਰਮੀ ਨਾਲ ਅਤੇ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਸੰਚਾਰ ਕਰਦੇ ਹਨ ਅਤੇ ਸੰਭਾਵੀ ਗਾਹਕਾਂ ਤੋਂ ਬਿਲਿੰਗ ਕਾਰਜਕੁਸ਼ਲਤਾ ਬਾਰੇ ਪਹਿਲਾਂ ਹੱਥੀਂ ਪੁੱਛਗਿੱਛ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ। ਵਿਕਰੇਤਾਵਾਂ ਅਤੇ ਖਾਤਿਆਂ ਨੂੰ ਉਹਨਾਂ ਦੀ ਕਾਰਜਕੁਸ਼ਲਤਾ ਵਿੱਚ ਸਾਰੀਆਂ ਮਹੱਤਵਪੂਰਨ ਤਬਦੀਲੀਆਂ ਅਤੇ ਪ੍ਰਤੀਯੋਗੀਆਂ ਦੇ ਸੌਫਟਵੇਅਰ ਲਈ ਨਵੀਨਤਮ ਅਪਡੇਟਾਂ ਤੋਂ ਜਾਣੂ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਵੱਖ-ਵੱਖ ਹੱਲਾਂ ਦੇ ਚੰਗੇ ਅਤੇ ਨੁਕਸਾਨ ਨੂੰ ਜਾਇਜ਼ ਠਹਿਰਾਉਣ ਦੇ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਹ ਸਾਡੇ ਕਰਮਚਾਰੀ ਹਨ ਜੋ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ ਕਿ ਕੀ ਕੁਝ ਬਿਲਿੰਗ ਸਮਰੱਥਾਵਾਂ ਇੱਕ ਅਸਲ ਮਿਆਰ ਬਣ ਜਾਂਦੀਆਂ ਹਨ, ਜਿਸ ਤੋਂ ਬਿਨਾਂ ਸੌਫਟਵੇਅਰ ਨੂੰ ਸੰਪੂਰਨ ਨਹੀਂ ਮੰਨਿਆ ਜਾ ਸਕਦਾ ਹੈ।
3. ਉਤਪਾਦ ਦਾ ਮਾਲਕ — ਸਾਡੇ ਚੋਟੀ ਦੇ ਪ੍ਰਬੰਧਕਾਂ ਵਿੱਚੋਂ ਇੱਕ ਜਾਂ ਇੱਕ ਬਹੁਤ ਹੀ ਤਜਰਬੇਕਾਰ ਪ੍ਰੋਜੈਕਟ ਮੈਨੇਜਰ। ਕੰਪਨੀ ਦੇ ਰਣਨੀਤਕ ਟੀਚਿਆਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਦੇ ਅਨੁਸਾਰ ਉਤਪਾਦ ਵਿਕਾਸ ਯੋਜਨਾਵਾਂ ਨੂੰ ਵਿਵਸਥਿਤ ਕਰਦਾ ਹੈ।
4. ਆਰਕੀਟੈਕਟ, ਇੱਕ ਵਿਅਕਤੀ ਜੋ ਚੁਣੇ/ਵਰਤੇ ਗਏ ਤਕਨਾਲੋਜੀ ਹੱਲਾਂ ਦੀਆਂ ਸਮਰੱਥਾਵਾਂ ਅਤੇ ਸੀਮਾਵਾਂ ਅਤੇ ਉਤਪਾਦ ਦੇ ਵਿਕਾਸ 'ਤੇ ਉਹਨਾਂ ਦੇ ਪ੍ਰਭਾਵ ਨੂੰ ਸਮਝਦਾ ਹੈ।
   ਵਿਕਾਸ ਅਤੇ ਟੈਸਟਿੰਗ ਟੀਮਾਂ। ਉਹ ਲੋਕ ਜੋ ਉਤਪਾਦ ਦੇ ਵਿਕਾਸ ਵਿੱਚ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਸ਼ਾਮਲ ਹਨ।

ਬੇਨਤੀਆਂ ਦਾ ਵਰਗੀਕਰਨ

ਅਸੀਂ ਸਰੋਤਾਂ ਤੋਂ ਕੱਚਾ ਡੇਟਾ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਾਂ - ਚਿੱਠੀਆਂ, ਟਿਕਟਾਂ, ਜ਼ੁਬਾਨੀ ਬੇਨਤੀਆਂ। ਸਾਰੇ
ਅਪੀਲਾਂ ਨੂੰ ਸ਼੍ਰੇਣੀਬੱਧ ਕੀਤਾ ਗਿਆ ਹੈ:

• ਮਸ਼ਵਰਾ ਅਰਥ ਦੇ ਨਾਲ "ਇਹ ਕਿਵੇਂ ਕਰਨਾ ਹੈ?", "ਇਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ?", "ਇਹ ਕੰਮ ਕਿਉਂ ਨਹੀਂ ਕਰਦਾ?", "ਮੈਨੂੰ ਸਮਝ ਨਹੀਂ ਆਉਂਦੀ..."। ਇਸ ਕਿਸਮ ਦੀਆਂ ਬੇਨਤੀਆਂ ਲੈਵਲ 1 ਸਪੋਰਟ ਲਾਈਨ 'ਤੇ ਜਾਂਦੀਆਂ ਹਨ। ਹੋਰ ਕਿਸਮ ਦੀਆਂ ਬੇਨਤੀਆਂ ਵਿੱਚ ਸਲਾਹ-ਮਸ਼ਵਰੇ ਨੂੰ ਦੁਬਾਰਾ ਸਿਖਾਉਣਾ ਸੰਭਵ ਹੈ।
• ਘਟਨਾਵਾਂ "ਕੰਮ ਨਹੀਂ ਕਰਦਾ" ਅਤੇ "ਗਲਤੀ" ਦੇ ਅਰਥਾਂ ਨਾਲ। 2 ਅਤੇ 3 ਸਹਾਇਤਾ ਲਾਈਨਾਂ ਦੁਆਰਾ ਪ੍ਰਕਿਰਿਆ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਜੇਕਰ ਤੁਰੰਤ ਸੁਧਾਰ ਅਤੇ ਪੈਚ ਨੂੰ ਜਾਰੀ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ, ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਸਹਾਇਤਾ ਤੋਂ ਸਿੱਧੇ ਵਿਕਾਸ ਵਿੱਚ ਤਬਦੀਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਬਦਲਾਵ ਦੀ ਬੇਨਤੀ ਦੇ ਰੂਪ ਵਿੱਚ ਇਸਨੂੰ ਦੁਬਾਰਾ ਵਰਗੀਕਰਨ ਕਰਨਾ ਅਤੇ ਇਸਨੂੰ ਬੈਕਲਾਗ ਵਿੱਚ ਭੇਜਣਾ ਸੰਭਵ ਹੈ।
• ਤਬਦੀਲੀਆਂ ਅਤੇ ਵਿਕਾਸ ਲਈ ਬੇਨਤੀਆਂ. ਉਹ ਸਮਰਥਨ ਲਾਈਨਾਂ ਨੂੰ ਬਾਈਪਾਸ ਕਰਦੇ ਹੋਏ, ਉਤਪਾਦ ਬੈਕਲਾਗ ਵਿੱਚ ਆਉਂਦੇ ਹਨ। ਪਰ ਉਹਨਾਂ ਲਈ ਇੱਕ ਵੱਖਰੀ ਪ੍ਰੋਸੈਸਿੰਗ ਪ੍ਰਕਿਰਿਆ ਹੈ.

ਬੇਨਤੀਆਂ 'ਤੇ ਅੰਕੜੇ ਹਨ: ਰੀਲੀਜ਼ ਤੋਂ ਤੁਰੰਤ ਬਾਅਦ, ਥੋੜ੍ਹੇ ਸਮੇਂ ਲਈ ਬੇਨਤੀਆਂ ਦੀ ਗਿਣਤੀ 10-15% ਵਧ ਜਾਂਦੀ ਹੈ. ਬੇਨਤੀਆਂ ਵਿੱਚ ਵੀ ਵਾਧਾ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਉਪਭੋਗਤਾਵਾਂ ਵਾਲਾ ਇੱਕ ਨਵਾਂ ਕਲਾਇੰਟ ਸਾਡੀ ਕਲਾਉਡ ਸੇਵਾਵਾਂ ਵਿੱਚ ਆਉਂਦਾ ਹੈ। ਲੋਕ ਨਵੀਆਂ ਸਾਫਟਵੇਅਰ ਸਮਰੱਥਾਵਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਸਿੱਖ ਰਹੇ ਹਨ, ਉਨ੍ਹਾਂ ਨੂੰ ਸਲਾਹ ਦੀ ਲੋੜ ਹੈ। ਇੱਥੋਂ ਤੱਕ ਕਿ ਇੱਕ ਛੋਟਾ ਕਲਾਇੰਟ, ਜਦੋਂ ਸਿਸਟਮ ਵਿੱਚ ਕੰਮ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ, ਹਰ ਮਹੀਨੇ 100 ਘੰਟਿਆਂ ਤੋਂ ਵੱਧ ਸਲਾਹ-ਮਸ਼ਵਰੇ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਸਾੜ ਦਿੰਦਾ ਹੈ. ਇਸ ਲਈ, ਜਦੋਂ ਇੱਕ ਨਵੇਂ ਕਲਾਇੰਟ ਨੂੰ ਜੋੜਦੇ ਹਾਂ, ਅਸੀਂ ਹਮੇਸ਼ਾ ਸ਼ੁਰੂਆਤੀ ਸਲਾਹ-ਮਸ਼ਵਰੇ ਲਈ ਸਮਾਂ ਰਾਖਵਾਂ ਰੱਖਦੇ ਹਾਂ। ਅਕਸਰ ਅਸੀਂ ਕਿਸੇ ਖਾਸ ਮਾਹਰ ਦੀ ਚੋਣ ਵੀ ਕਰਦੇ ਹਾਂ। ਕਿਰਾਏ ਦੀ ਕੀਮਤ, ਬੇਸ਼ੱਕ, ਇਹਨਾਂ ਕਿਰਤ ਲਾਗਤਾਂ ਨੂੰ ਕਵਰ ਨਹੀਂ ਕਰਦੀ, ਪਰ ਸਮੇਂ ਦੇ ਨਾਲ ਸਥਿਤੀ ਇੱਕਸਾਰ ਹੋ ਜਾਂਦੀ ਹੈ। ਅਨੁਕੂਲਨ ਦੀ ਮਿਆਦ ਆਮ ਤੌਰ 'ਤੇ 1 ਤੋਂ 3 ਮਹੀਨਿਆਂ ਤੱਕ ਹੁੰਦੀ ਹੈ, ਜਿਸ ਤੋਂ ਬਾਅਦ ਕਾਉਂਸਲਿੰਗ ਦੀ ਜ਼ਰੂਰਤ ਕਾਫ਼ੀ ਘੱਟ ਜਾਂਦੀ ਹੈ।

ਪਹਿਲਾਂ, ਅਸੀਂ ਬੇਨਤੀਆਂ ਨੂੰ ਸਟੋਰ ਕਰਨ ਲਈ ਸਵੈ-ਲਿਖਤ ਹੱਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸੀ। ਪਰ ਅਸੀਂ ਹੌਲੀ-ਹੌਲੀ ਐਟਲਸੀਅਨ ਉਤਪਾਦਾਂ ਵੱਲ ਬਦਲ ਗਏ। ਪਹਿਲਾਂ, ਅਸੀਂ ਐਜੀਲ ਦੇ ਅਨੁਸਾਰ ਕੰਮ ਕਰਨਾ ਆਸਾਨ ਬਣਾਉਣ ਲਈ ਵਿਕਾਸ ਨੂੰ ਟ੍ਰਾਂਸਫਰ ਕੀਤਾ, ਫਿਰ ਸਮਰਥਨ। ਹੁਣ ਸਾਰੀਆਂ ਨਾਜ਼ੁਕ ਪ੍ਰਕਿਰਿਆਵਾਂ ਜੀਰਾ SD ਵਿੱਚ ਰਹਿੰਦੀਆਂ ਹਨ, ਨਾਲ ਹੀ ਉਹਨਾਂ ਨੂੰ ਜੀਰਾ, ਪਲੱਸ ਕਨਫਲੂਏਂਸ ਲਈ ਵੱਖ-ਵੱਖ ਪਲੱਗਇਨਾਂ ਦੁਆਰਾ ਸਮਰਥਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਸਵੈ-ਲਿਖਤ ਹੱਲ ਕੇਵਲ ਉਹਨਾਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਲਈ ਹੀ ਰਹੇ ਜੋ ਕੰਪਨੀ ਦੀਆਂ ਗਤੀਵਿਧੀਆਂ ਲਈ ਮਹੱਤਵਪੂਰਨ ਨਹੀਂ ਸਨ। ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਸਾਡੇ ਕੰਮ ਹੁਣ ਕਰਾਸ-ਕੱਟ ਰਹੇ ਹਨ ਅਤੇ ਇੱਕ ਸਿਸਟਮ ਤੋਂ ਦੂਜੇ ਸਿਸਟਮ ਵਿੱਚ ਛਾਲ ਮਾਰਨ ਤੋਂ ਬਿਨਾਂ ਸਹਾਇਤਾ ਅਤੇ ਵਿਕਾਸ ਦੇ ਵਿਚਕਾਰ ਟ੍ਰਾਂਸਫਰ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ।

ਇਸ ਲਿੰਕ ਤੋਂ ਅਸੀਂ ਸਾਰੇ ਕੰਮਾਂ, ਯੋਜਨਾਬੱਧ ਅਤੇ ਅਸਲ ਲੇਬਰ ਲਾਗਤਾਂ 'ਤੇ ਡੇਟਾ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹਾਂ, ਗਾਹਕਾਂ ਲਈ ਵੱਖ-ਵੱਖ ਕੀਮਤ ਦੇ ਵਿਕਲਪਾਂ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹਾਂ ਅਤੇ ਅੰਦਰੂਨੀ ਲੋੜਾਂ ਲਈ ਦਸਤਾਵੇਜ਼ ਤਿਆਰ ਕਰ ਸਕਦੇ ਹਾਂ ਅਤੇ ਗਾਹਕਾਂ ਨੂੰ ਰਿਪੋਰਟ ਕਰ ਸਕਦੇ ਹਾਂ।

ਪਰਿਵਰਤਨ ਬੇਨਤੀਆਂ 'ਤੇ ਕਾਰਵਾਈ ਕੀਤੀ ਜਾ ਰਹੀ ਹੈ

ਆਮ ਤੌਰ 'ਤੇ, ਅਜਿਹੀਆਂ ਬੇਨਤੀਆਂ ਕਾਰਜਸ਼ੀਲਤਾ ਲੋੜਾਂ ਦੇ ਰੂਪ ਵਿੱਚ ਆਉਂਦੀਆਂ ਹਨ। ਸਾਡਾ ਵਿਸ਼ਲੇਸ਼ਕ ਬੇਨਤੀ ਦਾ ਅਧਿਐਨ ਕਰਦਾ ਹੈ, ਇੱਕ ਨਿਰਧਾਰਨ ਅਤੇ ਉੱਚ-ਪੱਧਰੀ ਤਕਨੀਕੀ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਬਣਾਉਂਦਾ ਹੈ। ਨਿਰਧਾਰਨ ਅਤੇ ਤਕਨੀਕੀ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਉਸ ਵਿਅਕਤੀ ਨੂੰ ਟ੍ਰਾਂਸਫਰ ਕਰਦਾ ਹੈ ਜਿਸ ਨੇ ਇਹ ਬੇਨਤੀ ਮਨਜ਼ੂਰੀ ਲਈ ਜਮ੍ਹਾਂ ਕਰਵਾਈ ਹੈ - ਸਾਨੂੰ ਇਹ ਯਕੀਨੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਅਸੀਂ ਗਾਹਕ ਨਾਲ ਉਹੀ ਭਾਸ਼ਾ ਬੋਲਦੇ ਹਾਂ।

ਗਾਹਕ ਤੋਂ ਪੁਸ਼ਟੀ ਪ੍ਰਾਪਤ ਕਰਨ ਤੋਂ ਬਾਅਦ ਕਿ ਅਸੀਂ ਇੱਕ ਦੂਜੇ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਸਮਝਿਆ ਹੈ, ਵਿਸ਼ਲੇਸ਼ਕ ਉਤਪਾਦ ਬੈਕਲਾਗ ਵਿੱਚ ਬੇਨਤੀ ਦਾਖਲ ਕਰਦਾ ਹੈ।

ਉਤਪਾਦ ਕਾਰਜਕੁਸ਼ਲਤਾ ਪ੍ਰਬੰਧਨ

ਬੈਕਲਾਗ ਤਬਦੀਲੀ ਅਤੇ ਵਿਕਾਸ ਲਈ ਆਉਣ ਵਾਲੀਆਂ ਬੇਨਤੀਆਂ ਨੂੰ ਇਕੱਠਾ ਕਰਦਾ ਹੈ। ਤਕਨੀਕੀ ਕੌਂਸਲ, ਜਿਸ ਵਿੱਚ ਡਾਇਰੈਕਟਰ, ਸਹਾਇਤਾ, ਵਿਕਾਸ, ਵਿਕਰੀ ਅਤੇ ਸਿਸਟਮ ਆਰਕੀਟੈਕਟ ਦੇ ਮੁਖੀ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ, ਹਰ ਛੇ ਮਹੀਨਿਆਂ ਬਾਅਦ ਮੀਟਿੰਗ ਕਰਦੇ ਹਨ। ਇੱਕ ਚਰਚਾ ਫਾਰਮੈਟ ਵਿੱਚ, ਕੌਂਸਲ ਬੈਕਲਾਗ ਤੋਂ ਅਰਜ਼ੀਆਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਦੀ ਹੈ ਅਤੇ ਤਰਜੀਹ ਦਿੰਦੀ ਹੈ ਅਤੇ ਅਗਲੀ ਰੀਲੀਜ਼ ਵਿੱਚ ਲਾਗੂ ਕਰਨ ਲਈ 5 ਵਿਕਾਸ ਕਾਰਜਾਂ 'ਤੇ ਸਹਿਮਤ ਹੁੰਦੀ ਹੈ।

ਅਸਲ ਵਿੱਚ, ਤਕਨੀਕੀ ਕੌਂਸਲ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ ਦਰਸਾਈ ਲੋੜਾਂ ਦੀ ਸਮੀਖਿਆ ਕਰਕੇ ਉਦਯੋਗ ਅਤੇ ਮਾਰਕੀਟ ਦੀਆਂ ਮੰਗਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ। ਹਰ ਚੀਜ਼ ਜੋ ਥੋੜੀ ਜਿਹੀ ਪ੍ਰਸੰਗਿਕ ਹੈ ਉਹ ਬੈਕਲਾਗ ਵਿੱਚ ਰਹਿੰਦੀ ਹੈ ਅਤੇ ਵਿਕਾਸ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਦੀ।

ਪਰਿਵਰਤਨ ਬੇਨਤੀਆਂ ਅਤੇ ਵਿੱਤ ਦਾ ਵਰਗੀਕਰਨ

ਵਿਕਾਸ ਮਹਿੰਗਾ ਹੈ। ਇਸ ਲਈ, ਅਸੀਂ ਤੁਰੰਤ ਤੁਹਾਨੂੰ ਦੱਸਾਂਗੇ ਕਿ ਜੇਕਰ ਤਬਦੀਲੀ ਦੀ ਬੇਨਤੀ ਕਿਸੇ ਕਰਮਚਾਰੀ ਤੋਂ ਨਹੀਂ, ਸਗੋਂ ਕਿਸੇ ਗਾਹਕ ਤੋਂ ਆਉਂਦੀ ਹੈ ਤਾਂ ਸਾਡੇ ਕੋਲ ਕਿਹੜੇ ਵਿਕਲਪ ਹੋ ਸਕਦੇ ਹਨ।

ਅਸੀਂ ਤਬਦੀਲੀ ਦੀਆਂ ਬੇਨਤੀਆਂ ਨੂੰ ਹੇਠ ਲਿਖੇ ਅਨੁਸਾਰ ਸ਼੍ਰੇਣੀਬੱਧ ਕਰਦੇ ਹਾਂ: ਉਦਯੋਗ ਦੀ ਲੋੜ ਜਾਂ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਦੀ ਵਿਅਕਤੀਗਤ ਵਿਸ਼ੇਸ਼ਤਾ; ਨਵੀਂ ਕਾਰਜਕੁਸ਼ਲਤਾ ਦੀ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਮਾਤਰਾ ਜਾਂ ਇੱਕ ਮਾਮੂਲੀ ਫਿਕਸ। ਮਾਮੂਲੀ ਫਿਕਸ ਅਤੇ ਵਿਅਕਤੀਗਤ ਬੇਨਤੀਆਂ 'ਤੇ ਬਿਨਾਂ ਕਿਸੇ ਝਿਜਕ ਦੇ ਕਾਰਵਾਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਵਿਅਕਤੀਗਤ ਬੇਨਤੀਆਂ ਦੀ ਗਣਨਾ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਅਤੇ ਇੱਕ ਖਾਸ ਕਲਾਇੰਟ ਲਈ ਉਸ ਨਾਲ ਪ੍ਰੋਜੈਕਟ ਦੇ ਕੰਮ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਲਾਗੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਜੇ ਇਹ ਇੱਕ ਵਿਸ਼ਾਲ ਉਦਯੋਗ ਦੀ ਜ਼ਰੂਰਤ ਨਹੀਂ ਹੈ ਅਤੇ ਕਾਰਜਸ਼ੀਲਤਾ ਦੀ ਮਾਤਰਾ ਵੱਡੀ ਹੈ, ਤਾਂ ਇੱਕ ਨਵਾਂ ਵੱਖਰਾ ਮੋਡੀਊਲ ਵਿਕਸਤ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਜੋ ਮੁੱਖ ਕਾਰਜਕੁਸ਼ਲਤਾ ਤੋਂ ਇਲਾਵਾ ਵੇਚਿਆ ਜਾਵੇਗਾ। ਜੇਕਰ ਕਿਸੇ ਕਲਾਇੰਟ ਤੋਂ ਅਜਿਹੀ ਕੋਈ ਬੇਨਤੀ ਪ੍ਰਾਪਤ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਅਸੀਂ ਮੋਡੀਊਲ ਨੂੰ ਵਿਕਸਤ ਕਰਨ ਦੇ ਖਰਚਿਆਂ ਨੂੰ ਪੂਰਾ ਕਰ ਸਕਦੇ ਹਾਂ, ਗਾਹਕ ਨੂੰ ਮੁਫਤ ਜਾਂ ਅੰਸ਼ਕ ਭੁਗਤਾਨ ਦੇ ਨਾਲ ਮੋਡੀਊਲ ਪ੍ਰਦਾਨ ਕਰ ਸਕਦੇ ਹਾਂ, ਅਤੇ ਮੋਡੀਊਲ ਨੂੰ ਖੁਦ ਵਿਕਰੀ ਲਈ ਰੱਖ ਸਕਦੇ ਹਾਂ। ਅਜਿਹੀ ਸਥਿਤੀ ਵਿੱਚ, ਕਲਾਇੰਟ ਵਿਧੀਗਤ ਲੋਡ ਦਾ ਹਿੱਸਾ ਲੈਂਦਾ ਹੈ ਅਤੇ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਆਪਣੇ ਆਪ 'ਤੇ ਮੋਡੀਊਲ ਦਾ ਇੱਕ ਪਾਇਲਟ ਲਾਗੂਕਰਨ ਕਰਦਾ ਹੈ।

ਜੇਕਰ ਇਹ ਇੱਕ ਵਿਸ਼ਾਲ ਉਦਯੋਗ ਦੀ ਜ਼ਰੂਰਤ ਹੈ, ਤਾਂ ਬੇਸ ਉਤਪਾਦ ਵਿੱਚ ਨਵੀਂ ਕਾਰਜਕੁਸ਼ਲਤਾ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਇਸ ਕੇਸ ਵਿੱਚ ਲਾਗਤ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਾਡੇ 'ਤੇ ਆਉਂਦੀ ਹੈ, ਅਤੇ ਨਵੀਂ ਕਾਰਜਸ਼ੀਲਤਾ ਪ੍ਰੋਗਰਾਮਾਂ ਦੇ ਮੌਜੂਦਾ ਸੰਸਕਰਣ ਵਿੱਚ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ.
ਪੁਰਾਣੇ ਗਾਹਕਾਂ ਨੂੰ ਇੱਕ ਅਪਡੇਟ ਪ੍ਰਦਾਨ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।

ਇਹ ਵੀ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਕਈ ਗਾਹਕਾਂ ਨੂੰ ਸਮਾਨ ਲੋੜ ਹੋਵੇ, ਪਰ ਇਹ ਇੱਕ ਵੱਡੇ ਉਤਪਾਦ ਲਈ ਯੋਗ ਨਹੀਂ ਹੁੰਦਾ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਅਸੀਂ ਇਹਨਾਂ ਗਾਹਕਾਂ ਨੂੰ ਨਿਰਧਾਰਨ ਭੇਜ ਸਕਦੇ ਹਾਂ ਅਤੇ ਉਹਨਾਂ ਵਿਚਕਾਰ ਵਿਕਾਸ ਲਾਗਤਾਂ ਨੂੰ ਵੰਡਣ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰ ਸਕਦੇ ਹਾਂ। ਅੰਤ ਵਿੱਚ, ਹਰ ਕੋਈ ਜਿੱਤਦਾ ਹੈ: ਗਾਹਕਾਂ ਨੂੰ ਘੱਟ ਕੀਮਤ 'ਤੇ ਲਾਗੂ ਕੀਤੀ ਕਾਰਜਕੁਸ਼ਲਤਾ ਮਿਲਦੀ ਹੈ, ਅਸੀਂ ਉਤਪਾਦ ਨੂੰ ਅਮੀਰ ਬਣਾਉਂਦੇ ਹਾਂ, ਅਤੇ ਕੁਝ ਸਮੇਂ ਬਾਅਦ, ਹੋਰ ਮਾਰਕੀਟ ਭਾਗੀਦਾਰ ਵੀ ਉਹਨਾਂ ਦੀ ਵਰਤੋਂ ਲਈ ਕਾਰਜਸ਼ੀਲਤਾ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹਨ।

DevOps

ਵਿਕਾਸ ਇੱਕ ਸਾਲ ਵਿੱਚ ਦੋ ਪ੍ਰਮੁੱਖ ਰੀਲੀਜ਼ ਤਿਆਰ ਕਰਦਾ ਹੈ। ਹਰੇਕ ਰੀਲੀਜ਼ ਵਿੱਚ, ਤਕਨੀਕੀ ਕੌਂਸਲ ਤੋਂ ਪ੍ਰਾਪਤ 5 ਕਾਰਜਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ ਸਮਾਂ ਰਾਖਵਾਂ ਕੀਤਾ ਗਿਆ ਹੈ। ਇਸ ਤਰ੍ਹਾਂ, ਰੁਟੀਨ ਦੇ ਵਿਚਕਾਰ, ਅਸੀਂ ਉਤਪਾਦ ਦੇ ਵਿਕਾਸ ਬਾਰੇ ਕਦੇ ਨਹੀਂ ਭੁੱਲਦੇ.

ਹਰੇਕ ਰੀਲੀਜ਼ ਟੈਸਟਿੰਗ ਅਤੇ ਦਸਤਾਵੇਜ਼ਾਂ ਦੇ ਇੱਕ ਉਚਿਤ ਸਮੂਹ ਵਿੱਚੋਂ ਗੁਜ਼ਰਦੀ ਹੈ। ਅੱਗੇ, ਇਹ ਰੀਲੀਜ਼ ਸੰਬੰਧਿਤ ਗਾਹਕ ਦੇ ਟੈਸਟ ਵਾਤਾਵਰਣ ਵਿੱਚ ਸਥਾਪਿਤ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਜੋ ਬਦਲੇ ਵਿੱਚ, ਹਰ ਚੀਜ਼ ਦੀ ਸਾਵਧਾਨੀ ਨਾਲ ਜਾਂਚ ਕਰਦਾ ਹੈ ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਹੀ ਰਿਲੀਜ਼ ਨੂੰ ਉਤਪਾਦਨ ਵਿੱਚ ਤਬਦੀਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਰੀਲੀਜ਼ ਸਿਸਟਮ ਤੋਂ ਇਲਾਵਾ, ਤੇਜ਼ ਬੱਗ ਫਿਕਸ ਲਈ ਇੱਕ ਫਾਰਮੈਟ ਹੈ ਤਾਂ ਜੋ ਗਾਹਕ ਛੇ ਮਹੀਨਿਆਂ ਲਈ ਗਲਤੀਆਂ ਨਾਲ ਨਾ ਰਹਿਣ। ਇਹ ਇੰਟਰਮੀਡੀਏਟ ਫਾਰਮੈਟ ਤੁਹਾਨੂੰ ਪਹਿਲੀ ਤਰਜੀਹ ਵਾਲੀਆਂ ਘਟਨਾਵਾਂ ਦਾ ਤੁਰੰਤ ਜਵਾਬ ਦੇਣ ਅਤੇ ਦੱਸੇ ਗਏ SLAs ਨੂੰ ਪੂਰਾ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦੇਵੇਗਾ।

ਉਪਰੋਕਤ ਸਾਰੇ ਮੁੱਖ ਤੌਰ 'ਤੇ ਕਾਰਪੋਰੇਟ ਸੈਕਟਰ ਅਤੇ ਆਨ-ਪ੍ਰੀਮਾਈਸ ਹੱਲਾਂ ਲਈ ਸਹੀ ਹਨ। SMB ਖੰਡ ਦੇ ਉਦੇਸ਼ ਨਾਲ ਕਲਾਉਡ ਸੇਵਾਵਾਂ ਲਈ, ਗਾਹਕਾਂ ਲਈ ਉਤਪਾਦ ਵਿਕਾਸ ਵਿੱਚ ਹਿੱਸਾ ਲੈਣ ਦੇ ਅਜਿਹੇ ਕੋਈ ਵਿਆਪਕ ਮੌਕੇ ਨਹੀਂ ਹਨ। SMB ਰੈਂਟਲ ਫਾਰਮੈਟ ਇਸ ਨੂੰ ਮੰਨਦਾ ਵੀ ਨਹੀਂ ਹੈ। ਕਾਰਪੋਰੇਟ ਪਾਰਟੀ ਤੋਂ ਸਪੱਸ਼ਟ ਲੋੜਾਂ ਦੇ ਰੂਪ ਵਿੱਚ ਇੱਕ ਤਬਦੀਲੀ ਦੀ ਬੇਨਤੀ ਦੀ ਬਜਾਏ, ਇੱਥੇ ਸੇਵਾ ਲਈ ਸਿਰਫ਼ ਆਮ ਫੀਡਬੈਕ ਅਤੇ ਇੱਛਾਵਾਂ ਹਨ। ਅਸੀਂ ਸੁਣਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਾਂ, ਪਰ ਉਤਪਾਦ ਬਹੁਤ ਵੱਡਾ ਹੈ ਅਤੇ ਇੱਕ ਗਾਹਕ ਦੀ ਆਪਣੀ ਪੁਰਾਣੀ ਇਤਿਹਾਸਕ ਪ੍ਰਣਾਲੀ ਤੋਂ ਕੁਝ ਜਾਣੂ ਲਿਆਉਣ ਦੀ ਇੱਛਾ ਸਮੁੱਚੇ ਤੌਰ 'ਤੇ ਸਿਸਟਮ ਦੀ ਵਿਕਾਸ ਰਣਨੀਤੀ ਦਾ ਵਿਰੋਧ ਕਰ ਸਕਦੀ ਹੈ।

ਸਰੋਤ: www.habr.com