Other Aspects in
Software Engineering
Week 11 · Dr. Sridhar Iyer (IIT Bombay) · Dr. Prajish Prasad (FLAME University)
Sab roles isi ek cheez ke liye exist karte hain — circle pe click karke seedha us role pe jao
Week 11 kya hai?
Ab tak course ne poora technical side cover kiya — requirements, user studies, design, development, coding, testing. Week 11 usse aage ka hissa hai: non-technical / human side. Yaani communication, collaboration, team roles aur woh skills jo ek engineer ko "great" banati hain.
Sridhar sir ka point simple hai — ye skills technical skills se kam important nahi hain. Software ek aadmi ka kaam nahi hai, team effort hai, aur usme client se lekar developers, marketing, sales tak sabke saath coordination chahiye.
Software Organizations
Company me kaun-kaun se roles hote hain aur har role karta kya hai.
Communication, Collaboration & Productivity
Conceptual integrity, knowledge sharing tools, aur productivity ka sahi matlab.
What Makes a Great Software Engineer?
ICSE research ke findings + rational decision making process.
Software company me kaun kya karta hai
Purpose of a software company = provide value to potential users of the software system. Sirf product banana purpose nahi hai. Software ek means to an end hai — jo software koi use hi nahi karta, woh koi value provide nahi karta.
Isi wajah se teams ke beech aur team ke andar smooth communication zaroori hai. Ek software organization me log alag-alag roles lete hain taaki customer tak ye value pahunche.
Reflection Spot (slide 4): "Imagine tum Amazon Seller Portal bana rahe ho — design, development, testing, maintenance ke alawa aur kaunse roles chahiye?"Marketing Team
Market me opportunity dhundhta hai — "value kahan de sakte hain?"
- Market me opportunities dhundhna — value kahan provide kar sakte hain
- Market research karna, audiences identify karna
- Dekhna ki kis type ke solutions ki zarurat hai
- Company ko promote karna + services/products customers ko sell karna
- Audience tak communicate karne me important role
Product Managers
Business + Technology + UX — teeno ka intersection. "You are here."
Business side:
- Marketing aur sales teams ke saath closely kaam
- Business goals samajhna — product ROI (return on investment) kaise maximise karega
Technology side:
- Code likhna zaroori nahi, par technology stack pata hona chahiye
- Level of effort samajhna — kitna kaam lagega
- Important technical decisions lena
User Experience side:
- User ke liye passionate — user actually chahta kya hai
Teeno needs balance karke hard decisions aur trade-offs lene padte hain.
Designers
Requirements ko solutions me convert karte hain.
- UX / UI roles
- Requirements ko solutions me transform karna
- Decide karna ki software value kaise provide karega
- Users se baat karna, prototypes banana
- Design ke multiple revisions hote hain
Software Engineers
Requirements implement karte hain — par decide nahi karte ki kya banega.
- Team ke doosre logon ke saath code likhna taaki requirements implement ho
- Requirements PM aur designers se aati hain
- Software engineers usually decide nahi karte ki kaunsa product banega ya product kaunsi problem solve karega
- Ye decisions PM aur designers lete hain — ye medium aur large companies me hota hai
- Startups / chhoti teams me ye roles ek me mil jaate hain, tab engineers bhi decide kar sakte hain
Engineering Managers
Aka Project Manager. Levels ke beech information ka pul.
- Large organizations me higher aur lower parts ke beech information transmit karna
- Isko project manager bhi kehte hain
- Work organize aur prioritize karna
- Schedule manage karna, resources identify karna
- Different teams ke beech coordination
- Engineers ke beech interpersonal conflict resolve karna
Sales Team
Product bechta hai + user feedback wapas laata hai.
- Jo users marketing team ne identify kiye, unko product sell karna
- Marketing, product aur design teams ko feedback dena
- Feedback me: users kya keh rahe hain, next version me kya chahiye, kaunse additional features maange gaye
- Ye feedback phir engineers next development cycle me address karte hain
Support Team
Level-1 → Level-2 escalation. Users ki problems solve karta hai.
- Clients ki problems resolve karna — helplines, chatbots, email, chat, phone
- Kabhi-kabhi query answer karne ke liye documentation check karni padti hai
- Level-1 support — commonly asked queries / FAQs handle karta hai
- Jo Level-1 handle na kar sake, woh Level-2 pe escalate hota hai, aur aage bhi
- Product, design aur engineering teams ko defects/shortcomings ka feedback dena
Data Scientists
Naya-naya prominent hua role. Data se better decisions.
- Different teams aur users se generate hua data analyze karna
- Organization ko better decisions lene me help karna
- Marketing team ko business data analyze karne me help
- Sales targets track karna
- Engineers ko app usage patterns samajhne me help
- In insights se future releases aur company ki direction decide hoti hai
Ethics & Policy Specialists
Law / social science / policy background wale log.
- Background: law, social science, policy
- Terms of service, software licenses, privacy policy shape karte hain
- Har us company ke liye important jo data ke saath kaam karti hai
- Khaaskar jo large scale pe data handle karti hai, ya jiska software misuse ho sakta hai
Product Manager ka famous Venn diagram
PM ko teeno circles balance karne padte hain — isliye trade-offs unavoidable hain
Engineers ke liye sirf apne kaam pe focus karna kaafi nahi hai. Alag-alag roles ke bahut saare logon ke saath kaam karna padta hai, doosron ka perspective consider karna padta hai, aur achhe se communicate + collaborate karna padta hai.
Reference: Cooperative Software Development — Dr. Amy J. Ko, University of Washington, Chapter 2: Organizations.
Baat karna hi asli skill hai
Badi teams me communication systematically aur frequently karna zaroori hai. Kyunki sab log milkar ek product bana rahe hain — sabke paas ek hi joint vision hona chahiye, chahe kaam kitne bhi logon me distribute ho.
Conceptual Integrity = team ke har member ka same understanding ho ki kya banaya jaa raha hai aur kyun banaya jaa raha hai.
Ise ensure karne ka ek hi tareeka hai — effective communication, teams ke beech aur team ke andar.
Cross-disciplinary collaboration & open mind
- Agar aap aisi domain ka software bana rahe ho jisme aapki expertise nahi hai, to domain experts ke saath collaborate karna padega
- Hum apne hi ideas se attached ho jaate hain — "code aise hi banega". Ye galat hai
- Mechanical engineers, electrical engineers, artists — sabke input ke liye open-mindedness chahiye
- Unhe code-related constraints batana bhi zaroori hai, kyunki user kabhi-kabhi aisi functionality maang leta hai jo programming support hi nahi karti
Marketing aur sales teams ko pata hona chahiye ki software kya kar sakta hai aur kya nahi. Unhe client se aise features promise nahi karne chahiye jo development team bana hi nahi sakti, ya jinko banana bahut expensive hoga. Isliye marketing/sales ko development team se interact karte rehna chahiye.
Engineers communicate kaise karte hain?
Simplest — colleague ke desk pe jaakar baat karna, email karna, ya messaging platforms / social media pe chat karna. Par main reason hota hai information lena — requirements ke baare me, code ke baare me.
Aasan information
"Ye function code me kahan hai?" → IDE khud bata dega.
Mushkil information
"Ye line of code likhi kyun gayi thi?" → jisne likhi thi usi se poochna padega.
Knowledge Sharing Tools
Documents share karna aur decisions archive karna. Kyunki kisi ke reply ka wait karna, khud dhoondhne se slow hai. Bottlenecks: reply aane me time lagega, ya developer abhi available hi nahi hoga.
Issue Tracker
JIRA, Pivotal Tracker. Different issues, user stories aur requirements track karte hain — saath me history ki kis-kisne un issues pe kaam kiya.
GitHub / GitHub Pages
Bahut saari libraries aur frameworks GitHub pe host hoti hain (e.g. Vue.js), aur unke GitHub Pages pe documentation hoti hai.
Slack
Specific purposes ke liye channels bana sakte ho, aur specific team members se directly communicate kar sakte ho.
Stack Overflow
Jo issue face kar rahe ho usko resolve karne me help karta hai, aur additional learning resources ke links bhi deta hai.
Documentation zaroori kyun hai?
- Ek project ka knowledge doosre project me kaam aa sakta hai — bas properly documented aur archived hona chahiye.
- Jab log organization chhod dete hain, unka specialized knowledge unke saath chala jaata hai. Agar aisa banda development ke beech me chhod ke jaaye, to koi uski jagah nahi le paata — progress ruk jaati hai.
Cross-training — developers ko projects ke beech rotate karna, taaki project maintain karne ke liye jo knowledge chahiye woh multiple engineers me distributed ho jaaye.
Productivity — ka matlab kya hai?
Traditional definition
Ek given time me kitna work done hua. Simple.
Software me ye kaam nahi karta
SE me work quantify karna mushkil hai — ye lines of code ki sankhya nahi hai, kyunki hum collaboratively ek system bana rahe hain.
Maan lo tumne apne assign kiye hue features deliver kar diye, par baaki requirements ignore kar diye, doosre team members se interact nahi kiya, apne modules ke doubts clarify nahi kiye. Ye ek individual ke liye efficient lagta hai — par poori team ki productivity ko nuksaan pahunchata hai.
Productive kaise bane? — Right Tools
Project management tools
Team ke sabhi members ko project ka big picture bhi milta hai aur progress ka detailed view bhi.
e.g. JIRA, Pivotal Tracker
Development tools
IDEs aur unke features developers ko zyada productive banate hain.
Ek normal work day me engineers ko meetings attend karni padti hain, emails ka jawab dena padta hai, aur doosre non-work activities aati hain. Individual perspective se ye distractions lagte hain — "mujhe bas code karna hai, ye meetings kyun".
Par ye meetings zaroori hain — inhi se sabke paas shared vision aati hai aur confirm hota hai ki jo client ne maanga hai wahi ban raha hai.
Communication team ki productivity ka key aspect hai. Chahe desk pe jaakar baat karo, text karo ya email — communication precise aur unambiguous honi chahiye, taaki dono ka understanding same ho.
Reference: Cooperative Software Development — Dr. Amy J. Ko, Chapter 3: Communication, Chapter 4: Productivity.
Research kya kehti hai
Ye koi opinion nahi hai — ispe actual research hui hai. Paper ka naam bhi wahi hai: "What Makes A Great Software Engineer?" by Paul Luo Li, Amy J. Ko, Jiamin Zhu, published at the 2015 IEEE/ACM 37th International Conference on Software Engineering (ICSE).
Researchers ne semi-structured interviews kiye — kuch architect-level engineers ke saath jinke paas 25+ saal ka experience tha. Findings ko 4 buckets me samjho:
Competent Coder
Sabse obvious aur sabse zaroori. Chahe UI accha ho, documentation accha ho, sales aur marketing achhe hon — agar product ki quality kharab hai aur bugs bhare hain, to software bikega nahi. Clean aur modular code, effective coding & design principles. Behtar hone ka tareeka = practice karte raho.
Decision Making
Accha code likhna necessary hai par sufficient nahi. Great engineers achhe decisions lete hain — aur ek rational decision making process follow karte hain (neeche detail me).
Interactions with Teammates
Doosron ke saath shared understanding banana. Complex abstract concepts ko non-technical logon (sales, marketing, end users) ko samjhana. Sirf clearly bolna nahi — communication ka level adjust karna, jargon avoid karna, par phir bhi sahi understanding dena.
Personality Traits → Continuous Learning
Field bahut fast change hoti hai — languages, dev environments, collaboration ke tareeke, naye tools. Great engineers curious hote hain, hamesha samajhne ki koshish karte hain, doosron se poochte hain, aur apna knowledge continuously update karte hain.
Macro vs Micro Decisions
Macro decisions
Design aur architecture level pe.
e.g. kaunsi libraries / frameworks use karni hain, kaunsa architectural style.
Micro decisions
Ek particular module ke level pe.
e.g. kaunse algorithms use karein, kaunse data structures.
Rational Decision Making Process
Ye 5 steps order me yaad karo — sequence pe question aa sakta hai.
Identify the decision to be made
Pehle ye clear karo ki decision lena kya hai.
Systematically identify alternatives
Sabhi options ko systematically list karo — randomly nahi.
Think through potential outcomes
Har alternative ka result kya nikalega, woh socho.
Evaluate which outcome is best for the given context
"Best" absolute nahi hota — context pe depend karta hai.
Make a decision
Ab decision lo.
- Achhe decision ka pehla step hai saari zaroori information gather karna
- Isme open-mindedness chahiye — jo information mile uske hisaab se apne preconceived notions chhodne ki willingness
- Team ke andar ya bahar doosron se help maangna bhi isi ka part hai, taaki information adequate ho
Continuously update kaise karein?
- Specific websites aur forums follow karna
- Blogs padhna — jo log dusron ko educate karne ke liye likhte hain
- Conferences attend karna — academic conferences me naye developments aur novel tools ke prototypes / proof of concepts pehli baar dikhaye jaate hain
- ICSE ek well-recognized conference hai; iska ek track software engineering education pe bhi hai (SE kaise seekhein / kaise sikhaayein)
Poore course ka summary
Software Processes
Software development me use hone wale different processes.
Tools
Requirements capture, software planning, development aur testing ke liye tools.
Code
Code kaise organize karein, clean aur effective code likhne ki best practices.
Teams
Team me effectively kaise kaam karein — projects ke through iska flavour mila.
Alag organizations, industries aur teams software banane ke alag tareeke use karti hain — jo course se thoda different ho sakta hai. Ye bada issue nahi hai, jab tak process ka conceptual understanding clear ho. Basic process pretty much sab follow karte hain, bas details alag hoti hain (koi X tool, koi Y tool; koi spec ek tarah likhta hai, koi doosri tarah).
Aur last — ye fast moving field hai, isliye continuously learn karte raho aur updated raho.
Ab khud test karo
Ye 18 questions Week 11 ke lectures aur slides ke content se banaye gaye hain, IITM graded assignment ke style me (MCQ + MSQ). Option pe click karo — turant pata chal jaayega sahi hai ya galat, aur explanation bhi milegi.