06 ਅਗ 2025·8 ਮਿੰਟ
Dustin Moskovitz ਅਤੇ Asana: ਮੀਟਿੰਗਾਂ ਦੀ ਥਾਂ ਪ੍ਰਣਾਲੀਆਂ
ਕਿਵੇਂ Dustin Moskovitz ਅਤੇ Asana ਨੇ ਇਹ ਵਿਚਾਰ ਪ੍ਰਚਲਿਤ ਕੀਤਾ ਕਿ ਸਾਫ਼ ਪ੍ਰਣਾਲੀਆਂ — ਲਗਾਤਾਰ ਮੀਟਿੰਗਾਂ ਜਾਂ ਹੀਰੋਇਕ ਕਦਮਾਂ ਨਹੀਂ — ਟੀਮਾਂ ਨੂੰ ਸਮਨਵਯ, ਫੈਸਲੇ ਅਤੇ ਕੰਮ ਸ਼ਿਪ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੀਆਂ ਹਨ।
ਕਿਵੇਂ Dustin Moskovitz ਅਤੇ Asana ਨੇ ਇਹ ਵਿਚਾਰ ਪ੍ਰਚਲਿਤ ਕੀਤਾ ਕਿ ਸਾਫ਼ ਪ੍ਰਣਾਲੀਆਂ — ਲਗਾਤਾਰ ਮੀਟਿੰਗਾਂ ਜਾਂ ਹੀਰੋਇਕ ਕਦਮਾਂ ਨਹੀਂ — ਟੀਮਾਂ ਨੂੰ ਸਮਨਵਯ, ਫੈਸਲੇ ਅਤੇ ਕੰਮ ਸ਼ਿਪ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੀਆਂ ਹਨ।
ਤੁਸੀਂ ਕੈਲੰਡਰ ਖੋਲ੍ਹਦੇ ਹੋ ਅਤੇ ਉਹ ਪੂਰਾ ਭਰਿਆ ਹੋਇਆ ਹੈ: “ਹਫਤਾਵਾਰੀ ਸਥਿਤੀ,” “ਸਿੰਕ,” “ਚੈੱਕ-ਇਨ,” “ਅਲਾਇਨਮੈਂਟ,” ਅਤੇ ਕੁੱਝ “ਇੱਕ ਛੋਟੀ ਕਾਲ” ਜੋ ਕਦੇ ਛੋਟੀ ਨਹੀਂ ਰਹਿੰਦੀਆਂ। ਹਰ ਕੋਈ ਵਿਆਸਤ ਹੈ, ਫਿਰ ਵੀ ਉਹੀ ਸਵਾਲ ਮੁੜ-ਮੁੜ ਉੱਠਦੇ ਰਹਿੰਦੇ ਨੇ: ਕੌਣ ਕੀ ਕਰ ਰਿਹਾ ਹੈ? ਪਿਛਲੇ ਹਫ਼ਤੇ ਤੋਂ ਕੀ ਬਦਲਿਆ? ਅਸੀ ਟੀਮ ਤੇ ਹਾਂ—ਯਾ ਸਿਰਫ਼ ਚੱਲ ਰਹੇ ਹਾਂ?
ਜਦੋਂ ਕੰਮ ਦਿਖਾਈ ਨਹੀਂ ਦਿੰਦਾ, ਮੀਟਿੰਗਾਂ ਹੀ ਇਹ ਜਾਣਨ ਦਾ ਮੂਲ ਤਰੀਕਾ ਬਣ ਜਾਂਦੀਆਂ ਹਨ ਕਿ ਕੀ ਹੋ ਰਿਹਾ ਹੈ। ਜੇ ਅਪਡੇਟ ਲੋਕਾਂ ਦੇ ਸਿਰਾਂ ਵਿੱਚ, ਫੈਲੇ ਹੋਏ DMs, ਜਾਂ ਕਈ ਦਸਤਾਵੇਜ਼ਾਂ ਅਤੇ ਸਪ੍ਰੈਡਸ਼ੀਟਾਂ ਵਿੱਚ ਰਹਿੰਦੇ ਨੇ, ਤਾਂ ਸਾਂਝੀ ਸਮਝ ਬਣਾਉਣ ਲਈ ਸਭ ਨੂੰ ਇੱਕੋ ਸਮੇਂ ਇਕੱਠਾ ਕਰਨਾ ਹੀ ਇਕੋ ਭਰੋਸੇਯੋਗ ਤਰੀਕਾ ਰਹਿੰਦਾ ਹੈ। ਨਤੀਜਾ ਅਕਸਰ ਇਹ ਹੁੰਦਾ ਹੈ: ਪਿਛਲੀ ਮੀਟਿੰਗ ਨੇ ਜੋ ਫੈਸਲਾ ਕੀਤਾ ਉਹ ਸਪਸ਼ਟ ਕਰਨ ਲਈ ਹੋਰ ਮੀਟਿੰਗਾਂ ਨਿਰਧਾਰਤ।
ਜ਼ਿਆਦातर ਟੀਮ ਵਾਧੂ ਮੀਟਿੰਗਾਂ ਇਸ ਲਈ ਨਹੀਂ ਰੱਖਦੀਆਂ ਕਿ ਉਹਨਾਂ ਨੂੰ ਮੀਟਿੰਗਾਂ ਪਸੰਦ ਹਨ। ਉਹ ਇਨ੍ਹਾਂ ਨੂੰ ਇਸ ਲਈ ਰੱਖਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਅਣਸੁਨਿੱਧਤਾ ਮਹਿੰਗੀ ਪੈਂਦੀ ਹੈ। ਇੱਕ 30-ਮਿੰਟ ਦੀ ਸਿੰਕ ਕਦੇ ਕਦੇ ਖਤਰੇ ਘਟਾਉਣ ਦਾ ਸਭ ਤੋਂ ਸਸਤਾ ਤਰੀਕਾ ਲੱਗਦੀ ਹੈ—ਜਦ ਤੱਕ ਇਹ ਹਫ਼ਤੇ ਅਤੇ ਪ੍ਰੋਜੈਕਟਾਂ 'ਤੇ ਇਕੱਠੇ ਨ ਹੋ ਜਾਵੇ।
ਅਸਲ ਮੁੱਦਾ ਇਹ ਹੈ ਕਿ ਕੰਮ ਗੱਲਾਂ ਦੇ ਵਿਚਕਾਰ "ਦਿੱਖੋਂ ਅਲੇਖ" ਬਣ ਜਾਂਦਾ ਹੈ:
ਕੰਮ ਮੈਨੇਜਮੈਂਟ ਟੂਲਾਂ ਦੇ ਪਿੱਛੇ ਮੁੱਖ ਵਿਚਾਰ — ਅਤੇ ਜੋ ਸੋਚ ਅਕਸਰ Dustin Moskovitz ਨਾਲ ਜੁੜੀੋਂ ਹੈ — ਸਧਾਰਨ ਹੈ: ਮੁੜ-ਮੁੜ ਮੌਖਿਕ ਸੰਜੋਧਨ ਨੂੰ ਇੱਕ ਦਿੱਖਣਯੋਗ ਰਿਕਾਰਡ ਸਿਸਟਮ ਨਾਲ ਬਦਲੋ। ਸਥਿਤੀ ਨੂੰ ਪਤਾ ਕਰਨ ਲਈ ਮੀਟਿੰਗ ਕਰਨ ਦੀ ਬਜਾਏ, ਟੀਮ ਉਹ ਸਥਿਤੀ ਉਸ ਜਗ੍ਹਾ ਅਪਡੇਟ ਕਰੇ ਜਿੱਥੇ ਹਰ ਕੋਈ ਦੇਖ ਸਕੇ।
Asana ਇਸ ਦ੍ਰਿਸ਼ਟੀ ਦਾ ਇੱਕ ਜਾਣਿਆ-ਪਹਚਾਨਿਆ ਉਦਾਹਰਨ ਹੈ: ਇੱਕ ਸਾਂਝੀ ਥਾਂ ਜਿੱਥੇ ਟਾਸਕ, ਮਾਲਿਕ, ਮਿਆਦਾਂ ਅਤੇ ਅਪਡੇਟ ਟ੍ਰੈਕ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਟੂਲ ਖੁਦ ਕੋਈ ਜਾਦੂ ਨਹੀਂ, ਪਰ ਇਹ ਬਿੰਦੂ ਦਰਸਾਉਂਦਾ ਹੈ—ਜਦੋਂ ਕੰਮ ਦੇਖਣਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਸਿਰਫ਼ ਰਾਹਦਾਰੀ 'ਵਾਸਤੇ' ਨਹੀਂ, ਬਹੁਤ ਘੱਟ ਮੀਟਿੰਗਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ।
Dustin Moskovitz ਨੂੰ ਜ਼ਿਆਦਾਤਰ Facebook ਦੇ ਕੋ-ਫਾਉਂਡਰ ਅਤੇ ਸ਼ੁਰੂਆਤੀ ਇੰਜੀਨੀਅਰਿੰਗ ਲੀਡਰ ਵਜੋਂ ਜਾਣਿਆ ਜਾਂਦਾ ਹੈ, ਜਿਸ ਨੇ ਇਕ ਛੋਟੀ ਟੀਮ ਨੂੰ ਛੇਤੀ ਵਿਸ਼ਾਲ ਸੰਸਥਾ ਦੇ ਰੂਪ ਵਿੱਚ ਵੇਖਿਆ। Facebook ਛੱਡ ਕੇ, ਉਹ Justin Rosenstein ਨਾਲ ਮਿਲਕੇ Asana ਦੀ ਸਥਾਪਨਾ ਕੀਤੀ, ਜਿਸਦਾ ਧਿਆਨ ਉਸ ਖਾਸ ਸਮੱਸਿਆ 'ਤੇ ਸੀ ਜੋ ਟੀਮਾਂ ਵੱਧਣ 'ਤੇ ਆਉਂਦੀ ਹੈ: ਕੋਆਰਡੀਨੇਸ਼ਨ ਕੰਮ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਔਖਾ ਹੋ ਜਾਂਦਾ ਹੈ।
ਛੋਟੀ ਟੀਮ ਵਿੱਚ, ਲੋਕ ਯੋਜਨਾਵਾਂ ਨੂੰ ਆਪਣੇ ਸਿਰ ਵਿੱਚ ਰੱਖ ਸਕਦੇ ਹਨ, ਗੱਲ-ਬਾਤ ਹਾਲੀ ਵਿੱਚ ਕਰ ਲੈਂਦੇ ਹਨ ਅਤੇ ਛੋਟੀਆਂ ਮੀਟਿੰਗਾਂ ਨਾਲ ਰਾਹ ਤੈਅ ਕਰ ਲੈਂਦੇ ਹਨ। ਜਦੋਂ ਹੇਡਕਾਉਂਟ ਵਧਦਾ ਹੈ, ਇਹ ਤਰੀਕਾ ਕੰਮ ਨਹੀਂ ਕਰਦਾ। ਜਾਣਕਾਰੀ ਇਨਬਾਕਸਾਂ ਅਤੇ ਚੈਟ ਵਿੱਚ ਫਸ ਜਾਂਦੀ ਹੈ, ਫੈਸਲੇ ਉਹਨਾਂ ਕਾਲਾਂ ਵਿੱਚ ਲਏ ਜਾਂਦੇ ਹਨ ਜਿੱਥੇ ਹਿੱਸੇਦਾਰਾਂ ਦਾ ਅੱਧਾ ਗਰੁੱਪ ਗੈਰਹਾਜ਼ਰ ਹੁੰਦਾ ਹੈ, ਅਤੇ “ਕੌਣ ਕੀ ਕਰ ਰਿਹਾ ਹੈ” ਅਸਪਸ਼ਟ ਹੋ ਜਾਂਦਾ ਹੈ। ਨਤੀਜਾ ਪੇਸ਼ਗੀ: ਹੋਰ ਮੀਟਿੰਗਾਂ, ਹੋਰ ਫਾਲੋ-ਅਪ, ਅਤੇ ਹੋਰ ਮੁੜ-ਕੰਮ।
Moskovitz ਦਾ ਮੂਲ ਵਿਚਾਰ ਇਹ ਹੈ ਕਿ ਕੰਮ ਨੂੰ ਇੱਕ ਪ੍ਰਣਾਲੀ ਵਾਂਗ ਵਰਤਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ: ਵਿਜ਼ਿਬਲ ਵਚਨ, ਮਾਲਿਕ, ਟਾਈਮਲਾਈਨ ਅਤੇ ਫੈਸਲਾ ਨਿਯਮ, ਜੋ ਕੋਈ ਵੀ ਦੇਖ ਸਕੇ। ਹੀਰੋਇਕਸ 'ਤੇ ਨਿਰਭਰ ਕਰਨ ਦੀ ਬਜਾਏ — ਕਿਸੇ ਦਾ ਸਭ ਕੁਝ ਯਾਦ ਰਹਿਣਾ, ਸਭ ਨੂੰ ਧੱਕਾ ਦੇਣਾ, ਅਤੇ ਟੀਮਾਂ ਅੰਦਰ ਅਨੁਵਾਦ ਕਰਨਾ — ਪ੍ਰਣਾਲੀ ਸੰਦਰਭ ਨੂੰ ਬਹਾਲ ਰੱਖਦੀ ਹੈ।
ਇਸ ਲਿਖਤ ਦਾ ਉਦੇਸ਼ ਨਿੱਜੀ ਟਾਈਮਲਾਈਨ ਖੋਜਣਾ ਨਹੀਂ, ਬਲਕਿ ਉਹ ਸਰਲੀ ਸਿਧਾਂਤ ਅਤੇ ਨਮੂਨੇ ਕੱਢਣਾ ਹੈ ਜੋ ਬਹੁਤਾਂ ਲੋਕਾਂ ਲਈ Asana ਦੇ ਕੰਮ ਮੈਨੇਜਮੈਂਟ ਦੇ ਰਵੱਈਏ ਨਾਲ ਸਬੰਧਤ ਹਨ:
ਤੁਸੀਂ Asana, ਹੋਰ ਵਰਕਫਲੋ ਟੂਲ, ਜਾਂ ਇੱਕ ਹਲਕਾ-ਫੁਲਕਾ ਪ੍ਰਕਿਰਿਆ ਵਰਤੋ, ਅਧਾਰਭੂਤ ਸਵਾਲ ਇੱਕੋ ਹਨ: ਕੀ ਟੀਮ ਦਾ ਕਾਰਜ-ਚਲਾਉਣ ਵਾਲਾ ਸਿਸਟਮ ਤੇਜ਼ੀ ਨਾਲ ਸੰਗਠਨਕ ਸੰਜੋਧਨ ਘਟਾ ਸਕਦਾ ਹੈ?
ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਲਗਾਤਾਰ ਮੀਟਿੰਗਾਂ ਚੁਣਦੀਆਂ ਨਹੀਂ; ਉਹ ਉਥੇ ਆ ਜਾਂਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਕੰਮ ਅਣਪਛਾਣਿਆ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਕੋਆਰਡੀਨੇਸ਼ਨ ਲਾਈਵ ਰੈਸਕਿਊ ਰਾਹੀਂ ਹੁੰਦੀ ਹੈ।
ਹੀਰੋਇਕਸ ਉਹ ਆਖਰੀ-ਮਿੰਟ ਬਚਾਅ ਹਨ ਜੋ ਪ੍ਰੋਜੈਕਟਾਂ ਨੂੰ ਠੀਕ ਰੱਖਦੇ ਹਨ: ਕੋਈ ਮਹੱਤਵਪੂਰਨ ਵਿਸਥਾਰ ਯਾਦ ਰੱਖਦਾ ਹੈ, ਟੁੱਟੀ ਹੋਈ ਹੱਫਤ ਦਾ ਬੰਧਨ ਠੀਕ ਕਰਦਾ ਹੈ, ਜਾਂ ਕਿਸੇ ਨੇ ਦੇਰ ਤੱਕ ਰਹਿ ਕੇ “ਸਿਰਫ਼ ਇਹ ਕਰ ਲੈਣਾ” ਕੀਤਾ। ਗਿਆਨ ਲੋਕਾਂ ਦੇ ਸਿਰਾਂ ਵਿੱਚ ਰਿਹਾ, ਤਰੱਕੀ ਅਕਸਰ ਅੱਗ-ਨਿਭਾਉਣ ਦੁਆਰਾ ਚਲਦੀ ਹੈ, ਅਤੇ ਟੀਮ ਅਨੌਪਚਾਰਿਕ ਟਿੱਪਣੀਆਂ—DMs, ਰਸਤੇ-ਰਾਹ ਗੱਲਾਂ, ਛੋਟੀਆਂ ਕਾਲਾਂ—'ਤੇ ਨਿਰਭਰ ਹੋ ਜਾਂਦੀ ਹੈ।
ਹੀਰੋਇਕਸ ਉਤਪਾਦਕ ਲੱਗਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਦਿੱਸਣਯੋਗ ਮੋਸ਼ਨ ਬਣਾਉਂਦੇ ਹਨ। ਇਕ ਅੱਗ ਬੁਝ ਜਾਂਦੀ ਹੈ। ਇੱਕ ਮਿਆਦ ਪੂਰੀ ਹੁੰਦੀ ਹੈ। ਹੀਰੋ ਦੀ ਸ਼ਾਬਾਸ਼ ਮਿਲਦੀ ਹੈ। ਪਰ ਅਧਾਰਭੂਤ ਸਿਸਟਮ ਸੁਧਰਦਾ ਨਹੀਂ, ਇਸ ਲਈ ਓਹੇ ਆਗ ਦਿੱਤਾ ਹੋਇਆ ਮੁੜ ਆ ਜਾਂਦਾ—ਅਕਸਰ ਵੱਡਾ।
ਜਦੋਂ ਟੀਮ ਵੱਧਦੀ ਹੈ, ਤਾਂ ਹੀਰੋਇਕਸ ਇੱਕ ਟੈਕਸ ਬਣ ਜਾਂਦੇ ਹਨ:
ਅੰਤ ਵਿੱਚ, ਮੀਟਿੰਗਾਂ ਉਸ ਡਿੱਠੇ ਪ੍ਰਸੰਗ ਨੂੰ ਮੁੜ-ਤਿਆਰ ਕਰਨ ਲਈ ਡਿਫ਼ੌਲਟ ਤਰੀਕਾ ਬਣ ਜਾਂਦੀਆਂ ਜੋ ਪਹਿਲਾਂ ਹੀ ਮੁਜੂਦ ਹੋਣੀ ਚਾਹੀਦੀ ਸੀ।
ਸਿਸਟਮ ਰੈਸਕਿਊ ਦੀ ਥਾਂ ਦੁਹਰਾਅਯੋਗਤਾ ਲਿਆਉਂਦੇ ਹਨ। ਯਾਦ ਅਤੇ ਅਤਿ-ਤਤਕਾਲਤਾ 'ਤੇ ਨਿਰਭਰ ਕਰਨ ਦੀ ਬਜਾਏ, ਟੀਮ ਸਾਫ਼ ਵਰਕਫਲੋਜ਼ ਵਰਤਦੀ ਹੈ: ਪਰਿਭਾਸ਼ਿਤ ਕਦਮ, ਸਪਸ਼ਟ ਮਾਲਿਕਾਨਾ, ਅਤੇ ਸਾਂਝਾ ਸੰਦਰਭ ਜਿੱਥੇ ਕੰਮ ਰਹਿੰਦਾ ਹੈ। ਮਕਸਦ ਬਿਊਰੋਕ੍ਰੇਸੀ ਨਹੀਂ—ਇਹ ਤਰੱਕੀ ਨੂੰ ਲੰਬੇ ਸਮੇਂ ਲਈ ਸਹੀ ਰੱਖਣ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ।
ਇੱਕ ਸਿਸਟਮ-ਚਲਿਤ ਟੀਮ ਵਿੱਚ, ਤੁਹਾਡੇ ਕੋਲ ਬਿਨਾਂ ਕਾਲ ਦੇ ਬੁਨਿਆਦੀ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਹੋਣਗੇ: ਮੌਜੂਦਾ ਸਥਿਤੀ ਕੀ ਹੈ? ਕੀ ਰੁਕਿਆ ਹੋਇਆ ਹੈ? ਜ਼ਿੰਮੇਵਾਰ ਕੌਣ ਹੈ? ਅਗਲਾ ਕਦਮ ਕੀ ਹੈ?
ਆਮ ਨਿਸ਼ਾਨ ਸ਼ਾਮਿਲ ਹਨ:
ਹੀਰੋਇਕਸ ਤੋਂ ਸਿਸਟਮ ਵੱਲ ਜਾਣਾ ਹੀ ਉਹ ਚੀਜ਼ ਹੈ ਜੋ ਘੱਟ ਮੀਟਿੰਗਾਂ ਨੂੰ ਹਕੀਕਤੀ ਬਣਾਉਂਦਾ ਹੈ: ਜਦੋਂ ਜਾਣਕਾਰੀ ਅਤੇ ਜਵਾਬਦੇਹੀ ਵਰਕਫਲੋ ਵਿੱਚ ਬਿਲਟ ਹੁੰਦੇ ਹਨ, ਤਾਂ ਕੋਆਰਡੀਨੇਸ਼ਨ ਲਗਾਤਾਰ ਰੀਅਲ-ਟਾਈਮ ਸਿੰਕ 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਰਹਿੰਦੀ।
ਹਰ ਮੀਟਿੰਗ “ਖਰਾਬ” ਨਹੀਂ ਹੁੰਦੀ। ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਕੀ ਮੀਟਿੰਗ ਸਾਂਝੀ ਸਮਝ ਬਣਾਉਂਦੀ ਹੈ—ਜਾਂ ਕੇਵਲ ਉਸ ਕੰਮ ਦੀ ਕਮੀ ਨੂੰ ਪੂਰਕ ਕਰ ਰਹੀ ਹੈ ਜੋ ਦਿਖਾਈ ਨਹੀਂ ਦੇ ਰਿਹਾ।
ਸਥਿਤੀ ਅਪਡੇਟ ਅਕਸਰ ਦੋਸ਼ੀ ਹੁੰਦੇ ਹਨ: ਹਰ ਕੋਈ ਤਰੱਕੀ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਕਿਸੇ ਨੂੰ ਭਰੋਸਾ ਯੋਗ, ਸਾਂਝਾ ਨਜ਼ਾਰਾ ਨਹੀਂ ਹੈ ਕਿ ਕੌਣ ਕੀ ਕਰ ਰਿਹਾ।
ਫੈਸਲਾ ਮੀਟਿੰਗਾਂ ਅਕਸਰ ਹੁੰਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਸੰਦਰਭ ਚੈਟ, ਦਸਤਾਵੇਜ਼ ਅਤੇ ਲੋਕਾਂ ਦੇ ਸਿਰਾਂ ਵਿੱਚ ਫੈਲਾ ਹੋਇਆ ਹੁੰਦਾ ਹੈ।
ਯੋਜਨਾ ਸੈਸ਼ਨ ਕਦੀਂ ਵਧੀਆ ਹੁੰਦੇ ਹਨ, ਪਰ ਜਦੋਂ ਕੋਈ ਪ੍ਰਣਾਲੀ ਯੋਜਨਾ ਨੂੰ ਰੱਖੇ ਨਹੀਂ ਤਾਂ ਇਹ ਲਾਈਵ ਪਰਿਯੋਜਨਾ ਟਰੈਕਿੰਗ ਵਿੱਚ ਡਿੱਗ ਜਾਂਦੇ ਹਨ।
ਅਲਾਇਨਮੈਂਟ ਮੀਟਿੰਗਾਂ ਉਸ ਵੇਲੇ ਆਉਂਦੀਆਂ ਹਨ ਜਦੋਂ ਲਕਸ਼ਾਂ ਅਤੇ ਪ੍ਰਾਥਮਿਕਤਾਵਾਂ ਇਸ ਤਰ੍ਹਾਂ ਲਿਖੀਆਂ ਨਹੀਂ ਗਈਆਂ ਜਿਨ੍ਹਾਂ ਨੂੰ ਟੀਮ ਰੋਜ਼ਾਨਾ ਦੇਖ ਸਕੇ।
ਜੇ ਤੁਹਾਡੀ ਟੀਮ ਇੱਕ ਵਰਕ ਮੈਨੇਜਮੈਂਟ ਟੂਲ (ਜਿਵੇਂ Asana) ਨੂੰ ਸਚਾਈ ਦਾ ਸਰੋਤ ਵਜੋਂ ਵਰਤਦੀ ਹੈ, ਤਾਂ ਅਕਸਰ ਇਹ ਘਟਾਏ ਜਾ ਸਕਦੇ ਹਨ:
ਮਕਸਦ ਘੱਟ ਗੱਲ-ਬਾਤ ਨਹੀਂ, ਬਲਕਿ ਘੱਟ ਦੋਹਰਾਈ ਗਈ ਗੱਲ-ਬਾਤ ਹੈ।
ਕੁਝ ਵਿਸ਼ਿਆਂ ਨੂੰ ਲਾਈਵ ਹੀ ਸੰਭਾਲਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿਉਂਕਿ ਗਲਤ ਸਮਝਣ ਦੀ ਕੀਮਤ ਬਹੁਤ ਉੱਚੀ ਹੁੰਦੀ ਹੈ:
ਜੇ ਅਪਡੇਟ ਲਿਖਤੀ ਸੰਦਰਭ ਤੋਂ ਸਮਝ ਆ ਸਕਦਾ ਹੈ ਅਤੇ ਲੋਕ 24 ਘੰਟਿਆਂ ਵਿੱਚ ਜਵਾਬ ਦੇ ਸਕਦੇ ਹਨ ਤਾਂ ਐਸਿੰਕ ਚੁਣੋ।
ਜੇ ਤੁਹਾਨੂੰ ਰੀਅਲ-ਟਾਈਮ बहਸ ਦੀ ਲੋੜ ਹੈ, ਭਾਵਨਾਵਾਂ ਜ਼ਰੂਰੀ ਹਨ, ਜਾਂ ਤੁਹਾਨੂੰ ਅੱਜ ਇਕ ਸਪਸ਼ਟ ਫੈਸਲਾ ਅਤੇ ਮਾਲਿਕ ਲੈ ਕੇ ਨਿਕਲਣਾ ਹੈ ਤਾਂ ਮੀਟਿੰਗ ਚੁਣੋ।
ਮੀਟਿੰਗ-ਹਲਕੀ ਵਰਕਫਲੋ “ਕੋਈ ਮੀਟਿੰਗ ਨਹੀਂ” ਨਹੀਂ ਹੈ। ਇਹ ਇਕ ਐਸਾ ਇੰਟ੍ਰੀਐਂਟ ਹੈ ਜਿੱਥੇ ਜ਼ਿਆਦਾਤਰ ਕੋਆਰਡੀਨੇਸ਼ਨ ਕੰਮ ਦੇ ਅੰਦਰ ਹੁੰਦੀ ਹੈ—ਤਾਂ ਜੋ ਘੱਟ ਲੋਕ ਪੁੱਛਣ ਕਿ “ਅਸੀਂ ਇੱਥੇ ਕਿੱਥੇ ਹਾਂ?” ਜਾਂ “ਕੌਣ ਇਹ ਕਰ ਰਿਹਾ ਹੈ?”
Asana ਵਰਗੇ ਟੂਲਾਂ ਨੇ ਇਹ ਵਿਚਾਰ ਪ੍ਰਚਲਿਤ ਕੀਤਾ ਕਿ ਕੰਮ ਇੱਕ ਸਾਂਝਾ ਪ੍ਰਣਾਲੀ ਹੋਵੇ: ਹਰ ਵਚਨ ਦਿਖਾਈ ਦੇ, ਨਿਰਧਾਰਤ ਅਤੇ ਸਮੇਂ-ਬੱਧ ਹੋਵੇ।
ਕੰਮ ਦੀ ਇਕਾਈ ਐਸੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਜੋ ਕੋਈ ਇਕ ਵਿਅਕਤੀ ਮੁਕੰਮਲ ਕਰ ਸਕੇ। ਜੇ ਟਾਸਕ ਗੱਲ-ਬਾਤ ਜਿਹੇ ਲੱਗਦਾ ਹੈ ("Q1 ਕੈੰਪੇਨ 'ਤੇ ਚਰਚਾ ਕਰੋ"), ਤਾਂ ਇਸਨੂੰ ਨਤੀਜੇ ਵਿੱਚ ਬਦਲੋ ("Q1 ਕੈੰਪੇਨ ਬ੍ਰੀਫ ਡਰਾਫਟ ਕਰੋ ਅਤੇ ਸਮੀਖਿਆ ਲਈ ਸਾਂਝਾ ਕਰੋ")।
ਇੱਕ ਚੰਗਾ ਟਾਸਕ ਆਮ ਤੌਰ 'ਤੇ ਸ਼ਾਮਿਲ ਕਰਦਾ ਹੈ:
ਜਦ ਇਹ ਮੌਜੂਦ ਹੁੰਦੇ ਹਨ, ਤਾਂ ਸਥਿਤੀ ਸਵਾਲ ਘੱਟ ਹੋ ਜਾਂਦੇ ਹਨ ਕਿਉਂਕਿ ਸਿਸਟਮ ਪਹਿਲਾਂ ਹੀ ਉਨ੍ਹਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ।
ਇੱਕ ਟਾਸਕ ਉਸ ਵੇਲੇ “ਹੋ ਗਿਆ” ਨਹੀਂ ਹੁੰਦਾ ਜਦੋਂ ਕਿਸੇ ਨੇ ਕਿਹਾ ਕਿ ਥੋੜ੍ਹਾ ਕੰਮ ਕੀਤਾ। ਇਹ ਉਸ ਵੇਲੇ “ਹੋਇਆ” ਹੋਵੇਗਾ ਜਦੋਂ ਇਹ ਇੱਕ ਸਪਸ਼ਟ ਪਰਿਭਾਸ਼ਾ ਪੂਰੀ ਕਰ ਲਏ। ਉਹ ਪਰਿਭਾਸ਼ਾ ਹਲਕੀ ਹੋ ਸਕਦੀ ਹੈ, ਪਰ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।
ਸਧਾਰਨ ਐਕਸੈਪਟੈਂਸ ਕ੍ਰਾਈਟੇਰੀਆ ਵਰਤੋ ਜਿਵੇਂ:
ਇਸ ਨਾਲ ਕਲਾਸਿਕ ਲੂਪ ਰੋਕਿਆ ਜਾਂਦਾ ਹੈ: “ਮੈਨੂੰ ਲੱਗਾ ਤੁਸੀਂ ਮਤਲਬ…” ਅਤੇ ਫਿਰ ਮੁੜ-ਕੰਮ ਅਤੇ ਹੋਰ ਕਾਲ।
ਟੈਂਪਲੇਟਾਂ ਨਾਲ ਕੋਆਰਡੀਨੇਸ਼ਨ ਦਾ ਖਰਚ ਘਟਦਾ ਹੈ—ਪਰ ਸਿਰਫ਼ ਜੇ ਉਹ ਸਧਾਰਨ ਰਹਿਣ। ਕੁਝ ਦੋਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਪੈਟਰਨ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ:
ਟੈਂਪਲੇਟਾਂ ਨੂੰ ਲਚਕੀਲਾ ਰੱਖੋ: ਡਿਫੌਲਟ ਫੀਲਡ, ਸੁਝਾਅ-ਸਬਟਾਸਕ, ਅਤੇ “ਜੋ ਚਾਹੀਦਾ ਨਾ ਹੋਵੇ ਓਹ ਹਟਾਓ” ਮਨੋਭਾਵ।
ਜੇ ਟਾਸਕ ਚੈਟ, ਕੈਲੇਂਡਰ ਅਤੇ ਕਿਸੇ ਦੇ ਯਾਦ ਵਿੱਚ ਰਹਿੰਦੇ ਹਨ, ਤਾਂ ਮੀਟਿੰਗਾਂ ਵਧਦੀਆਂ ਹਨ। ਵਚਨਾਂ—ਟਾਸਕ, ਮਾਲਿਕ, ਤਰੀਖਾਂ, ਅਤੇ ਫੈਸਲੇ—ਨੂੰ ਕੇਂਦਰੀ ਬਣਾਉਣਾ ਇੱਕ ਸਾਂਝਾ ਸਚਾਈ ਸਰੋਤ ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਕਈ “ਕੁਇਕ ਸਿੰਕ” ਨੂੰ ਇਕ ਛੋਟੇ ਨਜ਼ਰ ਨਾਲ ਬਦਲਦਾ ਹੈ।
ਜੇ ਆਉਟ-ਓਫ-ਥ-ਬਾਕਸ ਟੂਲ ਤੁਹਾਡੇ ਵਰਕਫਲੋ ਨਾਲ ਨਹੀਂ ਮਿਲਦੇ, ਤਾਂ ਕਈ ਟੀਮ ਇਕ ਹਲਕੀ ਅੰਦਰੂਨੀ ਪ੍ਰਣਾਲੀ ਬਣਾਉਂਦੀਆਂ ਹਨ ਜੋ ਟੀਮ ਦੀ ਤਰੀਕੇ ਨਾਲ ਫਿੱਟ ਹੋਵੇ। ਉਦਾਹਰਨ ਵਜੋਂ, ਟੀਮ Koder.ai ਵਰਤਦੀ ਹੈ (ਇੱਕ vibe-coding ਪਲੇਟਫਾਰਮ) ਕਸਟਮ ਵੈੱਬ ਡੈਸ਼ਬੋਰਡ, ਇੰਟੇਕ ਫਾਰਮ ਅਤੇ ਸਥਿਤੀ ਪੋਰਟਲ ਚੈਟ ਰਾਹੀਂ ਬਣਾਉਣ ਲਈ—ਤਾਂ ਜੋ “ਰਿਕਾਰਡ ਦੀ ਪ੍ਰਣਾਲੀ” ਉਸ ਤਰੀਕੇ ਨੂੰ ਫਿੱਟ ਕਰੇ ਜਿਸ ਤਰ੍ਹਾਂ ਟੀਮ ਅਸਲ ਵਿੱਚ ਕੰਮ ਕਰਦੀ ਹੈ, ਅਤੇ ਫਿਰ ਵੀ ਮਾਲਿਕੀ ਅਤੇ ਅਪਡੇਟ ਦਿੱਖਣਯੋਗ ਰੱਖੇ।
ਸਥਿਤੀ ਮੀਟਿੰਗ ਅਕਸਰ ਇੱਕ ਹੀ ਕਾਰਨ ਨਾਲ ਮੌਜੂਦ ਹੁੰਦੀਆਂ ਹਨ: ਕਿਸੇ ਨੂੰ ਭਰੋਸਾ ਨਹੀਂ ਕਿ ਵਰਤਮਾਨ ਸਥਿਤੀ ਦਿਖਦੀ ਹੈ। ਇੱਕ ਐਸਿੰਕ ਕੈਡੈਂਸ ਇਸਨੂੰ ਠੀਕ ਕਰਦਾ ਹੈ ਕਿ ਅਪਡੇਟ ਪੇਸ਼ਗੋਈਯੋਗ, ਤੇਜ਼ੀ ਨਾਲ ਸਕੈਨ ਕਰਨਯੋਗ, ਅਤੇ ਅਸਲੀ ਟਾਸਕਾਂ ਨਾਲ ਜੁੜੇ ਹੋਣ—ਤਾਂ ਜੋ “ਮੀਟਿੰਗ” ਇੱਕ ਹਲਕੀ ਲਗਾਤਾਰ ਚੈੱਕ-ਇਨ ਬਣ ਜਾਏ।
ਹਫਤਾਵਾਰ ਯੋਜਨਾ (ਸੋਮ): ਹਰ ਟੀਮ ਮੈਂਬਰ ਹਫਤੇ ਲਈ ਇਕ ਛੋਟੀ ਯੋਜਨਾ ਪੋਸਟ ਕਰਦਾ ਹੈ, ਜੋ ਉਹਨਾਂ ਦੇ ਟਾਸਕਾਂ ਜਾਂ ਪ੍ਰੋਜੈਕਟਾਂ ਨਾਲ ਜੁੜੀ ਹੋਵੀ। ਛੋਟੀ ਰੱਖੋ: ਤੁਸੀਂ ਕੀ ਪੂਰਾ ਕਰੋਗੇ, ਕੀ ਸ਼ੁਰੂ ਕਰੋਗੇ, ਅਤੇ ਕੀ ਨਹੀਂ ਕਰ ਰਹੇ।
ਪੱਧਰ ਮੱਧ (ਬੁੱਧ/ਵੀਰ): ਇੱਕ ਛੋਟੀ ਪਲਸ ਜਿਹੜੀ ਪਹਿਲਾਂ ਹੀ ਹੇਠੋਂ ਭਟਕਣ ਨੂੰ ਸਾਹਮਣੇ ਲਿਆਉਂਦੀ—ਕੀ ਬਦਲਿਆ, ਕੀ ਰੁਕਿਆ, ਅਤੇ ਪ੍ਰਾਥਮਿਕਤਾਵਾਂ ਨੂੰ ਅਨੁਕੂਲ ਕਰਨ ਦੀ ਲੋੜ ਹੈ ਜਾਂ ਨਹੀਂ।
ਹਫਤੇ ਦੀ ਸਮਾਪਤੀ (ਸ਼ੁੱਕਰ): ਨਤੀਜਿਆਂ ਦਾ ਸੰਖੇਪ (ਕਿਰਿਆਵਾਂ ਨਹੀਂ): ਕੀ ਸ਼ਿਪ ਹੋਇਆ, ਕੀ ਠੀਕ ਹੋਇਆ, ਕੀ ਨਹੀਂ ਹੋਇਆ, ਅਤੇ ਅਗਲੇ ਹਫਤੇ ਲਈ ਕੀ ਰੱਖਣਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਫਿਰ ਵੀ ਇੱਕ ਸਿੰਕ ਪਾਲਣਾ ਕਰਦੇ ਹੋ, ਤਾਂ ਇਸਨੂੰ ਐਕਸਪਸ਼ਨਾਂ ਲਈ ਰੱਖੋ: ਅਣਸੁਲਝੇ ਰੁਕਾਵਟਾਂ, ਕ੍ਰਾਸ-ਟੀਮ ਟਰੇਡਆਫਸ, ਜਾਂ ਅਜਿਹੀਆਂ ਗੱਲਾਂ ਜਿਨ੍ਹਾਂ ਨੂੰ ਵਾਸਤਵ ਵਿੱਚ ਲਾਈਵ बहਸ ਦੀ ਲੋੜ ਹੈ।
ਸਭ ਇੱਕ ਜਿਹੇ ਟੈਂਪਲੇਟ ਵਰਤੋਂ ਤਾਂ ਕਿ ਹਰ ਕੋਈ ਤੇਜ਼ੀ ਨਾਲ ਸਕੈਨ ਕਰ ਸਕੇ:
ਬੁਲੇਟਸ ਵਿੱਚ ਲਿਖੋ, ਸਿਰਲੇਖ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਅਤੇ ਅਧਾਰ ਕੰਮ ਨੂੰ ਲਿੰਕ ਕਰੋ ਬਜਾਏ ਦੁਹਰਾਉਣ ਦੇ।
ਫੈਸਲਿਆਂ ਲਈ ਇੱਕ ਸਥਾਨ (ਉਦਾਹਰਨ ਲਈ, ਪ੍ਰੋਜੈਕਟ “Decision Log” ਥ੍ਰੇਡ) ਅਤੇ ਕਾਰਜ ਲਈ ਇੱਕ ਹੋਰ (ਟਾਸਕ/ਪ੍ਰੋਜੈਕਟ ਟ੍ਰੈਕਰ) ਚੁਣੋ। ਅਪਡੇਟ ਦੋਹਾਂ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ: “ਫੈਸਲਾ ਇੱਥੇ ਚਾਹੀਦਾ” ਅਤੇ “ਕੰਮ ਇੱਥੇ ਟਰੈਕ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ।” ਇਸ ਨਾਲ “ਅਸੀ ਕਿੱਥੇ ਇਸ ਗੱਲ ਤੇ ਸਹਿਮਤ ਹੋਏ ਸੀ?” ਵਾਲੇ ਲਮ੍ਹੇ ਘੱਟ ਹੁੰਦੇ ਹਨ।
ਇੱਕ 24-ਘੰਟੇ ਅਪਡੇਟ ਵਿੰਡੋ ਸੈੱਟ ਕਰੋ (ਨ ਕਿ ਇੱਕ ਫਿਕਸ ਮੀਟਿੰਗ ਟਾਈਮ)। ਦਿਨ ਦੇ ਅਖੀਰ 'ਤੇ ਹੈਂਡਆਫ ਨੋਟ ਪ੍ਰੇਰਨਾ ਕਰੋ, ਅਤੇ ਅਗਲੀ ਸਮੇਂ-ਜ਼ੋਨ ਨੂੰ ਸਪਸ਼ਟ ਅਨੁਰੋਧ ਦਿਓ। ਜੇ ਜ਼ਰੂਰੀ ਮੁੱਦੇ ਹੋਣ, ਤਾਂ ਇੱਕ ਪਰਿਭਾਸ਼ਿਤ ਏਸਕਲੇਸ਼ਨ ਪਾਥ ਵਰਤੋ—ਨਹੀਂ ਤਾਂ ਐਸਿੰਕ ਕਾਰਜ ਕਰਨ ਦਿਓ।
ਮੀਟਿੰਗਾਂ ਅਕਸਰ ਇਸ ਲਈ ਵਧਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਫੈਸਲੇ “ਟਿਕ” ਨਹੀਂ ਹੁੰਦੇ। ਜੇ ਲੋਕ ਕਾਲ ਛੱਡ ਕੇ ਇਹ ਨਹੀਂ ਜਾਣਦੇ ਕਿ ਕੀ ਫੈਸਲਾ ਹੋਇਆ—ਜਾਂ ਕਿਉਂ—ਤਾਂ ਸਵਾਲ ਮੁੜ-ਵਾਪਸ ਆਉਂਦੇ ਹਨ, ਨਵੇਂ ਹਿੱਸੇਦਾਰ ਵਿਸ਼ਾ ਨੂੰ ਦੁਬਾਰਾ ਖੋਲ੍ਹ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਟੀਮ ਇੱਕ ਹੋਰ ਗੱਲ-ਬਾਤ ਨਿਰਧਾਰਤ ਕਰਦੀ ਹੈ।
ਇੱਕ ਫੈਸਲਾ ਨੂੰ ਸਪਸ਼ਟ ਰਿਕਾਰਡ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਸਧਾਰਾ ਲਫ਼ਜ਼ਾਂ ਵਿੱਚ:
ਫੈਸਲਾ ਲੌਗ ਜਿੰਨਾ ਸਾਦਾ ਹੋ ਸਕੇ ਉਤਨਾ ਰੱਖੋ—ਹਰ ਫੈਸਲੇ ਲਈ ਇੱਕ ਇੰਟਰੀ ਜੋ ਪ੍ਰੋਜੈਕਟ ਨਾਲ ਲਿੰਕ ਕੀਤੀ ਹੋਵੇ ਅਤੇ ਕਿਸੇ ਵੀ ਨਿਰਭਰ ਉੱਤੇ ਦਿੱਖਣਯੋਗ ਹੋਵੇ। ਕੁੰਜੀ ਇਹ ਹੈ ਕਿ ਇਹ ਬਣਾਉਣਾ ਆਸਾਨ ਅਤੇ ਲੱਭਣਾ ਆਸਾਨ ਹੋਵੇ।
ਹਰ ਐਂਟਰੀ ਛੋਟੀ ਰੱਖੋ:
ਫਿਰ ਫੈਸਲੇ ਨੂੰ ਮਾਲਿਕਾਂ ਨਾਲ ਜੁੜੇ ਕਾਰਜ ਵਿੱਚ ਤਬਦੀਲ ਕਰੋ। “ਅਸੀਂ X ਫੈਸਲਾ ਕੀਤਾ” ਸਿਰਫ਼ ਤਦ ਹੀ ਲਾਭਕਾਰੀ ਹੈ ਜਦੋਂ ਇਹ “Alex Y ਕਰੇਗਾ ਜਦ ਤੱਕ ਸ਼ੁੱਕਰ” ਵਰਗਾ ਕਾਰਜ ਪੈਦਾ ਕਰੇ। ਜੇ ਫੈਸਲੇ ਨੇ ਟਾਸਕ ਪੈਦਾ ਨਹੀਂ ਕੀਤੇ, ਤਾਂ ਉਹ ਸ਼ਾਇਦ ਅਜੇ ਫੈਸਲਾ ਨਹੀਂ।
ਲਾਈਵ ਕਾਲ ਮੰਗਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਨਿਰਧਾਰਤ ਪ੍ਰੀ-ਰੀਡ ਪੈਟਰਨ ਵਰਤੋ:
ਪ੍ਰਸਤਾਵ (ਤੁਸੀਂ ਕੀ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ)
ਵਿਕਲਪ (2–3 ਹਕੀਕਤੀ ਚੋਣਾਂ)
ਟਰੇਡਆਫਸ (ਲਗਤ, ਖਤਰਾ, ਗ੍ਰਾਹਕ ਪ੍ਰਭਾਵ, ਸਮਾਂ)
ਸਿਫਾਰਸ਼ (ਤੁਹਾਡੀ ਚੋਣ ਅਤੇ ਕਿਉਂ)
ਟਿੱਪਣੀਆਂ ਐਸਿੰਕ ਸੱਦਾ ਦਿਓ, ਇੱਕ ਡਿਡਲਾਈਨ ਰੱਖੋ (“ਫੀਡਬੈਕ 3pm ਤੱਕ”), ਅਤੇ ਫੈਸਲਾ ਨਿਯਮ ਸਪਸ਼ਟ ਕਰੋ (ਮਾਲਿਕ ਫ਼ੈਸਲਾ ਕਰੇਗਾ, ਸਹਿਮਤੀ, ਜਾਂ approver ਲਾਜ਼ਮੀ)।
ਜੇ ٿਰੈਡ ਵਧਦੇ ਹਨ ਪਰ ਕੁਝ ਵੀ ਸਥਿਰ ਨਹੀਂ ਹੁੰਦਾ, ਤਾਂ ਆਮ ਤੌਰ 'ਤੇ ਇਸਦਾ ਕਾਰਨ ਇਹ ਹੁੰਦਾ ਹੈ ਕਿ ਫੈਸਲਾ-ਕਰਨ ਵਾਲਾ ਸਪਸ਼ਟ ਨਹੀਂ, ਮਾਪਦੰਡ ਸਪਸ਼ਟ ਨਹੀਂ, ਜਾਂ “ਅਗਲਾ ਕਦਮ” ਧੁੰਦਲਾ ਹੈ। ਸੁਧਾਰ ਲਈ ਮਾਲਿਕ ਨੂੰ ਖੁੱਲ੍ਹਾ ਨਾਮ ਦੇਵੋ ਅਤੇ ਹਰ ਚਰਚਾ ਨੂੰ ਇਕ ਤਿੰਨ ਨਤੀਜਿਆਂ ਵਿੱਚੋਂ ਇੱਕ ਨਾਲ ਖਤਮ ਕਰੋ: ਫੈਸਲਾ, ਖਾਸ ਫੀਡਬੈਕ ਦੀ ਮੰਗ, ਜਾਂ ਤਾਰੀਖ ਦੇ ਨਾਲ ਮੁਲਤਵੀ।
ਮੀਟਿੰਗਾਂ ਇੱਕ ਸਧਾਰਨ ਕਾਰਨ ਨਾਲ ਵਧਦੀਆਂ ਹਨ: ਕੋਈ ਵੀ ਪੁੱਛਣ ਤੋਂ ਬਿਨਾ ਨਹੀਂ ਜਾਣਦਾ ਕਿ ਕੀ ਹੋ ਰਿਹਾ। ਇੱਕ ਇਕ ਸੋਰਸ ਆਫ ਟਰੂਥ ਟੀਮ ਨੂੰ ਇੱਕ ਭਰੋਸੇਯੋਗ ਥਾਂ ਦਿੰਦਾ ਹੈ ਜਿੱਥੇ ਵਚਨ ਰਹਿੰਦੇ ਹਨ—ਕਿਹੜਾ ਕੰਮ ਹੋ ਰਿਹਾ, ਕੌਣ, ਕਦੋਂ ਅਤੇ “ਪੂਰਾ” ਕਿਸ ਤਰ੍ਹਾਂ ਦੇਖਿਆ ਜਾਵੇ। ਜਦੋਂ ਕੰਮ ਖੋਜਯੋਗ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਜਵਾਬ ਲੱਭਣ ਲਈ ਕਈ ਕਾਲਾਂ ਦੀ ਲੋੜ ਘੱਟ ਹੋ ਜਾਂਦੀ ਹੈ।
ਜਦੋਂ ਟਾਸਕ ਚੈਟ ਵਿੱਚ ਚਰਚਾ ਹੁੰਦੇ ਹਨ, ਫੈਸਲੇ ਈਮੇਲ ਵਿੱਚ ਦੱਬੇ ਰਹਿੰਦੇ ਹਨ, ਅਤੇ ਟਾਈਮਲਾਈਨ ਕਿਸੇ ਦੇ ਨਿੱਜੀ ਨੋਟ ਵਿੱਚ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਉਹੀ ਸਵਾਲ ਮੁੜ-ਮੁੜ ਉੱਠਦੇ ਹਨ:
ਇਹ ਫੈਲਾਅ ਨਕਲ ਚਰਚਾ ਅਤੇ ਮਿਸਡ ਸੰਦਰਭ ਪੈਦਾ ਕਰਦਾ ਹੈ। ਟੀਮ ਇਕ ਸਿੰਕ ਇਸ ਲਈ ਨਿਰਧਾਰਤ ਕਰਦੀ ਹੈ ਕਿ ਕੰਮ ਨੂੰ ਅੱਗੇ ਨਹੀਂ ਵਧਾਉਂਣਾ, ਬਲਕਿ ਉਸਨੂੰ ਮੁੜ-ਬਰਾਬਰ ਕਰਨ ਲਈ।
Asana ਵਰਗਾ ਇੱਕ ਵਰਕ ਮੈਨੇਜਮੈਂਟ ਟੂਲ ਇਸ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ ਕਿ ਵਚਨ ਪਬਲਿਕ, ਸਟ੍ਰਕਚਰਡ, ਅਤੇ ਖੋਜਯੋਗ ਹੋਣ। ਮਕਸਦ ਹਰ ਸੋਚ ਦਸਤਾਵੇਜ਼ ਕਰਨ ਦਾ ਨਹੀਂ—ਮਕਸਦ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਹੈ ਕਿ ਜੌ ਕੁਝ ਟੀਮ ਨਿਰਭਰ ਕਰਦੀ ਹੈ, ਉਹ ਇੱਕ ਮੀਟਿੰਗ ਬਿਨਾਂ ਲੱਭ ਸਕਣ।
ਜੇ ਤੁਹਾਡੀ ਟੀਮਨੂੰ ਕੁਝ ਹੋਰ ਚਾਹੀਦਾ—ਜਿਵੇਂ ਕ੍ਰਾਸ-ਫੰਕਸ਼ਨਲ ਰਿਕਵੇਸਟ ਇੰਟੇਕ ਪੋਰਟਲ, ਇੱਕ ਫੈਸਲਾ ਲੌਗ ਜੋ ਆਟੋ-ਜਨਰੇਟ ਫਾਲੋ-ਅਪ ਟਾਸਕ ਬਣਾਵੇ, ਜਾਂ ਇਕ ਸਥਿਤੀ ਡੈਸ਼ਬੋਰਡ ਜੋ ਤੁਹਾਡੇ ਗਿਆ ਸਟੇਜਾਂ ਨਾਲ ਮਿਲਦਾ-ਜੁਲਦਾ ਹੋਵੇ—Koder.ai ਇੱਕ ਪ੍ਰੈਕਟਿਕਲ ਰਸਤਾ ਹੋ ਸਕਦਾ ਹੈ। ਤੁਸੀਂ ਚੈਟ ਵਿੱਚ ਵਰਕਫਲੋ ਵੇਰਵਾ ਕਰੋ, ਅਤੇ ਇਹ ਇੱਕ ਕੰਮ ਕਰਨਯੋਗ React ਵੈੱਬ ਐਪ Go/PostgreSQL ਬੈਕਐਂਡ ਨਾਲ ਜਨਰੇਟ ਕਰ ਸਕਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਯੋਜਨਾ ਮੋਡ, ਡੈਪਲੌਇਮੈਂਟ/ਹੋਸਟਿੰਗ, ਅਤੇ ਸਰੋਤ ਕੋਡ ਐਕਸਪੋਰਟ ਜਿਹੇ ਵਿਕਲਪ ਹੁੰਦੇ ਹਨ।
ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂਨੂੰ ਵਧੇਰੇ ਟੂਲਾਂ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ; ਉਹ ਸਪਸ਼ਟ ਹੱਦਾਂ ਦੀ ਲੋੜ ਹੈ:
ਜੇ ਇਹ ਡਿਲਿਵਰੀ 'ਤੇ ਪ੍ਰਭਾਵ ਪਾਉਂਦਾ ਹੈ, ਤਾਂ ਉਹ ਵਰਕ ਟੂਲ ਵਿੱਚ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ—ਸਿਰਫ ਚੈਟ ਵਿੱਚ ਨਹੀਂ।
ਸਿਸਟਮ ਨੂੰ ਭਰੋਸੇਯੋਗ ਬਣਾਉਣ ਲਈ ਕੁਝ ਖਾਸ ਨਾਰਮ ਰੱਖੋ:
ਜਦ ਲੋਕ ਜਾਣਦੇ ਹਨ ਕਿ ਕਿੱਥੇ ਦੇਖਣਾ ਹੈ—ਅਤੇ ਜੋ ਮਿਲੇਗਾ ਉਸ 'ਤੇ ਭਰੋਸਾ ਕਰਦੇ ਹਨ—ਤਾਂ ਸਥਿਤੀ ਮੀਟਿੰਗਾਂ ਡਿਫੌਲਟ ਖੋਜ ਤਰੀਕੇ ਵਜੋਂ ਬੰਦ ਹੋ ਜਾਂਦੀਆਂ ਹਨ।
ਸਿਸਟਮਾਂ ਦਾ ਮਕਸਦ “ਕੁਇਕ ਸਿੰਕ?” ਸੁਨੇਹਿਆਂ ਨੂੰ ਬਦਲਣਾ ਹੈ, ਨ ਕਿ ਨਏ ਕਿਸਮ ਦਾ ਬਿਜੀਵਰਕ ਬਣਾਉਣਾ। ਸਭ ਤੋਂ ਆਮ ਨਾਕਾਮੀ ਮੋਡ ਟੂਲ ਨਹੀਂ—ਇਹ ਵਰਕਫਲੋ ਨੂੰ ਰੱਦ ਕਰਦੇ ਸਮੇਂ ਜ਼ਿੰਮੇਵਾਰੀ ਨੂੰ ਧੁੰਦਲਾ ਛੱਡ ਦੇਂਦਾ ਹੈ।
ਮੁਲਤ: ਇੱਕ ਮੀਟਿੰਗ-ਹਲਕੀ ਵਰਕਫਲੋ ਆਪਣੇ ਵਜ਼ਨ ਹੇਠਾਂ ਢਹਿ ਸਕਦੀ ਹੈ ਜਦੋਂ ਇਹ ਅਪਡੇਟ ਕਰਨਾ ਕਾਲ ਕਰਨ ਦੇ ਬਜਾਏ ਵੱਧ ਔਖਾ ਹੋ ਜਾਵੇ।
ਪ੍ਰੋਸੈਸ ਥੀਏਟਰ ਉਹ ਵੇਲਾ ਹੈ ਜਦੋਂ ਕੰਮ ਦਿਖਾਈ ਦੇਣ ਵਾਲਾ ਢੰਗ ਵਿੱਚ ਆਯੋਜਿਤ ਹੈ—ਹਰ ਚੀਜ਼ ਕੋਠੇ, ਟੈਗ, ਰੰਗ ਹੈ—ਪਰ ਕੁਝ ਵੀ ਤੇਜ਼ ਨਹੀਂ ਹੋ ਰਿਹਾ। ਤੁਹਾਨੂੰ ਬਹੁਤ ਸਾਰੀ ਗਤੀਖੇਤੀ ਦੇਖਣ ਨੂੰ ਮਿਲੇਗੀ (ਅਪਡੇਟ, ਰੀ-ਕੈਟਰਗਰਾਈਜ਼, ਰੀ-ਅਸਾਈਨ) ਪਰ ਬਹੁਤ ਘੱਟ ਅਸਲ ਪ੍ਰਗਤੀ। ਟੈਲ-ਟੈਸਟ: ਲੋਕ ਵਰਕਫਲੋ ਪ੍ਰਬੰਧਨ 'ਤੇ ਕੰਮ ਕਰਨ ਵਿਚ ਜ਼ਿਆਦਾ ਸਮਾਂ ਗੁਜ਼ਾਰਦੇ ਹਨ ਬਨਾਮ ਕੰਮ ਮੁਕੰਮਲ ਕਰਨ ਦੇ।
ਸਿਸਟਮ ਨੂੰ ਪ੍ਰਯੋਗਕ ਬਣਾਓ: ਹਰ ਕਦਮ ਨੂੰ ਇੱਕ ਅਸਲ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ: ਕੌਣ ਮਾਲਿਕ ਹੈ? ਅਗла ਕੀ ਹੈ? ਕਦੋਂ ਮਿਥਿਆ? “ਪੂਰਾ” ਦਾ ਕੀ ਮਤਲਬ?
ਕੁਝ ਸਧਾਰਣ ਆਦਤਾਂ ਵੱਧਣ ਤੋਂ ਰੋਕਦੀਆਂ ਹਨ:
ਦਾਖਿਲੀ ਅਸਫਲਤਾ ਹੋਂਦੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਰਾਤੋ-ਰਾਤ ਕੰਪਨੀ ਭਰ ਵਿੱਚ “ਮੀਟਿੰਗਾਂ ਠੀਕ” ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹੋ। ਇੱਕ-ਟੀਮ, ਇੱਕ ਵਰਕਫਲੋ, ਇੱਕ ਮੈਟ੍ਰਿਕ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ।
ਇੱਕ ਐਸਾ ਵਰਕਫਲੋ ਚੁਣੋ ਜੋ ਵਰਤਮਾਨ ਵਿੱਚ ਸਥਿਤੀ ਮੀਟਿੰਗਾਂ ਪੈਦਾ ਕਰਦਾ ਹੋਵੇ (ਜਿਵੇਂ ਹਫਤਾਵਾਰ ਅਪਡੇਟ)। ਮੈਟ੍ਰਿਕ ਨਿਰਧਾਰਤ ਕਰੋ (ਉਦਾਹਰਨ: ਸਥਿਤੀ ਕਾਲਾਂ ਘੱਟ, ਸਰਕਿਟ ਸਮਾਂ ਤੇਜ਼, ਜਾਂ “ਇਹ ਕਿੱਥੇ ਹੈ?” ਪਿੰਗ ਘੱਟ)। ਦੋ ਹਫ਼ਤੇ ਲਈ ਚਲਾਓ, ਸੋਧ ਕਰੋ, ਫਿਰ ਫੈਲਾਓ—ਸਿਰਫ਼ ਜਦੋਂ ਵਰਕਫਲੋ ਪ੍ਰਮਾਣਤ ਕਰੇ ਕਿ ਇਹ ਸਮਾਂ ਬਚਾਉਂਦੀ ਹੈ ਨਾ ਕਿ ਖਰਚ ਕਰਦੀ।
ਜੇ ਤੁਸੀਂ ਮੀਟਿੰਗਾਂ ਹਟਾ ਦਿੰਦੇ ਹੋ ਬਿਨਾਂ ਸਿਸਟਮ ਸੁਧਾਰ ਕੀਤੇ, ਕੰਮ ਸ਼ਾਂਤ ਹੋ ਸਕਦਾ ਹੈ—ਪਰ ਤੇਜ਼ ਨਹੀਂ। ਮਕਸਦ ਘੱਟ ਵਿਘਨਵਾਂ ਨਾਲ ਦਿੱਖਣਯੋਗ ਤਰੱਕੀ ਹੈ, ਸਿਰਫ਼ ਖ਼ਾਲੀ ਕੈਲੰਡਰ ਨਹੀਂ।
2–4 ਹਫਤਿਆਂ ਵਿੱਚ ਜੋ ਤਬਦੀਲੀਆਂ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ:
ਇਹਨਾਂ ਨੂੰ ਦਿਸ਼ਾ-ਸੂਚਕ ਰੁਪ ਵਿੱਚ ਵਰਤੋ। ਜੇ ਮੀਟਿੰਗਾਂ ਘੱਟ ਹੋਂਦੀਆਂ ਹਨ ਪਰ ਸਰਪ੍ਰਾਈਜ਼ ਵੱਧ ਰਹੇ ਨੇ, ਤਾਂ ਤੁਸੀਂ ਦਰਦ ਨੂੰ ਸਿਰਫ਼ ਥਲੇ ਦਬਾ ਦਿੱਤਾ ਹੈ।
3–5 ਮੈਟ੍ਰਿਕ ਚੁਣੋ ਅਤੇ ਲਗਾਤਾਰ ਰੱਖੋ। ਉਪਯੋਗ ਵਿਕਲਪ:
ਤੁਸੀਂ ਇਹ ਵਰਕਫਲੋ ਸੌਫਟਵੇਅਰ ਵਿੱਚ ਇੱਕਸਾਰ ਸਥਿਤੀਆਂ, ਮਿਆਦਾਂ ਅਤੇ “ਪੂਰਾ” ਦੀ ਸਪਸ਼ਟ ਪਰਿਭਾਸ਼ਾ ਨਾਲ ਟ੍ਰੈਕ ਕਰ ਸਕਦੇ ਹੋ।
ਅੰਕੜੇ ਨਹੀਂ ਦੱਸਦੇ ਕਿ ਲੋਕ ਆਪਣੇ ਆਪ ਨੂੰ ਸੁਰੱਖਿਅਤ ਅਤੇ ਸਪਸ਼ਟ ਮਹਿਸੂਸ ਕਰ ਰਹੇ ਹਨ ਜਾਂ ਨਹੀਂ।
ਮਹੀਨੇ ਵਿੱਚ ਪੁੱਛੋ:
ਐਡ-ਹਾਕ ਕਾਲਾਂ ਅਤੇ ਆਖਰੀ-ਮਿੰਟ ਪਿੰਗਾਂ ਵਿੱਚ ਕਮੀ ਅਕਸਰ ਇਕ ਮਜ਼ਬੂਤ ਸੂਚਕ ਹੁੰਦੀ ਹੈ ਕਿ ਸਿਸਟਮ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ।
ਜੇ throughput ਠਹਿਰਿਆ ਰਹੇ ਜਾਂ ਗੁਣਵੱਤਾ ਘਟਦੀ ਹੋਵੇ ਤਾਂ “ਮੀਟਿੰਗ 40% ਘਟ ਗਈ” ਦਾ ਜਸ਼ਨ ਨਾ ਮਨਾਓ। ਸਭ ਤੋਂ ਵਧੀਆ ਸਕੋਰਕਾਰਡ ਬਚਾਇਆ ਸਮਾਂ ਨੂੰ ਚੰਗੇ ਨਤੀਜਿਆਂ ਨਾਲ ਜੋੜਦਾ ਹੈ: ਸਥਿਰ ਤਰੀਕੇ ਨਾਲ ਡਿਲਿਵਰੀ, ਘੱਟ ਮੁੜ-ਲੇਖ, ਅਤੇ ਘੱਟ ਕੋਆਰਡੀਨੇਸ਼ਨ ਘਰੜ—ਬਿਨਾਂ ਲੋਕਾਂ ਨੂੰ ਝਲਸਾਉਣ ਦੇ।
ਮੀਟਿੰਗ-ਹਲਕੀ ਵਰਕਫਲੋ ਸਭ ਤੋਂ ਵਧੀਆ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਕਰਦੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਆਦਤ ਨੂੰ ਇਕ ਵਾਰੀ ਬਦਲਦੇ ਹੋ, ਫਿਰ ਉਸ ਨੂੰ ਕਾਇਮ ਰੱਖਦੇ ਹੋ। ਇਹ ਇਕ ਸੁਰੱਖਿਅਤ 30-ਦਿਨ ਯੋਜਨਾ ਹੈ ਜੋ ਕਾਲਾਂ ਨੂੰ ਘੱਟ ਕਰਦੀ ਹੈ ਬਿਨਾਂ ਅਲਾਇਨਮੈਂਟ ਨੁਕਸਾਨ ਕੀਤੇ।
ਇੱਕ ਇਕੱਲੀ "status" ਮੀਟਿੰਗ ਚੁਣੋ ਜਿਸਦਾ ਸਭ ਤੋਂ ਸਪਸ਼ਟ ਵਿਕਲਪ ਹੋ—ਆਮ ਤੌਰ 'ਤੇ ਹਫਤਾਵਾਰੀ ਟੀਮ ਸਥਿਤੀ।
ਲਿਖਤੀ ਰੂਪ ਵਿੱਚ ਬਦਲ:
ਫਿਰ ਅਗਲੀ ਘਟਨਾ ਰੱਦ ਕਰੋ ਜਾਂ ਉਸਨੂੰ 15 ਮਿੰਟ ਵਿੱਚ ਘਟਾ ਦਿਓ ਅਤੇ ਇਸ ਵੇਲੇ ਸਿਰਫ਼ ਉਹੀ ਰੁਕਾਵਟ ਹੱਲ ਕਰੋ ਜੋ ਐਸਿੰਕ ਨਾਲ ਨਹੀਂ ਹੋ ਸਕਦੀ।
ਲੋਗ ਐਸਿੰਕ ਅਪਡੇਟ ਸਕਿੱਪ ਕਰਦੇ ਹਨ ਜਦੋਂ ਉਹਨਾਂ ਨੂੰ ਪਤਾ ਨਹੀਂ ਹੁੰਦਾ ਕਿ ਕੀ ਲਿਖਣਾ ਹੈ। ਛੋਟੇ ਟੈਂਪਲੇਟ ਜੋੜੋ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਡਿਫੌਲਟ ਬਣਾਓ।
ਜੇ ਤੁਸੀਂ ਆਪਣੀ ਵਰਕਫਲੋ ਖੁਦ ਬਣਾਉਣ ਦੀ ਥਾਂ ਉੱਪਰਅਦਾਨ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ ਉਹ ਸਥਾਨ ਹੈ ਜਿੱਥੇ Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ ਤੇਜ਼ੀ ਨਾਲ ਮੁਮਕਿਨ ਸਹਾਇਤਾ ਦੇ ਸਕਦੇ ਹਨ: ਸ਼ੁਰੂਆਤੀ ਐਪ ਅਤੇ ਟੈਂਪਲੇਟ ਜਨਰੇਟ ਕਰੋ, ਫਿਰ ਇਤਰਾਟੇਟ ਕਰੋ। snapshots ਅਤੇ rollback ਵਰਗੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਪ੍ਰਕਿਰਿਆ ਦੀਆਂ ਤਬਦੀਲੀਆਂ ਨੂੰ ਬਿਨਾਂ ਡਰ ਦੇ ਪ੍ਰਯੋਗ ਕਰਨ ਯੋਗ ਬਣਾਉਂਦੀਆਂ ਹਨ।
ਹਰ ਵਚਨ ਲਈ ਮਾਲਿਕ ਸਪਸ਼ਟ ਕਰੋ ਅਤੇ ਹੋਰਨਾਂ ਨੂੰ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਜਵਾਬ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ।
ਉਦਾਹਰਨ ਲਈ: “ਰੁਕਾਵਟਾਂ ਤੇ ਟਿੱਪਣੀ 24 ਘੰਟਿਆਂ ਵਿੱਚ” ਅਤੇ “ਜੇ EOD ਤੱਕ ਜਵਾਬ ਨਹੀਂ, ਤਾਂ ਮਾਲਿਕ ਵਿਕਲਪ A ਨਾਲ ਅੱਗੇ ਵਧੇ।” ਇਹ ਐਸਿੰਕ ਕੰਮ ਨੂੰ ਨੀਰਵਾਣ ਦਾ ਰੂਪ ਨਹੀਂ ਬਣਨ ਦਿੰਦਾ।
ਰਿਕਰਿੰਗ ਮੀਟਿੰਗਾਂ ਦਾ ਅਡਿਟ ਕਰੋ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਟੈਗ ਕਰੋ:
30ਵੇਂ ਦਿਨ 'ਤੇ: ਮੀਟਿੰਗਾਂ ਦੀ ਗਿਣਤੀ, ਟਾਈਮ ਤੇ ਡਿਲਿਵਰੀ, ਅਤੇ ਕੰਮ ਕਿੱਥੇ “ਸਰਪ੍ਰਾਈਜ਼ਿੰਗ” ਰਹਿੰਦਾ ਹੈ—ਇਹ ਤੁਲਨਾ ਕਰੋ। ਜੇ ਸਰਪ੍ਰਾਈਜ਼ ਘੱਟ ਹੋਏ, ਤਾਂ ਸਿਸਟਮ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਹੋਰ ਵਿਹਾਰਕ ਪਲੇਇਬੁਕ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ /blog 'ਤੇ ਟੀਮ ਵਰਕਫਲੋ ਗਾਈਡਾਂ ਅਤੇ ਟੈਂਪਲੇਟ ਵੇਖੋ।
ਮੀਟਿੰਗਾਂ ਵਧ ਜਾਂਦੀਆਂ ਨੇ ਜਦੋਂ ਟੀਮ ਕੋਲ ਕੰਮ ਦਾ ਇੱਕ ਭਰੋਸੇਯੋਗ, ਸਾਂਝਾ ਨਜ਼ਾਰਾ ਨਹੀਂ ਹੁੰਦਾ।
ਜੇ ਬਹੁਤ ਸਾਰੀਆਂ ਦਾਅਵਾਂ ਲੋਕਾਂ ਦੇ ਸਿਰਾਂ ਵਿੱਚ, DMs, ਫੈਲੇ ਹੋਏ ਦਸਤਾਵੇਜ਼ਾਂ ਜਾਂ ਸਪ੍ਰੈਡਸ਼ੀਟਾਂ ਵਿੱਚ ਰਹਿੰਦੀਆਂ ਹਨ, ਤਾਂ ਸਾਂਝਾ ਸੰਦਰਭ ਮੁੜ ਬਣਾਉਣ ਲਈ ਇਕੱਲੇ ਤਰੀਕੇ ਨਾਲ ਲੋਕਾਂ ਨੂੰ ਇਕੱਠਾ ਕਰਨਾ ਹੀ ਇੱਕੋ ਰਸਤਾ ਰਹਿ ਜਾਂਦਾ ਹੈ — ਫਿਰ ਵੀ, ਫਿਰ।
“ਦਿਖਣਯੋਗ ਕੰਮ” ਦਾ ਅਰਥ ਹੈ ਕਿ ਕੋਈ ਵੀ ਤੇਜ਼ੀ ਨਾਲ ਜਵਾਬ ਦੇ ਸਕੇ:
ਇਹ ਸਰਫ਼ ਪਾਰਦਰਸ਼ੀਤਾ ਲਈ ਨਹੀਂ, ਬਲਕਿਉਂ ਸੰਯੋਜਨ ਅਣਿਸ਼ਚਿਤਤਾ ਘਟਾਉਣ ਲਈ ਹੈ।
ਹੀਰੋਇਕਸ ਉਹ ਆਖਰੀ-ਪਲ ਦੇ ਬਚਾਅ ਹਨ ਜੋ ਯਾਦ, ਤਤਕਾਲਤਾ ਅਤੇ غیر ਰਸਮੀ ਨੁਸਖਿਆਂ (DMs, ਰਸਤੇ 'ਚ ਗੱਲਾਂ, ਛੋਟੀ ਕਾਲਾਂ) 'ਤੇ ਨਿਰਭਰ ਹੁੰਦੇ ਹਨ।
ਸਿਸਟਮ ਉਹ ਸਭ ਕੁਝ ਦੁਹਰਾਉਣਯੋਗ ਬਣਾਉਂਦੇ ਹਨ: ਸਾਫ਼ ਵਰਕਫਲੋਜ਼, ਖੁੱਲ੍ਹੀ ਜ਼ਿੰਮੇਵਾਰੀ, ਅਤੇ ਸੰਦਰਭ ਨੂੰ ਕੈਪਚਰ ਕਰਨਾ ਤਾਂ ਕਿ ਤਰੱਕੀ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਨਾ ਰਹੇ ਕਿ ਆਖ਼ਰੀ ਕੌਲ ਕੌਣ ਸੀ।
ਅਕਸਰ ਬਦਲਣ ਯੋਗ ਹਨ:
ਲਕਸ਼্য ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਘਟੀਆਆਂ ਗੱਲਾਂ ਨਹੀਂ, ਬਲਕਿ ਦੁਹਰਾਏ ਜਾ ਰਹੇ ਗੱਲ-ਬਾਤ ਘੱਟ ਹੋਣ।
ਹੇਠਾਂ ਵਾਲੀਆਂ ਸਥਿਤੀਆਂ ਵਿੱਚ ਸੀਜ਼ਨਲ ਹੋਰ-ਰੂਪ ਨਾਲ ਰੱਖੋ ਜਾਂ ਸੀਮਿਤ ਵਰਤੋ:
ਚੁਣੋ ਐਸਿੰਕ ਜੇ ਲਿਖਤੀ ਸੰਦਰਭ ਕਾਫ਼ੀ ਹੈ ਅਤੇ ਲੋਕ ~24 ਘੰਟਿਆਂ ਵਿੱਚ ਜਵਾਬ ਦੇ ਸਕਦੇ ਹਨ।
ਮੀਟਿੰਗ ਚੁਣੋ ਜੇ ਤੁਹਾਨੂੰ ਰੀਅਲ-ਟਾਈਮ बहस ਦੀ ਲੋੜ ਹੈ, ਭਾਵਨਾ/ਟੋਨ ਮਹੱਤਵਪੂਰਨ ਹਨ, ਜਾਂ ਤੁਹਾਨੂੰ ਅੱਜ ਇੱਕ ਇਕੱਲਾ ਫੈਸਲਾ ਅਤੇ ਸਪਸ਼ਟ ਮਾਲਿਕ ਲੈ ਕੇ ਨਿਕਲਣਾ ਹੈ।
ਇੱਕ ਮਜ਼ਬੂਤ ਟਾਸਕ ਇੱਕ ਅਸਲੀ ਵਾਅਦਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਨ ਕਿ ਧੁੰਦਲੀ ਨੋਟ:
ਜੇ ਟਾਸਕ “Discuss X” ਵਰਗਾ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਨਤੀਜੇ ਵਾਂਗ “Draft X and share for review” ਵਿੱਚ بدلੋ।
“ਪੂਰਾ” ਪਹਿਲਾਂ ਹੀ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ। ਹੌਲੀ-ਹੌਲੀ ਸਵੀਕਾਰਤਾ ਮਿਆਰ ਰੱਖੋ:
ਇਸ ਨਾਲ ਮੁੜ-ਕੰਮ ਅਤੇ “ਮੈਨੂੰ ਲੱਗਿਆ ਤੁਸੀਂ…” ਵਾਲੀ ਲੂਪ ਰੁਕਦੀ ਹੈ।
ਇੱਕ ਹਲਕੀ-ਫੁਲਕੀ ਫੈਸਲਾ ਲੌਗ ਝੱਟ ਬਣਾਓ ਜੋ ਇਹ ਦਰਸਾਉਂਦੀ:
ਜੇ ਇਹ ਫੈਸਲਾ ਮਾਲਿਕਾਂ ਨਾਲ ਜੁੜੇ ਟਾਸਕ ਨਹੀਂ ਬਣਾਉਂਦਾ, ਤਾਂ ਇਹ ਸ਼ਾਇਦ ਅਜੇ ਫੈਸਲਾ ਨਹੀਂ।
ਸਧਾਰਨ ਸਿੱਧੇ-ਸਪਾਟ ਹਦਬੰਦੀ ਰੱਖੋ:
ਨਿਯਮ: ਜੋ ਕੁਝ ਡਿਲਿਵਰੀ 'ਤੇ ਪ੍ਰਭਾਵ ਪਾਉਂਦਾ, ਉਹ work tool ਵਿੱਚ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ — ਸਿਰਫ਼ ਚੈਟ ਵਿੱਚ ਨਹੀਂ।