ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਇਹ ਵੇਰਵਾ ਕਿ SpaceX ਨੇ ਵਰਟੀਕਲ ਇੰਟੀਗਰੇਸ਼ਨ ਨਾਲ ਕਿਵੇਂ ਤੇਜ਼ ਫੀਡਬੈਕ ਲੂਪ بنایا, ਰਾਕੇਟਾਂ ਨੂੰ ਸਾਫਟਵੇਅਰ ਵਾਂਗ ਸੁਧਾਰਨ ਲਾਇਕ ਕੀਤਾ—ਅਤੇ ਕਿਵੇਂ ਲਾਂਚ ਕੈਡੰਸ ਇੱਕ ਮੋਅਟ ਬਣ ਜਾਂਦੀ ਹੈ।
SpaceX ਦਾ ਪਰਿਭਾਸ਼ਕ ਦਾਉ ਸਿਰਫ "ਰਾਕੇਟਾਂ ਨੂੰ ਰੀਯੂਜ਼ਬਲ ਬਣਾਉ" ਨਹੀਂ ਹੈ। ਇਸਦਾ ਮੰਨਣ ਇਹ ਹੈ ਕਿ ਇੱਕ ਰਾਕੇਟ ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਸਫਟਵੇਅਰ-ਵਾਂਗ ਸੋਚ ਨਾਲ ਚਲਾਇਆ ਜਾ ਸਕਦਾ ਹੈ: ਇੱਕ ਵਰਕਿੰਗ ਵਰਜਨ ਸ਼ਿਪ ਕਰੋ, ਅਸਲ-ਸੰਚਾਲਨ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ ਸਿੱਖੋ, ਅਤੇ ਉਹ ਸਿੱਖਿਆ ਅਗਲੇ ਨਿਰਮਾ ਵਿੱਚ ਜੋੜੋ—ਫਿਰ ਦੋਹਰਾਓ।
ਇਹ ਫਰੇਮਿੰਗ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਇਹ ਲਕੜੀ 'ਤੇ "ਇੱਕ ਪਰਫੈਕਟ" ਵਾਹਨ ਬਣਾਉਣ ਦੇ ਲਕੜ ਨੂੰ ਬਦਲ ਕੇ ਇੱਕ ਸੁਧਾਰ ਇੰਜਣ ਬਣਾਉਣ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰਦੀ ਹੈ। ਤੁਹਾਨੂੰ ਹਮੇਸ਼ਾ ਏਅਰੋਸਪੇਸ-ਗਰੇਡ ਇੰਜੀਨੀਅਰਿੰਗ ਅਤੇ ਸੁਰੱਖਿਆ ਦੀ ਲੋੜ ਹੈ। ਪਰ ਤੁਸੀਂ ਹਰ ਲਾਂਚ, ਲੈਂਡਿੰਗ, ਟੈਸਟ ਫਾਇਰ ਅਤੇ ਰੀਫਰਬਿਸ਼ਮੈਂਟ ਨੂੰ ਡੇਟਾ ਵਾਂਗ ਲੈਂਦੇ ਹੋ ਜੋ ਡਿਜ਼ਾਈਨ ਅਤੇ ਆਪਰੇਸ਼ਨਾਂ ਨੂੰ ਤਿੱਖਾ ਕਰਦਾ ਹੈ।
ਕੈਡੰਸ—ਤੁਸੀਂ ਕਿੰਨੀ ਵਾਰ ਲਾਂਚ ਕਰਦੇ ਹੋ—ਇਟਰੇਸ਼ਨ ਨੂੰ ਇੱਕ ਨਾਅਰੇ ਤੋਂ ਇੱਕ ਗੁਣਾ ਵਾਲਾ ਫਾਇਦਾ ਬਣਾ ਦਿੰਦਾ ਹੈ।
ਜਦੋਂ ਉਡਾਣਾਂ ਵੱਖ-ਵੱਖ ਘਟਿਤ ਹੁੰਦੀਆਂ ਹਨ, ਫੀਡਬੈਕ ਧੀਮਾ ਹੋ ਜਾਂਦਾ ਹੈ। ਸਮੱਸਿਆਵਾਂ ਮੁੜ ਬਣਾਉਣ ਵਿੱਚ ਜ਼ਿਆਦਾ ਵੇਲਾ ਲੱਗਦਾ ਹੈ, ਟੀਮਾਂ ਸੰਦਰਭ ਖੋ ਦੇਂਦੀਆਂ ਹਨ, ਸਪਲਾਇਰ ਹਿੱਸੇ ਬਦਲ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਸੁਧਾਰ ਵੱਡੇ, ਜੋਖਿਮ ਭਰੇ ਬੈਚਾਂ ਵਿੱਚ ਆਉਂਦੇ ਹਨ।
ਜਦੋਂ ਉਡਾਣਾਂ ਬਾਰੰਬਾਰ ਹੁੰਦੀਆਂ ਹਨ, ਫੀਡਬੈਕ ਲੂਪ ਛੋਟੇ ਹੋ ਜਾਂਦੇ ਹਨ। ਤੁਸੀਂ ਵੱਖ-ਵੱਖ ਹਾਲਤਾਂ ਵਿੱਚ ਪ੍ਰਦਰਸ਼ਨ ਦੇਖਦੇ ਹੋ, ਫਿਕਸਾਂ ਨੂੰ ਤੇਜ਼ ਪੁਸ਼ਟੀ ਕਰਦੇ ਹੋ, ਅਤੇ ਸਾਂਝੀ ਯਾਦਦਾਸ਼ਤ ਬਣਦੀ ਹੈ। ਸਮੇਂ ਦੇ ਨਾਲ, ਉੱਚ ਕੈਡੰਸ ਲਾਗਤ ਘਟਾ ਸਕਦੀ ਹੈ (ਸਥਿਰ ਉਤਪਾਦਨ ਅਤੇ ਰੀਯੂਜ਼ ਰਾਹੀਂ) ਅਤੇ ਭਰੋਸਾ ਵਧਾ ਸਕਦੀ ਹੈ (ਅਸਲ ਚਾਲੂ ਹਾਲਾਤਾਂ ਦੇ ਦੁਹਰਾਏ ਜਾਣ ਨਾਲ)।
ਇਹ ਲੇਖ ਤੇਜ਼ੀਸ਼ਟੀ, ਨਾ ਕਿ ਸ਼ੋਭਾ-ਬਾਜੀ 'ਤੇ ਕੇਂਦਰਿਤ ਹੈ। ਅਸੀਂ ਨੰਬਰਾਂ ਜਾਂ ਵਿਆਪਕ ਦਾਅਵਿਆਂ 'ਤੇ ਨਾਹਾਂ ਕਰਾਂਗੇ। ਇਸ ਦੀ ਬਜਾਏ, ਅਸੀਂ ਅਮਲੀ ਪ੍ਰਣਾਲੀ ਦੇਖਾਂਗੇ: ਕਿਵੇਂ ਨਿਰਮਾਣ, ਇੰਟੀਗ੍ਰੇਸ਼ਨ, ਆਪਰੇਸ਼ਨ ਅਤੇ ਸਿੱਖਣ ਦੀ ਗਤੀ ਇਕ-दੂਜੇ ਨੂੰ ਮਜ਼ਬੂਤ ਕਰਦੇ ਹਨ।
ਇਟਰੇਸ਼ਨ: ਬਣਾਉਣਾ, ਟੈਸਟ ਕਰਨਾ, ਸਿੱਖਣਾ ਅਤੇ ਅਪਡੇਟ ਕਰਨਾ—ਅਕਸਰ ਵੱਡੇ ਰੀ-ਡਿਜ਼ਾਈਨਾਂ ਦੀ ਬਜਾਏ ਛੋਟੇ, ਤੇਜ਼ ਕਦਮਾਂ ਵਿੱਚ।
ਇੰਟੀਗ੍ਰੇਸ਼ਨ (ਵਰਟੀਕਲ ਇੰਟੀਗ੍ਰੇਸ਼ਨ): ਡਿਜ਼ਾਈਨ ਅਤੇ ਨਿਰਮਾਣ ਤੋਂ ਲੈ ਕੇ ਸਾਫਟਵੇਅਰ ਅਤੇ ਆਪਰੇਸ਼ਨ ਤੱਕ "ਸਟੈਕ" ਦਾ ਜ਼ਿਆਦਾ ਹਿੱਸਾ ਆਪਣੇ ਹੱਥ ਵਿੱਚ ਰੱਖਣਾ, ਤਾਂ ਜੋ ਫ਼ੈਸਲੇ ਅਤੇ ਬਦਲਾਅ ਲੰਬੇ ਬਾਹਰੀ ਹੱਥਾਂ-ਹਥੌੜਿਆਂ 'ਤੇ ਨਾਹ ਰੁਿਕਣ।
ਮੋਅਟ: ਇੱਕ ਟਿਕਾਊ ਫਾਇਦਾ ਜੋ ਮੁਕਾਬਲੇਦਾਰਾਂ ਲਈ ਨਕਲ ਕਰਨਾ ਮੁਸ਼ਕਿਲ ਹੁੰਦਾ ਹੈ। ਇੱਥੇ, ਮੋਅਟ ਇੱਕ ਇੱਕਲੌਤਾ ਐਜਾਦ ਨਹੀਂ; ਇਹ ਇੱਕ ਫਲਾਈ੍ਹਵ੍ਹੀਲ ਹੈ ਜਿਥੇ ਕੈਡੰਸ ਸਿੱਖਣ ਨੂੰ ਤੇਜ਼ ਕਰਦੀ ਹੈ, ਸਿੱਖਣ ਵਾਹਨਾਂ ਅਤੇ ਆਪਰੇਸ਼ਨਾਂ ਨੂੰ ਸੁਧਾਰਦੀ ਹੈ, ਅਤੇ ਉਹ ਸੁਧਾਰ ਵੱਧ ਕੈਡੰਸ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ।
ਆਮ ਸ਼ਬਦਾਂ ਵਿੱਚ ਵਰਟੀਕਲ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਮੁੱਖ ਹਿੱਸਿਆਂ ਨੂੰ ਲੰਬੀ ਸਪਲਾਇਰ ਲੜੀ ਤੋਂ ਖਰੀਦਣ ਦੀ ਬਜਾਏ ਆਪਣਾ ਬਣਾਇਆ ਜਾਵੇ। ਇੱਕ "ਸਿਸਟਮ ਇੰਟੀਗਰੇਟਰ" ਵਾਂਗ ਨਾ ਹੋ ਕੇ ਜੋ ਹੋਰ ਕੰਪਨੀਆਂ ਦੇ ਕੰਪੋਨੇਟ ਜੋੜਦਾ ਹੈ, ਤੁਸੀਂ ਡਿਜ਼ਾਈਨ ਅਤੇ ਨਿਰਮਾਣ ਦਾ ਜ਼ਿਆਦਾ-ਤੋਂ-ਜਿਆਦਾ ਅੰਤ-ਤੋਂ-ਅੰਤ ਕੰਟਰੋਲ ਰੱਖਦੇ ਹੋ।
ਪੁਰਾਣੀ-ਸਟਾਈਲ ਏਅਰੋਸਪੇਸ ਅਕਸਰ ਠੇਕੇਦਾਰਾਂ 'ਤੇ ਭਾਰੀ ਨਿਰਭਰ ਸੀ ਕਈ ਵਾਜਬ ਕਾਰਨਾਂ ਕਰਕੇ:
ਜਦੋਂ ਸਟੈਕ ਦਾ ਵੱਧ ਹਿੱਸਾ ਇੱਕ ਛਤ ਹੇਠਾਂ (ਜਾਂ ਇੱਕ ਅੰਦਰੂਨੀ ਟੀਮ ਦੀ ਸੀਮਾ) ਹੁੰਦਾ ਹੈ, ਤਦ ਕੋਆਰਡੀਨੇਸ਼ਨ ਸాదਾ ਹੋ ਜਾਂਦਾ ਹੈ। ਕੰਪਨੀਆਂ ਵਿਚਕਾਰ ਘੱਟ "ਇੰਟਰਫੇਸ" ਹੁੰਦੇ ਹਨ, ਘੱਟ ਕਾਂਟ੍ਰੈਕਚੁਅਲ ਹੱਦਾਂ ਹੁੰਦੀਆਂ ਹਨ, ਅਤੇ ਹਰ ਵਾਰੀ ਡਿਜ਼ਾਈਨ ਬਦਲਣ 'ਤੇ ਘੱਟ ਮੌਕੇ ਦੀ ਚਰਚਾ ਹੁੰਦੀ ਹੈ।
ਇਹ ਮੈਟਰ ਕਿਉਂਕਿ ਹਾਰਡਵੇਅਰ ਵਿੱਚ ਇਟਰੇਸ਼ਨ ਤੇਜ਼ ਲੂਪਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ:
ਵਰਟੀਕਲ ਇੰਟੀਗਰੇਸ਼ਨ ਆਪਣੇ ਆਪ ਵਿੱਚ ਨਹੀਂ ਚਮਕਦਾ। ਤੁਸੀਂ ਉੱਚ ਫਿਕਸ ਲਾਗਤਾਂ (ਫੈਸਿਲਟੀਜ਼, ਉਪਕਰਣ, ਕਰਮਚਾਰੀ) ਨੂੰ ਸੰਭਾਲਦੇ ਹੋ ਅਤੇ ਤੁਹਾਨੂੰ ਕਈ ਵਿਭਾਗਾਂ ਵਿੱਚ ਵਿਸ਼ਾਲ ਅੰਦਰੂਨੀ నిపੁੰਨਤਾ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਜੇ ਤੁਹਾਡੀ ਲਾਂਚ ਦਰ ਜਾਂ ਉਤਪਾਦਨ ਵਾਲੀਮ ਘਟਦੀ ਹੈ, ਤੁਸੀਂ ਉਹ ਲਾਗਤਾਂ ਫਿਰ ਵੀ ਚੁੱਕਦੇ ਹੋ।
ਇਹ ਨਵੇਂ ਅੰਦਰੂਨੀ ਬੋਤਲ-ਗਰਦੇ ਵੀ ਬਣਾਉਂਦਾ ਹੈ: ਜਦੋਂ ਤੁਸੀਂ ਹਰ ਚੀਜ਼ ਆਪਣੇ ਹੱਥ 'ਚ ਰੱਖਦੇ ਹੋ, ਤੁਸੀਂ ਜ਼ਿੰਮੇਵਾਰੀ ਆਊਟਸੋਰਸ ਨਹੀਂ ਕਰ ਸਕਦੇ—ਤੁਸੀਂ ਖੁਦ ਸਮਰੱਥਾ ਬਣਾਉਣੀ ਪੈਂਦੀ ਹੈ, ਅਤੇ ਇਹ ਲਗਾਤਾਰ ਪ੍ਰਬੰਧਕੀ ਧਿਆਨ ਮੰਗਦਾ ਹੈ।
SpaceX ਦੀ ਇਤਰੈਸ਼ਨ ਗਤੀ ਸਿਰਫ਼ ਡਿਜ਼ਾਈਨ ਦੀ ਕਹਾਣੀ ਨਹੀਂ—ਇਹ ਇੱਕ ਫੈਕਟਰੀ ਦੀ ਕਹਾਣੀ ਹੈ। ਨਿਰਮਾਣ ਦੀ ਗਤੀ ਟੈਸਟ ਗਤੀ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀ ਹੈ, ਜੋ ਡਿਜ਼ਾਈਨ ਦੀ ਗਤੀ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀ ਹੈ। ਜੇ ਅਗਲਾ ਯੂਨਿਟ ਬਣਾਉਣ ਲਈ ਹਫ਼ਤੇ ਲੱਗਦੇ ਹਨ, ਟੀਮ ਨੂੰ ਹਫ਼ਤੇ ਇੰਤਜ਼ਾਰ ਕਰਨਾ ਪੈਂਦਾ ਹੈ ਕਿ ਕੋਈ ਬਦਲਾਅ ਮਦਦਗਾਰ ਹੈ ਜਾਂ ਨਹੀਂ। ਜੇ ਦਿਨ ਲੱਗਦੇ ਹਨ, ਸਿੱਖਣਾ ਰੂਟੀਨ ਬਣ ਜਾਂਦਾ ਹੈ।
ਇੱਕ ਫੈਕਟਰੀ ਜੋ ਲਗਾਤਾਰ ਹਥਿਆਰਾਂ ਨੂੰ ਤੰਗ ਰਿਥਮ 'ਤੇ ਉਤਪਾਦ ਕਰ ਸਕਦੀ ਹੈ ਪਰਯੋਗਾਂ ਨੂੰ ਇੱਕ ਪਾਈਪਲਾਈਨ ਵਾਂਗ ਬਣਾ ਦਿੰਦੀ ਹੈ ਨਾਂ ਕਿ ਖਾਸ ਸਮਾਰੋਹ। ਇਹ ਮਹੱਤਵਪੂਰਣ ਹੈ ਕਿਉਂਕਿ ਰਾਕੇਟਾਂ "ਫੀਲਡ ਵਿੱਚ ਸਸਤੇ ਤੌਰ 'ਤੇ ਡੀਬੱਗ" ਨਹੀਂ ਹੁੰਦੀਆਂ; ਸਭ ਤੋਂ ਨੇੜਲਾ ਸਮਕਾਲੀ ਹੈ ਅਸਲ ਹਾਰਡਵੇਅਰ ਬਣਾਉਣਾ, ਟੈਸਟ ਕਰਨਾ ਅਤੇ ਉਡਾਉਣਾ। ਜਦੋਂ ਉਤਪਾਦਨ ਧੀਮਾ ਹੁੰਦਾ ਹੈ, ਹਰ ਟੈਸਟ ਕੀਮਤੀ ਹੁੰਦਾ ਹੈ ਅਤੇ ਸ਼ਡਿਊਲ ਨਜ਼ੁਕ ਹੋ ਜਾਂਦੇ ਹਨ। ਜਦੋਂ ਉਤਪਾਦਨ ਤੇਜ਼ ਹੁੰਦੀ ਹੈ, ਟੀਮਾਂ ਬਹੁਤ ਸਾਰੇ ਮੌਕੇ ਲੈ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ਹਾਲੇ ਵੀ ਜੋਖਿਮ ਕਾਬੂ ਵਿੱਚ ਰੱਖਦੇ ਹਨ।
ਮਿਆਰੀਕਰਨ ਇੱਕ ਚੁਪਚਾਪ ਐਕਸੇਲੇਰੇਟਰ ਹੈ: ਆਮ ਇੰਟਰਫੇਸ, ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਹਿੱਸੇ, ਅਤੇ ਸਾਂਝੇ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇਕ ਖੇਤਰ ਵਿੱਚ ਬਦਲਾਅ ਸਾਰਾ ਸਿਸਟਮ ਮੁੜ-ਡਿਜ਼ਾਈਨ ਨਾ ਕਰਵਾਏ। ਜਦੋਂ ਕਨੈਕਟਰ, ਮਾਊਂਟਿੰਗ ਪੁਆਇੰਟ, ਸਾਫਟਵੇਅਰ ਹੂਕ, ਅਤੇ ਟੈਸਟ ਪ੍ਰਕਿਰਿਆਵਾਂ ਸਤਤ ਹਨ, ਟੀਮਾਂ "ਇਸ ਨੂੰ ਫਿੱਟ ਕਰਨ" ਵਿੱਚ ਘੱਟ ਸਮਾਂ ਲਗਾਉਂਦੀਆਂ ਹਨ ਅਤੇ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਤੱਥਾਂ 'ਤੇ ਧਿਆਨ ਦਿੰਦੇ ਹਨ।
ਟੂਲਿੰਗ—ਜਿਗ, ਫਿਕਸਚਰ, ਟੈਸਟ ਸਟੈਂਡ ਅਤੇ ਮਾਪਣ ਪ੍ਰਣਾਲੀਆਂ—ਪ੍ਰਵਧੀ ਰੱਖਣ ਨਾਲ ਟੀਮਾਂ ਪ੍ਰੋਡਕਸ਼ਨ ਸਿਸਟਮ ਨੂੰ ਉਤਨਾ ਹੀ ਤੇਜ਼ ਅਪਡੇਟ ਕਰ ਸਕਦੀਆਂ ਹਨ ਜਿੰਨਾ ਉਤਨਾ ਉਤਪਾਦ ਨੂੰ। ਆਟੋਮੇਸ਼ਨ ਦੋ ਵਾਰੀ ਮਦਦ ਕਰਦੀ ਹੈ: ਇਹ ਦੁਹਰਾਏ ਕੰਮ ਨੂੰ ਤੇਜ਼ ਕਰਦੀ ਹੈ ਅਤੇ ਗੁਣਵੱਤਾ ਨੂੰ ਮਾਪਯੋਗ ਬਣਾਉਂਦੀ ਹੈ, ਤਾਂ ਜੋ ਟੀਮਾਂ ਨਤੀਜ਼ਿਆਂ 'ਤੇ ਭਰੋਸਾ ਕਰ ਸਕਣ ਅਤੇ ਅੱਗੇ ਵਧ ਸਕਣ।
DFM ਦਾ ਮਤਲਬ ਹੈ ਉਹ ਹਿੱਸੇ ਤਿਆਰ ਕਰਨਾ ਜੋ ਹਰ ਵਾਰੀ ਆਸਾਨੀ ਨਾਲ ਬਣ ਸਕਣ: ਘੱਟ ਵਿਲੱਖਣ ਕੰਪੋਨੇਟ, ਸਧਾਰਣ اسمبلیਆਂ, ਅਤੇ ਅਸਲੀ ਦੁਕਾਨ ਦੀ ਸਮਰੱਥਾ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਟੋਲਰੈਂਸ। ਵਾਪਸੀ ਸਿਰਫ਼ ਲਾਗਤ ਘਟਾਉਣਾ ਨਹੀਂ—ਇਹ ਛੋਟੇ ਚੱਕਰਾਂ ਦਾ ਫਾਇਦਾ ਹੈ, ਕਿਉਂਕਿ "ਅਗਲਾ ਵਰਜਨ" ਨੂੰ ਬਣਾਉਣ ਲਈ ਨਿਰਮਾਣ ਦੇ ਤਰੀਕੇ ਨੂੰ ਮੁੜ-ਖੋਜਣ ਦੀ ਲੋੜ ਨਹੀਂ ਰਹਿੰਦੀ।
SpaceX ਦਾ ਇਟਰੈਸ਼ਨ ਲੂਪ "ਇੱਕ ਵਾਰੀ ਡਿਜ਼ਾਈਨ ਕਰੋ, ਪ੍ਰਮਾਣਕਰਣ ਤੋਂ ਬਾਅਦ ਉਡਾਓ" ਵਾਲੀ ਸੋਚ ਵਾਂਗ ਨਹੀਂ, ਸਗੋਂ ਇਹ ਇੱਕ ਦੋਹਰਾਏ ਚੱਕਰ ਬਣਾਉ→ਟੈਸਟ→ਸਿੱਖੋ→ਬਦਲੋ ਵਾਂਗ ਹੈ। ਤਾਕਤ ਕਿਸੇ ਇਕ ਵੱਡੇ ਤਰੱਕੀ ਦਾ ਨਹੀਂ—ਇਹ ਬਹੁਤ ਸਾਰੇ ਛੋਟੇ ਸੁਧਾਰਾਂ ਦਾ ਗੁਣਾ ਪ੍ਰਭਾਵ ਹੈ ਜੋ ਜ਼ਿਆਦਾ ਤੇਜ਼ੀ ਨਾਲ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਪਹਿਲਾਂ ਕਿਉਂਕਿ ਧਾਰਨਾਵਾਂ ਪ੍ਰੋਗਰਾਮ-ਵਿਆਪਕ ਬਹੁਤ ਜ਼ਿਆਦਾ ਠੋਸ ਨਹੀਂ ਹੋਈਆਂ।
ਕੁੰਜੀ ਇਹ ਹੈ ਕਿ ਹਾਰਡਵੇਅਰ ਨੂੰ ਅਜਿਹਾ ਸਮਝੋ ਜੋ ਤੁਸੀਂ ਬਹੁਤ ਜਲਦੀ ਛੂ ਸਕਦੇ ਹੋ। ਇੱਕ ਭਾਗ ਜੋ ਕਾਗਜ਼ ਦੇ ਸਮੀਖਿਆ ਵਿੱਚ ਪਾਸ ਹੁੰਦਾ ਹੈ, ਅਜੇ ਵੀ ਟੁੱਟ ਸਕਦਾ ਹੈ, ਕੰਪਨ ਕਰ ਸਕਦਾ ਹੈ, ਲੀਕ ਕਰ ਸਕਦਾ ਹੈ, ਜਾਂ ਠੰਢ/ਗਰਮੀ ਵਿੱਚ ਅਜਿਹੇ ਵਿਵਹਾਰ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਸਪ੍ਰੇਡਸ਼ੀਟ ਪੂਰੀ ਤਰ੍ਹਾਂ ਕੈਪਚਰ ਨਹੀਂ ਕਰ ਸਕਦੀ। ਵਾਰ-ਵਾਰ ਟੈਸਟਿੰਗ ਇਹਨਾਂ ਹਕੀਕਤਾਂ ਨੂੰ ਜਲਦੀ ਪ੍ਰਗਟ ਕਰਦੀ ਹੈ, ਜਦੋਂ ਫਿਕਸ ਸਸਤੇ ਹੁੰਦੇ ਹਨ ਅਤੇ ਸਾਰੇ ਵਾਹਨ 'ਤੇ ਪ੍ਰਭਾਵ ਨਹੀਂ ਪਾਂਦਾ।
ਇਸ ਲਈ SpaceX ਇੰਸਟ੍ਰੂਮੈਂਟਡ ਟੈਸਟਿੰਗ—ਸਟੈਟਿਕ ਫਾਇਰਜ਼, ਟੈਂਕ, ਵਾਲਵ, ਇੰਜਣ, ਸਟੇਜ ਵੱਖਰੇ ਹੋਣ ਵਾਲੇ ਇਵੈਂਟ—'ਤੇ ਜੋਰ ਦਿੰਦਾ ਹੈ—ਜਿੱਥੇ ਮਕਸਦ ਇਹ ਦੇਖਣਾ ਹੁੰਦਾ ਹੈ ਕਿ ਅਸਲ ਵਿੱਚ ਕੀ ਹੁੰਦਾ ਹੈ, ਨਾ ਕਿ ਇਹ ਕਿ ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ ਸੀ।
ਕਾਗਜ਼ੀ ਸਮੀਖਿਆਆਂ ਜ਼ਰੂਰੀ ਹਨ ਤਾ ਕਿ ਸਪਸ਼ਟ ਗਲਤੀਆਂ ਬਚਾਈਆਂ ਜਾਣ ਅਤੇ ਟੀਮਾਂ ਸਹਿਮਤ ਹੋਣ। ਪਰ ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਭਰੋਸੇ ਅਤੇ ਪੂਰਨਤਾ ਨੂੰ ਇਨਾਮ ਦਿੰਦੀਆਂ ਹਨ, ਜਦਕਿ ਟੈਸਟ ਸੱਚਾਈ ਨੂੰ ਇਨਾਮ ਦਿੰਦੇ ਹਨ। ਹਾਰਡਵੇਅਰ ਚਲਾਉਣ ਨਾਲ:
ਇਟਰੈਸ਼ਨ ਦਾ ਮਤਲਬ ਉਦਾਸੀ ਨਹੀਂ ਹੁੰਦਾ। ਇਹ ਮਤਲਬ ਹੈ ਕਿ ਪਰਯੋਗਾਂ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਜਾਵੇ ਕਿ ਫੇਲਿਅਰ ਬਚਾਏ ਜਾ ਸਕਣ: ਲੋਕਾਂ ਦੀ ਸੁਰੱਖਿਆ, ਧਮਾਕੇ ਦੀ ਸੀਮਾ, ਟੈਲੀਮੇਟ੍ਰੀ ਕੈਪਚਰ, ਅਤੇ ਨਤੀਜੇ ਨੂੰ ਸਪਸ਼ਟ ਇੰਜੀਨੀਅਰਿੰਗ ਕਾਰਵਾਈ ਵਿੱਚ ਬਦਲ ਦੇਣ। ਟੈਸਟ ਆਰਟਿਕਲ ਵਿੱਚ ਇੱਕ ਫੇਲਿਅਰ ਜਾਣਕਾਰੀ-ਭਰਪੂਰ ਹੋ ਸਕਦਾ ਹੈ; ਉਹੀ ਫੇਲਿਅਰ ਇੱਕ ਓਪੀਰੇਸ਼ਨਲ ਮਿਸ਼ਨ ਦੌਰਾਨ ਰਿਆਪਰੇਸ਼ਨਲ ਅਤੇ ਗਾਹਕ ਪ੍ਰਭਾਵ ਵਾਲਾ ਹੋ ਸਕਦਾ ਹੈ।
ਇੱਕ ਲਾਭਕਾਰੀ ਫਰਕ ਮਕਸਦ ਵਿੱਚ ਹੈ:
ਇਹ ਸੀਮਾ ਸਾਫ਼ ਰੱਖਣ ਨਾਲ ਗਤੀ ਅਤੇ ਅਨੁਸ਼ਾਸਨ ਇੱਕੱਠੇ ਰਹਿ ਸਕਦੇ ਹਨ।
SpaceX ਨੂੰ ਅਕਸਰ ਇਸ ਤਰੀਕੇ ਨਾਲ ਵਰਣਨ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਕਿ ਉਹ ਰਾਕੇਟਾਂ ਨੂੰ ਸਾਫਟਵੇਅਰ ਵਾਂਗ ਸਲ਼ੂਚਿਤ ਕਰਦਾ ਹੈ: ਬਣਾਉ, ਟੈਸਟ ਕਰੋ, ਸਿੱਖੋ, ਸੁਧਾਰ ਕੀਤਾ ਜਾਂਦਾ "ਵਰਜ਼ਨ" ਸ਼ਿਪ ਕਰੋ। ਤੁਲਨਾ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਹੀਂ ਫਿੱਟ ਹੁੰਦੀ, ਪਰ ਇਹ ਆਧੁਨਿਕ ਲਾਂਚ ਸਿਸਟਮਾਂ ਦੇ ਸੁਧਾਰ ਦੇ ਢੰਗ ਵਿੱਚ ਇੱਕ ਅਸਲ ਬਦਲਾਅ ਵਿਆਖਿਆ ਕਰਦੀ ਹੈ।
ਸਾਫਟਵੇਅਰ ਟੀਮਾਂ ਰੋਜ਼ਾਨਾ ਅੱਪਡੇਟ ਪুশ ਕਰ ਸਕਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਗ਼ਲਤੀਆਂ ਵਾਪਸ-ਲਿਆਈਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ਰੋਲਬੈਕ ਸਸਤਾ ਹੁੰਦਾ ਹੈ। ਰਾਕੇਟ ਭੌਤਿਕ ਮਸ਼ੀਨ ਹਨ ਜੋ ਅਤੀਤ ਸੀਮਾਂ ਤੇ ਕੰਮ ਕਰਦੀਆਂ ਹਨ; ਫੇਲਿਅਰ ਮਹਿੰਗੇ ਅਤੇ ਕਦੇ-ਕਦੇ ਹਾਨਿਕਾਰਕ ਹੁੰਦੇ ਹਨ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇਟਰੈਸ਼ਨ ਨੂੰ ਨਿਰਮਾਣ ਹਕੀਕਤ ਅਤੇ ਸੁਰੱਖਿਆ ਗੇਟਾਂ ਵਿੱਚੋਂ ਲੰਘਣਾ ਪੈਂਦਾ ਹੈ: ਹਿੱਸੇ ਬਣਾਉਣੇ, ਇਕਠਾ ਕਰਨ, ਨਿਰੂਪਣ ਕਰਨ, ਟੈਸਟ ਕਰਨ ਤੇ ਪ੍ਰਮਾਣਿਤ ਕਰਨੇ।
ਰਾਕੇਟ ਵਿਕਾਸ ਨੂੰ "ਸਾਫਟਵੇਅਰ-ਵਾਂਗ" ਮਹਿਸੂਸ ਕਰਾਉਣ ਵਾਲੀ ਚੀਜ਼ ਇਹ ਹੈ ਕਿ ਉਸ ਭੌਤਿਕ ਚੱਕਰ ਨੂੰ ਸੰਕੋਚਿਤ ਕਰਨਾ—ਅਨਿਸ਼ਚਿਤਤਾ ਦੇ ਮਹੀਨਿਆਂ ਨੂੰ ਮਾਪਯੋਗ ਤਰ੍ਹਾਂ ਹਫ਼ਤਿਆਂ ਵਿੱਚ ਬਦਲਣਾ।
ਜਦੋਂ ਕੰਪੋਨੇਟਾਂ ਨੂੰ ਐਸਾ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਕਿ ਉਹ ਅਸਾਨੀ ਨਾਲ ਬਦਲੇ, ਰੀਫਰਬਿਸ਼ ਅਤੇ ਦੁਹਰਾਏ ਜਾ ਸਕਣ, ਤਦ ਇਟਰੈਸ਼ਨ ਤੇਜ਼ ਹੁੰਦੀ ਹੈ। ਰੀਯੂਜ਼ਬਿਲਿਟੀ ਸਿਰਫ਼ ਹਾਰਡਵੇਅਰ ਬਚਾਉਣ ਬਾਰੇ ਨਹੀਂ; ਇਹ ਉਡਿਆ ਹਿੱਸਿਆਂ ਦੀ ਛਾਂਟ ਕਰਨ, ਧਾਰਨਾਵਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ, ਅਤੇ ਸੁਧਾਰਾਂ ਨੂੰ ਅਗਲੇ ਨਿਰਮਾ ਵਿੱਚ ਫੀਡ ਕਰਨ ਦੇ ਵੀ ਹੋਰ ਮੌਕੇ ਬਣਾਉਂਦੀ ਹੈ।
ਕੁਝ ਐਨੇਬਲਰ ਇਸ ਲੂਪ ਨੂੰ ਤਿੱਖਾ ਕਰਦੇ ਹਨ:
ਸਾਫਟਵੇਅਰ ਟੀਮਾਂ ਲੌਗ ਅਤੇ ਨਿਗਰਾਨੀ ਤੋਂ ਸਿੱਖਦੀਆਂ ਹਨ। SpaceX ਘਣੀ ਟੈਲੀਮੇਟ੍ਰੀ ਤੋਂ ਸਿੱਖਦਾ ਹੈ: ਸੈਂਸਰ, ਉੱਚ-ਰੇਟ ਡੇਟਾ ਸਟ੍ਰੀਮ, ਅਤੇ ਆਟੋਮੇਟਿਕ ਵਿਸ਼ਲੇਸ਼ਣ ਜੋ ਹਰ ਟੈਸਟ ਫਾਇਰ ਅਤੇ ਉਡਾਣ ਨੂੰ ਡੇਟਾਸੈੱਟ ਵਿੱਚ ਬਦਲ ਦਿੰਦੇ ਹਨ। ਜਿੰਨਾ ਤੇਜ਼ ਡੇਟਾ ਦਰਸਤ ਅੰਦਰੂਨੀ ਤੇਜ਼ ਸਿੱਖਿਆ ਬਣਦੀ ਹੈ—ਅਤੇ ਸਿੱਖਿਆ ਤੁਰੰਤ ਡਿਜ਼ਾਈਨ ਬਦਲਾਅ ਵਿੱਚ ਬਦਲਦੀ ਹੈ—ਉਸੇ ਧੁਨੀ ਇਟਰੈਸ਼ਨ ਗੁਣਾ ਬਣਦਾ ਹੈ।
ਰਾਕੇਟਾਂ ਨੂੰ ਹਜੇ ਵੀ ਉਹ ਸੀਮਾਵਾਂ ਜਿੰਨ੍ਹਾਂ ਨੂੰ ਸਾਫਟਵੇਅਰ ਨਹੀਂ ਮਿਲਦੀਆਂ, ਮੰਨਣੀਆਂ ਪੈਂਦੀਆਂ ਹਨ:
ਇਸ ਲਈ ਰਾਕੇਟ ਐਪਸ ਵਾਂਗ ਨਹੀਂ ਇਤਰੈਟ ਕਰ ਸਕਦੇ। ਪਰ ਮੋਡੀਊਲ ਡਿਜ਼ਾਈਨ, ਭਾਰੀ ਇੰਸਟਰੂਮੈਂਟੇਸ਼ਨ, ਅਤੇ ਅਨੁਸ਼ਾਸਿਤ ਟੈਸਟਿੰਗ ਨਾਲ ਉਹ ਇਸ ਕਾਬਲ ਹੋ ਸਕਦੇ ਹਨ ਕਿ ਸਾਫਟਵੇਅਰ ਦਾ ਇੱਕ ਮੁੱਖ ਲਾਭ—ਛੋਟੇ-ਛੋਟੇ ਤੇਜ਼ ਸੁਧਾਰ—ਪਕੜ ਸਕਣ।
ਕੈਡੰਸ ਨੂੰ ਵੈਨਿਟੀ ਮੈਟ੍ਰਿਕ ਮੰਨਣਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ—ਜਦ ਤੱਕ ਤੁਸੀਂ ਇਸਦੇ ਦੂਜੇ-ਕ੍ਰਮ ਪ੍ਰਭਾਵਾਂ ਨੂੰ ਨਾ ਦੇਖੋ। ਜਦੋਂ ਇੱਕ ਟੀਮ ਬਾਰ-ਬਾਰ ਉੱਡਦੀ ਹੈ, ਹਰ ਲਾਂਚ ਹਾਰਡਵੇਅਰ ਪ੍ਰਦਰਸ਼ਨ, ਮੌਸਮ ਫੈਸਲੇ, ਰੇਂਜ ਕੋਆਰਡੀਨੇਸ਼ਨ, ਕੰਟਾਉਂਟਡਾਊਨ ਟਾਈਮਿੰਗ, ਅਤੇ ਰਿਕਵਰੀ ਆਪਰੇਸ਼ਨਾਂ 'ਤੇ ਤਾਜ਼ਾ ਡੇਟਾ ਪੈਦਾ ਕਰਦੀ ਹੈ। ਇਸ "ਅਸਲ-ਦੁਨੀਆ ਦੀ ਵਰਤੋਂ" ਦੀ ਮਾਤਰਾ ਸਿਮੁਲੇਸ਼ਨ ਅਤੇ ਕਦੇ-ਕਦੇ ਹੋਣ ਵਾਲੀਆਂ ਮਿਸ਼ਨਾਂ ਨਾਲ ਮੁਕਾਬਲੇ ਵਿੱਚ ਤੇਜ਼ੀ ਨਾਲ ਸਿੱਖਣ ਨੂੰ ਤੇਜ਼ ਕਰਦੀ ਹੈ।
ਹਰ ਵਾਧੂ ਲਾਂਚ ਨਤੀਜਿਆਂ ਦਾ ਇੱਕ ਵੱਡਾ ਨਮੂਨਾ ਦਿੰਦਾ ਹੈ: ਨਰਮ ਅਨੋਮਲੀ, ਅਨੋਮਲੀਕ ਸੰਵੇਦਨ, ਟਰਨਅਰਾਊਂਡ ਸਰਪ੍ਰਾਈਜ਼, ਅਤੇ ਗ੍ਰਾਊਂਡ-ਸਿਸਟਮ ਖਾਮੀਆਂ। ਸਮੇਂ ਦੇ ਨਾਲ ਪੈਟਰਨ ਉਭਰਦੇ ਹਨ।
ਇਹ ਭਰੋਸੇ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਇੱਕ ਵਾਹਨ ਜਿਸ ਨੇ ਵੱਖ-ਵੱਖ ਹਾਲਤਾਂ ਵਿੱਚ ਬਾਰ-ਬਾਰ ਉਡੀਕੀ ਹੋਈ ਹੈ ਉਸ 'ਤੇ ਭਰੋਸਾ ਕਰਨਾ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ—ਨਾ ਕਿ ਕਿਸੇ ਨੇ ਜੋਖਿਮ ਨੂੰ ਹਥਿਆ ਕੇਂਦਰਤ ਕੀਤਾ ਹੈ, ਬਲਕਿ ਇਸ ਲਈ ਕਿ ਅਸਲ ਤੌਰ 'ਤੇ ਜੋ ਹੁੰਦਾ ਹੈ ਉਸਦਾ ਮੋਟਾ ਰਿਕਾਰਡ ਹੈ।
ਉੱਚ ਕੈਡੰਸ ਸਿਰਫ਼ ਰਾਕੇਟ ਸੁਧਾਰਦੀ ਨਹੀਂ; ਇਹ ਲੋਕਾਂ ਅਤੇ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਵੀ ਸੁਧਾਰਦੀ ਹੈ।
ਗ੍ਰਾਊਂਡ ਕ੍ਰੂ ਰਿਪੀਟਿਸ਼ਨ ਰਾਹੀਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਸੰਵਾਰਦੇ ਹਨ। ਟ੍ਰੇਨਿੰਗ ਸਪਸ਼ਟ ਹੋ ਜਾਂਦੀ ਹੈ ਕਿਉਂਕਿ ਇਹ ਹਾਲੀਆ ਘਟਨਾਵਾਂ 'ਤੇ ਅਧਾਰਿਤ ਹੁੰਦੀ ਹੈ, ਨਾ ਕਿ ਪੁਰਾਣੇ ਦਸਤਾਵੇਜ਼ਾਂ 'ਤੇ। ਟੂਲਿੰਗ, ਚੈਕਲਿਸਟ, ਅਤੇ ਹੈਂਡਆਫ਼ਸ ਤਿੱਖੇ ਹੋ ਜਾਂਦੇ ਹਨ। ਇੱਥੋਂ ਤੱਕ ਕਿ "ਧੁੰਧਲੇ" ਹਿੱਸੇ—ਪੈਡ ਫਲੋ, ਪ੍ਰੋਪੈਲੈਂਟ ਲੋਡਿੰਗ, ਕਮਜ਼-ਪ੍ਰੋਟੋਕੋਲ—ਨਿਯਮਤ ਅਭਿਆਸ ਨਾਲ ਬਿਹਤਰ ਹੁੰਦੇ ਹਨ।
ਇੱਕ ਲਾਂਚ ਪ੍ਰੋਗਰਾਮ ਕੋਲ ਵੱਡੀਆਂ ਫਿਕਸ ਲਾਗਤਾਂ ਹੁੰਦੀਆਂ ਹਨ: ਫੈਸਿਲਟੀਜ਼, ਵਿਸ਼ੇਸ਼ ਉਪਕਰਣ, ਇੰਜੀਨੀਅਰਿੰਗ ਸਹਾਇਤਾ, ਸੁਰੱਖਿਆ ਸਿਸਟਮ, ਅਤੇ ਪ੍ਰਬੰਧਕੀ ਓਵਰਹੈੱਡ। ਵੱਧ ਉਡਾਣਾਂ ਨਾਲ ਉਹਨਾਂ ਫਿਕਸ ਖਰਚਾਂ ਨੂੰ ਵੱਧ ਮਿਸ਼ਨਾਂ 'ਤੇ ਫੈਲਾਇਆ ਜਾ ਸਕਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਪ੍ਰਤੀ-ਲਾਂਚ ਔਸਤ ਲਾਗਤ ਘਟ ਸਕਦੀ ਹੈ।
ਸਾਥ ਹੀ, ਇੱਕ ਭਵਿੱਖ-ਅਨੁਮਾਨ ਰਿਥਮ ਥ੍ਰੈਸ਼ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ। ਟੀਮਾਂ ਸਟਾਫਿੰਗ, ਮੇਂਟੇਨੈਂਸ ਵਿੰਡੋ ਅਤੇ ਇਨਵੈਂਟਰੀ ਨੂੰ ਘੱਟ ਇमरਜੈਂਸੀ ਅਤੇ ਘੱਟ ਆਈਡਲ ਸਮੇਂ ਨਾਲ ਯੋਜਨਾ ਕਰਦੀਆਂ ਹਨ।
ਕੈਡੰਸ ਸਪਲਾਈ ਪਾਸੇ ਨੂੰ ਵੀ ਬਦਲ ਦੇਂਦੀ ਹੈ। ਨਿਯਮਤ ਮੰਗ ਆਮ ਤੌਰ 'ਤੇ ਸਪਲਾਇਰ ਨਾਲ ਸੌਦੇਬਾਜ਼ੀ ਵਿੱਚ ਸੁਧਾਰ ਲਿਆਉਂਦੀ ਹੈ, ਲੀਡ-ਟਾਈਮ ਘਟਦੀ ਹੈ, ਅਤੇ ਐਕਸਪੇਡੀਟਿੰਗ ਫੀਸਾਂ ਘੱਟ ਹੁੰਦੀਆਂ ਹਨ। ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ, स्थਿਰ ਸ਼ਡਿਊਲ ਪਾਰਟਾਂ ਨੂੰ ਸਟੇਜ ਕਰਨ, ਟੈਸਟ ਆਸੈਟਾਂ ਨੂੰ ਵੰਡਣ, ਅਤੇ ਆਖ਼ਰੀ-ਪਲ ਦੇ ਦੁਬਾਰਾ-ਬਤਾਵਾਂ ਤੋਂ ਬਚਣ ਨੂੰ ਆਸਾਨ ਬਣਾ ਦਿੰਦਾ ਹੈ।
ਇਨ੍ਹਾ ਚੀਜ਼ਾਂ ਨੂੰ ਇਕਠੇ ਕਰਕੇ, ਕੈਡੰਸ ਇੱਕ ਫਲਾਈ੍ਹਵ੍ਹੀਲ ਬਣ ਜਾਂਦੀ ਹੈ: ਜ਼ਿਆਦਾ ਉਡਾਣਾਂ ਹੋਰ ਸਿੱਖਣ ਪੈਦਾ ਕਰਦੀਆਂ ਹਨ, ਜਿਸ ਨਾਲ ਭਰੋਸਾ ਅਤੇ ਕੁਸ਼ਲਤਾ ਸੁਧਰਦੀ ਹੈ, ਜੋ ਹੋਰ ਉਡਾਣਾਂ ਨੂੰ ਯੋਗ ਬਣਾਉਂਦਾ ਹੈ।
ਉੱਚ ਲਾਂਚ ਕੈਡੰਸ ਸਿਰਫ਼ "ਜ਼ਿਆਦਾ ਲਾਂਚ" ਨਹੀਂ। ਇਹ ਇਕ ਪ੍ਰਣਾਲੀਕ ਫਾਇਦਾ ਹੈ ਜੋ ਗੁਣਾ ਹੁੰਦਾ ਹੈ। ਹਰ ਉਡਾਣ ਡੇਟਾ ਪੈਦਾ ਕਰਦੀ ਹੈ, ਆਪਰੇਸ਼ਨਾਂ ਨੂੰ ਸਟ੍ਰੈਸ-ਟੈਸਟ ਕਰਦੀ ਹੈ, ਅਤੇ ਟੀਮਾਂ ਨੂੰ ਅਸਲ ਸੀਮਾਵਾਂ ਹੇਠਾਂ ਸਮੱਸਿਆਵਾਂ ਹੱਲ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰਦੀ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਇਹ ਰੀਪਟੀਸ਼ਨ ਬਣਾਕੇ ਰੱਖ ਸਕਦੇ ਹੋ—ਲੰਬੇ ਰੀਸੈੱਟ ਬਿਨਾਂ—ਤਾਂ ਤੁਸੀਂ ਮੁਕਾਬਲੇਦਾਰਾਂ ਨਾਲੋਂ ਤੇਜ਼ੀ ਨਾਲ ਲਰਨਿੰਗ ਕਰ ਲੈਂਦੇ ਹੋ।
ਕੈਡੰਸ ਇੱਕ ਤਿੰਨ-ਭਾਗੀ ਫਲਾਈਹਵੀਲ ਬਣਾਉਂਦਾ ਹੈ:
ਕੋਈ ਮੁਕਾਬਲੇਦਾਰ ਇੱਕ ਡਿਜ਼ਾਈਨ ਫੀਚਰ ਦੀ ਨਕਲ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਕੈਡੰਸ ਨੂੰ ਮੇਚ ਕਰਨ ਲਈ ਇੱਕ ਐਂਡ-ਟੂ-ਐਂਡ ਮਸ਼ੀਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ: ਨਿਰਮਾਣ ਦਰ, ਸਪਲਾਈ ਚੇਨ ਜਵਾਬਦੇਹੀ, ਪ੍ਰਸ਼ਿਛਤ ਕ੍ਰੂਜ਼, ਗ੍ਰਾਊਂਡ ਇੰਫ੍ਰਾਸਟ੍ਰਕਚਰ, ਅਤੇ ਦੁਹਰਾਏ ਪ੍ਰਕਿਰਿਆਵਾਂ ਚਲਾਉਣ ਦੀ ਡਿਸੀਪਲਿਨ। ਜੇ ਕੋਈ ਲਿੰਕ ਧੀਮਾ ਹੈ, ਤਾਂ ਕੈਡੰਸ ਰੁੱਕ ਜਾਂਦੀ ਹੈ—ਅਤੇ ਗੁਣਾ ਵਾਲਾ ਫਾਇਦਾ ਲੁਕ ਜਾਂਦਾ ਹੈ।
ਵੱਡਾ ਬੈਕਲੌਗ ਘੱਟ ਟੈਂਪੋ ਨਾਲ ਵੀ ਹੋ ਸਕਦਾ ਹੈ ਜੇ ਵਾਹਨ, ਪੈਡ, ਜਾਂ ਆਪਰੇਸ਼ਨ ਸੀਮਿਤ ਹਨ। ਕੈਡੰਸ "ਲਗਾਤਾਰ ਨਿਭਾਣ" ਬਾਰੇ ਹੈ, ਮਾਰਕੀਟਿੰਗ ਮੰਗ ਬਾਰੇ ਨਹੀਂ।
ਜੇ ਤੁਸੀਂ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਕੈਡੰਸ ਇੱਕ ਟਿਕਾਊ ਫਾਇਦੇ ਵਿੱਚ ਬਦਲ ਰਿਹਾ ਹੈ, ਤਾਂ ਟਰੈਕ ਕਰੋ:
ਏਹ ਮੈਟ੍ਰਿਕਸ ਦਰਸਾਉਂਦੇ ਹਨ ਕਿ ਪ੍ਰਣਾਲੀ ਸਕੇਲ ਹੋ ਰਹੀ ਹੈ—ਜਾਂ ਸਿਰਫ ਕਦੇ-ਕਦੇ ਜੋੜਾ ਦੌੜਾ ਰਹੀ ਹੈ।
ਰਾਕੇਟ ਨੂੰ ਦੁਬਾਰਾ ਵਰਤਣਾ ਸੁਣਨ ਵਿੱਚ ਆਸਾਨ ਲਾਗਤ ਨੁਕਸਾਨ ਮਿਲਦਾ ਹੈ: ਇਸਨੂੰ ਫੇਰ ਉਡਾਉ, ਘੱਟ ਪੈਸਾ ਖਰਚ। ਵਾਸਤਵ ਵਿੱਚ, ਰਿਉਜ਼ਬਿਲਿਟੀ ਸਿਰਫ਼ ਮਾਰਜਿਨਲ ਲਾਗਤ ਘਟਾਉਂਦੀ ਹੈ ਜੇ ਲਾਂਚਾਂ ਦੇ ਦਰਮਿਆਨ ਸਮਾਂ ਅਤੇ ਮਜ਼ਦੂਰ ਕੰਟਰੋਲ ਵਿੱਚ ਰਹਿੰਦੇ ਹਨ। ਜੇ ਇੱਕ ਬੂਸਟਰ ਨੂੰ ਅਗਲੀ ਮਿਸ਼ਨ ਲਈ ਹਫ਼ਤਿਆਂ ਦੀ ਨਜ਼ਾਕਤ ਭਰਪੂਰ ਰੀਵਰਕ ਦੀ ਲੋੜ ਹੋਵੇ, ਤਾਂ ਉਹ ਇਕ ਹਾਈ-ਵੈਲੋਸਿਟੀ ਐਸੈਟ ਦੀ ਬਜਾਏ ਮਿਊਜ਼ੀਅਮ ਪੀਸ ਬਣ ਜਾਂਦਾ ਹੈ।
ਅਸਲ ਸਵਾਲ ਇਹ ਨਹੀਂ ਹੈ "ਕੀ ਅਸੀਂ ਇਸਨੂੰ ਲੈਂਡ ਕਰ ਸਕਦੇ ਹਾਂ?" ਪਰ "ਅਸੀਂ ਇਸਨੂੰ ਅਗਲੀ ਮਿਸ਼ਨ ਲਈ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਸਰਟੀਫਾਇ ਕਰ ਸਕਦੇ ਹਾਂ?" ਤੇਜ਼ ਰੀਫਰਬਿਸ਼ਮੈਂਟ ਰੀਯੂਜ਼ ਨੂੰ ਸ਼ਡਿਊਲ ਫਾਇਦਾ ਬਣਾਉਂਦਾ ਹੈ: ਘੱਟ ਨਵੇਂ ਸਟੇਜ ਬਣਾਉਣ, ਘੱਟ ਲੰਬੇ-ਲੀਡ ਹਿੱਸਿਆਂ ਦੀ ਉਡੀਕ, ਅਤੇ ਵੱਧ ਲਾਂਚ ਮੌਕੇ।
ਇਹ ਤੇਜ਼ੀ ਸਰਵਿਸੇਬਿਲਿਟੀ ਲਈ ਡਿਜ਼ਾਈਨ (ਆਸਾਨ ਪਹੁੰਚ, ਮੋਡੀਊਲ ਸਵੈਪ) ਅਤੇ ਇਹ ਸਿੱਖਣ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ ਕਿ ਕੀ ਛੇਡਣਾ ਨਹੀਂ ਹੈ। ਹਰ ਬਚਾਇਆ ਗਿਆ ਟੀਅਰਡਾਊਨ ਮਜ਼ਦੂਰ, ਟੂਲਿੰਗ, ਅਤੇ ਕੈਲੰਡਰ ਸਮੇਂ ਵਿੱਚ ਇੱਕ ਗੁਣਾ ਲਾਭ ਹੈ।
ਤੇਜ਼ ਟਰਨਅਰਾਊਂਡ ਹੀਰੋਇਕਸ ਦੀ ਬਜਾਏ ਸਪਸ਼ਟ SOPs ਬਾਰੇ ਹੁੰਦਾ ਹੈ। ਸਪਸ਼ਟ ਚੈੱਕਲਿਸਟ, ਦੁਹਰਾਏ ਜਾਂਦੇ ਇੰਸਪੈਕਸ਼ਨ, ਅਤੇ "ਨੱਠ-ਚੰਗਾ" ਵਰਕਫ਼ਲੋ ਵੈਰੀਏਸ਼ਨ ਘਟਾਉਂਦੇ ਹਨ—ਤੇਜ਼ ਰੀਯੂਜ਼ ਲਈ ਛੁਪਿਆ ਦੋਸ਼।
SOPs ਪੈਨਾਂ ਨੂੰ ਮਾਪਯੋਗ ਬਣਾਉਂਦੀਆਂ ਹਨ: ਟਰਨਅਰਾਊਂਡ ਘੰਟੇ, ਖ਼ਰਾਬੀ ਦਰ, ਅਤੇ ਦੁਹਰਾਏ ਜਾਣ ਵਾਲੇ ਫੇਲਿਓਰ ਮੋਡ। ਜਦੋਂ ਟੀਮਾਂ ਉਡਾਣਾਂ ਨੂੰ ਸੇਬ-ਟੂ-ਐਪਲ ਤੁਲਨਾ ਕਰ ਸਕਦੀਆਂ ਹਨ, ਇਟਰੈਸ਼ਨ ਧਿਆਨ ਕੇਂਦਰਤ ਹੁੰਦੀ ਹੈ, ਨਾ ਕਿ ਵਿਵਾਦਤਾਰਕ।
ਰੀਯੂਜ਼ ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਪਰਚੀਆਂ ਨਾਲ ਸੀਮਤ ਹੁੰਦੀ ਹੈ:
ਸਹੀ ਢੰਗ ਨਾਲ ਸੰਭਾਲੇ ਜਾਣ 'ਤੇ, ਰੀਯੂਜ਼ ਕੈਡੰਸ ਨੂੰ ਵਧਾਉਂਦੀ ਹੈ, ਅਤੇ ਉੱਚ ਕੈਡੰਸ ਰੀਯੂਜ਼ ਨੂੰ ਸੁਧਾਰਦੀ ਹੈ। ਵਧੇਰੇ ਉਡਾਣਾਂ ਵੱਧ ਡੇਟਾ ਪੈਦਾ ਕਰਦੀਆਂ ਹਨ, ਜੋ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਤਿੱਖਾ ਕਰਦੀ ਹੈ, ਡਿਜ਼ਾਈਨਾਂ ਨੂੰ ਸੁਧਾਰਦੀ ਹੈ, ਅਤੇ ਪ੍ਰਤੀ-ਫਲਾਈਟ ਅਣਿਸ਼ਚਿਤਤਾ ਘਟਾਉਂਦੀ ਹੈ—ਰੀਯੂਜ਼ਬਿਲਿਟੀ ਨੂੰ ਰੀਯੂਜ਼ ਦੀ ਫਲਾਈਹਵੀਲ ਲਈ ਸਹਾਇਕ ਬਣਾਉਂਦੀਆਂ ਹਨ, ਨਾਂ ਕਿ ਸਸਤੇ ਲਾਂਚਾਂ ਲਈ ਛੇਤੀ ਰਾਹ।
SpaceX ਦਾ ਵੱਧ ਤੋਂ ਵੱਧ ਆਪਣਾ ਹਾਰਡਵੇਅਰ ਬਣਾਉਣ ਦਾ ਦਬਾਅ ਸਿਰਫ਼ ਪੈਸਾ ਬਚਾਉਣ ਬਾਰੇ ਨਹੀਂ ਸੀ—ਇਹ ਸ਼ਡਿਊਲ ਦੀ ਰੱਖਿਆ ਬਾਰੇ ਵੀ ਸੀ। ਜਦੋਂ ਇੱਕ ਮਿਸ਼ਨ ਕਿਸੇ ਇੱਕ ਦੇਰ ਵਾਲੇ ਵਾਲਵ, ਚਿਪ, ਜਾਂ ਕਾਸਟਿੰਗ 'ਤੇ ਨਿਰਭਰ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਰਾਕੇਟ ਪ੍ਰੋਗਰਾਮ ਸਪਲਾਇਰ ਦੇ ਕੈਲੰਡਰ ਨੂੰ ਅਪਣਾਉਂਦਾ ਹੈ। ਮੁੱਖ ਕੰਪੋਨੇਟਾਂ ਨੂੰ ਅੰਦਰੂਨੀ ਬਣਾਕੇ, ਤੁਸੀਂ ਬਾਹਰੀ ਹਥੋੜਿਆਂ ਦੀ ਗਿਣਤੀ ਘਟਾ ਦਿੰਦੇ ਹੋ ਅਤੇ ਉਪਰ-ਉਪਲਬਧੀ ਦੇ ਕਾਰਨ ਕਿਸੇ ਉਪਸਟ੍ਰੀਮ ਦੇਰੀ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਮੇਲ-ਮੁਲ ਮਿਸ਼ਨ ਛੁਟਦੇ ਜਾਣ ਦੇ ਖਤਰੇ ਨੂੰ ਘਟਾਉਂਦੇ ਹੋ।
ਅੰਦਰੂਨੀ ਸਪਲਾਈ ਚੇਨਾਂ ਨੂੰ ਲਾਂਚ ਟੀਮ ਨਾਲ ਇੱਕੋ ਹੀ ਤਰਜੀਹਾਂ 'ਤੇ ਮਿਲਾਇਆ ਜਾ ਸਕਦਾ ਹੈ: ਤੇਜ਼ ਬਦਲਾਅ-ਮੰਜੂਰੀ, ਸਭ ਤੋਂ ਵੱਧ ਕੋਆਰਡੀਨੇਸ਼ਨ ਉੱਤੇ ਧਿਆਨ, ਅਤੇ ਲੀਡ-ਟਾਈਮ ਬਾਰੇ ਘੱਟ ਹੈਰਾਨੀ। ਜੇ ਟੈਸਟ ਤੋਂ ਬਾਅਦ ਡਿਜ਼ਾਈਨ ਟਵੀਕ ਦੀ ਲੋੜ ਹੋਵੇ, ਇੱਕ ਇਕੀਕ੍ਰਿਤ ਟੀਮ ਬਿਨਾਂ ਕੰਟਰੈਕਟ ਮੁੜ-ਚਰਚਾ ਜਾਂ ਵੈਂਡਰ ਦੇ ਅਗਲੇ ਉਤਪਾਦਨ ਸਲਾਟ ਦੀ ਉਡੀਕ ਕਰਕੇ ਇਟਰੈਟ ਕਰ ਸਕਦੀ ਹੈ।
ਆਪਣੇ ਹੋਰ ਹਿੱਸਿਆਂ ਨੂੰ ਬਣਾ ਕੇ ਵੀ ਅਸਲੀ ਸੀਮਾਵਾਂ ਰਹਿੰਦੀਆਂ ਹਨ:
ਜਿਵੇਂ ਜਿਵੇਂ ਉਡਾਣ ਵਾਲੀਮ ਵਧਦੀ ਹੈ, ਮੈਕ-ਵਸ-ਬਾਇ ਨਿਰਣੇ ਆਮ ਤੌਰ 'ਤੇ ਬਦਲਦੇ ਹਨ। ਸ਼ੁਰੂ ਵਿੱਚ, ਖਰੀਦਣਾ ਤੇਜ਼ ਲੱਗ ਸਕਦਾ ਹੈ; ਬਾਅਦ ਵਿੱਚ, ਉੱਚ throughput ਦਫਾ اختصاصੀ ਅੰਦਰੂਨੀ ਲਾਈਨਾਂ, ਟੂਲਿੰਗ, ਅਤੇ QA ਸਰੋਤਾਂ ਨੂੰ ਜਾਇਜ਼ ਬਣਾ ਸਕਦਾ ਹੈ। ਲਕੜੀ ਦਾ ਮਕਸਦ "ਹਰ ਚੀਜ਼ ਬਣਾਉਣਾ" ਨਹੀਂ, ਬਲਕਿ "ਉਹਨਾਂ ਚੀਜ਼ਾਂ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਨਾ ਜੋ ਤੁਹਾਡੇ ਸ਼ਡਿਊਲ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਦੀਆਂ ਹਨ"।
ਵਰਟੀਕਲ ਇੰਟੀਗਰੇਸ਼ਨ ਇਕਲੋ ਜ਼ਰਾ-ਜਿਹਾ ਨੁਕਸਾਨ ਬਣਾ ਸਕਦੀ ਹੈ: ਜੇ ਇਕ ਅੰਦਰੂਨੀ ਸੈੱਲ ਪਿੱਛੇ ਰਹਿ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਕੋਈ ਦੂਜਾ ਸਪਲਾਇਰ ਨਹੀਂ ਹੋਵੇਗਾ ਜੋ ਖਾਲੀ ਜਗ੍ਹਾ ਭਰ ਸਕੇ। ਇਹ ਗੁਣਵੱਤਾ ਨਿਯੰਤਰਣ, ਅਹਿਮ ਪ੍ਰਕਿਰਿਆਵਾਂ ਵਿੱਚ ਰੀਡੰਡੈਂਸੀ, ਅਤੇ ਸਪਸ਼ਟ ਸਵੀਕ੍ਰਿਤ ਮਿਆਰਾਂ ਲਈ ਬਲ ਪੈਦਾ ਕਰਦਾ ਹੈ—ਤਾਕਿ ਤੇਜ਼ੀ ਚੁਪਚਾਪ ਮੁੜ-ਕਾਮ ਅਤੇ ਖਰਾਬ ਹਿੱਸਿਆਂ ਵਿੱਚ ਬਦਲ ਨਾ ਹੋ ਜਾਵੇ।
ਏਅਰੋਸਪੇਸ ਵਿੱਚ ਗਤੀ ਸਿਰਫ਼ ਇੱਕ ਟਾਈਮਲਾਈਨ ਨਹੀਂ—ਇਹ ਇੱਕ ਸੰਗਠਨਾਤਮਕ ਡਿਜ਼ਾਈਨ ਚੋਣ ਹੈ। SpaceX ਦੀ ਰਫ਼ਤਾਰ ਸਪਸ਼ਟ ਮਲੀਕੀਅਤ, ਤੇਜ਼ ਫੈਸਲੇ, ਅਤੇ ਇੱਕ ਸੱਭਿਆਚਾਰ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ ਜੋ ਹਰ ਟੈਸਟ ਨੂੰ ਇੱਕ ਡੇਟਾ ਇਕੱਠਾ ਕਰਨ ਦੇ ਮੌਕੇ ਵਾਂਗ ਦੇਖਦੀ ਹੈ ਨਾ ਕਿ ਇਕ ਅਦਾਲਤ ਦੀ ਤਰ੍ਹਾਂ।
ਵੱਡੇ ਇੰਜੀਨੀਅਰਿੰਗ ਪ੍ਰੋਗਰਾਮਾਂ ਵਿੱਚ ਇੱਕ ਆਮ गलਤੀ "ਸਾਂਝੀ ਜ਼ਿੰਮੇਵਾਰੀ" ਹੈ, ਜਿੱਥੇ ਹਰ ਕੋਈ ਟਿੱਪਣੀ ਕਰ ਸਕਦਾ ਹੈ ਪਰ ਕੋਈ ਫੈਸਲਾ ਨਹੀਂ ਲੈਂਦਾ। SpaceX-ਸਟਾਈਲ ਏਕਸੇਕਿਊਸ਼ਨ ਇਕਲ-ਥ੍ਰੈਡ ਮਲਕੀਅਤ 'ਤੇ ਜ਼ੋਰ ਦਿੰਦੀ ਹੈ: ਇੱਕ ਵਿਸ਼ੇਸ਼ ਵਿਅਕਤੀ ਜਾਂ ਛੋਟੀ ਟੀਮ ਇੱਕ ਸਬਸਿਸਟਮ ਲਈ ਆਖ਼ਰੀ ਜ਼ਿੰਮੇਵਾਰ ਹੋਂਦੀ ਹੈ—ਨਿਰਧਾਰਣਾਂ, ਡਿਜ਼ਾਈਨ ਟਰੇਡ-ਆਫ, ਟੈਸਟਿੰਗ ਅਤੇ ਫਿਕਸਾਂ ਤੱਕ।
ਉਹ ਢਾਂਚਾ ਹਥੋੜਿਆਂ ਅਤੇ ਅਸਪਸ਼ਟਤਾ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ। ਇਹ ਤਰਜੀਹ ਨੂੰ ਵੀ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ: ਜਦੋਂ ਕਿਸੇ ਫੈਸਲੇ ਦਾ ਨਾਂ ਹੁੰਦਾ ਹੈ, ਸੰਗਠਨ ਬੜੀ ਤੇਜ਼ੀ ਨਾਲ ਬਿਨਾਂ ਚੌੜੇ ਸਮਰਥਨ ਦੀ ਉਡੀਕ ਕੀਤੇ ਅੱਗੇ ਵਧ ਸਕਦੀ ਹੈ।
ਤੇਜ਼ ਇਟਰੈਸ਼ਨ ਤਬ ਹੀ ਕੰਮ ਕਰਦੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਟੁੱਟਣ ਤੋਂ ਤੇਜ਼ ਸਿੱਖ ਸਕੋ। ਇਸ ਲਈ ਲੋੜੀਂਦਾ ਹੈ:
ਮਕਸਦ ਦਸਤਾਵੇਜ਼ ਲਈ ਕਾਗਜ਼ੀ ਰੂਟीन ਨਹੀਂ ਹੈ। ਇਹ ਸਿੱਖਣ ਨੂੰ ਸਮੂਹਿਕ ਬਣਾਉਂਦਾ ਹੈ—ਤਾਂ ਜੋ ਫਿਕਸ ਟਿਕਿੰਦਾ ਹੈ ਅਤੇ ਨਵੇਂ ਇੰਜੀਨੀਅਰ ਪਿਛਲੇ ਟੀਮ ਦੀਆਂ ਖੋਜਾਂ 'ਤੇ ਬਣ ਸਕਣ।
ਰਾਕੇਟਸ ਵਿੱਚ "ਤੇਜ਼ੀ ਨਾਲ ਚਲੋ" ਦੇ ਨਿਰਦੇਸ਼ਾਂ ਨੂੰ ਸੁਰੱਖਿਆ ਦੀਆਂ ਰੋਕਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਗੇਟ ਨਿੱਕੇ ਅਤੇ ਉੱਚ-ਪ੍ਰਭਾਵ ਵਾਲੇ ਹੁੰਦੇ ਹਨ: ਉਹ ਆਲ੍ਹੇ-ਦੁਆਲੇ ਖਤਰਾ, ਇੰਟਰਫੇਸ ਅਤੇ ਮਿਸ਼ਨ ਅਸ਼ੋਰੈਂਸ ਆਈਟਮਾਂ ਦੀ ਜਾਂਚ ਕਰਦੇ ਹਨ, ਜਦਕਿ ਘੱਟ-ਖਤਰੇ ਵਾਲੀਆਂ ਸੁਧਾਰ ਲਾਹੇ-ਬੇਨਕੇ ਰਾਹ ਨਾਲ ਗੁਜ਼ਰਨ ਦਿੰਦੇ ਹਨ।
ਹਰ ਬਦਲਾਅ ਨੂੰ ਮਹੀਨਿਆਂ ਲੰਬੇ ਮਨਜ਼ੂਰੀ ਚੱਕਰ ਵਿੱਚ ਨੈੜੇ ਨਾ ਲਿਆਉਣ ਦੀ ਬਜਾਏ, ਟੀਮਾਂ ਇਹ ਪਰਿਭਾਸ਼ਤ ਕਰਦੀਆਂ ਹਨ ਕਿ ਕੀ ਚੀਜ਼ਾਂ ਗਹਿਰੀ ਸਮੀਖਿਆ ਦੀ ਮੰਗ ਕਰਦੀਆਂ ਹਨ (ਉਦਾਹਰਣ ਲਈ, ਪ੍ਰੋਪਲਸ਼ਨ ਬਦਲਾਅ, ਫਲਾਈਟ ਸਾਫਟਵੇਅਰ ਸੁਰੱਖਿਆ ਲਾਜਿਕ, ਸਾਂଠ-ਸਮਰੱਥਾ ਮਾਰਜਿਨ)। ਹੋਰ ਸਭ ਚੀਜ਼ਾਂ ਇੱਕ ਹਲਕੀ ਰਾਹ ਤੋਂ ਰਾਹ ਹੋ ਜਾਂਦੀਆਂ ਹਨ।
ਜੇ ਕੇਵਲ ਇਨਾਮ "ਕੋਈ ਗਲਤੀ ਨਾ ਹੋਵੇ" ਹੋਵੇ ਤਾਂ ਲੋਕ ਮੁੱਦਿਆਂ ਲੁਕਾ ਲੈਂਦੇ ਹਨ ਅਤੇ ਚੁਸਤ ਟੈਸਟਾਂ ਤੋਂ ਡਰਦੇ ਹਨ। ਇਕ ਸਿਹਤਮੰਦ ਸਿਸਟਮ ਚੰਗੇ ਤਰੀਕੇ ਨਾਲ ਡਿਜ਼ਾਈਨ ਕੀਤੇ ਪਰਯੋਗਾਂ, ਪਾਰਦਰਸ਼ੀ ਰਿਪੋਰਟਿੰਗ, ਅਤੇ ਤੇਜ਼ ਸੁਧਾਰ ਨੂੰ ਮਨਾਉਂਦਾ ਹੈ—ਤਾਂ ਜੋ ਸੰਗਠਨ ਹਰ ਚੱਕਰ ਵਿੱਚ ਹੋਰ ਸਮਝਦਾਰ ਹੋਵੇ, ਨਾ ਕਿ ਸਿਰਫ ਕਾਗਜ਼ੀ ਰੂਪ ਵਿੱਚ ਸੁਰੱਖਿਅਤ।
ਰਾਕੇਟ ਇਟਰੈਸ਼ਨ ਖਾਲੀ ਕਿਸੇ ਵੀ ਸਥਾਨ ਵਿੱਚ ਨਹੀਂ ਹੁੰਦੀ। ਤੇਜ਼-ਚਲਦੀ ਇੰਜੀਨੀਅਰਿੰਗ ਸੱਭਿਆਚਾਰ ਦੇ ਬਾਵਜੂਦ, ਲਾਂਚ ਕੈਡੰਸ ਲਾਇਸੰਸਿੰਗ, ਰੇਂਜ ਸ਼ਡਿਊਲ, ਅਤੇ ਸੁਰੱਖਿਆ ਨਿਯਮਾਂ ਨਾਲ ਸੀਮਿਤ ਹੁੰਦੀ ਹੈ ਜੋ ਇੱਕ ਟੀਮ ਦੀ ਚਾਹਤ ਨਾਲ ਸਿੱਟੀ ਨਹੀਂ ਹੁੰਦੀਆਂ।
ਯੂ.ਐਸ. ਵਿੱਚ, ਹਰੇਕ ਲਾਂਚ ਲਈ ਨਿਯਮਕ ਮੰਜ਼ੂਰੀਆਂ ਅਤੇ ਇੱਕ ਸਪਸ਼ਟ ਸੁਰੱਖਿਆ ਕੇਸ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਵਾਤਾਵਰਣੀ ਸਮੀਖਿਆਵਾਂ, ਫਲਾਈਟ ਸੁਰੱਖਿਆ ਵਿਸ਼ਲੇਸ਼ਣ, ਅਤੇ ਜਨਤਕ ਜੋਖਿਮ ਹੱਦਾਂ ਅਸਲੀ ਲੀਡ-ਟਾਈਮ ਬਣਾਉਂਦੀਆਂ ਹਨ। ਚਾਹੇ ਵਾਹਨ ਅਤੇ ਪੇਲੋਡ ਤਿਆਰ ਹੋਣ, ਰੇਂਜ (ਟ੍ਰੈਕਿੰਗ, ਏਅਰਸਪੇਸ ਅਤੇ ਮੈਰੀਟਾਈਮ ਕਲੋਜ਼ਰ, ਹੋਰ ਉਪਭੋਗਤਾਵਾਂ ਨਾਲ ਕੋਆਰਡੀਨੇਸ਼ਨ) ਗੇਟਿੰਗ ਫੈਕਟਰ ਹੋ ਸਕਦਾ ਹੈ। ਅਮਲੀ ਤੌਰ 'ਤੇ, ਕੈਡੰਸ ਫੈਕਟਰੀ ਆਉਟਪੁੱਟ, ਆਪਰੇਸ਼ਨਲ ਤਿਆਰੀ, ਅਤੇ ਬਾਹਰੀ ਕੈਲੰਡਰ ਦੇ ਵਿਚਕਾਰ ਇੱਕ ਸਮਝੌਤੇ ਦਾ ਨਤੀਜਾ ਹੁੰਦੀ ਹੈ।
ਬਿਨਾ-ਮਨੁੱਖੀ ਟੈਸਟ ਫਲਾਈਟਾਂ ਹੋਰ ਅਣਿਸ਼ਚਿਤਤਾ ਸਹਿਣ ਕਰ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ਅਨੋਮਲੀਆਂ ਤੋਂ ਤੇਜ਼ ਸਿੱਖ ਸਕਦੀਆਂ ਹਨ—ਸੁਰੱਖਿਆ ਸੀਮਾਵਾਂ ਦੇ ਅੰਦਰ। ਮਨੁੱਖੀ ਮਿਸ਼ਨਾਂ ਲਈ ਮਿਆਰ ਉੱਚਾ ਹੈ: ਰੀਡੰਡੈਂਸੀ, ਅਬੋਰਟ ਸਮਰੱਥਾ, ਅਤੇ ਰਸਮੀ ਪ੍ਰਮਾਣੀਕਰਣ ਇਤਰੈਸ਼ਨ ਦੀ ਜਗ੍ਹਾ ਘਟਾਉਂਦੇ ਹਨ। ਰਾਸ਼ਟਰੀ ਸੁਰੱਖਿਆ ਮਿਸ਼ਨਾਂ 'ਤੇ ਹੋਰ ਪਰਤਾਂ ਲੱਗ ਜਾਂਦੀਆਂ ਹਨ: ਖ਼ਤਰਨਾਕ ਭਰੋਸਾ, ਦਸਤਾਵੇਜ਼ੀਕਰਨ, ਅਤੇ ਆਮ ਤੌਰ ਤੇ ਫਲਾਈਟ ਦੇ ਨੇੜੇ ਸੋਧ ਲਈ ਘੱਟ ਰਵਾਇਤ। ਖੇਡ-ਪੁਸਤਕ "ਟ੍ਰਾਈ, ਸਿੱਖੋ, ਸ਼ਿਪ" ਤੋਂ ਬਦਲ ਕੇ "ਬਦਲਾਅ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰੋ, ਪਰਖੋ, ਫਿਰ ਉਡਾਓ" ਤੇ ਜਾ ਸਕਦਾ ਹੈ।
ਜਿਵੇਂ-ਜਿਵੇਂ ਇੱਕ ਪ੍ਰੋਵਾਈਡਰ ਡਿਫਾਲਟ ਚੋਣ ਬਣਦਾ ਹੈ, ਉਮੀਦਾਂ "ਨਵੀਂ ਹਾਰਡਵੇਅਰ ਲਈ ਪ੍ਰਭਾਵਸ਼ਾਲੀ" ਤੋਂ "ਏਅਰਲਾਈਨ-ਜੈਸੀ ਪੂਰਬਾਂਗ" ਤਕ ਬਦਲ ਜਾਂਦੀਆਂ ਹਨ। ਇਸ ਨਾਲ ਪ੍ਰੇਰਨਾ ਬਦਲ ਜਾਂਦੀ ਹੈ: ਉਹੀ ਤੇਜ਼ ਫੀਡਬੈਕ ਲੂਪ ਮੁੱਢੇ ਰੂਪ ਵਿੱਚ ਕੀਮਤੀ ਰਹਿੰਦੇ ਹਨ, ਪਰ ਹੋਰ ਸਿੱਖਿਆ ਨੂੰ ਜ਼ਮੀਨ 'ਤੇ (ਪ੍ਰਕਿਰਿਆ ਆਡਿਟ, ਭਾਗ ਸਕ੍ਰੀਨਿੰਗ, ਯੋਗਤਾ ਟੈਸਟ) ਵਿੱਚ ਲਿਆਉਣਾ ਪੈਂਦਾ ਹੈ ਨਾਂ ਕਿ ਉਡਾਣ ਰਿਸਕ ਵਧਾ ਕੇ।
ਉੱਚ-ਪ੍ਰੋਫਾਈਲ ਘਟਨਾਵਾਂ ਜਨਤਕ ਨਿਗਰਾਨੀ ਅਤੇ ਨਿਯਮਕ ਦਬਾਅ ਪੈਦਾ ਕਰਦੀਆਂ ਹਨ, ਜੋ ਇਟਰੈਸ਼ਨ ਨੂੰ ਮੰਹਗਾ ਕਰ ਸਕਦੀ ਹੈ। ਪਰ ਅਨੁਸ਼ਾਸਿਤ ਅੰਦਰੂਨੀ ਰਿਪੋਰਟਿੰਗ—ਨੀਅਰ-ਮਿਸਾਂ ਨੂੰ ਡੇਟਾ ਵਾਂਗ ਟ੍ਰੀਟ ਕਰਨਾ, ਦੋਸ਼ ਵਜੋਂ ਨਹੀਂ—ਸਿੱਖਣ ਨੂੰ ਗੁਣਾ ਕਰਨ ਦਿੰਦਾ ਹੈ ਬਿਨਾਂ ਕਿਸੇ ਜਨਤਕ ਨਾਕਾਮੀ ਦੇ ਇੰਤਜ਼ਾਰ ਕੀਤੇ।
SpaceX ਦੀਆਂ ਸਰੋਖੀ ਪ੍ਰਾਪਤੀਆਂ ਏਅਰੋਸਪੇਸ-ਨਿਰਦਿਸ਼ਟ ਹਨ, ਪਰ ਹੇਠਾਂਲੇ ਅਪਰੇਟਿੰਗ ਵਿਚਾਰ ਬਹੁਤ ਥਾਂਵਾਂ 'ਤੇ ਲਾਗੂ ਹੋ ਸਕਦੇ ਹਨ—ਖ਼ਾਸ ਕਰਕੇ ਉਹ ਕੰਪਨੀਆਂ ਜਿਹੜੀਆਂ ਭੌਤਿਕ ਉਤਪਾਦ ਬਣਾਉਂਦੀਆਂ ਜਾਂ ਜਟਿਲ ਆਪਰੇਸ਼ਨਾਂ ਚਲਾਉਂਦੀਆਂ ਹਨ।
ਸਭ ਤੋਂ ਜਿਆਦਾ ਲਾਗੂ ਹੋਣ ਵਾਲੇ ਸਬਕ ਸਿੱਖਣ ਦੀ ਗਤੀ ਬਾਰੇ ਹਨ:
ਤੁਹਾਨੂੰ ਇੰਜਣ ਬਣਾਉਣ ਦੀ ਲੋੜ ਨਹੀਂ ਕਿ ਤੁਸੀਂ ਇਨ੍ਹਾਂ ਤੋਂ ਫਾਇਦਾ ਲੈ ਸਕੋ। ਇੱਕ ਰੀਟੇਲ ਚੇਨ ਇਨ੍ਹਾਂ ਨੂੰ ਸਟੋਰ ਲੇਆਊਟਾਂ 'ਤੇ ਲਾਗੂ ਕਰ ਸਕਦੀ ਹੈ, ਇੱਕ ਹੈਲਥਕੇਅਰ ਗਰੁੱਪ ਪੇਸ਼ੰਟ ਫਲੋ 'ਤੇ, ਇੱਕ ਨਿਰਮਾਤਾ ਯੀਲਡ ਅਤੇ ਰੀ-ਵਰਕ 'ਤੇ।
ਪ੍ਰਕਿਰਿਆ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਹੀਰੋਇਕਸ ਨਾਲ ਨਹੀਂ:
ਜੇ ਤੁਸੀਂ ਸਾਫ਼ਟਵੇਅਰ ਡਿਲਿਵਰੀ ਵਿੱਚ ਇਸੇ "ਸ਼ਿਪ → ਸਿੱਖੋ → ਸੁਧਾਰ" ਲਹਿਰ ਨੂੰ ਲੈ ਕੇ ਆਉਂਦੇ ਹੋ, ਤਾਂ Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ ਫੀਡਬੈਕ ਲੂਪ ਨੂੰ ਅਸਲ ਵਰਤੋਂ ਦੇ ਨੇੜੇ ਲਿਆਉਂਦੇ ਹਨ—ਟੀਮਾਂ ਨੂੰ ਚੈਟ ਰਾਹੀਂ ਵੈੱਬ, ਬੈਕਐਂਡ ਅਤੇ ਮੋਬਾਈਲ ਐਪ ਬਣਾਉਣ ਅਤੇ ਦੋਹਰਾਉਣ ਦਿੰਦੇ ਹੋਏ—ਅਤੇ ਫਿਰ ਵੀ ਅਮਲੀ ਨਿਯੰਤਰਣ ਜਿਵੇਂ planning mode, snapshots, ਅਤੇ rollback ਜਿਵੇਂ ਜ਼ਰੂਰੀ ਕੰਟਰੋਲ ਰੱਖਦੇ ਹਨ।
ਨੋਟ: Koder.ai ਇਕ ਡੋਮੇਨ/ਪ产品 ਨਾਂ ਹੈ ਅਤੇ ਇਸਨੂੰ ਬਦਲਿਆ ਨਹੀਂ ਗਿਆ ਹੈ।
ਸਟੈਕ ਦਾ ਜ਼ਿਆਦਾ ਹਿੱਸਾ ਰੱਖਣਾ ਨੁਕਸਾਨਦਾਇਕ ਹੋ ਸਕਦਾ ਹੈ ਜਦੋਂ:
ਇੱਕ ਛੋਟਾ ਸੈੱਟ ਮੈਟਰਿਕਸ ਲਗਾਤਾਰ ਟ੍ਰੈਕ ਕਰੋ:
ਪਲੇਯਬੁੱਕ ਦੀ ਨਕਲ ਕਰੋ, ਉਤਪਾਦ ਨਹੀਂ: ਇੱਕ ਐਸਾ ਸਿਸਟਮ ਬਣਾਉ ਜੋ ਸਿੱਖਣ ਨੂੰ ਗੁਣਾ ਕਰੇ।
ਇਸਦਾ مطلب ਹੈ ਕਿ ਰਾਕੇਟ ਵਿਕਾਸ ਨੂੰ ਇੱਕ ਦੁਹਰਾਵਾਂ ਵਾਲੇ ਉਤਪਾਦ ਲੂਪ ਵਾਂਗ ਚਲਾਇਆ ਜਾਵੇ: ਬਣਾਓ → ਟੈਸਟ ਕਰੋ → ਸਿੱਖੋ → ਬਦਲੋ। ਇਕ “ਪਰਫੈਕਟ” ਡਿਜ਼ਾਈਨ ਦੀ ਉਡੀਕ ਕਰਨ ਦੀ ਬਜਾਏ, ਟੀਮਾਂ ਵਰਕਿੰਗ ਵਰਜਨਾਂ ਨੂੰ ਸ਼ਿਪ ਕਰਦੀਆਂ ਹਨ, ਅਸਲ ਸੰਚਾਲਨ ਡੇਟਾ (ਟੈਸਟ ਅਤੇ ਉਡਾਣਾਂ) ਇਕੱਤਰ ਕਰਦੀਆਂ ਹਨ, ਅਤੇ ਅਗਲੇ ਨਿਰਮਾ ਵਿੱਚ ਸੁਧਾਰ ਲਿਆਉਂਦੀਆਂ ਹਨ।
ਰਾਕੇਟਾਂ ਵਿੱਚ ਇਹ ਲੂਪ ਸਾਫਟਵੇਅਰ ਨਾਲੋਂ ਧੀਮਾ ਅਤੇ ਉੱਚ ਦਾਅ ਵਾਲਾ ਹੁੰਦਾ ਹੈ, ਪਰ ਮਕਸਦ ਇੱਕੋ ਹੀ ਹੈ: ਫੀਡਬੈਕ ਸਾਇਕਲਾਂ ਨੂੰ ਛੋਟਾ ਕਰੋ ਤਾਂ ਜੋ ਸਿੱਖਿਆ ਜ਼ਿਆਦਾ ਤੇਜ਼ੀ ਨਾਲ ਇਕਠੀ ਹੋਵੇ।
ਕੈਡੰਸ ਸਿੱਖਣ ਨੂੰ ਗੁਣਾ ਕਰਨ ਵਾਲਾ ਫਾਇਦਾ ਬਣਾ ਦਿੰਦੀ ਹੈ। ਵਾਰ-ਵਾਰ ਦੀਆਂ ਉਡਾਣਾਂ ਨਾਲ ਤੁਹਾਨੂੰ ਵਧੇਰੇ ਅਸਲੀ ਦੁਨੀਆ ਦੇ ਡੇਟਾ ਮਿਲਦੇ ਹਨ, ਸੁਧਾਰਾਂ ਦੀ ਤੇਜ਼ ਪੁਸ਼ਟੀ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਟੀਮਾਂ ਅਤੇ ਸਪਲਾਇਰਾਂ ਲਈ ਇੱਕ ਸਥਿਰ ਰਿਥਮ ਬਣਦਾ ਹੈ।
ਘੱਟ ਕੈਡੰਸ ਫੀਡਬੈਕ ਨੂੰ ਮਹੀਨਿਆਂ ਜਾਂ ਸਾਲਾਂ ਤੱਕ ਛੱਡ ਦਿੰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਦੁਬਾਰਾ ਬਣਾਉਣੇ ਔਖੇ ਹੋ ਜਾਂਦੇ ਹਨ, ਸੁਧਾਰਾਂ ਵਿੱਚ ਰਿਸਕ ਵੱਧਦਾ ਹੈ, ਅਤੇ ਸਾਂਝੀ ਯਾਦਦਾਸ਼ਤ ਖਤਮ ਹੋ ਸਕਦੀ ਹੈ।
ਵਰਟੀਕਲ ਇੰਟੀਗਰੇਸ਼ਨ ਬਾਹਰੀ ਹੋਫ਼ਾਫ਼ੇ ਘਟਾਉਂਦੀ ਹੈ। ਜਦੋਂ ਇੱਕੋ ਹੀ ਸੰਸਥਾ ਡਿਜ਼ਾਈਨ, ਨਿਰਮਾਣ, ਟੈਸਟਿੰਗ ਅਤੇ ਆਪਰੇਸ਼ਨ ਕੋਂਟਰੋਲ ਕਰਦੀ ਹੈ, ਤਦ ਸੋਧਾਂ ਨੂੰ ਵੈਂਡਰ ਸਮਾਂ-ਸਾਰਣੀ, ਕੰਟ੍ਰੈਕਟ ਮੁੜ-ਚਰਚਾ ਜਾਂ ਕ੍ਰਾਸ-ਕੰਪਨੀ ਇੰਟਰਫੇਸਾਂ ਦੀ ਉਡੀਕ ਨਹੀਂ ਰਹਿੰਦੀ।
ਵਾਸਤਵ ਵਿੱਚ, ਇਹ ਯੋਗ ਬਣਾਉਂਦਾ ਹੈ:
ਮੁੱਖ ਤੌਰ 'ਤੇ ਵਪਾਰੀ ਲਾਗਤ ਅਤੇ ਅੰਦਰੂਨੀ ਬੋਤਲ-ਗਰਦੇ ਹਨ। ਸਟੈਕ ਦਾ ਵੱਧ ਹਿਸਾ ਆਪਣੇ ਹੱਥ ਵਿੱਚ ਰੱਖਣ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਫੈਸਿਲਟੀਜ਼, ਟੂਲਿੰਗ, ਸਟਾਫ਼ ਅਤੇ ਕਵਾਲਿਟੀ ਸਿਸਟਮਾਂ ਲਈ ਖਰਚ ਚੁੱਕਦੇ ਹੋ—ਚਾਹੇ ਵਾਲੀਮ ਘੱਟ ਹੋ ਜਾਵੇ।
ਇਹ ਅੰਦਰੂਨੀ ਜੋਖਿਮ ਵੀ ਬਣਾਉਂਦਾ ਹੈ: ਜੇ ਕੋਈ ਅੰਦਰੂਨੀ ਪ੍ਰੋਡਕਸ਼ਨ ਸੈੱਲ ਪਿੱਛੇ ਰਹਿ ਜਾਂਦੀ ਹੈ ਤਾਂ ਬੈਕਅਪ ਵੈਂਡਰ ਨਹੀਂ ਹੁੰਦਾ। ਪੇਅਆਫ਼ ਸਿਰਫ਼ ਤਦ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਪ੍ਰਬੰਧਨ ਗੁਣਵੱਤਾ, ਪ੍ਰਵਾਹ ਅਤੇ ਤਰਜੀਹਾਂ ਨੂੰ ਡਿਸਿਸਪਲਿਨਡ ਰੱਖੇ।
ਇੱਕ ਤੇਜ਼ ਫੈਕਟਰੀ ਟੈਸਟਿੰਗ ਨੂੰ ਖਾਸ ਘਟਨਾ ਦੀ ਬਜਾਏ ਰੂਟੀਨ ਬਣਾ ਦਿੰਦੀ ਹੈ। ਜੇ "ਅਗਲਾ ਯੂਨਿਟ" ਬਣਾਉਣ ਲਈ ਹਫ਼ਤੇ ਲੱਗਦੇ ਹਨ ਤਾਂ ਸਿੱਖਿਆ ਉਡੀਕ ਕਰਦੀ ਹੈ; ਜੇ ਦਿਨ ਲੱਗਦੇ ਹਨ ਤਾਂ ਟੀਮ ਹੋਰ ਪ੍ਰਯੋਗ ਚਲਾ ਸਕਦੀਆਂ ਹਨ, ਵਾਰੰ-ਵਾਰ ਵੇਰਵੇ ਅਲੱਗ ਕਰ ਸਕਦੀਆਂ ਹਨ, ਅਤੇ ਸੁਧਾਰ ਤੀਜ਼ੀ ਨਾਲ ਪੁਸ਼ਟੀ ਹੋ ਸਕਦੇ ਹਨ।
ਨਿਰਮਾਣ ਦੀ ਗਤੀ ਨਾਲ ਆਪਰੇਸ਼ਨ ਵੀ ਅਸਥਿਰ ਹੁੰਦਾ ਹੈ: ਭਰੋਸੇਯੋਗ ਆਉਟਪੁੱਟ ਸਟੈਫਿੰਗ, ਸਟੌਕ ਅਤੇ ਲਾਂਚ ਯੋਜਨਾ ਨੂੰ ਸਮਰਥਿਤ ਕਰਦਾ ਹੈ।
ਸਟੈਂਡਰਡਾਈਜੇਸ਼ਨ ਦੁਹਰਾਈ ਅਤੇ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਹੰਗਾਮਿਆਂ ਨੂੰ ਘਟਾਉਂਦੀ ਹੈ। ਜਦੋਂ ਇੰਟਰਫੇਸ ਅਤੇ ਪ੍ਰਕਿਰਿਆਵਾਂ ਸਥਿਰ ਹਨ, ਤਾਂ ਇੱਕ ਸਬਸਿਸਟਮ ਵਿੱਚ ਬਦਲਾਅ ਹੋਰ ਥਾਂ 'ਤੇ ਦੁਬਾਰਾ ਡਿਜ਼ਾਈਨ ਕਰਵਾਉਂਦਾ ਨਹੀਂ।
ਇਸਦੇ ਫਾਇਦੇ:
ਨਤੀਜਾ: ਘੱਟ ਅਫਰਾ-ਤਫਰੀ ਨਾਲ ਤੇਜ਼ ਇਟਰੈਸ਼ਨ।
ਇਸਦਾ ਮਤਲਬ ਹੈ ਟੈਸਟਾਂ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਡਿਜ਼ਾਈਨ ਕਰਨਾ ਕਿ ਨੁਕਸਾਨ ਸੀਮਿਤ, ਇੰਸਟ੍ਰੂਮੈਂਟਡ ਅਤੇ ਜਾਣਕਾਰੀ-ਪ੍ਰਦ ਹੋਵੇ। ਲਕੜੀ ਤੋਂ “ਤੇਜ਼ੀ ਨਾਲ ਫੇਲ” ਮਤਲਬ ਲੈਣ ਦੇ ਬਜਾਏ, ਮਕਸਦ ਹੈ ਜਲਦੀ ਸਿੱਖਣਾ ਬਿਨਾਂ ਲੋਕਾਂ ਜਾਂ ਮਿਸ਼ਨ ਨੂੰ ਖਤਰੇ ਵਿੱਚ ਪਾਏ।
ਚੰਗੀ ਪ੍ਰੈਕਟਿਸ ਵਿੱਚ ਸ਼ਾਮਲ ਹੈ:
ਪ੍ਰੋਟੋਟਾਈਪ ਟੈਸਟਿੰਗ ਸਿੱਖਣ ਨੂੰ ਪ੍ਰਾਥਮਿਕਤਾ ਦਿੰਦੀ ਹੈ ਅਤੇ ਅਣਜਾਣੀਆਂ ਬੇਨਤੀ ਕਰਨ ਲਈ ਵੱਧ ਜੋਖਿਮ ਸਵੀਕਾਰ ਕਰ ਸਕਦੀ ਹੈ। ਓਪੀਰੇਸ਼ਨਲ ਮਿਸ਼ਨਾਂ ਵਿੱਚ ਮਿਸ਼ਨ ਸਫਲਤਾ, ਗਾਹਕ ਪ੍ਰਭਾਵ ਅਤੇ ਅਸਥਿਰਤਾ ਪ੍ਰਾਥਮਿਕ ਹੋਂਦੀ ਹੈ—ਬਦਲਾਵਾਂ ਸੰਯਮ ਨਾਲ ਪ੍ਰबंधਿਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ।
ਇਨ੍ਹਾਂ ਨੂੰ ਵੱਖਰਾ ਰੱਖਣ ਨਾਲ ਵਿਕਾਸ ਦੌਰਾਨ ਗਤੀ ਅਤੇ ਡਿਲਿਵਰੀ ਦੌਰਾਨ ਭਰੋਸੇਯੋਗਤਾ ਦੋਹਾਂ ਕਾਇਮ ਰਹਿੰਦੇ ਹਨ।
ਰਿਉਜ਼ਬਿਲਿਟੀ ਸਿਰਫ਼ ਉਦਾਹਰਣ ਦੇ ਤੌਰ 'ਤੇ ਲਾਭ ਨਹੀਂ ਦਿੰਦੀ ਜੇ ਤਰਤੀਬੀ ਰੀਫਰਬਿਸ਼ਮੈਂਟ ਤੇਜ਼ ਅਤੇ ਪੇਸ਼ਗੋਈਯੋਗ ਨਾ ਹੋਵੇ। ਇਕ ਬੂਸਟਰ ਜੋ ਵੱਡੇ ਪੈਮਾਣੇ ਦੇ ਟੁੱਟ-ਫੇਰ ਦੀ ਲੋੜ ਰੱਖਦਾ ਹੈ, ਉਹ ਇੱਕ ਉੱਚ-ਗਤਿਵਿਧੀ ਸੰਪਤੀ ਦੀ ਬਜਾਏ ਮਿਊਜ਼ੀਅਮ ਆਈਟਮ ਬਣ ਜਾਂਦਾ ਹੈ।
ਰਿਉਜ਼ ਤੋਂ ਲਾਭ ਲੈਣ ਲਈ ਕੁੰਜੀਆਂ ਹਨ:
ਨਾਇਕੀਂ ਨੂੰ ਲਾਇਸੰਸਿੰਗ, ਰੈਂਜ ਉਪਲਬਧਤਾ ਅਤੇ ਮਿਸ਼ਨ ਅਸ਼ੋਰੈਂਸ ਜ਼ਰੂਰਤਾਂ ਵੱਲੋਂ ਸੀਮਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ—ਇਹ ਉਹ ਹਾਰਡ ਬਾਊਂਡਰੀਆਂ ਹਨ ਜੋ ਸਿਰਫ਼ ਟੀਮ ਦੀ ਇੱਛਾ ਨਾਲ ਛੋਟੀ ਨਹੀਂ ਹੁੰਦੀਆਂ।
ਕੈਡੰਸ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਨ ਵਾਲੇ ਤੱਤ:
