ਕਈ ਐਪਾਂ ਪਰਫੈਕਟ ਇੰਜੀਨੀਅਰਿੰਗ ਦੇ ਬਜਾਏ ਵੀ ਕਾਰਗਰ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਜਾਣੋ ਕਿ ਕਦੋਂ “ਪਰਯਾਪਤ” ਠੀਕ ਹੈ, ਖਤਰੇ ਅਤੇ ਤਕਨੀਕੀ ਕਰਜ਼ੇ ਦਾ ਪ੍ਰਬੰਧ ਕਿਵੇਂ ਕਰਣਾ ਹੈ, ਅਤੇ ਕਿਹੜੇ ਖੇਤਰਾਂ ਵਿੱਚ ਗੁਣਵੱਤਾ ਅਟੱਲ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।
“ਪੂਰੀ ਇੰਜੀਨੀਅਰਿੰਗ” ਆਮ ਤੌਰ 'ਤੇ ਉਹ ਕੋਡ ਹੁੰਦਾ ਹੈ ਜੋ ਸੁੰਦਰ ਤਰੀਕੇ ਨਾਲ ਬਣਿਆ ਹੋਵੇ, ਵੱਧ ਤੋਂ ਵੱਧ ਓਪਟੀਮਾਈਜ਼ ਕੀਤਾ ਹੋਇਆ, ਵਿਸਤ੍ਰਿਤ ਟੈਸਟ ਕੀਤਾ ਹੋਇਆ, ਅਤੇ ਹਰ ਭਵਿੱਖੀ ਸਥਿਤੀ ਨੂੰ ਸਾਂਭਣ ਲਈ ਡਿਜ਼ਾਇਨ ਕੀਤਾ ਗਿਆ—ਭਾਵੇਂ ਉਹ ਸਥਿਤੀਆਂ ਕਦੇ ਆਈਆਂ ਹੀ ਨਾ ਹੋਣ।
“ਉਪਯੋਗੀ ਸੌਫਟਵੇਅਰ” ਸਧਾਰਨ ਹੈ: ਇਹ ਕਿਸੇ ਨੂੰ ਇੱਕ ਕੰਮ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਮੁਕੰਮਲ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ ਤਾਂ ਜੋ ਉਹ ਇਸਨੂੰ ਵਰਤਦਾ ਰਹੇ। ਇਹ ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ ਸੋਹਣਾ ਨਾ ਵੀ ਹੋਵੇ, ਪਰ ਇਹ ਸਪੱਸ਼ਟ ਉਪਭੋਗਤਾ ਮੁੱਲ ਦਿੰਦਾ ਹੈ।
ਅਧਿਕਤਰ ਲੋਕ ਕਿਸੇ ਐਪ ਨੂੰ ਇਸ ਲਈ ਨਹੀਂ اپਣਾਉਂਦੇ ਕਿ ਉਸਦੀ ਆਰਕੀਟੈਕਚਰ ਸਾਫ਼ ਹੈ। ਉਹ ਇਸਨੂੰ ਇਸ ਲਈ ਵਰਤਦੇ ਹਨ ਕਿਉਂਕਿ ਇਹ ਸਮਾਂ ਬਚਾਉਂਦਾ ਹੈ, ਗਲਤੀਆਂ ਘਟਾਉਂਦਾ ਹੈ, ਜਾਂ ਉਹ ਕੰਮ ਕਰਵਾਂਦਾ ਹੈ ਜੋ ਪਹਿਲਾਂ ਮੁਸ਼ਕਿਲ ਸੀ। ਜੇ ਤੁਹਾਡੀ ਐਪ ਲਗਾਤਾਰ ਸਹੀ ਨਤੀਜਾ ਦਿੰਦੀ ਹੈ, reasonably ਤੇਜ਼ ਲੋਡ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਡੇਟਾ ਲੋਸ ਜਾਂ ਉਲਝਣ ਵਾਲੇ ਵਿਹਾਰ ਨਾਲ ਉਪਭੋਗਤਿਆਂ ਨੂੰ ਹੈਰਾਨ ਨਹੀਂ ਕਰਦੀ, ਤਾਂ ਇਹ ਬਹੁਤ ਲਾਭਦਾਇਕ ਹੋ ਸਕਦੀ ਹੈ—ਚਾਹੇ ਕੋਡਬੇਸ ਸ਼ੋਕੇਸ ਨਾ ਹੋਵੇ।
ਇਹ ਘੰਦਲ ਕੰਮ ਲਈ ਐਸਾ ਦਲੀਲ ਨਹੀਂ ਹੈ। ਇਹ ਆਪਣੇ ਯੁੱਧਾਂ ਦੀ ਚੋਣ ਕਰਨ ਲਈ ਦਲੀਲ ਹੈ। ਇੰਜੀਨੀਅਰਿੰਗ ਦੀ ਕੋਸ਼ਿਸ਼ ਸੀਮਤ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਅੰਦਰੂਨੀ ਹਿੱਸਿਆਂ ਨੂੰ ਪੋਲਿਸ਼ ਕਰਨ ਵਿੱਚ ਹਰ ਹਫ਼ਤਾ ਉਹ ਹਫ਼ਤਾ ਹੈ ਜੋ ਉਪਭੋਗਤਾ ਅਨੁਭਵ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣ ਤੋਂ ਕੱਟਿਆ ਜਾਂਦਾ ਹੈ: ਓਨਬੋਰਡਿੰਗ, ਸਪੱਸ਼ਟਤਾ, ਕੋਰ ਫੀਚਰ, ਅਤੇ ਸਹਾਇਤਾ।
ਅਸੀਂ ਵੇਖਾਂਗੇ ਕਿ ਗੁਣਵੱਤਾ ਨਾਲ ਖ਼ਤਰਾ ਲੈਣ ਦੇ ਬਿਨਾਂ ਪ੍ਰਗਮੈਟਿਕ ਉਤਪਾਦ ਇੰਜੀਨੀਅਰਿੰਗ ਟਰੇਡ-ਆਫ਼ ਕਿਵੇਂ ਕਰਨੇ ਜਾਣ।
ਅਸੀਂ ਐਸੇ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦਿਆਂਗੇ:
ਲਕਸ਼ ਹੈ ਕਿ ਤੁਸੀਂ ਭਰੋਸੇ ਨਾਲ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰੋ: ਹੁਣ ਅਸਲੀ ਉਪਭੋਗਤਾ ਮੁੱਲ ਦਿਓ, ਅਤੇ ਗੁਣਵੱਤਾ ਬਾਅਦ ਵਿੱਚ ਖਤਰੇ ਅਤੇ ਸਬੂਤ ਅਧਾਰਿਤ ਸੁਧਾਰ ਜਾਂਚੇ ਜਾਣ।
ਅਧਿਕਤਰ ਉਪਭੋਗਤਾ ਉਹ ਨਹੀਂ ਚਾਹੁੰਦੇ ਕਿ ਤੁਹਾਡਾ ਕੋਡਬੇਸ ਸੁੰਦਰ ਅਬਸਟ੍ਰੈਕਸ਼ਨਾਂ ਨਾਲ ਭਰਪੂਰ ਹੋਵੇ। ਉਹ ਇੱਕ ਟਾਸਕ ਘੱਟ ਘਰਲੂ ਰੁਕਾਵਟ ਨਾਲ ਪੂਰਾ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਨ। ਜੇ ਐਪ ਉਨ੍ਹਾਂ ਨੂੰ ਇੱਕ ਸਪੱਸ਼ਟ ਨਤੀਜਾ ਤੇਜ਼ੀ ਨਾਲ ਪਹੁੰਚਣ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ—ਅਤੇ ਰਸਤੇ ਵਿੱਚ ਭਰੋਸਾ ਨਹੀਂ ਟੋੜਦੀ—ਤਾਂ ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਇਸਨੂੰ “ਚੰਗਾ” ਮੰਨ ਲੈਂਦੇ ਹਨ।
ਦਿਨ-ਦੁਨੀਆ ਦੀਆਂ ਐਪਾਂ ਲਈ ਉਪਭੋਗਤਾ ਪ੍ਰਾਥਮਿਕਤਾਵਾਂ ਹੈਰਾਨ ਕਰਨ ਵਾਲੀਆਂ ਤਰ੍ਹਾਂ ਸਥਿਰ ਹਨ:
ਨੋਟ ਕਰੋ ਕਿ ਕੀ غਾਇب ਹੈ: ਅੰਦਰੂਨੀ ਆਰਕੀਟੈਕਚਰ, ਫਰੇਮਵਰਕ, ਮਾਈਕਰੋਸਰਵਿਸਿਜ਼ ਦੀ ਗਿਣਤੀ, ਜਾਂ ਡੋਮੇਨ ਮਾਡਲ ਦੀ “ਸਾਫ਼ਾਈ”।
ਉਪਭੋਗਤਾ ਤੁਹਾਡੇ ਪ੍ਰੋਡਕਟ ਨੂੰ ਉਸ ਤਰ੍ਹਾਂ ਅੰਕਣ ਕਰਦੇ ਹਨ ਜਦੋਂ ਉਹ ਕਲਿੱਕ, ਟਾਈਪ, ਭੁਗਤਾਨ, ਅੱਪਲੋਡ, ਜਾਂ ਸਣਦੇ ਹਨ—ਨਾ ਕਿ ਤੁਸੀਂ ਇਹ ਕਿਵੇਂ ਕੀਤਾ। ਇੱਕ ਗੰਦੇ ਤਰੀਕੇ ਨਾਲ ਲਿਖਿਆ ਇੰਪਲੀਮੈਨਟੇਸ਼ਨ ਜੋ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਉਨ੍ਹਾਂ ਨੂੰ ਐਪੌਇੰਟਮੈਂਟ ਬੁੱਕ ਕਰਨ ਜਾਂ ਚਲਾਨ ਭੇਜਣ ਦਿੰਦਾ ਹੈ, ਉਸ ਸੁੰਦਰ ਇੰਜੀਨੀਅਰ ਕੀਤਾ ਸਿਸਟਮ ਨੂੰ ਹਰਾ ਦੇਵੇਗਾ ਜੋ ਸੁਸਤ ਜਾਂ ਉਲਝਣ ਭਰਿਆ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ।
ਇਹ ਇੰਜੀਨੀਅਰਿੰਗ ਵਿਰੋਧੀ ਨਹੀਂ ਹੈ—ਇਹ ਯਾਦ ਦਿਲਾਉਂਦਾ ਹੈ ਕਿ ਇੰਜੀਨੀਅਰਿੰਗ ਗੁਣਵੱਤਾ ਉਸ ਹੱਦ ਤੱਕ ਮਹੱਤਵਪੂਰਨ ਹੈ ਜਦ ਤੱਕ ਉਹ ਅਨੁਭਵ ਨੂੰ ਸੁਧਾਰਦੀ ਹੈ ਅਤੇ ਖਤਰੇ ਘਟਾਉਂਦੀ ਹੈ।
“ਪਰਯਾਪਤ” ਅਕਸਰ ਉਹ ਤਰੀਕੇ ਹਨ ਜੋ ਉਪਭੋਗਤਾ ਨੂੰ ਤੁਰੰਤ ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ:
ਉਪਭੋਗਤਾ ਨਿੱਕੀਆਂ ਰੁਕਾਵਟਾਂ ਬਰਦਾਸ਼ਤ ਕਰ ਲੈਂਦੇ ਹਨ—ਕਦੇ-ਕਦੇ ਧੀਮੀ ਐਨੀਮੇਸ਼ਨ, ਥੋੜ੍ਹਾ ਅਚਰ-ਚੋੜਾ settings ਸਕਰੀਨ, ਜਾਂ ਇੱਕ ਮਿਸਿੰਗ ਕੀਬੋਰਡ ਸ਼ਾਰਟਕੱਟ।
ਉਹ ਡੀਲ-ਬ੍ਰੇਕਰ ਨਹੀਂ ਬਰਦਾਸ਼ਤ ਕਰਦੇ: ਡੇਟਾ ਖੋ ਜਾਣਾ, ਗਲਤ ਨਤੀਜੇ, ਅਚਾਨਕ ਚਾਰਜ, ਸੁਰੱਖਿਆ ਸੰਬੰਧੀ ਮੁੱਦੇ, ਜਾਂ ਕੁਝ ਵੀ ਜੋ ਐਪ ਵਾਅਦਾ ਕਰਨ ਵਾਲੇ ਮੁੱਖ ਕੰਮ ਨੂੰ ਰੋਕੇ। ਇਹੀ ਲਕੀਰ ਜਿਨ੍ਹਾਂ ਉਤਪਾਦਾਂ ਨੂੰ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਰੱਖਣੀ ਚਾਹੀਦੀ ਹੈ: ਕੋਰ ਨਤੀਜੇ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰੋ, ਫਿਰ ਉੱਚ-ਟੱਚ ਏਜਾਂ ਨੂੰ ਪਾਲਿਸ਼ ਕਰੋ।
ਉਤਪਾਦ ਦੀ ਜ਼ਿੰਦਗੀ ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ, ਤੁਸੀਂ ਅਧੂਰੇ ਜਾਣਕਾਰੀ ਨਾਲ ਫੈਸਲੇ ਲੈ ਰਹੇ ਹੋ। ਤੁਹਾਨੂੰ ਅਜੇ ਨਹੀਂ ਪਤਾ ਕਿ ਕਿਹੜਾ ਗਾਹਕ ਸੈਗਮੈਂਟ ਟਿਕੇਗਾ, ਕਿਹੜੇ ਵਰਕਫਲੋਜ਼ ਰੋਜ਼ਾਨਾ ਆਦਤ ਬਣਨਗੇ, ਜਾਂ ਕਿਹੜੇ ਐਜ ਕੇਸ ਕਦੇ ਆਉਣਗੇ ਹੀ ਨਹੀਂ। ਉਸ ਅਨਿਸ਼ਚਿਤਤਾ ਹੇਠਾਂ “ਪੂਰਾ” ਇੰਜੀਨੀਅਰਿੰਗ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਅਕਸਰ ਉਹ ਗਰਾਂਟੀਆਂ ਭੁਗਤਣੀ ਬਣ ਜਾਂਦੀ ਹੈ ਜਿੰਨ੍ਹਾਂ ਦੀ ਤੁਹਾਨੂੰ ਲੋੜ ਨਹੀਂ ਹੈ।
ਪਰਫੈਕਸ਼ਨ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਕਿਸਮ ਦੀ ਓਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਹੁੰਦੀ ਹੈ: ਤੇਜ਼ ਪ੍ਰਦਰਸ਼ਨ, ਸਾਫ਼ ਅਬਸਟ੍ਰੈਕਸ਼ਨ, ਵੱਧ ਲਚਕੀਲਾ ਆਰਕੀਟੈਕਚਰ, ਵਿਆਪਕ ਕਵਰੇਜ। ਇਹ ਉਹ ਸਮੇਂ ਵੈਲਯੂਫੁਲ ਹੋ ਸਕਦੇ ਹਨ—ਜਦ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ ਕਿ ਇਹ ਕਿੱਥੇ ਉਪਭੋਗਤਾ ਮੁੱਲ ਬਣਾਉਂਦੇ ਹਨ।
ਪਰ ਸ਼ੁਰੂ ਵਿੱਚ ਸਭ ਤੋਂ ਵੱਡਾ ਖਤਰਾ ਗਲਤ ਚੀਜ਼ ਬਣਾਉਣਾ ਹੈ।ਓਵਰਬਿਲਡਿੰਗ ਮਹਿੰਗੀ ਪੈਂਦੀ ਹੈ ਕਿਉਂਕਿ ਇਹ ਉਹਨਾਂ ਫੀਚਰਾਂ 'ਤੇ ਕੰਮ ਦੂਗੁਣਾ ਕਰਦੀ ਜੋ ਕੋਈ ਵਰਤਦਾ ਹੀ ਨਹੀਂ: ਵਾਧੂ ਸਕਰੀਨ, ਸੈਟਿੰਗਸ, ਇੰਟੈਗਰੇਸ਼ਨ, ਅਤੇ ਲੇਅਰ "ਸਰਫ਼ ਇਨ੍ਹਾਂ ਲਈ।" ਭਾਵੇਂ ਸਭ ਕੁਝ ਸੋਹਣਾ ਹੋਵੇ, ਜੇ ਇਹ ਅਡਾਪਸ਼ਨ, ਰੀਟੇਨਸ਼ਨ ਜਾਂ ਆਮਦਨ ਨਹੀਂ ਵਧਾਉਂਦਾ ਤਾਂ ਇਹ ਬੇਵਕੂਫ਼ੀ ਹੈ।
ਇੱਕ ਵਧੀਆ ਰਣਨੀਤੀ ਇਹ ਹੈ ਕਿ ਕਿਸੇ ਅਸਲ चीਜ਼ ਨੂੰ ਉਪਭੋਗਤਿਆਂ ਦੇ ਹੱਥਾਂ ਵਿੱਚ ਪਹੁੰਚਾਓ ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਸਿੱਖੋ। ਸ਼ਿਪਿੰਗ ਇੱਕ ਫੀਡਬੈਕ ਲੂਪ ਬਣਾਉਂਦੀ ਹੈ:
ਉਹ ਲੂਪ ਅਨਿਸ਼ਚਿਤਤਾ ਨੂੰ ਸਪੱਸ਼ਟਤਾ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ—ਅਤੇ ਤੁਹਾਨੂੰ ਉਹੀ ਗੱਲਾਂ 'ਤੇ ਧਿਆਨ ਕਰਨ ਲਈ ਮਜ਼ਬੂਰ ਕਰਦਾ ਹੈ ਜੋ ਅਸਲ ਵਿੱਚ ਮਤਲਬ ਰੱਖਦੀਆਂ ਹਨ।
ਹਰ ਚੋਣ ਨੂੰ ਇਕੋ ਜਿਹੀ ਗੰਭੀਰਤਾ ਦੇਣ ਜ਼ਰੂਰੀ ਨਹੀਂ। ਇਕ ਬਹੁਤ ਸਧਾਰਣ ਨਿਯਮ ਹੈ:
ਜਿੱਥੇ ਉਲਟਣਾ ਮਹਿੰਗਾ ਜਾਂ ਖਤਰਨਾਕ ਹੋਵੇ, ਓਥੇ ਪਹਿਲਾਂ ਨਿਵੇਸ਼ ਕਰੋ। ਬਾਕੀ ਹਰ ਜਗ੍ਹਾ “ਸਿੱਖਣ ਲਈ ਪ੍ਰਯਾਪਤ” ਆਮ ਤੌਰ 'ਤੇ ਸਿਆਣਾ ਹੁੰਦਾ ਹੈ।
MVP (ਘੱਟੋ-ਘੱਟ ਵਰਤੋਂਯੋਗ ਉਤਪਾਦ) ਇੱਕ “ਸਸਤਾ ਵਰਜਨ” ਨਹੀਂ; ਇਹ ਇੱਕ ਸਿੱਖਣ ਦਾ ਸੰਦ ਹੈ: ਸਭ ਤੋਂ ਛੋਟੀ ਰਿਲੀਜ਼ ਜੋ ਕਿਸੇ ਅਸਲ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇ ਸਕੇ। ਠੀਕ ਕੀਤਾ ਗਿਆ, ਇਹ ਤੁਹਾਨੂੰ ਮੰਗ, ਕੀਮਤ, ਵਰਕਫਲੋਜ਼, ਅਤੇ ਸੁਨੇਹਾਬਾਜ਼ੀ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ ਪਹਿਲਾਂ ਕਿ ਤੁਸੀਂ ਮਹੀਨਿਆਂ ਨੂੰ ਗਲਤ ਚੀਜ਼ਾਂ ਬਿਲਡ ਕਰਨ ਵਿੱਚ ਖਰਚੋ।
ਇੱਕ ਪ੍ਰੋਟੋਟਾਈਪ ਆਮ ਤੌਰ 'ਤੇ ਅੰਦਰੂਨੀ ਸਿੱਖਣ ਲਈ ਹੋਂਦਾ ਹੈ। ਇਹ ਇੱਕ ਕਲਿੱਕੇਬਲ ਮੋਕਅਪ, ਇੱਕ concierge ਟੈਸਟ, ਜਾਂ ਇੱਕ throwaway ਡੇਮੋ ਹੋ ਸਕਦਾ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਵਿਚਾਰਾਂ ਦੀ ਪੜਤਾਲ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।
ਇੱਕ MVP ਯੂਜ਼ਰਾਂ ਲਈ ਹੁੰਦਾ ਹੈ। ਜਦ ਅਸਲ ਗਾਹਕ ਇਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ, ਤਾਂ ਇਸਨੂੰ ਪ੍ਰੋਡਕਸ਼ਨ ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ ਦੀ ਲੋੜ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ: ਭਵਿਸ਼ਵਾਣੀ ਵਿਹਾਰ, ਸਪੱਸ਼ਟ ਹੱਦਾਂ, ਅਤੇ ਸਮੱਸਿਆ ਆਉਣ 'ਤੇ ਸਹਾਇਤਾ ਦਾ ਰਸਤਾ। MVP ਛੋਟਾ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਲੱਛਣਹੀਨ ਨਹੀਂ ਹੋ ਸਕਦਾ।
ਇੱਕ ਕਾਰਨ ਕਿ ਟੀਮਾਂ ਓਵਰਇੰਜੀਨੀਅਰਿੰਗ ਵੱਲ ਝੁਕ ਜਾਂਦੀਆਂ ਹਨ ਉਹ ਹੈ ਕਿ ਆਈਡੀਆ ਤੋਂ ਵਰਕਿੰਗ ਸਾਫਟਵੇਅਰ ਤਕ ਰਸਤਾ ਧੀਮਾ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਉਹ "ਇਸਨੂੰ ਮ੍ਰਦੁ ਬਣਾਉਂਦੇ" ਹੋਏ ਵਾਧੂ ਆਰਕੀਟੈਕਚਰ ਜੋੜ ਲੈਂਦੇ ਹਨ। ਤੇਜ਼ ਬਿਲਡ ਲੂਪ ਇਸ ਪ੍ਰੇਲਣ ਨੂੰ ਘੱਟ ਕਰ ਸਕਦਾ ਹੈ। ਉਦਾਹਰਨ ਵਜੋਂ, Koder.ai ਇੱਕ vibe-coding ਪਲੇਟਫਾਰ्म ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਚੈਟ ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਵੈਬ, ਬੈਕਐਂਡ, ਜਾਂ ਮੋਬਾਈਲ ਐਪ ਬਣਾਉਂਦੇ ਹੋ, ਫਿਰ ਸਰੋਤ ਕੋਡ ਐਕਸਪੋਰਟ, ਡਿਪਲੋਈ, ਅਤੇ snapshots/rollback ਨਾਲ ਦੁਹਰਾਅ ਕਰ ਸਕਦੇ ਹੋ। ਚਾਹੇ ਤੁਸੀਂ Koder.ai ਜਾਂ ਰਵਾਇਤੀ ਸਟੈਕ ਵਰਤਦੇ ਹੋ, ਸਿਧਾਂਤ ਇੱਕੋ ਹੈ: ਫੀਡਬੈਕ ਚਕਰ ਛੋਟੇ ਕਰੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਉਹਨਾ ਥਾਵਾਂ 'ਤੇ ਇੰਜੀਨੀਅਰਿੰਗ ਸਮਾਂ ਖਰਚ ਕਰੋ ਜਿੱਥੇ ਅਸਲੀ ਵਰਤੋਂ ਇਸ ਦੀ ਵਾਜਬੀ ਸਾਬਤ ਕਰੇ।
MVP ਇੱਕ ਪੜਾਅ ਹੈ, ਸਥਾਈ ਪਹਚਾਣ ਨਹੀਂ। ਜੇ ਉਪਭੋਗਤਿਆਂ ਨੂੰ ਲਗਾਤਾਰ ਘੱਟ ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ ਅਤੇ ਬਦਲਦੇ ਨਿਯਮ ਦਿਖਾਈ ਦੇ ਰਹੇ ਹੋਣ, ਤਾਂ ਉਹ ਪ੍ਰੋਡਕਟ 'ਤੇ ਭਰੋਸਾ ਖੋ ਦੇਂਦੇ ਹਨ—ਭਾਵੇਂ ਕੋਰ ਆਈਡੀਆ ਚੰਗੀ ਹੋਵੇ।
ਇਕ ਸਿਹਤਮੰਦ ਰਵੱਈਆ ਇਹ ਹੈ: ਸਭ ਤੋਂ ਰਿਸਕੀ ਧਾਰਨਾਵਾਂ ਨੂੰ ਪਹਿਲਾਂ ਸਚ ਕਰਕੇ ਵੈਰੀਫਾਈ ਕਰੋ, ਫਿਰ ਜੋ ਚੱਲ ਰਿਹਾ ਹੈ ਉਸਨੂੰ ਮਜ਼ਬੂਤ ਕਰੋ। ਆਪਣੇ MVP ਨੂੰ ਇੱਕ ਭਰੋਸੇਯੋਗ 1.0 ਵਿੱਚ ਬਦਲੋ: ਵਧੀਆ ਡਿਫਾਲਟਸ, ਘੱਟ ਹੈਰਾਨੀ, ਸਪੱਸ਼ਟ UX, ਅਤੇ ਮੈਂਟੇਨੈਂਸ ਅਤੇ ਸਪੋਰਟ ਦੀ ਯੋਜਨਾ।
“ਤਕਨੀਕੀ ਕਰਜ਼ਾ” ਇਸ ਲਈ ਉਪਯੋਗੀ ਹੈ ਕਿਉਂਕਿ ਇਹ ਇੰਜੀਨੀਅਰਿੰਗ ਛੋਟਾਂ ਨੂੰ ਗੈਰ-ਟੈਕਨੀਕੀ ਟੀਮਾਂ ਲਈ ਸਮਝਾਉਂਦਾ ਹੈ: ਇਹ ਇਕ ਲੋਨ ਲੈਣ ਵਰਗਾ ਹੈ। ਤੁਸੀਂ ਹੁਣ ਕੁਝ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹੋ (ਤੇਜ਼ੀ), ਪਰ ਬਾਅਦ ਵਿੱਚ ਸੁਧਾਰ ਦੀ ਕੀਮਤ ਦਿੰਦੇ ਹੋ (ਵੱਧ ਸਮਾਂ, ਬੱਗ, ਹੌਲੀ ਬਦਲਾਅ)। ਕੁੰਜੀ ਇਹ ਨਹੀਂ ਕਿ ਸਾਰਾ ਕਰਜ਼ਾ ਬਚਿਆ ਜਾਵੇ—ਇਹ ਹੈ ਉਦੇਸ਼ਿਤ ਤਰੀਕੇ ਨਾਲ ਕਰਜ਼ਾ ਲੈਣਾ।
ਸਿਹਤਮੰਦ ਕਰਜ਼ਾ ਇਰਾਦੇ ਨਾਲ ਲਿਆ ਜਾਂਦਾ ਹੈ। ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਸਿੱਖਣ, ਡੈੱਡਲਾਈਨ ਮਾਰਨ, ਜਾਂ ਮੰਗ ਨੂੰ ਵੈਰੀਫਾਈ ਕਰਨ ਲਈ ਇੱਕ ਸਧਾਰਨ ਤਰੀਕਾ ਚੁਣਦੇ ਹੋ—ਅਤੇ ਤੁਸੀਂ ਟਰੇਡ-ਆਫ ਨੂੰ ਸਮਝਦੇ ਹੋ ਅਤੇ ਇਸ ਨੂੰ ਦੁਬਾਰਾ ਕਰਨ ਦੀ ਯੋਜਨਾ ਬਣਾਉਂਦੇ ਹੋ।
ਅਨਹੈਲਥੀ ਕਰਜ਼ਾ ਅਕਸਮਾਤ ਬਣਦਾ ਹੈ। ਇਹ ਉਸ ਵੇਲੇ ਹੁੰਦਾ ਹੈ ਜਦੋਂ “ਅਸਥਾਈ” ਹੈਕ ਇਕੱਠੇ ਹੋ ਜਾਂਦੇ ਹਨ ਅਤੇ ਕਿਸੇ ਨੂੰ ਯਾਦ ਹੀ ਨਹੀਂ ਰਹਿੰਦਾ ਕਿ ਉਹ ਕਿਉਂ ਕੀਤੇ ਗਏ ਸਨ। ਫਿਰ ਬਿਆਜ ਤੇਜ਼ੀ ਨਾਲ ਵੱਧ ਜਾਂਦਾ ਹੈ: ਰਿਲੀਜ਼ ਦਰ ਦੁਸ਼ਵਾਰ ਹੋ ਜਾਂਦੀ ਹੈ, ਓਨਬੋਰਡਿੰਗ ਲੰਬੀ ਹੋ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਹਰ ਤਬਦੀਲੀ ਨੂੰ ਡਰ ਹੁੰਦਾ ਹੈ ਕਿ ਕੁਝ ਹੋਰ ਟੁੱਟ ਜਾਏ।
ਜ਼ਿਆਦਾਤਰ ਕਰਜ਼ਾ ਕਿਸੇ ਇੱਕ ਵੱਡੇ ਆਰਕੀਟੈਕਚਰਿਕ ਫੈਸਲੇ ਤੋਂ ਨਹੀਂ ਆਉਂਦਾ। ਇਹ ਹਰ ਰੋਜ਼ ਦੀਆਂ ਛੋਟੀਆਂ ਛੇਡਾਂ ਤੋਂ ਆਉਂਦਾ ਹੈ, ਜਿਵੇਂ:
ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਨੈਤਿਕ ਅਸਫਲਤਾ ਨਹੀਂ—ਇਹ ਅਕਸਰ ਮੋਮੈਂਟ ਵਿੱਚ ਤਰਕਸੰਗਤ ਹੁੰਦੇ ਹਨ। ਪਰ ਜੇ ਛੱਡ ਦਿੱਤੇ ਜਾਣ, ਤਾਂ ਇਹ ਮਹਿੰਗੇ ਹੋ ਜਾਂਦੇ ਹਨ।
ਜੇ ਤੁਸੀਂ ਕਰਜ਼ਾ ਲੈਂਦੇ ਹੋ, ਤਾਂ ਉਸਨੂੰ ਦਿੱਖਯੋਗ ਅਤੇ ਸਮੇਂ-ਬੱਧ ਬਣਾਓ:
ਤਕਨੀਕੀ ਕਰਜ਼ੇ ਨੂੰ ਕਿਸੇ ਹੋਰ ਰੋਡਮੈਪ ਖ਼ਰਚ ਵਾਂਗੋਂ ਸਾਡੇਖੋ: ਕਿਸੇ ਸਮੇਂ ਵਿੱਚ ਕਾਬੂ 'ਚ ਹੋਣ 'ਤੇ ਮਨਜ਼ੂਰ, ਅਣਦੇਖਾ ਕਰਨ 'ਤੇ ਖ਼ਤਰਨਾਕ।
“ਪਰਯਾਪਤ ਚੰਗਾ” ਉਹ ਤੱਕ ਹੀ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਤੁਹਾਡੀ ਐਪ ਉਹਨਾਂ ਖੇਤਰਾਂ ਨੂੰ ਛੂੰਹਦੀ ਨਹੀਂ ਜਿੱਥੇ ਇੱਕ ਛੋਟਾ ਨੁਕਸਾਨ ਬਹੁਤ ਵੱਡਾ ਨੁਕਸਾਨ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ। ਓਹਨਾਂ ਜ਼ੋਨਾਂ ਵਿਚ, ਤੁਸੀਂ ਸ਼ਾਨ ਲਈ ਪਾਲਿਸ਼ ਨਹੀਂ ਕਰ ਰਹੇ—ਤੁਸੀਂ ਘਟਨਾ ਰੋਕ ਰਹੇ ਹੋ, ਗਾਹਕਾਂ ਦੀ ਹਿਫਾਜ਼ਤ ਕਰ ਰਹੇ ਹੋ, ਅਤੇ ਭਰੋਸਾ ਬਚਾ ਰਹੇ ਹੋ।
ਕੁਝ ਭਾਗ ਹਨ ਜਿਨ੍ਹਾਂ 'ਤੇ “ਕਦੇ ਨਾ ਫੇਲ” ਵਾਂਗ ਵਰਤਣਾ ਚਾਹੀਦਾ ਹੈ:
ਇਨ੍ਹਾਂ ਖੇਤਰਾਂ ਵਿੱਚ “ਜ਼ਿਆਦਾ-ਆਮ ਤੌਰ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ” ਇੱਕ ਖਾਮੀ ਹੈ—ਇਹ ਇਕ ਲਾਇਬਿਲਟੀ ਹੋ ਸਕਦੀ ਹੈ।
ਗੋਪਨੀਯਤਾ ਅਤੇ ਭੁਗਤਾਨੀ ਫਲੋ ਅਕਸਰ ਕਾਨੂੰਨੀ ਜ਼ਿੰਮੇਵਾਰੀਆਂ, ਆਡੀਟ ਉਮੀਦਾਂ, ਅਤੇ ਠੇਕੇਦਾਰੀ ਵਚਨਾਂ ਨਾਲ ਜੁੜੇ ਹੁੰਦੇ ਹਨ। ਸਭ ਤੋਂ ਵੱਡੀ ਗੱਲ, ਉਪਭੋਗਤਿਆਂ ਦੀ ਯਾਦਦਾਸ਼ਤ ਲੰਮੀ ਹੁੰਦੀ ਹੈ: ਇੱਕ breach, ਇੱਕ ਗੈਰ-ਅਧਿਕ੍ਰਿਤ ਚਾਰਜ, ਜਾਂ ਇੱਕ ਲੀਕ ਹੋਇਆ ਦਸਤਾਵੇਜ਼ ਸਾਲਾਂ ਦੀ ਚੰਗੀ ਇਮੇਜ ਨੂੰ ਵਾਪਸ ਨਹੀਂ ਲਿਆ ਸਕਦਾ।
ਕੁਝ ਹਕੀਕਤੀ ਸੰਦਰਭ ਜਿੱਥੇ ਇੱਕ ਨਿੱਕਾ ਬੱਗ ਵੱਡਾ ਨੁਕਸਾਨ ਕਰ ਸਕਦਾ ਹੈ:
ਅ決ਰਨ ਕਰਦੇ ਸਮੇਂ ਕਿ ਕਿਸ ਹਿੱਸੇ ਨੂੰ "ਨਿਰੀਖਣਯੋਗ" ਗੁਣਵੱਤਾ ਚਾਹੀਦੀ ਹੈ, ਤੇਜ਼ੀ ਨਾਲ ਸਕੋਰ ਕਰੋ:
ਖਤਰਾ ਸਕੋਰ = ਪ੍ਰਭਾਵ × ਸੰਭਾਵਨਾ × ਪਛਾਣਯੋਗਤਾ
ਉਚੀ ਪ੍ਰਭਾਵ + ਘੱਟ ਪਛਾਣਯੋਗਤਾ ਤੁਹਾਨੂੰ ਵਧੇਰੇ ਕਠੋਰ ਰੀਵਿਊ, ਟੈਸਟਿੰਗ, ਮਾਨੀਟਰਿੰਗ ਅਤੇ ਸੇਫਰ ਡਿਜ਼ਾਈਨ ਵਿੱਚ ਨਿਵੇਸ਼ ਕਰਨ ਦਾ ਸੰਕੇਤ ਦਿੰਦੀ ਹੈ।
ਹਰ ਹਿੱਸੇ ਲਈ ਇੱਕੋ ਜਿਹੀ ਮੇਹਨਤ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ। ਗੁਣਵੱਤਾ ਦੀ ਝੰਡੀ ਖਤਰੇ ਦੇ ਆਧਾਰ 'ਤੇ ਰੱਖੋ: ਉਪਭੋਗਤਾ ਨੂੰ ਨੁਕਸਾਨ, ਆਮਦਨੀ ਪ੍ਰਭਾਵ, ਸੁਰੱਖਿਆ ਖ਼ਤਰਾ, ਕਾਨੂੰਨੀ ਜ਼ਿੰਮੇਵਾਰੀ, ਅਤੇ ਸਪੋਰਟ ਖਰਚ।
ਹਰ ਫੀਚਰ ਨੂੰ ਇੱਕ ਗੁਣਵੱਤਾ ਟੀਅਰ ਵਿੱਚ ਟੈਗ ਕਰੋ:
ਫੇਰ ਉਮੀਦਾਂ ਨੂੰ ਮਿਲਾਓ: Tier 1 ਨੂੰ ਸੰਭਲ ਕੇ ਡਿਜ਼ਾਈਨ, ਧਿਆਨਪੂਰਣ ਕੋਡ ਰਿਵਿਊ ਅਤੇ ਮਜ਼ਬੂਤ ਮਾਨੀਟਰਿੰਗ ਮਿਲਦੀ ਹੈ। Tier 3 ਨੂੰ ਜਾਣਿਆ ਗਿਆ ਕੱਚਪਨ ਹੋ ਸਕਦਾ ਹੈ—ਜੌਂਦੋ ਇੱਕ ਯੋਜਨਾ ਅਤੇ ਮਾਲਕ ਹੋਵੇ।
ਲੌਗਇਨ / authentication (Tier 1): ਇੱਕ ਲੌਗਇਨ ਬੱਗ ਸਾਰੇ ਉਪਭੋਗਤਿਆਂ ਨੂੰ ਬਲਾਕ ਕਰ ਸਕਦਾ ਹੈ; ਸੁਰੱਖਿਆ ਗਲਤੀਆਂ ਭਿਆਨਕ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਸਾਫ ਫਲੋ, rate limiting, ਸੁਰੱਖਿਅਤ password reset, ਅਤੇ ਵਧੀਆ ਐਰਰ ਹੈਂਡਲਿੰਗ ਵਿੱਚ ਨਿਵੇਸ਼ ਕਰੋ।
ਬਿਲਿੰਗ ਅਤੇ सबਸਕ੍ਰਿਪਸ਼ਨ (Tier 1): ਗਲਤ ਬਿਲਿੰਗ ਰਿਫੰਡ, churn, ਅਤੇ ਗੁੱਸੇਲੇ ਈਮੇਲ ਬਣਾਂਦੀ ਹੈ। idempotent payments, audit trails, ਅਤੇ 문제 reconciliation ਦਾ ਇਕ ਭਰੋਸੇਯੋਗ ਤਰੀਕਾ ਬਣਾਓ।
ਡੇਟਾ ਨਿਰਯਾਤ (Tier 1 ਜਾਂ Tier 2): ਨਿਰਯਾਤ compliance ਜਾਂ trust ਨਾਲ ਜੁੜ ਸਕਦੀ ਹੈ। ਭਾਵੇਂ “ਸਿਰਫ CSV” ਹੋਵੇ, ਗਲਤ ਡੇਟਾ ਅਸਲ ਕਾਰੋਬਾਰੀ ਨੁਕਸਾਨ ਪੈਦਾ ਕਰ ਸਕਦੀ ਹੈ।
ਅੰਦਰੂਨੀ ਐਡਮਿਨ ਪੰਨੇ (Tier 3): ਜੇ صرف ਤੁਹਾਡੀ ਟੀਮ ਹੀ ਇਸਨੂੰ ਵਰਤਦੀ ਹੈ, ਤਾਂ clunkier UI ਅਤੇ ਘੱਟ ਰੀਫੈਕਟਰਿੰਗ ਸਵੀਕਾਰ ਕਰੋ। ਮੀਟ੍ਰਿਕ ਇਹ ਹੈ: “ਕੰਮ ਕਰਦਾ ਹੈ, ਡੇਟਾ ਖਰਾਬ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਠੀਕ ਕਰਨ ਵਿੱਚ ਆਸਾਨ ਹੈ।”
ਟੈਸਟਿੰਗ ਨੂੰ ਉਹੀ ਤਰ੍ਹਾਂ ਪਰਤਾਂ ਵਿੱਚ ਰੱਖੋ:
ਪਾਲਿਸ਼ ਕੈਲੰਡਰ ਨੂੰ ਭਰ ਦਿੰਦੀ ਹੈ। ਇਸ 'ਤੇ ਕਠੋਰ ਸੀਮਾ ਰੱਖੋ: ਉਦਾਹਰਨ ਵਜੋਂ, “ਬਿਲਿੰਗ ਐਰਰ ਸੁਨੇਹਿਆਂ ਨੂੰ ਸੁਧਾਰਨ ਅਤੇ reconciliation logs ਜੋੜਨ ਲਈ ਦੋ ਦਿਨ,” ਫਿਰ ਸ਼ਿਪ ਕਰੋ। ਜੇ ਹੋਰ ਸੁਧਾਰ ਰਹਿ ਜਾਂਦੇ ਹਨ, ਉਨ੍ਹਾਂ ਨੂੰ ਮੈਟਰਿਕਸ-ਨਿਰਧਾਰਤ ਖਤਰੇ (refund ਦਰ, ਸਪੋਰਟ ਟਿਕਟ) ਨਾਲ ਜੁੜੇ ਸਕੋਪਡ follow-ups ਵਿੱਚ ਰੱਖੋ ਨਾ ਕਿ ਨਿੱਜੀ ਮਿਆਰਾਂ 'ਤੇ।
ਓਵਰਇੰਜੀਨੀਅਰਿੰਗ ਬਹੁਤ ਹੀ ਸ਼ੋਰ ਨਾ ਕਰਕੇ ਫੇਲ ਹੁੰਦੀ ਹੈ। ਇਹ ਚੁਪਕੇ ਫੇਲ ਹੁੰਦੀ ਹੈ—ਸਭ ਕੁਝ ਲੰਮਾ ਕਰਕੇ। ਤੁਸੀਂ ਇਹ ਇਕ ਸਿੰਗਲ ਸਪ੍ਰਿੰਟ 'ਚ ਨੋਟਿਸ ਨਹੀਂ ਕਰਦੇ; ਤੁਸੀਂ ਮਹੀਨਿਆਂ ਬਾਅਦ ਨੋਟਿਸ ਕਰਦੇ ਹੋ ਜਦੋਂ “ਛੋਟੇ ਬਦਲਾਅ” ਲਈ ਮੀਟਿੰਗਾਂ, ਡਿਆਗ੍ਰਾਮ, ਅਤੇ ਇਕ ਹਫ਼ਤੇ ਦੀ ਰਿਗ੍ਰੈਸ਼ਨ ਟੈਸਟਿੰਗ ਦੀ ਲੋੜ ਪੈਂਦੀ ਹੈ।
ਇੱਕ ਬਹੁਤ ਇੰਜੀਨੀਅਰ ਕੀਤਾ ਸਿਸਟਮ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਅਕਸਰ ਵਿਆਜ ਲਗਾਉਂਦਾ ਹੈ:
ਇਹ ਤੁਸੀਂ ਬਜਟ 'ਤੇ ਨੋਟਿਸ ਨਹੀਂ ਕਰਦੇ, ਪਰ ਇਹ ਮੌਕੇ ਅਤੇ ਅਨੁਕੂਲਤਾ ਨੂੰ ਘਟਾ ਦਿੰਦੇ ਹਨ।
ਕੁਝ ਐਪਾਂ ਸੱਚਮੁਚ ਪਹਿਲਾਂ ਤੋਂ ਵੱਧ ਇੰਜੀਨੀਅਰਿੰਗ ਦੀ ਲੋੜ ਰੱਖਦੀਆਂ ਹਨ। ਜੱਟਿਲਤਾ ਅਮੂਮਨ ਵਾਜ਼ਿਬ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ ਸਪੱਸ਼ਟ, ਮੌਜੂਦਾ ਮੰਗ ਹੈ ਜਿਵੇਂ:
ਜੇ ਇਹ ਲੋੜਾਂ ਮੌਜੂਦ ਨਹੀਂ ਹਨ, ਤਾਂ "ਜਸਟ ਇਨ ਕੇਸ" ਲਈ ਬਣਾਉਣਾ ਮਹਿੰਗਾ ਅਨੁਮਾਨ ਹੈ।
ਜਟਿਲਤਾ ਨੂੰ ਪੈਸੇ ਵਾਂਗ ਲਓ: ਤੁਸੀਂ ਇਸਨੂੰ ਖਰਚ ਕਰ ਸਕਦੇ ਹੋ, ਪਰ ਤੁਹਾਨੂੰ ਇਸ ਦਾ ਟ੍ਰੈਕ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ।
ਨਵੀਂ ਜਾਂ ਜਟਿਲ ਚੀਜ਼ਾਂ ਦੀ ਇੱਕ ਕਮਜ਼ੋਰ ਲੌਗ ਰੱਖੋ (ਨਵੀਂ ਸਰਵਿਸ, ਨਵਾਂ ਫਰੇਮਵਰਕ, ਨਵਾਂ ਅਬਸਟ੍ਰੈਕਸ਼ਨ) ਦੇ ਨਾਲ (1) ਇਹ ਹੁਣ ਕਿਉਂ ਜ਼ਰੂਰੀ ਹੈ, (2) ਇਹ ਕੀ ਬਦਲਦਾ ਹੈ, ਅਤੇ (3) ਸਮੀਖਿਆ ਦੀ ਮਿਤੀ। ਜੇ ਸਮੀਖਿਆ ਤੱਕ ਇਹ ਲਾਭਦਾਇਕ ਨਹੀਂ ਸਾਬਤ ਹੁੰਦੀ, ਤਾਂ ਸਗਲ ਕਰੋ।
ਕੋਡ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਪਹਿਲਾਂ ਸਧਾਰੋ—ਕੱਟੋ।
ਕਦੇ-ਕਦੇ ਸਭ ਤੋਂ ਤੇਜ਼ ਕਾਰਗੁਜ਼ਾਰੀ ਸੁਧਾਰ ਇੱਕ ਛੋਟਾ ਰਸਤਾ ਬਣਾਉਣਾ ਹੈ। ਘੱਟ ਫੀਚਰ ਇੱਕ ਛੋਟੀ ਉਤਪਾਦ ਬਣਾਉਂਦੇ ਹਨ ਜੋ ਇੰਜੀਨੀਅਰਿੰਗ ਡੀਮਾਂਡ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ—ਅਤੇ “ਪਰਯਾਪਤ” ਨੂੰ ਪਹੁੰਚ ਅਤੇ ਬਣਾਏ ਰੱਖਣਾ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ।
ਜਦ ਲੋਕ ਕਹਿੰਦੇ ਹਨ ਕਿ ਇੱਕ ਐਪ “ਉੱਚ ਗੁਣਵੱਤਾ ਵਾਲੀ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ,” ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਸਧਾਰਨ ਗੱਲ ਮਤਲਬ ਲੈਂਦੇ ਹਨ: ਇਸ ਨੇ ਉਹਨਾਂ ਨੂੰ ਬਿਨਾਂ ਜ਼ਿਆਦਾ ਸੋਚੇ-ਸਮਝੇ ਇੱਕ ਲਕਸ਼ ਪ੍ਰਾਪਤ ਕਰਵਾਇਆ। ਉਪਭੋਗਤਾ ਕੁਝ ਰੁਕਾਵਟਾਂ ਨੂੰ ਸਹਿਣ ਕਰ ਲੈਂਦੇ ਹਨ ਜੇ ਮੁੱਖ ਕੰਮ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਉਹ ਭਰੋਸਾ ਕਰਦੇ ਹਨ ਕਿ ਉਹ ਕੰਮ ਖੋਣਗੇ ਨਹੀਂ।
ਛੋਟੀਆਂ ਖਾਮੀਆਂ ਮਨਜ਼ੂਰ ਹਨ ਜਦੋਂ ਐਪ ਭਵਿਖਬਾਣੀ ਯੋਗ ਹੋਵੇ। ਗਲਤ ਲੇਬਲ, ਅਚਾਨਕ ਵਰਤਾਰ, ਜਾਂ ਡੇਟਾ ਨੂੰ "ਖਾ ਜਾਣ ਵਾਲੇ" ਜਿਹੇ ਐਰਰ ਉਪਭੋਗਤਾ ਮਾਫ਼ ਨਹੀਂ ਕਰਦੇ।
ਇੱਕ ਪ੍ਰਯੋਗਾਤਮਕ ਟਰੇਡ-ਆਫ: ਐਰਰ ਸੁਨੇਹਿਆਂ ਨੂੰ ਸੁਧਾਰਨਾ ਅਕਸਰ ਇੱਕ fancy ਰੀਫੈਕਟਰ ਤੋਂ ਵਧੀਆ ਨਤੀਜੇ ਦਿੰਦਾ ਹੈ।
ਦੂਜੇ ਸੁਨੇਹੇ ਨਾਲ ਸਪੋਰਟ ਟਿਕਟਾਂ ਘੱਟ ਹੋ ਸਕਦੀਆਂ ਹਨ, ਟਾਸਕ ਪੂਰਾ ਹੋਣ ਦੀ ਦਰ ਵੱਧ ਸਕਦੀ ਹੈ, ਅਤੇ ਭਰੋਸਾ ਬਣ ਸਕਦਾ ਹੈ—ਚਾਹੇ ਅੰਦਰੂਨੀ ਕੋਡ ਸੁੰਦਰ ਨਾ ਹੋਵੇ।
ਪ੍ਰਤੀਤ ਗੁਣਵੱਤਾ ਸਿਰਫ UI 'ਚ ਨਹੀਂ ਹੁੰਦੀ। ਇਹ ਇਸ ਗੱਲ ਵਿੱਚ ਵੀ ਹੈ ਕਿ ਕੋਈ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਕਾਮਯਾਬ ਹੁੰਦਾ ਹੈ। ਚੰਗੀ ਓਨਬੋਰਡਿੰਗ ਅਤੇ ਦਸਤਾਵੇਜ਼ੀਕਰਨ "ਨਾਈਸ-ਟੂ-ਹੈਵ" ਫੀਚਰ ਦੀ ਕਮੀ ਨੂੰ ਕਵਰ ਕਰ ਸਕਦੇ ਹਨ:
ਹਾਲਾਂਕਿ ਇੱਕ ਹਲਕਾ-ਫੁਲਕਾ help center ਜੋ ਐਪ ਦੇ ਅੰਦਰ ਲਿੰਕ ਕੀਤਾ ਹੋਵੇ, ਅਨੁਭਵ ਨੂੰ ਪਰਿਪੱਕ ਕਰ ਸਕਦਾ ਹੈ।
ਤੁਹਾਨੂੰ ਭਰੋਸੇਯੋਗ ਮਹਿਸੂਸ ਕਰਨ ਲਈ ਪੂਰੀ ਇੰਜੀਨੀਅਰਿੰਗ ਦੀ ਲੋੜ ਨਹੀਂ, ਪਰ ਤੁਹਾਨੂੰ ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ ਦੀ ਲੋੜ ਹੈ:
ਇਹ ਕੇਵਲ ਆਫਤਾਂ ਨੂੰ ਰੋਕਦੇ ਨਹੀਂ; ਇਹ ਪਰਿਪਕਵਤਾ ਦਾ ਸੰਕੇਤ ਵੀ ਦੇਂਦੇ ਹਨ।
“ਪਰਯਾਪਤ” ਇੱਕ ਹਿਲਦਾ ਟਾਰਗੇਟ ਹੈ। ਉਹ ਛੋਟੀਆਂ shortcuts ਜੋ ਸ਼ੁਰੂ ਵਿੱਚ ਠੀਕ ਸਨ, ਉਹ ਗਾਹਕਾਂ ਦੇ ਦਿਨ-ਰੋਜ਼ੀ ਬਰਤਾਉ ਵਿੱਚ ਦਰਦ ਬਣ ਸਕਦੇ ਹਨ। ਲਕਸ਼ ਪਰਫੈਕਸ਼ਨ ਨਹੀਂ—ਇਹ ਨਿਸ਼ਾਨੀ ਦੇਖਣਾ ਹੈ ਜਦੋਂ "ਪਰਯਾਪਤ" ਰਹਿਣ ਦਾ ਖ਼ਰਚ ਵਧ ਰਿਹਾ ਹੈ।
ਤੁਹਾਨੂੰ ਡੈਸ਼ਬੋਰਡ ਦੀ ਲੋੜ ਨਹੀਂ। ਕੁਝ ਨੰਬਰ, ਲਗਾਤਾਰ ਟਰੈਕ ਕੀਤੇ ਜਾਣ, ਤੁਹਾਨੂੰ ਦੱਸ ਸਕਦੇ ਹਨ ਕਿ ਗੁਣਵੱਤਾ ਵਧਾਉਣੀ ਚਾਹੀਦੀ ਹੈ:
ਜੇ ਇਹ ਕੇਹੜੇ ਹਫ਼ਤਿਆਂ ਲਈ ਗਲਤ ਰੁਝਾਨ ਦਿਖਾਉਂਦੇ ਹਨ, ਤਾਂ “ਪਰਯਾਪਤ” ਦੀ ਮਿਆਦ ਖਤਮ ਹੋ ਗਈ ਹੈ।
ਇਕ ਪ੍ਰਯੋਗਾਤਮਕ ਆਦਤ: ਜਦ ਤੁਸੀਂ ਕਿਸੇ ਖੇਤਰ ਨੂੰ ਛੇਡੋ, ਉੱਥੇ ਹੀ ਥੋੜ੍ਹਾ refactor ਕਰੋ। ਜਦ ਤੁਸੀਂ ਕਿਸੇ ਫੀਚਰ 'ਤੇ ਕੰਮ ਕਰਦੇ ਹੋ, ਓਥੇ ਇੱਕ ਨਿਰੀਯਤ ਸਮਾਂ ਦਿਓ ਕਿ ਇਸ ਖੇਤਰ ਨੂੰ ਸਮਝਣ ਯੋਗ ਅਤੇ ਬਦਲਣ ਲਈ ਸੁਰੱਖਿਅਤ ਬਣਾਇਆ ਜਾਵੇ—ਫੰਕਸ਼ਨਾਂ ਦਾ ਨਾਮ ਬਦਲੋ, ਇੱਕ ਘੱਟ ਟੈਸਟ ਜੋੜੋ, ਇੱਕ ਕੰਡੀਸ਼ਨ ਨੂੰ ਸੁਧਾਰੋ, ਮਰੇ ਹੋਏ ਕੋਡ ਨੂੰ ਹਟਾਓ। ਇਹ ਸੁਧਾਰ ਅਸਲੀ ਕੰਮ ਨਾਲ ਜੁੜੇ ਰਹਿੰਦੇ ਹਨ ਅਤੇ ਲੰਬੇ ਕਲੀਨਅਪ ਪ੍ਰੋਜੈਕਟਾਂ ਤੋਂ ਬਚਾਉਂਦੇ ਹਨ।
ਹਰ ਮਹੀਨੇ ਇੱਕ ਛੋਟੀ ਮੇਂਟੇਨੈਂਸ ਬਲਾਕ ਰੱਖੋ (ਆਧਾ ਦਿਨ ਤੋਂ ਦੋ ਦਿਨ):
ਇਸ ਨਾਲ ਗੁਣਵੱਤਾ ਅਸਲ ਖਤਰੇ ਅਤੇ ਉਪਭੋਗਤਾ ਪ੍ਰਭਾਵ ਨਾਲ سیدੀ ਰਹਿੰਦੀ ਹੈ—ਬਿਨਾਂ ਇਸ ਦੇ ਕਿ ਸਿਰਫ਼ ਨਿੱਜੀ ਮਿਆਰ ਲਈ ਪਾਲਿਸ਼ ਕੀਤੀ ਜਾਵੇ।
ਸ਼ਿਪਿੰਗ ਬਨਾਮ ਪਾਲਿਸ਼ ਇਕ ਨੈਤਿਕ ਬਹਿਸ ਨਹੀਂ—ਇਹ ਪ੍ਰਾਥਮਿਕਤਾ ਹੈ। ਲਕਸ਼ ਤੇਜ਼ੀ ਨਾਲ ਉਪਭੋਗਤਾ ਮੁੱਲ ਪਹੁੰਚਾਉਣਾ ਹੈ ਜਦੋਂ ਕਿ ਭਰੋਸਾ ਰੱਖੋ ਅਤੇ ਭਵਿੱਖ ਦੇ ਕੰਮ ਨੂੰ ਸਸਤਾ ਰੱਖੋ।
ਇੱਕ ਸੰਤੁਲਿਤ ਨਿਸ਼ਕਰਸ਼: ਜਦ ਖਤਰੇ ਕਾਬੂ 'ਚ ਹੋਣ, ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰੋ; ਜਿੱਥੇ ਫੇਲ ਮਹਿੰਗਾ ਹੋ ਸਕਦਾ ਹੈ ਉਥੇ ਭਰੋਸਾ ਰੱਖੋ; ਅਤੇ ਨਿਰੰਤਰ ਸੁਧਾਰ ਕਰੋ ਜਦੋਂ ਅਸਲੀ ਵਰਤੋਂ ਦੱਸਦੀ ਹੈ ਕਿ ਕੀ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ।
“ਪੂਰੀ ਇੰਜੀਨੀਅਰਿੰਗ” ਅੰਦਰੂਨੀ ਗੁਣਵੱਤਾਵਾਂ ਨੂੰ ਓਪਟੀਮਾਈਜ਼ ਕਰਦੀ ਹੈ—ਜਿਵੇਂ ਆਰਕੀਟੈਕਚਰ ਦੀ ਪਵਿੱਤਰਤਾ, ਵੱਧ ਤੋਂ ਵੱਧ ਲਚਕੀਲਾਪਨ, ਵਿਸਤ੍ਰਿਤ ਟੈਸਟ ਕਵਰੇਜ, ਅਤੇ ਭਵਿੱਖੀ ਦ੍ਰਿਸ਼ਟਾਂਤਾਂ ਲਈ ਤਿਆਰ ਕਰਨਾ।
“ਉਪਯੋਗੀ ਸੌਫਟਵੇਅਰ” ਉਪਭੋਗਤਾ ਦੇ ਨਤੀਜਿਆਂ ਨੂੰ ਓਪਟੀਮਾਈਜ਼ ਕਰਦਾ ਹੈ: ਇਹ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਕੋਈ ਅਸਲ ਕੰਮ ਮੁਕੰਮਲ ਕਰਵਾਂਦਾ ਹੈ ਘੱਟ ਘਰਲੂ ਰੁਕਾਵਟ ਦੇ ਨਾਲ। ਜੇ ਇਹ ਤੇਜ਼, ਸਪੱਸ਼ਟ ਅਤੇ ਭਰੋਸੇਯੋਗ (ਡੇਟਾ ਘਾਟ, ਸੁਰੱਖਿਆ ਦੀਆਂ ਨਾਕਾਮੀਆਂ ਨਹੀਂ) ਹੈ, ਤਾਂ ਉਪਭੋਗਤਾ ਇਸਨੂੰ ਰੱਖ ਲੈਂਦੇ ਹਨ—ਚਾਹੇ ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ ਕੋਡ ਸੁੰਦਰ ਨਾ ਹੋਵੇ।
ਅਕਸਰ ਉਪਭੋਗਤਾ ਨੋਟਿਸ ਕਰਦੇ ਹਨ:
ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਤੁਹਾਡੀ ਆਰਕੀਟੈਕਚਰ, ਫਰੇਮਵਰਕ ਚੋਣਾਂ ਜਾਂ ਐਬਸਟਰੈਕਸ਼ਨ ਗੁਣਵੱਤਾ ਦੀ ਚਿੰਤਾ ਨਹੀਂ ਕਰਦੇ, ਜਦ ਤਕ ਇਹ ਸਿੱਧਾ ਤਜਰਬੇ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਨਾ ਕਰੇ।
ਕਾਰਨ ਇਹ ਹੈ ਕਿ ਸ਼ੁਰੂ ਵਿੱਚ ਤੁਸੀਂ ਨਹੀਂ ਜਾਣਦੇ ਕਿ ਕਿਹੜੇ ਫੀਚਰ, ਵਰਕਫਲੋਜ਼ ਜਾਂ ਐਜ ਕੇਸ ਮਹੱਤਵਪੂਰਨ ਹੋਣਗੇ।
ਜੇ ਤੁਸੀਂ ਗਲਤ ਚੀਜ਼ ਨੂੰ “ਪੂਰਾ” ਕਰ ਲੈਂਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਉਸ ਓਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਦੀ ਕੀਮਤ ਅਦਾ ਕਰਦੇ ਹੋ ਬਿਨਾਂ ਕਿਸੇ ਉਪਭੋਗਤਾ ਮੁੱਲ ਦੇ। ਛੋਟਾ ਕੁਝ ਰਿਲੀਜ਼ ਕਰਨ ਨਾਲ ਇੱਕ ਫੀਡਬੈਕ ਲੂਪ ਬਣਦਾ ਹੈ ਜੋ ਅਨੁਮਾਨ ਨੂੰ ਸਬੂਤ ਵਿਚ ਬਦਲਦਾ ਹੈ, ਤਾਂ ਜੋ ਤੁਸੀਂ ਉਹੀ ਇੰਜੀਨੀਅਰਿੰਗ ਸਮਾਂ ਖਰਚ ਕਰੋ ਜਿੱਥੇ ਅਸਲੀ ਫਾਇਦਾ ਹੋਵੇ।
ਇਸਨੂੰ ਇੱਕ ਸਕੇਟਰ ਵਜੋਂ ਦੇਖੋ:
ਸਰਲ ਟੈਸਟ: ਜੇ ਬਦਲਣਾ ਬਾਅਦ ਵਿੱਚ ਖਤਰਨਾਕ ਮਾਈਗਰੈਸ਼ਨ, ਕਾਨੂੰਨੀ ਖ਼ਤਰੇ ਜਾਂ ਗਾਹਕ ਪ੍ਰਭਾਵ ਵਾਲਾ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਬੇਧਿਆਨ ਤਰੀਕੇ ਨਾਲ MVP ਨਾ ਬਣਾਓ।
ਇੱਕ MVP ਇੱਕ ਸਿੱਖਣ ਵਾਲਾ ਸੰਦ ਹੈ: ਸਭ ਤੋਂ ਛੋਟੀ ਰਿਲੀਜ਼ ਜੋ ਉਪਭੋਗਤਾ ਮੁੱਲ ਬਾਰੇ ਵਾਸਤਵਿਕ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇ ਸਕੇ।
ਇਹ “ਸਸਤਾ ਅਤੇ ਲੱਛਣਹੀਨ” ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ। ਜਦ ਵੀ ਅਸਲੀ ਗਾਹਕ ਇਸ 'ਤੇ ਨਿਰਭਰ ਹੋਣ, ਇਸਨੂੰ ਪ੍ਰੋਡਕਸ਼ਨ ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ: ਭਰੋਸੇਯੋਗ ਵਿਵਹਾਰ, ਸਪੱਸ਼ਟ ਹੱਦਾਂ, ਅਤੇ ਕੋਈ ਸਮੱਸਿਆ ਆਉਣ 'ਤੇ ਸਹਾਇਤਾ ਦਾ ਰਸਤਾ।
ਦਿਸ਼ਾ-ਨਿਰਦੇਸ਼:
ਤਕਨੀਕੀ ਕਰਜ਼ਾ ਇੱਕ ਲੋਨ ਵਾਂਗ ਹੈ: ਹੁਣ ਤੁਹਾਨੂੰ ਫਾਇਦਾ ਮਿਲਦਾ ਹੈ (ਤੇਜ਼ੀ), ਪਰ ਬਾਅਦ ਵਿੱਚ ਬਿਆਜ ਚੁੱਕਣਾ ਪੈਂਦਾ ਹੈ (ਜ਼ਿਆਦਾ ਸਮਾਂ, ਬੱਗ, ਹੌਲੀ ਤਬਦੀਲੀਆਂ)।
ਪ੍ਰਯੋਗਾਤਮਕ ਤਰੀਕਾ: ਜਦ ਤੁਸੀਂ ਕਰਜ਼ਾ ਲੈਂਦੇ ਹੋ ਤਾਂ ਉਸਨੂੰ ਟਿਕਟ ਵਿੱਚ ਦਰਜ ਕਰੋ—ਕੀ ਕੀਤਾ, ਕਿਉਂ ਕੀਤਾ, ਅਤੇ “ਚੁੱਕਤੀ” ਕਿਸ ਤਰ੍ਹਾਂ ਮੁਕੰਮਲ ਹੋਵੇਗੀ—ਫਿਰ ਹਰ ਸਾਈਕਲ ਵਿੱਚ ਕੁਝ ਸਮਰੱਥਾ ਰਾਖੋ ਤਾਂ ਕਿ ਉਸਨੂੰ ਅਦਾ ਕੀਤਾ ਜਾਏ।
ਕੁਝ ਖੇਤਰ ਅਸਲ ਵਿੱਚ ਘਰਿਆਲ ਨੁਕਸਾਨ ਕਰ ਸਕਦੇ ਹਨ—ਇਥੇ “ਲਗਭਗ ਕੰਮ ਕਰਦਾ ਹੈ” ਮਨਜ਼ੂਰ ਨਹੀਂ:
ਇਨ੍ਹਾਂ ਖੇਤਰਾਂ ਵਿੱਚ ਛੋਟਾ ਬੱਗ ਵੀ ਵੱਡਾ ਨੁਕਸਾਨ ਪਹੁੰਚਾ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਉੱਥੇ ਗੁਣਵੱਤਾ ਅਟੱਲ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।
ਇੱਕ ਸਧਾਰਣ ਖ਼ਤਰਾ ਟੈਸਟ: ਖਤਰਾ ਸਕੋਰ = ਪ੍ਰਭਾਵ × ਸੰਭਾਵਨਾ × ਪਛਾਣ ਯੋਗਤਾ
ਉੱਚ ਪ੍ਰਭਾਵ + ਘੱਟ ਪਛਾਣਯੋਗਤਾ ਤੁਹਾਨੂੰ ਵਧੇਰੇ ਕਠੋਰ ਰੀਵਿਊ, ਟੈਸਟਿੰਗ ਅਤੇ ਮਾਨੀਟਰਿੰਗ ਵਿਚ ਨਿਵੇਸ਼ ਕਰਨ ਦਾ ਸੰਕੇਤ ਦਿੰਦੀ ਹੈ।
ਓਵਰਇੰਜੀਨੀਅਰਿੰਗ ਅਕਸਰ ਚੁਪਕੇ ਨੁਕਸਾਨ ਪਹੁੰਚਾਂਦੀ ਹੈ: ਸਭ ਕੁਝ ਜ਼ਿਆਦਾ ਲੰਮਾ ਹੋ ਜਾਂਦਾ ਹੈ, ਨਵੀਆਂ ਭਰਤੀ ਚੀਜ਼ਾਂ ਸਿੱਖਣ ਵਿੱਚ ਮੁਿਮਕਿਨ ਹੋ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਛੋਟੀਆਂ ਤਬਦੀਲੀਆਂ ਅਣਅਪੇਖਿਤ ਪ੍ਰਭਾਵ ਪੈਦਾ ਕਰਨ ਲੱਗਦੀਆਂ ਹਨ।
ਜਦ complexity ਕਾਇਮ ਕਰਨ ਲਈ ਵਾਜ਼ਿਬ ਹੁੰਦੀ ਹੈ:
ਇਹਨਾਂ ਮਾਮਲਿਆਂ ਨੂੰ ਇਕ “complexity ਬਜਟ” ਦੇ ਤੌਰ ਤੇ ਮੈਨੇਜ ਕਰੋ: ਹਰ ਨਵੀਂ ਜਟਿਲਤਾ ਲਈ ਕਾਰਨ ਲਿਖੋ ਅਤੇ ਸਮੀਖਿਆ ਦੀ ਮਿਤੀ ਨਿਰਧਾਰਤ ਕਰੋ।
ਜਦ ਠੀਕਰਾ “ਪਰਯਾਪਤ” ਹੋ ਕੇ ਨਹੀਂ ਰਿਹਾ:
ਹੁਣੇ ਦੇ ਨਾਲ‑ਨਾਲ ਕਰਜ਼ਾ ਵਾਪਸ ਚੁੱਕੋ: ਕਿਸੇ ਫੀਚਰ ਨੂੰ ਛੇੜਦੇ ਸਮੇਂ ਥੋੜ੍ਹਾ ਸਮਾਂ ਰੀਫੈਕਟਰ ਕਰਨ ਲਈ ਰੱਖੋ—ਇਸ ਨਾਲ ਵੱਡੀ ਰੀਰਾਈਟ ਤੋਂ ਬਿਨਾਂ ਧੀਰੇ-ਧੀਰੇ ਸੁਧਾਰ ਹੋਣਗੇ।
