DevOps ਸਿਧਾਂਤਾਂ 'ਤੇ ਆਧਾਰਿਤ ਸੱਤ ਪਰਿਵਰਤਨ ਆਰਕੀਟਾਈਪਸ

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

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

ਜੌਨ ਵਿਲਿਸ - DevOps ਦੇ ਪਿਤਾਵਾਂ ਵਿੱਚੋਂ ਇੱਕ। ਜੌਨ ਕੋਲ ਬਹੁਤ ਸਾਰੀਆਂ ਕੰਪਨੀਆਂ ਨਾਲ ਕੰਮ ਕਰਨ ਦਾ ਦਹਾਕਿਆਂ ਦਾ ਤਜਰਬਾ ਹੈ। ਹਾਲ ਹੀ ਵਿੱਚ, ਜੌਨ ਨੇ ਉਹਨਾਂ ਖਾਸ ਪੈਟਰਨਾਂ ਵੱਲ ਧਿਆਨ ਦੇਣਾ ਸ਼ੁਰੂ ਕੀਤਾ ਜੋ ਉਹਨਾਂ ਵਿੱਚੋਂ ਹਰੇਕ ਨਾਲ ਕੰਮ ਕਰਦੇ ਸਮੇਂ ਵਾਪਰਦੇ ਹਨ. ਇਹਨਾਂ ਪੁਰਾਤੱਤਵ ਕਿਸਮਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਜੌਨ ਕੰਪਨੀਆਂ ਨੂੰ DevOps ਪਰਿਵਰਤਨ ਦੇ ਸਹੀ ਮਾਰਗ 'ਤੇ ਮਾਰਗਦਰਸ਼ਨ ਕਰਦਾ ਹੈ। DevOops 2018 ਕਾਨਫਰੰਸ ਤੋਂ ਉਸਦੀ ਰਿਪੋਰਟ ਦੇ ਅਨੁਵਾਦ ਵਿੱਚ ਇਹਨਾਂ ਪੁਰਾਤੱਤਵ ਕਿਸਮਾਂ ਬਾਰੇ ਹੋਰ ਪੜ੍ਹੋ।

ਸਪੀਕਰ ਬਾਰੇ:

ਆਈਟੀ ਪ੍ਰਬੰਧਨ ਵਿੱਚ 35 ਸਾਲਾਂ ਤੋਂ ਵੱਧ, ਕੈਨੋਨੀਕਲ ਵਿਖੇ ਓਪਨਕਲਾਊਡ ਦੇ ਪੂਰਵਗਾਮੀ ਦੀ ਸਿਰਜਣਾ ਵਿੱਚ ਹਿੱਸਾ ਲਿਆ, 10 ਸਟਾਰਟਅੱਪਾਂ ਵਿੱਚ ਹਿੱਸਾ ਲਿਆ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਦੋ ਡੇਲ ਅਤੇ ਡੌਕਰ ਨੂੰ ਵੇਚੇ ਗਏ ਸਨ। ਵਰਤਮਾਨ ਵਿੱਚ ਉਹ SJ Technologies ਵਿਖੇ DevOps ਅਤੇ ਡਿਜੀਟਲ ਅਭਿਆਸਾਂ ਦੇ ਉਪ ਪ੍ਰਧਾਨ ਹਨ।

ਅੱਗੇ ਜੌਨ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ ਕਹਾਣੀ ਹੈ.

ਮੇਰਾ ਨਾਮ ਜੌਨ ਵਿਲਿਸ ਹੈ ਅਤੇ ਮੈਨੂੰ ਲੱਭਣ ਲਈ ਸਭ ਤੋਂ ਆਸਾਨ ਜਗ੍ਹਾ ਟਵਿੱਟਰ 'ਤੇ ਹੈ, @botchagalupe. ਮੇਰੇ ਕੋਲ Gmail ਅਤੇ GitHub 'ਤੇ ਉਹੀ ਉਪਨਾਮ ਹੈ. ਏ ਇਸ ਲਿੰਕ ਰਾਹੀਂ ਤੁਸੀਂ ਉਹਨਾਂ ਲਈ ਮੇਰੀਆਂ ਰਿਪੋਰਟਾਂ ਅਤੇ ਪੇਸ਼ਕਾਰੀਆਂ ਦੀ ਵੀਡੀਓ ਰਿਕਾਰਡਿੰਗ ਲੱਭ ਸਕਦੇ ਹੋ।

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

DevOps ਕੀ ਹੈ?

ਦਰਅਸਲ, ਜੇਕਰ ਤੁਸੀਂ 10 ਵੱਖ-ਵੱਖ ਲੋਕਾਂ ਨੂੰ ਪੁੱਛਦੇ ਹੋ, ਤਾਂ ਉਹ 10 ਵੱਖ-ਵੱਖ ਜਵਾਬ ਦੇਣਗੇ। ਪਰ ਇੱਥੇ ਦਿਲਚਸਪ ਗੱਲ ਇਹ ਹੈ: ਇਹਨਾਂ ਵਿੱਚੋਂ ਸਾਰੇ ਦਸ ਜਵਾਬ ਸਹੀ ਹੋਣਗੇ। ਇੱਥੇ ਕੋਈ ਗਲਤ ਜਵਾਬ ਨਹੀਂ ਹੈ. ਮੈਂ ਲਗਭਗ 10 ਸਾਲਾਂ ਤੋਂ DevOps ਵਿੱਚ ਬਹੁਤ ਡੂੰਘਾ ਸੀ, ਅਤੇ ਪਹਿਲੇ DevOpsDay ਵਿੱਚ ਪਹਿਲਾ ਅਮਰੀਕੀ ਸੀ। ਮੈਂ ਇਹ ਨਹੀਂ ਕਹਾਂਗਾ ਕਿ ਮੈਂ DevOps ਵਿੱਚ ਸ਼ਾਮਲ ਹਰੇਕ ਨਾਲੋਂ ਹੁਸ਼ਿਆਰ ਹਾਂ, ਪਰ ਸ਼ਾਇਦ ਹੀ ਕੋਈ ਅਜਿਹਾ ਹੋਵੇ ਜਿਸ ਨੇ ਇਸ 'ਤੇ ਜਿੰਨਾ ਮਿਹਨਤ ਕੀਤੀ ਹੋਵੇ। ਮੇਰਾ ਮੰਨਣਾ ਹੈ ਕਿ DevOps ਉਦੋਂ ਵਾਪਰਦਾ ਹੈ ਜਦੋਂ ਮਨੁੱਖੀ ਪੂੰਜੀ ਅਤੇ ਤਕਨਾਲੋਜੀ ਇਕੱਠੇ ਆਉਂਦੇ ਹਨ। ਅਸੀਂ ਅਕਸਰ ਮਨੁੱਖੀ ਮਾਪ ਨੂੰ ਭੁੱਲ ਜਾਂਦੇ ਹਾਂ, ਹਾਲਾਂਕਿ ਅਸੀਂ ਹਰ ਕਿਸਮ ਦੇ ਸਭਿਆਚਾਰਾਂ ਬਾਰੇ ਬਹੁਤ ਕੁਝ ਬੋਲਦੇ ਹਾਂ.

ਹੁਣ ਸਾਡੇ ਕੋਲ ਬਹੁਤ ਸਾਰਾ ਡੇਟਾ ਹੈ, ਪੰਜ ਸਾਲਾਂ ਦੀ ਅਕਾਦਮਿਕ ਖੋਜ, ਉਦਯੋਗਿਕ ਪੈਮਾਨੇ 'ਤੇ ਸਿਧਾਂਤਾਂ ਦੀ ਜਾਂਚ। ਇਹ ਅਧਿਐਨ ਸਾਨੂੰ ਕੀ ਦੱਸਦੇ ਹਨ ਕਿ ਜੇਕਰ ਤੁਸੀਂ ਇੱਕ ਸੰਗਠਨਾਤਮਕ ਸੱਭਿਆਚਾਰ ਵਿੱਚ ਕੁਝ ਵਿਹਾਰਕ ਪੈਟਰਨਾਂ ਨੂੰ ਜੋੜਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ 2000x ਦੀ ਗਤੀ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ। ਇਹ ਪ੍ਰਵੇਗ ਸਥਿਰਤਾ ਵਿੱਚ ਬਰਾਬਰ ਸੁਧਾਰ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ। ਇਹ ਲਾਭ ਦਾ ਇੱਕ ਮਾਤਰਾਤਮਕ ਮਾਪ ਹੈ ਜੋ DevOps ਕਿਸੇ ਵੀ ਕੰਪਨੀ ਨੂੰ ਲਿਆ ਸਕਦਾ ਹੈ। ਕੁਝ ਸਾਲ ਪਹਿਲਾਂ, ਮੈਂ ਇੱਕ Fortune 5000 ਕੰਪਨੀ ਦੇ CEO ਨਾਲ DevOps ਬਾਰੇ ਗੱਲ ਕਰ ਰਿਹਾ ਸੀ। ਜਦੋਂ ਮੈਂ ਪੇਸ਼ਕਾਰੀ ਦੀ ਤਿਆਰੀ ਕਰ ਰਿਹਾ ਸੀ, ਮੈਂ ਬਹੁਤ ਘਬਰਾਇਆ ਹੋਇਆ ਸੀ ਕਿਉਂਕਿ ਮੈਨੂੰ 5 ਮਿੰਟਾਂ ਵਿੱਚ ਆਪਣੇ ਸਾਲਾਂ ਦੇ ਅਨੁਭਵ ਦਾ ਸਾਰ ਦੇਣਾ ਪਿਆ ਸੀ।

ਅੰਤ ਵਿੱਚ ਮੈਂ ਹੇਠਾਂ ਦਿੱਤਾ DevOps ਦੀ ਪਰਿਭਾਸ਼ਾ: ਇਹ ਅਭਿਆਸਾਂ ਅਤੇ ਪੈਟਰਨਾਂ ਦਾ ਇੱਕ ਸਮੂਹ ਹੈ ਜੋ ਮਨੁੱਖੀ ਪੂੰਜੀ ਨੂੰ ਉੱਚ-ਪ੍ਰਦਰਸ਼ਨ ਵਾਲੀ ਸੰਗਠਨਾਤਮਕ ਪੂੰਜੀ ਵਿੱਚ ਬਦਲਣ ਦੇ ਯੋਗ ਬਣਾਉਂਦਾ ਹੈ। ਟੋਇਟਾ ਨੇ ਪਿਛਲੇ 50 ਜਾਂ 60 ਸਾਲਾਂ ਤੋਂ ਜਿਸ ਤਰ੍ਹਾਂ ਦਾ ਸੰਚਾਲਨ ਕੀਤਾ ਹੈ, ਉਸ ਦੀ ਉਦਾਹਰਣ ਹੈ।

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

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

ਮੈਨੂੰ ਲਗਦਾ ਹੈ ਕਿ ਮੇਰੇ ਬਹੁਤ ਸਾਰੇ ਸਹਿਯੋਗੀ ਗਲਤੀ ਕਰਦੇ ਹਨ ਕਿ ਉਹ ਸਿਰਫ਼ ਕੰਪਨੀ ਨੂੰ ਪੰਜ-ਪੁਆਇੰਟ ਗਾਈਡ ਦਿੰਦੇ ਹਨ ਅਤੇ ਫਿਰ ਛੇ ਮਹੀਨਿਆਂ ਬਾਅਦ ਵਾਪਸ ਆਉਂਦੇ ਹਨ ਅਤੇ ਦੇਖਦੇ ਹਨ ਕਿ ਕੀ ਹੋਇਆ. ਇੱਥੋਂ ਤੱਕ ਕਿ ਇੱਕ ਚੰਗੀ ਸਕੀਮ ਜਿਵੇਂ ਕਿ ਮੁੱਲ ਸਟ੍ਰੀਮ ਮੈਪਿੰਗ ਵਿੱਚ, ਮੰਨ ਲਓ, ਅੰਨ੍ਹੇ ਸਥਾਨ ਹਨ. ਵੱਖ-ਵੱਖ ਕੰਪਨੀਆਂ ਦੇ ਡਾਇਰੈਕਟਰਾਂ ਨਾਲ ਸੈਂਕੜੇ ਇੰਟਰਵਿਊਆਂ ਤੋਂ ਬਾਅਦ, ਮੈਂ ਇੱਕ ਖਾਸ ਪੈਟਰਨ ਵਿਕਸਿਤ ਕੀਤਾ ਹੈ ਜੋ ਸਾਨੂੰ ਸਮੱਸਿਆ ਨੂੰ ਇਸਦੇ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੰਡਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਹੁਣ ਅਸੀਂ ਇਹਨਾਂ ਵਿੱਚੋਂ ਹਰੇਕ ਹਿੱਸੇ ਨੂੰ ਕ੍ਰਮ ਵਿੱਚ ਵਿਚਾਰਾਂਗੇ। ਕਿਸੇ ਵੀ ਤਕਨੀਕੀ ਹੱਲ ਨੂੰ ਲਾਗੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਮੈਂ ਇਸ ਪੈਟਰਨ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹਾਂ, ਅਤੇ ਨਤੀਜੇ ਵਜੋਂ, ਮੇਰੀਆਂ ਸਾਰੀਆਂ ਕੰਧਾਂ ਚਿੱਤਰਾਂ ਨਾਲ ਢੱਕੀਆਂ ਹੁੰਦੀਆਂ ਹਨ. ਹਾਲ ਹੀ ਵਿੱਚ ਮੈਂ ਇੱਕ ਮਿਉਚੁਅਲ ਫੰਡ ਨਾਲ ਕੰਮ ਕਰ ਰਿਹਾ ਸੀ ਅਤੇ ਮੈਂ ਅਜਿਹੀਆਂ 100-150 ਸਕੀਮਾਂ ਨੂੰ ਖਤਮ ਕੀਤਾ।

ਮਾੜਾ ਸੱਭਿਆਚਾਰ ਨਾਸ਼ਤੇ ਲਈ ਚੰਗੀ ਪਹੁੰਚ ਖਾਂਦਾ ਹੈ

ਮੁੱਖ ਵਿਚਾਰ ਇਹ ਹੈ: ਜੇਕਰ ਸੰਸਥਾ ਦਾ ਸੱਭਿਆਚਾਰ ਖੁਦ ਖਰਾਬ ਹੈ ਤਾਂ Lean, Agile, SAFE ਅਤੇ DevOps ਦੀ ਕੋਈ ਵੀ ਮਾਤਰਾ ਮਦਦ ਨਹੀਂ ਕਰੇਗੀ। ਇਹ ਸਕੂਬਾ ਗੀਅਰ ਤੋਂ ਬਿਨਾਂ ਡੂੰਘਾਈ ਤੱਕ ਗੋਤਾਖੋਰੀ ਕਰਨ ਜਾਂ ਐਕਸ-ਰੇ ਤੋਂ ਬਿਨਾਂ ਕੰਮ ਕਰਨ ਵਰਗਾ ਹੈ। ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿਚ, ਡ੍ਰਕਰ ਅਤੇ ਡੈਮਿੰਗ ਦੀ ਵਿਆਖਿਆ ਕਰਨ ਲਈ: ਇੱਕ ਮਾੜਾ ਸੰਗਠਨਾਤਮਕ ਸਭਿਆਚਾਰ ਕਿਸੇ ਵੀ ਚੰਗੀ ਪ੍ਰਣਾਲੀ ਨੂੰ ਇਸ ਨੂੰ ਦਬਾਏ ਬਿਨਾਂ ਨਿਗਲ ਜਾਵੇਗਾ।

ਇਸ ਮੁੱਖ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਹੇਠ ਲਿਖੇ ਕਦਮ ਚੁੱਕਣ ਦੀ ਲੋੜ ਹੈ:

1. ਸਾਰੇ ਕੰਮ ਨੂੰ ਦ੍ਰਿਸ਼ਮਾਨ ਬਣਾਓ: ਤੁਹਾਨੂੰ ਸਾਰੇ ਕੰਮ ਨੂੰ ਦ੍ਰਿਸ਼ਮਾਨ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ। ਇਸ ਅਰਥ ਵਿਚ ਨਹੀਂ ਕਿ ਇਹ ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ ਕਿਸੇ ਸਕ੍ਰੀਨ 'ਤੇ ਪ੍ਰਦਰਸ਼ਿਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਪਰ ਇਸ ਅਰਥ ਵਿਚ ਕਿ ਇਹ ਦੇਖਣਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
2. ਏਕੀਕ੍ਰਿਤ ਕੰਮ ਪ੍ਰਬੰਧਨ ਪ੍ਰਣਾਲੀਆਂ: ਪ੍ਰਬੰਧਨ ਪ੍ਰਣਾਲੀਆਂ ਨੂੰ ਇਕਸਾਰ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। “ਕਬਾਇਲੀ” ਗਿਆਨ ਅਤੇ ਸੰਸਥਾਗਤ ਗਿਆਨ ਦੀ ਸਮੱਸਿਆ ਵਿੱਚ, 9 ਵਿੱਚੋਂ 10 ਮਾਮਲਿਆਂ ਵਿੱਚ ਰੁਕਾਵਟ ਲੋਕ ਹਨ। ਕਿਤਾਬ ਵਿੱਚ "ਫੀਨਿਕ੍ਸ ਪ੍ਰੋਜੈਕਟ" ਸਮੱਸਿਆ ਇੱਕ ਸਿੰਗਲ ਵਿਅਕਤੀ, ਬ੍ਰੈਂਟ ਨਾਲ ਸੀ, ਜਿਸ ਕਾਰਨ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਸਮਾਂ-ਸਾਰਣੀ ਤੋਂ ਤਿੰਨ ਸਾਲ ਪਿੱਛੇ ਕਰਨਾ ਪਿਆ। ਅਤੇ ਮੈਂ ਹਰ ਜਗ੍ਹਾ ਇਹਨਾਂ "ਬ੍ਰੈਂਟਸ" ਵਿੱਚ ਭੱਜਦਾ ਹਾਂ. ਇਹਨਾਂ ਰੁਕਾਵਟਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ, ਮੈਂ ਸਾਡੀ ਸੂਚੀ ਵਿੱਚ ਅਗਲੀਆਂ ਦੋ ਆਈਟਮਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹਾਂ.
3. ਥਿਊਰੀ ਆਫ਼ ਕੰਸਟ੍ਰੈਂਟਸ ਮੈਥੋਡੌਲੋਜੀ: ਪਾਬੰਦੀਆਂ ਦਾ ਸਿਧਾਂਤ।
4. ਸਹਿਯੋਗੀ ਹੈਕ: ਸਹਿਯੋਗ ਹੈਕ.
5. ਟੋਇਟਾ ਕਾਟਾ (ਕੋਚਿੰਗ ਕਾਟਾ): ਮੈਂ ਟੋਇਟਾ ਕਾਟਾ ਬਾਰੇ ਜ਼ਿਆਦਾ ਗੱਲ ਨਹੀਂ ਕਰਾਂਗਾ। ਜੇ ਦਿਲਚਸਪੀ ਹੈ, ਮੇਰੇ ਗਿਥਬ 'ਤੇ ਪੇਸ਼ਕਾਰੀਆਂ ਹਨ ਇਹਨਾਂ ਵਿੱਚੋਂ ਲਗਭਗ ਹਰ ਇੱਕ ਵਿਸ਼ੇ 'ਤੇ।
6. ਮਾਰਕੀਟ ਓਰੀਐਂਟਿਡ ਸੰਗਠਨ: ਮਾਰਕੀਟ-ਅਧਾਰਿਤ ਸੰਗਠਨ.
7. ਸ਼ਿਫਟ-ਖੱਬੇ ਆਡੀਟਰ: ਚੱਕਰ ਦੇ ਸ਼ੁਰੂਆਤੀ ਪੜਾਵਾਂ 'ਤੇ ਆਡਿਟ.

ਮੈਂ ਇੱਕ ਸੰਸਥਾ ਨਾਲ ਕੰਮ ਕਰਨਾ ਬਹੁਤ ਹੀ ਅਸਾਨੀ ਨਾਲ ਸ਼ੁਰੂ ਕਰਦਾ ਹਾਂ: ਮੈਂ ਕੰਪਨੀ ਵਿੱਚ ਜਾਂਦਾ ਹਾਂ ਅਤੇ ਕਰਮਚਾਰੀਆਂ ਨਾਲ ਗੱਲ ਕਰਦਾ ਹਾਂ। ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਵੇਖ ਸਕਦੇ ਹੋ, ਕੋਈ ਉੱਚ ਤਕਨਾਲੋਜੀ ਨਹੀਂ. ਤੁਹਾਨੂੰ ਸਿਰਫ਼ ਲਿਖਣ ਲਈ ਕੁਝ ਚਾਹੀਦਾ ਹੈ। ਮੈਂ ਇੱਕ ਕਮਰੇ ਵਿੱਚ ਕਈ ਟੀਮਾਂ ਇਕੱਠੀਆਂ ਕਰਦਾ ਹਾਂ ਅਤੇ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਦਾ ਹਾਂ ਕਿ ਉਹ ਮੇਰੇ 7 ਪੁਰਾਤੱਤਵ ਕਿਸਮਾਂ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ ਮੈਨੂੰ ਕੀ ਦੱਸਦੇ ਹਨ। ਅਤੇ ਫਿਰ ਮੈਂ ਉਹਨਾਂ ਨੂੰ ਖੁਦ ਇੱਕ ਮਾਰਕਰ ਦਿੰਦਾ ਹਾਂ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਬੋਰਡ ਉੱਤੇ ਉਹ ਸਭ ਕੁਝ ਲਿਖਣ ਲਈ ਕਹਿੰਦਾ ਹਾਂ ਜੋ ਉਹਨਾਂ ਨੇ ਹੁਣ ਤੱਕ ਉੱਚੀ ਆਵਾਜ਼ ਵਿੱਚ ਕਿਹਾ ਹੈ। ਆਮ ਤੌਰ 'ਤੇ ਇਸ ਕਿਸਮ ਦੀਆਂ ਮੀਟਿੰਗਾਂ ਵਿੱਚ ਇੱਕ ਵਿਅਕਤੀ ਹੁੰਦਾ ਹੈ ਜੋ ਸਭ ਕੁਝ ਲਿਖਦਾ ਹੈ, ਅਤੇ ਸਭ ਤੋਂ ਵਧੀਆ ਉਹ 10% ਚਰਚਾ ਲਿਖ ਸਕਦਾ ਹੈ। ਮੇਰੀ ਵਿਧੀ ਨਾਲ, ਇਹ ਅੰਕੜਾ ਲਗਭਗ 40% ਤੱਕ ਵਧਾਇਆ ਜਾ ਸਕਦਾ ਹੈ.

(ਇਸ ਦ੍ਰਿਸ਼ਟਾਂਤ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ ਲਿੰਕ ਵੇਖੋ)

ਮੇਰੀ ਪਹੁੰਚ ਵਿਲੀਅਮ ਸਨਾਈਡਰ ਦੇ ਕੰਮ 'ਤੇ ਅਧਾਰਤ ਹੈ। ਰੀਇੰਜੀਨੀਅਰਿੰਗ ਵਿਕਲਪ). ਪਹੁੰਚ ਇਸ ਵਿਚਾਰ 'ਤੇ ਅਧਾਰਤ ਹੈ ਕਿ ਕਿਸੇ ਵੀ ਸੰਗਠਨ ਨੂੰ ਚਾਰ ਵਰਗਾਂ ਵਿੱਚ ਵੰਡਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਮੇਰੇ ਲਈ ਇਹ ਸਕੀਮ ਆਮ ਤੌਰ 'ਤੇ ਉਨ੍ਹਾਂ ਸੈਂਕੜੇ ਹੋਰ ਸਕੀਮਾਂ ਨਾਲ ਕੰਮ ਕਰਨ ਦਾ ਨਤੀਜਾ ਹੈ ਜੋ ਕਿਸੇ ਸੰਸਥਾ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਵੇਲੇ ਪੈਦਾ ਹੁੰਦੀਆਂ ਹਨ। ਮੰਨ ਲਓ ਕਿ ਸਾਡੇ ਕੋਲ ਉੱਚ ਪੱਧਰੀ ਨਿਯੰਤਰਣ ਵਾਲੀ ਸੰਸਥਾ ਹੈ, ਪਰ ਘੱਟ ਯੋਗਤਾ ਦੇ ਨਾਲ। ਇਹ ਇੱਕ ਬਹੁਤ ਹੀ ਅਣਚਾਹੇ ਵਿਕਲਪ ਹੈ: ਜਦੋਂ ਹਰ ਕੋਈ ਲਾਈਨ 'ਤੇ ਖੜ੍ਹਾ ਹੁੰਦਾ ਹੈ, ਪਰ ਕੋਈ ਨਹੀਂ ਜਾਣਦਾ ਕਿ ਕੀ ਕਰਨਾ ਹੈ।

ਇੱਕ ਕੁਝ ਬਿਹਤਰ ਵਿਕਲਪ ਇੱਕ ਉੱਚ ਪੱਧਰੀ ਨਿਯੰਤਰਣ ਅਤੇ ਯੋਗਤਾ ਦੋਵਾਂ ਦੇ ਨਾਲ ਹੈ। ਜੇਕਰ ਅਜਿਹੀ ਕੰਪਨੀ ਲਾਭਦਾਇਕ ਹੈ, ਤਾਂ ਸ਼ਾਇਦ ਇਸ ਨੂੰ DevOps ਦੀ ਜ਼ਰੂਰਤ ਨਹੀਂ ਹੈ. ਅਜਿਹੀ ਕੰਪਨੀ ਨਾਲ ਕੰਮ ਕਰਨਾ ਸਭ ਤੋਂ ਦਿਲਚਸਪ ਹੈ ਜਿਸ ਕੋਲ ਉੱਚ ਪੱਧਰ ਦਾ ਨਿਯੰਤਰਣ, ਘੱਟ ਯੋਗਤਾ ਅਤੇ ਸਹਿਯੋਗ ਹੈ, ਪਰ ਉਸੇ ਸਮੇਂ ਇੱਕ ਉੱਚ ਪੱਧਰੀ ਸੱਭਿਆਚਾਰ (ਖੇਤੀ) ਹੈ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਕੰਪਨੀ ਕੋਲ ਬਹੁਤ ਸਾਰੇ ਲੋਕ ਹਨ ਜੋ ਉੱਥੇ ਕੰਮ ਕਰਨਾ ਪਸੰਦ ਕਰਦੇ ਹਨ ਅਤੇ ਲੇਬਰ ਟਰਨਓਵਰ ਘੱਟ ਹੈ।

(ਇਸ ਦ੍ਰਿਸ਼ਟਾਂਤ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ ਲਿੰਕ ਵੇਖੋ)

ਇਹ ਮੈਨੂੰ ਜਾਪਦਾ ਹੈ ਕਿ ਸਖ਼ਤ ਦਿਸ਼ਾ-ਨਿਰਦੇਸ਼ਾਂ ਵਾਲੇ ਤਰੀਕੇ ਸੱਚ ਦੀ ਪ੍ਰਾਪਤੀ ਦੇ ਰਾਹ ਵਿੱਚ ਆ ਜਾਂਦੇ ਹਨ। ਖਾਸ ਤੌਰ 'ਤੇ ਵੈਲਯੂ ਸਟ੍ਰੀਮ ਮੈਪਿੰਗ ਵਿੱਚ, ਇਸ ਬਾਰੇ ਬਹੁਤ ਸਾਰੇ ਨਿਯਮ ਹਨ ਕਿ ਜਾਣਕਾਰੀ ਨੂੰ ਕਿਵੇਂ ਢਾਂਚਾ ਬਣਾਇਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਕੰਮ ਦੇ ਸ਼ੁਰੂਆਤੀ ਪੜਾਵਾਂ ਵਿੱਚ, ਜਿਸ ਬਾਰੇ ਮੈਂ ਹੁਣ ਗੱਲ ਕਰ ਰਿਹਾ ਹਾਂ, ਕਿਸੇ ਨੂੰ ਵੀ ਇਹਨਾਂ ਨਿਯਮਾਂ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਜੇਕਰ ਕੋਈ ਵਿਅਕਤੀ ਆਪਣੇ ਹੱਥਾਂ ਵਿੱਚ ਮਾਰਕਰ ਵਾਲਾ ਬੋਰਡ 'ਤੇ ਕੰਪਨੀ ਦੀ ਅਸਲ ਸਥਿਤੀ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਹ ਸਥਿਤੀ ਨੂੰ ਸਮਝਣ ਦਾ ਸਭ ਤੋਂ ਵਧੀਆ ਤਰੀਕਾ ਹੈ। ਅਜਿਹੀ ਜਾਣਕਾਰੀ ਡਾਇਰੈਕਟਰਾਂ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਦੀ। ਇਸ ਸਮੇਂ, ਵਿਅਕਤੀ ਨੂੰ ਵਿਘਨ ਪਾਉਣਾ ਅਤੇ ਇਹ ਕਹਿਣਾ ਕਿ ਉਸਨੇ ਕਿਸੇ ਕਿਸਮ ਦਾ ਤੀਰ ਗਲਤ ਤਰੀਕੇ ਨਾਲ ਕੱਢਿਆ ਹੈ, ਇਹ ਮੂਰਖਤਾ ਹੈ. ਇਸ ਪੜਾਅ 'ਤੇ, ਸਧਾਰਨ ਨਿਯਮਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਬਿਹਤਰ ਹੈ, ਉਦਾਹਰਨ ਲਈ: ਬਹੁ-ਪੱਧਰੀ ਐਬਸਟਰੈਕਸ਼ਨ ਨੂੰ ਬਹੁ-ਰੰਗਦਾਰ ਮਾਰਕਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਬਣਾਇਆ ਜਾ ਸਕਦਾ ਹੈ।

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

(ਇਸ ਦ੍ਰਿਸ਼ਟਾਂਤ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ ਲਿੰਕ ਵੇਖੋ)

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

(ਇਸ ਦ੍ਰਿਸ਼ਟਾਂਤ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ ਲਿੰਕ ਵੇਖੋ)

ਅਤੇ ਫਿਰ ਅਸੀਂ ਦੂਜੇ ਵਿਭਾਗਾਂ ਦੇ ਲੋਕਾਂ ਨਾਲ ਗੱਲ ਕੀਤੀ ਅਤੇ ਇਹ ਪਤਾ ਲੱਗਾ ਕਿ ਲਗਭਗ 8 ਸਾਲ ਪਹਿਲਾਂ, ਸਾਫਟਵੇਅਰ ਡਿਵੈਲਪਰਾਂ ਨੇ ਸੁਰੱਖਿਆ ਕਰਮਚਾਰੀਆਂ ਨੂੰ ਨੌਕਰੀ ਤੋਂ ਕੱਢ ਦਿੱਤਾ ਕਿਉਂਕਿ ਉਹ ਕੰਮ ਨੂੰ ਹੌਲੀ ਕਰ ਰਹੇ ਸਨ। ਅਤੇ ਫਿਰ ਇਹ ਇੱਕ ਪਾਬੰਦੀ ਵਿੱਚ ਬਦਲ ਗਿਆ, ਜਿਸਨੂੰ ਮੰਨਿਆ ਗਿਆ ਸੀ. ਹਾਲਾਂਕਿ ਅਸਲ ਵਿੱਚ ਕੋਈ ਪਾਬੰਦੀ ਨਹੀਂ ਸੀ।

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

ਫਿਰ IT ਗਵਰਨੈਂਸ ਦਾ ਇੰਚਾਰਜ ਵਿਅਕਤੀ, ਜੋ ਚਾਰ ਘੰਟੇ ਤੋਂ ਚੁੱਪ ਸੀ, ਅਚਾਨਕ ਜਦੋਂ ਅਸੀਂ ਉਸ ਦੇ ਵਿਸ਼ੇ 'ਤੇ ਪਹੁੰਚ ਗਏ, ਤਾਂ ਉਸ ਨੇ ਬਹੁਤ ਦੇਰ ਤੱਕ ਸਾਡੇ 'ਤੇ ਕਬਜ਼ਾ ਕਰ ਲਿਆ। ਅੰਤ ਵਿੱਚ ਮੈਂ ਉਸਨੂੰ ਪੁੱਛਿਆ ਕਿ ਉਹ ਮੀਟਿੰਗ ਬਾਰੇ ਕੀ ਸੋਚਦਾ ਹੈ, ਅਤੇ ਮੈਂ ਉਸਦਾ ਜਵਾਬ ਕਦੇ ਨਹੀਂ ਭੁੱਲਾਂਗਾ। ਉਸਨੇ ਕਿਹਾ: "ਮੈਂ ਸੋਚਦਾ ਸੀ ਕਿ ਸਾਡੇ ਬੈਂਕ ਕੋਲ ਸੌਫਟਵੇਅਰ ਪ੍ਰਦਾਨ ਕਰਨ ਦੇ ਸਿਰਫ ਦੋ ਤਰੀਕੇ ਹਨ, ਪਰ ਹੁਣ ਮੈਨੂੰ ਪਤਾ ਹੈ ਕਿ ਉਹਨਾਂ ਵਿੱਚੋਂ ਪੰਜ ਹਨ, ਅਤੇ ਮੈਨੂੰ ਤਿੰਨ ਬਾਰੇ ਵੀ ਨਹੀਂ ਪਤਾ ਸੀ."

(ਇਸ ਦ੍ਰਿਸ਼ਟਾਂਤ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ ਲਿੰਕ ਵੇਖੋ)

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

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

ਇਸ ਲਈ, ਮੈਂ ਵਰਕਰਾਂ ਨੂੰ ਸਵਾਲ ਪੁੱਛਦਾ ਹਾਂ, ਉਹ ਤਿੰਨ ਰੰਗਾਂ (ਕਾਲਾ, ਲਾਲ ਅਤੇ ਨੀਲਾ) ਦੇ ਮਾਰਕਰਾਂ ਨਾਲ ਜਵਾਬ ਲਿਖਦੇ ਹਨ। ਮੈਂ ਆਰਕੀਟਾਈਪਾਂ ਲਈ ਉਹਨਾਂ ਦੇ ਜਵਾਬਾਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਦਾ ਹਾਂ. ਆਉ ਹੁਣ ਕ੍ਰਮ ਵਿੱਚ ਸਾਰੀਆਂ ਪੁਰਾਤੱਤਵ ਕਿਸਮਾਂ ਦੀ ਚਰਚਾ ਕਰੀਏ।

1. ਸਾਰੇ ਕੰਮ ਨੂੰ ਦ੍ਰਿਸ਼ਮਾਨ ਬਣਾਓ: ਕੰਮ ਨੂੰ ਦ੍ਰਿਸ਼ਮਾਨ ਬਣਾਓ

ਜ਼ਿਆਦਾਤਰ ਕੰਪਨੀਆਂ ਜਿਨ੍ਹਾਂ ਨਾਲ ਮੈਂ ਕੰਮ ਕਰਦਾ ਹਾਂ ਉਨ੍ਹਾਂ ਕੋਲ ਅਣਜਾਣ ਕੰਮ ਦੀ ਬਹੁਤ ਜ਼ਿਆਦਾ ਪ੍ਰਤੀਸ਼ਤਤਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਇਹ ਉਦੋਂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਇੱਕ ਕਰਮਚਾਰੀ ਦੂਜੇ ਕੋਲ ਆਉਂਦਾ ਹੈ ਅਤੇ ਸਿਰਫ਼ ਕੁਝ ਕਰਨ ਲਈ ਕਹਿੰਦਾ ਹੈ। ਵੱਡੀਆਂ ਸੰਸਥਾਵਾਂ ਵਿੱਚ, 60% ਗੈਰ-ਯੋਜਨਾਬੱਧ ਕੰਮ ਹੋ ਸਕਦਾ ਹੈ। ਅਤੇ 40% ਤੱਕ ਦਾ ਕੰਮ ਕਿਸੇ ਵੀ ਤਰੀਕੇ ਨਾਲ ਦਸਤਾਵੇਜ਼ੀ ਨਹੀਂ ਹੈ। ਜੇ ਇਹ ਬੋਇੰਗ ਹੁੰਦਾ, ਤਾਂ ਮੈਂ ਆਪਣੀ ਜ਼ਿੰਦਗੀ ਵਿਚ ਦੁਬਾਰਾ ਉਨ੍ਹਾਂ ਦੇ ਜਹਾਜ਼ ਵਿਚ ਨਹੀਂ ਚੜ੍ਹਦਾ। ਜੇਕਰ ਅੱਧੇ ਕੰਮ ਨੂੰ ਹੀ ਦਸਤਾਵੇਜ਼ੀ ਰੂਪ ਦਿੱਤਾ ਜਾਵੇ ਤਾਂ ਪਤਾ ਨਹੀਂ ਲੱਗਦਾ ਕਿ ਇਹ ਕੰਮ ਸਹੀ ਢੰਗ ਨਾਲ ਹੋ ਰਿਹਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਹੋਰ ਸਾਰੇ ਤਰੀਕੇ ਬੇਕਾਰ ਸਾਬਤ ਹੁੰਦੇ ਹਨ - ਕਿਸੇ ਵੀ ਚੀਜ਼ ਨੂੰ ਸਵੈਚਲਿਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਦਾ ਕੋਈ ਮਤਲਬ ਨਹੀਂ ਹੈ, ਕਿਉਂਕਿ ਜਾਣਿਆ-ਪਛਾਣਿਆ 50% ਕੰਮ ਦਾ ਸਭ ਤੋਂ ਇਕਸਾਰ ਅਤੇ ਸਪੱਸ਼ਟ ਹਿੱਸਾ ਹੋ ਸਕਦਾ ਹੈ, ਜਿਸਦਾ ਆਟੋਮੇਸ਼ਨ ਵਧੀਆ ਨਤੀਜੇ ਨਹੀਂ ਦੇਵੇਗਾ, ਅਤੇ ਸਭ ਤੋਂ ਭੈੜੇ. ਚੀਜ਼ਾਂ ਅਦਿੱਖ ਅੱਧ ਵਿੱਚ ਹਨ. ਦਸਤਾਵੇਜ਼ਾਂ ਦੀ ਅਣਹੋਂਦ ਵਿੱਚ, ਹਰ ਕਿਸਮ ਦੇ ਹੈਕ ਅਤੇ ਲੁਕੇ ਹੋਏ ਕੰਮ ਨੂੰ ਲੱਭਣਾ ਅਸੰਭਵ ਹੈ, ਨਾ ਕਿ ਰੁਕਾਵਟਾਂ ਨੂੰ ਲੱਭਣਾ, ਉਹ "ਬ੍ਰੈਂਟਸ" ਜਿਨ੍ਹਾਂ ਬਾਰੇ ਮੈਂ ਪਹਿਲਾਂ ਹੀ ਗੱਲ ਕੀਤੀ ਹੈ। Dominica DeGrandis ਦੁਆਰਾ ਇੱਕ ਸ਼ਾਨਦਾਰ ਕਿਤਾਬ ਹੈ "ਕੰਮ ਨੂੰ ਦ੍ਰਿਸ਼ਮਾਨ ਬਣਾਉਣਾ". ਉਹ ਪ੍ਰਗਟ ਕਰਦੀ ਹੈ ਪੰਜ ਵੱਖ-ਵੱਖ "ਸਮਾਂ ਲੀਕ" (ਸਮੇਂ ਦੇ ਚੋਰ):

• ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਬਹੁਤ ਜ਼ਿਆਦਾ ਕੰਮ (WIP)
• ਅਗਿਆਤ ਨਿਰਭਰਤਾ
• ਗੈਰ ਯੋਜਨਾਬੱਧ ਕੰਮ
• ਵਿਰੋਧੀ ਤਰਜੀਹਾਂ
• ਅਣਗਹਿਲੀ ਵਾਲਾ ਕੰਮ

ਇਹ ਬਹੁਤ ਕੀਮਤੀ ਵਿਸ਼ਲੇਸ਼ਣ ਹੈ ਅਤੇ ਕਿਤਾਬ ਬਹੁਤ ਵਧੀਆ ਹੈ, ਪਰ ਇਹ ਸਾਰੀ ਸਲਾਹ ਬੇਕਾਰ ਹੈ ਜੇਕਰ ਸਿਰਫ 50% ਡੇਟਾ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ. ਡੋਮਿਨਿਕਾ ਦੁਆਰਾ ਪ੍ਰਸਤਾਵਿਤ ਤਰੀਕਿਆਂ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ ਜੇਕਰ 90% ਤੋਂ ਵੱਧ ਦੀ ਸ਼ੁੱਧਤਾ ਪ੍ਰਾਪਤ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਮੈਂ ਉਹਨਾਂ ਸਥਿਤੀਆਂ ਬਾਰੇ ਗੱਲ ਕਰ ਰਿਹਾ ਹਾਂ ਜਿੱਥੇ ਇੱਕ ਬੌਸ ਇੱਕ ਮਾਤਹਿਤ ਨੂੰ 15-ਮਿੰਟ ਦਾ ਕੰਮ ਦਿੰਦਾ ਹੈ, ਪਰ ਇਸ ਵਿੱਚ ਉਸਨੂੰ ਤਿੰਨ ਦਿਨ ਲੱਗਦੇ ਹਨ; ਪਰ ਬੌਸ ਅਸਲ ਵਿੱਚ ਇਹ ਨਹੀਂ ਜਾਣਦਾ ਕਿ ਇਹ ਅਧੀਨ ਚਾਰ ਜਾਂ ਪੰਜ ਹੋਰ ਲੋਕਾਂ 'ਤੇ ਨਿਰਭਰ ਹੈ।

ਫੀਨਿਕਸ ਪ੍ਰੋਜੈਕਟ ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਬਾਰੇ ਇੱਕ ਸ਼ਾਨਦਾਰ ਕਹਾਣੀ ਹੈ ਜੋ ਤਿੰਨ ਸਾਲ ਬਹੁਤ ਦੇਰ ਨਾਲ ਸੀ। ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਇੱਕ ਪਾਤਰ ਨੂੰ ਇਸ ਕਾਰਨ ਬਰਖਾਸਤਗੀ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ, ਅਤੇ ਉਹ ਇੱਕ ਹੋਰ ਪਾਤਰ ਨਾਲ ਮਿਲਦਾ ਹੈ ਜਿਸ ਨੂੰ ਇੱਕ ਕਿਸਮ ਦੇ ਸੁਕਰਾਤ ਵਜੋਂ ਪੇਸ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਉਹ ਇਹ ਪਤਾ ਲਗਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ ਕਿ ਅਸਲ ਵਿੱਚ ਕੀ ਗਲਤ ਹੋਇਆ ਹੈ। ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਕੰਪਨੀ ਦਾ ਇੱਕ ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਕ ਹੈ, ਜਿਸਦਾ ਨਾਮ ਬ੍ਰੈਂਟ ਹੈ, ਅਤੇ ਸਾਰਾ ਕੰਮ ਕਿਸੇ ਨਾ ਕਿਸੇ ਤਰੀਕੇ ਨਾਲ ਉਸ ਦੁਆਰਾ ਜਾਂਦਾ ਹੈ. ਮੀਟਿੰਗਾਂ ਵਿੱਚੋਂ ਇੱਕ ਵਿੱਚ, ਅਧੀਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨੂੰ ਪੁੱਛਿਆ ਜਾਂਦਾ ਹੈ: ਹਰੇਕ ਅੱਧੇ ਘੰਟੇ ਦੇ ਕੰਮ ਨੂੰ ਇੱਕ ਹਫ਼ਤਾ ਕਿਉਂ ਲੱਗਦਾ ਹੈ? ਇਸ ਦਾ ਜਵਾਬ ਕਿਊਇੰਗ ਥਿਊਰੀ ਅਤੇ ਲਿਟਲ ਦੇ ਕਾਨੂੰਨ ਦੀ ਇੱਕ ਬਹੁਤ ਹੀ ਸਰਲ ਪੇਸ਼ਕਾਰੀ ਹੈ, ਅਤੇ ਇਸ ਪ੍ਰਸਤੁਤੀ ਵਿੱਚ ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ 90% ਆਕੂਪੈਂਸੀ ਵਿੱਚ, ਕੰਮ ਦੇ ਹਰ ਘੰਟੇ ਵਿੱਚ 9 ਘੰਟੇ ਲੱਗਦੇ ਹਨ। ਹਰੇਕ ਕੰਮ ਨੂੰ ਸੱਤ ਹੋਰ ਲੋਕਾਂ ਨੂੰ ਭੇਜਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਜੋ ਉਹ ਘੰਟਾ 63 ਘੰਟੇ, 7 ਗੁਣਾ 9 ਬਣ ਜਾਵੇ। ਮੈਂ ਜੋ ਕਹਿ ਰਿਹਾ ਹਾਂ ਉਹ ਇਹ ਹੈ ਕਿ ਲਿਟਲਜ਼ ਲਾਅ ਜਾਂ ਕਿਸੇ ਵੀ ਗੁੰਝਲਦਾਰ ਕਤਾਰ ਸਿਧਾਂਤ ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ, ਤੁਹਾਡੇ ਕੋਲ ਘੱਟੋ-ਘੱਟ ਡਾਟਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

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

ਜਦੋਂ ਕੰਮ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਡੇਟਾ ਨੂੰ ਸਾਫ਼-ਸਾਫ਼ ਵਰਗੀਕ੍ਰਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ (ਜੋ ਕਿ ਡੋਮਿਨਿਕਾ ਫੋਟੋ ਵਿੱਚ ਕਰ ਰਹੀ ਹੈ), ਪੰਜ ਵਾਰ ਲੀਕ ਦਾ ਐਬਸਟਰੈਕਸ਼ਨ ਲਾਗੂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਆਟੋਮੇਸ਼ਨ ਨੂੰ ਲਾਗੂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

2. ਕੰਮ ਪ੍ਰਬੰਧਨ ਪ੍ਰਣਾਲੀਆਂ ਨੂੰ ਇਕੱਠਾ ਕਰੋ: ਕਾਰਜ ਪ੍ਰਬੰਧਨ

ਮੈਂ ਜਿਸ ਪੁਰਾਤੱਤਵ ਦੀ ਗੱਲ ਕਰ ਰਿਹਾ ਹਾਂ ਉਹ ਇੱਕ ਕਿਸਮ ਦੇ ਪਿਰਾਮਿਡ ਹਨ। ਜੇ ਪਹਿਲਾ ਸਹੀ ਢੰਗ ਨਾਲ ਕੀਤਾ ਗਿਆ ਹੈ, ਤਾਂ ਦੂਜਾ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਕਿਸਮ ਦਾ ਐਡ-ਆਨ ਹੈ. ਇਹਨਾਂ ਵਿੱਚੋਂ ਬਹੁਤ ਸਾਰੇ ਸਟਾਰਟਅੱਪਸ ਲਈ ਕੰਮ ਨਹੀਂ ਕਰਦੇ, ਉਹਨਾਂ ਨੂੰ Fortune 5000 ਵਰਗੀਆਂ ਵੱਡੀਆਂ ਕੰਪਨੀਆਂ ਲਈ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣ ਦੀ ਲੋੜ ਹੈ। ਪਿਛਲੀ ਕੰਪਨੀ ਜਿਸ ਲਈ ਮੈਂ ਕੰਮ ਕੀਤਾ ਸੀ, ਉਸ ਕੋਲ 10 ਟਿਕਟਿੰਗ ਸਿਸਟਮ ਸਨ। ਇੱਕ ਟੀਮ ਕੋਲ ਉਪਾਅ ਸੀ, ਦੂਜੀ ਨੇ ਆਪਣੀ ਕਿਸਮ ਦਾ ਸਿਸਟਮ ਲਿਖਿਆ, ਤੀਜੇ ਨੇ ਜੀਰਾ ਦੀ ਵਰਤੋਂ ਕੀਤੀ, ਅਤੇ ਕੁਝ ਨੇ ਈਮੇਲ ਨਾਲ ਕੀਤਾ। ਇਹੀ ਸਮੱਸਿਆ ਪੈਦਾ ਹੁੰਦੀ ਹੈ ਜੇਕਰ ਕੰਪਨੀ ਕੋਲ 30 ਵੱਖ-ਵੱਖ ਪਾਈਪਲਾਈਨਾਂ ਹਨ, ਪਰ ਮੇਰੇ ਕੋਲ ਅਜਿਹੇ ਸਾਰੇ ਮਾਮਲਿਆਂ 'ਤੇ ਚਰਚਾ ਕਰਨ ਦਾ ਸਮਾਂ ਨਹੀਂ ਹੈ।

ਮੈਂ ਲੋਕਾਂ ਨਾਲ ਬਿਲਕੁਲ ਚਰਚਾ ਕਰਦਾ ਹਾਂ ਕਿ ਟਿਕਟਾਂ ਕਿਵੇਂ ਬਣਾਈਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਉਹਨਾਂ ਦਾ ਅੱਗੇ ਕੀ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਕਿਵੇਂ ਰੋਕਿਆ ਜਾਂਦਾ ਹੈ। ਸਭ ਤੋਂ ਦਿਲਚਸਪ ਗੱਲ ਇਹ ਹੈ ਕਿ ਸਾਡੀਆਂ ਮੀਟਿੰਗਾਂ ਵਿਚ ਲੋਕ ਕਾਫ਼ੀ ਇਮਾਨਦਾਰੀ ਨਾਲ ਗੱਲ ਕਰਦੇ ਹਨ। ਮੈਂ ਪੁੱਛਿਆ ਕਿ ਕਿੰਨੇ ਲੋਕ ਟਿਕਟਾਂ 'ਤੇ "ਮਾਮੂਲੀ / ਕੋਈ ਪ੍ਰਭਾਵ ਨਹੀਂ" ਪਾਉਂਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਅਸਲ ਵਿੱਚ "ਮੁੱਖ ਪ੍ਰਭਾਵ" ਦਿੱਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਹ ਪਤਾ ਲੱਗਾ ਕਿ ਲਗਭਗ ਹਰ ਕੋਈ ਅਜਿਹਾ ਕਰਦਾ ਹੈ. ਮੈਂ ਨਿੰਦਿਆ ਵਿੱਚ ਸ਼ਾਮਲ ਨਹੀਂ ਹਾਂ ਅਤੇ ਲੋਕਾਂ ਦੀ ਪਛਾਣ ਨਾ ਕਰਨ ਲਈ ਹਰ ਸੰਭਵ ਤਰੀਕੇ ਨਾਲ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹਾਂ। ਜਦੋਂ ਉਹ ਇਮਾਨਦਾਰੀ ਨਾਲ ਮੇਰੇ ਲਈ ਕੁਝ ਕਬੂਲ ਕਰਦੇ ਹਨ, ਤਾਂ ਮੈਂ ਉਸ ਵਿਅਕਤੀ ਨੂੰ ਨਹੀਂ ਦਿੰਦਾ। ਪਰ ਜਦੋਂ ਲਗਭਗ ਹਰ ਕੋਈ ਸਿਸਟਮ ਨੂੰ ਬਾਈਪਾਸ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਸਾਰੀ ਸੁਰੱਖਿਆ ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ ਵਿੰਡੋ ਡਰੈਸਿੰਗ ਹੈ. ਇਸ ਲਈ, ਇਸ ਪ੍ਰਣਾਲੀ ਦੇ ਡੇਟਾ ਤੋਂ ਕੋਈ ਸਿੱਟਾ ਨਹੀਂ ਕੱਢਿਆ ਜਾ ਸਕਦਾ ਹੈ.

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

ਇਹ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਅਤੇ ਸੰਚਾਲਨ ਸਮੇਤ ਸਾਰੇ ਵਿਭਾਗਾਂ 'ਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਮਾਮਲਿਆਂ ਦੀ ਸਥਿਤੀ ਬਾਰੇ ਘੱਟੋ ਘੱਟ ਕੁਝ ਪ੍ਰਸ਼ੰਸਾਯੋਗ ਵਿਚਾਰ ਬਣਾਉਣਾ ਸੰਭਵ ਹੈ. ਇੱਕ ਵਾਰ ਜਦੋਂ ਇਹ ਪ੍ਰਕਿਰਿਆ ਸਥਾਪਤ ਹੋ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਇਹ ਅਚਾਨਕ ਪਛਾਣਨਾ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ ਕਿ ਹਰੇਕ ਐਪਲੀਕੇਸ਼ਨ ਲਈ ਕੌਣ ਜ਼ਿੰਮੇਵਾਰ ਹੈ। ਕਿਉਂਕਿ ਹੁਣ ਸਾਨੂੰ 50% ਨਹੀਂ, ਸਗੋਂ 98% ਨਵੀਆਂ ਸੇਵਾਵਾਂ ਮਿਲਦੀਆਂ ਹਨ। ਜੇ ਇਹ ਕੋਰ ਪ੍ਰਕਿਰਿਆ ਕੰਮ ਕਰਦੀ ਹੈ, ਤਾਂ ਪੂਰੇ ਸਿਸਟਮ ਵਿੱਚ ਸ਼ੁੱਧਤਾ ਵਿੱਚ ਸੁਧਾਰ ਹੁੰਦਾ ਹੈ।

ਸੇਵਾਵਾਂ ਪਾਈਪਲਾਈਨ

ਇਹ ਦੁਬਾਰਾ ਸਿਰਫ ਵੱਡੀਆਂ ਕਾਰਪੋਰੇਸ਼ਨਾਂ 'ਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ. ਜੇ ਤੁਸੀਂ ਇੱਕ ਨਵੇਂ ਖੇਤਰ ਵਿੱਚ ਇੱਕ ਨਵੀਂ ਕੰਪਨੀ ਹੋ, ਤਾਂ ਆਪਣੀਆਂ ਸਲੀਵਜ਼ ਨੂੰ ਰੋਲ ਕਰੋ ਅਤੇ ਆਪਣੇ ਟ੍ਰੈਵਿਸ ਸੀਆਈ ਜਾਂ ਸਰਕਲਸੀਆਈ ਨਾਲ ਕੰਮ ਕਰੋ। ਜਦੋਂ ਫਾਰਚਿਊਨ 5000 ਕੰਪਨੀਆਂ ਦੀ ਗੱਲ ਆਉਂਦੀ ਹੈ, ਤਾਂ ਇੱਕ ਕੇਸ ਜੋ ਉਸ ਬੈਂਕ ਵਿੱਚ ਵਾਪਰਿਆ ਜਿੱਥੇ ਮੈਂ ਕੰਮ ਕੀਤਾ ਸੀ। ਗੂਗਲ ਉਨ੍ਹਾਂ ਕੋਲ ਆਇਆ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਪੁਰਾਣੇ ਆਈਬੀਐਮ ਪ੍ਰਣਾਲੀਆਂ ਦੇ ਚਿੱਤਰ ਦਿਖਾਏ ਗਏ। ਗੂਗਲ ਦੇ ਮੁੰਡਿਆਂ ਨੇ ਉਲਝਣ ਵਿੱਚ ਪੁੱਛਿਆ - ਇਸਦਾ ਸਰੋਤ ਕੋਡ ਕਿੱਥੇ ਹੈ? ਪਰ ਇੱਥੇ ਕੋਈ ਸਰੋਤ ਕੋਡ ਨਹੀਂ ਹੈ, ਇੱਕ GUI ਵੀ ਨਹੀਂ ਹੈ। ਇਹ ਉਹ ਅਸਲੀਅਤ ਹੈ ਜਿਸ ਨਾਲ ਵੱਡੀਆਂ ਸੰਸਥਾਵਾਂ ਨੂੰ ਨਜਿੱਠਣਾ ਪੈਂਦਾ ਹੈ: ਇੱਕ ਪ੍ਰਾਚੀਨ ਮੇਨਫ੍ਰੇਮ 'ਤੇ 40 ਸਾਲ ਪੁਰਾਣੇ ਬੈਂਕ ਰਿਕਾਰਡ। ਮੇਰੇ ਗਾਹਕਾਂ ਵਿੱਚੋਂ ਇੱਕ ਸਰਕਟ ਬ੍ਰੇਕਰ ਪੈਟਰਨਾਂ ਦੇ ਨਾਲ ਕੁਬਰਨੇਟਸ ਕੰਟੇਨਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਨਾਲ ਹੀ ਕੈਓਸ ਮੌਨਕੀ, ਸਾਰੇ ਕੀਬੈਂਕ ਐਪਲੀਕੇਸ਼ਨ ਲਈ। ਪਰ ਇਹ ਕੰਟੇਨਰ ਆਖਰਕਾਰ ਇੱਕ COBOL ਐਪਲੀਕੇਸ਼ਨ ਨਾਲ ਜੁੜਦੇ ਹਨ।

ਗੂਗਲ ਦੇ ਮੁੰਡਿਆਂ ਨੂੰ ਪੂਰਾ ਭਰੋਸਾ ਸੀ ਕਿ ਉਹ ਮੇਰੇ ਗਾਹਕ ਦੀਆਂ ਸਾਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰ ਦੇਣਗੇ, ਅਤੇ ਫਿਰ ਉਹਨਾਂ ਨੇ ਸਵਾਲ ਪੁੱਛਣੇ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤੇ: IBM ਡੇਟਾਪਾਈਪ ਕੀ ਹੈ? ਉਹਨਾਂ ਨੂੰ ਕਿਹਾ ਜਾਂਦਾ ਹੈ: ਇਹ ਇੱਕ ਕਨੈਕਟਰ ਹੈ. ਇਹ ਕਿਸ ਨਾਲ ਜੁੜਦਾ ਹੈ? ਸਪਰੀ ਸਿਸਟਮ ਨੂੰ. ਅਤੇ ਉਹ ਕੀ ਹੈ? ਇਤਆਦਿ. ਪਹਿਲੀ ਨਜ਼ਰ 'ਤੇ ਇਹ ਜਾਪਦਾ ਹੈ: ਕਿਸ ਕਿਸਮ ਦੇ DevOps ਹੋ ਸਕਦੇ ਹਨ? ਪਰ ਅਸਲ ਵਿੱਚ, ਇਹ ਸੰਭਵ ਹੈ. ਇੱਥੇ ਡਿਲੀਵਰੀ ਸਿਸਟਮ ਹਨ ਜੋ ਤੁਹਾਨੂੰ ਵਰਕਫਲੋ ਨੂੰ ਡਿਲੀਵਰੀ ਟੀਮਾਂ ਨੂੰ ਸੌਂਪਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ।

3. ਥਿਊਰੀ ਆਫ਼ ਕੰਸਟ੍ਰੈਂਟਸ: ਥਿਊਰੀ ਆਫ਼ ਕੰਸਟ੍ਰੈਂਟਸ

ਆਉ ਤੀਜੇ ਪੁਰਾਤੱਤਵ ਵੱਲ ਵਧੀਏ: ਸੰਸਥਾਗਤ/"ਕਬਾਇਲੀ" ਗਿਆਨ। ਇੱਕ ਨਿਯਮ ਦੇ ਤੌਰ ਤੇ, ਕਿਸੇ ਵੀ ਸੰਸਥਾ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਲੋਕ ਹੁੰਦੇ ਹਨ ਜੋ ਸਭ ਕੁਝ ਜਾਣਦੇ ਹਨ ਅਤੇ ਹਰ ਚੀਜ਼ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਦੇ ਹਨ. ਇਹ ਉਹ ਹਨ ਜੋ ਸੰਗਠਨ ਵਿੱਚ ਸਭ ਤੋਂ ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਰਹੇ ਹਨ ਅਤੇ ਜੋ ਸਾਰੇ ਹੱਲ ਜਾਣਦੇ ਹਨ।

ਜਦੋਂ ਇਹ ਡਾਇਗ੍ਰਾਮ 'ਤੇ ਆਉਂਦਾ ਹੈ, ਤਾਂ ਮੈਂ ਖਾਸ ਤੌਰ 'ਤੇ ਅਜਿਹੇ ਲੋਕਾਂ ਨੂੰ ਮਾਰਕਰ ਨਾਲ ਘੇਰਦਾ ਹਾਂ: ਉਦਾਹਰਨ ਲਈ, ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਸਾਰੀਆਂ ਮੀਟਿੰਗਾਂ ਵਿੱਚ ਇੱਕ ਖਾਸ ਲੂ ਮੌਜੂਦ ਹੈ। ਅਤੇ ਇਹ ਮੇਰੇ ਲਈ ਸਪੱਸ਼ਟ ਹੈ: ਇਹ ਸਥਾਨਕ ਬ੍ਰੈਂਟ ਹੈ। ਜਦੋਂ CIO ਮੇਰੇ ਵਿੱਚੋਂ ਇੱਕ ਟੀ-ਸ਼ਰਟ ਅਤੇ ਸਨੀਕਰਸ ਅਤੇ ਸੂਟ ਵਿੱਚ IBM ਦੇ ਲੜਕੇ ਨੂੰ ਚੁਣਦਾ ਹੈ, ਤਾਂ ਮੈਂ ਇਸ ਲਈ ਚੁਣਿਆ ਜਾਂਦਾ ਹਾਂ ਕਿਉਂਕਿ ਮੈਂ ਨਿਰਦੇਸ਼ਕ ਨੂੰ ਉਹ ਗੱਲਾਂ ਦੱਸ ਸਕਦਾ ਹਾਂ ਜੋ ਦੂਜਾ ਵਿਅਕਤੀ ਨਹੀਂ ਦੱਸੇਗਾ ਅਤੇ ਇਹ ਕਿ ਡਾਇਰੈਕਟਰ ਸ਼ਾਇਦ ਸੁਣਨਾ ਪਸੰਦ ਨਾ ਕਰੇ। . ਮੈਂ ਉਨ੍ਹਾਂ ਨੂੰ ਦੱਸਦਾ ਹਾਂ ਕਿ ਉਨ੍ਹਾਂ ਦੀ ਕੰਪਨੀ ਵਿੱਚ ਰੁਕਾਵਟ ਫਰੈੱਡ ਨਾਮਕ ਕੋਈ ਹੈ ਅਤੇ ਕੋਈ ਲੂ ਨਾਮਕ ਹੈ। ਇਸ ਰੁਕਾਵਟ ਨੂੰ ਖੋਲ੍ਹਣ ਦੀ ਲੋੜ ਹੈ, ਉਨ੍ਹਾਂ ਦਾ ਗਿਆਨ ਉਨ੍ਹਾਂ ਤੋਂ ਕਿਸੇ ਨਾ ਕਿਸੇ ਤਰੀਕੇ ਨਾਲ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ।

ਇਸ ਕਿਸਮ ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ, ਮੈਂ, ਉਦਾਹਰਨ ਲਈ, ਸਲੈਕ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਸੁਝਾਅ ਦੇ ਸਕਦਾ ਹਾਂ। ਇੱਕ ਚੁਸਤ ਨਿਰਦੇਸ਼ਕ ਪੁੱਛੇਗਾ - ਕਿਉਂ? ਆਮ ਤੌਰ 'ਤੇ, ਅਜਿਹੇ ਮਾਮਲਿਆਂ ਵਿੱਚ, DevOps ਸਲਾਹਕਾਰ ਜਵਾਬ ਦਿੰਦੇ ਹਨ: ਕਿਉਂਕਿ ਹਰ ਕੋਈ ਇਹ ਕਰ ਰਿਹਾ ਹੈ. ਜੇ ਨਿਰਦੇਸ਼ਕ ਸੱਚਮੁੱਚ ਹੁਸ਼ਿਆਰ ਹੈ, ਤਾਂ ਉਹ ਕਹੇਗਾ: ਤਾਂ ਕੀ. ਅਤੇ ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਗੱਲਬਾਤ ਖਤਮ ਹੁੰਦੀ ਹੈ. ਅਤੇ ਇਸਦਾ ਮੇਰਾ ਜਵਾਬ ਹੈ: ਕਿਉਂਕਿ ਕੰਪਨੀ ਵਿੱਚ ਚਾਰ ਰੁਕਾਵਟਾਂ ਹਨ, ਫਰੇਡ, ਲੂ, ਸੂਜ਼ੀ ਅਤੇ ਜੇਨ. ਆਪਣੇ ਗਿਆਨ ਨੂੰ ਸੰਸਥਾਗਤ ਬਣਾਉਣ ਲਈ, ਕਿਸੇ ਨੂੰ ਪਹਿਲਾਂ ਸਲੈਕ ਨੂੰ ਪੇਸ਼ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਤੁਹਾਡੀਆਂ ਸਾਰੀਆਂ ਵਿਕੀ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬਕਵਾਸ ਹਨ ਕਿਉਂਕਿ ਕੋਈ ਵੀ ਉਨ੍ਹਾਂ ਦੀ ਹੋਂਦ ਬਾਰੇ ਨਹੀਂ ਜਾਣਦਾ। ਜੇ ਇੰਜੀਨੀਅਰਿੰਗ ਟੀਮ ਫਰੰਟ-ਐਂਡ ਅਤੇ ਬੈਕ-ਐਂਡ ਵਿਕਾਸ ਵਿੱਚ ਸ਼ਾਮਲ ਹੈ ਅਤੇ ਹਰ ਕਿਸੇ ਨੂੰ ਇਹ ਜਾਣਨ ਦੀ ਜ਼ਰੂਰਤ ਹੁੰਦੀ ਹੈ ਕਿ ਉਹ ਸਵਾਲਾਂ ਦੇ ਨਾਲ ਫਰੰਟ-ਐਂਡ ਵਿਕਾਸ ਟੀਮ ਜਾਂ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਟੀਮ ਨਾਲ ਸੰਪਰਕ ਕਰ ਸਕਦੇ ਹਨ। ਇਹ ਉਦੋਂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਲੂ ਜਾਂ ਫਰੇਡ ਕੋਲ ਵਿਕੀ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਣ ਦਾ ਸਮਾਂ ਹੋਵੇਗਾ। ਅਤੇ ਫਿਰ ਸਲੈਕ ਵਿੱਚ ਕੋਈ ਪੁੱਛ ਸਕਦਾ ਹੈ ਕਿ ਕਿਉਂ, ਕਹੋ, ਕਦਮ 5 ਕੰਮ ਨਹੀਂ ਕਰ ਰਿਹਾ ਹੈ। ਅਤੇ ਫਿਰ ਲੂ ਜਾਂ ਫਰੇਡ ਵਿਕੀ 'ਤੇ ਨਿਰਦੇਸ਼ਾਂ ਨੂੰ ਠੀਕ ਕਰਨਗੇ। ਜੇ ਤੁਸੀਂ ਇਸ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਸਥਾਪਿਤ ਕਰਦੇ ਹੋ, ਤਾਂ ਬਹੁਤ ਸਾਰੀਆਂ ਚੀਜ਼ਾਂ ਆਪਣੇ ਆਪ ਵਿੱਚ ਆ ਜਾਣਗੀਆਂ.

ਇਹ ਮੇਰਾ ਮੁੱਖ ਨੁਕਤਾ ਹੈ: ਕਿਸੇ ਵੀ ਉੱਚ ਤਕਨਾਲੋਜੀ ਦੀ ਸਿਫ਼ਾਰਸ਼ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਪਹਿਲਾਂ ਉਹਨਾਂ ਲਈ ਬੁਨਿਆਦ ਨੂੰ ਕ੍ਰਮ ਵਿੱਚ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਇਹ ਹੁਣੇ ਦੱਸੇ ਗਏ ਘੱਟ-ਤਕਨੀਕੀ ਹੱਲਾਂ ਨਾਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਉੱਚ ਤਕਨੀਕਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋ ਅਤੇ ਇਹ ਨਹੀਂ ਦੱਸਦੇ ਕਿ ਉਹਨਾਂ ਦੀ ਲੋੜ ਕਿਉਂ ਹੈ, ਤਾਂ, ਇੱਕ ਨਿਯਮ ਦੇ ਤੌਰ ਤੇ, ਇਹ ਚੰਗੀ ਤਰ੍ਹਾਂ ਖਤਮ ਨਹੀਂ ਹੁੰਦਾ. ਸਾਡੇ ਗਾਹਕਾਂ ਵਿੱਚੋਂ ਇੱਕ Azure ML ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਇੱਕ ਬਹੁਤ ਹੀ ਸਸਤਾ ਅਤੇ ਸਧਾਰਨ ਹੱਲ। ਉਨ੍ਹਾਂ ਦੇ ਲਗਭਗ 30% ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਸਵੈ-ਸਿਖਲਾਈ ਮਸ਼ੀਨ ਦੁਆਰਾ ਦਿੱਤੇ ਗਏ ਸਨ। ਅਤੇ ਇਹ ਗੱਲ ਓਪਰੇਟਰਾਂ ਦੁਆਰਾ ਲਿਖੀ ਗਈ ਸੀ ਜੋ ਡੇਟਾ ਵਿਗਿਆਨ, ਅੰਕੜੇ ਜਾਂ ਗਣਿਤ ਵਿੱਚ ਸ਼ਾਮਲ ਨਹੀਂ ਸਨ। ਇਹ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਅਜਿਹੇ ਹੱਲ ਦੀ ਲਾਗਤ ਬਹੁਤ ਘੱਟ ਹੈ.

4. ਸਹਿਯੋਗ ਹੈਕ: ਸਹਿਯੋਗ ਹੈਕ

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

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

5. ਕੋਚਿੰਗ ਕਾਟਾ

ਜਿਵੇਂ ਕਿ ਮੈਂ ਸ਼ੁਰੂ ਵਿੱਚ ਚੇਤਾਵਨੀ ਦਿੱਤੀ ਸੀ, ਮੈਂ ਅੱਜ ਇਸ ਬਾਰੇ ਗੱਲ ਨਹੀਂ ਕਰਾਂਗਾ। ਜੇ ਤੁਸੀਂ ਦਿਲਚਸਪੀ ਰੱਖਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਇੱਕ ਨਜ਼ਰ ਮਾਰ ਸਕਦੇ ਹੋ ਮੇਰੀਆਂ ਕੁਝ ਪੇਸ਼ਕਾਰੀਆਂ.

ਮਾਈਕ ਰੌਦਰ ਤੋਂ ਇਸ ਵਿਸ਼ੇ 'ਤੇ ਇੱਕ ਚੰਗੀ ਗੱਲਬਾਤ ਵੀ ਹੈ:

6. ਮਾਰਕਿਟ ਓਰੀਐਂਟੇਡ: ਬਜ਼ਾਰ-ਮੁਖੀ ਸੰਸਥਾ

ਇੱਥੇ ਵੱਖ-ਵੱਖ ਸਮੱਸਿਆਵਾਂ ਹਨ। ਉਦਾਹਰਨ ਲਈ, "I" ਲੋਕ, "T" ਲੋਕ ਅਤੇ "E" ਲੋਕ। "ਮੈਂ" ਲੋਕ ਉਹ ਹੁੰਦੇ ਹਨ ਜੋ ਸਿਰਫ ਇੱਕ ਕੰਮ ਕਰਦੇ ਹਨ। ਆਮ ਤੌਰ 'ਤੇ ਉਹ ਅਲੱਗ-ਥਲੱਗ ਵਿਭਾਗਾਂ ਵਾਲੀਆਂ ਸੰਸਥਾਵਾਂ ਵਿੱਚ ਮੌਜੂਦ ਹੁੰਦੇ ਹਨ। "ਟੀ" ਉਦੋਂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਕੋਈ ਵਿਅਕਤੀ ਇੱਕ ਚੀਜ਼ ਵਿੱਚ ਚੰਗਾ ਹੁੰਦਾ ਹੈ ਪਰ ਕੁਝ ਹੋਰ ਚੀਜ਼ਾਂ ਵਿੱਚ ਵੀ ਚੰਗਾ ਹੁੰਦਾ ਹੈ। "ਈ" ਜਾਂ ਇੱਥੋਂ ਤੱਕ ਕਿ "ਕੰਘੀ" ਉਦੋਂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਇੱਕ ਵਿਅਕਤੀ ਕੋਲ ਬਹੁਤ ਸਾਰੇ ਹੁਨਰ ਹੁੰਦੇ ਹਨ.

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

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

ਬਹੁਤ ਸਾਰੇ ਲੋਕ ਇਸ ਢਾਂਚੇ ਨੂੰ ਵੱਖ-ਵੱਖ ਤਰੀਕਿਆਂ ਨਾਲ ਬਿਆਨ ਕਰਦੇ ਹਨ, ਮੈਨੂੰ ਸ਼ਬਦਾਵਲੀ ਪਸੰਦ ਹੈ ਟੀਮਾਂ ਬਣਾਓ/ਚਲਾਓ, ਐਮਾਜ਼ਾਨ 'ਤੇ ਉਹ ਇਸਨੂੰ ਕਹਿੰਦੇ ਹਨ ਦੋ ਪੀਜ਼ਾ ਟੀਮਾਂ. ਇਸ ਢਾਂਚੇ ਵਿੱਚ, ਸਾਰੇ ਕਿਸਮ ਦੇ “I” ਲੋਕਾਂ ਨੂੰ ਇੱਕ ਸੇਵਾ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਸਮੂਹ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਹੌਲੀ-ਹੌਲੀ ਉਹ “T” ਟਾਈਪ ਕਰਨ ਦੇ ਨੇੜੇ ਹੋ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਜੇਕਰ ਸਹੀ ਪ੍ਰਬੰਧਨ ਮੌਜੂਦ ਹੈ, ਤਾਂ ਉਹ “E” ਵੀ ਬਣ ਸਕਦੇ ਹਨ। ਇੱਥੇ ਪਹਿਲੀ ਵਿਰੋਧੀ ਦਲੀਲ ਇਹ ਹੈ ਕਿ ਅਜਿਹੀ ਬਣਤਰ ਵਿੱਚ ਬੇਲੋੜੇ ਤੱਤ ਹੁੰਦੇ ਹਨ। ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਟੈਸਟਰਾਂ ਦਾ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਵਿਭਾਗ ਹੋ ਸਕਦਾ ਹੈ ਤਾਂ ਤੁਹਾਨੂੰ ਹਰੇਕ ਵਿਭਾਗ ਵਿੱਚ ਇੱਕ ਟੈਸਟਰ ਦੀ ਲੋੜ ਕਿਉਂ ਹੈ? ਜਿਸਦਾ ਮੈਂ ਜਵਾਬ ਦਿੰਦਾ ਹਾਂ: ਇਸ ਕੇਸ ਵਿੱਚ ਵਾਧੂ ਲਾਗਤਾਂ ਭਵਿੱਖ ਵਿੱਚ "E" ਕਿਸਮ ਬਣਨ ਲਈ ਸਮੁੱਚੀ ਸੰਸਥਾ ਲਈ ਕੀਮਤ ਹਨ। ਇਸ ਢਾਂਚੇ ਵਿੱਚ, ਟੈਸਟਰ ਹੌਲੀ-ਹੌਲੀ ਨੈੱਟਵਰਕ, ਆਰਕੀਟੈਕਚਰ, ਡਿਜ਼ਾਈਨ ਆਦਿ ਬਾਰੇ ਸਿੱਖਦਾ ਹੈ। ਨਤੀਜੇ ਵਜੋਂ, ਸੰਸਥਾ ਵਿੱਚ ਹਰ ਭਾਗੀਦਾਰ ਨੂੰ ਸੰਸਥਾ ਵਿੱਚ ਵਾਪਰਨ ਵਾਲੀ ਹਰ ਚੀਜ਼ ਬਾਰੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਪਤਾ ਹੁੰਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਜਾਣਨਾ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਇਹ ਸਕੀਮ ਉਦਯੋਗ ਵਿੱਚ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਹੈ, ਤਾਂ ਪੜ੍ਹੋ ਮਾਈਕ ਰੋਦਰ, ਟੋਇਟਾ ਕਾਟਾ.

7. ਸ਼ਿਫਟ-ਖੱਬੇ ਆਡੀਟਰ: ਚੱਕਰ ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ ਆਡਿਟ। ਡਿਸਪਲੇ 'ਤੇ ਸੁਰੱਖਿਆ ਨਿਯਮਾਂ ਦੀ ਪਾਲਣਾ

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

ਬੇਸ਼ੱਕ, ਇਹ ਪਹੁੰਚ ਕੰਮ ਨਹੀਂ ਕਰਦੀ. ਮੈਨੂੰ ਅਜਿਹੀਆਂ ਚੀਜ਼ਾਂ ਤੋਂ ਛੁਟਕਾਰਾ ਪਾਉਣਾ ਪਵੇਗਾ ਕਿਉਂਕਿ ਇਹ ਲੋਕ ਸਿਸਟਮ ਦੀ ਰੱਖਿਆ ਨਹੀਂ ਕਰ ਰਹੇ ਹਨ। ਫੈਸਲਾ ਟੀਮ ਨੂੰ ਖੁਦ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ ਟੀਮ ਨੂੰ ਇਸਦੇ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ. ਨਹੀਂ ਤਾਂ, ਇੱਕ ਵਿਰੋਧਾਭਾਸੀ ਸਥਿਤੀ ਪੈਦਾ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਇੱਕ ਮੈਨੇਜਰ ਜਿਸ ਨੇ ਆਪਣੀ ਜ਼ਿੰਦਗੀ ਵਿੱਚ ਕਦੇ ਕੋਡ ਨਹੀਂ ਲਿਖਿਆ, ਪ੍ਰੋਗਰਾਮਰ ਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਕੋਡ ਲਿਖਣ ਵਿੱਚ ਕਿੰਨਾ ਸਮਾਂ ਲੈਣਾ ਚਾਹੀਦਾ ਹੈ। ਇੱਕ ਕੰਪਨੀ ਜਿਸ ਨਾਲ ਮੈਂ ਕੰਮ ਕੀਤਾ ਸੀ, ਵਿੱਚ 7 ​​ਵੱਖ-ਵੱਖ ਬੋਰਡ ਸਨ ਜੋ ਹਰ ਬਦਲਾਅ ਦੀ ਸਮੀਖਿਆ ਕਰਦੇ ਸਨ, ਜਿਸ ਵਿੱਚ ਇੱਕ ਆਰਕੀਟੈਕਚਰ ਬੋਰਡ, ਇੱਕ ਉਤਪਾਦ ਬੋਰਡ ਆਦਿ ਸ਼ਾਮਲ ਹਨ। ਇੱਕ ਲਾਜ਼ਮੀ ਇੰਤਜ਼ਾਰ ਦੀ ਮਿਆਦ ਵੀ ਸੀ, ਹਾਲਾਂਕਿ ਇੱਕ ਕਰਮਚਾਰੀ ਨੇ ਮੈਨੂੰ ਦੱਸਿਆ ਕਿ ਕੰਮ ਦੇ XNUMX ਸਾਲਾਂ ਵਿੱਚ, ਇਸ ਲਾਜ਼ਮੀ ਮਿਆਦ ਦੇ ਦੌਰਾਨ ਇਸ ਵਿਅਕਤੀ ਦੁਆਰਾ ਕੀਤੀ ਗਈ ਤਬਦੀਲੀ ਨੂੰ ਕਦੇ ਵੀ ਕਿਸੇ ਨੇ ਰੱਦ ਨਹੀਂ ਕੀਤਾ ਸੀ।

ਆਡੀਟਰਾਂ ਨੂੰ ਸਾਡੇ ਨਾਲ ਜੁੜਨ ਲਈ ਸੱਦਾ ਦੇਣ ਦੀ ਲੋੜ ਹੈ, ਨਾ ਕਿ ਉਹਨਾਂ ਤੋਂ ਛੁਟਕਾਰਾ ਪਾਉਣ ਲਈ. ਉਹਨਾਂ ਨੂੰ ਦੱਸੋ ਕਿ ਤੁਸੀਂ ਅਟੱਲ ਬਾਈਨਰੀ ਕੰਟੇਨਰ ਲਿਖਦੇ ਹੋ ਜੋ, ਜੇਕਰ ਉਹ ਸਾਰੇ ਟੈਸਟ ਪਾਸ ਕਰਦੇ ਹਨ, ਤਾਂ ਹਮੇਸ਼ਾ ਲਈ ਅਟੱਲ ਰਹਿੰਦੇ ਹਨ। ਉਹਨਾਂ ਨੂੰ ਦੱਸੋ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਕੋਡ ਵਜੋਂ ਪਾਈਪਲਾਈਨ ਹੈ ਅਤੇ ਦੱਸੋ ਕਿ ਇਸਦਾ ਕੀ ਅਰਥ ਹੈ। ਉਹਨਾਂ ਨੂੰ ਹੇਠ ਦਿੱਤੀ ਸਕੀਮ ਦਿਖਾਓ: ਇੱਕ ਕੰਟੇਨਰ ਵਿੱਚ ਇੱਕ ਅਟੱਲ ਰੀਡ-ਓਨਲੀ ਬਾਈਨਰੀ ਜੋ ਸਾਰੇ ਕਮਜ਼ੋਰੀ ਟੈਸਟਾਂ ਨੂੰ ਪਾਸ ਕਰਦੀ ਹੈ; ਅਤੇ ਫਿਰ ਨਾ ਸਿਰਫ ਕੋਈ ਇਸਨੂੰ ਛੂਹਦਾ ਹੈ, ਉਹ ਉਸ ਸਿਸਟਮ ਨੂੰ ਵੀ ਨਹੀਂ ਛੂਹਦਾ ਜੋ ਪਾਈਪਲਾਈਨ ਬਣਾਉਂਦਾ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਗਤੀਸ਼ੀਲ ਤੌਰ 'ਤੇ ਵੀ ਬਣਾਇਆ ਗਿਆ ਹੈ। ਮੇਰੇ ਕੋਲ ਗਾਹਕ ਹਨ, ਕੈਪੀਟਲ ਵਨ, ਜੋ ਬਲਾਕਚੈਨ ਵਰਗਾ ਕੁਝ ਬਣਾਉਣ ਲਈ ਵਾਲਟ ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹਨ। ਆਡੀਟਰ ਨੂੰ ਸ਼ੈੱਫ ਤੋਂ "ਪਕਵਾਨਾਂ" ਦਿਖਾਉਣ ਦੀ ਜ਼ਰੂਰਤ ਨਹੀਂ ਹੈ; ਇਹ ਬਲਾਕਚੈਨ ਦਿਖਾਉਣ ਲਈ ਕਾਫ਼ੀ ਹੈ, ਜਿਸ ਤੋਂ ਇਹ ਸਪੱਸ਼ਟ ਹੁੰਦਾ ਹੈ ਕਿ ਉਤਪਾਦਨ ਵਿੱਚ ਜੀਰਾ ਟਿਕਟ ਦਾ ਕੀ ਹੋਇਆ ਅਤੇ ਇਸਦੇ ਲਈ ਕੌਣ ਜ਼ਿੰਮੇਵਾਰ ਹੈ।

ਦੇ ਅਨੁਸਾਰ ਰਿਪੋਰਟ, ਸੋਨਾਟਾਈਪ ਦੁਆਰਾ 2018 ਵਿੱਚ ਬਣਾਇਆ ਗਿਆ, 2017 ਵਿੱਚ 87 ਬਿਲੀਅਨ OSS ਡਾਊਨਲੋਡ ਬੇਨਤੀਆਂ ਸਨ।

ਕਮਜ਼ੋਰੀਆਂ ਕਾਰਨ ਹੋਏ ਨੁਕਸਾਨ ਨਿਰੋਧਕ ਹਨ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਜੋ ਅੰਕੜੇ ਤੁਸੀਂ ਹੁਣ ਉੱਪਰ ਦੇਖਦੇ ਹੋ, ਉਨ੍ਹਾਂ ਵਿੱਚ ਮੌਕੇ ਦੀਆਂ ਲਾਗਤਾਂ ਸ਼ਾਮਲ ਨਹੀਂ ਹਨ। ਸੰਖੇਪ ਵਿੱਚ DevSecOps ਕੀ ਹੈ? ਮੈਂ ਫੌਰਨ ਦੱਸ ਦਈਏ ਕਿ ਇਹ ਨਾਮ ਕਿੰਨਾ ਕੁ ਸਫਲ ਹੈ, ਇਸ ਬਾਰੇ ਗੱਲ ਕਰਨ ਵਿੱਚ ਮੇਰੀ ਕੋਈ ਦਿਲਚਸਪੀ ਨਹੀਂ ਹੈ। ਬਿੰਦੂ ਇਹ ਹੈ ਕਿ ਕਿਉਂਕਿ DevOps ਬਹੁਤ ਸਫਲ ਰਿਹਾ ਹੈ, ਸਾਨੂੰ ਉਸ ਪਾਈਪਲਾਈਨ ਵਿੱਚ ਸੁਰੱਖਿਆ ਜੋੜਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ।

ਇਸ ਲੜੀ ਦੀ ਇੱਕ ਉਦਾਹਰਨ:


ਇਹ ਖਾਸ ਉਤਪਾਦਾਂ ਲਈ ਸਿਫ਼ਾਰਸ਼ ਨਹੀਂ ਹੈ, ਹਾਲਾਂਕਿ ਮੈਨੂੰ ਉਹ ਸਾਰੇ ਪਸੰਦ ਹਨ। ਮੈਂ ਉਹਨਾਂ ਨੂੰ ਇਹ ਦਰਸਾਉਣ ਲਈ ਇੱਕ ਉਦਾਹਰਨ ਦੇ ਤੌਰ ਤੇ ਹਵਾਲਾ ਦਿੱਤਾ ਕਿ DevOps, ਜੋ ਕਿ ਸ਼ੁਰੂ ਵਿੱਚ ਉਦਯੋਗ ਵਿੱਚ ਸੰਗਠਨਾਤਮਕ ਪੈਰਾਡਾਈਮ 'ਤੇ ਅਧਾਰਤ ਸੀ, ਤੁਹਾਨੂੰ ਇੱਕ ਉਤਪਾਦ 'ਤੇ ਕੰਮ ਦੇ ਹਰ ਪੜਾਅ ਨੂੰ ਸਵੈਚਾਲਤ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ।

ਅਤੇ ਅਜਿਹਾ ਕੋਈ ਕਾਰਨ ਨਹੀਂ ਹੈ ਕਿ ਅਸੀਂ ਸੁਰੱਖਿਆ ਲਈ ਇੱਕੋ ਜਿਹੀ ਪਹੁੰਚ ਕਿਉਂ ਨਾ ਅਪਣਾ ਸਕੀਏ।

ਨਤੀਜਾ

ਸਿੱਟੇ ਵਜੋਂ, ਮੈਂ DevSecOps ਲਈ ਕੁਝ ਸੁਝਾਅ ਦੇਵਾਂਗਾ. ਤੁਹਾਨੂੰ ਆਪਣੇ ਸਿਸਟਮ ਬਣਾਉਣ ਦੀ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਆਡੀਟਰਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਸਿੱਖਿਆ ਦੇਣ ਵਿੱਚ ਸਮਾਂ ਬਿਤਾਉਣ ਦੀ ਲੋੜ ਹੈ। ਤੁਹਾਨੂੰ ਆਡੀਟਰਾਂ ਨਾਲ ਸਹਿਯੋਗ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਅੱਗੇ, ਤੁਹਾਨੂੰ ਝੂਠੇ ਸਕਾਰਾਤਮਕ ਵਿਰੁੱਧ ਇੱਕ ਬਿਲਕੁਲ ਬੇਰਹਿਮ ਲੜਾਈ ਲੜਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ. ਇੱਥੋਂ ਤੱਕ ਕਿ ਸਭ ਤੋਂ ਮਹਿੰਗੇ ਕਮਜ਼ੋਰ ਸਕੈਨਿੰਗ ਟੂਲ ਦੇ ਨਾਲ, ਤੁਸੀਂ ਆਪਣੇ ਡਿਵੈਲਪਰਾਂ ਵਿੱਚ ਬਹੁਤ ਬੁਰੀਆਂ ਆਦਤਾਂ ਪੈਦਾ ਕਰ ਸਕਦੇ ਹੋ ਜੇਕਰ ਤੁਸੀਂ ਨਹੀਂ ਜਾਣਦੇ ਕਿ ਤੁਹਾਡਾ ਸਿਗਨਲ-ਟੂ-ਆਇਸ ਅਨੁਪਾਤ ਕੀ ਹੈ। ਡਿਵੈਲਪਰ ਇਵੈਂਟਸ ਨਾਲ ਹਾਵੀ ਹੋ ਜਾਣਗੇ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਬਸ ਮਿਟਾ ਦੇਣਗੇ। ਜੇਕਰ ਤੁਸੀਂ Equifax ਕਹਾਣੀ ਬਾਰੇ ਸੁਣਿਆ ਹੈ, ਤਾਂ ਇਹ ਬਹੁਤ ਕੁਝ ਹੈ ਜੋ ਉੱਥੇ ਹੋਇਆ ਸੀ, ਜਿੱਥੇ ਸਭ ਤੋਂ ਵੱਧ ਚੇਤਾਵਨੀ ਪੱਧਰ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕੀਤਾ ਗਿਆ ਸੀ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਕਮਜ਼ੋਰੀਆਂ ਨੂੰ ਅਜਿਹੇ ਤਰੀਕੇ ਨਾਲ ਸਮਝਾਉਣ ਦੀ ਲੋੜ ਹੈ ਜੋ ਇਹ ਸਪੱਸ਼ਟ ਕਰੇ ਕਿ ਉਹ ਕਾਰੋਬਾਰ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਭਾਵਤ ਕਰਦੇ ਹਨ। ਉਦਾਹਰਨ ਲਈ, ਤੁਸੀਂ ਕਹਿ ਸਕਦੇ ਹੋ ਕਿ ਇਹ ਉਹੀ ਕਮਜ਼ੋਰੀ ਹੈ ਜਿਵੇਂ ਕਿ Equifax ਕਹਾਣੀ ਵਿੱਚ ਹੈ। ਸੁਰੱਖਿਆ ਕਮਜ਼ੋਰੀਆਂ ਨੂੰ ਦੂਜੇ ਸੌਫਟਵੇਅਰ ਮੁੱਦਿਆਂ ਵਾਂਗ ਹੀ ਸਮਝਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਯਾਨੀ, ਉਹਨਾਂ ਨੂੰ ਸਮੁੱਚੀ DevOps ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਤੁਹਾਨੂੰ ਜੀਰਾ, ਕਨਬਨ, ਆਦਿ ਰਾਹੀਂ ਉਹਨਾਂ ਨਾਲ ਕੰਮ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਇਹ ਨਹੀਂ ਸੋਚਣਾ ਚਾਹੀਦਾ ਕਿ ਕੋਈ ਹੋਰ ਅਜਿਹਾ ਕਰੇਗਾ - ਇਸਦੇ ਉਲਟ, ਹਰ ਕਿਸੇ ਨੂੰ ਇਹ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ. ਅੰਤ ਵਿੱਚ, ਤੁਹਾਨੂੰ ਲੋਕਾਂ ਨੂੰ ਸਿਖਲਾਈ ਦੇਣ ਲਈ ਊਰਜਾ ਖਰਚ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ.

ਉਪਯੋਗੀ ਲਿੰਕ

ਇੱਥੇ DevOops ਕਾਨਫਰੰਸ ਦੀਆਂ ਕੁਝ ਗੱਲਾਂ ਹਨ ਜੋ ਤੁਹਾਨੂੰ ਲਾਭਦਾਇਕ ਲੱਗ ਸਕਦੀਆਂ ਹਨ:

• ਸੇਰਗੇਈ ਬਰਡਨੀਕੋਵ, ਆਰਟਿਓਮ ਕਲਿਚਕਿਨ - ਸਫਲਤਾ ਦੀ ਕਹਾਣੀ, ਜਾਂ "ਦੇਵ+ਦੇਵਓਪਸ+ਓਪਸ" (видео, ਰਿਪੋਰਟ ਦੀ ਪ੍ਰਤੀਲਿਪੀ)
• ਬਾਰੂਚ ਸਡੋਗੁਰਸਕੀ, ਲਿਓਨਿਡ ਇਗੋਲਨਿਕ - ਇੱਕ ਪੈਮਾਨੇ 'ਤੇ DevOps: ਤਿੰਨ ਕੰਮਾਂ ਵਿੱਚ ਇੱਕ ਯੂਨਾਨੀ ਦੁਖਾਂਤ (видео, ਰਿਪੋਰਟ ਦੀ ਪ੍ਰਤੀਲਿਪੀ)
• ਅਲੈਗਜ਼ੈਂਡਰ ਟਿਟੋਵ, ਕਿਰਿਲ ਤੋਲਕਾਚੇਵ - DevOps, ਇੰਜੀਨੀਅਰ ਅਤੇ ਕਮਿਊਨਿਟੀ
• ਟਿਮੋਥੀ ਲਿਸਟਰ - ਅੱਖਰ, ਭਾਈਚਾਰਾ ਅਤੇ ਸੱਭਿਆਚਾਰ: ਖੁਸ਼ਹਾਲੀ ਲਈ ਮਹੱਤਵਪੂਰਨ ਕਾਰਕ

ਇਸ ਨੂੰ ਦੇਖੋ ਪ੍ਰੋਗਰਾਮ DevOops 2020 ਮਾਸਕੋ - ਉੱਥੇ ਬਹੁਤ ਸਾਰੀਆਂ ਦਿਲਚਸਪ ਚੀਜ਼ਾਂ ਵੀ ਹਨ।

ਸਰੋਤ: www.habr.com