08 ਨਵੰ 2025·8 ਮਿੰਟ
ਛੋਟੀ ਟੀਮਾਂ AI ਨਾਲ ਵੱਡੀਆਂ ਇੰਜੀਨੀਅਰਿੰਗ ਆਰਗਜ਼ ਨਾਲੋਂ ਤੇਜ਼ ਕਿਵੇਂ ਸ਼ਿਪ ਕਰਦੀਆਂ ਹਨ
ਸਿੱਖੋ ਕਿ ਕਿਉਂ ਛੋਟੀ ਟੀਮਾਂ AI ਦੀ ਵਰਤੋਂ ਨਾਲ ਵੱਡੀਆਂ ਇੰਜੀਨੀਅਰਿੰਗ ਟੀਮਾਂ ਨਾਲੋਂ ਤੇਜ਼ਸ਼ਿਪ ਕਰਦੀਆਂ ਹਨ: ਘੱਟ ਓਵਰਹੈੱਡ, ਤੰਗ ਫੀਡਬੈਕ ਲੂਪ, ਸਮਾਰਟ ਆਟੋਮੇਸ਼ਨ, ਅਤੇ ਸਪਸ਼ਟ ਮਾਲਕੀ।
ਸਿੱਖੋ ਕਿ ਕਿਉਂ ਛੋਟੀ ਟੀਮਾਂ AI ਦੀ ਵਰਤੋਂ ਨਾਲ ਵੱਡੀਆਂ ਇੰਜੀਨੀਅਰਿੰਗ ਟੀਮਾਂ ਨਾਲੋਂ ਤੇਜ਼ਸ਼ਿਪ ਕਰਦੀਆਂ ਹਨ: ਘੱਟ ਓਵਰਹੈੱਡ, ਤੰਗ ਫੀਡਬੈਕ ਲੂਪ, ਸਮਾਰਟ ਆਟੋਮੇਸ਼ਨ, ਅਤੇ ਸਪਸ਼ਟ ਮਾਲਕੀ।
“ਸ਼ਿਪਿੰਗ ਤੇਜ਼” ਦਾ ਮਤਲਬ ਸਿਰਫ਼ ਤੇਜ਼ੀ ਨਾਲ ਕੋਡ ਟਾਈਪ ਕਰਨਾ ਨਹੀਂ ਹੈ। ਅਸਲ ਡਿਲਿਵਰੀ ਗਤੀ ਉਹ ਸਮਾਂ ਹੈ ਜੋ ਇੱਕ ਖਿਆਲ ਨੂੰ ਇੱਕ ਭਰੋਸੇਯੋਗ ਸੁਧਾਰ ਬਣਨ ਤੋਂ ਲੈ ਕੇ ਯੂਜ਼ਰਾਂ ਲਈ ਲਾਈਵ ਹੋਣ ਅਤੇ ਟੀਮ ਇਹ ਸਿੱਖਣ ਤੱਕ ਲੱਗਦਾ ਹੈ ਕਿ ਇਹ ਕੰਮ ਕੀਤਾ ਜਾਂ ਨਹੀਂ।
ਟੀਮਾਂ ਗਤੀ ਬਾਰੇ ਬਹਿਸ ਇਸ ਲਈ ਕਰਦੀਆਂ ਹਨ ਕਿ ਉਹ ਵੱਖ-ਵੱਖ ਚੀਜ਼ਾਂ ਮਾਪ ਰਹੀਆਂ ਹੁੰਦੀਆਂ ਹਨ। ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਦ੍ਰਿਸ਼ਟੀ ਵਿੱਚ ਕੁਝ ਮੁੱਖ ਡਿਲਿਵਰੀ ਮੈਟ੍ਰਿਕਸ ਹਨ:
ਇੱਕ ਛੋਟੀ ਟੀਮ ਜੋ ਪੀਹਲੇ ਪੰਜ ਛੋਟੇ ਬਦਲਾਅ ਹਫ਼ਤੇ ਵਿੱਚ ਡਿਪਲੋਇ ਕਰਦੀ ਹੈ ਅਕਸਰ ਇੱਕ ਵੱਡੀ ਆਰਗ ਜੋ ਮਹੀਨੇ ਵਿੱਚ ਇੱਕ ਵੱਡੀ ਰਿਲੀਜ਼ ਕਰਦੀ ਹੈ ਨਾਲੋਂ ਤੇਜ਼ ਸਿੱਖਦੀ ਹੈ—ਭਾਵੇਂ ਮਹੀਨਾਵਾਰ ਰਿਲੀਜ਼ ਵਿੱਚ ਜ਼ਿਆਦਾ ਕੋਡ ਹੋਵੇ।
ਅਮਲੀ ਰੂਪ ਵਿੱਚ, “ਇੰਜੀਨੀਅਰਿੰਗ ਲਈ AI” ਆਮ ਤੌਰ 'ਤੇ ਮੌਜੂਦਾ ਕੰਮ ਵਿੱਚ ਏਨੀ ਸਹਾਇਕਾਂ ਦੀ ਸ਼੍ਰੇਣੀ ਵਾਂਗ ਲੱਗਦਾ ਹੈ:
AI ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਮਦਦ ਕਰਦਾ ਹੈ ਪਰਤੀ ਵਿਅਕਤੀ throughput ਅਤੇ ਦੁਬਾਰਾ ਕੰਮ ਘਟਾਉਣ ਵਿਚ—ਪਰ ਇਹ ਚੰਗਾ ਉਤਪਾਦ ਨਿਰੀਖਣ, ਸਪਸ਼ਟ ਲੋੜਾਂ, ਜਾਂ ਮਾਲਕੀ ਦੀ ਥਾਂ ਨਹੀਂ ਲੈਂਦਾ।
ਗਤੀ ਅਧਿਕ ਤੌਰ 'ਤੇ ਦੋ ਤਾਕਤਾਂ ਨਾਲ ਸੀਮਿਤ ਹੁੰਦੀ ਹੈ: ਸੰਯੋਜਨ ਓਵਰਹੈੱਡ (ਹੈਂਡਆਫ਼ਸ, ਮਨਜ਼ੂਰੀਆਂ, ਉਡੀਕ) ਅਤੇ ਇਟਰੈਸ਼ਨ ਲੂਪ (ਬਨਾਉ → ਰਿਲੀਜ਼ → ਦੇਖੋ → ਠੀਕ ਕਰੋ)। AI ਉਹਨਾਂ ਟੀਮਾਂ ਨੂੰ ਵਧਾਉਂਦਾ ਹੈ ਜੋ ਪਹਿਲਾਂ ਹੀ ਕੰਮ ਨੂੰ ਛੋਟਾ ਰੱਖਦੀਆਂ ਹਨ, ਫੈਸਲੇ ਸਾਫ਼ ਰੱਖਦੀਆਂ ਹਨ ਅਤੇ ਫੀਡਬੈਕ ਘੱਟ ਹੁੰਦਾ ਹੈ।
ਆਦਤਾਂ ਅਤੇ ਗਾਰਡਰੇਲ—ਟੈਸਟ, ਕੋਡ ਰਿਵਿਊ, ਅਤੇ ਰਿਲੀਜ਼ ਅਨੁਸ਼ਾਸਨ—ਵਿਨਾਂ, AI ਗਲਤ ਕੰਮ ਨੂੰ ਵੀ ਤੇਜ਼ੀ ਨਾਲ ਤੇਜ਼ ਕਰ ਸਕਦਾ ਹੈ।
ਵੱਡੇ ਇੰਜੀਨੀਅਰਿੰਗ ਆਰਗ ਸਿਰਫ਼ ਲੋਕ ਨਹੀਂ ਵਧਾਉਂਦੇ—ਉਹ ਕਨੈਕਸ਼ਨ ਵਧਾਉਂਦੇ ਹਨ। ਹਰ ਨਵਾਂ ਟੀਮ ਸਰਹੱਦ ਐਸਾ ਸੰਯੋਜਨ ਕੰਮ ਲਿਆਉਂਦਾ ਹੈ ਜੋ ਫੀਚਰ ਸ਼ਿਪ ਨਹੀਂ ਕਰਦਾ: ਤਰਜੀਹਾਂ ਨੂੰ ਸਧਾਰਨ ਕਰਨਾ, ਡਿਜ਼ਾਇਨ ਸੰਰਚਨਾ ਮਿਲਾਉਣਾ, ਮਾਲਕੀ ਤੇ ਗੱਲਬਾਤ, ਅਤੇ ਬਦਲਾਅ ਨੂੰ “ਠੀਕ” ਚੈਨਲਾਂ ਰਾਹੀਂ ਭੇਜਣਾ।
ਸੰਯੋਜਨ ਓਵਰਹੈੱਡ ਮੁਹੱਈਆ ਜਾਣ ਵਾਲੀ ਜਗ੍ਹਾ ਵਿੱਚ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ:
ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਅਪ੍ਰाकृतिक ਨਹੀਂ ਹੈ। ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਇਹ ਇਕੱਠੇ ਹੋ ਜਾਂਦੇ ਹਨ—ਅਤੇ ਇਹ ਹੇਡਕਾਊਂਟ ਨਾਲੋਂ ਤੇਜ਼ੀ ਨਾਲ ਵੱਧਦੇ ਹਨ।
ਵੱਡੇ ਆਰਗ ਵਿੱਚ ਇੱਕ ਸਧਾਰਨ ਬਦਲਾਅ ਅਕਸਰ ਕਈ ਡਿਪੈਂਡੈਂਸੀ ਲਾਈਨਾਂ ਨੂੰ ਪਾਰ ਕਰਦਾ ਹੈ: ਇੱਕ ਟੀਮ UI ਦੀ ਮਾਲਕੀ ਕਰਦੀ ਹੈ, ਦੂਜੀ API ਦੀ, ਪਲੈਟਫਾਰਮ ਟੀਮ ਡਿਪਲੋਇਮੈਂਟ ਦੀ, ਅਤੇ ਇਨਫੋਸੈਕ ਗਰੂਪ ਮਨਜ਼ੂਰੀ ਦੀ। ਭਾਵੇਂ ਹਰ ਗਰੂਪ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੋਵੇ, ਕਤਾਰ ਸਮਾਂ ਪ੍ਰਮੁੱਖ ਹੋ ਜਾਂਦਾ ਹੈ।
ਆਮ ਧੀਰਜਾਂ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਦੀਆਂ ਹਨ:
Lead time ਸਿਰਫ਼ ਕੋਡਿੰਗ ਸਮਾਂ ਨਹੀਂ ਹੈ; ਇਹ ਆਈਡੀਆ ਤੋਂ ਪ੍ਰੋਡਕਸ਼ਨ ਤੱਕ ਦਾ ਲੱਗਿਆ ਹੋਇਆ ਸਮਾਂ ਹੈ। ਹਰ ਵਾਧੂ ਹੈਂਡਸ਼ੇਕ ਨੇ latency ਵਧਾਈ: ਤੁਸੀਂ ਅਗਲੇ ਮੀਟਿੰਗ, ਅਗਲੇ ਰਿਵਿਊਅਰ, ਅਗਲੇ ਸਪ੍ਰਿੰਟ, ਕਿਸੇ ਹੋਰ ਦੀ ਕਤਾਰ ਵਿਚ ਅਗਲੇ ਸਲਾਟ ਦਾ ਇੰਤਜ਼ਾਰ ਕਰਦੇ ਹੋ।
ਛੋਟੀ ਟੀਮਾਂ ਅਕਸਰ ਜਿੱਤਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਉਹ ਮਾਲਕੀ ਤੰਗ ਰੱਖ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ਫੈਸਲੇ ਲੋਕਲ ਕਰ ਸਕਦੀਆਂ ਹਨ। ਇਸਦਾ ਮਤਲਬ ਸਮੀਖਿਆ ਖਤਮ ਹੋ ਜਾਣੀ ਨਹੀਂ—ਇੱਕ ਤੋਂ ਵੱਧ ਹੌਪਸ ਦੀ ਗਿਣਤੀ ਘੱਟ ਹੋ ਜਾਂਦੀ ਹੈ ਜਿੱਥੇ ਵੱਡੇ ਆਰਗ ਦਿਨ ਅਤੇ ਹਫ਼ਤੇ ਖੋ ਬੈਠਦੇ ਹਨ।
ਗਤੀ ਸਿਰਫ਼ ਤੇਜ਼ ਟਾਈਪ ਕਰਨ ਬਾਰੇ ਨਹੀਂ—ਇਹ ਘੱਟ ਲੋਕਾਂ ਨੂੰ ਉਡੀਕ ਕਰਨ ਬਾਰੇ ਹੈ। ਛੋਟੀ ਟੀਮਾਂ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰਦੀਆਂ ਹਨ ਜਦੋਂ ਕੰਮ ਵਿੱਚ single-threaded ownership ਹੋਵੇ: ਇੱਕ ਸਪਸ਼ਟ ਜ਼ਿੰਮੇਵਾਰ ਵਿਅਕਤੀ (ਜਾਂ ਜੋੜਾ) ਜੋ ਇੱਕ ਫੀਚਰ ਨੂੰ ਆਇਡੀਆ ਤੋਂ ਪ੍ਰੋਡਕਸ਼ਨ ਤੱਕ ਚਲਾਉਂਦਾ ਹੈ, ਅਤੇ ਇੱਕ ਨਾਮ-ਦਿੱਤਾ ਫੈਸਲਾ ਕਰਨ ਵਾਲਾ ਹੁੰਦਾ ਹੈ ਜੋ ਟਰੇਡ-ਆਫ਼ਸ ਨੂੰ ਸੁਝਾਇਆ ਜਾ ਸਕਦਾ ਹੈ।
ਜਦੋਂ ਇੱਕ ਮਾਲਕ ਨਤੀਜਿਆਂ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਫੈਸਲੇ product, design, engineering, ਅਤੇ “platform team” ਵਿਚ ਟੁੱਟ-ਟੁੱਟ ਕੇ ਨਹੀਂ ਘੁਮਦੇ। ਮਾਲਕ ਇਨਪੁੱਟ ਇਕੱਤਰ ਕਰਦਾ, ਫੈਸਲਾ ਕਰਦਾ, ਅਤੇ ਅੱਗੇ ਵੱਧਦਾ।
ਇਸਦਾ ਮਤਲਬ ਇਕੱਲਾ ਕੰਮ ਕਰਨਾ ਨਹੀਂ; ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਹਰ ਕੋਈ ਜਾਣਦਾ ਹੈ ਕਿ ਕੌਣ ਸਟੀਅਰ ਕਰ ਰਿਹਾ ਹੈ, ਕੌਣ ਮਨਜ਼ੂਰ ਕਰਦਾ ਹੈ, ਅਤੇ “done” ਦਾ ਕੀ ਅਰਥ ਹੈ।
ਹਰ ਹੈਂਡਆਫ਼ ਦੋ ਕਿਸਮ ਦੇ ਖਰਚ ਜੋੜਦਾ ਹੈ:
ਛੋਟੀ ਟੀਮਾਂ ਇਸ ਨੂੰ ਇਸ ਤਰੀਕੇ ਨਾਲ ਬਚਦੀਆਂ ਹਨ ਕਿ ਸਮੱਸਿਆ ਇੱਕ ਕੱਸੂਤੀ ਲੂਪ ਵਿੱਚ ਰਹਿੰਦੀ: ਇੱਕੋ ਮਾਲਕ ਲੋੜਾਂ, ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ, ਰੋਲਆਉਟ, ਅਤੇ ਫਾਲੋਅਪ ਵਿੱਚ ਭਾਗ ਲੈਂਦਾ ਹੈ। ਨਤੀਜਾ ਹੁੰਦਾ ਹੈ ਘੱਟ “ਉਹ ਨਹੀ ਸੀ ਜੋ ਮੈਂ ਮੰਗਿਆ” momenten।
AI ਮਾਲਕੀ ਦੀ ਥਾਂ ਨਹੀਂ ਲੈਂਦਾ—ਇਹ ਉਸਨੂੰ ਵਿਸਤਾਰ ਦਿੰਦਾ ਹੈ। ਇੱਕ ਮਾਲਕ AI ਦੀ ਵਰਤੋਂ ਨਾਲ ਹੋਰ ਟਾਸਕ ਬਹੁਤ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਹੱਥ ਵਿੱਚ ਰੱਖ ਸਕਦਾ ਹੈ:
ਮਾਲਕ ਹਾਲੇ ਵੀ ਲਈ ਜਾਂਦੇ ਨਿਯਮਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ ਅਤੇ ਫੈਸਲਾ ਕਰਦਾ ਹੈ, ਪਰ ਖਾਲੀ ਪੰਨੇ ਤੋਂ ਕਾਰਜਯੋਗ ਡਰਾਫਟ ਤੱਕ ਜਾਣਾ ਬਹੁਤ ਤੇਜ਼ ਹੋ ਜਾਂਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ vibe-coding ਵਰਕਫਲੋ (ਉਦਾਹਰਨ ਲਈ Koder.ai) ਵਰਤ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ “ਇੱਕ ਮਾਲਕ ਸਾਰੀ ਸਲਾਈਸ ਕਵਰ ਕਰੇ” ਮਾਡਲ ਹੋਰ ਵੀ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ: ਤੁਸੀਂ ਇੱਕ ਯੋਜਨਾ ਡਰਾਫਟ ਕਰ ਸਕਦੇ ਹੋ, React UI ਅਤੇ Go/PostgreSQL ਬੈਕਐਂਡ ਸਕੈਲੈਟਨ ਜਨਰੇਟ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਚੈਟ-ਚਲਿਤ ਲੂਪ ਵਿੱਚ ਛੋਟੇ ਬਦਲਾਅ ਦੁਆਰਾ ਦੌਰ ਕਰ ਸਕਦੇ ਹੋ—ਫਿਰ ਜਦੋਂ ਤੁਹਾਨੂੰ ਸਖਤ ਨਿਯੰਤਰਣ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਸੋਰਸ ਕੋਡ ਨਿਰਯਾਤ ਕਰੋ।
ਇਹ ਓਪਰੇਸ਼ਨਲ ਸੁਚਕਾਂਵ ਖੋਜੋ:
ਜਦੋਂ ਇਹ ਨਿਸ਼ਾਨੀਆਂ ਮੌਜੂਦ ਹੁੰਦੀਆਂ ਹਨ, ਇੱਕ ਛੋਟੀ ਟੀਮ ਸ਼ੱਕ-ਮੁਕਤ ਹੋ ਕੇ ਅੱਗੇ ਵੱਧ ਸਕਦੀ ਹੈ—ਅਤੇ AI ਉਸ ਗਤੀ ਨੂੰ ਬਣਾਈ ਰੱਖਣ ਵਿੱਚ ਆਸਾਨੀ ਪੈਦਾ ਕਰਦਾ ਹੈ।
ਵੱਡੀਆਂ ਯੋਜਨਾਵਾਂ ਕੁਝ ਵਾਰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਮਹਿਸੂਸ ਹੁੰਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਉਹ “ਫੈਸਲਾ ਲੈਣ ਵਾਲੇ ਮੁਕਾਮਾਂ” ਨੂੰ ਘਟਾ ਦਿੰਦੀਆਂ ਹਨ। ਪਰ ਅਕਸਰ ਉਹ ਸਿੱਖਣ ਨੂੰ ਆਖਿਰ ਵਿੱਚ ਧੱਕ ਦਿੰਦੀਆਂ ਹਨ—ਕਈ ਹਫ਼ਤਿਆਂ ਬਾਅਦ—ਜਦੋਂ ਬਦਲਾਅ ਸਭ ਤੋਂ ਮਹਿੰਗੇ ਹੋ ਜਾਂਦੇ ਹਨ। ਛੋਟੀ ਟੀਮਾਂ ਅਸਲ ਰਾਹ ਤੇ ਤੁਰਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਉਹ ਇੱਕ ਖਿਆਲ ਅਤੇ ਅਸਲ-ਦੁਨੀਆ ਫੀਡਬੈਕ ਦੇ ਦਰਮਿਆਨ ਦੀ ਦੂਰੀ ਘਟਾਉਂਦੀਆਂ ਹਨ।
ਛੋਟਾ ਫੀਡਬੈਕ ਲੂਪ ਸਧਾਰਨ ਹੈ: ਉਹ ਸਭ ਤੋਂ ਛੋਟੀ ਚੀਜ਼ ਬਣਾਓ ਜੋ ਤੁਹਾਨੂੰ ਕੁਝ ਸਿਖਾ ਸਕੇ, ਇਸ ਨੂੰ ਯੂਜ਼ਰਾਂ ਦੇ ਸਾਹਮਣੇ ਰੱਖੋ, ਅਤੇ ਅਗਲਾ ਕੀ ਕਰਨਾ ਹੈ ਫੈਸਲਾ ਕਰੋ।
ਜਦੋਂ ਫੀਡਬੈਕ ਦਿਨਾਂ ਵਿੱਚ ਆਉਂਦਾ ਹੈ (ਕੁਆਰਟਰਾਂ ਨਹੀਂ), ਤਾਂ ਤੁਸੀਂ ਗਲਤ ਹੱਲ ਨੂੰ ਪੋਲਿਸ਼ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹੋ। ਤੁਸੀਂ ਉਨ੍ਹਾਂ “ਜਸਟ-ਇਨ-ਕੇਸ” ਲੋੜਾਂ ਦੇ ਲਈ ਓਵਰ-ਇੰਗੀਨੀਅਰ ਕਰਨ ਤੋਂ ਵੀ ਬਚਦੇ ਹੋ ਜੋ ਕਦੇ ਆਉਂਦੀਆਂ ਨਹੀਂ।
ਛੋਟੀ ਟੀਮਾਂ ਹਲਕੇ ਚੱਕਰ ਚਲਾ ਸਕਦੀਆਂ ਹਨ ਜੋ ਫਿਰ ਵੀ ਮਜ਼ਬੂਤ ਸਿਗਨਲ ਦਿੰਦੀਆਂ ਹਨ:
ਮੁੱਖ ਗੱਲ: ਹਰ ਚੱਕਰ ਨੂੰ ਇੱਕ ਪ੍ਰਯੋਗ ਵਜੋਂ ਲਓ, ਛੋਟੇ ਪ੍ਰੋਜੈਕਟ ਵਜੋਂ ਨਹੀਂ।
AI ਦੀ ਸਭ ਤੋਂ ਵੱਡੀ ਲੀਵਰੇਜ ਇਹ ਨਹੀਂ ਕਿ ਉਹ ਹੋਰ ਕੋਡ ਲਿਖੇ—ਇਹ ਹੈ “ਅਸੀਂ ਕੁਝ ਸੁਣਿਆ” ਤੋਂ “ਅਸੀਂ ਜਾਣਦੇ ਹਾਂ ਕਿ ਅਗਲਾ ਕੀ ਅਜ਼ਮਾਉਣਾ ਹੈ” ਤੱਕ ਦੇ ਸਮੇਂ ਨੂੰ ਖਿੱਚਣਾ। ਉਦਾਹਰਨ ਵਜੋਂ, ਤੁਸੀਂ AI ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ:
ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਸੁੰਞੇਸ਼ਨ ਮੀਟਿੰਗਾਂ ਵਿੱਚ ਘੱਟ ਸਮਾਂ ਲੱਗਦਾ ਹੈ ਅਤੇ ਅਗਲਾ ਟੈਸਟ ਚਲਾਉਣ ਲਈ ਵਧੇਰੇ ਸਮਾਂ ਮਿਲਦਾ ਹੈ।
ਟੀਮਾਂ ਅਕਸਰ ਸ਼ਿਪਿੰਗ velocity ਦੀ ਸ਼ਾਬਾਸ਼ੀ ਮੰਨਦੀਆਂ ਹਨ—ਕਿੰਨੇ ਫੀਚਰ ਬਾਹਰ ਗਏ। ਪਰ ਅਸਲ ਗਤੀ ਹੈ learning velocity: ਤੁਸੀਂ ਅਣਜਾਣੀ ਨੂੰ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਘਟਾ ਸਕਦੇ ਹੋ ਅਤੇ ਚੰਗੇ ਫੈਸਲੇ ਕਰ ਸਕਦੇ ਹੋ।
ਇੱਕ ਵੱਡਾ ਆਰਗ ਬਹੁਤ ਕੁਝ ਸ਼ਿਪ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਫਿਰ ਵੀ ਸਲੋ ਹੋ ਸਕਦਾ ਹੈ ਜੇ ਉਹ ਦੇਰ ਨਾਲ ਸਿੱਖਦਾ ਹੈ। ਇੱਕ ਛੋਟੀ ਟੀਮ ਘੱਟ “ਵਾਲੀਅਮ” ਸ਼ਿਪ ਕਰਕੇ ਵੀ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵੱਧ ਸਕਦੀ ਹੈ ਕਿਉਂਕਿ ਉਹ ਪਹਿਲਾਂ ਸਿੱਖਦੀ, ਜਲਦੀ ਠੀਕ ਕਰਦੀ, ਅਤੇ ਰੋਡਮੇਪ ਨੂੰ ਸਬੂਤ-ਆਧਾਰਿਤ ਬਣਾਉਂਦੀ ਹੈ।
AI ਇੱਕ ਛੋਟੀ ਟੀਮ ਨੂੰ “ਵੱਡੀ” ਨਹੀਂ ਬਣਾਉਂਦਾ। ਇਹ ਟੀਮ ਦੀ ਮੌਜੂਦਾ ਸੁਝਬੂਝ ਅਤੇ ਮਾਲਕੀ ਨੂੰ ਹੋਰ ਦੂਰ ਤਕ ਲੈ ਜਾਂਦਾ ਹੈ। ਜਿੱਤ ਇਹ ਨਹੀਂ ਕਿ AI ਕੋਡ ਲਿਖਦਾ ਹੈ; ਜਿੱਤ ਇਹ ਹੈ ਕਿ ਇਹ ਉਹਨਾਂ ਹਿੱਸਿਆਂ ਤੋਂ ਡ੍ਰੈਗ ਘਟਾ ਦਿੰਦਾ ਹੈ ਜੋ ਸਮਾਂ ਖਾਂਦੇ ਹਨ ਅਤੇ ਉਤਪਾਦ ਨੂੰ ਬਿਹਤਰ ਨਹੀਂ ਬਣਾਉਂਦੇ।
ਛੋਟੀ ਟੀਮਾਂ ਨੂੰ ਜ਼ਿਆਦਾ ਲਾਭ ਮਿਲਦਾ ਹੈ ਜਦੋਂ ਉਹ AI ਨੂੰ ਉਹਨਾਂ ਕੰਮਾਂ 'ਤੇ ਲਗਾਉਂਦੀਆਂ ਹਨ ਜੋ ਲੋੜੀਲੇ ਹਨ ਪਰ ਅਕਸਰ ਵੱਖਪੱਖ ਨਹੀਂ ਬਣਦੇ:
ਪੈਟਰਨ ਇੱਕੋ ਹੈ: AI ਪਹਿਲਾਂ ਦੇ 80% ਨੂੰ ਤੇਜ਼ ਕਰਦਾ ਹੈ ਤਾਂ ਜੋ ਮਨੁੱਖ ਫਾਈਨਲ 20% 'ਤੇ ਵਧੇਰੇ ਸਮਾਂ ਲਗਾ ਸਕਣ—ਉਹ ਹਿੱਸਾ ਜੋ ਉਤਪਾਦੀ ਸੁਝਾਨਾ ਮੰਗਦਾ ਹੈ।
AI ਰੁਟੀਨ ਟਾਸਕਾਂ, “ਪਛਾਣੇ ਹੋਏ ਸਮੱਸਿਆਵਾਂ”, ਅਤੇ ਕਿਸੇ ਵੀ ਚੀਜ਼ 'ਤੇ ਚਮਕਦਾ ਹੈ ਜੋ ਮੌਜੂदा ਕੋਡਬੇਸ ਪੈਟਰਨ ਤੋਂ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ। ਇਹ ਤੇਜ਼ੀ ਨਾਲ ਵਿਕਲਪ ਖੋਜਣ ਲਈ ਵੀ ਚੰਗਾ ਹੈ: ਦੋ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨਾਂ ਦੀ ਪੇਸ਼ਕਸ਼, ਟਰੇਡ-ਆਫ਼ ਲਿਖੋ, ਜਾਂ ਉਹਨਾਂ ਐਜ ਕੇਸਾਂ ਨੂੰ ਉੱਠਾਓ ਜੋ ਤੁਸੀਂ ਚੁੱਕ ਗਏ ਹੋ ਸਕਦੇ ਹੋ।
ਇਹ ਘੱਟ ਮਦਦ ਕਰਦਾ ਹੈ ਜਦੋਂ ਲੋੜਾਂ ਅਸਪਸ਼ਟ ਹਨ, ਜਦੋਂ ਆਰਕੀਟੈਕਚਰ ਫੈਸਲਾ ਲੰਬੇ ਸਮੇਂ ਵਾਲੇ ਨਤੀਜੇ ਰੱਖਦਾ ਹੈ, ਜਾਂ ਜਦੋਂ ਸਮੱਸਿਆ ਬਹੁਤ ਡੋਮੇਨ-ਵਿਸ਼ੇਸ਼ ਹੈ ਅਤੇ ਲਿਖੀ ਹੋਈ ਸੰਦੇਭ ਨਹੀਂ ਹੈ। ਜੇ ਟੀਮ ਇਹ ਨਹੀਂ ਸਮਝਾ ਸਕਦੀ ਕਿ “done” ਦਾ ਕੀ ਮਤਲਬ ਹੈ, ਤਾਂ AI ਸਿਰਫ਼ ਯਕੀਨੀ-ਲੇਖੀ ਆਉਟਪੁੱਟ ਤੇਜ਼ੀ ਨਾਲ ਜਨਰੇਟ ਕਰੇਗਾ।
AI ਨੂੰ ਜੂਨੀਅਰ ਸਹਿਯੋਗੀ ਵਜੋਂ ਵਰਤੋ: ਉਪਯੋਗੀ, ਤੇਜ਼, ਅਤੇ ਕਈ ਵਾਰ ਗਲਤ। ਮਨੁੱਖਾਂ ਹੋਰਾਂ ਨੇ ਨਤੀਜੇ ਦੀ ਮਾਲਕੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।
ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਹਰ AI-ਸਹਾਇਤ ਬਦਲਾਅ ਫਿਰ ਵੀ ਸਮੀਖਿਆ, ਟੈਸਟ, ਅਤੇ ਮੂਲ ਚੈਕਸ਼ਾਂ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ। ਪ੍ਰਾਇਗਟਿਕਲ ਨਿਯਮ: AI ਲਈ ਡਰਾਫਟ ਅਤੇ ਰੂਪਾਂਤਰ; ਮਨੁੱਖ ਲਈ ਫੈਸਲਾ ਅਤੇ ਪ੍ਰਮਾਣੀਕਰਨ। ਇਹੀ ਤਰ੍ਹਾਂ ਛੋਟੀ ਟੀਮਾਂ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰਦੀਆਂ ਹਨ ਬਿਨਾਂ ਇਸਦੇ ਕਿ velocity ਭਵਿੱਖੀ ਸਫਾਈ ਵਿੱਚ ਬਦਲੇ।
Context switching ਛੋਟੀ ਟੀਮਾਂ 'ਤੇ ਗਤੀ ਦਾ ਇਕ ਖਾਮੋਸ਼ ਘਾਤਕ ਹੈ। ਇਹ ਸਿਰਫ਼ “ਵਿਚਕਾਰ-ਟੋਟਿਆ” ਹੀ ਨਹੀਂ—ਇਹ ਉਹ ਮਨਸਿਕ ਰੀਬੂਟ ਹੈ ਜੋ ਹਰ ਵਾਰੀ ਤੁਹਾਨੂੰ ਕੋਡ, ਟਿਕਟ, ਡੌਕ, Slack ਥ੍ਰੈੱਡਸ, ਅਤੇ ਸਿਸਟਮ ਦੇ незнаком ਭਾਗਾਂ ਵਿਚਕਾਰ ਛਾਲ ਮਾਰਨ 'ਤੇ ਕਰਨਾ ਪੈਂਦਾ ਹੈ। AI ਸਭ ਤੋਂ ਵੱਧ ਉਸ ਸਮੇਂ ਮਦਦ ਕਰਦਾ ਹੈ ਜਦੋਂ ਇਹ ਰੀਬੂਟਾਂ ਨੂੰ ਛੋਟੇ pit-stop 'ਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।
20 ਮਿੰਟ ਲੱਭਣ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਤੇਜ਼ ਸੰਖੇਪ, ਸੰਭਾਵਿਤ ਫਾਇਲਾਂ ਲਈ ਨਿਰਦੇਸ਼, ਜਾਂ ਜਿਸ ਚੀਜ਼ ਨੂੰ ਤੁਸੀਂ ਦੇਖ ਰਹੇ ਹੋ ਉਸਦਾ ਸਧਾਰਣ-ਅੰਗ੍ਰੇਜ਼ੀ ਵਿਆਖਿਆ ਪੁੱਛ ਸਕਦੇ ਹੋ। ਚੰਗੀ ਵਰਤੋਂ ਨਾਲ, AI ਸਮਝਣ ਲਈ “ਪਹਿਲਾ ਡਰਾਫਟ” ਜਨਰੇਟਰ ਬਣ ਜਾਂਦਾ ਹੈ: ਇਹ ਲੰਮੇ PR ਦਾ ਸੰਖੇਪ ਕਰ ਸਕਦਾ ਹੈ, ਅਸਪਸ਼ਟ ਬੱਗ ਰਿਪੋਰਟ ਨੂੰ ਹਾਇਪੋਥੇਸਿਸ ਵਿੱਚ ਤਬਦੀਲ ਕਰ ਸਕਦਾ ਹੈ, ਜਾਂ ਡਰੌਨ ਵਾਲੇ stack trace ਨੂੰ ਸੰਭਾਵਿਤ ਕਾਰਨਾਂ ਵਿੱਚ ਤਰਜਮਾ ਕਰ ਸਕਦਾ ਹੈ।
ਜਿੱਤ ਇਹ ਨਹੀਂ ਕਿ AI ਹਮੇਸ਼ਾ ਸਹੀ ਹੈ—ਜਿੱਤ ਇਹ ਹੈ ਕਿ ਇਹ ਤੁਹਾਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਦਿਸ਼ਾ ਦਿੰਦਾ ਤਾਂ ਜੋ ਤੁਸੀਂ ਅਸਲ ਫੈਸਲੇ ਕਰ ਸਕੋ।
ਕੁੱਝ ਪ੍ਰਾਂਪਟ ਪੈਟਰਨ ਜਿਹੜੇ ਲਗਾਤਾਰ thrash ਘਟਾਉਂਦੇ ਹਨ:
ਇਹ ਪ੍ਰਾਂਪਟ ਤੁਹਾਨੂੰ ਘੁੰਮਣ ਤੋਂ ਕਰਵਾਈ ਵੱਲ ਬਦਲਦੇ ਹਨ।
ਗਤੀ ਤਾਂ ਮਿਲਦੀ ਹੈ ਜਦ ਪ੍ਰਾਂਪਟ ਟੀਮ ਪੱਧਰੀ ਟੈਮਪਲੇਟ ਬਣ ਜਾਂਦੇ ਹਨ। ਛੋਟੀ ਇਕ ਅੰਦਰੂਨੀ “prompt kit” ਬਣਾਓ ਆਮ ਕੰਮਾਂ ਲਈ: PR ਸਮੀਖਿਆ, ਇਨਸੀਡੈਂਟ ਨੋਟਸ, migration ਯੋਜਨਾ, QA ਚੈਕੇਲਿਸਟ, ਅਤੇ ਰਿਲੀਜ਼ ਰਨਬੁਕ। ਸਥਿਰਤਾ ਮਹੱਤਵਪੂਰਕ ਹੈ: ਗੋਲ, ਸੀਮਾਵਾਂ (ਸਮਾਂ, ਸਕੋਪ, ਜੋਖਮ), ਅਤੇ ਉਮੀਦ ਕੀਤੇ ਗਏ ਆਉਟਪੁੱਟ ਫਾਰਮੈਟ ਸ਼ਾਮਲ ਕਰੋ।
ਰਹੱਸ, ਗਾਹਕ ਡੇਟਾ, ਜਾਂ ਕੋਈ ਵੀ ਚੀਜ਼ ਜੋ ਤੁਸੀਂ ਟਿਕਟ ਵਿੱਚ ਨਹੀਂ ਪਾਉਣਾ ਚਾਹੁੰਦੇ, ਪੇਸਟ ਨਾ ਕਰੋ। ਆਉਟਪੁੱਟ ਨੂੰ ਸੁਝਾਵ ਸਮਝੋ: ਅਹੰਕਾਰਪੂਰਕ ਦਾਅਵਿਆਂ ਦੀ ਜਾਂਚ ਕਰੋ, ਟੈਸਟ ਚਲਾਓ, ਅਤੇ ਜਨੇਰੇਟ ਕੀਤੇ ਕੋਡ ਦੀ ਦੋਹਰੀ ਜਾਂਚ ਕਰੋ—ਖਾਸ ਕਰਕੇ auth, payments, ਅਤੇ data deletion ਦੇ ਆਲੇ-ਦੁਆਲੇ। AI context switching ਘਟਾਉਂਦਾ ਹੈ; ਇਹ engineering ਸੁਝਬੂਝ ਦੀ ਥਾਂ ਨਹੀਂ ਲੈਣਾ ਚਾਹੀਦਾ।
ਤੇਜ਼ ਸ਼ਿਪਿੰਗ ਹੀਰੋਇਕ ਸਪ੍ਰਿੰਟਾਂ ਬਾਰੇ ਨਹੀਂ ਹੈ; ਇਹ ਹਰ ਬਦਲਾਅ ਦਾ ਆਕਾਰ ਘਟਾਉਣ ਬਾਰੇ ਹੈ ਤਾਂ ਕਿ ਡਿਲਿਵਰੀ ਰੋਜ਼ਮਰਰਾ ਬਣ ਜਾਵੇ। ਛੋਟੀ ਟੀਮਾਂ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਫਾਇਦਾ ਹੁੰਦਾ ਹੈ: ਘੱਟ ਡਿਪੈਂਡੈਂਸੀਜ਼ ਕੰਮ ਨੂੰ ਬਹੁਤ ਛੋਟਾ ਕੱਟਣਾ ਆਸਾਨ ਬਣਾਉਂਦੀਆਂ ਹਨ। AI ਉਸ ਫਾਇਦੇ ਨੂੰ ਵਧਾਉਂਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ “ਖਿਆਲ” ਤੋਂ “ਸੁਰੱਖਿਅਤ, ਰਿਲੀਜ਼ਯੋਗ ਬਦਲਾਅ” ਤੱਕ ਦਾ ਸਮਾਂ ਘਟਾਉਂਦਾ ਹੈ।
ਇੱਕ ਸਧਾਰਨ ਪਾਈਪਲਾਈਨ ਜ਼ਿਆਦਾ ਵਿਸ਼ਾਲ ਤੋਂ ਵਧੀਆ:
AI ਰਿਲੀਜ਼ ਨੋਟਸ ਡਰਾਫਟ ਕਰਕੇ, ਛੋਟੇ commits ਸੁਝਾ ਕੇ, ਅਤੇ ਉਹ ਫਾਇਲਾਂ ਜਿਹੜੀਆਂ ਨਾਲ਼ ਆਮ ਤੌਰ 'ਤੇ ਛੇੜਛਾੜ ਹੋਣ ਦੀ ਨਿਸ਼ਾਨਦੀਹੀ ਕਰਕੇ ਤੁਹਾਡੇ PRs ਨੂੰ ਸਾਫ਼ ਅਤੇ ਤੰਗ ਰੱਖਣ ਲਈ ਮਦਦ ਕਰਦਾ ਹੈ।
ਟੈਸਟ ਆਮ ਤੌਰ 'ਤੇ “ਅਕਸਰ ਸ਼ਿਪ” ਦੀ ਰੁਕਾਵਟ ਹੁੰਦੇ ਹਨ। AI ਇਸ friction ਨੂੰ ਘਟਾ ਸਕਦਾ ਹੈ:
AI-ਨਿਰਮਿਤ ਟੈਸਟਾਂ ਨੂੰ ਪਹਿਲੇ ਡਰਾਫਟ ਵਜੋਂ ਲਓ: ਸਹੀਪਨ ਲਈ ਸਮੀਖਿਆ ਕਰੋ, ਫਿਰ ਉਹਨਾਂ ਨੂੰ ਰੱਖੋ ਜੋ ਸਤਹ ਨੂੰ ਮਾਹਿਰ ਕਰਦੇ ਹਨ।
ਅਕਸਰ ਡਿਪਲੋਇਜ਼ ਤੇਜ਼ ਪਤਾ ਲਗਾਉਣ ਅਤੇ ਤੇਜ਼ ਰੀਕਵਰੀ ਮੰਗਦੇ ਹਨ। ਬਣਾਓ:
ਜੇ ਤੁਹਾਡੇ ਡਿਲਿਵਰੀ ਮੂਲ ਤੱਤ ਧੁੰਦਲੇ ਹੋ ਰਹੇ ਹਨ, ਤਾਂ ਆਪਣੀ ਟੀਮ ਦੇ ਸਾਂਝੇ ਪਾਠ ਵਿੱਚ ਇਹ ਜੋੜੋ: /blog/continuous-delivery-basics.
ਇਨ੍ਹਾਂ ਅਭਿਆਸਾਂ ਨਾਲ, AI ਜਾਦੂ ਨਾਲ “ਤੇਜ਼” ਨਹੀਂ ਬਣਾਉਂਦਾ—ਇਹ ਛੋਟੇ ਦੇਰੀਆਂ ਨੂੰ ਹਟਾਉਂਦਾ ਹੈ ਜੋ ਨਹੀਂ ਤਾਂ ਹਫ਼ਤਿਆਂ ਦੇ ਚੱਕਰ ਬਣ ਜਾਂਦੀਆਂ।
ਵੱਡੇ ਇੰਜੀਨੀਅਰਿੰਗ ਆਰਗ ਅਕਸਰ ਆਹਿਸਤਾ ਨਹੀਂ ਚੱਲਦੇ ਕਿ ਲੋਕ ਸੁਸਤੀ ਹਨ। ਉਹ ਇਸ ਲਈ ਆਹਿਸਤਾ ਚੱਲਦੇ ਹਨ ਕਿ ਫੈਸਲੇ ਕਤਾਰਬੱਧ ਹੁੰਦੇ ਹਨ। ਆਰਕੀਟੈਕਚਰ ਕੌਂਸਲ ਮਹੀਨਾਵਾਰ ਮਿਲਦੇ ਹਨ। ਸੁਰੱਖਿਆ ਅਤੇ ਪ੍ਰਾਈਵੇਸੀ ਸਮੀਖਿਆ ਟਿਕਟ ਬੈਕਲੌਗ ਦੇ ਪਿੱਛੇ ਬੈਠੀ ਹੁੰਦੀ ਹੈ। “ਸਧਾਰਨ” ਬਦਲਾਅ ਲਈ ਟੈਕ ਲੀਡ ਰਿਵਿਊ, ਫਿਰ staff engineer ਰਿਵਿਊ, ਫਿਰ platform sign-off, ਫਿਰ release manager ਮਨਜ਼ੂਰੀ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ। ਹਰ ਹੌਪ ਉਡੀਕ ਦਾ ਸਮਾਂ ਜੋੜਦਾ ਹੈ, ਕੇਵਲ ਕੰਮ ਦਾ ਸਮਾਂ ਨਹੀਂ।
ਛੋਟੀ ਟੀਮਾਂ ਉਹ ਸਮਾਂ afford ਨਹੀਂ ਕਰ ਸਕਦੀਆਂ, ਇਸ ਲਈ ਉਹਨਾਂ ਨੂੰ ਹੋਰ ਮਾਡਲ ਲੋੜੀਦਾ ਹੈ: ਘੱਟ ਮਨਜ਼ੂਰੀਆਂ, ਮਜ਼ਬੂਤ ਗਾਰਡਰੇਲਜ਼।
ਅਨుమੋਦਨ ਜੋਖਮ-ਪ੍ਰਬੰਧਨ ਦਾ ਉਪਕਾਰਣ ਹਨ। ਉਹ ਖ਼ਰਾਬ ਬਦਲਾਅ ਦੀ ਸੰਭਾਵਨਾ ਘਟਾਉਂਦੇ ਹਨ, ਪਰ ਉਹ ਫੈਸਲੇ ਕੇਂਦਰੀਕ੍ਰਿਤ ਕਰ ਦਿੰਦੇ ਹਨ। ਜਦੋਂ ਹਰ ਮਹੱਤਵਪੂਰਕ ਬਦਲਾਅ ਇੱਕ ਹੀ ਛੋਟੀ ਗਰੁੱਪ ਨੂੰ ਮਨਜ਼ੂਰ ਕਰਵਾਉਣਾ ਪੈਂਦਾ ਹੈ, throughput ਢਹਿ ਜਾਂਦੀ ਹੈ ਅਤੇ ਇੰਜੀਨੀਅਰ ”manਜੂਰੀ ਲੈਣਾ“ ਲਈ optimize ਕਰਨ ਲੱਗਦੇ ਹਨ ਨਾ ਕਿ ਉਤਪਾਦ ਸੁਧਾਰਨਾ ਲਈ।
Guardrails ਗੁਣਵੱਤਾ ਜਾਂਚਾਂ ਨੂੰ ਮੀਟਿੰਗਾਂ ਤੋਂ defaults ਵਿੱਚ ਬਦਲ ਦਿੰਦੀਆਂ ਹਨ:
“ਕਿਸ ਨੇ ਇਹ ਮਨਜ਼ੂਰ ਕੀਤਾ?” ਦੀ ਥਾਂ ਸੁਵਾਲ ਹੁੰਦਾ ਹੈ “ਕੀ ਇਹ ਸਹਿਮਤ ਦਰਵਾਜ਼ੇ ਪਾਰ ਕਰ ਗਿਆ?”
AI ਗੁਣਵੱਤਾ ਨੂੰ ਸਥਿਰ ਕਰ ਸਕਦਾ ਹੈ ਬਿਨਾਂ ਲੂਪ ਵਿੱਚ ਹੋਰ ਮਨੁੱਖ ਜੋੜੇ:
ਇਸ ਨਾਲ ਸਥਿਰਤਾ ਆਉਂਦੀ ਹੈ ਅਤੇ ਸਮੀਖਿਆ ਤੇਜ਼ ਹੁੰਦੀ ਹੈ, ਕਿਉਂਕਿ ਸਮੀਖਿਆਕਾਰ ਖਾਲੀ ਸਕਰੀਨ ਤੋਂ ਸ਼ੁਰੂ ਨਹੀਂ ਕਰਦਾ—ਉਹ ਇੱਕ ਸੰਗਠਿਤ ਸੰਖੇਪ ਤੋਂ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ।
Compliance ਨੂੰ ਕਿਸੇ ਕਮੀਟੀ ਦੀ ਲੋੜ ਨਹੀਂ। ਇਸਨੂੰ ਦੁਹਰਾਉਣਯੋਗ ਰੱਖੋ:
ਉੱਚ-ਜੋਖਮ ਕੰਮ ਲਈ ਮਨਜ਼ੂਰੀਆਂ ਅਸਤੀਤਵ ਬਣ ਜਾਂਦੀਆਂ ਹਨ; guardrails ਬਾਕੀ ਹੰਢਾਂ ਸਮਭਾਲ ਲੈਂਦੇ ਹਨ। ਇਸੀ ਤਰ੍ਹਾਂ ਛੋਟੀ ਟੀਮ ਤੇਜ਼ ਰਹਿੰਦੀ ਹੈ ਬਿਨਾਂ ਲਾਪਰਵਾਹ ਹੋਏ।
ਵੱਡੀਆਂ ਟੀਮਾਂ ਅਕਸਰ “ਸਿਸਟਮ ਪੂਰਾ ਡਿਜ਼ਾਈਨ ਕਰੋ” ਕਰਦੀਆਂ ਹਨ ਪਹਿਲਾਂ ਕਿ ਕੋਈ ਵੀ ਚੀਜ਼ ਸ਼ਿਪ ਹੋਵੇ। ਛੋਟੀ ਟੀਮਾਂ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵੱਧਦੀਆਂ ਹਨ ਜਦੋਂ ਉਹ ਪਤਲੇ ਸਲਾਈਸ ਡਿਜ਼ਾਈਨ ਕਰਦੀਆਂ ਹਨ: ਉਹ ਸਭ ਤੋਂ ਛੋਟੀ end-to-end ਯੂਨਿਟ ਜੋ ਆਇਡੀਆ → ਕੋਡ → ਪ੍ਰੋਡਕਸ਼ਨ ਤੱਕ ਜਾਂਦੀ ਹੋ ਅਤੇ (ਛੋਟੇ ਕੋਹੋਰਟ ਦੁਆਰਾ) ਵਰਤੀ ਜਾ ਸਕਦੀ ਹੋ।
ਇੱਕ ਪਤਲਾ ਸਲਾਈਸ Vertical ownership ਹੈ, ਨਾ ਕਿ ਇੱਕ ਹੋਰੀਜ਼ਾਂਟਲ ਫੇਜ਼। ਇਹ ਉਸਦੀ ਲੋੜ ਹੈ ਜੋ ਇੱਕ ਨਤੀਜੇ ਨੂੰ ਅਸਲ ਬਣਾਉਣ ਲਈ ਡਿਜ਼ਾਇਨ, ਬੈਕਐਂਡ, ਫਰੰਟਐਂਡ ਅਤੇ ops ਵਿੱਚ ਲਿਆਉਂਦੀ ਹੈ।
“onboarding ਨੂੰ ਮੁੜ ਡਿਜ਼ਾਈਨ ਕਰੋ” ਦੀ ਥਾਂ, ਇੱਕ ਪਤਲਾ ਸਲਾਈਸ ਹੋ ਸਕਦਾ ਹੈ “ਇੱਕ ਹੋਰ signup ਫੀਲਡ ਲਵੋ, ਇਸਦੀ ਵੈਧਤਾ ਕਰੋ, ਸਟੋਰ ਕਰੋ, ਪ੍ਰੋਫ਼ਾਈਲ ਵਿੱਚ ਦਿਖਾਓ, ਅਤੇ completion ਟਰੈਕ ਕਰੋ।” ਇਹ ਛੋਟਾ ਹੈ ਇਸ ਲਈ ਜਲਦੀ ਖਤਮ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਯਥਾਰਥਪੂਰਕ ਸਿੱਖਣ ਲਈ ਕਾਫ਼ੀ ਪੂਰਾ ਹੈ।
AI ਇੱਕ ਸੰਰਚਿਤ ਸੋਚ ਸਾਥੀ ਵਜੋਂ ਉਪਯੋਗੀ ਹੈ:
ਮਕਸਦ ਜ਼ਿਆਦਾ ਟਾਸਕ ਨਹੀਂ—ਇੱਕ ਸਪਸ਼ਟ, ਸ਼ਿਪ ਕਰਨਯੋਗ ਸੀਮਾ ਹੈ।
Momentum ਉੱਠ ਜਾਂਦੀ ਹੈ ਜਦੋਂ “ਲਗਭਗ ਹੋ ਗਿਆ” ਲੰਬਾ ਖਿੱਚਦਾ ਹੈ। ਹਰ ਸਲਾਈਸ ਲਈ ਸਪਸ਼ਟ Definition of Done ਆਈਟਮ ਲਿਖੋ:
POST /checkout/quote ਜੋ ਕੀਮਤ + ਟੈਕਸ ਵਾਪਸ ਕਰਦਾ ਹੈThin slices ਡਿਜ਼ਾਈਨ ਨੂੰ ਸਚਾ ਰੱਖਦੇ ਹਨ: ਤੁਸੀਂ ਹੁਣ ਜਿਹੜਾ ਡਿਜ਼ਾਈਨ ਕਰ ਰਹੇ ਹੋ ਉਹ ਹੁਣੇ ਹੀ ਸ਼ਿਪ ਹੋ ਸਕਦਾ ਹੈ, ਤੇਜ਼ੀ ਨਾਲ ਸਿੱਖ ਕੇ ਅੱਗੇ ਵਧੋ।
AI ਇੱਕ ਛੋਟੀ ਟੀਮ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧਾ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ failure modes ਨੂੰ ਵੀ ਬਦਲਦਾ ਹੈ। ਮਕਸਦ “ਸੁਰੱਖਿਅਤ ਰਹਿਣ ਲਈ ਧੀਰੇ ਹੋ ਜਾਓ” ਨਹੀਂ—ਮਗਰ ਇਹ ਹੈ ਕਿ ਹਲਕੀਆਂ ਗਾਰਡਰੇਲਜ਼ ਜੋੜੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਸਟੱਕ ਨਾ ਕਰਨ ਬਗੈਰ ਸ਼ਿਪ ਕਰ ਸਕੋ।
ਤੇਜ਼ੀ ਨਾਲ ਚਲਣ ਨਾਲ ਉਹ ਸੰਭਾਵਨਾ ਵੱਧ ਜਾਂਦੀ ਹੈ ਕਿ ਕਚਾ ਕੰਮ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਆ ਜਾਵੇ। AI ਸਹਾਇਤਾ ਨਾਲ ਕੁਝ ਆਮ ਖਤਰੇ:
ਨਿਯਮ ਸਪਸ਼ਟ ਅਤੇ ਆਸਾਨ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। ਕੁਝ ਅਭਿਆਸ ਜ਼ਿਆਦਾ ਲਾਭ ਦਿੰਦੇ ਹਨ:
AI ਕੋਡ ਡਰਾਫਟ ਕਰ ਸਕਦਾ ਹੈ; ਮਨੁੱਖ ਨਤੀਜੇ ਦੀ ਮਾਲਕੀ ਲੈਣ।
ਪ੍ਰਾਂਪਟਾਂ ਨੂੰ ਧਾਰਮਿਕ ਲਿਖੋ: ਸਿੱਕੇ, ਟੋਕਨ, ਜਾਂ ਗਾਹਕ ਡੇਟਾ ਪੇਸਟ ਨਾ ਕਰੋ। ਮਾਡਲ ਨੂੰ assumptions ਸਮਝਾਉਣ ਲਈ ਕਹੋ, ਫਿਰ ਮੁੱਖ ਸਰੋਤ (ਡੌਕਸ) ਅਤੇ ਟੈਸਟਾਂ ਨਾਲ ਪੁਸ਼ਟੀ ਕਰੋ। ਜਦੋਂ ਕੁਝ “ਬਹੁਤ ਆਸਾਨ” ਮਹਿਸੂਸ ਹੋਵੇ, ਤਦ ਉਹ ਅਕਸਰ ਨਜ਼ਦੀਕੀ ਜਾਂਚ ਮੰਗਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗਾ AI-ਨਿਰਮਿਤ build environment ਵਰਤਦੇ ਹੋ, ਉਹੀ ਨਿਯਮ ਲਗੂ ਕਰੋ: ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ prompts ਵਿੱਚ ਨਾ ਪਾਓ, ਟੈਸਟ ਅਤੇ ਸਮੀਖਿਆ ਲਾਜ਼ਮੀ ਰੱਖੋ, ਅਤੇ snapshots/rollback-ਅਨੁਕੂਲ ਵਰਕਫਲੋ ਰੱਖੋ ਤਾਂ ਕਿ “ਤੇਜ਼” ਦਾ ਅਰਥ “ਵਾਪਸੀ ਯੋਗ” ਵੀ ਰਹੇ।
ਗਤੀ ਉਸ ਵੇਲੇ ਹੀ ਮਹੱਤਵਪੂਰਨ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇਸਨੂੰ ਵੇਖ ਸਕੋ, ਸਮਝਾ ਸਕੋ, ਅਤੇ ਦੁਹਰਾਓ। ਲਕੜੀ ਦਾ ਉਦੇਸ਼ “ਹੋਰ AI ਵਰਤੋ” ਨਹੀਂ—ਇੱਕ ਸਧਾਰਨ ਪ੍ਰਣਾਲੀ ਹੈ ਜਿੱਥੇ AI-ਸਹਾਇਤ ਅਭਿਆਸ ਨਿਯਮਤ ਤੌਰ 'ਤੇ time-to-value ਘਟਾਉਂਦੇ ਹਨ ਬਿਨਾਂ ਜੋਖਮ ਵਧਾਏ।
ਹਫ਼ਤਾਵਾਰ ਟਰੈਕ ਕਰਨ ਲਈ ਕੁਝ ਛੋਟੇ ਚੁਣੋ:
ਇੱਕ ਗੁਣਾਤਮਕ ਸੰਕੇਤ ਜੋੜੋ: “ਇਸ ਹਫ਼ਤੇ ਸਾਨੂੰ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਕੀ ਰੋਕਿਆ?” ਇਹ ਉਹ ਬੋਤਲਨੇਕ ਪ੍ਰਗਟ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰੇਗਾ ਜੋ ਮੈਟ੍ਰਿਕਸ ਨਹੀਂ ਦਿਖਾਉਂਦੇ।
ਇਸਨੂੰ ਸਥਿਰ ਰੱਖੋ, ਅਤੇ ਛੋਟੀ-ਟੀਮ ਮੈਚਿੰਗ ਰੱਖੋ:
ਹਫ਼ਤਾ 1: ਬੇਸਲਾਈਨ. ਉਪਰ ਦਿੱਤੇ ਮੈਟ੍ਰਿਕਸ 5–10 ਕਾਰਜ ਦਿਨਾਂ ਲਈ ਮਾਪੋ। ਫਿਰ ਕੋਈ ਤਬਦੀਲੀ ਨਹੀਂ।
ਹਫ਼ਤੇ 2–3: 2–3 AI ਵਰਕਫਲੋ ਚੁਣੋ. ਉਦਾਹਰਨ: PR ਵਰਣਨ + ਰਿਸਕ ਚੈਕੇਲਿਸਟ ਜਨਰੇਸ਼ਨ, ਟੈਸਟ-ਲਿਖਣ ਸਹਾਇਤਾ, ਰਿਲੀਜ਼ ਨੋਟਸ + ਚੇਂਜਲੌਗ ਡਰਾਫਟ ਕਰਨਾ।
ਹਫ਼ਤਾ 4: ਪਹਿਲਾਂ/ਬਾਅਦ ਤੁਲਨਾ ਕਰੋ ਅਤੇ ਆਦਤਾਂ ਲਾਕ ਕਰੋ. ਜੇ PR ਸਾਈਜ਼ ਘੱਟ ਹੋਈ ਅਤੇ ਸਮੀਖਿਆ ਦਾ ਸਮਾਂ ਬਿਨਾਂ ਵਧਦੇ incidents ਦੇ ਸੁਧਰ ਗਿਆ, ਤਾਂ ਇਹ ਜਾਰੀ ਰੱਖੋ। ਜੇ incidents ਵਧੇ, ਤਾਂ ਗਾਰਡਰੇਲਜ਼ ਜੋੜੋ (ਛੋਟੇ ਰੋਲਆਉਟ, ਵਧੀਆ ਟੈਸਟ, ਸਪਸ਼ਟ ਮਾਲਕੀ)।
ਡਿਲਿਵਰੀ ਦੀ ਉੱਚੀ ਗਤੀ ਉਹ ਸਮਾਂ ਹੈ ਜੋ ਖਿਆਲ ਦੇ ਫੈਸਲੇ ਤੋਂ ਲੈ ਕੇ ਇੱਕ ਭਰੋਸੇਯੋਗ ਬਦਲਾਅ ਦੇ ਯੂਜ਼ਰਾਂ ਲਈ ਲਾਈਵ ਹੋਣ ਅਤੇ ਉਨ੍ਹਾਂ ਤੋਂ ਸਪੱਸ਼ਟ ਫੀਡਬੈਕ ਮਿਲਣ ਤੱਕ ਲੱਗਦਾ ਹੈ। ਇਹ ਸਿਰਫ਼ “ਤੇਜ਼ੀ ਨਾਲ ਕੋਡ ਲਿਖਣਾ” ਨਹੀਂ ਹੈ, ਬਲਕਿ ਕਤਾਰਾਂ, ਮਨਜ਼ੂਰੀਆਂ ਅਤੇ ਹੇੰਡਆਫ਼ਸ ਨੂੰ ਘੱਟ ਕਰਕੇ build → release → observe → adjust ਲੂਪਾਂ ਨੂੰ ਤੰਗ ਕਰਨ ਉੱਤੇ ਧਿਆਨ ਦਿੰਦਾ ਹੈ।
ਇਹ ਚਾਰੋ ਮਿਲ ਕੇ ਇਹ ਰੋਕਾਂ ਪਕੜਨ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ ਕਿ ਤੁਸੀਂ ਕੇਵਲ ਇੱਕ ਨੰਬਰ ਵਧਾ ਕੇ ਦੂਜੇ ਵਿੱਚ ਛੱਪ ਨਾ ਰਹੋ।
ਸੰਯੋਜਨ ਓਵਰਹੈੱਡ ਟੀਮ ਦੀਆਂ ਸਰਹੱਦਾਂ ਅਤੇ ਡਿਪੈਂਡੈਂਸੀਜ਼ ਦੇ ਨਾਲ ਵੱਧਦਾ ਹੈ। ਹੋਰ ਹੇੰਡਆਫ਼ਜ਼ ਜ਼ਿਆਦਾ:
ਇੱਕ ਛੋਟੀ ਟੀਮ ਜਿੱਥੇ ਮਾਲਕੀ ਸਾਫ਼ ਹੋਵੇ ਉਹ ਅਕਸਰ ਫੈਸਲੇ ਲੋਕਲ ਰੱਖ ਕੇ ਛੋਟੇ ਇੰਕਰੀਮੈਂਟ ਵਿੱਖੇ ਸ਼ਿਪ ਕਰ ਸਕਦੀ ਹੈ।
ਇਸਦਾ ਅਰਥ ਹੈ ਕਿ ਇੱਕ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਜ਼ਿੰਮੇਵਾਰ ਮਾਲਕ ਇੱਕ ਸਲਾਈਸ ਨੂੰ ਆਇਡੀਆ ਤੋਂ ਪ੍ਰੋਡਕਸ਼ਨ ਤੱਕ ਚਲਾਉਂਦਾ ਹੈ, ਇਨਪੁੱਟ ਲੈਂਦਾ ਹੈ ਅਤੇ ਜਦੋਂ ਟਰੇਡ-ਆਫ਼ਸ ਆਉਂਦੇ ਹਨ ਤਾਂ ਫੈਸਲਾ ਕਰਦਾ ਹੈ। ਅਮਲੀ ਤੌਰ ਤੇ:
ਇਹ ਬੈਕ-ਅਤੇ-ਫੋਰਥ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ ਅਤੇ ਕੰਮ ਨੂੰ ਅੱਗੇ ਰੱਖਦਾ ਹੈ।
AI ਸਭ ਤੋਂ ਵਧੀਆ ਤਰੀਕੇ ਨਾਲ ਡਰਾਫਟ ਅਤੇ ਰੂਪਾਂਤਰਣਾਂ ਨੂੰ ਤੇਜ਼ ਕਰਦਾ ਹੈ, ਜਿਵੇਂ:
ਇਹ ਪ੍ਰਤੀ ਵਿਅਕਤੀ throughput ਵਧਾਉਂਦਾ ਹੈ ਅਤੇ ਦੁਬਾਰਾ ਕੰਮ ਘਟਾਉਂਦਾ ਹੈ—ਪਰ ਇਹ ਉਤਪਾਦੀ ਫੈਸਲੇ ਜਾਂ ਮਾਨਤਾ ਦੀ ਥਾਂ ਲਈ ਨਹੀਂ ਹੈ।
ਜੇ ਤੁਸੀਂ ਸਿੱਖਣ ਨੂੰ ਤੰਗ ਨਾ ਰੱਖੋ ਤਾਂ AI ਤੁਹਾਨੂੰ ਗਲਤ ਚੀਜ਼ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾ ਕੇ ਬੜੀ ਗਲਤੀ ਕਰਵਾ ਸਕਦਾ ਹੈ। ਵਧੀਆ ਅਭਿਆਸ AI-ਸਹਾਇਤ ਬਣਾਉਣ ਨੂੰ AI-ਸਹਾਇਤ ਸਿੱਖਣ ਨਾਲ ਜੋੜਦਾ ਹੈ:
ਮੁੱਲ ਦਿਓ learning velocity ਨੂੰ, ਨਾ ਕਿ ਸਿਰਫ਼ ਫੀਚਰ ਵਾਲੀ ਵਿਵਰਤਿ ਨੂੰ।
AI ਆਉਟਪੁੱਟ ਨੂੰ ਤੇਜ਼ ਜੂਨੀਅਰ ਸਹਿਯੋਗੀ ਵਜੋਂ ਸਮਝੋ: ਮਦਦਗਾਰ ਹੈ, ਪਰ ਕਦੇ-ਕਦੇ ਗਲਤ ਵੀ ਹੋ ਸਕਦਾ ਹੈ। ਗਾਰਡਰੇਲਜ਼ ਹਲਕੇ ਤੇ ਆਟੋਮੇਟਿਕ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ:
ਨਿਯਮ: AI ਡਰਾਫਟ ਕਰਦਾ ਹੈ; ਮਨੁੱਖ ਫੈਸਲਾ ਕਰਦੇ ਅਤੇ ਪ੍ਰਮਾਣਿਤ ਕਰਦੇ ਹਨ।
ਅਨੁਮੋਦਨ ਲੰਬੀਆਂ ਕਤਾਰਾਂ ਬਣਾਉਂਦੇ ਹਨ; guardrails ਉਨ੍ਹਾਂ ਦੀ ਥਾਂ 'ਤੇ ਕੰਮ ਕਰਦੇ ਹਨ:
ਇਹਨਾਂ ਨਾਲ ਸਧਾਰਨ ਕੰਮ “ਸੁਰੱਖਿਅਤ-ਡਿਫਾਲਟ” ਹੋ ਜਾਂਦੇ ਹਨ ਅਤੇ ਮਨੁੱਖੀ ਮਨਜ਼ੂਰੀਆਂ ਉਚ-ਖਤਰੇ ਵਾਲੇ ਕੰਮ ਲਈ ਰੱਖੋ।
ਇੱਕ thin slice ਇੱਕ ਛੋਟੀ, end-to-end ਯੂਨਿਟ ਹੈ ਜੋ ਕੀਮਤੀ ਹੈ (ਡਿਜ਼ਾਈਨ + ਬੈਕਐਂਡ + ਫਰੰਟਐਂਡ + ops ਜਿੱਥੇ ਲੋੜ ਹੋਵੇ) ਅਤੇ ਜੋ ਸ਼ਿਪ ਹੋ ਕੇ ਕੁਝ ਸਿੱਖਾਉਂਦੀ ਹੈ। ਉਦਾਹਰਨਾਂ:
POST /checkout/quote ਜੋ ਕੀਮਤ + ਟੈਕਸ ਵਾਪਸ ਕਰੇThin slices momentum ਬਰਕਰਾਰ ਰੱਖਦੇ ਹਨ ਕਿਉਂਕਿ ਤੁਸੀਂ ਜਲਦੀ ਪ੍ਰੋਡਕਸ਼ਨ ਤੇ ਪਹੁੰਚਦੇ ਹੋ ਅਤੇ ਫੀਡਬੈਕ ਲੈਂਦੇ ਹੋ।
ਇੱਕ ਬੇਸਲਾਈਨ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਕੁਝ ਹਫ਼ਤਿਆਂ ਲਈ ਹੇਠਾਂ ਦਿੱਤੇ weekly signals ਟਰੈਕ ਕਰੋ:
ਜੇ ਤੁਸੀਂ AI ਵਰਕਫਲੋਅਜ਼ ਸ਼ੁਰੂ ਕਰ ਰਹੇ ਹੋ ਤਾਂ ਹਫ਼ਤੇ-ਦਰ-ਹਫ਼ਤੇ ਦਿਖੋ ਕੀ ਬਦਲਿਆ—PR ਸਾਈਜ਼ ਘੱਟ ਹੋਈ? ਸਮੀਖਿਆ ਦਾ ਸਮਾਂ ਕਿਵੇਂ ਬਦਲਿਆ? ਘਟਨਾਵਾਂ ਵਧੀਆਂ? ਇਹ ਨਤੀਜੇ ਤੁਹਾਨੂੰ ਅਗਲਾ ਕਦਮ ਦੱਸਣਗੇ।