ਸਿੱਖੋ ਕਿ ਕਿਵੇਂ ਐਪ ਸਪੈਸ ਵਿੱਚ ਪਾਬੰਦੀਆਂ ਅਤੇ ਨਾਨ-ਗੋਲ ਲਿਖਣ ਨਾਲ ਦੁਬਾਰਾ ਕੰਮ ਤੇਜ਼ੀ ਨਾਲ ਘਟਦਾ ਹੈ। ਇੱਕ ਸਧਾਰਣ ਫਾਰਮੈਟ ਵਰਤੋ ਜੋ ਸਟੈਕ, ਬਜਟ, ਡੇਡਲਾਈਨ ਅਤੇ ਬਦਲ ਸਕਣ ਵਾਲੀਆਂ ਚੀਜ਼ਾਂ ਦਰਸਾਉਂਦਾ ਹੈ।
ਦੋਹਰਾ ਕੰਮ ਉਹ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਕੁਝ ਐਸਾ ਬਣਾਉਂਦੇ ਹੋ ਜੋ ਕੰਮ ਕਰਦਾ ਹੈ, ਪਰ ਪ੍ਰੋਜੈਕਟ ਲਈ ਗਲਤ ਹੁੰਦਾ ਹੈ। ਟੀਮਾਂ ਸਕਰੀਨਾਂ ਦੁਬਾਰਾ ਬਣਾਉਂਦੀਆਂ ਹਨ, ਲੋਜਿਕ ਫਿਰ ਲਿਖੀ ਜਾਂਦੀ ਹੈ, ਡੇਟਾ ਮਾਈਗ੍ਰੇਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜਾਂ ਫੀਚਰ ਮੁੜ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ ਕੋਈ ਮੁੱਖ ਫੈਸਲਾ ਦੇਰ ਨਾਲ ਸਾਹਮਣੇ ਆ ਜਾਂਦਾ ਹੈ।
ਅਕਸਰ ਇਹ ਜਾਣ-ਪਛਾਣ ਵਾਲੇ ਤਰੀਕਿਆਂ ਵਿੱਚ ਨਜ਼ਰ ਆਉਂਦਾ ਹੈ: ਕਿਸੇ ਫਲੋ ਨੂੰ ਮੁੜ ਬਣਾਉਣਾ ਕਿਉਂਕਿ ਗਲਤ ਯੂਜ਼ਰ ਰੋਲ ਸਮਝਿਆ ਗਿਆ; ਸਕਰੀਨਾਂ ਨੂੰ ਰੀਡਿਜ਼ਾਈਨ ਕੀਤਾ ਗਿਆ ਕਿਉਂਕਿ ਮੋਬਾਈਲ ਸਹਾਇਤਾ ਦੀ ਉਮੀਦ ਸੀ ਪਰ ਉੱਕਾ ਨਹੀਂ ਦਿੱਤਾ ਗਿਆ; ਡੇਟਾ ਮਾਡਲ ਬਦਲਿਆ ਗਿਆ ਕਿਉਂਕਿ “ਸਾਨੂੰ ਆਡੀਟ ਇਤਿਹਾਸ ਚਾਹੀਦਾ ਹੈ” ਵਰਜਨ ਇਕ ਤੋਂ ਬਾਅਦ ਆਇਆ; ਇਕ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਬਦਲ ਦਿੱਤਾ ਗਿਆ ਕਿਉਂਕਿ ਕਲਾਇੰਟ ਕੋਈ ਤੀਜੇ-ਪੱਖ ਸੇਵਾ ਵਰਤ ਨਹੀਂ ਸਕਦਾ; ਜਾਂ ਕੰਪਲਾਇੰਸ/ਰੀਜਨ ਨਿਯਮਾਂ ਕਰਕੇ ਹੋਸਟਿੰਗ ਬਦਲਣੀ ਪਈ।
ਗਾਇਬ ਪਾਬੰਦੀਆਂ ਬਾਅਦ ਵਿੱਚ ਹੈਰਾਨੀਆਂ ਪੈਦਾ ਕਰਦੀਆਂ ਹਨ। ਜਦੋਂ ਸਪੈਸ ਕਹਿੰਦਾ ਹੈ “ਇੱਕ CRM ਬਣਾਓ,” ਤਾਂ ਇਹ ਦਰਜਨਾਂ ਸਵਾਲ ਛੱਡ ਦਿੰਦਾ ਹੈ: ਕੌਣ ਇਸਨੂੰ ਵਰਤਦਾ, ਕਿਹੜੀਆਂ ਪਲੇਟਫਾਰਮ ਮਹੱਤਵ ਰੱਖਦੀਆਂ, ਕਿਹੜੇ ਸੁਰੱਖਿਆ ਨਿਯਮ ਲਾਗੂ ਹੋਣਗੇ, ਕੀ ਬਾਹਰ ਰਹਿਣਾ ਚਾਹੀਦਾ ਅਤੇ ਅਸਲ ਬਜਟ ਅਤੇ ਸਮਾਂ-ਰੇਖਾ ਕੀ ਹਨ। ਜੇ ਜਵਾਬ ਕੋਡ ਹੋਣ ਤੋਂ ਬਾਅਦ ਆਉਂਦੇ ਹਨ, ਤਾਂ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਦੋ ਵਾਰੀ ਖਰਚਣਾ ਪੈਂਦਾ ਹੈ: ਇੱਕ ਵਾਰੀ ਬਣਾਉਣ ਲਈ, ਅਤੇ ਇੱਕ ਵਾਰੀ ਉਥੋਂ ਵਾਪਸ ਕਰਨ ਲਈ।
ਇੱਕ ਸਧਾਰਣ ਉਦਾਹਰਨ: ਇੱਕ ਫਾਉਂਡਰ “appointments + reminders” ਮੰਗਦਾ ਹੈ। ਪਹਿਲੇ ਹਫ਼ਤੇ ਈਮੇਲ ਰਿਮਾਈਂਡਰ ਭੇਜੇ ਜਾਂਦੇ ਹਨ। ਦੂਜੇ ਹਫ਼ਤੇ ਉਹ ਕਹਿੰਦਾ ਹੈ ਕਿ ਉਨ੍ਹਾਂ ਨੂੰ SMS ਚਾਹੀਦਾ ਹੈ, ਪਰ SMS ਉਨ੍ਹਾਂ ਦੇ ਦੇਸ਼ ਵਿੱਚ ਮਨਾਹੀ ਹੈ ਜਾਂ ਇਹ ਬਜਟ ਤੋ ਵੱਧ ਹੋ ਜਾਂਦਾ ਹੈ। ਹੁਣ ਰਿਮਾਈਂਡਰ ਸਿਸਟਮ ਨੂੰ ਰੀਡਿਜ਼ਾਈਨ ਕਰਨਾ ਪੈਂਦਾ, ਸਕਰੀਨ ਬਦਲਦੇ ਹਨ, ਅਤੇ ਟੈਸਟ ਮੁੜ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ। ਰੀਵਰਕ ਖਰਾਬ ਕੋਡਿੰਗ ਕਰਕੇ ਨਹੀਂ ਸੀ — ਇਹ ਦੇਰ ਨਾਲ ਆਈਆਂ ਪਾਬੰਦੀਆਂ ਕਾਰਨ ਸੀ।
ਉਦੇਸ਼ ਇਹ ਹੈ ਕਿ ਕਿਸੇ ਵੀ ਕੋਡ ਲਿਖਣ ਜਾਂ ਜਨਰੇਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਬੈਕ-ਅਤੇ-ਫਾਰਗ ਘਟਾਏ ਜਾਣ। ਚਾਹੇ ਤੁਸੀਂ ਹੱਥ ਤੋਂ ਕੋਡ ਕਰੋ ਜਾਂ ਚੈਟ-ਅਧਾਰਤ ਬਿਲਡਰ ਵਰਤੋ, ਨਤੀਜਾ ਕੇਵਲ ਉਹ ਨਿਯਮਾਂ ਮੰਨ ਕੇ ਹੀ ਆ ਸਕਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਦਿੰਦੇ ਹੋ। ਜੇ ਨਿਯਮ ਦੇਰ ਨਾਲ ਆਉਂਦੇ ਹਨ, ਕੰਮ ਥੱਲੇ ਉਲਟਦਾ ਹੈ ਅਤੇ ਤੁਸੀਂ ਦੁਬਾਰਾ ਬਣਾਉਂਦੇ ਹੋ।
ਇਹ ਕਿਸੇ ਲੰਬੇ ਦਸਤਾਵੇਜ਼ ਦੀ ਲੋੜ ਨਹੀਂ — ਇੱਕ ਹਲਕੀ-ਫੁਲਕੀ ਸਪੈਸ ਵੀ ਜਿੱਥੇ ਗੱਲ ਮਹੱਤਵ ਦੀ ਹੋ ਉਥੇ ਕਠੋਰ ਹੋ ਸਕਦੀ ਹੈ। ਸ਼ੁਰੂ ਵਿੱਚ, ਇਹਨਾਂ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇਣੇ ਚਾਹੀਦੇ ਹਨ:
ਜਦੋਂ ਪਾਬੰਦੀਆਂ ਅਤੇ ਨਾਨ-ਗੋਲ ਪਹਿਲਾਂ ਲਿਖੇ ਜਾਂਦੇ ਹਨ, ਉਹ ਗਾਰਡਰੇਲ ਵਾਂਗ ਕੰਮ ਕਰਦੇ ਹਨ। ਤੁਹਾਨੂੰ ਘੱਟ ਹੈਰਾਨੀਆਂ, ਘੱਟ ਮੁੜ-ਬਣਾਉਣ ਅਤੇ ਪਹਿਲੇ ਦਿਨ ਤੋਂ ਜ਼ਿਆਦਾ ਸਪਸ਼ਟ ਫੈਸਲੇ ਮਿਲਦੇ ਹਨ।
ਪਾਬੰਦੀਆਂ ਉਹ ਫ਼ੈਸਲੇ ਹਨ ਜੋ ਤੁਹਾਡੇ ਪ੍ਰੋਜੈਕਟ ਨਾਲ ਜ਼ਿੰਦਾ ਰਹਿਣੇ ਲਾਜ਼ਮੀ ਹੁੰਦੇ ਹਨ। ਉਨ੍ਹਾਂ ਨੂੰ ਅਣਡਿੱਠਾ ਕਰੋ ਅਤੇ ਤੁਸੀਂ ਦੋ ਵਾਰੀ ਕੰਮ ਕਰੋਗੇ, ਕਿਉਂਕਿ ਤੁਸੀਂ ਐਸੇ ਦਿਸ਼ਾ ਵਿੱਚ ਬਣਾਉਂਦੇ ਹੋ ਜੋ ਸ਼ਿਪ ਨਹੀਂ ਹੋ ਸਕਦੀ।
ਨਾਨ-ਗੋਲ ਸਾਫ਼ ਚੋਣ ਹਨ ਕਿ ਅਸੀਂ ਕੋਈ ਚੀਜ਼ ਨਹੀਂ ਬਣਾਉਂਦੇ। ਜੇ ਉਹ ਛੱਡ ਦਿੱਤੇ ਜਾਣ ਤਾਂ ਸਪੈਸ ਆਹਿਸਤਾ-ਆਹਿਸਤਾ ਵadh ਜਾਂਦਾ ਹੈ ਜਦ ਲੋਕ “ਛੋਟੀ” ਤਬਦੀਲੀਆਂ ਜੋੜਦੇ ਹਨ। ਇਹੀ ਤਰ੍ਹਾਂ ਸਕਰੀਨਾਂ, ਫਲੋਅਜ਼ ਅਤੇ ਡੇਟਾ ਮਾਡਲ ਮੁੜ-ਬਦਲ ਹੋ ਜਾਂਦੇ ਹਨ।
ਇੱਕ ਤੇਜ਼ ਨਿਯਮ: ਪਾਬੰਦੀਆਂ ਇਸ ਗੱਲ ਨੂੰ ਸੀਮਤ ਕਰਦੇ ਹਨ ਕਿ ਤੁਸੀਂ ਕਿਵੇਂ ਬਣਾਉਂਦੇ ਹੋ; ਨਾਨ-ਗੋਲ ਇਸ ਗੱਲ ਨੂੰ ਸੀਮਤ ਕਰਦੇ ਹਨ ਕਿ ਤੁਸੀਂ ਕੀ ਬਣਾਉਂਦੇ ਹੋ।
ਪਾਬੰਦੀ ਉਹ ਜ਼ਰੂਰੀ ਗੱਲ ਹੈ ਜੋ ਬਿਨਾਂ ਕਿਸੇ ਅਸਲ ਫੈਸਲੇ (ਅਤੇ ਤਬਦੀਲੇ) ਦੇ ਨਾ ਬਦਲੇ।
ਉਦਾਹਰਣ:
ਜਦੋਂ ਪਾਬੰਦੀ ਅਸਲ ਹੁੰਦੀ ਹੈ, ਉਸਨੂੰ ਇਕ ਐਸੇ ਵਾਕ ਵਿੱਚ ਲਿਖੋ ਜਿਸ 'ਤੇ ਕੋਈ ਗੱਲਬਾਤ ਨਾ ਕਰ ਸਕੇ। ਜੇ ਕਿਸੇ ਨੇ “ਸ਼ਾਇਦ” ਕਹਿ ਸਕਿਆ, ਤਾਂ ਉਹ ਅਜੇ ਪਾਬੰਦੀ ਨਹੀਂ।
ਨਾਨ-ਗੋਲ ਇੱਕ ਸਪਸ਼ਟ “ਅਸੀਂ ਇਹ ਨਹੀਂ ਕਰ ਰਹੇ” ਬਿਆਨ ਹੈ, ਭਾਵੇਂ ਇਹ ਲਾਭਦਾਇਕ ਲੱਗੇ। ਇਹ ਪਹਿਲੀ ਰਿਲੀਜ਼ ਦੀ ਰੱਖਿਆ ਕਰਦਾ ਹੈ।
ਉਦਾਹਰਣ:
ਨਾਨ-ਗੋਲ ਨਕਾਰਾਤਮਕਤਾ ਨਹੀਂ ਹਨ। ਉਹ ਮਹਿੰਗੀਆਂ ਭਟਕਣਾਂ ਤੋਂ ਬਚਾਉਂਦੇ ਹਨ। ਉਦਾਹਰਨ ਵਜੋਂ, “v1 ਵਿੱਚ ਕੋਈ ਕਸਟਮ ਰੋਲ ਨਹੀਂ” ਕਈ ਹਫ਼ਤੇ ਬਚਾ ਸਕਦਾ ਹੈ ਜੋ ਪਰਮੀਸ਼ਨ ਐੱਜ ਕੇਸਾਂ ਕਰਕੇ ਡੇਟਾਬੇਸ ਅਤੇ UI ਰੀਡਿਜ਼ਾਈਨ ਮੰਗਦੇ।
ਬਫ਼ਤੂ ਰੂਪ ਵਿੱਚ ਵੇਰਵੇ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ, ਇਕ ਵਾਕ ਲਿਖੋ ਜੋ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਟਿਕਾ ਦੇਵੇ। ਇਹ ਵਾਰ੍ਹ-ਵਾਰ ਹੋਣ 'ਤੇ ਟੀਮ ਨੂੰ ਸਹੀ ਰਾਹ ਤੇ ਰੱਖਦਾ ਹੈ।
ਇੱਕ ਚੰਗੀ ਇੱਕ-ਪੰਗਤੀ ਇਹ ਦੱਸਦੀ ਹੈ: ਇਹ ਕਿਸ ਲਈ ਹੈ, ਅਤੇ ਮੁੱਖ ਕੰਮ ਕੀ ਹੈ?
ਉਦਾਹਰਨ ਇੱਕ-ਪੰਗਤੀਆਂ:
ਫਿਰ ਇੱਕ ਛੋਟੀ ਸਫਲਤਾ ਪਰਿਭਾਸ਼ਾ ਜੋ 3 ਤੋਂ 5 ਨਤੀਜੇ ਹੋਣ — ਅਸਲ ਯੂਜ਼ਰ ਕੀ ਪ੍ਰਾਪਤ ਕਰਨਗੇ। ਨਤੀਜਿਆਂ ਨੂੰ ਫੀਚਰ ਨਾ ਬਣਾ ਕੇ ਯੂਜ਼ਰ ਨਤੀਜੇ ਵਜੋਂ ਲਿਖੋ।
ਟਿਊਟਰ ਬੁਕਿੰਗ ਉਦਾਹਰਨ ਲਈ:
ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਅਜੇ ਮੈਟਰਿਕਸ ਨਹੀਂ ਹਨ, ਤਾਂ ਸਫਲਤਾ ਸ਼ਬਦਾਂ ਵਿੱਚ ਵਰਣਨ ਕਰੋ। “ਫਾਸਟ” ਅਸਪਸ਼ਟ ਹੈ, ਪਰ “ਫੋਨ 'ਤੇ ਤੇਜ਼ ਮਹਿਸੂਸ ਹੁੰਦਾ” ਫਾਇਦੇਮੰਦ ਹੈ। “ਆਸਾਨ” ਅਸਪਸ਼ਟ ਹੈ, ਪਰ “ਕੋਈ ਸੈਟਅਪ ਕਾਲ ਦੀ ਲੋੜ ਨਹੀਂ” ਜ਼ਿਆਦਾ ਸਪਸ਼ਟ ਹੈ।
ਇਸ ਸੈਕਸ਼ਨ ਨੂੰ ਛੋਟਾ ਰੱਖੋ। ਇਹ ਹਰ ਚੀਜ਼ ਲਈ ਸੰਦਰਭ ਬਣਦਾ ਹੈ: ਕੀ ਸੱਚਮੁੱਚ ਸੱਚ ਹੋਣਾ ਚਾਹੀਦਾ, ਕੀ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ, ਅਤੇ ਕੀ ਬਦਲ ਸਕਦਾ ਹੈ।
ਅਕਸਰ ਮੁੜ-ਬਣਾਉਣਾ ਉਸ ਵੇਲੇ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਸਮਾਂ-ਰੇਖਾ ਅਤੇ ਫੈਸਲਾ ਪ੍ਰਕਿਰਿਆ ਕੇਵਲ ਕਿਸੇ ਦੇ ਦਿਮاغ਼ ਵਿੱਚ ਰਹਿ ਜਾਂਦੀ ਹੈ। ਸਕਰੀਨਾਂ ਅਤੇ ਫੀਚਰ ਵੇਰਵਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰੋਜੈਕਟ ਪਾਬੰਦੀਆਂ ਸਪੈਸ ਵਿੱਚ ਰੱਖੋ।
ਉਹਨਾਂ ਨੂੰ ਸਧਾਰਨ, ਟੈਸਟਬਲ ਬਿਆਨਾਂ ਵਜੋਂ ਲਿਖੋ:
ਇੱਕ ਸਧਾਰਣ ਉਦਾਹਰਨ:
“ਪਹਿਲੀ ਰਿਲੀਜ਼ 30 ਮਈ ਤੱਕ ਸ਼ਿਪ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਇਸ ਵਿੱਚ ਲੌਗਿਨ, ਇੱਕ ਬੁਨਿਆਦੀ ਕਸਟਮਰ ਲਿਸਟ ਅਤੇ ਇੱਕ ਮਾਸਿਕ ਰਿਪੋਰਟ ਸ਼ਾਮਲ ਹੈ। v1 ਵਿੱਚ ਕੋਈ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਨਹੀਂ। ਬਜਟ $8,000 ਕੈਪ ਹੈ ਜਿਸ ਵਿੱਚ ਪਹਿਲੇ ਮਹੀਨੇ ਦੀ ਹੋਸਟਿੰਗ ਸ਼ਾਮਲ ਹੈ। ਰਿਵਿਊ ਵੀਕਡੇਜ਼ ਵਿੱਚ 24 ਘੰਟੇ ਦੇ ਅੰਦਰ ਹੋਣਗੇ। ਪ੍ਰੋਡਕਟ ਮਾਲਿਕ Sam ਹੈ, ਜੋ ਸਕੋਪ ਬਦਲਣ ਦੀ ਮਨਜ਼ੂਰੀ ਦਿੰਦਾ ਹੈ।”
ਫੀਡਬੈਕ ਦੀ ਰਫ਼ਤਾਰ ਨੂੰ ਵੱਖ-ਵੱਖ ਲਾਈਨ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਕੰਮ ਕਰਨ ਦੀ ਸੁਰੱਖਿਆ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਦਾ ਹੈ। ਜੇ ਸਟੇਕਹੋਲਡਰ ਸਿਰਫ ਹਫ਼ਤਾਵਾਰ ਰਿਵਿਊ ਕਰ ਸਕਦੇ ਹਨ, ਤਾਂ ਸਪੈਸ ਨੂੰ ਛੋਟੇ ਰਿਲੀਜ਼ ਅਤੇ ਘੱਟ ਐਡਜ ਕੇਸਾਂ ਨੂੰ ਤਰਜੀਹ ਦੇਣੀ ਚਾਹੀਦੀ ਹੈ।
ਇੱਕ ਰਿਵਿਊ ਕੈਡੰਸ ਚੁਣੋ ਜੋ ਹਕੀਕਤ ਨਾਲ ਮਿਲਦੀ ਹੋਵੇ: ਇਕੋ-ਦਿਨ ਫੀਡਬੈਕ, ਵیکਡੇਜ਼ ਵਿੱਚ 24-48 ਘੰਟੇ, ਸਪੱਤਾਹਿਕ ਮੀਟਿੰਗ, ਜਾਂ (ਕਦੇ-ਕਦੇ) “ਕੋਈ ਫੀਡਬੈਕ ਲੋੜੀਂਦਾ ਨਹੀਂ।”
ਜੇ ਤੁਸੀਂ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਟੈਕਨੀਕਲ ਪਾਬੰਦੀਆਂ ਨਹੀਂ ਲਿਖਦੇ, ਲੋਕ ਧਾਰਣਾਂ ਨਾਲ ਖਾਲੀ ਥਾਵਾਂ ਭਰ ਲੈਂਦੇ ਹਨ। ਇਸੇ ਕਰਕੇ ਟੀਮ ਕੰਮ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਬਾਅਦ ਸਕਰੀਨਾਂ, ਮਾਈਗ੍ਰੇਸ਼ਨ ਜਾਂ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਮੁੜ ਕਰਨੀ ਪੈਂਦੀ ਹੈ।
ਸ਼ੁਰੂਆਤ ਇਸ ਤੋਂ ਕਰੋ ਕਿ ਕੀ ਲੌਕ ਹੈ ਅਤੇ ਕੀ ਸਿਰਫ ਪਸੰਦ ਹੈ। “Prefer React” ਅਤੇ “must be React because we rely on an in-house component library” ਇੱਕੋ ਨਹੀਂ। ਇੱਕ-ਵਾਕ ਪਰ ਹਰ ਫ਼ੈਸਲੇ ਲਈ ਕਾਫ਼ੀ ਹੈ।
ਪੂਰੇ ਐਪ ਵਿੱਚ ਖੁੱਲ੍ਹੇ ਤੌਰ 'ਤੇ ਲਿਖੋ: ਵੈੱਬ, ਬੈਕਐਂਡ, ਡੇਟਾਬੇਸ ਅਤੇ ਮੋਬਾਈਲ. ਜੇ ਕੋਈ ਹਿੱਸਾ ਲਚਕੀਲਾ ਹੈ, ਤਾਂ ਇਹ ਦੱਸੋ ਅਤੇ ਇੱਕ ਸੀਮਾ ਜੋੜੋ (ਉਦਾਹਰਨ ਲਈ, “v1 ਵਿੱਚ ਮੋਬਾਈਲ ਵੈੱਬ-ਆਨਲੀ ਹੈ”)।
ਇੱਕ ਸਧਾਰਣ ਲਿਖਣ ਦਾ ਤਰੀਕਾ:
ਫਿਰ ਉਹ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਲਿਸਟ ਕਰੋ ਜੋ ਬਚਣਾ ਮুশਕਲ ਹੈ। ਸਿਸਟਮਾਂ ਦਾ ਨਾਮ ਲਿਖੋ (payments, email, analytics, CRM) ਅਤੇ ਕਠੋਰ ਸੀਮਾਵਾਂ ਨੋਟ ਕਰੋ। ਉਦਾਹਰਨ: “ਬਿਲਿੰਗ ਲਈ Stripe ਵਰਤਣਾ ਲਾਜ਼ਮੀ ਹੈ,” “ਈਮੇਲ ਸਾਡੇ ਮੌਜੂਦਾ ਪ੍ਰੋਵਾਈਡਰ ਰਾਹੀਂ ਭੇਜੀ ਜਾਵੇ,” “Analytics ਵਿੱਚ ਨਿੱਜੀ ਡਾਟਾ ਟਰੈਕ ਨਹੀਂ ਹੋਵੇ।” ਜੇ authentication ਫਿਕਸ ਹੈ (SSO, Google login, passwordless), ਤਾਂ ਉਸਨੂੰ ਵੀ ਸਪੱਸ਼ਟ ਕਰੋ।
ਹੋਸਟਿੰਗ ਚੋਣ ਆਰਕੀਟੈਕਚਰ ਬਦਲ ਦਿੰਦੀ ਹੈ। ਲਿਖੋ ਕਿ ਐਪ ਕਿੱਥੇ ਚੱਲਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਕਿਉਂ: “Germany ਵਿੱਚ ਡਿਪਲੋਇ ਹੋਵੇ,” “ਡੇਟਾ EU ਵਿੱਚ ਰਹੇ,” ਜਾਂ “ਗਲੋਬਲ ਤੌਰ 'ਤੇ ਚੱਲ ਸਕਦਾ।”
ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਕੰਪਲਾਇੰਸ ਲੋੜਾਂ ਹਨ, ਉਦਾਹਰਣ-ਰੂਪ ਵਿੱਚ ਉਨ੍ਹਾਂ ਨੂੰ ਕਾਂਕਰੀਟ ਰੱਖੋ: ਰਿਟੇਨਸ਼ਨ ਅਵਧੀ, ਡਿਲੀਸ਼ਨ ਨਿਯਮ, ਅਤੇ ਆਡੀਟ ਦੀ ਲੋੜ।
ਉਦਾਹਰਨ: “ਰਿਕਾਰਡ 7 ਸਾਲ ਲਈ ਸਟੋਰ ਕਰੋ, ਤਸਦੀਕ ਕੀਤੇ ਬੇਨਤੀ 'ਤੇ 30 ਦਿਨਾਂ ਵਿੱਚ ਮਿਟਾਇਆ ਜਾਵੇ, ਕਿਸਨੇ ਰਿਕਾਰਡ ਵੇਖਿਆ ਇਸ ਦਾ ਆਡੀਟ ਲੌਗ ਰੱਖੋ, ਅਤੇ ਸਿਰਫ ਉਸੇ ਦੇਸ਼ ਵਿੱਚ ਡਿਪਲੋਇ ਕਰੋ ਜਿੱਥੇ ਮਰੀਜ਼ ਰਹਿੰਦੇ ਹਨ।” ਇਹ ਲਾਈਨਾਂ ਅੰਤ ਵਿੱਚ ਤੁਹਾਡੇ ਤਿਆਰ ਹੋਣ ਵੇਲੇ ਦੇਰ ਨਾਲ ਆਉਂਦੀਆਂ ਹੈਰਾਨੀਆਂ ਨੂੰ ਰੋਕਦੀਆਂ ਹਨ।
ਨਾਨ-ਗੋਲ ਸਪੈਸ ਦੇ ਗਾਰਡਰੇਲ ਹਨ। ਇਹ ਦੱਸਦੇ ਹਨ ਕਿ ਤੁਸੀਂ ਕੀ ਨਹੀਂ ਬਣਾ ਰਹੇ, ਸਮਰਥਨ ਨਹੀਂ ਕਰ ਰਹੇ, ਜਾਂ ਪਹਿਲੀ ਰਿਲੀਜ਼ ਵਿੱਚ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸੁਧਾਰ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕਰ ਰਿਹੇ। ਇਹ ਇੱਕ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਿਆਂ ਵਿੱਚੋਂ ਹੈ ਹੈਰਾਨੀਆਂ ਘਟਾਉਣ ਦੀ, ਕਿਉਂਕਿ ਬਹੁਤ ਸਾਰੇ “ਛੋਟੇ” ਬੇਨਤੀ ਬਾਅਦ ਵਿੱਚ ਆਉਂਦੀਆਂ ਹਨ ਅਤੇ ਨਰਮਾਈ ਨਾਲ ਪੂਰੇ ਯੋਜਨਾ ਨੂੰ ਬਦਲ ਦਿੰਦੀਆਂ ਹਨ।
ਇੱਕ ਚੰਗਾ ਨਾਨ-ਗੋਲ ਇੱਕ ਵਾਕ ਵਿੱਚ ਇੰਨਾ ਸਪਸ਼ਟ ਹੋਵੇ ਕਿ ਟੀਮ ਦਾ ਕੋਈ ਮੈਂਬਰ ਤੁਰੰਤ ਸਕੋਪ ਕ੍ਰੀਪ ਨੋਟ ਕਰ ਸਕੇ। ਇਹ ਸਮੇਂ-ਬੱਧ ਵੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। “v1 ਵਿੱਚ ਨਹੀਂ” “ਅਸੀਂ ਇਹ ਨਹੀਂ ਕਰੋਗੇ” ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਸਪਸ਼ਟ ਹੈ।
ਲੋਕਾਂ ਅਕਸਰ ਉਹ ਫੀਚਰ ਮਨ ਲੈਂਦੇ ਹਨ ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਸ਼ਾਮਲ ਮੰਨੇ ਜਾਂਦੇ ਹਨ। ਸਧਾਰਨ ਬੁਕਿੰਗ ਐਪ ਲਈ, ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਹੋ ਸਕਦਾ ਹੈ:
ਇਹ ਫੀਚਰ ਬੁਰੇ ਨਹੀਂ ਹਨ; ਇਹ ਮਹਿੰਗੇ ਹਨ। ਉਨ੍ਹਾਂ ਨੂੰ ਲਿਖਣ ਨਾਲ ਪਹਿਲੀ ਰਿਲੀਜ਼ ਫੋਕਸ ਰਹਿੰਦੀ ਹੈ।
ਉਸਦੇ ਨਾਲ-ਨਾਲ ਉਹ “ਡਿਟੇਲ” ਆਈਟਮ ਵੀ ਦਰਜ ਕਰੋ ਜੋ ਵੱਡੀਆਂ ਲੜੀਵਾਰ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਕਰਦੇ ਹਨ: ਰੋਲ, ਪਰਮੀਸ਼ਨ, ਅਤੇ ਐੱਡਜ-ਕੇਸ ਵਰਕਫਲੋ। “ਕੋਈ ਕਸਟਮ ਰੋਲ ਨਹੀਂ। ਕੇਵਲ ਦੋ ਰੋਲ: Owner ਅਤੇ Member.” ਇਹ ਇੱਕ ਲਾਈਨ ਕਈ ਹਫ਼ਤੇ ਬਚਾ ਸਕਦੀ ਹੈ।
ਟੀਮਾਂ ਅਕਸਰ ਉਹ ਨਾਨ-ਗੋਲ ਭੁੱਲ ਜਾਂਦੀਆਂ ਜੋ ਫੀਚਰ ਦੀ ਸ਼੍ਰੇਣੀ ਵਿੱਚ ਨਹੀਂ ਆਉਂਦੀਆਂ। ਇਹ ਬਾਅਦ ਵਿੱਚ ਦੁਖਦਾਈ ਮੁੜ-ਬਣਾਉਣ ਵਜੋਂ ਆ ਜਾਂਦੀਆਂ ਹਨ।
ਤੈਅ ਕਰੋ ਕਿ ਤੁਸੀਂ ਕਿਸ ਗੱਲ ਲਈ ਅਪਟਿਮਾਈਜ਼ ਨਹੀਂ ਕਰ ਰਹੇ। ਉਦਾਹਰਨ ਲਈ: “ਅਸੀਂ 1M ਯੂਜ਼ਰਾਂ ਲਈ ਟਿਊਨ ਨਹੀਂ ਕਰਾਂਗੇ। v1 ਲਈ ਅਸੀਂ 500 ਹਫਤਾਵਾਰ ਐਕਟਿਵ ਯੂਜ਼ਰ ਤੱਕ ਦੀ ਗਣਨਾ ਕਰਦੇ ਹਾਂ।”
ਇਸਦੇ ਨਾਲ ਇਹ ਵੀ ਨੋਟ ਕਰੋ ਕਿ ਤੁਸੀਂ ਕੀ ਸਹਾਇਤਾ ਨਹੀਂ ਕਰੋਗੇ, ਤਾਂ ਕਿ ਟੈਸਟਿੰਗ ਯਥਾਰਥ ਰਹੇ: “No Internet Explorer,” “ਕੋਈ ਟੈਬਲੇਟ-ਖਾਸ ਲੇਆਊਟ ਨਹੀਂ,” ਜਾਂ “ਲੌਗਿਨ ਕੇਵਲ ਈਮੇਲ ਅਤੇ ਪਾਸਵਰਡ (ਕੋਈ SSO, ਕੋਈ ਮੈਜਿਕ ਲਿੰਕ ਨਹੀਂ)।”
ਜਦੋਂ ਸਪੈਸ ਵਿੱਚ ਛੋਟੇ ਫੈਸਲੇ ਵਧਣ ਦੀ ਜਗ੍ਹਾ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਲੋਕ ਛੋਟੀ-ਛੋਟੀ ਬਦਲਾਉਂ ਕਰ ਸਕਦੇ ਹਨ ਬਿਨਾਂ ਪੂਰੇ ਯੋਜਨਾ ਨੂੰ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕੀਤੇ। ਇੱਕ ਛੋਟੀ “ਬਦਲ ਸਕਦਾ ਹੈ” ਲਿਸਟ ਲੋਕਾਂ ਨੂੰ ਪ੍ਰੋਡਕਟ ਸੁਧਾਰਨ ਲਈ ਜਗ੍ਹਾ ਦਿੰਦੀ ਹੈ ਬਿਨਾਂ ਸਭ ਕੁਝ ਦੁਬਾਰਾ ਖੋਲ੍ਹੇ।
ਹਕੀਕਤ-ਪੱਖੀ ਬਣਾਓ। ਉਹ ਚੀਜ਼ਾਂ ਕਵਰ ਕਰੋ ਜਿਨ੍ਹਾਂ ਬਾਰੇ ਤੁਸੀਂ ਉਮੀਦ ਕਰਦੇ ਹੋ ਕਿ ਇੱਕ ਕੰਮ ਕਰਨ ਵਾਲੇ ਵਰਜ਼ਨ ਦੇਖਣ ਤੋਂ ਬਾਅਦ ਸਿੱਖਿਆ ਮਿਲੇਗੀ, ਨਾ ਕਿ ਵੱਡੇ ਨਵੇਂ ਫੀਚਰ। ਆਮ ਲਚਕੀਲੇ ਆਈਟਮਾਂ ਵਿੱਚ UI ਟੈਕਸਟ, ਛੋਟੇ ਫਲੋ ਟਵੀਕ, ਰਿਪੋਰਟਿੰਗ ਕਾਲਮ, ਨਾਂ (ਰੋਲ, ਸਟੇਟਸ, ਸ਼੍ਰੇਣੀ), ਅਤੇ ਬੁਨਿਆਦੀ ਲੇਆਊਟ ਚੋਣ ਸ਼ਾਮਲ ਹੋ ਸਕਦੀਆਂ ਹਨ।
ਅਗਲੇ ਤੋਂ, ਫੈਸਲਾ ਕਰੋ ਕਿ ਬਦਲਾਅ ਕਿਵੇਂ ਮਨਜ਼ੂਰ ਹੋਣਗੇ। ਇਕ ਸਧਾਰਣ ਮਨਜ਼ੂਰ ਕਰਨ ਵਾਲੀ ਪ੍ਰਕਿਰਿਆ ਬਹੁਤ ਟੀਮਾਂ ਲਈ ਕੰਮ ਕਰਦੀ ਹੈ:
ਮੁੱਖ ਨਿਯਮ: ਲਚਕੀਲੇ ਬਦਲਾਅ ਫਿਕਸ ਪਾਬੰਦੀਆਂ ਨੂੰ ਤੋੜ ਨਹੀਂ ਸਕਦੇ। ਜੇ ਤੁਹਾਡਾ ਸਟੈਕ React + Go + PostgreSQL ਲੌਕ ਹੈ, ਤਾਂ “ਬਦਲ ਸਕਦਾ ਹੈ” ਦੀ ਬੇਨਤੀ “ਚਲੋ ਬੈਕਐਂਡ ਸਵਿੱਚ ਕਰੀਏ” ਨਹੀਂ ਹੋ ਸਕਦੀ। ਜੇ ਡੇਡਲਾਈਨ ਫਿਕਸ ਹੈ, ਤਾਂ “ਬਦਲ ਸਕਦਾ” ਦਾ ਮਤਲਬ ਇੱਕ ਨਵੇਂ ਮੋਡੀਊਲ ਦਾ ਜੁੜਨਾ ਨਹੀਂ ਹੋ ਸਕਦਾ ਜੋ ਦੋ ਹਫ਼ਤੇ ਹੋਰ ਲੈਂਦਾ।
ਹਰੇਕ ਲਈ ਇੱਕ ਟਰੇਡ-ਆਫ਼ ਨੋਟ ਸ਼ਾਮਲ ਕਰੋ ਜਿਸ 'ਤੇ ਸਭ ਸਹਿਮਤ ਹੋਣ। ਉਦਾਹਰਨ: “ਜੇ ਅਸੀਂ ਇੱਕ ਨਵਾਂ ਯੂਜ਼ਰ ਰੋਲ ਜੋੜਦੇ ਹਾਂ ਜਿਸ ਦੀਆਂ ਕਸਟਮ ਪਰਮੀਸ਼ਨਾਂ ਹੋਣ, ਤਾਂ ਅਸੀਂ ਅਡਵਾਂਸਡ ਰਿਪੋਰਟਿੰਗ ਨੂੰ ਫੇਜ਼ 2 ਵਿਚ ਡੇਲੈ ਕਰ ਦੇਵਾਂਗੇ।”
ਇੱਕ ਵਧੀਆ ਸਪੈਸ ਵਿਕਲਪ ਵਧਾਉਣ ਨਾਲ ਸ਼ੁਰੂ ਕਰਨ ਦੀ بجائے ਵਿਕਲਪ ਘਟਾ ਕੇ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ। ਇਹ ਫਾਰਮੈਟ ਤੁਹਾਨੂੰ ਨਿਰਮਾਣ ਦੀ ਸ਼ੁਰੂਆਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਨਿਯਮ ਲਿਖਣ ਲਈ ਮਜ਼ਬੂਰ ਕਰਦਾ ਹੈ।
ਡੌਕ ਦੇ ਹੈਡਰ ਵਿੱਚ ਇਹ ਵਰਤੋ:
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]
(ਕੋਡ ਫੇਂਸ ਅੰਦਰ ਦੀ ਵਸਤੂ ਬਦਲੀ ਨਹੀਂ ਕਰਨੀ—ਉਸਨੂੰ ਜਿਵੇਂ ਦਾ ਤਿਵੇਂ ਰੱਖੋ.)
ਬਹੁਤ ਸਾਰੀਆਂ ਹੈਰਾਨੀਆਂ ਕਿਸਮਤ ਨਹੀਂ ਹੁੰਦੀਆਂ—ਉਹ ਇਸ ਕਰਕੇ ਹੁੰਦੀਆਂ ਹਨ ਕਿ ਸਪੈਸ ਵੱਖ-ਵੱਖ ਅਰਥ ਬਿਆਨ ਕਰਨ ਲਈ ਰਾਹ ਛੱਡ ਦਿੰਦਾ ਹੈ।
ਇੱਕ ਆਮ ਫੰਦਾ ਹੈ ਟੀਚਾ ਅਤੇ ਹੱਲ ਮਿਲਾ ਦੇਣਾ। ਟੀਮਾਂ ਸਕਰੀਨਾਂ ਅਤੇ ਵਰਕਫਲੋ 'ਤੇ ਸਿੱਧਾ ਕੂਦ ਪੈਂਦੀਆਂ ਹਨ ਬਿਨਾਂ ਇਹ ਦਿੱਸਣ ਦੇ ਕਿ ਕੀ ਫਿਕਸ ਹੈ (ਡੇਡਲਾਈਨ, ਬਜਟ, ਟੈਕ ਸਟੈਕ) ਅਤੇ ਕੀ ਸਕੋਪ ਤੋਂ ਬਾਹਰ ਹੈ। ਨਤੀਜਾ ਇੱਕ ਸੋਹਣਾ UI ਪਲੈਨ ਹੁੰਦਾ ਹੈ ਜੋ ਪਾਬੰਦੀਆਂ ਦੇ ਅੰਦਰ ਫਿੱਟ ਨਹੀਂ ਹੋ ਸਕਦਾ।
ਦੂਜਾ ਫੰਦਾ ਹੈ ਅਸਪਸ਼ਟ ਨਾਨ-ਗੋਲ। “ਕੋਈ ਵਾਧੂ ਫੀਚਰ ਨਹੀਂ” ਕਠੋਰ ਲੱਗਦਾ ਹੈ, ਪਰ ਜਦ ਕੋਈ “ਸਿਰਫ ਇਕ ਹੋਰ ਰਿਪੋਰਟ” ਜਾਂ “ਤੁਰੰਤ ਇਕ ਢੁੱਕਵਾਂ ਐਡਮਿਨ ਪੈਨਲ” ਮੰਗੇ ਤਾਂ ਇਹ ਸਕੋਪ ਕ੍ਰੀਪ ਨੂੰ ਰੋਕ ਨਹੀਂ ਕਰਦਾ। ਚੰਗੇ ਨਾਨ-ਗੋਲ ਸਪਸ਼ਟ ਅਤੇ ਟੈਸਟਬਲ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ।
ਚੁਪ-ਚੁਪ ਬਜਟ ਜਾਂ “ਸੌਫਟ” ਡੇਡਲਾਈਨ ਵੀ ਸਕੋਪ ਬੰਬ ਹਨ। ਜੇ ਅਸਲੀ ਬਜਟ $5k ਹੈ ਪਰ ਸਪੈਸ $50k ਵਰਗਾ ਦਿਸਦਾ ਹੈ, ਤਾਂ ਟੀਮ ਗਲਤ ਚੀਜ਼ ਬਣਾਏਗੀ। ਨਾ-ਆਰਾਮਦਾਇਕ ਨੰਬਰ ਪੰਨੇ 'ਤੇ ਰੱਖੋ।
ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਅਤੇ ਡੇਟਾ ਮਲਕੀਅਤ ਵੀ ਖਾਮੋਸ਼ ਹੈਰਾਨੀਆਂ ਪੈਦਾ ਕਰਦੇ ਹਨ। ਜੇ ਤੁਸੀਂ ਕਹਿੰਦੇ ਹੋ “Stripe ਨਾਲ ਜੁੜੋ” ਪਰ ਇਹ ਨਿਰਧਾਰਤ ਨਹੀਂ ਕਰਦੇ ਕਿ ਕਿਹੜੇ ਇਵੈਂਟ, ਕਿਹੜੇ ਫੀਲਡ ਅਤੇ ਡਾਟਾ ਕੌਣ ਰੱਖਦਾ, ਤਾਂ ਤੁਸੀਂ ਇਕੋ ਫੈਸਲੇ ਨੂੰ ਕਈ ਵਾਰ ਦੁਹਰਾਉਂਦੇ ਹੋ।
ਅਖੀਰਲਾ ਫੰਦਾ ਹੈ ਮੱਧ-ਬਣਾਉ ਦੇ ਦੌਰਾਨ ਪਾਬੰਦੀਆਂ ਨੂੰ ਬਦਲਣਾ ਬਿਨਾਂ ਟਰੇਡ-ਆਫ਼ ਨਾਮ ਜ਼ਾਹਿਰ ਕੀਤੇ। “ਵੈੱਬ-ਓਨਲੀ” ਤੋਂ “ਵੈੱਬ + ਮੋਬਾਈਲ” ਤੱਕ ਬਦਲਣਾ ਜਾਂ “Postgres” ਤੋਂ “ਸਭ ਤੋਂ ਸਸਤਾ” ਕਰਨ ਦਾ ਫੈਸਲਾ ਯੋਜਨਾ ਬਦਲ ਦੇਂਦਾ। ਤੁਸੀਂ ਬਦਲ ਸਕਦੇ ਹੋ, ਪਰ ਤੁਹਾਨੂੰ ਸਕੋਪ, ਟਾਈਮਲਾਈਨ ਜਾਂ ਗੁਣਵੱਤਾ ਦੀਆਂ ਉਮੀਦਾਂ ਅੱਪਡੇਟ ਕਰਨੀ ਹੋਵੇਗੀ।
ਆਪਣੀ ਸਪੈਸ ਵਿੱਚ ਇੱਕ ਛੋਟਾ ਨੋਟ ਸ਼ਾਮਲ ਕਰੋ ਜੋ ਪੰਜ ਬਿੰਦੂਆਂ ਨੂੰ ਪਤਾ ਦਿੰਦਾ:
ਕਿਸੇ ਨੇ ਵੀ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ, ਤੁਹਾਨੂੰ “ਕੀ ਫਿਕਸ ਹੈ?” ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਬਿਨਾਂ ਕਿਸੇ ਲੰਬੇ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਖੋਜਣ ਦੇ ਦੇ ਸਕਣਾ ਚਾਹੀਦਾ ਹੈ।
ਤੇਜ਼ ਚੈੱਕ:
ਜੇ ਇਨ੍ਹਾਂ ਵਿਚੋਂ ਕੋਈ ਇਕ ਨਹੀਂ ਹੈ, ਤਾਂ ਪਹਿਲੀ ਬਿਲਡ ਹੋ ਜਾਏਗੀ, ਪਰ ਦੂਜੀ ਬਿਲਡ ਅਸਲ ਹੋਵੇਗੀ।
ਅਗਲੇ ਕਦਮ ਜੋ ਗਲਤ ਫੈਸਲਿਆਂ 'ਤੇ ਤੁਹਾਨੂੰ ਲਾਕ ਨਹੀਂ ਕਰਦੇ:
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. (ਇਸ ਵਾਕ ਨੂੰ ਜਿਵੇਂ ਦਾ ਤਿਵੇਂ ਰੱਖੋ, ਕਿਉਂਕਿ ਇਹ ਇੱਕ ਬਰਾਂਡ ਅਤੇ ਡੋਮੇਨ ਹੈ.)
ਜਦੋਂ ਇਹ ਨਿਯਮ ਪਹਿਲਾਂ ਲਿਖੇ ਜਾਂਦੇ ਹਨ, ਫੀਚਰ ਚਰਚਾ ਅਸਾਨ ਹੋ ਜਾਂਦੀ ਹੈ ਕਿਉਂਕਿ ਹਰ ਕੋਈ ਜਾਣਦਾ ਹੈ ਕਿ ਕੀ ਫਿਕਸ ਰਹੇਗਾ ਅਤੇ ਕੀ ਹਿਲ ਸਕਦਾ ਹੈ।
ਦੋਹਰਾ ਕੰਮ ਉਹ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਕੋਈ ਚੀਜ਼ ਬਣਾਉਂਦੇ ਹੋ ਜੋ ਕੰਮ ਕਰਦੀ ਤਾਂ ਹੈ, ਪਰ ਪ੍ਰੋਜੈਕਟ ਲਈ ਗਲਤ ਹੁੰਦੀ ਹੈ ਕਿਉਂਕਿ ਕੋਈ ਮੁੱਖ ਫੈਸਲਾ ਦੇਰ ਨਾਲ ਆ ਗਿਆ। ਅਕਸਰ ਇਹ ਉਸ ਵੇਲੇ ਹੁੰਦਾ ਹੈ ਜਦ/specs ਪਹਿਲਾਂ ਮਹੱਤਪੂਰਨ ਪਾਬੰਦੀਆਂ ਨਹੀਂ ਦੱਸਦੀਆਂ, ਇਸ ਲਈ ਟੀਮ ਨੇ ਮਨੁਆਉਣ ਤਰੀਕੇ ਅਨੁਸਾਰ ਕੰਮ ਕੀਤਾ ਜੋ ਬਾਅਦ ਵਿੱਚ ਗਲਤ ਸਾਬਤ ਹੁੰਦੇ ਹਨ।
ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਉਹ ਚੀਜ਼ ਲਿਖੋ ਜੋ ਬਿਨਾਂ ਵੱਡੇ ਤਰਜੀਹ ਦੇ ਬਦਲ ਨਹੀਂ ਸਕਦੀ — ਜਿਵੇਂ ਡੇਡਲਾਈਨ, ਬਜਟ ਕੈਪ, ਹੋਸਟਿੰਗ ਰੀਜਨ, ਲਾਜ਼ਮੀ ਸਟੈਕ ਅਤੇ ਕੰਪਲਾਇੰਸ ਨਿਯਮ. ਫਿਰ ਇੱਕ ਛੋਟੀ ਨਾਨ-ਗੋਲ ਸੈਕਸ਼ਨ ਸ਼ਾਮਲ ਕਰੋ ਤਾਂ ਕਿ ਲੋਕ “ਛੋਟੇ” ਐਡ-ਓਨਜ਼ ਨਾਲ ਦਾਇਰਾ ਵਧਾਉਂ ਨਾ ਦੇਣ।
ਪਾਬੰਦੀ ਉਸ ਗੱਲ ਨੂੰ ਸੀਮਤ ਕਰਦੀ ਹੈ ਕਿ ਤੁਸੀਂ ਕਿਵੇਂ ਬਣਾ ਰਹੇ ਹੋ (ਜਿਵੇਂ “EU ਵਿੱਚ ਚਲਣਾ ਚਾਹੀਦਾ” ਜਾਂ “React ਅਤੇ PostgreSQL ਵਰਤਣੇ ਜ਼ਰੂਰੀ”)। ਨਾਨ-ਗੋਲ ਇਹ ਸੀਮਤ ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਕੀ ਨਹੀਂ ਬਣਾਉਣਗੇ (ਜਿਵੇਂ “v1 ਵਿੱਚ ਕੋਈ ਮੋਬਾਈਲ ਐਪ ਨਹੀਂ” ਜਾਂ “ਲਾਂਚ ਤੇ ਕੋਈ ਕਸਟਮ رول ਨਹੀਂ”).
ਇਸਨੂੰ ਇੱਕ ਟੈਸਟਬਲ ਵਾਕ ਦੀ ਤਰ੍ਹਾਂ ਲਿਖੋ, ਨਾ ਕਿ ਪਸੰਦ। ਜੇ ਕੋਈ ‘‘ਸ਼ਾਇਦ’’ ਕਹਿ ਸਕਦਾ ਹੈ ਤੇ ਕਿਸੇ ਦਾ ਫੈਸਲਾ ਨਾਹ ਹੋਵੇ, ਤਾਂ ਇਹ ਹਾਲੇ ਤੱਕ ਅਸਲ ਪਾਬੰਦੀ ਨਹੀਂ—ਉਹ ਖੁੱਲ੍ਹਾ ਸਵਾਲ ਹੈ।
3 ਤੋਂ 5 ਯੂਜ਼ਰ ਨਤੀਜਿਆਂ ਦੀ ਚੋਣ ਕਰੋ ਜੋ ਪਹਿਲੀ ਰਿਲੀਜ਼ ਲਈ ਸਫਲਤਾ ਦਰਸਾਉਂਦੇ ਹਨ, ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ। ਨਤੀਜੇ ਟੀਮ ਨੂੰ ਉਹਨਾਂ ਕੰਮਾਂ 'ਤੇ ਫੋਕਸ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ ਜਿਹੜੇ ਯੂਜ਼ਰਾਂ ਨੂੰ ਸੱਚਮੁੱਚ ਲੋੜੀਂਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਅਜਿਹੀਆਂ ਫੀਚਰਾਂ ਨੂੰ ਅਧਿਕਤਾ ਨਾ ਮਿਲੇ ਜੋ ਪਹਿਲੀ ਰਿਲੀਜ਼ ਲਈ ਜ਼ਰੂਰੀ ਨਹੀਂ।
ਅਕਸਰ ਛੁਪੀਆਂ ਹੋਈਆਂ ਪਾਬੰਦੀਆਂ: ਮੋਬਾਈਲ ਸਹਾਇਤਾ, ਰੋਲ ਅਤੇ ਪਰਮੀਸ਼ਨ, ਆਡੀਟ ਇਤਿਹਾਸ, ਡੇਟਾ ਰਿਹਾਇਸ਼, ਅਤੇ ਐਨਟੀਗ੍ਰੇਸ਼ਨ ਜੋ ਕਲਾਇੰਟ ਵਰਤ ਨਹੀਂ ਸਕਦਾ। ਜੇ ਇਹ ਸ਼ੁਰੂ ਵਿੱਚ ਸਾਹਮਣੇ ਆ ਜਾਣ, ਤਾਂ ਤੁਸੀਂ ਸਕਰੀਨ ਰੀਡਿਜ਼ਾਈਨ, ਡੇਟਾ ਮਾਡਲ ਬਦਲਣ ਜਾਂ ਪ੍ਰੋਵਾਈਡਰ ਬਦਲਣ ਤੋਂ ਬਚ ਜਾਵੋਗੇ।
ਸਪਸ਼ਟ ਅਤੇ ਸਮੇਂ-ਬੱਧ ਹੋਵੋ, ਜਿਵੇਂ “v1 ਵਿੱਚ ਨਹੀਂ” ਜਾਂ “ਅਸੀਂ ਟੇਬਲਟ ਸਪੋਰਟ ਨਹੀਂ ਕਰਾਂਗੇ।” ਇਕ ਅੰਧੇ-ਨੋਨ-ਗੋਲ ਜਿਵੇਂ “ਕੋਈ ਵਾਧੂ ਫੀਚਰ ਨਹੀਂ” ਸਕੋਪ ਕ੍ਰੀਪ ਰੋਕਣ ਲਈ ਕਾਫ਼ੀ ਨਹੀਂ ਹੁੰਦਾ ਕਿਉਂਕਿ ਉਹ ਕਿਸੇ ਵੱਖਰੇ ਬੇਨਤੀ ਨੂੰ ਰੋਕਦਾ ਨਹੀਂ।
ਲਿਖੋ ਕਿ ਕੌਣ ਬਦਲਾਅ ਮਨਜ਼ੂਰ ਕਰਦਾ ਹੈ, ਫੀਡਬੈਕ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਮਿਲਦਾ ਹੈ, ਅਤੇ ਬਦਲਾਅ ਕਿਸ ਕੈਡੰਸ 'ਤੇ ਵੇਖਿਆ ਜਾਵੇਗਾ। ਧੀਮੀ ਫੀਡਬੈਕ ਇੱਕ ਅਸਲ ਪਾਬੰਦੀ ਹੈ ਕਿਉਂਕਿ ਇਹ ਨਿਰਣਾਏ ਦੀ ਰਫ਼ਤਾਰ ਤੇ ਪ੍ਰਭਾਵ ਪਾਂਦੀ ਹੈ।
ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਖਾਸ ਮਾਲਿਕ ਅਤੇ ਨਿਯਤ ਮਿਆਦ ਨਾਲ ਖੁੱਲ੍ਹੇ ਸਵਾਲਾਂ ਵਜੋਂ ਲਿਖੋ, ਅਤੇ ਪ੍ਰਭਾਵਤ ਖੇਤਰਾਂ 'ਤੇ ਨਿਰਮਾਣ ਨਾ ਸ਼ੁਰੂ ਕਰੋ ਜਦ ਤੱਕ ਜਵਾਬ ਲੌਕ ਨਾ ਹੋਵੇ। ਜੇ ਤੁਰੰਤ ਸ਼ੁਰੂ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ, ਤਾਂ ਇਸ ਅਨੁਮਾਨ ਨੂੰ ਸਪੈਸ ਵਿੱਚ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਦਰਜ ਕਰੋ ਤਾਂ ਜੋ ਬਾਅਦ ਵਿੱਚ ਗਲਤਫਹਮੀ ਨਾ ਹੋਵੇ।
Planning Mode ਵਿੱਚ constraints ਅਤੇ non-goals ਲੌਕ ਕਰੋ ਤਾਂ ਜੋ ਪਹਿਲਾ ਡਰਾਫਟ ਤੁਹਾਡੇ ਸਟੈਕ, ਰੀਜਨ ਅਤੇ ਸਕੋਪ ਨਾਲ ਮਿਲਦਾ ਹੋਵੇ। ਜੇ ਪ੍ਰਾਥਮਿਕਤਾਵਾਂ ਬਦਲਦੀਆਂ ਹਨ, ਤਾਂ snapshots ਅਤੇ rollback ਫੀਚਰ ਬਿਨਾਂ ਸਥਿਰ ਬੇਸਲਾਈਨ ਗੁਆਉਣ ਦੇ ਬਦਲਾਅ ਟੈਸਟ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ, ਅਤੇ source code export ਉਨ੍ਹਾਂ ਹਾਲਾਤਾਂ ਵਿੱਚ ਲਾਭਦਾਇਕ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਕੰਮ ਨੂੰ ਦੂਜੇ ਥਾਂ ਲੈ ਜਾਣਾ ਪਏ।