काम को छोटे हिस्सों में बाँटना
(jacobian.org)- Project estimation या delegation की शुरुआत “इसे बनाना है” जैसे बड़े अनुरोध को स्पष्ट task list में बदलने से होती है, और हर item में वांछित बदलाव और completion state साफ दिखनी चाहिए
- breakdown की प्रक्रिया में idea, sketch या शुरुआती list से ज़रूरी steps लिखे जाते हैं, और जब तक हर item पर्याप्त रूप से define न हो जाए, उसे recursively और छोटे हिस्सों में बाँटा जाता है
- outdoor activities के लिए streak tracker का उदाहरण धीरे-धीरे data model, calendar view, activity logging, streak calculation और streak freeze में बँटता है, साथ ही uncertain points भी सामने आते हैं
- “पर्याप्त रूप से defined task” वह स्थिति है जिसमें desired change, completion कैसा दिखेगा, completion तक के सभी steps, और तुरंत शुरू करने के लिए ज़रूरी जानकारी—इन सब पर हाँ कहा जा सके
- task breakdown एक skill है जिसमें experience-based pattern matching चाहिए, इसलिए beginner teams को planning आज़माने और feedback पाने के लिए सुरक्षित practice opportunities चाहिए
बड़े project को task list में बदलना
- Project estimation पर पिछली चर्चाएँ यह मानकर चलीं कि पहले से स्पष्ट task list मौजूद है, लेकिन असल field में उससे पहले वाला step—task breakdown—पहले ज़रूरी हो सकता है
- task breakdown बड़े project को उसके component tasks में बाँटने की प्रक्रिया है, और estimation या delegation के लिए “यह चित्र बनाना है” जैसे single task से अधिक granular units चाहिए
- अगर यह अकेले किया जा रहा personal project है, तो sketch ही काफी हो सकता है; लेकिन किसी और को सौंपना हो या timeline estimate करनी हो, तो detail level बढ़ाना पड़ेगा
उदाहरण: personal streak tracker
- outdoor activity किए गए दिनों को track करने वाला personal streak tracker उदाहरण के तौर पर इस्तेमाल किया गया है
- Streaks app जैसा रूप चाहिए
- running, cycling, skiing जैसी outdoor activity options जोड़ना चाहते हैं
- Duolingo का streak freeze feature भी शामिल करना चाहते हैं
-
पहला दौर: sketch से शुरुआत
- visual mockup यह समझाने के लिए अच्छा starting point है कि कौन-सा feature बनाना है
- अगर project अकेले बना रहे हों, तो इस स्तर के sketch से सीधे code लिखना भी शुरू किया जा सकता है
- अगर मकसद estimation या delegation है, तो “यह चित्र बनाना है” से अधिक छोटे-छोटे tasks की list चाहिए
-
दूसरा दौर: बड़े feature units में बाँटना
- पहली breakdown में project को मोटे-मोटे components में बाँटा जाता है
- data modeling
- current week की dates दिखाने वाला calendar view
- icons पर click करके activity record करने और उस date को streak tracking में complete mark करने वाला interactive calendar
- current streak length calculate और display करना
- streak freeze implement करना
- उदाहरण को सरल रखने के लिए deployment, database setup जैसे operational tasks बाहर रखे गए हैं
- वास्तविक projects में, खासकर जहाँ कई लोग शामिल हों, deployment, frontend, backend tasks को अलग items में बाँटना अधिक उपयुक्त होगा
- सिर्फ इस step से भी कुछ हद तक estimation संभव है, लेकिन freeze accumulation/tracking method, past records, activity types add/delete करने जैसी uncertainties बची रहती हैं
-
तीसरा दौर: completion criteria दिखें, इसके लिए और बाँटना
- data model को activity types, recorded activities, freezes और streaks में बाँटा जाता है
- activity types के लिए run/bike/ski/climb जैसी hardcoded list पर्याप्त है
- recorded activity में date और type होता है
- freeze में earned date और used date होते हैं
- streak में start date, end date और activity type-wise aggregate information होती है
- static calendar view को weekly view, home screen, monthly view, navigation और date jump input में बाँटा जाता है
- date jump के लिए complex fuzzy date input के बजाय HTML5 date widget इस्तेमाल किया जा सकता है
- dynamic weekly calendar monthly view में dynamic input नहीं जोड़ता, बल्कि किसी specific date पर activity type click करने से completion record छोड़ता है
- streak calculation और display activity records को scan करके streak calculate करते हैं, current streak को UI में दिखाते हैं, और UI में activity record होने पर streak फिर से calculate करते हैं
- streak freeze में accumulation, duplicate accumulation prevention, UI में use और remaining count display तक शामिल है
- freeze earn करने का criterion X days फिलहाल hardcode किया जा सकता है
- freezes अगले streak में carry over हो सकते हैं
- past activities edit करके streak recalculate करते समय freezes दोबारा मिलने वाली duplicate accumulation को रोकना होगा
बार-बार लागू की जाने वाली breakdown प्रक्रिया
- task breakdown एक बार में खत्म होने वाली design नहीं, बल्कि iterative process है
- task list या एक बड़े project से शुरुआत करें
- उस task को पूरा करने के लिए ज़रूरी steps सोचकर लिखें
- check करें कि हर step पर्याप्त रूप से defined है या नहीं
- अगर पर्याप्त नहीं है, तो उस item को फिर से break down करें
- हर iteration का complete या accurate होना ज़रूरी नहीं; पिछली list से थोड़ा भी अधिक expanded हो जाना काफी है
- जब तक सभी tasks पर्याप्त रूप से defined न हो जाएँ, वही process दोहराएँ
“task” और “पर्याप्त रूप से defined” होने के criteria
- software development और project estimation में task काम की ऐसी unit है जो पर्याप्त रूप से defined, complete हो, और कोई change deliver करे
- “work on stuff” task नहीं है, क्योंकि requirements की outline ही नहीं है
- “पेड़ काटना” complete task नहीं है अगर आपने सिर्फ chainsaw लाया है
- work context में task तभी meaningful है जब उसे करने के बाद कुछ बदलता हो
- task पर्याप्त रूप से defined है या नहीं, यह इस बात से तय होता है कि worker नीचे दिए सवालों में सभी का जवाब “हाँ” दे सकता है या नहीं
- क्या आप समझते हैं कि desired change क्या है
- क्या आप समझते हैं कि “done” कैसा दिखेगा
- क्या आप completion तक के सभी required steps define कर सकते हैं
- अगर blockers या dependencies न हों, तो क्या आपके पास अभी तुरंत शुरू करने के लिए सारी ज़रूरी जानकारी है
- organizational context के हिसाब से project manager, key stakeholders, auditors जैसे observers को भी इन सवालों पर “हाँ” कह पाने की ज़रूरत हो सकती है
- bug fix जैसे tasks में ऐसे unknowns हो सकते हैं जिन्हें और छोटा करना मुश्किल हो
- ऐसे मामलों में timeboxing जैसी techniques इस्तेमाल की जा सकती हैं
experience से बनने वाली breakdown sense
- task breakdown एक skill है जिसे practice चाहिए, और शुरुआत में यह आसान न लगे तो वह सामान्य है
- उदाहरण में data modeling को पहले रखने की वजह कोई clear algorithm नहीं, बल्कि experience-based intuition है
- समान tools बनाते समय data model पहले तय करने पर काम बेहतर चला था
- Django model-data-first flow के साथ बेहतर fit होने वाली affordance देता है
- अगर आपने कई projects देखे या किए नहीं हैं, तो starting point तय करना मुश्किल हो सकता है
- team को यह capability विकसित करनी हो, तो safe environment में project plans बनाने, breakdown करने और feedback लेने का मौका चाहिए
- अगर initial plan काफी गलत भी हो, लेकिन सज़ा न दी जाए, तो वही mistakes अगली बार की pattern matching में इस्तेमाल होने वाला experience data बन जाती हैं
example project का estimation result
- bonus estimation में tasks को छोटे हिस्सों में बाँटने के बाद complexity, uncertainty, expected days और worst-case days जोड़े जाते हैं
- कुल expected estimate 15.5 days, और worst case 23.5 days calculate हुआ
- major items में streak calculation और freeze accumulation medium complexity और moderate uncertainty के साथ हर एक के लिए expected 3 days, worst case 4.5 days हैं
- freeze duplicate accumulation prevention small complexity है, लेकिन extreme uncertainty के कारण expected 1 day और worst case 5 days रखा गया
- असल में यह करीब बारह evenings और एक लंबी flight में पूरा हुआ, लेकिन design को काफी हद तक skip किया गया था और freeze algorithm में ऐसे bugs होने की संभावना है जो बाद में सामने आएँगे
1 टिप्पणियां
Hacker News की राय
पहली, असल steps को planned तरीके से आखिर तक पूरा करना मेरे साथ बहुत कम हुआ है। कुछ steps के बाद ही कुछ नया समझ आ जाता है, कोई छूटी हुई चीज़ मिल जाती है, या कोई आसान तरीका दिख जाता है, इसलिए plan follow नहीं होता
दूसरी, बनाने का तरीका सोचने वाली creative effort पूरी शुरुआत में ही जमा हो जाती है, इसलिए मुझे इस तरह काम करना पसंद नहीं। बाकी हिस्सा अब भी काम का ज़्यादातर भाग होता है, लेकिन सिर्फ सबसे boring हिस्सा बचता है; creativity और boring work को ज़्यादा बराबरी से मिलाना अधिक मज़ेदार होता है, इसलिए तेज़ भी होता है और नतीजा भी बेहतर आता है
दोनों शायद जुड़े हुए हैं, और यह भी असंभव नहीं कि मुझे ADHD हो
अगर आप अपना project explore या build कर रहे हैं और accountability की कोई खास structure नहीं है, तो जब तक आपको planning खुद पसंद न हो, इतना plan करने की ज़रूरत नहीं
लेकिन जैसे ही boss पूछता है, “कितना समय लगेगा? कौन क्या करेगा? कहाँ से शुरू करेंगे?”, किसी framework की ज़रूरत पड़ जाती है
मुझे भी arbitrary या बहुत rigid systems के हिसाब से ढलना पसंद नहीं, लेकिन system simple और flexible होना चाहिए, और productivity systems लोगों की मदद के लिए होते हैं
लगता है लेखक ने इसे किसी detailed recipe की तरह नहीं, बल्कि अपना approach दिखाने के लिए लिखा था ताकि दूसरे लोग अपने ideas निकाल सकें
“plan कभी वैसा follow नहीं होता” से भी बुरा हो सकता है। execution के दौरान अगर tasks जोड़ते रहें, तो अंत में वे planning के समय बने tasks के साथ मिलकर ऐसे incomplete tasks की बिखरी list छोड़ देते हैं जिनकी अब ज़रूरत ही नहीं रहती
क्योंकि ऐसे tasks execution के दौरान बनने वाले पूरे context के बिना बनाए गए थे
programming का मज़ा इसमें है कि यह flexible और flow में चलने वाली creative activity है। आप आगे बढ़ते हुए बनाते हैं और उसे organically experience करते हैं
work environment में monitoring और accountability चाहिए होती है, इसलिए यह organic nature अक्सर हटा दिया जाता है
अगली बार वही या मिलता-जुलता काम plan करते समय future plan बेहतर होगा
project managers के पास भी slogan होता है: “planning में fail हुए तो failure plan कर रहे हैं”
क्योंकि याद रखने वाली ढेरों चीज़ों के बीच मैं अक्सर चीज़ें miss कर देता हूँ
plan बस future self को यह याद दिलाने का तरीका है कि past self ने ideal outcome क्या सोचा था। लगातार plan बदलते हुए जुगनुओं के पीछे भागने के बजाय
“task breakdown” इतना बड़ा विषय है कि यह किताबों या podcasts की genre बन सकता है। self-improvement या organization से जुड़ी किताबों में अक्सर task को तोड़ने की activity को ऐसा माना जाता है जैसे readers में पहले से मौजूद कोई मूलभूत मानवीय क्षमता हो
लेकिन मेरे अनुभव और group sessions में सुनी बातों के अनुसार, task breakdown बहुत कठिन है और avoidance या despair पैदा कर सकता है
मैंने जो सबसे broadly applicable सलाह देखी है, वह यह है कि task को तब तक और छोटे हिस्सों में तोड़ते रहें जब तक आपको 90% भरोसा न हो जाए कि आप उसे सफलतापूर्वक पूरा कर सकते हैं। यह confidence level self-trust और risk-taking tendency पर निर्भर करता है, इसलिए कुछ लोग लगभग 70% success probability तक भी तोड़ सकते हैं
एक दिन में usable time लगभग 6 घंटे होता है, लेकिन अगर कोई confidently कहे कि “आधा दिन” लगेगा और आप उसे बताएं कि इसका मतलब लगभग 3 घंटे है, तो वह अचानक बहुत कम confident हो जाता है या नाराज़ हो जाता है। और 3 दिन बाद भी वह वही कर रहा होता है
यह तरीका time estimation में आश्चर्यजनक रूप से accurate रहा, लेकिन कुल मिलाकर; individual estimates बहुत गलत निकले
अंततः यह probability estimate ही है। बहुत सारी events के बाद average converge कर जाता है
समस्या जिसे ज़्यादातर लोग नहीं जानते, यह है कि software development सबसे बढ़कर एक creative activity के करीब है। बेशक इसके गंभीर technical पहलू हैं, लेकिन problem खुद virtual होती है और civil engineering की तरह real-world constraints से बंधी नहीं होती, इसलिए एक fixed optimal solution नहीं होता
problem को ठीक से देखने से पहले solution define करने की कोशिश करने पर आप सिर्फ final output को सीमित कर देते हैं। ज़्यादातर exploration असल में coding शुरू करने के बाद ही होती है
software में final output और time का clearly defined न होना इतना महत्वपूर्ण नहीं है, क्योंकि per-unit cost नहीं होती। software engineering background न रखने वाले managers इसे ठीक से नहीं समझते
general-purpose product बिना extra development cost के कई customers को बेचा जा सकता है
लेकिन चूँकि ज़्यादातर companies factory की तरह operate करती हैं, इसलिए सारी processes अंततः किसी specific customer को target करने वाला बहुत limited product बनाती हैं। बड़ी tech companies ने ठीक इसी चीज़ से बचा
लगता है पूरी industry ने यह pattern स्वीकार कर लिया है
लेकिन सच कहूँ तो मुझे लगता है कि हममें से ज़्यादातर लोगों को रोकने वाली चीज़ उल्टे ऐसा न करने की क्षमता की कमी है। अगर कोई चीज़ बनानी है, तो हर टुकड़े को plan मत कीजिए; बस वह सबसे छोटी चीज़ बना दीजिए जिसमें value हो सकती है
उदाहरण के लिए “Today” screen और 4 buttons से शुरू कर सकते हैं। रोज़ दबाने के लिए exercise के 4 buttons दिखाना आप आज बना सकते हैं। streak, freeze, calendar view की ज़रूरत नहीं
वे ideas अच्छे हैं और बाद में करेंगे, लेकिन पहले momentum चाहिए। कुछ दिनों बाद आप यह भी तय कर सकते हैं कि वह calendar view आपको पसंद नहीं है
ज़्यादा प्रोजेक्ट्स में “छोटा ही सही, बस कर दो” वाली धक्का देने की ज़रूरत होती है। आज खत्म करो, और उस बिंदु पर देखो कि अगला काम क्या है। इसकी काफी संभावना है कि यह planning stage में सोची गई चीज़ से अलग होगा
बेशक यह भी आसान नहीं है। सबसे छोटी चीज़ ढूँढने और भटके बिना release करने का निश्चय करने के लिए सोच और discipline चाहिए। फिर भी इसका अभ्यास करने लायक है
अनिश्चितता का सामना हो तो “अगला सही काम” पर ध्यान देना चाहिए, यही principle है [0]
मेरा मतलब इसे मामूली दिखाने का नहीं है। अगला सही काम क्या है, यह पता लगाना कठिन है, और मेरी नज़र में planning का सबसे valuable हिस्सा है
0: https://en.wikipedia.org/wiki/The_Next_Right_Thing#Synopsis
उदाहरण के लिए, एक व्यक्ति test के लिए comparison method बनाए, दूसरा एक approach आज़माए, कोई और दूसरी approach, तीसरा एक और approach आज़माए, और तय अवधि के बाद सभी का evaluation हो
बेशक इसका मतलब तभी है जब पहले से कोई preferred approach या स्पष्ट रूप से superior approach न हो
असली development में modularization parallelization का तरीका हो सकता है। जैसे हर व्यक्ति या team एक component संभाले
अपने काम में, खासकर जब दिशा अभी समझ रहा होता हूँ, मुझे user-facing हिस्से और technical internals के बीच बारी-बारी से आगे बढ़ना पसंद है। उपयोग क्या होगा यह जाने बिना सिर्फ technology develop करने से usable तरीका एक खास दिशा में force हो जाता है, और technology जाने बिना सिर्फ interface design करने में भी pitfalls हैं
लेकिन research जैसे कामों में, जहाँ पहले से न जान सकने वाली चीज़ों को validate करने के लिए creative experiments और concept proof चाहिए, वहाँ work breakdown खुद ही टूट जाता है
इसलिए मेरी आदत बन गई है कि अधिकांश concept proof work निजी तौर पर करूँ और किसी को न बताऊँ
अगर अच्छा चला तो public कर सकते हैं, और अगर नहीं चला तो शर्मिंदा हुए बिना, या यह confirm होने के बाद भी कि इसे जारी नहीं रखना चाहिए, “किसी तरह इसे बना दो” सुनने के बजाय उसे discard करके आगे बढ़ सकते हैं
कह सकते हैं, “X की जाँच पर 3 घंटे, Y पर 3 घंटे, Z पर 3 घंटे लगाते हैं, और फिर आगे क्या करना है इस पर planning meeting करते हैं”
नतीजे चार होंगे। पहला हल कर दे, दूसरा हल कर दे, तीसरा हल कर दे, या कोई भी हल न कर पाए
अगर समस्या थोड़े effort से हल हो सकती है, तो दूसरे प्रयास, यानी 6 घंटे के भीतर, हल होने की probability 50% है
और किसी मोड़ पर बस करना ही पड़ता है
work breakdown और estimation लगभग एक ही चीज़ हैं। breakdown पूरा हो जाए तो कुछ साल experience वाला व्यक्ति छोटे tasks के standard estimates रखता है, इसलिए हर टुकड़े पर estimate लगाने में कुछ मिनट ही लगते हैं
मेरे मामले में, मैं काम को उन chunks में तोड़ता हूँ जिनका मैं estimate लगा सकूँ, और जिन हिस्सों का estimate नहीं लगा सकता, उनके लिए दूसरों की राय लेता हूँ
हालांकि मैं नहीं मानता कि skill का असली रास्ता work breakdown है। कोई भी खराब breakdown बना सकता है
असली skill इसमें है कि कब evidence दिखा रहा है कि वह work breakdown problem पैदा करने लायक गलत है, यह पहचानना, और उसे communicate करना या re-estimate करना [0]
और यह सहजता से स्वीकार करना भी ज़रूरी है कि ऐसा होगा, ताकि शुरुआत से ही ऐसा schedule देने में stress न हो जिसमें बदलाव की संभावना अधिक है
managers आम तौर पर शुरुआत से ही accurate roadmap चाहते हैं, लेकिन यह असंभव चीज़ माँगना है। अच्छी management flexibility में है, और इस बात को समझने में है कि समय के साथ developers सीखते हैं और expected work की प्रकृति बदलती है
लेख के अंत का छोटा उदाहरण भी सोचने लायक है। अगर किसी ने accurate estimate, यानी “plane trips के दौरान कुछ dinners में खत्म हो जाएगा”, कहा भी होता, तो भी उसने इसे बहुत risky मानकर मना कर दिया होता
इससे दिखता है कि estimation केवल accuracy का मामला नहीं है। इसमें risk management, expectation management, work familiarity जैसे कई ऐसे factors हैं जो शब्दों में पूरी तरह सामने नहीं आते
[0] https://jacobian.org/2021/jun/8/incorrect-estimates/ - इस विषय पर एक लेख भी है
वे अच्छे नए software लोग होते हैं, लेकिन domain नया होने के कारण कभी-कभी सचमुच नहीं जानते कि basic functionality कैसे खड़ी की जाए। मेरे अनुभव में वे ऐसे tasks चाहते हैं जिन्हें वे सीखकर अच्छी तरह कर सकें, और वही growth में बदलता है
यह ज़रूर याद रखना चाहिए कि process cost एक continuum है जिसे team के हिसाब से adjust किया जाता है। NBA players match के दौरान huddle में गेंद फेंकना नहीं सीखते, लेकिन तीसरी कक्षा के बच्चे सीखते हैं
planning और coaching के दोनों तरीके अपनी-अपनी team के हिसाब से सही हों तो appropriate हैं
शायद यही software engineering का core truth हो। हो सकता है लेखक जो Streak app बनाना चाहता है उसका open-source version पहले से मौजूद हो, और वह wheel को फिर से invent कर रहा हो
लगता है दिमाग task lists पसंद नहीं करता। list बनाना मज़ेदार हो सकता है, लेकिन startup या coding का अधिकांश हिस्सा exploration है
और task lists exploration को रोकती हैं
अगर नहीं, तो software development में ऐसा क्या अलग है कि हमारे पेशे में “मुझे नहीं पता” एक reasonable जवाब बन जाता है?
कभी यह सही होता है, कभी नहीं। “map territory नहीं होता”
काम को छोटे tasks में बाँटने के लिए duplicate work करना पड़ता है, और कला इसे minimize करने में है
अगर आप बिल्कुल भी unnecessary काम नहीं करना चाहेंगे, तो अंत में सब कुछ एक साथ करना पड़ेगा
उदाहरण के लिए मान लें कि आप एक program refactor कर रहे हैं जिसमें modules A और B हैं, और B, A पर depend करता है। सबसे कम waste वाला तरीका दोनों modules को साथ में refactor करना है। लेकिन वही सबसे ज्यादा risky है और estimate करना भी मुश्किल है
बांटने का तरीका यह है कि A को refactor किया जाए, और B को refactored A के साथ काम करने के लिए adjust किया जाए। फिर अगर A को दोबारा refactor करें, तो पहले किया गया adaptation work जल्दी ही फेंक दिए जाने का जोखिम पैदा हो जाता है
अगर आप फेंके जाने वाले काम को 0 करना चाहते हैं, तो अक्सर काम को टुकड़ों में बांटना संभव नहीं होता। 20 साल के अनुभव के बावजूद, मैं काम को बांटने के लिए फेंक दिए जाने वाले temporary work करने में आज भी अक्सर हिचकिचाता हूं
इसके बजाय, कई हफ्तों का काम करते हुए, छोड़े हुए yak hair का एक भी रेशा बाकी न छोड़ते हुए सब कुछ shave कर देने जैसा हो जाता है
शुरू करने से पहले जिस problem को solve करना है उस पर सोचना समझ में आता है, और मोटे milestones भी महत्वपूर्ण हैं। लेकिन अधिकतर मामलों में unknown unknowns इतने ज्यादा होते हैं कि पूरी तरह से तोड़ना बिल्कुल बेकार या असंभव होता है
project को तोड़ने में लगा समय अगर बस solution खोजने या बनाने में लगाया होता, तो शायद बहुत तेजी से खत्म हो गया होता। कम-से-कम मुझे तो ऐसा लगता है
मैं आम तौर पर अलग तरीके से approach करता हूं। शुरुआत में ही यह आकलन करना कि effort कितना लगेगा, ताकि तय किया जा सके कि इसे बनाना भी है या नहीं। कहें तो cost-benefit judgement में मदद करना पहला कारण है
यह team के लिए भी बहुत उपयोगी हो सकता है। खासकर कम अनुभवी लोगों के साथ काम करते समय, काम को काफी बांटा और parallelize किया जा सकता है
मुझे लगता है Jacob ने भी अपनी Streak app implement करते समय इस तरह की decomposition बहुत ज्यादा नहीं की होगी, इसलिए शायद समझाने के लिए recursive तरीके से example दिया है
ऐसे समय में उसे छोटे tasks में बांटना और एक-एक करके खत्म करना उपयोगी रहा। इससे deadlock में फंसे होने या काम न करने का मन होने की हालत में भी progress बनती है, और वही progress आगे बढ़ने की momentum पैदा करती है
managers के लिए speed estimate कर पाना भी निश्चित रूप से valuable है। हालांकि दिक्कत यह है कि एक बार इसका स्वाद लग जाए, तो वे “पक्का नहीं है” वाली बात सच में समझना छोड़ देते हैं
मैं भी consultant हूं, इसलिए भले ही हम “agile” तरीके से काम करें, “हम इसे इस समय के भीतर deliver करेंगे” कहना बहुत महत्वपूर्ण है