ਸਟੇਕਹੋਲਡਰਾਂ ਤੋਂ ਫੀਡਬੈਕ ਲਓ—ਬਿਨਾਂ ਬਿਲਡ ਨੂੰ ਭਟਕਾਏ

ਫੀਡਬੈਕ ਕਿਵੇਂ ਬਿਲਡ ਨੂੰ ਭਟਕਾ ਸਕਦਾ ਹੈ

ਜਿਆਦਾਤਰ ਬਿਲਡ ਇੱਕ ਹੀ ਕਾਰਨ ਕਰਕੇ ਰਸਤੇ ਤੋਂ ਭਟਕਦੇ ਹਨ: ਯੋਜਨਾ ਵਾਰ ਵਾਰ ਬਦਲ ਰਹੀ ਹੁੰਦੀ ਹੈ।

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

ਇਸ ਲਈ ਸਟੇਕਹੋਲਡਰ ਫੀਡਬੈਕ ਸਮੱਸਿਆ ਬਣ ਸਕਦਾ ਹੈ, ਭਾਵੇਂ ਸਭ ਦੀ نੀّت ਚੰਗੀ ਹੋਵੇ। ਹਰ ਟਿੱਪਣੀ ਅਪਨੇ ਆਪ ਵਿੱਚ ਛੋਟੀ ਲੱਗਦੀ ਹੈ, ਪਰ ਲਗਾਤਾਰ ਛੋਟੀ-ਛੋਟੀ ਬੇਨਤੀਆਂ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਉਸਦੇ ਮਕਸਦ ਤੋਂ ਹੌਲੀ-ਹੌਲੀ ਪੇਛੇ ਖਿੱਚ ਸਕਦੀਆਂ ਹਨ।

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

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

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

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

ਲਾਗਤ ਸਿਰਫ ਵਾਧੂ ਕੰਮ ਨਹੀਂ ਹੁੰਦੀ। ਇਹ ਗੁੰਝਲ, ਡਿਲਿਵਰੀ ਦੀ ਰੁਕਾਵਟ ਅਤੇ ਇੱਕ ਐਸੀ ਟੀਮ ਹੈ ਜੋ ਹੁਣ ਨਹੀਂ ਜਾਣਦੀ ਕਿ ਮੁਕੰਮਲ ਹੋਣਾ ਕੀ ਦਿਖਦਾ ਹੈ।

ਫੀਡਬੈਕ ਦੀਆਂ ਨਿਯਮ-ਰੇਖਾਵਾਂ ਪਹਿਲਾਂ ਤੈਅ ਕਰੋ

ਜੇ ਤੁਸੀਂ ਲਾਭਦਾਇਕ ਫੀਡਬੈਕ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ ਸ਼ੁਰੂ 'ਚ ਨਿਯਮ ਤੈਅ ਕਰੋ।

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

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

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

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

ਸਕੋਪ ਬਾਰੇ ਵੀ ਸਪਸ਼ਟ ਹੋਵੋ। ਲੋਕਾਂ ਨੂੰ ਦੱਸੋ ਕਿ ਹੁਣ ਕੀ ਰਿਵਿਊ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ, ਕੀ ਬਾਅਦੀ ਫੇਜ਼ ਲਈ ਹੈ ਅਤੇ ਕੀ ਇਸ ਵਰਜਨ ਦੇ ਬਾਹਰ ਹੈ। ਇੱਕ ਸਰਲ ਨੋਟ ਜਿਵੇਂ "ਇਹ ਰਾਊਂਡ ਸਿਰਫ ਸਾਈਨਅੱਪ ਫਲੋ ਅਤੇ ਡੈਸ਼ਬੋਰਡ ਬੇਸਿਕਸ ਲਈ ਹੈ" ਅਕਸਰ ਸਾਈਡ ਰਿਕਵੇਸਟਾਂ ਨੂੰ ਰੋਕ ਦਿੰਦਾ ਹੈ।

ਚੰਗੇ ਨਿਯਮ ਕਠੋਰ ਹੋਣ ਲਈ ਨਹੀਂ ਹੁੰਦੇ। ਉਹ ਸਭ ਲਈ ਫੀਡਬੈਕ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ। ਲੋਕ ਜਾਣ ਲੈਂਦੇ ਹਨ ਕਿ ਕੇਥੇ ਭੇਜਣਾ ਹੈ, ਕਿਵੇਂ ਲਿਖਣਾ ਹੈ, ਕਦੋਂ ਸਮੀਖਿਆ ਹੋਏਗੀ ਅਤੇ ਹੁਣ ਕਿਸ ਤਰ੍ਹਾਂ ਦੀ ਰਾਏ ਲਾਭਦਾਇਕ ਹੈ।

ਰਿਕਵੇਸਟਾਂ ਨੂੰ ਵਰਕਫਲੋਅ ਮੁਤਾਬਕ ਗਰੁੱਪ ਕਰੋ

ਜਦੋਂ ਫੀਡਬੈਕ ਆਉਣ ਲੱਗੇ, ਉਸਨੂੰ ਉਸ ਯੂਜ਼ਰ ਯਾਤਰਾ ਦੇ ਹਿੱਸੇ ਅਨੁਸਾਰ ਛਾਂਟੋ ਜਿਸ 'ਤੇ ਉਹ ਅਸਰ ਕਰਦਾ ਹੈ।

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

ਇਸ ਤਰ੍ਹਾਂ ਦੀ ਛਾਂਟ ਦੋ ਫਾਇਦੇ ਦਿਖਾਉਂਦੀ ਹੈ। ਪਹਿਲਾਂ, ਇਹ ਨਕਲੀਆਂ ਬੇਨਤੀਆਂ ਨੂੰ ਬੇਨਕਾਬ ਕਰਦੀ ਹੈ। ਇੱਕ ਸਟੇਕਹੋਲਡਰ ਕਹਿ ਸਕਦਾ ਹੈ, "ਫਾਰਮ ਦਿੱਲ ਬਹੁਤ ਮੰਗਦਾ ਹੈ," ਤੇ ਦੂਜਾ ਕਹੇ, "ਉਪਭੋਗਤਿਆਂ ਨੂੰ ਪੰਜ ਖੇਤ ਭਰਨੇ ਨਹੀਂ ਚਾਹੀਦੇ।" ਅਕਸਰ ਇਹਨਾਂ ਦਾ ਮਤਲਬ ਇੱਕੋ ਹੀ ਗੱਲ ਹੁੰਦਾ ਹੈ।

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

ਚੰਗੀ ਆਦਤ ਹੈ ਕਿ ਫੀਡਬੈਕ ਨੂੰ ਆਓਣ ਦੇ ਕ੍ਰਮ ਦੀ ਥਾਂ ਵਰਕਫਲੋਅ ਬੈਚਾਂ ਵਿੱਚ ਚਰਚਾ ਕਰੋ। ਮੀਟਿੰਗਾਂ ਕੇਂਦਰਤ ਰਹਿੰਦੀਆਂ ਹਨ ਅਤੇ ਦੁਹਰਾਈ ਵਾਲੀਆਂ ਚਰਚਾਵਾਂ ਥੋੜ੍ਹੀਆਂ ਹੋ ਜਾਂਦੀਆਂ ਹਨ।

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

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

ਬੱਗਾਂ ਨੂੰ ਆਈਡੀਅਾਂ ਤੋਂ ਵੱਖ ਕਰੋ

ਇੱਕ ਗਲਤੀ ਬਹੁਤ ਗੁੰਝਲ पैदा ਕਰਦੀ ਹੈ: ਹਰ ਟਿੱਪਣੀ ਨੂੰ ਇੱਕੋ ਤਰ੍ਹਾਂ ਦੀ ਬੇਨਤੀ ਸਮਝਣਾ।

ਇਹ ਇਕੋ ਨਹੀਂ ਹੁੰਦਾ ਜਦੋਂ ਕੁਝ ਟੁੱਟਿਆ ਹੋਇਆ ਹੈ ਅਤੇ ਜਦੋਂ ਕੋਈ ਬਦਲਾਅ ਚਾਹਿੰਦਾ ਹੈ।

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

ਜੇ ਕਿਸੇ ਗਾਹਕ ਫਾਰਮ ਨੇ ਡੇਟਾ ਭੇਜਨਾ ਬੰਦ ਕਰ ਦਿੱਤਾ, ਉਹ ਬੱਗ ਹੈ। ਜੇ ਕਿਸੇ ਨੇ ਕਿਹਾ ਫਾਰਮ ਛੋਟਾ ਹੋਵੇ ਜਾਂ ਬਟਨ ਦਾ ਰੰਗ ਬਦਲੇ, ਤਾਂ ਉਹ ਆਈਡੀਅ ਹੈ।

ਟੀਮ ਕੰਮ ਰੋਕਣ ਤੋਂ ਪਹਿਲਾਂ, ਬੱਗ ਲਈ ਕੁਝ ਸਪਸ਼ਟ ਮੰਗੋ: ਸਕ੍ਰੀਨਸ਼ੌਟ, ਸਪੱਸ਼ਟ ਕਦਮ, ਪ੍ਰਭਾਵਤ ਪੇਜ ਅਤੇ ਉਮੀਦ ਕੀ ਸੀ। ਬਿਨਾਂ ਇਹਨਾਂ ਦੇ, ਬਹੁਤ ਸਾਰੀਆਂ ਰਿਪੋਰਟ ਕੀਤੀਆਂ "ਬੱਗਾਂ" ਸਮਝੌਤੇ, ਪੁਰਾਣੇ ਵਰਜ਼ਨ ਜਾਂ ਡਿਜ਼ਾਈਨ ਪਸੰਦ ਹੋ ਸਕਦੀਆਂ ਹਨ।

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

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

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

ਇੱਕ ਸਪਸ਼ਟ ਫੈਸਲੇਦਾਰ ਰੱਖੋ

ਜਦੋਂ ਬਹੁਤ ਸਾਰੇ ਲੋਕ 'ਹਾਂ' ਕਹਿ ਸਕਦੇ ਹਨ, ਤਾਂ ਹਰ ਬੇਨਤੀ ਖੁਲੀ ਰਹਿ ਜਾਂਦੀ ਹੈ।

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

ਇਸਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ ਉਹ ਵਿਅਕਤੀ ਹੋਰਾਂ ਦੀ ਅਣਸੁਣੀ ਕਰੇ। ਇਸਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਇਨਪੁਟ ਸਾਂਝਾ ਕੀਤਾ ਜਾਵੇ, ਫਿਰ ਫੈਸਲਾ ਸਥਿਰ ਹੋ ਜਾਵੇ। ਡਿਜ਼ાઈનਰ, ਡਿਵੈਲਪਰ, ਸੇਲਜ਼, ਸਪੋਰਟ ਅਤੇ ਲੀਡਰਸ਼ਿਪ ਸਾਰਾ ਸੰਦਰਭ ਦੇ ਸਕਦੇ ਹਨ। ਪਰ ਇੱਕ ਨਾਂਤਕ ਵਿਅਕਤੀ ਇਹ ਨਿਰਧਾਰਨ ਕਰਦਾ ਹੈ ਕਿ ਹੁਣ ਕੀ ਸ਼ਾਮਲ ਕੀਤਾ ਜਾਵੇ, ਕੀ ਪਿੱਛੇ ਰਹੇ ਅਤੇ ਕੀ ਛੱਡ ਦਿੱਤਾ ਜਾਵੇ।

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

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

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

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

ਲੋਕ ਅਜੇ ਵੀ ਸੁਣੇ ਹੋਏ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ, ਪਰ ਬਿਲਡ ਅੱਗੇ ਵਧਦੀ ਰਹਿੰਦੀ ਹੈ।

ਹਰ ਵਾਰੀ ਇੱਕ ਸਧਾਰਣ ਸਮੀਖਿਆ ਪ੍ਰਕਿਰਿਆ ਵਰਤੋ

ਫੀਡਬੈਕ ਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸੰਭਾਲਣ ਦਾ ਸਭ ਤੋਂ ਆਸਾਨ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਹਰ ਵਾਰੀ ਉਹੀ ਰਾਹ ਫੋਲੋ ਕੀਤਾ ਜਾਵੇ।

ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਹਰ ਰਿਕਵੇਸਟ ਨੂੰ ਇੱਕ ਸਾਂਝੀ ਥਾਂ ਭੇਜੋ। ਫਿਰ ਇਸਨੂੰ ਇੱਕ ਨਿਰਧਾਰਿਤ ਕ੍ਰਮ ਵਿੱਚ ਰਿਵਿਊ ਕਰੋ:

1. ਇਸਨੂੰ ਉਸ ਵਰਕਫਲੋਅ ਦੇ ਅੰਦਰ ਰੱਖੋ ਜਿਸ 'ਤੇ ਇਹ ਅਸਰ ਕਰਦਾ ਹੈ।
2. ਇਨ੍ਹਾਂ ਨੂੰ ਸਪਸ਼ਟ ਲੇਬਲ ਦਿਓ: ਬੱਗ, ਆਈਡੀਅ, ਫੀਚਰ ਬੇਨਤੀ ਜਾਂ ਸਵਾਲ।
3. ਜੇ ਇਹ ਅਸਪਸ਼ਟ ਹੈ ਤਾਂ ਕਿਸੇ ਨੇ ਕਾਰਵਾਈ ਤੋਂ ਪਹਿਲਾਂ ਫਾਲੋਅਪ ਮੰਗੋ।
4. ਦੁਹਰਾਈਆਂ ਨੂੰ ਇੱਕ ਵਸਤੂ ਵਿੱਚ ਮਿਲਾਓ।
5. ਪ੍ਰਭਾਵ ਬਾਰੇ ਛੋਟੀ ਨੋਟ ਜੋੜੋ।

ਅਕਸਰ ਇਹੀ ਜ਼ਿਆਦਾ ਟੀਮਾਂ ਲਈ ਕਾਫ਼ੀ ਹੁੰਦਾ ਹੈ।

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

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

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

ਇਕ ਸਪਸ਼ਟ ਪ੍ਰਕਿਰਿਆ ਲੋਕਾਂ ਨੂੰ ਸੁਣਿਆ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦੀ ਹੈ ਬਿਨਾਂ ਹਰ ਇੱਕ ਰਾਏ ਨੂੰ ਤੁਰੰਤ ਕੰਮ ਬਣਾਉਣ ਦੇ।

ਫੀਲਡ ਟ੍ਰਯਾਜ਼ ਕਿਵੇਂ ਦਿਖਦੀ ਹੈ ਵਾਸਤਵਿਕ ਜੀਵਨ ਵਿੱਚ

ਕਲਪਨਾ ਕਰੋ ਇੱਕ ਛੋਟੀ ਟੀਮ ਗਾਹਕ ਐਪ ਬਣਾ ਰਹੀ ਹੈ।

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

ਤਿੰਨوں ਬੇਨਤੀਆਂ ਮਹੱਤਵਪੂਰਨ ਲੱਗਦੀਆਂ ਹਨ, ਪਰ ਉਹਨਾਂ ਨੂੰ ਇੱਕੋ ਹੀ ਪ੍ਰਾਥਮਿਕਤਾ ਵਾਲੇ ਬਕਸੇ ਵਿੱਚ ਨਹੀਂ ਰੱਖਣਾ ਚਾਹੀਦਾ।

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

ਇਹ ਛਾਂਟ ਹੀ ਮਦਦ ਕਰਦੀ ਹੈ। ਇਹ ਤਿੰਨ ਰਿਕਵੇਸਟ ਇੱਕੋ ਜਗ੍ਹਾ ਦੀਆਂ ਨਹੀਂ ਹਨ ਅਤੇ ਵੱਖ-ਵੱਖ ਤਰ੍ਹਾਂ ਦੇ ਜਰੂਰੀਪਨ ਰੱਖਦੀਆਂ ਹਨ।

ਅਗਲੇ ਕਦਮ 'ਚ ਫੈਸਲੇਦਾਰ ਹਰ ਇੱਕ ਨੂੰ ਲੇਬਲ ਕਰਦਾ ਹੈ। ਰੀਸੈਟ ਈਮੇਲ ਬੱਗ ਹੈ। ਵਾਧੂ ਖੇਤ ਫੀਚਰ ਬੇਨਤੀ ਹਨ। ਚਾਰਟ ਸੁਧਾਰ ਦਾ ਆਈਡੀਅ ਹੈ।

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

ਵਾਧੂ ਖੇਤ ਲਾਭਕਾਰੀ ਹੋ ਸਕਦੇ ਹਨ ਪਰ ਜ਼ਰੂਰੀ ਨਹੀਂ। ਫੈਸਲੇਦਾਰ ਇੱਕ ਫਾਲੋਅਪ ਸਵਾਲ ਪੁੱਛਦਾ: ਕੀ ਇਹ ਖੇਤ ਅਜੇ ਲੀਡ ਨੂੰ ਯੋਗਕਰਣ ਵਿੱਚ ਮਦਦ ਕਰਨਗੇ ਜਾਂ ਪਹਿਲਾਂ ਮੌਜੂਦਾ ਫਾਰਮ ਟੈਸਟ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ? ਜੇ ਜਵਾਬ ਸਪਸ਼ਟ ਨਹੀਂ ਹੈ ਤਾਂ ਬੇਨਤੀ ਰੁਕ ਜਾਂਦੀ ਹੈ।

ਚਾਰਟ идея 'ਤੇ ਰੱਖ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਮਾਰਕੀਟਿੰਗ ਨੂੰ ਉਹ ਚਾਹੀਦਾ ਹੋ ਸਕਦਾ ਹੈ ਪਰ ਇਹ ਕਿਸੇ ਨੂੰ ਸਾਈਨਅੱਪ ਕਰਨ, ਲੌਗਿਨ ਕਰਨ ਜਾਂ ਮੁੱਖ ਕੰਮ ਪੂਰਾ ਕਰਨ ਤੋਂ ਨਹੀਂ ਰੋਕਦਾ।

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

ਆਮ ਗਲਤੀਆਂ ਜੋੋਂ ਬਚਣਾ ਚਾਹੀਦਾ ਹੈ

ਬਿਲਡ ਤੇ ਕਬਜ਼ਾ کھੋਣ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਹਰ ਫੀਡਬੈਕ ਨੂੰ ਤੁਰੰਤ ਟਾਸਕ ਸਮਝ ਲਿਆ ਜਾਵੇ।

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

ਅਸਪਸ਼ਟ ਨੋਟਾਂ ਵੀ ਮੁਸ਼ਕਿਲ ਪੈਦਾ ਕਰਦੀਆਂ ਹਨ। "ਇਸਨੂੰ ਆਸਾਨ ਬਣਾਓ" ਜਾਂ "ਇਸਨੂੰ ਸਾਫ਼ ਕਰੋ" ਵਰਗੀਆਂ ਟਿੱਪਣੀਆਂ ਲਾਭਦਾਇਕ لگਦੀਆਂ ਹਨ ਪਰ ਕਾਰਵਾਈ ਯੋਗ ਨਹੀਂ। ਜਦ ਤਕ ਕਿਸੇ ਨੇ ਇਸ ਨੂੰ ਸਪਸ਼ਟ ਸਮੱਸਿਆ ਵਿੱਚ ਨਹੀਂ ਬਦਲਿਆ, ਟੀਮ ਅਣਧਿਆਨੀ ਹੋਕੇ ਅਨੁਮਾਨ ਲਾਵੇਗੀ।

ਝੂਠੀ ਸਹਿਮਤੀ ਇੱਕ ਹੋਰ ਫੰਦ ਹੈ। ਲੋਕ ਮੀਟਿੰਗ ਵਿੱਚ ਸਿਰ ਊਠਾ ਦਿੰਦੇ ਹਨ "ਅਸੀਂ ਸਾਰੇ ਸਹਿਮਤ ਹਾਂ," ਪਰ ਜੇ ਕਿਸੇ ਕੋਲ ਫੈਸਲਾ ਕਰਨ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਨਹੀਂ, ਤਾਂ ਅਗਲੇ ਦਿਨ ਉਹੀ ਮੁੱਦਾ ਨਵੇਂ ਵਿਚਾਰ ਨਾਲ ਮੁੜ ਆ ਜਾਂਦਾ ਹੈ।

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

ਇੱਕ ਵਧੀਆ ਆਦਤ ਸਧਾਰਨ ਹੈ: ਰੁਕੋ, ਸਪਸ਼ਟ ਕਰੋ, ਗਰੁੱਪ ਕਰੋ ਅਤੇ ਫੈਸਲਾ ਕਰੋ।

ਕੰਮ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਛੋਟਾ ਚেকਲਿਸਟ

ਨਵਾਂ ਫੀਡਬੈਕ ਕਾਰਵਾਈ 'ਤੇ ਲਿਆਉਣ ਤੋਂ ਪਹਿਲਾਂ 5 ਮਿੰਟ ਲੈ ਕੇ ਕੁਝ ਮੂਲ ਗੱਲਾਂ ਚੈੱਕ ਕਰੋ।

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

ਫਿਰ ਦੇਖੋ ਕਿ ਫੈਸਲੇਦਾਰ ਨੇ ਇਸਨੂੰ ਮਨਜ਼ੂਰ ਕੀਤਾ ਹੈ ਜਾਂ ਨਹੀਂ ਅਤੇ ਕੀ ਇਹ ਹੁਣ ਕਰਵਾਈ ਲੋੜਦਾ ਹੈ ਜਾਂ ਅਗਲੇ ਸਮੀਖਿਆ ਚੱਕਰ ਲਈ ਰਹਿ ਸਕਦਾ ਹੈ।

ਇਹ ਛੋਟਾ ਫਿਲਟਰ ਬਹੁਤ ਸਾਰਾ ਸ਼ੋਰ ਕੱਟ ਦਿੰਦਾ ਹੈ। ਇਕ ਬੱਲਾਕ ਬੱਗ ਜੋ ਯੂਜ਼ਰਾਂ ਨੂੰ ਰੋਕਦਾ ਹੈ ਉਸਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਭੇਜੋ। ਇੱਕ ਸੁਧਾਰ ਜੋ ਅਨੁਭਵ ਬਣਾਉਂਦਾ ਹੈ ਉਹ ਯੋਜਨਾ ਲਈ ਰੁਕ ਸਕਦਾ ਹੈ।

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

ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ 'ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਇਹ ਹੋਰ ਵੀ ਜ਼ਰੂਰੀ ਹੋ ਜਾਂਦਾ ਹੈ। ਤੇਜ਼ੀ ਤਦ ਹੀ ਲਾਭਦਾਇਕ ਹੈ ਜਦ ਕੰਮ ਅਸਲ ਯੂਜ਼ਰ ਲੋੜਾਂ ਅਤੇ ਸਪਸ਼ਟ ਮਨਜ਼ੂਰੀ ਨਾਲ ਜੁੜਿਆ ਰਹੇ।

ਕਾਰਗਰ ਅਗਲੇ ਕਦਮ

ਭਾਰੀ ਪ੍ਰਕਿਰਿਆ ਨਾਲ ਸ਼ੁਰੂ ਨਾ ਕਰੋ। ਇੱਕ ਸਾਂਝਾ ਟੈਂਪਲੇਟ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਹਰ ਕੋਈ ਵਰਤੇ।

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

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

ਇੱਕ ਸਧਾਰਣ ਫੈਸਲਾ ਲੌਗ ਵੀ ਰੱਖੋ। ਇੱਕ spreadsheet ਜਾਂ ਛੋਟੀ ਟੇਬਲ ਕਾਫ਼ੀ ਹੈ। ਜੋ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ ਲੋਕ ਵੇਖ ਸਕਣ ਕੀ ਮਨਜ਼ੂਰ ਹੋਇਆ, ਕੀ ਮੁਲਤਵੀ ਕੀਤਾ ਗਿਆ ਅਤੇ ਕਿਉਂ।

ਜੇ ਤੁਹਾਡੀ ਟੀਮ Koder.ai ਵਿੱਚ ਬਣਾਉਂਦੀ ਹੈ, ਤਾਂ planning mode ਮਦਦਗਾਰ ਹੋ ਸਕਦਾ ਹੈ ਜਦ ਫੀਡਬੈਕ ਮਨਜ਼ੂਰ ਹੋ ਜਾਵੇ। ਇਹ ਤੁਹਾਨੂੰ ਇੱਕ ਬੇਨਤੀ ਨੂੰ ਬਿਲਡ ਕਦਮਾਂ ਵਿੱਚ ਬਦਲਣ ਦਾ ਤਰੀਕਾ ਦਿੰਦਾ ਹੈ। ਜਦੋਂ ਤਬਦੀਲੀਆਂ ਦੀ ਜਾਂਚ ਕਰਨੀ ਹੋਵੇ, snapshots ਮਦਦ ਕਰਦੇ ਹਨ—ਅਪਡੇਟ ਦੀ ਟੈਸਟਿੰਗ, ਪ੍ਰਤਿਕ੍ਰਿਆ ਇਕੱਠੀ ਕਰਨੀ ਅਤੇ ਲੋੜ ਪੈਣ 'ਤੇ ਰੋਲਬੈਕ ਕਰਨ ਲਈ ਬਿਨਾਂ ਸੁਰੱਖਿਅਤ ਵਰਜਨ ਗੁਆਏ।

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

ਇਹੀ ਲਕੜੀ ਹੈ: ਫੀਡਬੈਕ ਨੂੰ ਉਤਪਾਦ ਨੂੰ ਬੇਤਰ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਾ ਕਿ ਉਨ੍ਹਾਂ ਨੂੰ ਰਾਹ ਤੋਂ بھਟਕਾਉਣਾ।