Theory
वह bug जो कभी code में था ही नहीं
Metatech ने एक बार एक billing module ship किया जो GST perfectly calculate करता था, और फिर भी client को furious बना दिया।
क्यों? Client ने analyst को बताया था 'invoice monthly'। Analyst ने लिखा 'generate invoices at month end'। Developer ने इसे calendar month end के लिए बनाया। Client का मतलब था हर customer की signup date से 30 days।
Code की हर line काम कर रही थी। Communication chain 3 में से hop 2 पर fail हुई। कोई debugger इस class के bug को नहीं ढूँढ सकता, और यह industry में सबसे expensive class है।
Theory
Nervous system, small talk नहीं
लोग communication को असली काम के इर्द-गिर्द की pleasantries की तरह imagine करते हैं। एक software team में यह nervous system है: एक codebase पर काम कर रहे 8 brains के एक organism बने रहने का यही एकमात्र तरीका है। Signals stand-ups, tickets, pull-request descriptions और client calls की तरह travel करते हैं। जब nervous system slow या noisy होता है, हाथ coordinate करना बंद कर देते हैं, चाहे हर हाथ कितना भी strong हो।
Theory
Communication एक project के लिए असल में क्या करता है
चार jobs जो एक exam answer को name करने चाहिए:
- Requirement clarity: needs client से analyst तक developer तक travel करती हैं; अच्छा communication हर hop पर degradation से लड़ता है।
- Coordination: कौन क्या बना रहा है, किस order में, किस interface के against; दो लोगों को एक-दूसरे का काम तोड़ने से रोकता है।
- Early risk surfacing: आज के stand-up में ज़ोर से कहा गया एक blocker 1 day cost करता है; छुपाया गया, यह एक sprint cost करता है।
- Stakeholder trust: clients उन delays को tolerate करते हैं जिनके बारे में उन्हें जल्दी पता चले; वे silence पर छोड़ देते हैं।
At a glance
Project management communication instruments पर चलता है; हर एक की अपनी failure signature है।
| Project Activity | Communication Instrument | Failure कैसा दिखता है |
|---|---|---|
| Daily coordination | Stand-up meeting, time-boxed | दो developers एक हफ़्ते तक conflicting changes बनाते हैं |
| Task tracking | Clear descriptions वाले tickets | काम दो बार होता है, या बिल्कुल नहीं, कोई sure नहीं |
| Code review | Pull-request description और comments | Reviewers intent guess करते हैं, defects slip through होते हैं |
| Client relationship | Status reports, demos, early bad news | Delivery पर surprise, trust destroy |
Quiz
एक Metatech developer Monday को discover करता है कि जिस API पर उसका module depend करता है वह 2 weeks delay होगा। Sprint review Friday को है। उसे क्या करना चाहिए?
- इसे बिल्कुल अगले stand-up में raise करना ताकि plan तुरंत adjust हो सके
- Friday के sprint review का इंतज़ार करना, क्योंकि वह official reporting meeting है
- किसी को बताए बिना चुपचाप एक workaround बनाना शुरू करना, resourceful दिखने के लिए
- इसका ज़िक्र सिर्फ़ तभी करना जब project manager सीधे उसकी progress के बारे में पूछे
Show the answer
इसे बिल्कुल अगले stand-up में raise करना ताकि plan तुरंत adjust हो सके
Blockers हर silent day के साथ value खोते हैं: Monday को raise किया गया, team re-plan कर सकती है, tasks swap कर सकती है, या dependency negotiate कर सकती है; Friday को discover किया गया, एक हफ़्ता पहले ही lost है। Official meeting का इंतज़ार करना, workaround के पीछे छुपना, या सिर्फ़ पूछे जाने पर answer देना सब diligence के रूप में dressed silence है, और silence project communication की सबसे expensive habit है।
Think first
Requirements degrade क्यों होते हैं?
Client ने कहा 'invoice monthly' और calendar-month billing मिली जो उन्होंने कभी नहीं चाही। पहले सोचिए: client से analyst तक developer तक travel करते हुए meaning क्यों degrade होता है?
Show the answer
क्योंकि हर hop एक translation है। Client business intentions में बोलता है, analyst requirement language में लिखता है, developer implementation terms में पढ़ता है, और हर translation चुपचाप missing details के लिए अपनी assumptions substitute करता है। किसी ने झूठ नहीं बोला और कोई careless नहीं था; ambiguity ने बस हर hop पर gaps अलग तरह से भर दिए। Defence है communication discipline: जो आप समझे वह restate कीजिए, examples दिखाइए ('तो एक customer जो 14th को sign up करता है उसे 14th को bill किया जाता है?'), और बनाने से पहले लिखित में confirm कीजिए।
Watch out
'Communication overhead है' वाला trap
Classic junior mistake: meetings, tickets, और documentation को coding के असली काम में interruptions मानना। फिर एक un-communicated API change team को एक हफ़्ता cost करता है, उस महीने के सारे stand-ups मिलाकर से भी ज़्यादा। Exams में, कभी मत लिखिए कि communication 'development time waste करता है'; लिखिए कि un-communicated काम rework बनाता है, और rework असली overhead है।
Theory
यह thread आगे कहाँ जाता है
यह unit अब practical होता है: conflicts और disagreements resolve करना (अगला topic), remote और distributed teams में communicate करना, rapport और cohesion बनाना, और आख़िर में automation और AI teams किस बारे में communicate करते हैं यह कैसे बदलते हैं। आप BCA202-02 में management view से मिले; यहाँ आप software team के अंदर हैं बाहर देखते हुए।
Summary
Key takeaways
- सबसे expensive project failures communication failures हैं, code failures नहीं।
- Communication के चार jobs: requirement clarity, coordination, early risk surfacing, stakeholder trust।
- हर project-management artifact (stand-up, ticket, PR description, status report) एक communication instrument है।
- Requirements हर hop पर degrade होते हैं क्योंकि हर translation gaps को अलग assumptions से भरता है; restate और confirm कीजिए।
- तुरंत raise किए गए blockers days cost करते हैं; छुपाए गए blockers sprints cost करते हैं।
- Memory hook: code compile होता है, team को भी होना चाहिए।