19 ਜੁਲਾ 2025·7 ਮਿੰਟ
ਫੀਚਰ ਅਨੁਸਾਰ AI ਨਿਰਮਾਣ ਲਾਗਤ ਅਨੁਮਾਨ: ਇੱਕ ਸਧਾਰਣ ਬਜਟ ਢੰਗ
AI ਨਿਰਮਾਣ ਲਾਗਤ ਦਾ ਅਨੁਮਾਨ ਆਸਾਨ: ਹਰ ਫੀਚਰ ਲਈ ਕ੍ਰੈਡਿਟ ਅਤੇ ਟੋਕਨ ਭਵਿੱਖਬਾਣੀ ਕਰੋ, ਪ੍ਰਾਂਪਟਾਂ ਦਾ ਸਕੋਪ ਸਪਸ਼ਟ ਕਰੋ, ਅਤੇ ਦੁਬਾਰਾ ਕੰਮ ਤੋਂ ਬਚੋ ਤਾਂ ਜੋ ਤੁਹਾਡੀ ਐਪ ਬਜਟ ਵਿੱਚ ਰਹੇ।
AI ਨਿਰਮਾਣ ਲਾਗਤ ਦਾ ਅਨੁਮਾਨ ਆਸਾਨ: ਹਰ ਫੀਚਰ ਲਈ ਕ੍ਰੈਡਿਟ ਅਤੇ ਟੋਕਨ ਭਵਿੱਖਬਾਣੀ ਕਰੋ, ਪ੍ਰਾਂਪਟਾਂ ਦਾ ਸਕੋਪ ਸਪਸ਼ਟ ਕਰੋ, ਅਤੇ ਦੁਬਾਰਾ ਕੰਮ ਤੋਂ ਬਚੋ ਤਾਂ ਜੋ ਤੁਹਾਡੀ ਐਪ ਬਜਟ ਵਿੱਚ ਰਹੇ।
AI ਮਦਦ ਨਾਲ ਬਣਾਉਣਾ ਸ਼ੁਰੂ ਵਿੱਚ ਸਸਤਾ ਲੱਗਦਾ ਹੈ, ਪਰ ਅਚਾਨਕ ਇਹ ਮਹਿੰਗਾ ਹੋ ਜਾਂਦਾ ਹੈ। ਏਸਦਾ ਕਾਰਨ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਇੱਕ ਫਿਕਸ ਕੀਮਤ ਲਈ ਨਹੀਂ ਭੁਗਤਾਨ ਕਰ ਰਹੇ — ਤੁਸੀਂ ਕੋਸ਼ਿਸ਼ਾਂ ਲਈ ਭੁਗਤਾਨ ਕਰ ਰਹੇ ਹੋ: ਸੁਨੇਹੇ, ਜਨਰੇਟ ਕੀਤਾ ਕੋਡ, ਸੋਧਾਂ, ਟੈਸਟਾਂ ਅਤੇ ਦੁਬਾਰਾ ਕੰਮ। ਜਦੋਂ ਯੋਜਨਾ ਅਸਪਸ਼ਟ ਹੁੰਦੀ ਹੈ, ਕੋਸ਼ਿਸ਼ਾਂ ਦੀ ਗਿਣਤੀ ਤੇਜ਼ੀ ਨਾਲ ਵੱਧਦੀ ਹੈ।
ਜ਼ਿਆਦਾਤਰ ਲਾਗਤ ਵਾਧੇ ਇੱਕੋ ਹੀ ਕੁਝ ਨਮੂਨਿਆਂ ਤੋਂ ਹੁੰਦੇ ਹਨ:
ਜਦੋਂ ਤੁਸੀਂ ਅਨੁਮਾਨ ਲਗਾਉਂਦੇ ਹੋ, ਤਾਂ ਇਹ ਬਖ਼ੂਬੀ ਦਰਸਾਓ ਕਿ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਕੀ ਬਜਟ ਕਰ ਰਹੇ ਹੋ:
ਕਿਸੇ ਵੀ ਅਨੁਮਾਨ ਨੂੰ ਇੱਕ ਨੰਬਰ ਦੀ ਥਾਂ ਇੱਕ ਰੇਂਜ ਸਮਝੋ। ਇੱਕ ਫੀਚਰ UI 'ਚ ਛੋਟਾ ਲੱਗ ਸਕਦਾ ਹੈ ਪਰ ਲਾਜਿਕ ਵਿੱਚ ਵੱਡਾ ਹੋ ਸਕਦਾ ਹੈ, ਜਾਂ ਉਲਟ। ਬੇਸਟ-ਕੇਸ ਇੱਕ ਮਜ਼ਬੂਤ ਪਹਿਲਾ ਡਰਾਫਟ ਹੁੰਦਾ ਹੈ। ਵੋਰਸਟ-ਕੇਸ ਕਈ ਸੋਧ ਲੂਪ ਹੁੰਦੇ ਹਨ।
ਇਸ ਗਾਈਡ ਦੀ ਬਾਕੀ ਭਾਗ ਫੀਚਰ ਬਕੇਟਾਂ 'ਤੇ ਆਧਾਰਿਤ ਹੈ: auth, CRUD, ਇੰਟੀਗ੍ਰੇਸ਼ਨ, ਅਤੇ UI ਰੀਡਿਜ਼ਾਈਨ। ਜੇ ਤੁਸੀਂ ਕਿਸੇ ਕਰੈਡਿਟ-ਆਧਾਰਿਤ vibe-coding ਪਲੇਟਫਾਰਮ ਵਰਗਾ Koder.ai (koder.ai) ਵਰਤ ਰਹੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਇਹ ਜਲਦੀ ਮਹਿਸੂਸ ਕਰੋ ਗੇ: "build a dashboard" ਨਾਲ ਸ਼ੁਰੂ ਕਰਕੇ ਬਾਅਦ ਵਿੱਚ roles, audit logs, ਅਤੇ ਨਵਾਂ ਲੇਆਉਟ ਜੋੜਨਾ ਉਨ੍ਹਾਂ ਨਿਯਮਾਂ ਨੂੰ ਪਹਿਲਾਂ ਲਿਖਣ ਨਾਲੋਂ ਕਾਫੀ ਜ਼ਿਆਦਾ ਕ੍ਰੈਡਿਟ ਖਾ ਲੈਂਦਾ ਹੈ।
ਲੋਕ ਤਿੰਨ ਵੱਖ-ਵੱਖ ਵਿਚਾਰਾਂ ਨੂੰ ਮਿਲਾ ਦਿੰਦੇ ਹਨ: ਟੋਕਨ, ਕ੍ਰੈਡਿਟ, ਅਤੇ ਬਿਲਡ ਸਟੈਪ। ਉਨ੍ਹਾਂ ਨੂੰ ਅਲੱਗ ਕਰਨ ਨਾਲ ਲਾਗਤਾਂ ਅਨੁਮਾਨੀ ਹੋਣਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ।
A token ਉਹ ਛੋਟਾ ਟੁਕੜਾ ਲਿਖਤ ਹੁੰਦਾ ਹੈ ਜੋ ਮਾਡਲ ਪੜ੍ਹਦਾ ਜਾਂ ਲਿਖਦਾ ਹੈ। ਤੁਹਾਡਾ ਪ੍ਰਾਂਪਟ ਟੋਕਨ ਵਰਤਦਾ ਹੈ, ਮਾਡਲ ਦਾ ਜਵਾਬ ਟੋਕਨ ਵਰਤਦਾ ਹੈ, ਅਤੇ ਲੰਬਾ ਚੈਟ ਇਤਿਹਾਸ ਵੀ ਟੋਕਨ ਵਰਤਦਾ ਹੈ ਕਿਉਂਕਿ ਮਾਡਲ ਨੂੰ ਓਹਨਾਂ ਨੂੰ ਫਿਰ ਤੋਂ ਪੜ੍ਹਨਾ ਪੈਂਦਾ ਹੈ।
A credit ਤੁਹਾਡੇ ਪਲੇਟਫਾਰਮ ਦੀ ਬਿਲਿੰਗ ਇਕਾਈ ਹੈ। Koder.ai ਵਰਗੇ ਟੂਲਾਂ 'ਤੇ, ਕ੍ਰੈਡਿਟ ਆਮ ਤੌਰ 'ਤੇ ਮਾਡਲ ਉਪਯੋਗਤਾਂ ਨਾਲ ਨਾਲ ਚੈਟ ਪਿੱਛੇ ਪਲੇਟਫਾਰਮ ਕੰਮ ਨੂੰ ਵੀ ਕਵਰ ਕਰਦੇ ਹਨ (ਉਦਾਹਰਨ ਲਈ, ਏਜੰਟ ਟਾਸਕ ਚਲਾਉਣਾ, ਫਾਇਲਾਂ ਬਣਾਉਣਾ, ਅਤੇ ਨਤੀਜੇ ਜਾਂਚਣਾ)। ਤੁਸੀਂ ਬਜਟ ਬਣਾਉਣ ਲਈ ਅੰਦਰਲੇ ਵੇਰਵੇ ਨਹੀਂ ਜਾਣਨ ਦੀ ਲੋੜ ਹੈ, ਪਰ ਤੁਹਾਨੂੰ ਇਹ ਸੂਝਣੀ ਚਾਹੀਦੀ ਹੈ ਕਿ ਉਪਯੋਗਤਾਂ ਵਧਾਉਂਦੀਆਂ ਕੀ ਹਨ।
A build step ਇੱਕ ਪਰਿਭਾਸ਼ਿਤ ਪਰਿਵਰਤਨ ਹੈ: "ਈਮੇਲ ਲੌਗਿਨ ਸ਼ਾਮਿਲ ਕਰੋ," "ਯੂਜ਼ਰਸ ਟੇਬਲ ਬਣਾਓ," ਜਾਂ "ਇਸ ਸਕ੍ਰੀਨ ਨੂੰ ਏਂਡਪੌਇੰਟ ਨਾਲ ਵਾਇਰ ਕਰੋ।" ਇੱਕ ਫੀਚਰ ਲਈ ਅਕਸਰ ਕਈ ਸਟੈਪ ਲੱਗਦੇ ਹਨ, ਅਤੇ ਹਰ ਸਟੈਪ ਕਈ ਮਾਡਲ ਕਾਲਾਂ ਨੂੰ ਟ੍ਰਿਗਰ ਕਰ ਸਕਦਾ ਹੈ।
ਉਪਯੋਗਤਾ ਤੇਜ਼ੀ ਨਾਲ ਵਧਦੀ ਹੈ ਜਦੋਂ:
ਛੋਟੇ ਪ੍ਰਾਂਪਟ ਬਦਲਾਅ ਲਾਗਤ ਨੂੰ ਬਦਲ ਦੇ ਸਕਦੇ ਹਨ ਕਿਉਂਕਿ ਓਹ ਰੀਟ੍ਰਾਇਜ਼ ਦੀ ਗਿਣਤੀ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ। "A complete auth system" ਵਿਕਲਪਾਂ ਨੂੰ ਬੁਲਾਂਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਨਹੀਂ ਮੰਗੇ। "Email and password only, no social login, exactly two screens" ਘੱਟ ਹਿਲਦੇ-ਡੁਲਦੇ ਹਿੱਸਿਆਂ ਨੂੰ ਕੱਟ ਦਿੰਦਾ ਹੈ।
ਇੱਕ ਨਿਯਮ ਜੋ ਕੰਮ ਕਰਦਾ ਹੈ: ਘੱਟ ਗਤੀਵਿਧੀਆਂ = ਘੱਟ ਰੀਟ੍ਰਾਇਜ਼।
"ਸਕ੍ਰੀਨ" ਜਾਂ "ਮੇਸੇਜ" ਵਿੱਚ ਅਨੁਮਾਨ ਲਗਾਉਣਾ ਬੰਦ ਕਰੋ। ਉਹਨਾਂ ਫੀਚਰਾਂ ਵਿੱਚ ਅਨੁਮਾਨ ਲਗਾਓ ਜਿਨ੍ਹਾਂ ਨੂੰ ਇਕ ਯੂਜ਼ਰ ਜ਼ਬਾਨ ਨਾਲ ਨਾਮ ਦੇਵੇਗਾ। ਇਹ ਬਜਟ ਨੂੰ ਨਤੀਜਿਆਂ ਨਾਲ ਜੋੜਦਾ ਹੈ, ਨਾ ਕਿ ਕਿੱਨਾ ਚੈਟੀਬੁਲਡ ਹੋ ਰਿਹਾ ਹੈ।
ਹਰ ਫੀਚਰ ਲਈ ਤਿੰਨ ਹਿੱਸਿਆਂ ਦਾ ਅਨੁਮਾਨ ਲਗਾਓ:
ਅਧਿਕਤਮ ਓਵਰਰਨ ਟੈਸਟਿੰਗ ਅਤੇ ਰੀਵਾਈਜ਼ਨ 'ਚ ਹੁੰਦੇ ਹਨ, ਪਹਿਲੇ ਡਰਾਫਟ ਵਿੱਚ ਨਹੀਂ।
ਹਰ ਹਿੱਸੇ ਲਈ ਇੱਕ ਰੇਂਜ ਵਰਤੋਂ: low (ਸਿੱਧਾ), typical (ਕੁਝ ਵਾਪਸੀ-ਫਿਰ), high (ਅਚਾਨਕ ਸਮੱਸਿਆਵਾਂ)। ਜੇ ਤੁਹਾਡਾ ਪਲੇਟਫਾਰਮ ਕ੍ਰੈਡਿਟ-ਆਧਾਰਿਤ ਹੈ ਤਾਂ ਕ੍ਰੈਡਿਟ ਵਿੱਚ ਟ੍ਰੈਕ ਕਰੋ। ਜੇ ਤੁਸੀਂ ਸਿੱਧਾ ਟੋਕਨ ਟ੍ਰੈਕ ਕਰਦੇ ਹੋ ਤਾਂ ਟੋਕਨ ਵਿੱਚ ਟ੍ਰੈਕ ਕਰੋ। ਮਕਸਦ ਇੱਕ ਐਸਾ ਅਨੁਮਾਨ ਹੈ ਜੋ ਹਕੀਕਤ ਬਦਲਣ 'ਤੇ ਸੱਚਾ ਰਹੇ।
ਦੋ ਲਾਈਨ ਜੋ ਆਪ-ਗਲਤੀ ਵੱਲੋਂ ਵੱਧ ਖਰਚ ਰੋਕਦੀਆਂ ਹਨ:
Unknowns buffer (10-20%) ਨੂੰ ਆਪਣੀ ਲਿਸਟ ਵਿੱਚ ਵੱਖਰਾ ਰੱਖੋ।
Later changes requested ਨੂੰ ਨਵੀਆਂ ਵਿਚਾਰਾਂ ਲਈ ਵੱਖਰਾ ਬਕੈਟ ਬਣਾਓ ਜੋ ਫੀਚਰ ਮਨਜ਼ੂਰ ਹੋਣ ਤੋਂ ਬਾਅਦ ਆਉਂਦੀਆਂ ਹਨ। ਜੇ ਤੁਸੀਂ ਇਹ ਵੱਖਰਾ ਨਹੀਂ ਰੱਖਦੇ ਤਾਂ ਅਸਲੀ ਅਨੁਮਾਨ ਨੂੰ ਸਾਰੇ ਤਬਦੀਲੀਆਂ ਦਾ ਦੋਸ਼ ਦੇਣਾ ਆਸਾਨ ਹੈ।
ਇੱਥੇ ਇੱਕ ਹਲਕਾ ਟੈਂਪਲੇਟ ਹੈ ਜੋ ਤੁਸੀਂ ਨਕਲ ਕਰ ਸਕਦੇ ਹੋ:
Feature: Password login
- Build: low 30 | typical 60 | high 120
- Test: low 15 | typical 30 | high 60
- Revise: low 10 | typical 20 | high 40
Subtotal (typical): 110
Buffer (15%): 17
Later changes (held): 50
ਹਰ ਫੀਚਰ ਲਈ ਇਹ ਦੁਹਰਾਓ (auth, CRUD, ਇਕ ਇੰਟੀਗ੍ਰੇਸ਼ਨ, UI ਰੀਫ੍ਰੈਸ਼). ਆਪਣੇ ਯੋਜਨਾਪੱਤਰ ਲਈ "typical" ਵਰਤੋਂ ਅਤੇ worst-case ਲਈ "high"।
Auth ਅਤੇ CRUD ਸਧਾਰਣ ਲੱਗਦੇ ਹਨ, ਪਰ ਜਦੋਂ ਸਕੋਪ ਅਸਪਸ਼ਟ ਹੁੰਦਾ ਹੈ ਉਹ ਮਹਿੰਗੇ ਹੋ ਜਾਂਦੇ ਹਨ। ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਮੈਨੂ ਵਾਂਗ ਵਰਤੋ: ਹਰ ਵਿਕਲਪ ਲਾਗਤ ਵਧਾਉਂਦਾ ਹੈ।
ਲਿਖੋ ਕਿ "ਕੰਮ ਖਤਮ ਕਿਵੇਂ ਹੋਵੇਗਾ"। ਸਭ ਤੋਂ ਵੱਡੀਆਂ ਡ੍ਰਾਇਵਰ ਹਨ ਲੌਗਿਨ ਵਿਧੀਆਂ ਦੀ ਗਿਣਤੀ ਅਤੇ ਪਰਮੀਸ਼ਨ ਪਾਥਾਂ ਦੀ ਗਿਣਤੀ।
ਨਿਰਧਾਰਤ ਰਹੋ:
ਜੇ ਤੁਸੀਂ ਕੇਵਲ ਕਹੋਂ "add auth" ਤਾਂ ਤੁਹਾਨੂੰ ਜਨਰਿਕ ਹੱਲ ਮਿਲੇਗਾ ਅਤੇ ਫਿਰ ਬਾਅਦ ਵਿੱਚ ਐਜ-ਕੇਸਾਂ ਲਈ ਪੈਸਾ ਖਰਚਣਾ ਪਵੇਗਾ। ਪਹਿਲਾਂ ਆਕਾਰ ਨਿਰਧਾਰਿਤ ਕਰਨਾ ਸਸਤਾ ਪੈਂਦਾ ਹੈ।
CRUD ਦੀ ਲਾਗਤ ਇਸ ਗੱਲ 'ਤੇ ਆਧਾਰਿਤ ਹੁੰਦੀ ਹੈ ਕਿ ਹਰ ਇਕ ਐਂਟਿਟੀ ਨੂੰ ਕਿੰਨੇ ਵਿਹਾਰ ਦੀ ਲੋੜ ਹੈ। ਪ੍ਰਯੋਗਿਕ ਮਾਡਲ: ਹਰ ਇੱਕ ਐਂਟਿਟੀ ਆਮ ਤੌਰ 'ਤੇ 3–6 ਸਕ੍ਰੀਂ ਦਰਜ ਕਰਦੀ ਹੈ (list, detail, create, edit, ਕਦੇ-ਕਦੇ admin ਜਾਂ audit views), ਨਾਲ API ਕੰਮ ਅਤੇ ਵੈਲਿਡੇਸ਼ਨ।
ਜਦੋਂ ਤੁਸੀਂ CRUD ਸਕੋਪ ਕਰੋ ਤਾਂ ਐਂਟਿਟੀਆਂ ਦਾ ਨਾਮ ਲਿਖੋ ਅਤੇ ਫੀਲਡਾਂ, ਕਿਸਮਾਂ ਅਤੇ ਵੈਲਿਡੇਸ਼ਨ ਨਿਯਮ (required, unique, ranges) ਸ਼ਾਮਿਲ ਕਰੋ। ਫਿਰ ਲਿਸਟ ਵਿਹਾਰ ਨਿਰਧਾਰਤ ਕਰੋ: ਫਿਲਟਰ, ਸੋਰਟ, pagination, ਅਤੇ search। "Search" ਇੱਕ ਸਰਲ contains ਫਿਲਟਰ ਹੋ ਸਕਦੀ ਹੈ ਜਾਂ ਕੁਝ ਹੋਰ ਭਾਰੀ ਗੱਲ।
ਫੈਸਲਾ ਕਰੋ ਕਿ admin ਸਕ੍ਰੀਨ ਯੂਜ਼ਰ ਸਕ੍ਰੀਨ ਤੋਂ ਵੱਖਰੀਆਂ ਹਨ ਜਾਂ ਨਹੀਂ। ਵੱਖਰੇ ਲੇਆਉਟ, ਵਾਧੂ ਫੀਲਡ, ਅਤੇ ਬਲਕ ਕਾਰਵਾਈਆਂ ਕੰਮ ਨੂੰ ਦੁੱਗਣਾ ਕਰ ਸਕਦੀਆਂ ਹਨ।
ਜਿਨ੍ਹਾਂ ਐਜ਼ਜ ਕੇਸਾਂ ਨਾਲ ਖਰਚ ਤੇਜ਼ੀ ਨਾਲ ਵਧਦਾ ਹੈ ਉਹ ਹਨ: row-level permissions, audit logs, CSV import/export, soft delete, ਅਤੇ approval workflows। ਇਹ ਸਭ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਪਰ ਜਦੋਂ ਤੁਸੀਂ ਪਹਿਲਾਂ ਤੈਅ ਕਰ ਲੈਂਦੇ ਹੋ ਤਾਂ ਬਜਟ ਅਨੁਮਾਨ ਜ਼ਿਆਦਾ ਅੰਦਾਜ਼ਯੋਗ ਰਹਿੰਦਾ ਹੈ।
ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਮਹਿੰਗੇ ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਕੰਮ ਲੁਕਾ ਕੇ ਰੱਖਦੇ ਹਨ। ਸੁਧਾਰ ਇਹ ਹੈ ਕਿ ਉਹਨਾਂ ਨੂੰ ਛੋਟੇ, ਟੈਸਟੇਬਲ ਟੁਕੜਿਆਂ ਵਿੱਚ ਤੋੜੋ ਬਜਾਏ "connect to X"। ਇਸ ਨਾਲ ਅਨੁਮਾਨ ਜ਼ਿਆਦਾ ਭਰੋਸੇਯੋਗ ਬਣਦਾ ਹੈ ਅਤੇ ਤੁਹਾਡਾ ਪ੍ਰਾਂਪਟ ਵੀ ਸਾਫ਼ ਹੁੰਦਾ ਹੈ।
ਇੱਕ ਮਜ਼ਬੂਤ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਸਕੋਪ ਆਮ ਤੌਰ 'ਤੇ ਸ਼ਾਮਿਲ ਹੁੰਦਾ ਹੈ:
ਪ੍ਰਾਂਪਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਡਾਟਾ ਕਾਂਟਰੈਕਟ ਨੂੰ ਲਾਕ ਕਰੋ। ਜਿਨ੍ਹਾਂ ਆਬਜੈਕਟਾਂ ਅਤੇ ਠੀਕ ਫੀਲਡਾਂ ਦੀ ਲੋੜ ਹੈ ਉਹ ਲਿਖੋ। "Sync customers" ਅਸਪਸ਼ਟ ਹੈ। "Sync Customer{id, email, status} ਅਤੇ Order{id, total, updated_at}" ਮਾਡਲ ਨੂੰ ਵਾਧੂ ਟੇਬਲਾਂ, ਸਕ੍ਰੀਨਾਂ ਅਤੇ ਏਂਡਪੌਇੰਟ ਬਣਾਉਣ ਤੋਂ ਰੋਕਦਾ ਹੈ।
ਅਗਲਾ, ਦਿਸ਼ਾ ਅਤੇ ਫ੍ਰਿਕਵੈਂਸੀ ਫੈਸਲਾ ਕਰੋ। ਇੱਕ-ਦਿਸ਼ਾ ਸਿੰਕ (ਕੇਵਲ ਇੰਪੋਰਟ) ਦੋ-ਦਿਸ਼ਾ ਸਿੰਕ ਨਾਲੋਂ ਕਾਫੀ ਸਸਤੀ ਹੈ ਕਿਉਂਕਿ ਦੋ-ਦਿਸ਼ਾ ਝਗੜੇ ਵਾਲੇ ਨਿਯਮ ਅਤੇ ਹੋਰ ਟੈਸਟ ਮੰਗਦੀ ਹੈ। ਜੇ ਦੋ-ਦਿਸ਼ਾ ਲਾਜ਼ਮੀ ਹੈ ਤਾਂ ਉੱਪਰ ਵਾਲੇ ਨਿਯਮ (source of truth, last-write-wins, ਜਾਂ manual review) ਪਹਿਲਾਂ ਚੁਣੋ।
ਫੇਲਿਊਰ ਲਈ ਯੋਜਨਾ ਬਣਾਓ ਜਿਵੇਂ ਕਿ ਇਹ ਪੱਕਾ ਹੈ। ਜਦੋਂ API ਡਾਊਨ ਹੋਵੇ ਤਾਂ ਕੀ ਹੋਵੇ? ਇਕ ਲੌਗ ਐਂਟਰੀ + ਅਲਰਟ ਅਤੇ ਇੱਕ ਮੈਨੂਅਲ "ਰੀ-ਰਨ ਸਿੰਕ" ਬਟਨ ਅਕਸਰ ਕਾਫੀ ਹੁੰਦਾ ਹੈ। ਇਸਨੂੰ ਨਿਊਨਤਮ ਰੱਖ ਕੇ ਤੁਸੀਂ ਅਣਚਾਹੀ ਓਪਸ ਸਿਸਟਮ ਲਈ ਪੈਸਾ ਖਰਚਣ ਤੋਂ ਬਚ ਸਕਦੇ ਹੋ।
ਅੰਤ ਵਿੱਚ, ਤੀਜੀ-ਪਾਰਟੀ ਅਨੋਖੇਪਣ ਅਤੇ ਟੈਸਟਿੰਗ ਲਈ 20–40% ਬਫਰ ਸ਼ਾਮਿਲ ਕਰੋ। ਭਾਵੇਂ ਇਹ "ਸਰਲ" APIs ਹੋਣ, pagination, ਅਨੋਖੇ enums, ਅਨਕੰਛਿਤ ਦਸਤਾਵੇਜ਼ ਅਤੇ rate limits ਆਮ ਹਨ।
UI ਕੰਮ ਉਹੀ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ ਬਜਟ ਚੁਪਚਾਪ ਲੀਕ ਹੁੰਦਾ ਹੈ। "Redesign" ਰੰਗਾਂ ਦੀ ਬਦਲਕ ਤੋਂ ਲੈ ਕੇ ਪੂਰੇ ਫਲੋ ਦੀ ਦੁਬਾਰਾ ਬਣਾਵਟ ਤੱਕ ਹੋ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਦੱਸੋ ਕਿ ਕੀ ਬਦਲ ਰਿਹਾ ਹੈ: layout, components, copy, ਜਾਂ user steps।
ਵਿਜ਼ੂਅਲ-ਕੇਵਲ ਬਦਲਾਵਾਂ ਨੂੰ ਵਿਹਾਰਕ ਬਦਲਾਵਾਂ ਤੋਂ ਅਲੱਗ ਰੱਖੋ। ਵਿਜ਼ੂਅਲ-ਕੇਵਲ ਸਿਰਫ਼ ਸਟਾਈਲ, ਸਪੇਸਿੰਗ ਅਤੇ ਕੰਪੋਨੈਂਟ ਸਟ੍ਰਕਚਰ ਨੂੰ ਛੂਹਦੇ ਹਨ। ਜਦੋਂ ਤੁਸੀਂ ਬਟਨ ਦੀ ਕਾਰਵਾਈ, ਵੈਲਿਡੇਸ਼ਨ ਜਾਂ ਡੇਟਾ ਲੋਡਿੰਗ ਬਦਲਦੇ ਹੋ, ਉਹ ਫੀਚਰ ਕੰਮ ਬਣ ਜਾਂਦਾ ਹੈ।
"ਸਾਰਾ ਐਪ ਰੀਡਿਜ਼ਾਈਨ" ਤੋਂ ਬਚੋ। ਇੱਕ-ਇੱਕ ਸਕ੍ਰੀਨ ਲਿਖੋ। ਜੇ ਤੁਸੀਂ ਪੇਜਾਂ ਦੀ ਸੂਚੀ ਨਹੀਂ ਲਿਖ ਸਕਦੇ ਤਾਂ ਤੁਸੀਂ ਅਨੁਮਾਨ ਨਹੀਂ ਲਗਾ ਸਕਦੇ।
ਸਕੋਪ ਸਪਸ਼ਟ ਅਤੇ ਸੰਕੁਚਿਤ ਰੱਖੋ:
ਇਹ ਪ੍ਰਾਂਪਟ ਮਾਡਲ ਨੂੰ ਪੂਰੇ ਕੋਡਬੇਸ 'ਤੇ ਡਿਜ਼ਾਈਨ ਅਨੁਮਾਨ ਕਰਨ ਤੋਂ ਰੋਕਦਾ ਹੈ, ਜੋ ਵਾਪਸੀ-ਚਿੰਨ੍ਹਦਾ ਹੈ।
UI ਬਦਲਾਵਾਂ ਲਈ ਆਮ ਤੌਰ 'ਤੇ ਘੱਟੋ-ਘੱਟ ਦੋ ਚੈੱਕ ਹੁੰਦੇ ਹਨ: ਡੈਸਕਟਾਪ ਅਤੇ ਮੋਬਾਇਲ। ਇੱਕ ਛੋਟੀ accessibility ਬੁਨਿਆਦੀ ਜਾਂਚ (ਕਾਂਟ੍ਰਾਸਟ, ਫੋਕਸ ਸਟੇਟਸ, ਕੀਬੋਰਡ ਨੈਵੀਗੇਸ਼ਨ) ਸ਼ਾਮਿਲ ਕਰੋ ਭਾਵੇਂ ਤੁਸੀਂ ਪੂਰੀ ਆਡਿਟ ਨਾ ਕਰ ਰਹੇ ਹੋ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਅਨੁਮਾਨ ਪদ্ধਤੀ ਹੈ:
(ਪੇਜਾਂ ਦੀ ਗਿਣਤੀ) x (ਬਦਲਾਅ ਦੀ ਗਹਿਰਾਈ) x (ਪਾਸਾਂ ਦੀ ਗਿਣਤੀ)
ਉਦਾਹਰਣ: 3 ਪੇਜ x ਮਧ्यम ਡੈਪਥ (ਨਵਾਂ ਲੇਆਉਟ + ਕੰਪੋਨੈਂਟ ਟਵੀਕ) x 2 ਪਾਸ = ਇੱਕ ਪੇਸ਼ਗੋਇ ਕ੍ਰੈਡਿਟ ਚੰਕ। ਜੇ ਤੁਸੀਂ ਅਨਬੋਰਡਿੰਗ ਫਲੋ ਵੀ ਬਦਲਦੇ ਹੋ ਤਾਂ ਉਸਨੂੰ ਵੱਖਰੇ ਲਾਈਨ ਆਈਟਮ ਵਜੋਂ ਟ੍ਰੀਟ ਕਰੋ।
ਕ੍ਰੈਡਿਟਾਂ ਨੂੰ ਕੰਟਰੋਲ ਕਰਨ ਦੀ ਸਭ ਤੋਂ ਸਸਤੀ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਮੰਗਣ ਤੋਂ ਪਹਿਲਾਂ ਤੈਅ ਕਰੋ ਕਿ ਤੁਸੀਂ ਕੀ ਚਾਹੁੰਦੇ ਹੋ। ਦੁਬਾਰਾ ਕੰਮ ਹੀ ਖਰਚ ਵਧਾਉਂਦਾ ਹੈ।
ਇੱਕ ਸਿੰਗਲ ਪੈਰਾ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਯੂਜ਼ਰ ਅਤੇ ਲਕਸ਼ ਦੱਸੇ। ਉਦਾਹਰਣ: "A small clinic receptionist logs in, adds patients, schedules appointments, and sees today's list." ਇਹ ਸਿਮਾਵਾਂ ਸੈੱਟ ਕਰਦਾ ਹੈ ਅਤੇ ਮਾਡਲ ਨੂੰ ਵਾਧੂ ਰੋਲ, ਸਕ੍ਰੀਨ ਜਾਂ ਵਰਕਫਲੋਜ ਸ਼ਾਮਿਲ ਕਰਨ ਤੋਂ ਰੋਕਦਾ ਹੈ।
ਫਿਰ ਉਤਪਾਦ ਨੂੰ ਸਕ੍ਰੀਨ ਅਤੇ ਕਾਰਵਾਈਆਂ ਵਜੋਂ ਵਰਣਨ ਕਰੋ, vague modules ਨਹੀਂ। "appointments module" ਦੀ ਥਾਂ "Calendar screen: create, reschedule, cancel, search" ਲਿਖੋ। ਇਹ ਕੰਮ ਗਿਣਤੀਯੋਗ ਬਣਾਉਂਦਾ ਹੈ।
ਕੇਵਲ ਜ਼ਰੂਰੀ ਡੇਟਾ ਸ਼ਾਮਿਲ ਕਰੋ। ਹਰ ਫੀਚਰ ਲਈ 2–4 Acceptance checks ਲਿਖੋ: "User can reset password via email" ਜਾਂ "Create appointment prevents double booking." ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਤ ਰਹੇ ਹੋ ਤਾਂ ਓਹ ਚੈੱਕਸ Planning Mode ਵਿੱਚ ਫ਼ਿਟ ਹੋ ਜਾਂਦੇ ਹਨ ਪਹਿਲਾਂ ਕੋਡ ਜਨਰੇਟ ਕਰਨ ਤੋਂ।
ਆਪਣਾ Out-of-scope ਸਪਸ਼ਟ ਰੱਖੋ: "no admin dashboard," "no payments," "no multi-language," "no external calendar sync." ਇਹ ਤੁਹਾਨੂੰ surprise "nice-to-have" ਕੰਮ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ।
ਛੋਟੇ ਟੁਕੜਿਆਂ ਵਿੱਚ ਬਣਾਉ ਅਤੇ ਹਰ ਟੁਕੜੇ ਤੋਂ ਬਾਅਦ ਮੁੜ ਅਨੁਮਾਨ ਕਰੋ। ਆਮ ਰਿਦਮ:
ਅ۱) ਇੱਕ ਸਕ੍ਰੀਨ ਜਾਂ ਏਂਡਪੌਇੰਟ ਜਨਰੇਟ ਕਰੋ ਬ۲) ਇਸਨੂੰ ਚਲਾਉ ਅਤੇ ਮੁੱਖ ਮੁੱਦਿਆਂ ਨੂੰ ਠੀਕ ਕਰੋ ਤ۳) ਫਿਰ ਅੱਗੇ ਵਧੋ
ਜੇ ਕੋਈ ਟੁਕੜਾ ਉਮੀਦ ਤੋਂ ਜ਼ਿਆਦਾ ਮਹਿੰਗਾ ਪੈ ਗਿਆ ਤਾਂ ਅੱਗੇ ਦੇ ਟੁਕੜੇ ਵਿਚੋਂ ਸਕੋਪ ਕੱਟੋ।
ਜਿਆਦਾਤਰ ਖਰਚ spike ਇਕ ਸੁਨੇਹੇ ਵਿੱਚ ਬਹੁਤ ਕੁਝ ਕਰਨ ਨਾਲ ਹੁੰਦੇ ਹਨ। ਮਾਡਲ ਨੂੰ ਇੱਕ ਟੀਮ ਮੈਂਬਰ ਸਮਝ ਕੇ ਛੋਟੇ, ਸਪੱਸ਼ਟ ਕਦਮਾਂ ਵਿੱਚ ਦਿਓ।
ਪਹਿਲਾਂ ਇੱਕ ਯੋਜਨਾ ਮੰਗੋ, ਫਿਰ ਇੱਕ ਛੋਟਾ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਸਟੈਪ, ਫਿਰ ਤੁਰੰਤ ਸਮੀਖਿਆ। ਇੱਕੇ ਪ੍ਰਾਂਪਟ ਵਿੱਚ ਯੋਜਨਾ, ਬਣਾਉ, ਟੈਸਟ, ਕਾਪੀਰਾਈਟ, ਅਤੇ ਸਟਾਈਲਿੰਗ ਮਿਲਾਉਣ ਨਾਲ ਲੰਬੇ ਆਊਟਪੁੱਟ ਅਤੇ ਗਲਤੀਆਂ ਹੋ ਸਕਦੀਆਂ ਹਨ।
ਸੰਦਰਭ ਨਿੱਘਾ ਰੱਖੋ; ਕੇਵਲ ਉਹੀ ਸੰਦਰਭ ਦਿਓ ਜੋ ਉਸ ਬਦਲਾਅ ਲਈ ਜਰੂਰੀ ਹੈ। Koder.ai ਵਰਤੋਂ ਵਾਲੇ ਯੂਜ਼ਰ ਖਾਸ ਫਾਇਲਾਂ ਚੁਣ ਸਕਦੇ ਹਨ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਨਾਮ ਨਾਲ ਦਰਸਾ ਸਕਦੇ ਹਨ। ਵਧੀਕ ਫਾਇਲਾਂ ਟੋਕਨ ਵਧਾਉਂਦੀਆਂ ਅਤੇ ਗੈਰ-ਸੰਬੰਧਤ ਖੇਤਰਾਂ 'ਤੇ ਸੋਧਾਂ ਖਿੱਚਦੀਆਂ ਹਨ।
ਛੋਟੇ ਡਿਫਸ ਮੰਗੋ: ਇੱਕ ਪ੍ਰਾਂਪਟ ਵਿੱਚ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਇੱਕ ਚੀਜ਼ ਬਦਲੋ। ਛੋਟੇ ਬਦਲਾਅ ਆਸਾਨੀ ਨਾਲ ਸਮੀਖਿਆ ਹੋ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਜੇ ਕੁਝ ਗਲਤ ਹੁੰਦਾ ਹੈ ਤਾਂ ਤੁਸੀਂ ਗੈਰ-ਸੰਬੰਧਤ ਕੰਮ ਦੁਬਾਰਾ ਨਹੀਂ ਭੁਗਤਦੇ।
ਛੋਟੇ ਕੰਮ ਕਰਨ ਦੀਆਂ ਨਿਯਮਾਵਲੀਆਂ:
ਜੇ ਦੂਜੀ ਕੋਸ਼ਿਸ਼ ਵੀ ਠੀਕ ਨਹੀਂ, ਤਾਂ ਦੋਸ਼ ਨਹੀਂ, ਇਨਪੁੱਟ ਬਦਲੋ: ਗੁੰਮ ਕੌਂਸਟਰੈਂਟ ਜੋੜੋ, ਵਿਰੋਧੀ ਮੰਗ ਹਟਾਓ, ਜਾਂ ਅਸਲ ਫੇਲ ਯਕੀਨੀ ਕੇਸ ਦਿਖਾਓ।
ਉਦਾਹਰਨ: ਤੁਸੀਂ "login + forgot password" ਅਤੇ ਇਕ ਵਧੀਆ ਲੇਆਉਟ ਚਾਹੁੰਦੇ ਹੋ। ਇਸਨੂੰ ਤਿੰਨ ਪ੍ਰਾਂਪਟਾਂ ਵਿੱਚ ਕਰੋ: (1) ਫਲੋਜ਼ ਅਤੇ ਲੋੜੀਂਦੀਆਂ ਸਕ੍ਰੀਨਾਂ ਦਾ ਢਾਂਚਾ, (2) ਸਿਰਫ auth ਫਲੋ ਲਾਗੂ ਕਰੋ, (3) UI spacing ਅਤੇ ਰੰਗ ਠੀਕ ਕਰੋ। ਹਰ ਕਦਮ ਸਸਤਾ ਅਤੇ ਸਮੀਖਿਆਯੋਗ ਰਹੇਗਾ।
ਜਿਆਦਾਤਰ ਓਵਰਰਨ ਵੱਡੇ ਫੀਚਰਾਂ ਕਰਕੇ ਨਹੀਂ ਹੁੰਦੇ; ਉਹ ਛੋਟੇ ਸਕੋਪ ਗੈਪਾਂ ਤੋਂ ਹੁੰਦੇ ਹਨ ਜੋ ਕਈ ਰਾਊਂਡ ਵਿੱਚ ਬਦਲ ਜਾਂਦੇ ਹਨ।
"ਡਨ" ਤੇ ਸਹਿਮਤੀ ਤੋਂ ਪਹਿਲਾਂ ਬਣਾਉਣਾ
ਜੇ ਤੁਸੀਂ acceptance checks ਬਿਨਾਂ ਕੋਡ ਜਨਰੇਟ ਕਰਦੇ ਹੋ ਤਾਂ ਤੁਹਾਨੂੰ ਦੁਬਾਰਾ ਲਿਖਵਾਉਣ ਲਈ ਭੁਗਤਾਨ ਕਰਨਾ ਪਵੇਗਾ। ਪਹਿਲਾਂ 3-5 checks ਲਿਖੋ।
ਅਸਪਸ਼ਟ ਸ਼ਬਦ ਵਰਤਣਾ
"Modern," "nice," ਅਤੇ "make it better" ਵਧੇਰੇ ਵਾਪਸੀ ਲਿਆਉਂਦੇ ਹਨ। ਹਟਾ ਕੇ ਵਿਸ਼ੇਸ਼ ਦਿਓ: "ਡੈਸਕਟਾਪ ਤੇ ਦੋ-ਕਾਲਮ, ਮੋਬਾਇਲ ਤੇ ਇਕ-ਕਾਲਮ" ਜਾਂ "ਪ੍ਰਾਇਮਰੀ ਬਟਨ ਦਾ ਰੰਗ #1F6FEB"।
ਇੱਕ ਪ੍ਰਾਂਪਟ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਫੀਚਰ ਭਰਨਾਂ
"Add auth, add billing, add admin dashboard" ਬਹੁਤ ਕੁਝ ਇੱਕੱਠੇ ਕਰਨ ਨਾਲ ਬਦਲਾਅ ਨੂੰ ਟ੍ਰੈਕ ਕਰਨਾ ਔਖਾ ਹੋ ਜਾਂਦਾ ਹੈ। ਇੱਕ-ਇੱਕ ਫੀਚਰ ਕਰੋ ਅਤੇ ਫਾਇਲਾਂ 'ਤੇ ਛੋਟਾ ਸਾਰ ਲਵੋ।
ਡਾਟਾ ਮਾਡਲ ਨੂੰ ਦੇਰ ਨਾਲ ਬਦਲਣਾ
ਬਾੌਚ-ਟੇਬਲਾਂ ਦਾ ਨਾਮ ਬਦਲਣਾ, ਰਿਲੇਸ਼ਨਸ਼ਿਪਾਂ ਤਬਦੀਲ ਕਰਨੀ ਜਾਂ IDs ਸਵਿੱਚ ਕਰਨਾ UI, API, ਅਤੇ ਮਾਈਗ੍ਰੇਸ਼ਨਜ਼ 'ਤੇ ਸੋਧ ਮੰਗਦਾ ਹੈ। ਕੋਰ ਐਂਟਿਟੀ ਨੂੰ ਪਹਿਲਾਂ ਲਾਕ ਕਰੋ, ਹਾਲਾਂਕਿ ਕੁਝ ਫੀਲਡ "ਭਵਿੱਖ" ਲਈ ਛੱਡੀ ਜਾ ਸਕਦੀਆਂ ਹਨ।
ਟੈਸਟਿੰਗ ਨੂੰ ਅੰਤ ਤੱਕ ਛੱਡਣਾ
ਬੱਗਸ regenerate-fix-regenerate ਚੱਕਰ ਬਣਾਉਂਦੇ ਹਨ। ਹਰ ਫੀਚਰ ਲਈ ਇੱਕ ਛੋਟਾ ਟੈਸਟ ਸੈੱਟ ਮੰਗੋ, ਨਾ ਕਿ ਇਕ ਵੱਡੀ ਟੈਸਟ ਪਾਸ ਬਾਅਦ ਵਿੱਚ।
ਇੱਕ ਵਾਸਤਵਿਕ ਉਦਾਹਰਣ: ਤੁਸੀਂ Koder.ai ਨੂੰ "make the CRM better" ਕਹਿੰਦੇ ਹੋ ਅਤੇ ਇਹ ਲੇਆਉਟ, ਫੀਲਡਾਂ ਦੇ ਨਾਮ ਅਤੇ ਐਂਡਪੌਇੰਟ ਸੋਧ ਦਿਆਂਦਾ ਹੈ ਇੱਕ ਵਾਰੀ। ਫਿਰ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਟੁੱਟ ਜਾਂਦੀ ਹੈ ਅਤੇ ਤੁਸੀਂ ਸਿਰਫ਼ ਇਹ ਖੋਜਣ ਲਈ ਕ੍ਰੈਡਿਟ ਖਰਚਦੇ ਹੋ ਕਿ ਕੀ ਬਦਲਿਆ। ਜੇ ਤੁਸੀਂ ਕਹੋ: "ਡੇਟਾ ਮਾਡਲ ਨਾ ਛੁਹੋ, ਸਿਰਫ਼ ਲਿਸਟ ਪੇਜ ਅੱਪਡੇਟ ਕਰੋ, API ਰੂਟ ਨਾ ਛੁਹੋ, ਅਤੇ ਇਹ 4 ਚੈਕ ਪਾਸ ਕਰਨੇ ਹਨ," ਤਾਂ ਤੁਸੀਂ churn ਘਟਾਉਦੇ ਹੋ ਅਤੇ ਲਾਗਤ ਸਥਿਰ ਰੱਖਦੇ ਹੋ।
ਬਜਟਿੰਗ ਨੂੰ ਇਕ ਛੋਟੇ ਪ੍ਰੋਜੈਕਟ ਦੀ ਤਰ੍ਹਾਂ ਸੋਚੋ; ਇੱਕ 2-ਮਿੰਟ ਚੈੱਕ ਜ਼ਿਆਦਾਤਰ ਓਵਰਸਪੈਂਡ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਫੜ ਲੈਂਦੀ ਹੈ।
ਇਨ੍ਹਾਂ ਚੀਜ਼ਾਂ ਨੂੰ ਜਾਂਚੋ ਅਤੇ ਕੋਈ ਵੀ "ਨਹੀਂ" ਹੋਵੇ ਤਾਂ ਉਸਨੂੰ ਠੀਕ ਕਰੋ:
ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਤ ਰਹੇ ਹੋ ਤਾਂ ਹਰ ਚੰਕ ਨੂੰ ਇੱਕ snapshot ਬਿੰਦੂ ਸਮਝੋ: ਇੱਕ ਹਿੱਸਾ ਬਣਾਓ, ਟੇਸਟ ਕਰੋ, ਫਿਰ ਜਾਰੀ ਰੱਖੋ। Snapshots ਅਤੇ rollback ਖਾਸ ਕਰਕੇ ਡੇਟਾ ਮਾਡਲ ਸਾਂਝੇ-ਸੰਸਕਾਰ, ਵਿਆਪਕ UI ਰੀਫੈਕਟਰ, ਜਾਂ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਰੀਰਾਈਟ ਤੋਂ ਪਹਿਲਾਂ ਬਹੁਤ ਮੁੱਲਵਾਨ ਹੁੰਦੇ ਹਨ।
ਸਰਲ ਉਦਾਹਰਣ: ਬਦਲੇ ਦੇ ਮਤਲਬ ਨਾਲ ਨਾ ਪੁੱਛੋ "Build user management"; ਇਸ ਦੀ ਥਾਂ "Email login only, password reset included, no social login, admin can deactivate users, must have tests for login and reset." ਇਹ ਚੈੱਕਸ ਰੀਟ੍ਰਾਇਜ਼ ਘਟਾਉਂਦੇ ਹਨ, ਅਤੇ ਰੀਟ੍ਰਾਇਜ਼ ਹੀ ਟੋਕਨ ਅਤੇ ਕ੍ਰੈਡਿਟ ਬਜਟ ਲੈ ਜਾਂਦੇ ਹਨ।
ਲਾਗਤ ਇਕ ਰੇਂਜ ਦੇ ਤੌਰ ਤੇ ਬਜਟ ਕਰੋ ਕਿਉਂਕਿ ਤੁਸੀਂ ਇੱਕ ਨਿਰਧਾਰਤ ਫੀਚਰ ਕੀਮਤ ਦੇ ਲਈ ਨਹੀਂ, ਬਲਕਿ ਕੋਸ਼ਿਸ਼ਾਂ ਲਈ ਪੈਸਾ ਦੇ ਰਹੇ ਹੋ। ਖਰਚ ਵਧਣ ਦੇ ਕਾਰਨ ਹਨ:
ਇੱਕ “ਛੋਟਾ” UI ਬਦਲਾਅ ਮਹਿੰਗਾ ਪੈ ਸਕਦਾ ਹੈ ਜੇ ਇਹ ਤਰਕ, ਡੇਟਾ ਜਾਂ ਫਲੋ ਨੂੰ ਬਦਲ ਦੇਵੇ।
ਟੋਕਨ ਉਹ ਛੋਟੇ-ਛੋਟੇ ਟੁਕੜੇ ਹੁੰਦੇ ਹਨ ਜੋ ਮਾਡਲ ਪੜ੍ਹਦਾ ਜਾਂ ਲਿਖਦਾ ਹੈ (ਤੁਹਾਡਾ ਪ੍ਰਾਂਪਟ, ਉਸ ਦਾ ਆਉਟਪੁੱਟ, ਅਤੇ ਕੋਈ ਚੈਟ ਇਤਿਹਾਸ)।
ਕ੍ਰੈਡਿਟ ਤੁਹਾਡੇ ਪਲੇਟਫਾਰਮ ਦੀ ਬਿਲਿੰਗ ਇਕਾਈ ਹੁੰਦੀ ਹੈ (ਅਕਸਰ ਮਾਡਲ ਉਪਯੋਗ ਅਤੇ ਪਲੇਟਫਾਰਮ ਦੇ ਕੰਮ ਜਿਵੇਂ ਏਜੰਟ ਟਾਸਕ, ਫਾਇਲ ਬਣਾਉਣਾ ਆਦਿ ਸ਼ਾਮਲ)।
ਬਿਲਡ ਸਟੇਪ ਉਹ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਪਰਿਵਰਤਨ ਹੁੰਦਾ ਹੈ: “ਈਮੇਲ ਲੌਗਿਨ ਸ਼ਾਮਿਲ ਕਰੋ”, “ਯੂਜ਼ਰਸ ਟੇਬਲ ਬਣਾਓ”, ਜਾਂ “ਇਸ ਸਕ੍ਰੀਨ ਨੂੰ ਏਂਡਪੌਇੰਟ ਨਾਲ ਜੁੜੋ”। ਇਕ ਫੀਚਰ ਅਕਸਰ ਕਈ ਸਟੇਪਾਂ ਦੀ ਲੋੜ ਰੱਖਦਾ ਹੈ, ਅਤੇ ਹਰ ਸਟੇਪ ਕਈ ਮਾਡਲ ਕਾਲਾਂ ਚਲਾ ਸਕਦਾ ਹੈ।
ਹੋਵੇਂ ਕਿ ਉਪਭੋਗਤਾ ਮੂੰਹੋਂ ਨਾਮ ਲਏ ਬਿਨਾਂ ਨਾ ਅੰਦਾਜ਼ਾ ਲਗਾਓ — ਜਿਵੇਂ “ਪਾਸਵਰਡ ਲੌਗਿਨ”, “ਕਿਰਪਾ ਕਰਕੇ ਕਰਮਚਾਰੀ ਦੀ ਸੂਚੀ”, “ਐਸੈਟ ਅਸਾਈਨ” — ਬਜਾਏ "ਸਕ੍ਰੀਨ" ਜਾਂ "ਮੇਸੇਜ" ਦੀ ਗਿਣਤੀ ਦੇ। ਹਰ ਫੀਚਰ ਲਈ ਤਿੰਨ ਹਿੱਸਿਆਂ ਦਾ ਬਜਟ ਬਣਾਓ:
ਫਿਰ ਹਰ ਹਿੱਸੇ ਲਈ Low/Typical/High ਰੇਂਜ ਦਿਓ ਅਤੇ ਜੋੜੋ।
ਦੋ ਵੱਖਰੇ ਲਾਇਨਾਂ ਜੋ ਆਮ ਤੌਰ ਤੇ ਸਹਾਇਕ ਰਹਿੰਦੀਆਂ ਹਨ:
Unknowns buffer (10–20%): ਇਸਨੂੰ ਆਪਣੀ ਲਿਸਟ ਵਿੱਚ ਵੱਖਰਾ ਰੱਖੋ, ਛੁਪਾਓ ਨਹੀਂ।
Later changes requested: ਨਵੀਆਂ ਵਿਚਾਰਾਂ ਲਈ ਵੱਖਰਾ ਬੱਡਲ (ਫੀਚਰ ਮਨਜ਼ੂਰ ਹੋਣ ਤੋਂ ਬਾਅਦ)। ਇਹ ਵੱਖਰਾ ਨਾ ਰੱਖਣ ਨਾਲ ਤੁਸੀਂ ਆਖ਼ਰਕਾਰ ਮੂਲ ਅਨੁਮਾਨ ਨੂੰ ਦੋਸ਼ੀ ਹੋਵੋਗੇ।
"ਡਨ" ਦਾ ਮਤਲਬ auth ਲਈ ਕੀ ਹੈ ਇਹ ਲਿਖੋ। ਸਭ ਤੋਂ ਵੱਡੇ ਖਰਚ-ਚਲਾਉਣ ਵਾਲੇ ਹਨ:
ਜੇ ਤੁਸੀਂ ਸਿਰਫ "add auth" ਕਹਿੰਦੇ ਹੋ ਤਾਂ ਤੁਹਾਨੂੰ ਜਨਰਿਕ ਹੱਲ ਮਿਲੇਗਾ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਏਡ-ਆਨ ਲਈ ਪੈਸਾ ਖਰਚਣਾ ਪਵੇਗਾ। ਇੱਕ ਵਿਧੀ (email/password) ਅਤੇ 1–2 ਰੋਲ ਨਿਰਧਾਰਿਤ ਕਰਨ ਨਾਲ ਲਾਗਤ ਅਨੁਮਾਨ ਸਥਿਰ ਰਹਿਣਗਾ।
CRUD ਦੀ ਲਾਗਤ ਵਿਹਾਰ ਤੇ ਟ੍ਰੈਕ ਹੁੰਦੀ ਹੈ, ਸਿਰਫ ਟੇਬਲਾਂ ਤੇ ਨਹੀਂ। ਹਰ ਐਂਟਿਟੀ ਲਈ ਇਹ ਨਿਰਧਾਰਿਤ ਕਰੋ:
CSV ਆਯਾਤ/ਨਿਰਯਾਤ, ਆਡੀਟ ਲੌਗ, ਸੋਫ਼ਟ ਡੀਲੀਟ ਅਤੇ ਮੰਜੂਰੀ ਵਰਕਫਲੋਜ਼ ਜਿਹੜੇ ਐਡ ਹੋਣਗੇ ਉਹਨਾਂ ਨੂੰ ਵੱਖਰੇ ਲਾਈਨ ਆਈਟਮ ਵਜੋਂ ਬਜਟ ਕਰੋ।
ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਅਕਸਰ ਮਹਿੰਗੀ ਲੱਗਣਦੀ ਹੈ ਕਿਉਂਕਿ ਉਨ੍ਹਾਂ ਵਿੱਚ ਲੁੱਕਿਆ ਹੋਇਆ ਕੰਮ ਹੁੰਦਾ ਹੈ। ਇਸਨੂੰ چھੋਟੇ, ਟੈਸਟੇਬਲ ਹਿੱਸਿਆਂ ਵਿੱਚ ਤੋੜੋ ਨਾ ਕਿ "connect to X" ਜਿਹਾ ਵਿਸ਼ਾਲ ਕਮਾਂਡ ਦਿਓ। ਇੱਕ ਪक्का ਸਕੋਪ ਆਮ ਤੌਰ 'ਤੇ ਸ਼ਾਮਿਲ ਕਰਦਾ ਹੈ:
ਜਨਰੇਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਡਾਟਾ ਕਾਂਟਰੈਕਟ ਲਾਕ ਕਰੋ: ਕਿਹੜੇ ਆਬਜੈਕਟ ਅਤੇ ਠੀਕ ਫੀਲਡ ਚਾਹੀਦੀਆਂ ਹਨ। "Sync customers" ਅਸਪਸ਼ਟ ਹੈ; ਪਰ "Sync Customer{id, email, status} ਅਤੇ Order{id, total, updated_at}" ਮਾਡਲ ਨੂੰ ਜ਼ਰੂਰੀ ਗੱਲਾਂ ਹੀ ਬਣਾਉਣ 'ਤੇ ਰੱਖਦਾ ਹੈ।
UI ਕੰਮ ਅਕਸਰ ਬਜਟ ਵਾਹੀ-ਵਾਹੀ ਲੀਕ ਹੁੰਦੇ ਹਨ। "Redesign" ਦੇ ਮਤਲਬ ਨੂੰ ਸਪਸ਼ਟ ਕਰੋ: layout, components, copy, ਜਾਂ user steps। ਵਿਜ਼ੂਅਲ-ਕੇਵਲ ਬਦਲਾਵਾਂ ਨੂੰ ਵਿਹਾਰਕ ਬਦਲਾਵਾਂ ਤੋਂ ਅਲੱਗ ਰੱਖੋ।
ਸਕੋਪ ਨੂੰ ਪੇਜ ਲਿਸਟ ਵਾਂਗ ਤੈਅ ਕਰੋ:
UI ਚੇਕਾਂ ਦੋ ਵਾਰ ਆਮ ਹਨ: ਡੈਸਕਟਾਪ ਅਤੇ ਮੋਬਾਇਲ। ਇਕ ਛੋਟੀ accessibility ਜਾਂਚ (ਕਾਂਟ੍ਰਾਸਟ, ਫੋਕਸ ਸਟੇਟਸ, ਕੀਬੋਰਡ ਨੈਵੀਗੇਸ਼ਨ) ਰੱਖੋ ਭਾਵੇਂ ਤੁਸੀਂ ਪੂਰਾ ਆਡੀਟ ਨਾ ਕਰ ਰਹੇ ਹੋ।
ਸਭ ਤੋਂ ਸਸਤੀ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਮਾਡਲ ਨੂੰ ਬਿਲਡ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਉਹ ਚਾਹੁੰਦੇ ਹੋ ਇਹ ਤੈਅ ਕਰ ਲਵੋ। ਦੁਬਾਰਾ ਕੰਮ ਖਰਚ ਵੱਧਾਉਂਦਾ ਹੈ।
ਇੱਕ ਛੋਟੀ ਪੈਰਾ ਦਿੱਤੋ ਜੋ ਯੂਜ਼ਰ ਅਤੇ ਉਦੇਸ਼ ਦੱਸੇ। ਉਦਾਹਰਣ: "ਇੱਕ ਨਿੱਕੀ ਕਲਿਨਿਕ ਦਾ ਰਿਸੈਪਸ਼ਨਿਸਟ ਲੌਗਿਨ ਕਰਦਾ ਹੈ, ਮਰੀਜ਼ ਜੋੜਦਾ ਹੈ, ਮਿਲਾਪ ਕਰਦਾ ਹੈ, ਅਤੇ ਅੱਜ ਦੀ ਸੂਚੀ ਵੇਖਦਾ ਹੈ." ਇਹ ਸੀਮਾਵਾਂ ਸੈੱਟ ਕਰਦਾ ਹੈ ਅਤੇ ਮਾਡਲ ਨੂੰ ਵੱਧ ਸਕ੍ਰੀਨਾਂ ਜਾਂ ਰੋਲ ਬਣਾਉਣ ਤੋਂ ਰੋਕਦਾ ਹੈ।
ਫਿਰ ਉਤਪਾਦ ਨੂੰ ਸਕ੍ਰੀਨ ਅਤੇ ਐਕਸ਼ਨਾਂ ਵਜੋਂ ਵੇਰਵਾ ਕਰੋ, ਨਾ ਕਿ ਵਿਗਿਆਨਿਕ ਮੋਡੀਊਲ ਵਜੋਂ। ਡੇਟਾ ਲੋੜਾਂ ਕੇਵਲ ਜਰੂਰੀ ਰਹਿਣ: ਹਰ ਫੀਚਰ ਲਈ 2–4 Acceptance checks ਲਿਖੋ (ਜਿਵੇਂ "ਯੂਜ਼ਰ ਈਮੇਲ ਰਾਹੀਂ password reset ਕਰ ਸਕਦਾ ਹੈ"), ਅਤੇ Out of scope ਆਈਟਮ ਲਿਖੋ ("ਕੋਈ ਅਡਮਿਨ ਡੈਸ਼ਬੋਰਡ ਨਹੀਂ", "ਕੋਈ ਭੁਗਤਾਨ ਨਹੀਂ")।
ਛੋਟੇ ਟੁਕੜੇ ਬਣਾਓ ਅਤੇ ਹਰ ਟੁਕੜੇ ਬਾਅਦ ਮੁੜ ਅਨੁਮਾਨ ਕਰੋ: ਇੱਕ ਸਕਰੀਨ ਜਾਂ ਏਂਡਪੌਇੰਟ ਜਨਰੇਟ ਕਰੋ, ਟੈਸਟ ਕਰੋ, ਫਿਰ ਅਗਲੇ 'ਤੇ ਜਾਓ। ਜੇ ਕੋਈ ਟੁਕੜਾ ਉਮੀਦ ਤੋਂ ਜ਼ਿਆਦਾ ਖਚ ਕਰਦਾ ਹੈ ਤਾਂ ਅਗਲੇ ਨੂੰ ਕੱਟੋ ਜਾਂ ਸਕੋਪ ਘਟਾਓ।
ਜ਼ਿਆਦਾਤਰ ਖਰਚ ਉਠਾਉਣ ਵਾਲੇ ਕਾਰਨ ਇੱਕ ਹੀ ਸੁਨੇਹੇ ਵਿੱਚ ਬਹੁਤ ਕੁਝ ਕਰਵਾਉਣਾ ਹੈ। ਮਾਡਲ ਨੂੰ ਇੱਕ ਸਾਥੀ ਵਾਂਗ ਸਮਝੋ: ਛੋਟੇ, ਸਪਸ਼ਟ ਕਦਮਾਂ ਵਿੱਚ ਬ੍ਰੀਫ਼ ਕਰੋ।
ਕਦੇ-ਕਦੇ ਕੰਮ ਨੂੰ ਇੱਕ ਪ੍ਰਾਂਪਟ ਵਿੱਚ ਪਲਾਨ, ਬਿਲਡ, ਟੈਸਟ, ਕਾਪੀਰਾਈਟ ਅਤੇ ਸਟਾਈਲਿੰਗ ਇਕੱਠੇ ਮੰਗਣ ਨਾਲ ਲੰਬੇ ਆਊਟਪੁੱਟ ਅਤੇ ਗਲਤੀਆਂ ਆਉਂਦੀਆਂ ਹਨ।
ਸੰਦਰਭ ਘੱਟ ਰੱਖੋ — ਕੇਵਲ ਉਹੀ ਫਾਇਲਾਂ/ਸਕ੍ਰੀਨਾਂ ਦਿੱਤੀਆਂ ਜਿਨ੍ਹਾਂ ਦੀ ਲੋੜ ਹੈ। ਛੋਟੇ ਡਿਫਸ ਮੰਗੋ: ਇਕ ਪ੍ਰਾਂਪਟ ਇੱਕ ਚੀਜ਼ ਬਦਲੇ ਜਿਵੇਂ ਇੱਕ ਏਂਡਪੌਇੰਟ, ਇੱਕ ਫਾਰਮ, ਇੱਕ ਐਰਰ ਸਟੇਟ, ਜਾਂ ਇੱਕ ਸਕ੍ਰੀਨ।
ਸਲਾਹ-ਆਮ ਨਿਯਮ:
ਅਕਸਰ ਜ਼ਿਆਦਾ ਖਰਚ ਵੱਡੇ ਫੀਚਰਾਂ ਤੋਂ ਨਹੀਂ, ਬਲਕਿ ਛੋਟੇ ਸਕੋਪ ਗੈਪਾਂ ਤੋਂ ਹੁੰਦਾ ਹੈ ਜੋ ਵਾਪਸੀ-ਰਾਊਂਡਾਂ, ਵੱਧ ਜਨਰੇਟ ਕੀਤੇ ਕੋਡ, ਅਤੇ ਹੋਰ ਫਿਕਸਾਂ ਵਿੱਚ ਬਦਲ ਜਾਂਦੇ ਹਨ।
ਪੰਜ ਬਜਟ-ਖਰਾਬ ਕਰਨ ਵਾਲੀਆਂ ਗਲਤੀਆਂ ਅਤੇ ਉਨ੍ਹਾਂ ਦੇ ਬਦਲੇ ਕੀ ਕਰੋ:
ਬਿਨਾਂ "ਡਨ" ਤੇ ਸਹਿਮਤ ਹੋਏ ਬਿਲਡ ਕਰਨਾ
3–5 checks ਪਹਿਲਾਂ ਲਿਖੋ: ਉਪਭੋਗਤਾ ਕੀ ਕਰ ਸਕਦਾ ਹੈ, ਕਿਸ ਤਰ੍ਹਾਂ ਦੀਆਂ ਗਲਤੀਆਂ ਦਿਖਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ, ਅਤੇ ਕੀ ਡੇਟਾ ਸਟੋਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਅਸਪਸ਼ਟ ਸ਼ਬਦ ਵਰਤਨਾ
"ਮੋਡਰਨ", "ਸੁੰਦਰ", "ਹੋਰ ਬੇਹਤਰ ਬਣਾਓ" ਜਿਹੇ ਸ਼ਬਦ ਲੰਬੇ-ਵਾਪਸੀ ਦਿਓ। ਥਾਂ ਤੇ ਵਿਸ਼ੇਸ਼ ਦਿਓ: "ਡੈਸਕਟਾਪ ਤੇ ਦੋ-ਕਾਲਮ, ਮੋਬਾਇਲ ਤੇ ਇਕ-ਕਾਲਮ" ਜਾਂ "ਪ੍ਰਾਇਮਰੀ ਬਟਨ ਰੰਗ #1F6FEB"।
ਬਜਟਿੰਗ ਨੂੰ ਇੱਕ ਛੋਟੇ ਪ੍ਰੋਜੈਕਟ ਦੀ ਤਰ੍ਹਾਂ ਸੋਚੋ, ਇੱਕ ਜਾਦੂਈ ਪ੍ਰਾਂਪਟ ਨਾ। 2-ਮਿੰਟ ਦੀ ਤਰਕੀਬ ਜ਼ਿਆਦਾਤਰ ਠਹਿਰਾਓ ਸਮੱਸਿਆਵਾਂ ਫੜ ਲੈਂਦੀ ਹੈ।
ਇਨ੍ਹਾਂ ਚੀਜ਼ਾਂ ਨੂੰ ਜਾਂਚੋ ਅਤੇ ਜੇ ਹੁਣ ਵੀ "ਨਹੀਂ" ਹੈ ਤਾਂ ਉਸ ਨੂੰ ਅਗੇ ਤੋਂ ਠੀਕ ਕਰੋ:
ਇੱਕ ਛੋਟੀ, ਹਕੀਕਤੀ ਉਦਾਹਰਣ ਜੋ ਤੁਸੀਂ ਨਕਲ ਕਰ ਸਕਦੇ ਹੋ: ਅੱਖਰ-ਅੰਦਰੂਨੀ ਟੂਲ — ਲੌਗਿਨ, ਦੋ ਸਧਾਰਨ ਮੌਡੀਊਲ ਅਤੇ ਇੱਕ ਇੰਟੀਗ੍ਰੇਸ਼ਨ।
ਮੰਨ ਲਓ ਇੱਕ "ਬਿਲਡ ਸਾਈਕਲ": ਛੋਟੀ ਯੋਜਨਾ, ਕੋਡ ਜਨਰੇਟ/ਅਪਡੇਟ, ਤੇਜ਼ ਸਮੀਖਿਆ ਅਤੇ ਫਿਕਸ। ਤੁਹਾਡੇ ਕ੍ਰੈਡਿਟ ਜ਼ਿਆਦਾਤਰ ਇਹਨਾਂ ਸਾਈਕਲਾਂ ਦੀ ਗਿਣਤੀ ਅਤੇ ਹਰ ਸਾਈਕਲ ਦੀ ਵੱਡਾਈ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ।
ਫੀਚਰ ਲਿਸਟ:
ਇੱਕ-ਤਰੀਕੇ ਦਾ ਸਿੰਕ (ਇੰਪੋਰਟ ਕੇਵਲ) ਦੋ-ਤਰੀਕੇ ਨਾਲੋਂ ਕਾਫੀ ਸਸਤਾ ਹੈ। ਜੇ ਦੋ-ਤਰੀਕੇ ਦੀ ਲੋੜ ਹੈ ਤਾਂ ਸਰੋਤ-ਦਾ-ਸੱਚ ('source of truth') ਜਾਂ last-write-wins ਆਦਿ ਨਿਯਮ ਪਹਿਲਾਂ ਤੈਅ ਕਰੋ।
ਤ੍ਰਿਜੀ-ਪਾਰਟੀ ਜ਼ਟਿਲਤਾਵਾਂ ਲਈ 20–40% ਵਾਧੂ ਬਫਰ ਰੱਖੋ; pagination, ਅਨੋਖੇ enums ਅਤੇ ਅਸਮਾਨ ਦਸਤਾਵੇਜ਼ ਆਮ ਹਨ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਅੰਦਾਜ਼ਾ: (ਪੇਜਾਂ ਦੀ ਗਿਣਤੀ) x (ਬਦਲਾਅ ਦੀ ਗਹਿਰਾਈ) x (ਪਾਸਾਂ ਦੀ ਗਿਣਤੀ)। ਉਦਾਹਰਣ: 3 ਪੇਜਾਂ x ਮੱਧ ਗਹਿਰਾਈ x 2 ਪਾਸ = ਅਨੁਮਾਨਿਤ ਕ੍ਰੈਡਿਟ ਖਚ।
ਜੇ ਦੂਜੀ ਕੋਸ਼ਿਸ਼ ਵੀ ਗਲਤ ਰਹੇ ਤਾਂ ਬੰਦ ਕਰੋ ਅਤੇ ਇਨਪੁੱਟ ਬਦਲੋ — ਘੱਟ ਵੇਰਵਾ ਜੋੜੋ, ਟਕਰਾਅ ਹਟਾਓ, ਜਾਂ ਫੇਲ ਹੋਣ ਵਾਲਾ ਕੇਸ ਦਿਖਾਓ।
ਇੱਕ-ਇੱਕ ਫੀਚਰ ਕਰੋ ਅਤੇ ਫਾਇਲਾਂ ਤਬਦੀਲ ਹੋਣ ਦਾ ਸੰਖੇਪ ਮੰਗੋ।
ਡਾਟਾ ਮਾਡਲ ਨੂੰ ਦੇਰ ਨਾਲ ਬਦਲਣਾ
ਟੇਬਲਾਂ ਨੂੰ ਰੀਨੇਮ ਕਰਨਾ, ਰਿਲੇਸ਼ਨਸ਼ਿਪ ਬਦਲਣਾ ਜਾਂ IDs ਬਦਲਣਾ UI, API ਅਤੇ ਮਾਈਗ੍ਰੇਸ਼ਨਾਂ 'ਤੇ ਬਦਲਾਅ ਮੰਗਦਾ ਹੈ। کور ਐਂਟਿਟੀ ਨੂੰ ਪਹਿਲਾਂ ਲਾਕ ਕਰੋ।
ਅੰਤ ਤੱਕ ਟੈਸਟ ਨਾ ਕਰਨਾਂ
हर ਫੀਚਰ ਲਈ ਛੋਟੀ ਟੈਸਟ ਸੈੱਟ ਮੰਗੋ, ਨਾ ਕਿ ਇਕ ਵੱਡਾ ਟੈਸਟ ਬਾਅਦ ਵਿੱਚ।
ਉਦਾਹਰਣ: Koder.ai ਨੂੰ "CRM ਨੂੰ ਬਿਹਤਰ ਬਣਾਓ" ਕਹਿਣ ਨਾਲ ਵਿਰਲੇ ਫੀਚਰ ਇਕੱਠੇ ਬਦਲ ਜਾਂਦੇ ਹਨ—ਲੈਆਉਟ, ਫੀਲਡ ਰੀਨੇਮ, ਏਂਡਪੌਇੰਟ ਤਬਦੀਲ—ਜੋ ਇੰਟੈਗ੍ਰੇਸ਼ਨ ਹੀ ਤੋੜ ਦਿੰਦਾ ਹੈ। ਬਦਲੇ ਵਿੱਚ ਕਹੋ: "ਡੇਟਾ ਮਾਡਲ ਅਉਨਚੇਨਗਡ ਰੱਖੋ, ਕੇਵਲ ਲਿਸਟ ਪੇਜ ਅੱਪਡੇਟ ਕਰੋ, API ਰੂਟਾਂ ਨਾ ਛੁਹੋ, ਅਤੇ ਇਹ 4 ਚੈੱਕ ਪਾਸ ਕਰਨੇ ਹਨ" — ਇਸ ਤਰ੍ਹਾਂ ਚਰਨ ਘਟਦਾ ਹੈ ਅਤੇ ਲਾਗਤ ਸਥਿਰ ਰਹਿੰਦੀ ਹੈ।
ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਤ ਰਹੇ ਹੋ ਤਾਂ ਹਰ ਚੁੰਕ ਨੂੰ ਇੱਕ snapshot ਪੁਆਇੰਟ ਸਮਝੋ: ਇੱਕ ਹਿੱਸਾ ਜਨਰੇਟ ਕਰੋ, ਟੈਸਟ ਕਰੋ, ਫਿਰ ਜਾਰੀ ਰੱਖੋ। ਖਤਰਨਾਕ ਤਬਦੀਲੀਆਂ ਤੋਂ ਪਹਿਲਾਂ snapshots ਅਤੇ rollback ਸਭ ਤੋਂ ਕੀਮਤੀ ਹੁੰਦੇ ਹਨ।
| Feature | What's included | Low | Typical | High |
|---|
| Login + roles | Sign in, sign out, two roles (Admin, User), protected pages | 1 cycle | 2 cycles | 4 cycles |
| CRUD module 1 | "Employees" list, create/edit, basic validation, search | 2 cycles | 3 cycles | 6 cycles |
| CRUD module 2 | "Assets" list, create/edit, assign to employee, audit fields | 2 cycles | 4 cycles | 7 cycles |
| One integration | Send an event to an external service when an asset is assigned | 1 cycle | 2 cycles | 5 cycles |
ਸਖਤ checkpoints ਰੱਖਣ ਲਈ ਪ੍ਰਾਂਪਟ ਸੀਕਵੈਂਸ:
ਖਰਚ ਉਦੋਂ ਵੱਧਦੇ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਕੋਡ ਮੌਜੂਦ ਹੋਣ ਦੇ ਬਾਅਦ ਫੈਸਲੇ ਬਦਲਦੇ ਹੋ। ਆਮ ਟ੍ਰਿੱਗਰ: ਰੋਲ ਬਦਲਾਅ, ਦੇਰ ਨਾਲ ਫੀਲਡ ਜੋੜਨਾ, ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਐਰਰ, ਜਾਂ ਫਾਰਮਾਂ ਦੇ ਬਣਨ ਤੋਂ ਬਾਅਦ UI redesign।
ਅਗਲੇ ਕਦਮ: ਫੀਚਰ-ਦਰ-ਫੀਚਰ ਯੋਜਨਾ ਬਣਾਓ, ਸਾਈਕਲਾਂ ਵਿੱਚ ਬਣਾਓ, ਅਤੇ ਹਰ ਸਾਈਕਲ ਤੋਂ ਬਾਅਦ ਕ੍ਰੈਡਿਟ ਜਾਂਚੋ। ਖਤਰਨਾਕ ਤਬਦੀਲੀਆਂ ਤੋਂ ਪਹਿਲਾਂ snapshots ਲਵੋ ਤਾਂ ਕਿ ਤੁਹਾਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਰੋਲਬੈਕ ਕਰਨ ਦੀ ਸੁਵਿਧਾ ਹੋਵੇ ਅਤੇ ਪ੍ਰੋਜੈਕਟ ਤੁਹਾਡੇ typical ਰੇਂਜ ਵਿੱਚ ਰਹੇ।