ਜਦੋਂ ਤੁਹਾਨੂੰ ਤੇਜ਼ ਜਾਣ ਲਈ ਕਿਹਾ ਜਾਂਦਾ ਹੈ ਪਰ ਹੋਰ ਲੋਕ ਨਹੀਂ ਦਿੱਤੇ ਜਾਂਦੇ ਤਾਂ ਤੁਸੀਂ ਕੀ ਕਰਦੇ ਹੋ?

Question

Accepted Answer

ਲੋਕ ਜੋੜਨਾ ਵੈਸੇ ਵੀ ਘੱਟ ਹੀ ਕਿਸੇ ਟੀਮ ਨੂੰ ਥੋੜ੍ਹੇ ਸਮੇਂ ਵਿੱਚ ਤੇਜ਼ ਬਣਾਉਂਦਾ ਹੈ, ਇਸ ਲਈ ਅਸਲ ਸਵਾਲ ਇਹ ਹੈ: ਟੀਮ ਦਾ *ਸਮਾਂ ਅਸਲ ਵਿੱਚ ਕਿੱਥੇ ਜਾ ਰਿਹਾ ਹੈ*, ਅਤੇ ਮੈਂ ਉਸ ਬਾਰੇ ਕੀ ਬਦਲ ਸਕਦਾ ਹਾਂ? ਮੈਂ "ਤੇਜ਼ ਜਾਓ" ਨੂੰ ਲੰਮੇ ਘੰਟੇ ਕੰਮ ਕਰਨ ਦੀ ਮੰਗ ਵਜੋਂ ਨਹੀਂ, ਸਗੋਂ leverage ਲੱਭਣ ਦੇ ਇਸ਼ਾਰੇ ਵਜੋਂ ਸਮਝਦਾ ਹਾਂ।

## ਮੈਂ ਰਫ਼ਤਾਰ ਕਿੱਥੇ ਲੱਭਦਾ ਹਾਂ

- **ਦਾਇਰਾ ਕੱਟੋ, ਕੋਨੇ ਨਹੀਂ।** ਤੇਜ਼ ship ਕਰਨ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਘੱਟ ਬਣਾਉਣਾ ਹੈ। ਮੈਂ PM ਨਾਲ ਬੇਰਹਿਮੀ ਨਾਲ ਤਰਜੀਹ ਦੇਣ ਅਤੇ ਸਭ ਤੋਂ ਛੋਟਾ version ਲੱਭਣ ਲਈ ਕੰਮ ਕਰਦਾ ਹਾਂ ਜੋ ਕੀਮਤ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਜ਼ਿਆਦਾਤਰ features 20% ਕੰਮ ਵਿੱਚ 80% ਕੀਮਤ ਹੁੰਦੇ ਹਨ।
- **ਰਗੜ ਅਤੇ ਇੰਤਜ਼ਾਰ ਦਾ ਸਮਾਂ ਹਟਾਓ।** ਅਕਸਰ bottleneck coding ਦੀ ਰਫ਼ਤਾਰ ਨਹੀਂ ਹੁੰਦਾ — ਇਹ ਹੌਲੀ CI, flaky tests, ਔਖੇ deploys, ਹੌਲੀ reviews, ਜਾਂ ਪ੍ਰਵਾਨਗੀਆਂ ਦਾ ਇੰਤਜ਼ਾਰ ਹੁੰਦਾ ਹੈ। ਇੱਕ 30-ਮਿੰਟ ਦੇ build ਜਾਂ ਦੋ-ਦਿਨ ਦੇ review turnaround ਨੂੰ ਠੀਕ ਕਰਨਾ ਮੁਫ਼ਤ ਵਿੱਚ ਅਸਲ velocity ਖ਼ਰੀਦਦਾ ਹੈ।
- **Work-in-progress ਘਟਾਓ।** ਦਸ ਚੀਜ਼ਾਂ ਨੂੰ juggle ਕਰਨ ਵਾਲੀਆਂ ਟੀਮਾਂ ਕੁਝ ਵੀ ਪੂਰਾ ਨਹੀਂ ਕਰਦੀਆਂ। ਸਮਾਨਾਂਤਰ ਘੱਟ ਚੀਜ਼ਾਂ 'ਤੇ ਫੋਕਸ ਕਰਨਾ ਚੀਜ਼ਾਂ ਨੂੰ ਜਲਦੀ ship ਕਰਦਾ ਹੈ।
- **ਦੁਹਰਾਉਣ ਵਾਲੇ ਨੂੰ automate ਕਰੋ।** ਹੱਥੀਂ testing, ਹੱਥੀਂ releases, ਹੱਥੀਂ environment setup — ਇੱਕ ਵਾਰ ਨਿਵੇਸ਼ ਕਰੋ, ਹਮੇਸ਼ਾ ਲਈ ਬਚਾਓ।
- **ਉਸ debt ਨੂੰ ਚੁਕਾਓ ਜੋ ਤੁਹਾਨੂੰ ਸਰਗਰਮੀ ਨਾਲ ਹੌਲੀ ਕਰ ਰਿਹਾ ਹੈ।** ਸਾਰਾ ਨਹੀਂ; ਸਿਰਫ਼ ਉਹ ਹਿੱਸਾ ਜਿਸ ਨਾਲ ਟੀਮ ਰੋਜ਼ਾਨਾ ਠੋਕਰ ਖਾਂਦੀ ਹੈ।
- **ਫੋਕਸ ਦੇ ਸਮੇਂ ਦੀ ਰੱਖਿਆ ਕਰੋ।** ਘੱਟ meetings ਅਤੇ ਰੁਕਾਵਟਾਂ ਕਿਸੇ ਵੀ tool ਨਾਲੋਂ ਵੱਡੀ ਜਿੱਤ ਹੋ ਸਕਦੀ ਹੈ।

## ਮੈਂ ਮੰਗ ਦਾ ਜਵਾਬ ਕਿਵੇਂ ਦਿੰਦਾ ਹਾਂ

ਮੈਂ ਸਿਰਫ਼ "ਅਸੰਭਵ" ਨਹੀਂ ਕਹਿੰਦਾ ਜਾਂ ਚੁੱਪ-ਚਾਪ ਇਸ ਨੂੰ ਸਵੀਕਾਰ ਨਹੀਂ ਕਰਦਾ। ਮੈਂ ਇੱਕ **trade-off** ਨਾਲ ਜਵਾਬ ਦਿੰਦਾ ਹਾਂ: "ਅਸੀਂ ਉਸ ਤਾਰੀਖ਼ ਨੂੰ ਪਹੁੰਚ ਸਕਦੇ ਹਾਂ ਜੇ ਅਸੀਂ features A ਅਤੇ B ਕੱਟ ਦੇਈਏ, ਜਾਂ testing 'ਤੇ ਵੱਧ ਜੋਖ਼ਮ ਸਵੀਕਾਰ ਕਰੀਏ। ਇੱਥੇ ਮੇਰੀ ਸਿਫ਼ਾਰਸ਼ ਹੈ।" ਇਹ ਰਫ਼ਤਾਰ ਨੂੰ ਇੱਕ ਚੁੱਪ ਗੁਣਵੱਤਾ ਜੂਏ ਦੀ ਬਜਾਏ ਇੱਕ ਸਾਂਝਾ, ਸੁਚੇਤ ਫ਼ੈਸਲਾ ਬਣਾਉਂਦਾ ਹੈ।

## ਬਚਣ ਵਾਲੀਆਂ ਗ਼ਲਤੀਆਂ

- **Overtime ਨੂੰ ਲਾਜ਼ਮੀ ਕਰਨਾ।** ਇਹ ਇੱਕ ਛੋਟਾ sprint ਖ਼ਰੀਦਦਾ ਹੈ ਅਤੇ ਇਸ ਨੂੰ burnout, bugs, ਅਤੇ attrition ਨਾਲ ਚੁਕਾਉਂਦਾ ਹੈ।
- **ਚੁੱਪ-ਚਾਪ tests ਅਤੇ reviews ਛੱਡਣਾ।** ਅੱਜ ਰਫ਼ਤਾਰ, ਅਗਲੇ ਮਹੀਨੇ ਇੱਕ outage।
- **ਕੁਝ ਵੀ ਬਦਲੇ ਬਿਨਾਂ ਤਾਰੀਖ਼ ਨੂੰ ਹਾਂ ਕਹਿਣਾ** — ਇਹ ਸਿਰਫ਼ ਉਮੀਦ ਕਰਨਾ ਹੈ, ਅਤੇ ਉਮੀਦ deadlines ਖੁੰਝਾ ਦਿੰਦੀ ਹੈ।

## ਇਹ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ

ਟਿਕਾਊ ਰਫ਼ਤਾਰ ਬਰਬਾਦੀ ਹਟਾਉਣ ਤੋਂ ਆਉਂਦੀ ਹੈ, ਨਾ ਕਿ ਲੋਕਾਂ ਨੂੰ ਨਿਚੋੜਨ ਤੋਂ। ਇੱਕ Tech Lead ਜੋ ਦਬਾਅ ਦਾ ਜਵਾਬ ਸਪੱਸ਼ਟ trade-offs ਅਤੇ ਪ੍ਰਕਿਰਿਆ ਸੁਧਾਰਾਂ ਨਾਲ ਦਿੰਦਾ ਹੈ, ਇੱਕ ਅਜਿਹੀ ਟੀਮ ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਸੱਚਮੁੱਚ ਤੇਜ਼ ਅਤੇ ਟਿਕਾਊ ਹੈ — ਨਾ ਕਿ ਉਹ ਜੋ sprint ਕਰਦੀ ਹੈ, ਢਹਿ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਆਪਣੇ ਸਭ ਤੋਂ ਵਧੀਆ engineers ਗੁਆ ਬੈਠਦੀ ਹੈ।