ਐਪ ਸਪੈਸ ਵਿੱਚ ਪਾਬੰਦੀਆਂ ਅਤੇ ਨਾਨ-ਗੋਲ — ਦੁਬਾਰਾ ਕੰਮ (ਦੋਹਰਾ ਕਾਰਜ) ਰੋਕੋ

ਕਿਉਂ ਸਪੈਸ ਵਿੱਚ ਪਾਬੰਦੀਆਂ ਛੱਡਣ ਨਾਲ ਦੁਬਾਰਾ ਕੰਮ ਹੁੰਦਾ ਹੈ

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

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

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

ਇੱਕ ਸਧਾਰਣ ਉਦਾਹਰਨ: ਇੱਕ ਫਾਉਂਡਰ “appointments + reminders” ਮੰਗਦਾ ਹੈ। ਪਹਿਲੇ ਹਫ਼ਤੇ ਈਮੇਲ ਰਿਮਾਈਂਡਰ ਭੇਜੇ ਜਾਂਦੇ ਹਨ। ਦੂਜੇ ਹਫ਼ਤੇ ਉਹ ਕਹਿੰਦਾ ਹੈ ਕਿ ਉਨ੍ਹਾਂ ਨੂੰ SMS ਚਾਹੀਦਾ ਹੈ, ਪਰ SMS ਉਨ੍ਹਾਂ ਦੇ ਦੇਸ਼ ਵਿੱਚ ਮਨਾਹੀ ਹੈ ਜਾਂ ਇਹ ਬਜਟ ਤੋ ਵੱਧ ਹੋ ਜਾਂਦਾ ਹੈ। ਹੁਣ ਰਿਮਾਈਂਡਰ ਸਿਸਟਮ ਨੂੰ ਰੀਡਿਜ਼ਾਈਨ ਕਰਨਾ ਪੈਂਦਾ, ਸਕਰੀਨ ਬਦਲਦੇ ਹਨ, ਅਤੇ ਟੈਸਟ ਮੁੜ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ। ਰੀਵਰਕ ਖਰਾਬ ਕੋਡਿੰਗ ਕਰਕੇ ਨਹੀਂ ਸੀ — ਇਹ ਦੇਰ ਨਾਲ ਆਈਆਂ ਪਾਬੰਦੀਆਂ ਕਾਰਨ ਸੀ।

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

ਇਹ ਕਿਸੇ ਲੰਬੇ ਦਸਤਾਵੇਜ਼ ਦੀ ਲੋੜ ਨਹੀਂ — ਇੱਕ ਹਲਕੀ-ਫੁਲਕੀ ਸਪੈਸ ਵੀ ਜਿੱਥੇ ਗੱਲ ਮਹੱਤਵ ਦੀ ਹੋ ਉਥੇ ਕਠੋਰ ਹੋ ਸਕਦੀ ਹੈ। ਸ਼ੁਰੂ ਵਿੱਚ, ਇਹਨਾਂ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇਣੇ ਚਾਹੀਦੇ ਹਨ:

• ਕੀ ਫਿਕਸ ਹੈ (ਡੇਡਲਾਈਨ, ਬਜਟ, ਟੀਮ, ਰਿਵਿਊ ਕੈਡੰਸ)?
• ਟੈਕਨੀਕਲ ਤੌਰ 'ਤੇ ਕੀ ਫਿਕਸ ਹੈ (ਸਟੈਕ, ਹੋਸਟਿੰਗ, ਡੇਟਾ ਸਥਾਨ)?
• ਐਪ ਨੂੰ ਕੀ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ (ਨਾਨ-ਗੋਲ)?
• ਕੀ ਬਦਲ ਸਕਦਾ ਹੈ ਬਿਨਾਂ ਪੂਰੇ ਯੋਜਨਾ ਨੂੰ ਦੁਬਾਰਾ ਖੋਲ੍ਹਣ ਦੇ?

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

ਪਾਬੰਦੀਆਂ ਵਿ. ਨਾਨ-ਗੋਲ: ਇੱਕ ਮਿੰਟ ਵਿੱਚ ਫ਼ਰਕ

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

ਨਾਨ-ਗੋਲ ਸਾਫ਼ ਚੋਣ ਹਨ ਕਿ ਅਸੀਂ ਕੋਈ ਚੀਜ਼ ਨਹੀਂ ਬਣਾਉਂਦੇ। ਜੇ ਉਹ ਛੱਡ ਦਿੱਤੇ ਜਾਣ ਤਾਂ ਸਪੈਸ ਆਹਿਸਤਾ-ਆਹਿਸਤਾ ਵadh ਜਾਂਦਾ ਹੈ ਜਦ ਲੋਕ “ਛੋਟੀ” ਤਬਦੀਲੀਆਂ ਜੋੜਦੇ ਹਨ। ਇਹੀ ਤਰ੍ਹਾਂ ਸਕਰੀਨਾਂ, ਫਲੋਅਜ਼ ਅਤੇ ਡੇਟਾ ਮਾਡਲ ਮੁੜ-ਬਦਲ ਹੋ ਜਾਂਦੇ ਹਨ।

ਇੱਕ ਤੇਜ਼ ਨਿਯਮ: ਪਾਬੰਦੀਆਂ ਇਸ ਗੱਲ ਨੂੰ ਸੀਮਤ ਕਰਦੇ ਹਨ ਕਿ ਤੁਸੀਂ ਕਿਵੇਂ ਬਣਾਉਂਦੇ ਹੋ; ਨਾਨ-ਗੋਲ ਇਸ ਗੱਲ ਨੂੰ ਸੀਮਤ ਕਰਦੇ ਹਨ ਕਿ ਤੁਸੀਂ ਕੀ ਬਣਾਉਂਦੇ ਹੋ।

ਕੀ ਗਿਣਿਆ ਜਾਂਦਾ ਹੈ ਇੱਕ ਪਾਬੰਦੀ ਵਜੋਂ

ਪਾਬੰਦੀ ਉਹ ਜ਼ਰੂਰੀ ਗੱਲ ਹੈ ਜੋ ਬਿਨਾਂ ਕਿਸੇ ਅਸਲ ਫੈਸਲੇ (ਅਤੇ ਤਬਦੀਲੇ) ਦੇ ਨਾ ਬਦਲੇ।

ਉਦਾਹਰਣ:

• “ਅਸੀਂ 6 ਹਫ਼ਤਿਆਂ ਵਿੱਚ ਲਾਂਚ ਕਰਨਾ ਹੈ।”
• “ਬਜਟ $15k 'ਤੇ ਸੀਮਤ ਹੈ।”
• “ਇਹ ਸਿਰਫ EU ਵਿੱਚ ਚੱਲਣਾ ਚਾਹੀਦਾ ਹੈ ਡੇਟਾ ਰਹਾਇਸ਼ ਲਈ।”
• “Frontend React ਹੋਵੇ, backend Go, ਡੇਟਾਬੇਸ PostgreSQL ਹੋਵੇ।”

ਜਦੋਂ ਪਾਬੰਦੀ ਅਸਲ ਹੁੰਦੀ ਹੈ, ਉਸਨੂੰ ਇਕ ਐਸੇ ਵਾਕ ਵਿੱਚ ਲਿਖੋ ਜਿਸ 'ਤੇ ਕੋਈ ਗੱਲਬਾਤ ਨਾ ਕਰ ਸਕੇ। ਜੇ ਕਿਸੇ ਨੇ “ਸ਼ਾਇਦ” ਕਹਿ ਸਕਿਆ, ਤਾਂ ਉਹ ਅਜੇ ਪਾਬੰਦੀ ਨਹੀਂ।

ਕੀ ਗਿਣਿਆ ਜਾਂਦਾ ਹੈ ਇੱਕ ਨਾਨ-ਗੋਲ ਵਜੋਂ

ਨਾਨ-ਗੋਲ ਇੱਕ ਸਪਸ਼ਟ “ਅਸੀਂ ਇਹ ਨਹੀਂ ਕਰ ਰਹੇ” ਬਿਆਨ ਹੈ, ਭਾਵੇਂ ਇਹ ਲਾਭਦਾਇਕ ਲੱਗੇ। ਇਹ ਪਹਿਲੀ ਰਿਲੀਜ਼ ਦੀ ਰੱਖਿਆ ਕਰਦਾ ਹੈ।

ਉਦਾਹਰਣ:

• “v1 ਵਿੱਚ ਮੋਬਾਈਲ ਐਪ ਨਹੀਂ; ਕੇਵਲ ਵੈੱਬ।”
• “ਲਾਂਚ 'ਤੇ ਕੋਈ ਮਲਟੀ-ਲੈਂਗਵੇਜ ਸਹਾਇਤਾ ਨਹੀਂ।”
• “ਕੋਈ ਰੀਅਲ-ਟਾਈਮ ਚੈਟ ਨਹੀਂ; ਈਮੇਲ ਨੋਟੀਫਿਕੇਸ਼ਨ ਕਾਫੀ ਹਨ।”

ਨਾਨ-ਗੋਲ ਨਕਾਰਾਤਮਕਤਾ ਨਹੀਂ ਹਨ। ਉਹ ਮਹਿੰਗੀਆਂ ਭਟਕਣਾਂ ਤੋਂ ਬਚਾਉਂਦੇ ਹਨ। ਉਦਾਹਰਨ ਵਜੋਂ, “v1 ਵਿੱਚ ਕੋਈ ਕਸਟਮ ਰੋਲ ਨਹੀਂ” ਕਈ ਹਫ਼ਤੇ ਬਚਾ ਸਕਦਾ ਹੈ ਜੋ ਪਰਮੀਸ਼ਨ ਐੱਜ ਕੇਸਾਂ ਕਰਕੇ ਡੇਟਾਬੇਸ ਅਤੇ UI ਰੀਡਿਜ਼ਾਈਨ ਮੰਗਦੇ।

ਇੱਕ-ਪੰਗਤੀ ਅਤੇ ਛੋਟੀ ਸਫਲਤਾ ਪਰਿਭਾਸ਼ਾ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ

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

ਇੱਕ ਚੰਗੀ ਇੱਕ-ਪੰਗਤੀ ਇਹ ਦੱਸਦੀ ਹੈ: ਇਹ ਕਿਸ ਲਈ ਹੈ, ਅਤੇ ਮੁੱਖ ਕੰਮ ਕੀ ਹੈ?

ਉਦਾਹਰਨ ਇੱਕ-ਪੰਗਤੀਆਂ:

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

ਫਿਰ ਇੱਕ ਛੋਟੀ ਸਫਲਤਾ ਪਰਿਭਾਸ਼ਾ ਜੋ 3 ਤੋਂ 5 ਨਤੀਜੇ ਹੋਣ — ਅਸਲ ਯੂਜ਼ਰ ਕੀ ਪ੍ਰਾਪਤ ਕਰਨਗੇ। ਨਤੀਜਿਆਂ ਨੂੰ ਫੀਚਰ ਨਾ ਬਣਾ ਕੇ ਯੂਜ਼ਰ ਨਤੀਜੇ ਵਜੋਂ ਲਿਖੋ।

ਟਿਊਟਰ ਬੁਕਿੰਗ ਉਦਾਹਰਨ ਲਈ:

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

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

ਇਸ ਸੈਕਸ਼ਨ ਨੂੰ ਛੋਟਾ ਰੱਖੋ। ਇਹ ਹਰ ਚੀਜ਼ ਲਈ ਸੰਦਰਭ ਬਣਦਾ ਹੈ: ਕੀ ਸੱਚਮੁੱਚ ਸੱਚ ਹੋਣਾ ਚਾਹੀਦਾ, ਕੀ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ, ਅਤੇ ਕੀ ਬਦਲ ਸਕਦਾ ਹੈ।

ਫਿਕਸ ਪ੍ਰੋਜੈਕਟ ਪਾਬੰਦੀਆਂ ਲਿਖੋ (ਸਮਾਂ, ਬਜਟ, ਲੋਕ)

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

ਉਹਨਾਂ ਨੂੰ ਸਧਾਰਨ, ਟੈਸਟਬਲ ਬਿਆਨਾਂ ਵਜੋਂ ਲਿਖੋ:

• ਡੇਡਲਾਈਨ ਅਤੇ ਮਾਈਲਸਟੋਨ: ਲਾਂਚ ਦੀ ਤਾਰੀਖ ਅਤੇ 2-3 ਚੈਕਪੋਇੰਟ (ਸਪੈਸ ਸਾਇਨ-ਆਫ, ਪ੍ਰੋਟੋਟਾਇਪ ਐਪਰੂਵਲ, ਪਹਿਲੀ ਰਿਲੀਜ਼ ਰੇਡੀ). ਕਿਹਾ ਕਿ ਪਹਿਲੀ ਰਿਲੀਜ਼ ਵਿੱਚ ਕੀ ਸ਼ਾਮਲ ਹੈ।
• ਬਜਟ: ਕੀ ਇਹ ਇੱਕ ਹਾਰਡ ਕੈਪ ਹੈ ਜਾਂ ਟਾਰਗਟ ਰੇਂਜ। ਇਹ ਵੀ ਦੱਸੋ ਕਿ ਕੀ ਸ਼ਾਮਲ ਹੈ (ਬਿਲਡ ਟਾਈਮ, ਡਿਜ਼ਾਈਨ, ਟੈਸਟਿੰਗ, ਹੋਸਟਿੰਗ, ਸਪੋਰਟ)।
• ਲੋਕ ਅਤੇ ਉਪਲਬਧ ਸਮਾਂ: ਕੌਣ ਰਿਵਿਊ ਕਰਦਾ ਹੈ ਅਤੇ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਉਹ ਜਵਾਬ ਦਿੰਦੇ ਹਨ। ਧੀਮਾ ਫੀਡਬੈਕ ਇੱਕ ਅਸਲ ਪਾਬੰਦੀ ਹੈ।
• ਫੈਸਲੇ ਦਾ ਮਾਲਿਕ: ਉਹ ਵਿਅਕਤੀ ਜੋ ਟਰੇਡ-ਆਫ਼ ਆਉਣ ਤੇ ਹਾਂ ਜਾਂ ਨਾ ਕਹਿ ਸਕਦਾ ਹੈ।

ਇੱਕ ਸਧਾਰਣ ਉਦਾਹਰਨ:

“ਪਹਿਲੀ ਰਿਲੀਜ਼ 30 ਮਈ ਤੱਕ ਸ਼ਿਪ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਇਸ ਵਿੱਚ ਲੌਗਿਨ, ਇੱਕ ਬੁਨਿਆਦੀ ਕਸਟਮਰ ਲਿਸਟ ਅਤੇ ਇੱਕ ਮਾਸਿਕ ਰਿਪੋਰਟ ਸ਼ਾਮਲ ਹੈ। v1 ਵਿੱਚ ਕੋਈ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਨਹੀਂ। ਬਜਟ $8,000 ਕੈਪ ਹੈ ਜਿਸ ਵਿੱਚ ਪਹਿਲੇ ਮਹੀਨੇ ਦੀ ਹੋਸਟਿੰਗ ਸ਼ਾਮਲ ਹੈ। ਰਿਵਿਊ ਵੀਕਡੇਜ਼ ਵਿੱਚ 24 ਘੰਟੇ ਦੇ ਅੰਦਰ ਹੋਣਗੇ। ਪ੍ਰੋਡਕਟ ਮਾਲਿਕ Sam ਹੈ, ਜੋ ਸਕੋਪ ਬਦਲਣ ਦੀ ਮਨਜ਼ੂਰੀ ਦਿੰਦਾ ਹੈ।”

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

ਇੱਕ ਰਿਵਿਊ ਕੈਡੰਸ ਚੁਣੋ ਜੋ ਹਕੀਕਤ ਨਾਲ ਮਿਲਦੀ ਹੋਵੇ: ਇਕੋ-ਦਿਨ ਫੀਡਬੈਕ, ਵیکਡੇਜ਼ ਵਿੱਚ 24-48 ਘੰਟੇ, ਸਪੱਤਾਹਿਕ ਮੀਟਿੰਗ, ਜਾਂ (ਕਦੇ-ਕਦੇ) “ਕੋਈ ਫੀਡਬੈਕ ਲੋੜੀਂਦਾ ਨਹੀਂ।”

ਫਿਕਸ ਟੈਕਨੀਕਲ ਪਾਬੰਦੀਆਂ ਲਿਖੋ (ਸਟੈਕ ਅਤੇ ਹੋਸਟਿੰਗ)

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

ਸ਼ੁਰੂਆਤ ਇਸ ਤੋਂ ਕਰੋ ਕਿ ਕੀ ਲੌਕ ਹੈ ਅਤੇ ਕੀ ਸਿਰਫ ਪਸੰਦ ਹੈ। “Prefer React” ਅਤੇ “must be React because we rely on an in-house component library” ਇੱਕੋ ਨਹੀਂ। ਇੱਕ-ਵਾਕ ਪਰ ਹਰ ਫ਼ੈਸਲੇ ਲਈ ਕਾਫ਼ੀ ਹੈ।

ਸਟੈਕ ਨੂੰ ਲੌਕ ਕਰੋ (ਕੇਵਲ ਉਹ ਜੋ ਅਸਲ ਵਿੱਚ ਨਹੀਂ ਬਦਲ ਸਕਦੇ)

ਪੂਰੇ ਐਪ ਵਿੱਚ ਖੁੱਲ੍ਹੇ ਤੌਰ 'ਤੇ ਲਿਖੋ: ਵੈੱਬ, ਬੈਕਐਂਡ, ਡੇਟਾਬੇਸ ਅਤੇ ਮੋਬਾਈਲ. ਜੇ ਕੋਈ ਹਿੱਸਾ ਲਚਕੀਲਾ ਹੈ, ਤਾਂ ਇਹ ਦੱਸੋ ਅਤੇ ਇੱਕ ਸੀਮਾ ਜੋੜੋ (ਉਦਾਹਰਨ ਲਈ, “v1 ਵਿੱਚ ਮੋਬਾਈਲ ਵੈੱਬ-ਆਨਲੀ ਹੈ”)।

ਇੱਕ ਸਧਾਰਣ ਲਿਖਣ ਦਾ ਤਰੀਕਾ:

• Web/UI: X ਵਰਤੋ (ਕਾਰਨ), ਜਾਂ X/Y ਵਰਤੇ ਜਾ ਸਕਦੇ ਹਨ (ਫੈਸਲਾ ਮਾਲਿਕ)
• Backend: X ਹੋਵੇ (ਕਾਰਨ) ਅਤੇ APIs ਇੱਕ ਪਰਿਭਾਸ਼ਤ ਸ਼ੈਲੀ ਵਿੱਚ ਹੋਣ (REST ਜਾਂ GraphQL)
• Database: X ਹੋਵੇ, ਅਤੇ ਕੀ ਹੁਣ ਮਲਟੀ-ਟੇਨੈਂਟ ਚਾਹੀਦਾ ਹੈ
• Mobile: ਨੈਟਿਵ/Flutter ਹੋਣਾ ਚਾਹੀਦਾ, ਜਾਂ “v1 ਵਿੱਚ ਨਹੀਂ”
• Dev ਅਤੇ delivery: ਕੀ source code export ਲੋੜੀਦਾ ਹੈ, ਅਤੇ ਜ਼ਰੂਰੀ ਏਨਵਾਇਰਨਮੈਂਟ (dev/stage/prod)

ਫਿਰ ਉਹ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਲਿਸਟ ਕਰੋ ਜੋ ਬਚਣਾ ਮুশਕਲ ਹੈ। ਸਿਸਟਮਾਂ ਦਾ ਨਾਮ ਲਿਖੋ (payments, email, analytics, CRM) ਅਤੇ ਕਠੋਰ ਸੀਮਾਵਾਂ ਨੋਟ ਕਰੋ। ਉਦਾਹਰਨ: “ਬਿਲਿੰਗ ਲਈ Stripe ਵਰਤਣਾ ਲਾਜ਼ਮੀ ਹੈ,” “ਈਮੇਲ ਸਾਡੇ ਮੌਜੂਦਾ ਪ੍ਰੋਵਾਈਡਰ ਰਾਹੀਂ ਭੇਜੀ ਜਾਵੇ,” “Analytics ਵਿੱਚ ਨਿੱਜੀ ਡਾਟਾ ਟਰੈਕ ਨਹੀਂ ਹੋਵੇ।” ਜੇ authentication ਫਿਕਸ ਹੈ (SSO, Google login, passwordless), ਤਾਂ ਉਸਨੂੰ ਵੀ ਸਪੱਸ਼ਟ ਕਰੋ।

ਹੋਸਟਿੰਗ, ਰੀਜਨ ਅਤੇ ਡੇਟਾ ਨਿਯਮ (ਸਧਾਰਨ ਭਾਸ਼ਾ)

ਹੋਸਟਿੰਗ ਚੋਣ ਆਰਕੀਟੈਕਚਰ ਬਦਲ ਦਿੰਦੀ ਹੈ। ਲਿਖੋ ਕਿ ਐਪ ਕਿੱਥੇ ਚੱਲਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਕਿਉਂ: “Germany ਵਿੱਚ ਡਿਪਲੋਇ ਹੋਵੇ,” “ਡੇਟਾ EU ਵਿੱਚ ਰਹੇ,” ਜਾਂ “ਗਲੋਬਲ ਤੌਰ 'ਤੇ ਚੱਲ ਸਕਦਾ।”

ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਕੰਪਲਾਇੰਸ ਲੋੜਾਂ ਹਨ, ਉਦਾਹਰਣ-ਰੂਪ ਵਿੱਚ ਉਨ੍ਹਾਂ ਨੂੰ ਕਾਂਕਰੀਟ ਰੱਖੋ: ਰਿਟੇਨਸ਼ਨ ਅਵਧੀ, ਡਿਲੀਸ਼ਨ ਨਿਯਮ, ਅਤੇ ਆਡੀਟ ਦੀ ਲੋੜ।

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

ਸਕੋਪ ਦੀ ਰੱਖਿਆ ਲਈ ਨਾਨ-ਗੋਲ ਸ਼ਾਮਲ ਕਰੋ

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

ਇੱਕ ਚੰਗਾ ਨਾਨ-ਗੋਲ ਇੱਕ ਵਾਕ ਵਿੱਚ ਇੰਨਾ ਸਪਸ਼ਟ ਹੋਵੇ ਕਿ ਟੀਮ ਦਾ ਕੋਈ ਮੈਂਬਰ ਤੁਰੰਤ ਸਕੋਪ ਕ੍ਰੀਪ ਨੋਟ ਕਰ ਸਕੇ। ਇਹ ਸਮੇਂ-ਬੱਧ ਵੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। “v1 ਵਿੱਚ ਨਹੀਂ” “ਅਸੀਂ ਇਹ ਨਹੀਂ ਕਰੋਗੇ” ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਸਪਸ਼ਟ ਹੈ।

ਪਹਿਲੀ ਰਿਲੀਜ਼ ਵਿੱਚ ਤੁਸੀਂ ਕੀ ਨਹੀਂ ਬਣਾਓਗੇ

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

• v1 ਵਿੱਚ ਕੋਈ admin ਪੋਰਟਲ ਨਹੀਂ (ਕੇਵਲ ਬੁਨਿਆਦੀ ਸਟਾਫ ਟੂਲ)
• v1 ਵਿੱਚ ਕੋਈ ਮਲਟੀ-ਭਾਸ਼ਾ ਜਾਂ ਲੋਕਲਾਈਜ਼ੇਸ਼ਨ ਨਹੀਂ
• ਕੋਈ ਆਫਲਾਈਨ ਮੋਡ ਜਾਂ ਸਿੰਕ ਨਹੀਂ
• ਕੋਈ ਕਾਂਪਲੈਕਸ ਡੈਸ਼ਬੋਰਡ ਨਹੀਂ (ਕੇਵਲ ਇੱਕ ਸਧਾਰਨ ਹਫ਼ਤਾਵਾਰ ਸੰਖੇਪ)
• v1 ਵਿੱਚ ਕੋਈ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਨਹੀਂ (payments, calendars, email tools)

ਇਹ ਫੀਚਰ ਬੁਰੇ ਨਹੀਂ ਹਨ; ਇਹ ਮਹਿੰਗੇ ਹਨ। ਉਨ੍ਹਾਂ ਨੂੰ ਲਿਖਣ ਨਾਲ ਪਹਿਲੀ ਰਿਲੀਜ਼ ਫੋਕਸ ਰਹਿੰਦੀ ਹੈ।

ਉਸਦੇ ਨਾਲ-ਨਾਲ ਉਹ “ਡਿਟੇਲ” ਆਈਟਮ ਵੀ ਦਰਜ ਕਰੋ ਜੋ ਵੱਡੀਆਂ ਲੜੀਵਾਰ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਕਰਦੇ ਹਨ: ਰੋਲ, ਪਰਮੀਸ਼ਨ, ਅਤੇ ਐੱਡਜ-ਕੇਸ ਵਰਕਫਲੋ। “ਕੋਈ ਕਸਟਮ ਰੋਲ ਨਹੀਂ। ਕੇਵਲ ਦੋ ਰੋਲ: Owner ਅਤੇ Member.” ਇਹ ਇੱਕ ਲਾਈਨ ਕਈ ਹਫ਼ਤੇ ਬਚਾ ਸਕਦੀ ਹੈ।

ਤੁਸੀਂ ਕਿਸ ਗੱਲ ਲਈ ਅਪਟਿਮਾਈਜ਼ ਨਹੀਂ ਕਰ ਰਹੇ

ਟੀਮਾਂ ਅਕਸਰ ਉਹ ਨਾਨ-ਗੋਲ ਭੁੱਲ ਜਾਂਦੀਆਂ ਜੋ ਫੀਚਰ ਦੀ ਸ਼੍ਰੇਣੀ ਵਿੱਚ ਨਹੀਂ ਆਉਂਦੀਆਂ। ਇਹ ਬਾਅਦ ਵਿੱਚ ਦੁਖਦਾਈ ਮੁੜ-ਬਣਾਉਣ ਵਜੋਂ ਆ ਜਾਂਦੀਆਂ ਹਨ।

ਤੈਅ ਕਰੋ ਕਿ ਤੁਸੀਂ ਕਿਸ ਗੱਲ ਲਈ ਅਪਟਿਮਾਈਜ਼ ਨਹੀਂ ਕਰ ਰਹੇ। ਉਦਾਹਰਨ ਲਈ: “ਅਸੀਂ 1M ਯੂਜ਼ਰਾਂ ਲਈ ਟਿਊਨ ਨਹੀਂ ਕਰਾਂਗੇ। v1 ਲਈ ਅਸੀਂ 500 ਹਫਤਾਵਾਰ ਐਕਟਿਵ ਯੂਜ਼ਰ ਤੱਕ ਦੀ ਗਣਨਾ ਕਰਦੇ ਹਾਂ।”

ਇਸਦੇ ਨਾਲ ਇਹ ਵੀ ਨੋਟ ਕਰੋ ਕਿ ਤੁਸੀਂ ਕੀ ਸਹਾਇਤਾ ਨਹੀਂ ਕਰੋਗੇ, ਤਾਂ ਕਿ ਟੈਸਟਿੰਗ ਯਥਾਰਥ ਰਹੇ: “No Internet Explorer,” “ਕੋਈ ਟੈਬਲੇਟ-ਖਾਸ ਲੇਆਊਟ ਨਹੀਂ,” ਜਾਂ “ਲੌਗਿਨ ਕੇਵਲ ਈਮੇਲ ਅਤੇ ਪਾਸਵਰਡ (ਕੋਈ SSO, ਕੋਈ ਮੈਜਿਕ ਲਿੰਕ ਨਹੀਂ)।”

ਕੀ ਬਦਲ ਸਕਦਾ ਹੈ ਬਿਨਾਂ ਸਭ ਕੁਝ ਮੁੜ-ਖੋਲ੍ਹਣ ਦੇ ਫੈਸਲਾ ਕਰੋ

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

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

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

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

ਮੁੱਖ ਨਿਯਮ: ਲਚਕੀਲੇ ਬਦਲਾਅ ਫਿਕਸ ਪਾਬੰਦੀਆਂ ਨੂੰ ਤੋੜ ਨਹੀਂ ਸਕਦੇ। ਜੇ ਤੁਹਾਡਾ ਸਟੈਕ React + Go + PostgreSQL ਲੌਕ ਹੈ, ਤਾਂ “ਬਦਲ ਸਕਦਾ ਹੈ” ਦੀ ਬੇਨਤੀ “ਚਲੋ ਬੈਕਐਂਡ ਸਵਿੱਚ ਕਰੀਏ” ਨਹੀਂ ਹੋ ਸਕਦੀ। ਜੇ ਡੇਡਲਾਈਨ ਫਿਕਸ ਹੈ, ਤਾਂ “ਬਦਲ ਸਕਦਾ” ਦਾ ਮਤਲਬ ਇੱਕ ਨਵੇਂ ਮੋਡੀਊਲ ਦਾ ਜੁੜਨਾ ਨਹੀਂ ਹੋ ਸਕਦਾ ਜੋ ਦੋ ਹਫ਼ਤੇ ਹੋਰ ਲੈਂਦਾ।

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

ਤੁਹਾਡੀ ਸਪੈਸ ਵਿੱਚ ਨਕਲ ਕਰਨ ਯੋਗ ਸਟੈਪ-ਬਾਈ-ਸਟੈਪ ਫਾਰਮੈਟ

ਇੱਕ ਵਧੀਆ ਸਪੈਸ ਵਿਕਲਪ ਵਧਾਉਣ ਨਾਲ ਸ਼ੁਰੂ ਕਰਨ ਦੀ بجائے ਵਿਕਲਪ ਘਟਾ ਕੇ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ। ਇਹ ਫਾਰਮੈਟ ਤੁਹਾਨੂੰ ਨਿਰਮਾਣ ਦੀ ਸ਼ੁਰੂਆਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਨਿਯਮ ਲਿਖਣ ਲਈ ਮਜ਼ਬੂਰ ਕਰਦਾ ਹੈ।

Copy/paste format (ਖਾਲੀ ਥਾਵਾਂ ਭਰੋ)

ਡੌਕ ਦੇ ਹੈਡਰ ਵਿੱਚ ਇਹ ਵਰਤੋ:

SPEC v0.1 (date)
Owner:
Reviewers:

1) One-liner
- Build: [what it is]
- For: [who]
- So they can: [main benefit]

2) Success definition (3 outcomes)
- Outcome 1: [measurable result]
- Outcome 2: [measurable result]
- Outcome 3: [measurable result]

3) Fixed constraints (cannot change without re-approval)
- Deadline: [date]
- Budget: [$ or hours]
- People: [who is available]
- Tech stack: [fixed choices]
- Hosting/region: [where it must run]

4) Non-goals (must NOT happen)
- [explicit “no”]
- [explicit “not in v1”]
- [explicit “we won’t support”]

5) Open questions
- Q: [question]
  Owner: [name]
  Due: [date]

6) Lock rule
- After review: changes require: [what approval looks like]

(ਕੋਡ ਫੇਂਸ ਅੰਦਰ ਦੀ ਵਸਤੂ ਬਦਲੀ ਨਹੀਂ ਕਰਨੀ—ਉਸਨੂੰ ਜਿਵੇਂ ਦਾ ਤਿਵੇਂ ਰੱਖੋ.)

ਇਸਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਖਤਮ ਕਰਨ ਲਈ 5-ਕਦਮ ਵਰਕਫ਼ਲੋ

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

ਆਮ ਫੰਦੇ ਜੋ ਬਾਅਦ ਵਿੱਚ ਹੈਰਾਨੀਆਂ ਪੈਦਾ ਕਰਦੇ ਹਨ

ਬਹੁਤ ਸਾਰੀਆਂ ਹੈਰਾਨੀਆਂ ਕਿਸਮਤ ਨਹੀਂ ਹੁੰਦੀਆਂ—ਉਹ ਇਸ ਕਰਕੇ ਹੁੰਦੀਆਂ ਹਨ ਕਿ ਸਪੈਸ ਵੱਖ-ਵੱਖ ਅਰਥ ਬਿਆਨ ਕਰਨ ਲਈ ਰਾਹ ਛੱਡ ਦਿੰਦਾ ਹੈ।

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

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

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

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

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

ਇਨ੍ਹਾਂ ਫੰਦੇ ਤੋਂ ਬਚਣ ਦੇ ਤੇਜ਼ ਤਰੀਕੇ

ਆਪਣੀ ਸਪੈਸ ਵਿੱਚ ਇੱਕ ਛੋਟਾ ਨੋਟ ਸ਼ਾਮਲ ਕਰੋ ਜੋ ਪੰਜ ਬਿੰਦੂਆਂ ਨੂੰ ਪਤਾ ਦਿੰਦਾ:

• ਕੀ ਫਿਕਸ ਹੈ (ਡੇਡਲਾਈਨ, ਬਜਟ ਰੇਂਜ, ਅਤੇ ਕੌਣ ਇੰਨੀਤੀ ਤਿਆਰ ਕਰ ਰਿਹਾ ਹੈ)
• ਟੈਕਨੀਕਲ ਤੌਰ 'ਤੇ ਕੀ ਫਿਕਸ ਹੈ (ਸਟੈਕ, ਹੋਸਟਿੰਗ, ਲਾਜ਼ਮੀ ਸੁਰੱਖਿਆ ਨਿਯਮ)
• ਕੀ ਖਾਸ ਤੌਰ 'ਤੇ ਸ਼ਾਮਲ ਨਹੀਂ ਹੈ (3 ਤੋਂ 5 ਸਪਸ਼ਟ ਨਾਨ-ਗੋਲ)
• ਪਹਿਲੀ ਰਿਲੀਜ਼ ਲਈ “ਡਨ” ਦਾ ਕੀ ਮਤਲਬ ਹੈ (ਇੱਕ ਮੈਜ਼ਰਬਲ ਨਤੀਜਾ)
• ਕੀ ਬਦਲ ਸਕਦਾ ਹੈ ਬਿਨਾਂ ਪੂਰੇ ਸਪੈਸ ਨੂੰ ਮੁੜ-ਖੋਲ੍ਹਣ ਦੇ

ਕਿਸੇ ਵੀ ਕੋਡ ਨੂੰ ਜਨਰੇਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਤੇਜ਼ ਚੈੱਕਲਿਸਟ ਅਤੇ ਅਗਲੇ ਕਦਮ

ਕਿਸੇ ਨੇ ਵੀ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ, ਤੁਹਾਨੂੰ “ਕੀ ਫਿਕਸ ਹੈ?” ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਬਿਨਾਂ ਕਿਸੇ ਲੰਬੇ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਖੋਜਣ ਦੇ ਦੇ ਸਕਣਾ ਚਾਹੀਦਾ ਹੈ।

ਤੇਜ਼ ਚੈੱਕ:

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

ਜੇ ਇਨ੍ਹਾਂ ਵਿਚੋਂ ਕੋਈ ਇਕ ਨਹੀਂ ਹੈ, ਤਾਂ ਪਹਿਲੀ ਬਿਲਡ ਹੋ ਜਾਏਗੀ, ਪਰ ਦੂਜੀ ਬਿਲਡ ਅਸਲ ਹੋਵੇਗੀ।

ਅਗਲੇ ਕਦਮ ਜੋ ਗਲਤ ਫੈਸਲਿਆਂ 'ਤੇ ਤੁਹਾਨੂੰ ਲਾਕ ਨਹੀਂ ਕਰਦੇ:

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

If you’re using Koder.ai (koder.ai), “Planning Mode” plus a clear constraints and non-goals section helps the platform generate a first draft that matches your stack, hosting region, and scope. And if priorities shift, snapshots and rollback let you test changes without losing a stable baseline. (ਇਸ ਵਾਕ ਨੂੰ ਜਿਵੇਂ ਦਾ ਤਿਵੇਂ ਰੱਖੋ, ਕਿਉਂਕਿ ਇਹ ਇੱਕ ਬਰਾਂਡ ਅਤੇ ਡੋਮੇਨ ਹੈ.)

ਜਦੋਂ ਇਹ ਨਿਯਮ ਪਹਿਲਾਂ ਲਿਖੇ ਜਾਂਦੇ ਹਨ, ਫੀਚਰ ਚਰਚਾ ਅਸਾਨ ਹੋ ਜਾਂਦੀ ਹੈ ਕਿਉਂਕਿ ਹਰ ਕੋਈ ਜਾਣਦਾ ਹੈ ਕਿ ਕੀ ਫਿਕਸ ਰਹੇਗਾ ਅਤੇ ਕੀ ਹਿਲ ਸਕਦਾ ਹੈ।