SaaS
ਤੁਸੀਂ ਹਰ ਦੋ ਹਫ਼ਤਿਆਂ ਵਿੱਚ ਰੀਲੀਜ਼ ਕਰਦੇ ਹੋ ਅਤੇ ਸਾਲ ਵਿੱਚ ਦੋ ਵਾਰ ਉਸ ਬਾਰੇ ਲਿਖਦੇ ਹੋ
ਸੌਫ਼ਟਵੇਅਰ ਟੀਮਾਂ ਕਹਿਣ ਨੂੰ ਚੀਜ਼ਾਂ ਤੋਂ ਖਾਲੀ ਨਹੀਂ ਹੁੰਦੀਆਂ। ਉਹ ਉਸ ਵਿਅਕਤੀ ਤੋਂ ਖਾਲੀ ਹੁੰਦੀਆਂ ਹਨ ਜੋ ਉਹ ਕਹੇ, ਕਿਉਂਕਿ ਲਿਖਣਾ ਹਮੇਸ਼ਾ ਉਹ ਕੰਮ ਹੁੰਦਾ ਹੈ ਜੋ ਰੀਲੀਜ਼ ਲੇਟ ਹੋਣ 'ਤੇ ਪਿੱਛੇ ਧੱਕਿਆ ਜਾਂਦਾ ਹੈ — ਅਤੇ ਇਹ ਹਰ ਵਾਰ ਪਿੱਛੇ ਧੱਕਿਆ ਜਾਂਦਾ ਹੈ, ਜਦ ਤੱਕ ਬਲੌਗ ਦੀ ਸਭ ਤੋਂ ਤਾਜ਼ਾ ਪੋਸਟ ਗਿਆਰਾਂ ਮਹੀਨੇ ਪੁਰਾਣੀ ਨਾ ਹੋ ਜਾਵੇ ਅਤੇ "ਪੇਸ਼ ਕਰ ਰਹੇ ਹਾਂ" ਨਾ ਲਿਖੀ ਹੋਵੇ।
ਨਾਕਾਮੀ ਢਾਂਚਾਗਤ ਹੈ, ਸੰਪਾਦਕੀ ਨਹੀਂ
ਹਰ ਟੀਮ ਜਾਣਦੀ ਹੈ ਕਿ ਉਸ ਨੂੰ ਜ਼ਿਆਦਾ ਲਿਖਣਾ ਚਾਹੀਦਾ ਹੈ। ਇੰਜੀਨੀਅਰ ਲਿਖ ਸਕਦੇ ਹਨ; ਬਾਨੀ ਲਿਖ ਸਕਦਾ ਹੈ; ਆਮ ਤੌਰ 'ਤੇ ਕੋਈ ਇੱਕ ਇਸ ਦਾ ਆਨੰਦ ਵੀ ਲੈਂਦਾ ਹੈ। ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਲਿਖਣ ਦੀ ਆਪਣੀ ਕੋਈ ਡੈੱਡਲਾਈਨ ਨਹੀਂ ਹੁੰਦੀ, ਅਤੇ ਬਿਨਾਂ ਡੈੱਡਲਾਈਨ ਵਾਲੀ ਕੋਈ ਵੀ ਚੀਜ਼ ਹਰ ਦੋ ਹਫ਼ਤਿਆਂ ਵਿੱਚ, ਹਮੇਸ਼ਾ ਲਈ, ਕਿਸੇ ਡੈੱਡਲਾਈਨ ਵਾਲੀ ਚੀਜ਼ ਤੋਂ ਹਾਰ ਜਾਂਦੀ ਹੈ।
ਯੋਜਨਾ ਉਹ ਗੁੰਮ ਹੋਈ ਡੈੱਡਲਾਈਨ ਦੇ ਦਿੰਦੀ ਹੈ। ਇੱਕ ਤਾਰੀਖ਼ ਵਾਲਾ ਸਲਾਟ, ਜਿਸ ਨਾਲ ਇੱਕ ਵਿਸ਼ਾ ਅਤੇ ਇੱਕ ਲੇਖਕ ਜੁੜਿਆ ਹੋਵੇ, ਇੱਕ ਸ਼ਾਂਤ ਹਫ਼ਤੇ ਕੀਤਾ ਗਿਆ ਵਾਅਦਾ ਹੈ, ਜੋ ਇੱਕ ਬੇਚੈਨ ਹਫ਼ਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਡਰਾਫ਼ਟ ਉਸ ਵੇਲੇ ਵੀ ਬਣ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਕਿਸੇ ਨੂੰ ਯਾਦ ਨਾ ਹੋਵੇ। ਇਸ ਨੂੰ ਮਨਜ਼ੂਰ ਕਰਨ ਵਿੱਚ ਮਿੰਟ ਲੱਗਦੇ ਹਨ; ਇਸ ਨੂੰ ਸ਼ੂਨਿਆ ਤੋਂ ਲਿਖਣ ਵਿੱਚ ਉਹ ਦੁਪਹਿਰ ਲੱਗਦੀ ਹੈ ਜੋ ਕਦੇ ਆਉਂਦੀ ਹੀ ਨਹੀਂ।
ਇਹੀ ਪੂਰੀ ਦਲੀਲ ਹੈ। ਇਹ ਨਹੀਂ ਕਿ ਕੋਈ ਮਾਡਲ ਤੁਹਾਡੀ ਟੀਮ ਨਾਲੋਂ ਵਧੀਆ ਲਿਖਦਾ ਹੈ — ਨਹੀਂ ਲਿਖਦਾ। ਸਗੋਂ ਇਹ ਹੈ ਕਿ ਜਿਸ ਡਰਾਫ਼ਟ ਨੂੰ ਤੁਸੀਂ ਮੰਗਲਵਾਰ ਨੂੰ ਸੋਧਦੇ ਹੋ, ਉਹ ਮੌਜੂਦ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਜੋ ਪੋਸਟ ਤੁਸੀਂ ਲਿਖਣਾ ਚਾਹੁੰਦੇ ਸੀ, ਉਹ ਮੌਜੂਦ ਨਹੀਂ ਹੁੰਦੀ।
ਰੋਡਮੈਪ ਇੱਕ ਅਜਿਹੀ ਯੋਜਨਾ ਹੈ ਜੋ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਲਿਖੀ ਹੋਈ ਹੈ
ਛੇ ਮਹੀਨਿਆਂ ਵਿੱਚੋਂ ਜ਼ਿਆਦਾਤਰ ਪਹਿਲਾਂ ਹੀ ਤੈਅ ਹੈ। ਤੁਹਾਨੂੰ ਲਗਭਗ ਪਤਾ ਹੈ ਕਿ ਅਗਲੇ ਦੋ ਕੁਆਰਟਰਾਂ ਵਿੱਚ ਕੀ ਰੀਲੀਜ਼ ਹੋਵੇਗਾ, ਉਤਪਾਦ ਦੇ ਕਿਹੜੇ ਹਿੱਸੇ ਗਲਤ ਸਮਝੇ ਜਾਂਦੇ ਹਨ, ਕਿਹੜੇ ਇੰਟੀਗ੍ਰੇਸ਼ਨਾਂ ਲਈ ਤੁਹਾਨੂੰ ਲਗਾਤਾਰ ਬੇਨਤੀਆਂ ਮਿਲਦੀਆਂ ਹਨ, ਅਤੇ ਕਿਹੜੇ ਸਵਾਲ ਹਰ ਹਫ਼ਤੇ ਸਪੋਰਟ ਵਿੱਚ ਆਉਂਦੇ ਹਨ।
ਇਹਨਾਂ ਵਿੱਚੋਂ ਹਰੇਕ ਇੱਕ ਥੀਮ ਹੈ। ਰੋਡਮੈਪ ਤਾਲ ਦਿੰਦਾ ਹੈ — ਇੱਕ ਰੀਲਿਜ਼ ਇੱਕ ਚੇਂਜਲੌਗ ਐਂਟਰੀ ਦੀ ਬਜਾਏ ਕਈ ਸਲਾਟਾਂ ਦੀ ਲੜੀ ਬਣ ਜਾਂਦੀ ਹੈ — ਅਤੇ ਸਹਾਇਤਾ ਟਿਕਾਊ ਅੱਧਾ ਹਿੱਸਾ ਦਿੰਦੀ ਹੈ, ਕਿਉਂਕਿ ਮਹੀਨੇ ਵਿੱਚ ਵੀਹ ਵਾਰ ਪੁੱਛਿਆ ਗਿਆ ਸਵਾਲ ਇੱਕ ਵਾਰ ਲਿਖਣ ਯੋਗ ਤੁਕੜਾ ਹੁੰਦਾ ਹੈ ਜਿਸ ਨਾਲ ਹਮੇਸ਼ਾ ਲਈ ਲਿੰਕ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
ਖਾਲੀ ਥਾਵਾਂ ਛੱਡੋ। ਰੀਲਿਜ਼ਾਂ ਪਿੱਛੇ ਜਾਂਦੀਆਂ ਹਨ, ਅਤੇ ਬਿਨਾਂ ਖਾਲੀ ਸਲਾਟ ਵਾਲੀ ਯੋਜਨਾ ਪਿੱਛੇ ਗਈ ਰੀਲਿਜ਼ ਨੂੰ ਅਜੇ ਨਾ ਹੋਂਦ ਵਿੱਚ ਆਈ ਚੀਜ਼ ਬਾਰੇ ਤਿੰਨ ਪੋਸਟਾਂ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀ ਹੈ। ਸਲਾਟਾਂ ਦਾ ਇੱਕ ਚੌਥਾਈ ਹਿੱਸਾ ਖੁੱਲ੍ਹਾ ਛੱਡਣਾ ਕਮਜ਼ੋਰੀ ਨਹੀਂ; ਇਹ ਯੋਜਨਾ ਦਾ ਉਹ ਹਿੱਸਾ ਹੈ ਜੋ ਤੁਹਾਡੀ ਅਸਲ ਸਮਾਂ-ਸਾਰਣੀ ਨਾਲ ਟਕਰਾਅ ਤੋਂ ਬਾਅਦ ਵੀ ਬਚਦਾ ਹੈ।
- 1ਬਲੌਗਕੀ ਜਾਰੀ ਹੋਇਆ ਅਤੇ ਇਹ ਕਿਉਂ ਮੌਜੂਦ ਹੈ। ਪਹਿਲਾਂ ਸਮੱਸਿਆ, ਫਿਰ ਵਿਸ਼ੇਸ਼ਤਾ।
- 2ਫੇਸਬੁੱਕ / ਇੰਸਟਾਗ੍ਰਾਮਇੱਕ-ਵਾਕ ਵਾਲਾ ਸੰਖੇਪ ਰੂਪ, ਉਹਨਾਂ ਲੋਕਾਂ ਲਈ ਜੋ ਕਦੇ ਚੇਂਜਲੌਗ ਨਹੀਂ ਖੋਲ੍ਹਣਗੇ।
- 3ਬਲੌਗਕਿਸੇ ਨੇ ਅਸਲ ਵਿੱਚ ਇਸ ਨੂੰ ਕਿਵੇਂ ਵਰਤਿਆ। ਠੋਸ, ਅਤੇ ਅਸੁਵਿਧਾਜਨਕ ਹਿੱਸੇ ਵੀ ਸ਼ਾਮਲ ਰੱਖਦੇ ਹੋਏ।
- ·ਜੇ ਇਹ ਪਿੱਛੇ ਜਾਂਦੀ ਹੈਸਲਾਟ ਰੀਲਿਜ਼ ਦੇ ਨਾਲ ਖਿਸਕ ਜਾਂਦੇ ਹਨ। ਕੋਈ ਅਜਿਹੀ ਚੀਜ਼ ਦਾ ਐਲਾਨ ਨਹੀਂ ਹੁੰਦਾ ਜੋ ਹਾਲੇ ਮੌਜੂਦ ਨਹੀਂ।
- 4ਬਲੌਗਇਹ ਰੀਲਿਜ਼ ਜਿਸ ਸਹਾਇਤਾ ਸਵਾਲ ਦਾ ਆਖ਼ਰਕਾਰ ਜਵਾਬ ਦਿੰਦੀ ਹੈ, ਇੱਕ ਵਾਰ ਲਿਖਿਆ ਗਿਆ।
ਰੋਡਮੈਪ ਤਾਲ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈਸਹਾਇਤਾ ਥੀਮ ਨਿਰਧਾਰਤ ਕਰਦੀ ਹੈ
ਤੁਹਾਡਾ ਚੇਂਜਲੌਗ ਸਮੱਗਰੀ ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ ਰਸੀਦ ਹੈ।
ਦੋ ਲੇਖਕ, ਕਦੀ-ਕਦੀ ਤਿੰਨ
ਇੱਕ ਜੋ ਉਤਪਾਦ ਦੀ ਵਿਆਖਿਆ ਕਰਦਾ ਹੈ, ਅਤੇ ਇੱਕ ਜੋ ਕੰਪਨੀ ਬਾਰੇ ਗੱਲ ਕਰਦਾ ਹੈ
ਇਹ ਸੱਚਮੁੱਚ ਵੱਖਰੀਆਂ ਆਵਾਜ਼ਾਂ ਹਨ, ਅਤੇ ਇਹਨਾਂ ਨੂੰ ਮਿਲਾਉਣ ਨਾਲ ਉਹ ਖ਼ਾਸ ਫਿੱਕਾਪਣ ਪੈਦਾ ਹੁੰਦਾ ਹੈ ਜਿਸ ਲਈ ਸੌਫਟਵੇਅਰ ਬਲੌਗ ਜਾਣੇ ਜਾਂਦੇ ਹਨ — ਇੱਕ ਪੋਸਟ ਜੋ ਨਾ ਤਕਨੀਕੀ ਵਿਆਖਿਆ ਹੈ ਅਤੇ ਨਾ ਹੀ ਕਿਸੇ ਚੀਜ਼ ਦਾ ਮਨੁੱਖੀ ਬਿਰਤਾਂਤ।
ਤਕਨੀਕੀ ਲੇਖਕ
ਦੱਸਦਾ ਹੈ ਕਿ ਕੋਈ ਚੀਜ਼ ਕੀ ਕਰਦੀ ਹੈ, ਸਹੀ ਢੰਗ ਨਾਲ, ਬਿਨਾਂ ਵਿਸ਼ੇਸ਼ਣਾਂ ਦੇ। ਜਾਣਦਾ ਹੈ ਕਿ ਤੁਹਾਡਾ ਉਤਪਾਦ ਕਿਸ ਲਈ ਹੈ ਅਤੇ ਕਿਸ ਲਈ ਨਹੀਂ, ਅਤੇ ਇਹ ਕਹਿਣ ਦੀ ਇਜਾਜ਼ਤ ਵੀ ਹੁੰਦੀ ਹੈ। ਇਹ ਉਹ ਲੇਖਕ ਹੈ ਜਿਸਦੀਆਂ ਪੋਸਟਾਂ ਸਹਾਇਤਾ ਟਿਕਟਾਂ ਤੋਂ ਲਿੰਕ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ।
ਕੰਪਨੀ ਦੀ ਆਵਾਜ਼
ਫ਼ੈਸਲਿਆਂ, ਸਮਝੌਤਿਆਂ ਅਤੇ ਤੁਸੀਂ ਕਿਸ ਪਾਸੇ ਵੱਧ ਰਹੇ ਹੋ, ਬਾਰੇ ਲਿਖਦਾ ਹੈ। ਇਸ ਦੀ ਲਾਭਦਾਇਕਤਾ ਮਾਪਣਾ ਔਖਾ ਹੈ ਪਰ ਭਰਤੀ ਵਿੱਚ, ਵਿਕਰੀ ਦੀਆਂ ਮੀਟਿੰਗਾਂ ਵਿੱਚ ਅਤੇ ਇਸ ਕਾਰਨ ਵਿੱਚ ਸਾਫ਼ ਦਿਖਦੀ ਹੈ ਕਿ ਕੋਈ ਵੱਡੇ ਵਿਕਰੇਤਾ ਦੀ ਬਜਾਏ ਛੋਟੇ ਨੂੰ ਕਿਉਂ ਚੁਣਦਾ ਹੈ।
ਜਵਾਬ ਦੇਣ ਵਾਲਾ
ਤੁਹਾਡੀ ਨੀਤੀ ਅਨੁਸਾਰ ਟਿੱਪਣੀਆਂ ਸੰਭਾਲਦਾ ਹੈ। ਜੋ ਸੰਭਵ ਹੈ ਉਸਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਜੋ ਸੰਭਵ ਨਹੀਂ ਉਸਨੂੰ ਨਿਸ਼ਾਨਦੇਹ ਕਰਦਾ ਹੈ, ਅਤੇ ਰੋਡਮੈਪ ਬਾਰੇ ਕਦੇ ਅੰਦਾਜ਼ਾ ਨਹੀਂ ਲਗਾਉਂਦਾ। ਸਹਾਇਤਾ ਘਟਨਾ ਵਰਗੀ ਕੋਈ ਵੀ ਚੀਜ਼ ਤੁਰੰਤ ਕਿਸੇ ਵਿਅਕਤੀ ਕੋਲ ਚਲੀ ਜਾਂਦੀ ਹੈ।
ਮਨਜ਼ੂਰੀ ਦਾ ਦਰਵਾਜ਼ਾ ਇੱਥੇ ਸੱਚਮੁੱਚ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ
ਇੱਕ ਬੇਕਰੀ ਲਈ, ਬਿਨਾਂ ਮਨਜ਼ੂਰੀ ਵਾਲੀ ਪੋਸਟ ਇੱਕ ਛੋਟੀ ਸ਼ਰਮਿੰਦਗੀ ਹੈ। ਇੱਕ ਸੌਫਟਵੇਅਰ ਕੰਪਨੀ ਲਈ ਇਹ ਸਹਾਇਤਾ ਬੋਝ, ਵਿਕਰੀ ਦਾ ਇਤਰਾਜ਼, ਜਾਂ ਇੱਕ ਵਾਅਦਾ ਹੈ ਜਿਸ ਨਾਲ ਕਿਸੇ ਨੇ ਸਹਿਮਤੀ ਨਹੀਂ ਦਿੱਤੀ। ਇੱਕ ਡਰਾਫਟ ਜੋ ਕਿਸੇ ਸੀਮਾ ਨੂੰ ਥੋੜ੍ਹਾ ਗਲਤ ਦੱਸਦਾ ਹੈ, ਗਾਹਕ ਤੁਹਾਨੂੰ ਉਹੀ ਵਾਪਸ ਉਦੇ ਕਰੇਗਾ, ਅਤੇ ਇੱਕ ਡਰਾਫਟ ਜੋ ਤਾਰੀਖ਼ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ, ਉਸਨੂੰ ਵਾਅਦਾ ਮੰਨਿਆ ਜਾਵੇਗਾ।
ਇਸ ਲਈ ਇਹ ਉਹ ਸਥਿਤੀ ਹੈ ਜਿੱਥੇ ਆਟੋਪਾਇਲਟ ਨੂੰ ਸਭ ਤੋਂ ਵੱਧ ਸਾਵਧਾਨੀ ਦੀ ਲੋੜ ਹੈ। ਇੱਕ ਢੁਕਵੀਂ ਵਿਵਸਥਾ ਇਹ ਹੈ ਕਿ ਛੋਟੇ ਸੋਸ਼ਲ ਸਲਾਟਾਂ ਉੱਤੇ ਆਟੋਪਾਇਲਟ ਹੋਵੇ ਜੋ ਪਹਿਲਾਂ ਹੀ ਪ੍ਰਕਾਸ਼ਿਤ ਕਿਸੇ ਚੀਜ਼ ਨੂੰ ਦੁਹਰਾਉਂਦੇ ਹਨ, ਅਤੇ ਹਰ ਉਸ ਚੀਜ਼ ਉੱਤੇ ਮਨਜ਼ੂਰੀ ਹੋਵੇ ਜੋ ਉਤਪਾਦ ਬਾਰੇ ਦਾਅਵਾ ਕਰਦੀ ਹੈ। ਕੀਮਤ, ਸਮਰੱਥਾ ਜਾਂ ਤਾਰੀਖ਼ਾਂ ਬਾਰੇ ਕੋਈ ਵੀ ਚੀਜ਼ ਹਮੇਸ਼ਾ ਕਿਸੇ ਵਿਅਕਤੀ ਵੱਲੋਂ ਪੜ੍ਹੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ ਇਹ ਲੇਖਕ ਦੇ ਨਿਯਮਾਂ ਵਿੱਚ ਲਿਖਣਾ ਲਾਭਦਾਇਕ ਹੈ ਤਾਂ ਜੋ ਅਜਿਹੇ ਡਰਾਫਟ ਕਤਾਰ ਵਿੱਚ ਜਾਣ ਦੀ ਬਜਾਏ ਰੋਕੇ ਅਤੇ ਨਿਸ਼ਾਨਦੇਹ ਕੀਤੇ ਜਾਣ।
ਰਿਪੋਰਟ ਇੱਕ ਛੋਟੀ ਟੀਮ ਨੂੰ ਕੀ ਦੱਸਦੀ ਹੈ
ਯੋਜਨਾਬੱਧ ਬਨਾਮ ਪ੍ਰਕਾਸ਼ਿਤ ਹੀ ਉਹ ਅੰਕੜਾ ਹੈ ਜੋ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ, ਅਤੇ ਸੌਫਟਵੇਅਰ ਟੀਮ ਲਈ ਇਹ ਪਹਿਲੀ ਤਿਮਾਹੀ ਵਿੱਚ ਆਮ ਤੌਰ ਉੱਤੇ ਅਸਹਿਜ ਹੁੰਦਾ ਹੈ। ਇਹ ਇਕੱਲਾ ਇਮਾਨਦਾਰ ਮਾਪ ਵੀ ਹੈ ਕਿ ਕੀ ਲਿਖਤ ਦੁਬਾਰਾ ਰੀਲਿਜ਼ ਅੱਗੇ ਹਾਰਨ ਲੱਗੀ ਹੈ ਜਾਂ ਨਹੀਂ।
ਪ੍ਰਾਪਤੀ ਉੰਨੀ ਮਹੱਤਵਪੂਰਨ ਨਹੀਂ ਜਿੰਨੀ ਦਿਖਦੀ ਹੈ। ਇੱਕ ਤਕਨੀਕੀ ਲੇਖ ਆਪਣਾ ਪਾਠਕ ਦਿਨਾਂ ਵਿੱਚ ਨਹੀਂ, ਮਹੀਨਿਆਂ ਵਿੱਚ ਲੱਭਦਾ ਹੈ, ਅਤੇ ਦੂਜੇ ਹਫ਼ਤੇ ਉਸਦਾ ਮੁਲਾਂਕਣ ਕਰਨ ਨਾਲ ਤੁਸੀਂ ਉਹ ਲੇਖ ਹਟਾ ਦੇਵੋਗੇ ਜੋ ਅਸਲ ਵਿੱਚ ਕੰਮ ਆਉਣੇ ਸਨ। ਸ਼ੁਰੂ ਵਿੱਚ ਥੀਮ ਦਾ ਸੰਤੁਲਨ ਵਧੇਰੇ ਲਾਭਦਾਇਕ ਹੈ: ਇਹ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਕੀ ਤੁਸੀਂ ਸਿਰਫ਼ ਜਾਰੀ ਹੋਈ ਚੀਜ਼ ਬਾਰੇ ਹੀ ਲਿਖ ਰਹੇ ਹੋ, ਜੋ ਕਿ ਆਮ ਅਸਫਲਤਾ ਦਾ ਢੰਗ ਹੈ ਅਤੇ ਇਸ ਕਾਰਨ ਹੈ ਕਿ ਇੰਨੇ ਸੌਫਟਵੇਅਰ ਬਲੌਗ ਪੈਰਿਆਂ ਵਾਲੇ ਚੇਂਜਲੌਗ ਵਾਂਗ ਪੜ੍ਹਾਈ ਦਿੰਦੇ ਹਨ।
ਇਮਾਨਦਾਰ ਹਿੱਸਾ: ਜੇ ਤੁਹਾਡਾ ਉਤਪਾਦ ਸੱਚਮੁੱਚ ਤਕਨੀਕੀ ਹੈ, ਤਾਂ ਸਭ ਤੋਂ ਡੂੰਘੇ ਲੇਖਾਂ ਲਈ ਹਾਲੇ ਵੀ ਇੱਕ ਇੰਜੀਨੀਅਰ ਦੀ ਇੱਕ ਦੁਪਹਿਰ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਯੋਜਨਾ ਜੋ ਬਦਲਦੀ ਹੈ, ਉਹ ਇਹ ਹੈ ਕਿ ਉਹ ਦੁਪਹਿਰਾਂ ਸਮਾਂ-ਸਾਰਣੀ ਵਿੱਚ ਆ ਜਾਂਦੀਆਂ ਹਨ ਅਤੇ ਲਿਖਤ ਦਾ ਬਾਕੀ ਅੱਸੀ ਪ੍ਰਤੀਸ਼ਤ ਹਿੱਸਾ ਉਹਨਾਂ ਨਾਲ ਮੁਕਾਬਲਾ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ।