ਤੁਸੀਂ ਆਰਕੀਟੈਕਟ (The Architect) ਹੋ।

ਪਛਾਣ

ਤੁਸੀਂ ਸਿਸਟਮ ਡਿਜ਼ਾਈਨ ਕਰਦੇ ਹੋ। ਸਿਰਫ਼ ਉਹ ਕੰਮ ਨਹੀਂ ਜੋ ਤੁਸੀਂ ਕਰਦੇ ਹੋ — ਬਲਕਿ ਉਹ ਤਰੀਕਾ ਜਿਸ ਨਾਲ ਕੰਮ ਹੁੰਦਾ ਹੈ। ਤੁਸੀਂ ਵਰਕਫਲੋ (workflow) ਬਾਰੇ ਸੋਚਦੇ ਹੋ, ਇਸ ਬਾਰੇ ਕਿ ਫੈਸਲੇ ਕਿਵੇਂ ਅੱਗੇ ਵਧਦੇ ਹਨ, ਕਿਹੜੀਆਂ ਭੂਮਿਕਾਵਾਂ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ ਅਤੇ ਹਰੇਕ ਭੂਮਿਕਾ ਦੀ ਕੀ ਜ਼ਿੰਮੇਵਾਰੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਕਿਸੇ ਸੰਸਥਾ, ਪ੍ਰੋਜੈਕਟ, ਜਾਂ ਟੀਮ ਨੂੰ ਦੇਖਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਉਸ ਢਾਂਚੇ ਨੂੰ ਦੇਖਦੇ ਹੋ ਜੋ ਗਤੀਵਿਧੀ (activity) ਪੈਦਾ ਕਰਦਾ ਹੈ — ਸਿਰਫ਼ ਗਤੀਵਿਧੀ ਨੂੰ ਨਹੀਂ। ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ, ਕਿਸੇ ਸਿਸਟਮ ਨੂੰ ਦੇਖਣ ਦੇ ਇੱਕ ਘੰਟੇ ਦੇ ਅੰਦਰ, ਦੱਸ ਸਕਦੇ ਹੋ ਕਿ ਰੁਕਾਵਟਾਂ (bottlenecks) ਕਿੱਥੇ ਹਨ ਅਤੇ ਬੁਨਿਆਦੀ ਬਣਤਰ (configuration) ਕੀ ਗਲਤ ਕਰ ਰਹੀ ਹੈ।

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

ਇਹ ਬੌਧਿਕ ਤੌਰ 'ਤੇ ਸੰਤੁਸ਼ਟੀਜਨਕ ਹੈ। ਇਹ ਇੱਕ ਖਾਸ ਤਰੀਕੇ ਨਾਲ ਖਤਰਨਾਕ ਵੀ ਹੈ ਜਿਸ ਬਾਰੇ ਵਿਧੀ (methodology) ਚੇਤਾਵਨੀ ਦਿੰਦੀ ਹੈ: ਢਾਂਚਾਗਤ ਖੂਬਸੂਰਤੀ (structural elegance) ਕਾਰਜਸ਼ੀਲ ਅਸਲੀਅਤ ਦੀ ਥਾਂ ਲੈਣੀ ਸ਼ੁਰੂ ਕਰ ਸਕਦੀ ਹੈ। ਜੋ ਸਿਸਟਮ ਤੁਸੀਂ ਕਾਗਜ਼ 'ਤੇ, ਚਿੱਤਰਾਂ ਵਿੱਚ, ਧਿਆਨ ਨਾਲ ਲੜੀਬੱਧ ਕੀਤੇ ਫਲੋਚਾਰਟਸ (flowcharts) ਵਿੱਚ ਡਿਜ਼ਾਈਨ ਕਰਦੇ ਹੋ, ਉਹ ਹਮੇਸ਼ਾ ਇਸ ਗੱਲ ਦਾ ਸਾਹਮਣਾ ਨਹੀਂ ਕਰ ਪਾਉਂਦੇ ਕਿ ਲੋਕ ਅਸਲ ਵਿੱਚ ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ। ਡਿਜ਼ਾਈਨ ਕੀਤੇ ਸਿਸਟਮ ਅਤੇ ਕੰਮ ਕਰਨ ਦੀ ਅਸਲੀਅਤ ਦੇ ਵਿਚਕਾਰ ਦਾ ਫਰਕ (mismatch) ਤੁਹਾਡੇ ਲਈ ਲੋੜ ਤੋਂ ਵੱਧ ਸਮੇਂ ਤੱਕ ਅਦਿੱਖ ਰਹਿ ਸਕਦਾ ਹੈ, ਕਿਉਂਕਿ ਤੁਸੀਂ ਵਰਤੋਂ ਦੀ ਬਜਾਏ ਡਿਜ਼ਾਈਨ ਵੱਲ ਦੇਖ ਰਹੇ ਹੋ।

ਅੰਦਰੂਨੀ ਵਿਧੀ

ਵਿਧੀ ਆਰਕੀਟੈਕਟ ਨੂੰ ਢਾਂਚਾਗਤ ਤੌਰ 'ਤੇ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਸਥਿਤੀ 'ਤੇ ਰੱਖਦੀ ਹੈ — ਉਹ ਪੇਸ਼ੇਵਰ ਜਿਸਦੀ ਸਮਝ ਹੁਣ ਸਿਸਟਮ ਪੱਧਰ 'ਤੇ ਪ੍ਰਭਾਵ (leverage) ਪੈਦਾ ਕਰਦੀ ਹੈ। ਇਹ ਉਹ ਪਰਤ (layer) ਹੈ ਜਿੱਥੇ ਬਣਤਰ ਵਿੱਚ ਛੋਟੀਆਂ ਤਬਦੀਲੀਆਂ ਨਤੀਜਿਆਂ 'ਤੇ ਬਹੁਤ ਵੱਡੇ ਪ੍ਰਭਾਵ (outsized effects) ਪੈਦਾ ਕਰਦੀਆਂ ਹਨ। ਇੱਕ ਚੰਗੀ ਤਰ੍ਹਾਂ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਗਿਆ ਸਿਸਟਮ ਇਸਦੇ ਅੰਦਰ ਕੰਮ ਕਰਨ ਵਾਲੇ ਹਰੇਕ ਵਿਅਕਤੀ ਦੀ ਪ੍ਰਭਾਵਸ਼ੀਲਤਾ ਨੂੰ ਕਈ ਗੁਣਾ ਵਧਾ ਸਕਦਾ ਹੈ। ਇੱਕ ਮਾੜੀ ਤਰ੍ਹਾਂ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਗਿਆ ਸਿਸਟਮ ਯੋਗ ਲੋਕਾਂ ਦੀ ਮਿਹਨਤ ਨੂੰ ਅਣਮਿੱਥੇ ਸਮੇਂ ਲਈ ਬਰਬਾਦ (drain) ਕਰ ਸਕਦਾ ਹੈ।

ਇੱਥੇ ਸਭ ਤੋਂ ਵੱਧ ਸਰਗਰਮ ਪੱਖਪਾਤ (bias) ਤੁਹਾਡੀਆਂ ਆਪਣੀਆਂ ਰਚਨਾਵਾਂ 'ਤੇ ਲਾਗੂ ਹੋਣ ਵਾਲੀ ਕਾਰਜਸ਼ੀਲ ਸਥਿਰਤਾ (functional fixedness) ਹੈ — ਇੱਕ ਹੀ ਬਣਤਰ ਨੂੰ ਸਹੀ ਮੰਨ ਕੇ ਉਸ ਨਾਲ ਚਿੰਬੜੇ ਰਹਿਣ ਦੀ ਪ੍ਰਵਿਰਤੀ ਅਤੇ ਸੋਧਾਂ ਦਾ ਵਿਰੋਧ ਕਰਨਾ, ਭਾਵੇਂ ਸਿਸਟਮ ਰਗੜ (friction) ਪੈਦਾ ਕਰ ਰਿਹਾ ਹੋਵੇ। ਉਹ ਆਰਕੀਟੈਕਟ ਜਿਸਨੇ ਸਿਸਟਮ ਡਿਜ਼ਾਈਨ ਕਰਨ ਵਿੱਚ ਕਾਫ਼ੀ ਸਮਾਂ ਲਗਾਇਆ ਹੈ, ਕੋਲ ਡਿਜ਼ਾਈਨ ਦਾ ਬਚਾਅ ਕਰਨ ਦਾ ਇੱਕ ਸ਼ਕਤੀਸ਼ਾਲੀ ਮਨੋਵਿਗਿਆਨਕ ਕਾਰਨ ਹੁੰਦਾ ਹੈ। ਆਈਕੀਆ (IKEA) ਪ੍ਰਭਾਵ (ਆਪਣੇ ਦੁਆਰਾ ਬਣਾਈ ਚੀਜ਼ ਨੂੰ ਵੱਧ ਮਹੱਤਵ ਦੇਣਾ) ਅਤੇ ਮਿਹਨਤ ਦਾ ਸਪੱਸ਼ਟੀਕਰਨ (effort justification) (ਕਿਸੇ ਚੀਜ਼ ਨੂੰ ਬਣਾਉਣ ਲਈ ਤੁਸੀਂ ਜਿੰਨਾ ਵੱਧ ਦੁੱਖ ਝੱਲਿਆ ਹੈ, ਤੁਸੀਂ ਉਸਦੀ ਓਨੀ ਹੀ ਵੱਧ ਕਦਰ ਕਰਦੇ ਹੋ) ਮੁਸ਼ਕਲ ਨੂੰ ਵਧਾਉਂਦੇ ਹਨ। ਜੋ ਸਿਸਟਮ ਹੁਣ ਕੰਮ ਨਹੀਂ ਕਰਦਾ ਉਹ ਸਾਲਾਂ ਤੱਕ ਕਾਇਮ ਰਹਿ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਇਸਨੂੰ ਛੱਡਣਾ ਉਸ ਮਿਹਨਤ ਨੂੰ ਅਯੋਗ (invalidate) ਕਰ ਦੇਵੇਗਾ ਜਿਸਨੇ ਇਸਨੂੰ ਪੈਦਾ ਕੀਤਾ ਸੀ।

ਗਿਆਨ ਦਾ ਸਰਾਪ (curse of knowledge) ਆਪਣੇ ਸਿਸਟਮ-ਡਿਜ਼ਾਈਨ ਰੂਪ ਵਿੱਚ ਵੀ ਇੱਥੇ ਮੌਜੂਦ ਹੈ। ਤੁਸੀਂ ਹਰੇਕ ਚੋਣ ਨੂੰ ਸਹੀ ਠਹਿਰਾਉਣ ਵਾਲੇ ਸਿਧਾਂਤਾਂ ਨੂੰ ਸਮਝਦੇ ਹੋਏ ਸਿਸਟਮ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਹੈ। ਇਸਦੇ ਅੰਦਰ ਕੰਮ ਕਰਨ ਵਾਲੇ ਲੋਕਾਂ ਕੋਲ ਹਮੇਸ਼ਾ ਉਹ ਸਮਝ ਨਹੀਂ ਹੁੰਦੀ। ਉਹ ਤਰਕ (reasoning) ਤੋਂ ਬਿਨਾਂ ਢਾਂਚੇ ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹਨ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਵਿਸ਼ੇਸ਼ ਮਾਮਲੇ (edge cases) ਅਤੇ ਤਬਦੀਲੀਆਂ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਆਪਣੇ ਆਪ ਸੰਭਾਲ ਲੈਂਦੇ, ਉਹ ਰਗੜ ਦੇ ਬਿੰਦੂ ਬਣ ਜਾਂਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਸਹਿਣ ਲਈ ਸਿਸਟਮ ਡਿਜ਼ਾਈਨ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਸੀ। ਜੋ ਸਿਸਟਮ ਇਸਦੇ ਡਿਜ਼ਾਈਨਰ ਨੂੰ ਸਮਝ ਆਉਂਦਾ ਹੈ ਉਹ ਇਸਦੇ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਅਸਪੱਸ਼ਟ (opaque) ਹੋ ਸਕਦਾ ਹੈ — ਅਤੇ ਡਿਜ਼ਾਈਨਰ ਅਕਸਰ ਆਪਣੀ ਸਪੱਸ਼ਟਤਾ ਦੇ ਅੰਦਰੋਂ ਉਸ ਅਸਪੱਸ਼ਟਤਾ ਨੂੰ ਨਹੀਂ ਦੇਖ ਸਕਦਾ।

ਤਣਾਅ

ਜਿਸ ਤਣਾਅ ਵਿੱਚੋਂ ਤੁਸੀਂ ਗੁਜ਼ਰਦੇ ਹੋ ਉਹ ਢਾਂਚਾਗਤ ਖੂਬਸੂਰਤੀ (structural elegance) ਅਤੇ ਕਾਰਜਸ਼ੀਲ ਅਸਲੀਅਤ (operational reality) ਦੇ ਵਿਚਕਾਰ ਹੈ। ਖੂਬਸੂਰਤੀ ਕਹਿੰਦੀ ਹੈ: ਇਹ ਬਣਤਰ ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ ਇਕਸਾਰ ਹੈ, ਚੰਗੀ ਤਰ੍ਹਾਂ ਤਰਕਸ਼ੀਲ ਹੈ, ਅਤੇ ਸਿਧਾਂਤਕ ਤੌਰ 'ਤੇ ਸਰਬੋਤਮ (optimal) ਹੈ। ਅਸਲੀਅਤ ਕਹਿੰਦੀ ਹੈ: ਜਦੋਂ ਸਿਸਟਮ ਚੱਲਦਾ ਹੈ ਤਾਂ ਲੋਕ ਅਸਲ ਵਿੱਚ ਇਹ ਕਰਦੇ ਹਨ, ਅਤੇ ਉਹ ਹਮੇਸ਼ਾ ਉਸ ਤਰ੍ਹਾਂ ਦਾ ਵਿਵਹਾਰ ਨਹੀਂ ਕਰਦੇ ਜਿਸਦੀ ਡਿਜ਼ਾਈਨ ਨੇ ਉਮੀਦ ਕੀਤੀ ਸੀ। ਉਹ ਆਰਕੀਟੈਕਟ ਜੋ ਅਸਲੀਅਤ ਨਾਲੋਂ ਖੂਬਸੂਰਤੀ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦਾ ਹੈ, ਉਹ ਸੁੰਦਰ ਸਿਸਟਮ ਪੈਦਾ ਕਰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਕੋਈ ਨਹੀਂ ਵਰਤ ਸਕਦਾ। ਉਹ ਆਰਕੀਟੈਕਟ ਜੋ ਖੂਬਸੂਰਤੀ ਨਾਲੋਂ ਅਸਲੀਅਤ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦਾ ਹੈ, ਉਹ ਗੜਬੜ ਵਾਲੇ (messy) ਸਿਸਟਮ ਪੈਦਾ ਕਰਦਾ ਹੈ ਜੋ ਕੰਮ ਤਾਂ ਕਰਦੇ ਹਨ ਪਰ ਜਿਨ੍ਹਾਂ ਨੂੰ ਸਕੇਲ (scale) ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਜਾਂ ਅੱਗੇ ਨਹੀਂ ਭੇਜਿਆ ਜਾ ਸਕਦਾ।

ਵਿਚਕਾਰਲਾ ਰਸਤਾ ਉਹ ਹੈ ਜਿੱਥੇ ਪਰਿਪੱਕ (mature) ਸਿਸਟਮ ਡਿਜ਼ਾਈਨ ਰਹਿੰਦਾ ਹੈ — ਅਤੇ ਇਸ ਲਈ ਇਨ੍ਹਾਂ ਦੋਵਾਂ ਖਿੱਚਾਂ (pulls) ਵਿਚਕਾਰ ਲਗਾਤਾਰ ਸੁਧਾਰ (calibration) ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਵਿਧੀ (methodology) ਦਾ ਜਵਾਬ ਇੱਕ ਨੂੰ ਦੂਜੇ 'ਤੇ ਚੁਣਨਾ ਨਹੀਂ ਹੈ ਬਲਕਿ ਖੂਬਸੂਰਤੀ ਨੂੰ ਵਾਰ-ਵਾਰ ਅਸਲੀਅਤ ਦੀ ਪਰਖ ਵਿੱਚੋਂ ਲੰਘਾਉਣਾ ਹੈ, ਅਤੇ ਡਿਜ਼ਾਈਨ ਨੂੰ ਉੱਥੇ ਸੋਧਣਾ ਹੈ ਜਿੱਥੇ ਅਸਲੀਅਤ ਸਿਧਾਂਤ ਨੂੰ ਮੰਨਣ ਤੋਂ ਇਨਕਾਰ ਕਰਦੀ ਹੈ।

ਤੋਹਫ਼ਾ

ਤੁਹਾਡੇ ਕੋਲ ਜੋ ਹੈ, ਜੋ ਕੰਮ ਦੇ ਪੱਧਰ (task-level) ਦੀ ਐਗਜ਼ੀਕਿਊਸ਼ਨ 'ਤੇ ਫਸੇ ਪੇਸ਼ੇਵਰ ਕੋਲ ਨਹੀਂ ਹੈ, ਉਹ ਹੈ ਪ੍ਰਭਾਵ (leverage)। ਇੱਕ ਚੰਗੀ ਤਰ੍ਹਾਂ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਗਿਆ ਸਿਸਟਮ ਅਜਿਹਾ ਮੁੱਲ ਪੈਦਾ ਕਰਦਾ ਹੈ ਜੋ ਇਸਨੂੰ ਬਣਾਈ ਰੱਖਣ ਲਈ ਲੋੜੀਂਦੀ ਮਿਹਨਤ ਤੋਂ ਵੱਧ ਹੁੰਦਾ ਹੈ। ਜੋ ਘੰਟੇ ਤੁਸੀਂ ਸਿਸਟਮ ਡਿਜ਼ਾਈਨ 'ਤੇ ਬਿਤਾਉਂਦੇ ਹੋ ਉਹ ਸਿਸਟਮ ਦੇ ਜੀਵਨ ਦੌਰਾਨ ਕਈ ਗੁਣਾ ਵੱਧ ਘੰਟੇ ਵਾਪਸ ਕਰਦੇ ਹਨ — ਤੁਹਾਡੇ ਲਈ ਅਤੇ ਇਸਦੇ ਅੰਦਰ ਕੰਮ ਕਰਨ ਵਾਲੇ ਹਰੇਕ ਵਿਅਕਤੀ ਲਈ। ਇਹ ਡੈਲੀਗੇਸ਼ਨ (ਕੰਮ ਸੌਂਪਣ) ਦੀ ਪ੍ਰਗਤੀ ਦੇ ਪੱਧਰ 4 (Level 4) ਤੋਂ ਪਹਿਲਾਂ ਉਪਲਬਧ ਪ੍ਰਭਾਵ (leverage) ਦਾ ਸਭ ਤੋਂ ਉੱਚਾ ਰੂਪ ਹੈ, ਅਤੇ ਇਹ ਹੀ ਉਹ ਚੀਜ਼ ਹੈ ਜੋ ਸਕੇਲ (scale) ਹੋਣ ਵਾਲੀਆਂ ਸੰਸਥਾਵਾਂ ਨੂੰ ਸਿਰਫ਼ ਵਿਕਾਸ ਕਰਨ ਵਾਲੀਆਂ ਸੰਸਥਾਵਾਂ ਤੋਂ ਵੱਖ ਕਰਦੀ ਹੈ।

ਤੋਹਫ਼ਾ ਉਦੋਂ ਹੋਰ ਵੱਧਦਾ ਹੈ ਜਦੋਂ ਤੁਹਾਡੇ ਦੁਆਰਾ ਡਿਜ਼ਾਈਨ ਕੀਤੇ ਸਿਸਟਮ ਉਨ੍ਹਾਂ ਲੋਕਾਂ ਲਈ ਪੜ੍ਹਨਯੋਗ (legible) ਵੀ ਹੁੰਦੇ ਹਨ ਜੋ ਉਨ੍ਹਾਂ ਨੂੰ ਚਲਾਉਂਦੇ ਹਨ। ਪੜ੍ਹਨਯੋਗਤਾ ਤੋਂ ਬਿਨਾਂ ਖੂਬਸੂਰਤੀ ਚਲਾਕ ਚੀਜ਼ਾਂ (artifacts) ਪੈਦਾ ਕਰਦੀ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਕੋਈ ਵੀ ਅੱਗੇ ਨਹੀਂ ਵਧਾ ਸਕਦਾ। ਪੜ੍ਹਨਯੋਗਤਾ ਦੇ ਨਾਲ ਖੂਬਸੂਰਤੀ ਅਜਿਹਾ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਪੈਦਾ ਕਰਦੀ ਹੈ ਜਿਸ 'ਤੇ ਖੇਤਰ ਹੋਰ ਨਿਰਮਾਣ ਕਰ ਸਕਦਾ ਹੈ।

ਅਗਲਾ ਕਦਮ

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

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

ਇਹ ਤੁਹਾਡੇ ਮੁਫ਼ਤ ਮੁਲਾਂਕਣ ਵਿੱਚੋਂ ਇੱਕ ਕਦਮ ਹੈ। ਪੂਰਾ ਪਰਸਨਲ ਪ੍ਰੋਫਾਈਲ (Personal Profile) ਇਸ ਧਿਆਨ ਦੇ ਨਾਲ ਤੁਹਾਡੇ ਛੇ-ਖੇਤਰ ਸਰੋਤ ਨਕਸ਼ੇ ਨੂੰ ਉਜਾਗਰ ਕਰਦਾ ਹੈ ਕਿ ਕੀ ਤੁਹਾਡਾ ਸਿਸਟਮ-ਨਿਰਮਾਣ ਪ੍ਰਭਾਵ (leverage) ਪੈਦਾ ਕਰ ਰਿਹਾ ਹੈ ਜਾਂ ਮਿਹਨਤ ਨੂੰ ਖਪਤ ਕਰ ਰਿਹਾ ਹੈ, ਇਸ ਧਿਆਨ ਨਾਲ ਤੁਹਾਡੇ ਟਰੱਸਟ ਫਾਰਮੂਲਾ (Trust Formula) ਸਕੋਰ ਕਿ ਸੰਚਾਰ ਕਰਨ ਯੋਗ (transmissible) ਮਿਆਰ ਵੱਡੇ ਪੱਧਰ 'ਤੇ ਡੈਮੋਨਸਟ੍ਰੇਟਡ ਇਮਪੈਕਟ (Demonstrated Impact) ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ, ਆਰਕੀਟੈਕਟ ਪੜਾਅ ਲਈ ਪੱਖਪਾਤ-ਵਿਸ਼ੇਸ਼ ਚੇਤਾਵਨੀਆਂ (ਕਾਰਜਸ਼ੀਲ ਸਥਿਰਤਾ, ਆਈਕੀਆ (IKEA) ਪ੍ਰਭਾਵ, ਗਿਆਨ ਦਾ ਸਰਾਪ, ਇੱਥੇ-ਨਹੀਂ-ਬਣਾਇਆ (not-invented-here) ਸਿੰਡਰੋਮ), ਅਤੇ ਉਸ 90-ਦਿਨਾਂ ਦੀ ਲੜੀ ਨੂੰ ਉਜਾਗਰ ਕਰਦਾ ਹੈ ਜੋ ਇੱਕ ਸੰਚਾਰ ਪਰਖ ਨੂੰ ਤੁਹਾਡੇ ਦੁਆਰਾ ਬਣਾਏ ਗਏ ਸਿਸਟਮਾਂ ਦੀ ਯੋਜਨਾਬੱਧ ਤਰੀਕੇ ਨਾਲ ਪਰਖ (pressure-testing) ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀ ਹੈ। ਜੇਕਰ ਇੱਕ ਕਦਮ ਲਾਭਦਾਇਕ ਹੈ, ਤਾਂ ਪੂਰਾ ਨਿਦਾਨ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਅਸਲੀ ਕੰਮ ਹੁੰਦਾ ਹੈ।