ਸੰਸਥਾ ਦੀ ਡਿਜ਼ਾਈਨ ਟੀਮ ਦੀਆਂ ਸੀਮਾਵਾਂ ਖਿੱਚਣੀ ਹੈ ਤਾਂ ਕਿ ਕੰਮ ਜੋ ਇਕੱਠੇ ਬਦਲਦਾ ਹੈ ਉਹ ਇਕੱਠੇ ਰਹੇ — ਟੀਮ-ਪਾਰ ਨਿਰਭਰਤਾਵਾਂ ਨੂੰ ਉਹਨਾਂ ਚੀਜ਼ਾਂ ਲਈ ਘੱਟ ਕਰਨਾ ਜੋ ਤੇਜ਼ ਚੱਲ ਰਹੀਆਂ ਹਨ। ਬਣਤਰ ਨੂੰ ਰਣਨੀਤੀ ਅਤੇ ਸਿਸਟਮ ਦੀ ਪਾਲਣਾ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ, ਉਲਟ ਨਹੀਂ।
ਸਿਧਾਂਤ
1. TEAMS OWN OUTCOMES, not layers (a team owns a product/domain end to end)
2. MINIMIZE DEPENDENCIES — autonomous teams ship faster
3. CONWAY'S LAW — your architecture will mirror your org; design both together
4. CLEAR OWNERSHIP — every critical area has ONE owning team
5. RIGHT SIZE — ~5–9 people; two-pizza teams
6. COGNITIVE LOAD — don't give one team more domains than it can hold
ਸਟ੍ਰੀਮ-ਅਲਾਈਨਡ ਸੋਚ
ਲੰਬੇ ਸਮੇਂ ਲਈ, ਸਟ੍ਰੀਮ-ਅਲਾਈਨਡ ਟੀਮਾਂ ਨੂੰ ਤਰਜੀਹ ਦਿਓ ਜੋ ਕੰਮ ਦੇ ਵਹਾਅ ਦੀ ਮਾਲਕਾਨਾ ਕਰਦੀਆਂ ਹਨ, ਪਲੱਟਫਾਰਮ ਟੀਮਾਂ ਦੁਆਰਾ ਸਮਰਥਿਤ ਜੋ ਦੂਜਿਆਂ ਦੀ ਬੌਧਿਕ ਲੋਡ ਨੂੰ ਘਟਾਉਂਦੀਆਂ ਹਨ। ਜਦੋਂ ਬਣਤਰ ਕੰਮ ਦੇ ਨਾਲ ਲੜਾਈ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰੇ ਤਾਂ ਮੁੜ ਸੰਗਠਨ ਕਰੋ — ਜਪਤਾ ਅਨੁਸਾਰ ਨਹੀਂ।
ਖਤਰੇ
- ਫੰਕਸ਼ਨਲ ਸਾਈਲੋ (ਇੱਕ "QA ਟੀਮ," ਇੱਕ "frontend ਟੀਮ") ਜੋ ਹਰ ਫੀਚਰ ਨੂੰ ਬਹੁਤ ਹੱਥ ਬਦਲਣ ਲਈ ਮਜਬੂਰ ਕਰਦੇ ਹਨ।
- Conway's Law ਨੂੰ ਅਣਦੇਖਾ ਕਰਨਾ ਅਤੇ ਹੈਰਾਨ ਹੋਣਾ ਕਿ ਆਰਕਿਟੈਕਚਰ ਆਰਗ ਚਾਰਟ ਨੂੰ ਪ੍ਰਤੀਬਿੰਬਤ ਕਰਦਾ ਹੈ।
- ਲਗਾਤਾਰ ਪੁਨਰ-ਸੰਗਠਨ, ਜੋ ਹਰ ਵਾਰ ਵਿਸ਼ਵਾਸ ਅਤੇ ਮਾਲਕਾਨਾ ਨੂੰ ਰੀਸੈੱਟ ਕਰਦਾ ਹੈ।
- ਧੁੰਦਲੀ ਮਾਲਕਾਨਾ, ਜਿੱਥੇ ਸਭ ਕੁਝ "ਸਾਂਝਾ" ਹੈ ਅਤੇ ਇਸ ਲਈ ਕਿਸੇ ਦਾ ਮਾਲਕ ਨਹੀਂ ਹੈ।
ਇਹ ਮਾਮਲਾ ਕਿਉਂ ਹੈ
ਬਣਤਰ ਖਾਮੋਸ਼ੀ ਨਾਲ ਗਤੀ ਨਿਰਧਾਰਤ ਕਰਦੀ ਹੈ।
ਖराब ਸੀਮਾਈ ਅੰਤਹੀਨ ਤਾਲਮੇਲ ਸਭਾਵਾਂ ਅਤੇ ਧੁੰਦਲੀ ਜਵਾਬਦੇਹੀ ਸਿਰਜਦੀਆਂ ਹਨ; ਚੰਗੀਆਂ ਸੀਮਾਵਾਂ ਟੀਮਾਂ ਨੂੰ ਸੁਤੰਤਰ ਤਰੀਕੇ ਨਾਲ ਅੱਗੇ ਵਧਣ ਦਿੰਦੀਆਂ ਹਨ।
Conway's Law ਦੀ ਜ਼ਬਾਨਦਹੀ ਕਾਰਨ, ਸੰਸਥਾ ਡਿਜ਼ਾਈਨ ਆਰਕਿਟੈਕਚਰ ਡਿਜ਼ਾਈਨ ਹੈ।
ਟੀਮ ਦੀਆਂ ਸੀਮਾਵਾਂ ਗ਼ਲਤ ਪਾਈਆਂ ਮਤਲਬ ਕੋਈ ਵੀ ਯਤਨ ਸਿਸਟਮ ਨੂੰ ਸਾਫ ਨਹੀਂ ਕਰ ਸਕਦਾ।