CTO से झूठ बोलकर संकट टालने की घटना
(GrumpyOldDev.com)- Fortune 500 कंपनी का एक बड़ा ग्राहक प्रोजेक्ट vendor product पर निर्भरता के साथ शुरू हुआ, लेकिन असल में वह भारी customization मांगने वाला लगभग अधूरा software निकला
- Vendor integration ने एक अनलचीले package और custom development—दोनों की कमियां एक साथ पैदा कर दीं, और अगस्त में delivery के बाद अक्टूबर launch पूरा करने के लिए integration death march शुरू हो गया
- सभी customer transactions को एक विशाल JSON document में store करने वाली design ने performance problem पैदा की, और उस समय MongoDB की प्रति document 16MB limit वास्तविक data migration में घातक सीमा साबित हुई
- कंपनी ने समस्या को customer और vendor से छिपाकर एक महीने देर से launch किया, और 3 लोगों की internal team के साथ vendor integration को बदलने वाली skunkworks rewrite लगभग 2 महीनों में पूरी की
- Christmas से ठीक पहले CTO ने holiday work का निर्देश दिया, तो team lead ने पहले से पूरा हो चुका काम हर दिन ongoing बताकर developers को आराम करने दिया, और team ने जनवरी की testing schedule और launch पूरा किया
Vendor product से शुरू हुई गलत design
- Fortune 500 कंपनी में CTO ने अपने निजी connection वाले एक महत्वपूर्ण customer के लिए बड़े project की delivery का वादा किया
- मुख्य हिस्सा एक बड़ी technology services company को outsource किया गया, और vendor ने दावा किया कि उसके पास ऐसा product है जो अधिकांश भारी काम संभाल लेगा
- असली product requirements से बस मोटे तौर पर मेल खाता था, इसलिए जरूरी behavior बनाने के लिए भारी customization चाहिए थी
- नतीजतन vendor software और custom software की कमियां साथ-साथ आ गईं
- वह ऐसा अनलचीला package बन गया जिसे उसके मूल design purpose से अलग काम करवाने के लिए जबरन ढालना पड़ता था
- Vendor के main codebase से fork होने के कारण maintenance cost बढ़ गई, और भविष्य में support खत्म होने की संभावना भी बन गई
- Project से जुड़े लोगों को यह तरीका अच्छा नहीं लगा, लेकिन CTO की direct reporting structure बार-बार बदल रही थी, इसलिए status meetings “अच्छा idea है, boss” जैसी दिशा में बहती रहीं
Schedule delay और घातक data structure
- Internal development team ने project के अन्य हिस्से खुद बनाए, और vendor पूरी गर्मियों में वादा करता रहा कि product जल्द ही integrate करने लायक हो जाएगा
- अगस्त में vendor product deliver हुआ, तो अक्टूबर launch लक्ष्य के साथ integration death march शुरू हो गया
- सितंबर में launch रोक देने लायक bugs सामने आए
- Vendor product सभी customer transactions को एक ही विशाल JSON document के अंदर JSON records के रूप में store करता था
- Test data बढ़ने के साथ performance लगातार धीमी होती गई
- हर नया transaction जोड़ते समय database से पूरा JSON document पढ़ा जाता था, और अंत में नया record append किया जाता था
- Vendor ने कहा कि transaction fields पर indexes जोड़ने से इसे ठीक किया जा सकता है, और यह तरीका थोड़ी देर के लिए मददगार दिखा
MongoDB 16MB limit और छिपी हुई rewrite
- इससे बड़ी समस्या यह थी कि vendor ने database के तौर पर MongoDB चुना था, और उस समय MongoDB में प्रति document 16MB limit थी
- अक्टूबर में conversion team ने वास्तविक customer data डालना शुरू किया, तो 16MB limit से टकराने लगी
- कंपनी ने यह limit customer से छिपाकर एक महीने देर से operations शुरू करने का फैसला किया
- साथ ही vendor integration को replace करने के लिए एक skunkworks project शुरू किया
- Vendor को भी यह बात नहीं बताई गई
- यानी customer और technology partner—दोनों से core situation छिपाई गई
- मूल रूप से vendor side पर करीब 70 लोग लगे थे, लेकिन internal replacement work के लिए सिर्फ 3 लोग assign किए गए
- 1 व्यक्ति database design के लिए
- 1 व्यक्ति database से interface करने वाला backend बनाने के लिए
- 1 व्यक्ति business logic और web services बनाने के लिए
Holiday death march से ठीक पहले का फैसला
- Customer को बताया गया कि जनवरी में test करने के लिए नया version दिया जाएगा, जो initial go-live के समय स्वीकार की गई सबसे घातक defects को ठीक करेगा
- लेकिन customer को यह नहीं बताया गया कि पूरा core system लगभग 2 महीनों में फिर से लिखा जा रहा है
- मूल project को launch तक पहुंचने में एक साल से ज्यादा लगा था, लेकिन rewrite 3 लोगों को holiday period सहित करनी थी
- दिसंबर के मध्य के आसपास project participants को request नहीं, बल्कि आदेश के रूप में holiday work की सूचना दी गई
- Team के अधिकांश सदस्य पहले ही 6 महीनों से हर हफ्ते 60–80 घंटे काम करके burnout की हालत में थे
- Software launch, stage performance जैसी pressure और reward देता है
- कई महीनों या वर्षों की तैयारी का परिणाम launch day पर वास्तविक users तक पहुंचता है
- Developers को “मैंने कर दिखाया” वाली भावना और users की reaction से मजबूत achievement का एहसास मिलता है
- Software launch introverted लोगों के लिए live performance जैसा महसूस हो सकता है
CTO को झूठी report देकर team को आराम दिलाया गया एक सप्ताह
- Christmas पास आने तक, 3 लोगों की team ने एक महीने में replacement software लगभग पूरा कर लिया था
- अभी कुछ features साफ-सुथरे करने बाकी थे, लेकिन अगर team burnout न होती तो जनवरी testing schedule पूरा किया जा सकता था
- CTO ने holidays cancel करने का निर्देश दिया, तो team lead ने ऊपर से “OK” कहा
- असल में उसने 3 developers से कहा, “एक हफ्ता आराम करो। मैं संभाल लूंगा”
- Team lead हर सुबह जरूरी status meeting में जाता और CTO को पिछले महीने ही पूरा हो चुका काम ऐसे report करता जैसे वह अभी चल रहा हो
- “Team बहुत मेहनत कर रही है। आज हम integration milestone #73 पर पहुंच गए हैं”
- “कल team ने अच्छी progress की, और एक और web service खत्म की”
- Developers एक हफ्ते बाद recharge होकर लौटे
- Team ने जनवरी schedule पूरा किया, अच्छा launch किया, और थोड़ी देर के लिए खुद को rockstar जैसा महसूस किया
- वह एहसास The Beatles से ज्यादा Herman’s Hermits जैसा था, लेकिन फिर भी अच्छा था, ऐसा वे याद करते हैं
1 टिप्पणियां
Hacker News की रायें
अगर आप “डिलीवरी-डेट केंद्रित” होने के नाम पर छुट्टियां रद्द करके लगातार काम करते रहते हैं, तो अपने अनुभव से मैं कहना चाहूंगा: अब मूर्खता बंद करें
मेहनत की पहचान मिलने लगे तो रुकना खास तौर पर मुश्किल हो जाता है, लेकिन आखिर में आप उस पूरे समय पर पछताएंगे
अगर कंपनी का ढांचा ऐसा है कि वह product बेचने के लिए कर्मचारियों की छुट्टियों और vacation को हक समझकर खींच लेती है, तो आप आज की कई समस्याओं वाली दुनिया बनाने में योगदान दे रहे हैं
अगर बहुत लोग ऐसा करेंगे तो और ज्यादा लोगों को ऐसा करना पड़ेगा; और अगर कोई न करे और लोग अपने व्यवहार से दिखाएं कि ऐसी मांग ही बेतुकी है, तो CEO की जेब पर चोट लगने के बावजूद कंपनी यथार्थवादी अनुमान लगाने लगेगी
अपनी छुट्टी की योजना बता दें, backup person तय कर दें, team calendar में डाल दें, handover कर दें और फिर बस आराम करें
Projects आते-जाते रहते हैं और schedule अपने आप भी खिसक जाते हैं
अगर आप project schedule के हिसाब से छुट्टियां सरकाना शुरू कर देंगे, तो जिंदगी भर छुट्टी नहीं ले पाएंगे
अपवाद बस ऐसे roles हो सकते हैं जहां साल के अंत, quarter-end, tax season जैसे busy periods साफ तौर पर पहले से ज्ञात हों और उस समय गायब हो जाना अनुचित हो
मेरे cousin ने सितंबर 2023 से जनवरी 2024 तक एक बेहद खराब तरीके से managed project खत्म करने के लिए लगभग हर दिन रात 1 बजे तक काम किया, और सिर्फ Christmas पर छुट्टी ली—वह भी इसलिए क्योंकि वह धार्मिक holiday था और director ने इस डर से अनुमति दी कि कर्मचारी मुकदमा कर सकते हैं
उसने जरूरी चीजें मिस कीं और stress से लगभग 20 pounds वजन घट गया
कंपनी को नए system पर migrate करने की tight deadline थी; उन्हें यह बात 5 साल पहले से पता थी, फिर भी पिछले साल तक शुरू नहीं किया
Deadline चूकने पर contract से बाहर के खर्च के रूप में करोड़ों dollar लग सकते थे, और अंत में team ने deadline पूरी कर दी, लेकिन reward कुछ हफ्तों बाद यह layoff था कि उसकी position खत्म हो गई है
अब वह 50 की उम्र पार कर चुका है और job market में सबसे खराब समय में नौकरी खोज रहा है
वे खुद को valuable और important महसूस करने के आदी हो चुके हैं, और office hours के बाद उनके पास करने को कुछ और नहीं होता
कुछ मामलों में award पाने वाला employee उस mess के लिए आंशिक रूप से जिम्मेदार भी था
करीब चौथे award के बाद ही कमरे में बैठे senior managers को एहसास हुआ कि कंपनी में structural problem है
अगर युवा लोग इसे पढ़ रहे हैं, तो ऐसी कहानी किस दिशा में जाती है, यह कंपनी और किस्मत पर बहुत ज्यादा निर्भर करता है
एक healthy company में शायद outsourced implementation वाला तरीका शुरू ही नहीं हुआ होता
क्योंकि यह इतना साफ failure pattern है कि अनुभवी व्यक्ति शुरुआत से पहले ही नतीजा भांप सकता है
इससे पहले ही लोग CTO से यह झूठ नहीं बोलते कि सब ठीक चल रहा है, बल्कि बताते कि चीजें नहीं चल रहीं
अगर project बचाने के लिए ज्यादा smart या creative तरीका चाहिए होता, तो CTO, और शायद customer के साथ भी मिलकर adjustment किया गया होता
Team पहले से burnout में हो तो छुट्टियों में लंबे समय तक धकेलकर काम भी नहीं कराया जाता
Manager या lead project की सफलता और team की सेहत के लिए ऊपर वालों के सामने खड़े होते, और जरूरत पड़ने पर इस बात पर जोर देते कि team को holiday पर आराम करना चाहिए
“आधा-स्वस्थ” organizations में manager जानबूझकर ambiguous हो सकता है या जानकारी छोड़ सकता है, और यह अच्छा है या नहीं, यह situation पर निर्भर करता है
लेकिन इस कहानी की तरह अगर manager या lead ने chain of command में ऊपर बार-बार खुले तौर पर झूठ बोला, तो healthy company हो या न हो, आम तौर पर इसे बहुत खराब माना जाता है
बेशक ऐसी situations को बाद में हाथ बांधकर judge करना कहीं आसान होता है
मुश्किल position में या overworked हालत में कोई भी गलती कर सकता है, लेकिन ऐसे scenarios देखकर सीखना मायने रखता है ताकि फिर किसी मिलती-जुलती खराब स्थिति में फेंके जाने पर बेहतर प्रतिक्रिया दी जा सके
अगर आप ऐसी कंपनी में हैं, तो नई नौकरी ढूंढना शुरू कर देना बेहतर है
ऊपर के स्तर की सड़ांध इस हद तक हो तो उसे ठीक करना असंभव है, और वे आपको CTO भी नहीं बनाने वाले
पिछले 25 साल काम करते हुए मैंने इसे एक बार भी नहीं देखा
इसे ठीक करने में डेढ़ साल लगा, और इस दौरान “underwear” ship हो चुका था इसलिए sale को reverse भी नहीं कर सकते थे
असल में हम underwear बेचते ही नहीं थे, सिर्फ network services बेचते थे, फिर भी customer की मदद करने से पहले system के order process बंद करने का इंतजार करना पड़ता था
वह board member एक साल बाद चला गया, और शायद इस बात से काफी खुश रहा होगा कि उसने मूर्ख CEO को बेवकूफ बना लिया
अंत में मुझे वहां से निकाल दिया गया, और उस घबराई हुई कंपनी के लिए मुझे कोई सहानुभूति नहीं है
वे मूर्ख थे जिन्होंने “solution” outsource करने की कोशिश की और सबके लिए तकलीफ ही बढ़ा दी
कुछ समस्याएं सच में हल करने लायक होती हैं, लेकिन आधी चीजें बस “in-house बनाए बिना पैसे बचा रहे हैं” जैसा महसूस कराने वाला कचरा होती हैं
अंत में उस कचरे को maintain करने के लिए contract cost लगातार देनी पड़ती है जिसे आपने शुरू में बनाया ही नहीं था
मतलब समस्याएं छिपाए बिना facts साफ-साफ कहना, जो सचमुच बहुत rare है
Microsoft security memo देख लें तो भी यही दिखता है
Holidays पर death march नहीं होता, यह बात कुछ हद तक सही है अगर आप bank या FAANG में काम करते हैं
अगर “startup culture” वाली company है, तो भूल जाइए
वास्तव में जब अपना interest जुड़ता है तो काम के प्रति attitude काफी जल्दी बदल जाता है, लेकिन ऐसी opportunity पाने और उसे देखने वाली companies ज्यादा नहीं हैं, ऐसा मेरा मानना है
मैंने कई बार आधी रात को चुपचाप rules मोड़कर जरूरी काम निपटाए हैं, और capable लोगों में भी कई ऐसे रास्ते पर गए हैं
यहां तक कि banks में भी मैंने ऐसा देखा है
जब तक आप company या team की value से बड़ा financial bet नहीं लगा रहे, कई चीजें यूं ही निकल जाती हैं
या तो काम कर दिखाते हैं और promotion पाते हैं, या अपनी promotion की संभावना खुद घटा लेते हैं और फिर नई नौकरी ढूंढते हैं
“वेंडर का product हर customer transaction को एक विशाल JSON document के अंदर JSON record के रूप में store करता था, और नया transaction जोड़ने के लिए database से पूरा JSON document पढ़कर उसके अंत में नया record जोड़ता था” — यह हिस्सा पागलपन जैसा लगे, यही सामान्य है
इसी तरह, एक fund के संभावित investment target के लिए मैंने कभी technical due diligence में मदद की थी, और उस startup की user table में ticket/booking data भी साथ में था
एक ticket एक column था, इसलिए अगर सबसे active user के पूरे history में 5 tickets थे, तो 5 columns चाहिए थे
जब review किया, तब तक 500 से ज़्यादा columns हो चुके थे, और वे “scale” करने के लिए investment ढूंढ रहे थे
बेशक यह solve हो सकने वाली problem है, लेकिन जैसा आप सोचेंगे, सब कुछ उल्टे-सीधे तरीके से design किया गया था, और वही सबसे साफ़ “ये क्या है” वाला moment था
Investment नहीं मिला
पूरा customer और product database plain-text passwords के साथ कई megabytes की public
.jssingle file में stored था, और 2000s की शुरुआती internet speed पर app कुछ भी करने से पहले वह पूरी file load करता थाऊपर से app एक ही विशाल file था, और directory में
index.1.js,index.final.js,index.newest.js,index.45.jsजैसे नामों की भरमार थीBest practices जानने लायक experience था, इसलिए मैंने CEO के पास जाकर CTO को fire करवाया, और
git,mysql, server-side logic और वास्तविक structure के साथ इसे फिर से बनाना शुरू कियाफिर जिस Windows server पर यह सब चल रहा था, वह hack होकर porn server बन गया; मैंने उस server को कभी देखा तक नहीं था और मेरे पास admin rights भी नहीं थे, फिर भी किसी तरह यह मेरी ज़िम्मेदारी बन गया
शुरुआती कुछ jobs वाकई बहुत शिक्षाप्रद थीं
Stanford से होने का दावा करने वाले senior engineer ने वह system design किया था
मैंने real production data के आधार पर लंबी बहस की कि launch होने पर यह scale नहीं करेगा, लेकिन किसी ने नहीं सुना, और launch के कुछ ही हफ्तों में यह ढह गया
जल्द ही मैं दूसरी team में चला गया, और सबसे बुरी बात यह थी कि वह senior engineer आखिरकार promote हो गया और वह system एक बिल्कुल नई team को सौंप दिया गया ताकि वे उससे लड़ें
पूरे system का design भयानक था, और आप अंदाज़ा लगा सकते हैं कि क्यों
Executives को शानदार dinner और trips से अपने पक्ष में किया, और खराब product थमा दिया ताकि आगे भी वे खुद ज़रूरी बने रहें
कहानी में CTO को खुद कुछ पता नहीं था
उसकी नज़र से तो अंत में सब कुछ ठीक ही हुआ दिखता है
हफ्ते में 80 घंटे काम करने वाले developers को छोड़कर, सबके लिए जीत
इस कहानी में सब कुछ टूटा हुआ है, protagonist का approach भी
Team lead का लोगों को छुट्टी देना और उसे झूठ बोलकर छिपाना बिल्कुल acceptable नहीं है, और यह company द्वारा fire किए जाने वाले दायरे में काफी हद तक आता है
दरअसल for-cause termination भी संभव लगता है
हालांकि ऊपर वाले लोग इतने track से उतरे हुए लगते हैं कि शायद बात निकल जाए और तारीफ भी मिल जाए
यह उसके माहौल के हिसाब से किया गया कदम लगता है
नए team leads को सलाह दूँ तो, यहाँ गर्व करने जैसा कुछ नहीं है; बेहतर विकल्प यह है कि जोर से issue उठाया जाए कि लोग overtime कर रहे हैं, और vendor पर सामान्य standards लागू करने या project scope को normal work week के हिसाब से फिर से देखने की मांग की जाए
ऐसी situation को किसी तरह चलाते रहने से बिना किसी फायदे के लोग burnout हो सकते हैं या fire हो सकते हैं
अगर परिवार पालने के लिए सच में बहुत desperate situation नहीं है, तो team lead की जिम्मेदारी है कि पागलपन भरी demands से team के reasonable working hours की रक्षा करे
वह ऐसा hill है जिस पर fire होने का जोखिम लिया जा सकता है, झूठ बोलने का नहीं
इसलिए अगर performance पर असर नहीं पड़ा, तो team lead का लोगों को छुट्टी देना और यहाँ तक कि झूठ बोलना भी पूरी तरह acceptable हो सकता है
अगर share कर दी होती तो management क्या करता? Project को और आगे खिसका देता
जो लोग अपनी glory के लिए दूसरों से और ज़्यादा काम करवाना चाहते हैं, उन्हें सबक मिलना चाहिए
आखिर किसका दिन बचाया गया?
वह घटिया vendor जिसने कचरा deliver किया?
वह CTO जिसने खुद को yes-men से घेर रखा है और जिसे company में क्या हो रहा है, यह साफ़ तौर पर बिल्कुल पता नहीं?
वे developers जिनसे हड्डियाँ टूटने तक काम करवाया गया, लेकिन बात “ठीक है, मैंने तुम्हें एक हफ्ते की छुट्टी तो दी थी” बन गई?
वह protagonist जिसने ऐसी company की मनमानी deadline पूरी करने के लिए सबको झूठ बोला जो employees की परवाह नहीं करती?
इस कहानी का हर पल रोंगटे खड़े करने वाला था
मैं मेहनत से काम करने वालों में हूँ, और customers के लिए launch smooth करने के लिए कभी-कभी extra work भी किया है, लेकिन यह कहानी शुद्ध पागलपन है
कभी-कभी ज़्यादा समय देना इसलिए होता है क्योंकि boss के साथ trust relationship होता है, और पता होता है कि हमेशा सच बोला जा सकता है
सच में, blame-free culture का core concept यही है, और यह तभी संभव है जब सभी सच बोलें
किसी बेवकूफ CTO की deadline पूरी करने के लिए पागलों की तरह झूठ बोलना literally sanity से बाहर है
अगर आप ऐसी situation में हैं, तो तुरंत निकलें और बेहतर job ढूंढें
“pride and sense of accomplishment” और burnout?
“हमने January schedule भी meet किया, शानदार launch किया, और थोड़ी देर के लिए rockstar बन गए” में जो “हम” है, वह साफ़ तौर पर मैं का मतलब है
हो सकता है मैं भाग्यशाली रहा होऊं, लेकिन सच बोलने पर मुझे कभी निकाला नहीं गया, और सच को निभाना ज़्यादा आसान था
जैसे कहना, “critical path में मौजूद third-party library में bug है। हम bug का सामना करना मुश्किल बना सकते हैं, लेकिन vendor के fix करने से पहले इसे ठीक नहीं कर सकते”, या “users बढ़ने से performance issue उम्मीद से जल्दी सामने आ गया। इसे ठीक करने में 2 महीने लगेंगे; इस दौरान infrastructure पर तीन गुना खर्च करके इसे कम किया जा सकता है, या performance की वजह से ग्राहक खो सकते हैं”, या “सबसे बड़े customer को पहला iteration मिलने के बाद ही पता चला कि उन्हें क्या चाहिए। यह उससे बिल्कुल अलग है जो हमें लगा था कि हम बनाएंगे। हम वह बना कर revenue कमा सकते हैं, या सिर्फ सपने के पीछे भागते हुए खत्म हो सकते हैं”
फिर कहूंगा, हो सकता है मैं भाग्यशाली रहा होऊं, लेकिन ईमानदारी ने मेरे लिए अच्छा काम किया
इसलिए, जैसा दूसरों ने कहा, “देखेंगे/समीक्षा करेंगे” कहकर धीरे-धीरे किनारे कर देते हैं या छिटपुट/निचले दर्जे के काम पर लगा देते हैं
दूसरा विकल्प है चुप रहना और देखना कि वे लंबे समय तक जूझते हुए अंततः असफल हो जाएं
आमतौर पर इसमें करीब 1 साल लगता है, लेकिन मैंने 2–3 महीनों में प्रोजेक्ट बंद होते और अगले quarter में leadership को व्यावहारिक रूप से हटा दिया जाता भी देखा है
कोई राय पूछे तो आप अपनी चिंताओं को कूटनीतिक ढंग से समझा सकते हैं, लेकिन न पूछे तो चुप भी रह सकते हैं
असली बात यह है कि क्या आप अपने से ऊपर बैठे व्यक्ति की credit लेने वाली योजना की खामियों को सक्रिय रूप से इंगित करेंगे
जैसे ही आप बोलते हैं, उन्हें लगता है कि उनके judgment पर सवाल उठाया जा रहा है, और वे इसे निजी हमला मान लेते हैं
दुश्मन बनाए बिना ऐसा करना बेहद मुश्किल है; दुश्मन लंबे समय तक रहते हैं, और एक दुश्मन से होने वाला नुकसान कई दोस्तों से भी पूरा करना मुश्किल होता है
इसलिए game खेलना पड़ता है
यह बेहद महत्वपूर्ण detail है कि मुख्य पात्र पहले से खत्म हो चुके काम के बारे में झूठ बोल रहा था
वह हर सुबह CTO के साथ अनिवार्य death-march status meeting में जाता और कहता, “team मेहनत कर रही है”, “आज हमने milestone integration point #73 पूरा किया”, “कल अच्छी progress हुई और एक और web service खत्म की”, लेकिन असल में ये वे काम थे जो पिछले महीने ही पूरे हो चुके थे
एक नजरिए से यह कम वादा करना और ज्यादा deliver करना जैसा दिखता है
अगर उसने अभी अधूरे काम को पूरा बता कर झूठ बोला होता, तो यह कहीं ज्यादा खराब लगता
वह निश्चित रूप से ज्यादा risky होता, और team के लौटने पर यह कहना भी team के लिए अच्छा नहीं होता कि “ये tickets हैं, लेकिन CTO को मैंने बता दिया है कि ये हो चुके हैं, इसलिए जल्दी करो”
developers और management के interaction को information asymmetry और trust की कमी से भारी नुकसान होता है
अभी हम एक ऐसे codebase को update करने के project पर काम कर रहे हैं जो बहुत पुराने compiler पर चलता है
इस पर 1 साल से काम कर रहे हैं और system के बड़े हिस्से पूरे हो चुके हैं, लेकिन एक काफी महत्वपूर्ण हिस्सा अभी बाकी है
management process को नहीं समझता और उन्हें यह भरोसा भी नहीं है कि project आखिरकार सफल होगा
software projects, खासकर transformation work, का fail होने का लंबा इतिहास रहा है, इसलिए उनकी चिंता के लिए मैं उन्हें दोष नहीं देता
पहले progress meeting हर हफ्ते होती थी, अब बढ़ाकर हफ्ते में 2 बार कर दी गई है; शायद उन्हें लगता है इससे काम तेज होगा
वे आमतौर पर खुद शामिल नहीं होते और एक middle manager messenger की भूमिका निभाता है
developer के नजरिए से यह निश्चित रूप से हो जाने वाला काम है, और व्यक्तिगत रूप से मैंने इसकी सफलता पर कभी संदेह नहीं किया
बस system बड़ा और पुराना है, इसलिए समय-सीमा अनिश्चित है
बाकी काम वर्षों का नहीं, महीनों का है, और मुझे 80/20 rule भी पता है, लेकिन हम उस 20% के अंदर काफी गहराई तक आ चुके हैं
management के लिए यह बस complete/incomplete की binary state है, इसलिए progress का अंदाजा लगाना मुश्किल है, और वे हमारी बातों पर “trust” नहीं करते
यह समझ में आता है
अगर हमने 1 साल तक कुछ न किया होता और सिर्फ meetings की होतीं, तो उन्हें पता नहीं चलता
fixed-price contract है, इसलिए हमारे पास खींचने की वजह नहीं है, लेकिन पूरा risk उन्हीं पर है
वे पहले ही काफी पैसा खर्च कर चुके हैं और चिंतित हैं
external technical expert की सलाह के आधार पर उन्होंने अच्छे technical decisions लिए, लेकिन फिर भी confidence की कमी है
अंततः project fail हुआ तो झटका उन्हें लगेगा, हमें अपेक्षाकृत कम लगेगा
आसान समाधान नहीं है
यह भर नहीं कहा जा सकता कि managers technical होने चाहिए, और वह technology उनके core business का हिस्सा भी नहीं है
और consultants बुलाने से भी मन को तसल्ली नहीं मिलेगी
हम जो सबसे अच्छा कर सकते हैं, वह है आगे बढ़ते रहना और deliver करना
एक-एक महीने के chunks भी ठीक हैं; बस granular बनाइए और सब कुछ sub-tasks में बांट दीजिए
perfect न हो तो भी चलेगा, rough edges हों तो भी ठीक है
हर chunk को friendly और मजेदार नाम देने की सलाह दूंगा
उदाहरण के लिए tango, cha-cha, waltz जैसे classic dance names अच्छे रहेंगे
managers के साथ meeting schedule करें, senior managers को भी शामिल करें, और middle managers से daily standup में observe करने का अनुरोध करें
सबको खड़ा रखें ताकि meeting छोटी रहे, और list में मौजूद tasks के मुकाबले progress track करें
अगर कोई task जुड़ जाए या थोड़ा late हो जाए, तो जब तक कुल मिलाकर आप लक्ष्य के करीब जा रहे हैं, लोग चौंकेंगे नहीं
हम दोनों जानते हैं कि actual deployment बड़ा hurdle है, लेकिन जब तक आप तैयार न हों, उन्हें बताने की जरूरत नहीं है
delay management को बेचैन करता है, और यह समझ में आता है, लेकिन ज्यादा meetings करने से काम तेज नहीं होता
PM का रोज 30 मिनट check-in करके यह कहना कि “मैं support करूंगा और project को वापस track पर लाने के लिए जो चाहिए दूंगा” मददगार नहीं है
जरूरत सिर्फ meetings कम करने की है
obstacle सिर्फ time है, और time obstacle इसलिए है क्योंकि ऊपर वालों ने शुरू से ही unrealistic schedule पर जोर दिया था
आखिरकार developers पर trust न दिखाकर वे यह भी दिखा रहे हैं कि सही developers hire करने की अपनी management ability पर उन्हें trust नहीं है
वे अपने काम के एक core हिस्से में बहुत खराब प्रदर्शन कर रहे हैं
1 साल का project complete/incomplete की binary state नहीं होना चाहिए
संभाले जा सकने वाले progress metrics होने चाहिए
top management का technical होना जरूरी नहीं, लेकिन hierarchy में कहीं न कहीं ऐसा व्यक्ति जरूर होना चाहिए जो progress को समझने योग्य format में translate कर सके
वेंडर के बारे में पक्के तौर पर पता दो बातों को माफ करना मुश्किल है
एक यह कि उसने core logic को Mongo records को अनंत तक बढ़ाने पर निर्भर बना दिया था, और दूसरी यह कि औसत से थोड़ा बेहतर तीन लोग जानबूझकर कोशिश करें तो उसे लगभग 3 महीनों में replace कर सकते थे
उस वेंडर का Fortune 500 ग्राहकों के साथ deal करने की स्थिति तक पहुंच जाना दिखाता है कि इस ग्राहक जैसे संगठन बहुत बड़े न होने वाले software कामों के सामने भी कितने असहाय महसूस करते हैं
सच कहें तो उस project का scope ऐसा लगता है कि यहां मौजूद कुछ लोग उसे hobby project के तौर पर भी कर सकते हैं
इसलिए यह भी समझ आता है कि Retool technology leaders के बीच popular है, लेकिन engineers के बीच जरूरी नहीं
सोचता हूं कि इसी gap को भरने के लिए और कौन-से product approaches हो सकते हैं
spreadsheets की वजह से निचले पद का कोई भी व्यक्ति संगठन में किसी और से निपटे बिना कुछ ही दिनों में लगभग काम करने वाला एक rough tool prototype बना सकता था
spreadsheets से पहले आपको ऊपर वालों को मनाकर IT department से request संभलवानी पड़ती थी, और सिर्फ उस process में ही कम से कम 3 महीने लगते थे
उसके बाद कुछ और quarters इंतजार करना पड़ता, तब जाकर Cobol या C जैसी किसी चीज़ में लिखा हुआ, requirements से मेल न खाने वाला लगभग काम करने वाला rough implementation मिलता
कुछ developers और कुछ support staff users से मिलने गए, और developers एक बड़े problem को हल करने के लिए 6 महीनों से नया tool बना रहे थे
लेकिन वही दिन था जब end users ने उसे पहली बार देखा
थोड़ी देर बाद हम state border पार करके वापस आ रहे थे, और developers की हालत शर्मिंदा-सी थी
जहां तक मुझे पता है, उस project का फिर किसी ने कभी जिक्र नहीं किया
नए लोगों से सारा काम करवाना और senior developer के hourly rate पर bill करना, यही तरीका है
काश लोग AI-generated header images इस्तेमाल करना बंद कर दें
शुरुआत से ही ध्यान भटक जाता है
क्या वह code monitor के पीछे है?
और पीछे वाली chair की backrest पर भी code है? या जो बैठा है वह कोई विशाल iPad है?
अगर AI image इस्तेमाल करनी है, तो कम-से-कम इतनी कोशिश तो करनी चाहिए कि वह पूरी तरह अजीब और पागलपन जैसी न दिखे
ऐसी images सचमुच कुछ seconds में generate हो जाती हैं, तो चुनी गई चीज़ों में सबसे अच्छी यही थी?