अपनी परियोजना के अंत के रूप में उल्टा पिरामिड

इस लेख में मैं आईटी परियोजनाओं में टीमों के निर्माण के बारे में थोड़ा अनुभव साझा करना चाहता हूं। मैं "टीम परिपक्वता पिरामिड" के रूप में हमेशा ऐसी स्पष्ट बात नहीं करना चाहता हूं।

यह संकेतक एक सख्त वैज्ञानिक शब्द नहीं है और इसमें सटीक गणना सूत्र नहीं हैं, लेकिन इसका सिद्धांत नाम में अच्छी तरह से तैयार है।

मध्यम और बड़ी परियोजनाओं में एक विशिष्ट टीम में विभिन्न प्रतिभागी शामिल होते हैं: परियोजना प्रबंधक, व्यवसाय विश्लेषक, डेवलपर्स, परीक्षक और ऑप इंजीनियर। प्रत्येक दिशा में आमतौर पर लीड होते हैं - दिशा में अग्रणी कर्मचारी, उदाहरण के लिए, एक अग्रणी विकास इंजीनियर, एक अग्रणी परीक्षण इंजीनियर, और इसी तरह।

यदि हम पिरामिड के रूप में ऐसी टीम की संरचना को कर्मचारियों के अनुभव और निर्णय लेने पर उनके प्रभाव के चित्रण के साथ चित्रित करते हैं, तो हमें ऐसा पिरामिड मिलता है:



हमें एक प्रकार का "टीम के लिए मास्लो का पिरामिड" मिला। लेकिन यह मत भूलो कि आईटी परियोजनाओं में सिर्फ इंजीनियर नहीं हैं। उदाहरण के लिए, डेवलपर्स को जूनियर / मध्य / वरिष्ठ / वरिष्ठ में विभाजित किया जा सकता है और भगवान जानता है कि कैसे, कार्य अनुभव और ज्ञान (या नियोक्ता की कल्पना पर) के आधार पर।

ऐसा होता है कि एक व्यक्ति के पास एक कम शीर्षक होता है, लेकिन अनुभव और ज्ञान से यह व्यक्ति समाधान वास्तुकार की भूमिका को पूरा करने में सक्षम होता है (लेकिन परिस्थितियों के कारण यह इस भूमिका को पूरा नहीं करता है)। जाहिर है, ऐसे लोग टीम के भीतर निर्णय लेने को प्रभावित करते हैं, यहां तक ​​कि परियोजना के भीतर औपचारिक पद ग्रहण किए बिना भी। और ऐसे लोगों को हमारे पिरामिड में दूसरे चरण में लाने की आवश्यकता है। यह महत्वपूर्ण है कि तीसरे की तुलना में दूसरे स्तर पर अधिक लोग नहीं हैं।

निर्णय लेने पर अनुभव और प्रभाव के आधार पर आप प्रत्येक टीम के सदस्य को एक निश्चित राशि "मन्ना" सौंप सकते हैं। उदाहरण के लिए, रैंक-एंड-फाइल टीम के सदस्यों को 1 पीटी, लीड और मैनेजर 2 पीटी प्राप्त होंगे।

कल्पना कीजिए कि हमारे पास 15 लोगों की एक टीम है, फिर एक ठेठ पिरामिड को किसी तरह इस तरह माना जाएगा:

1 :
Project Manager + Technical Lead = 4 pts
2 :
2x Stream Leads + 2x Senior Engineer = 8 pts
3 :
9x Middle and Junuor Engineers = 9 pts

और हमें ऐसा पिरामिड मिलता है:



ठीक है, आप कहते हैं, यह ठीक उसी तरह है या नहीं हमारे प्रोजेक्ट पर और हमारे साथ सब कुछ ठीक है। और इसका व्यावहारिक परिणाम क्या है?

इस पद्धति का उपयोग कर एक टीम का मूल्यांकन करने से आपको दो चीजों को समझने की अनुमति मिलती है: मौजूदा टीम कितनी प्रबंधनीय (स्थिर) है और यह कितना अजीब है कि ऐसी टीम में काम करना हर किसी के लिए कितना आरामदायक है।

वास्तव में, अधिक महत्वपूर्ण बात यह है कि जब टीम की परिपक्वता का पिरामिड उल्टा हो जाता है तो क्या होता है। या जब यह समतल हो जाता है, तो समानांतर रूप से या कुछ और। और यह बहुत बुरा परिदृश्य है।

सही पिरामिड बहुत स्थिर है, लेकिन उलटा एक नहीं है। आप कॉलोनी "व्हाइट स्वान" के साथ कपटपूर्ण प्रयोग को याद कर सकते हैं जहां कुछ आपराधिक अधिकारी बैठे थे और यह उनके लिए कैसे समाप्त हुआ।

और यदि आप आईटी क्षेत्र से विचलित नहीं होते हैं, तो आप दो वास्तविक स्थितियों की कल्पना कर सकते हैं:

• वे एक प्रभावी परियोजना प्रबंधक को सस्ते और हंसमुख बनाने का प्रस्ताव देते हैं - 30 "भारतीयों" को किराए पर लेते हैं और छह महीने के बजाय एक महीने में परियोजना दर्ज करते हैं;
• एक बहुत ही महत्वपूर्ण ग्राहक साक्षात्कार में वरिष्ठ या लीड शीर्षकों के अलावा सभी इंजीनियरों को काटता है।

पहले मामले में, हमें पिरामिड के बजाय एक "ईंट" मिलती है और एक उदास अंत के साथ एक स्पष्ट रूप से बेकाबू परियोजना है।

दूसरे मामले में, हमें परियोजना पर समान कॉलोनी "व्हाइट स्वान" मिलती है। यह तब होता है जब सम्मानित और अनुभवी लोग एक कमरे में इकट्ठा होते हैं और दो घंटे में एक सरल समाधान नहीं कर सकते हैं। सिर्फ इसलिए कि वे सभी अनुभवी और शांत हैं, उनमें से प्रत्येक बाहर बोलना चाहता है और मानता है कि उसका विचार अच्छा है। इस तरह की बातचीत की भावना आमतौर पर बहुत छोटी है। इसके अलावा, यह स्पष्ट नहीं है कि किसको "साबुन उठाना" चाहिए, ओह, अर्थात, इस सुविधा को किसको देखना चाहिए?

मेरे करियर में टीमों में इस तरह के लोगों के साथ परियोजनाएं रही हैं और मैं ईमानदारी से कहता हूं कि पहले और दूसरे संस्करण में काम करना बहुत सहज नहीं है। प्रबंधक और साधारण कर्मचारी दोनों। जब किसी टीम में बहुत अधिक स्मार्ट लोग होते हैं, तो वह गूंगा हो जाता है। पिरामिड अस्थिर हो जाता है और अक्सर लापरवाही से "गिर" जाता है।

वास्तव में, सब कुछ सरल है, एक आईटी परियोजना में पर्याप्त इंजीनियर होने चाहिए जो काम करते हैं, लाभ उठाते हैं और सवाल नहीं पूछते हैं। ऐसे लोगों की पर्याप्त संख्या के बिना, इस परियोजना में पर्याप्त "हार्सपावर" नहीं है और यह एक खुशहाल भविष्य में कर नहीं देता है।
रिवर्स स्थिति तब होती है जब आपके पास बहुत अधिक "हॉर्स पावर" और थोड़ा नियंत्रण होता है, फिर आपकी रेसिंग कार पहले बाड़ पर दुर्घटनाग्रस्त हो जाएगी।

एक आईटी टीम में लोगों की आदर्श संख्या 5-15 लोग हैं। अमेज़न के बेजोस ने इसे "टू पिज्जा टीम" सिद्धांत के रूप में संकलित किया। लोगों की संख्या में और वृद्धि टीम के भीतर संचार को जटिल बनाती है और अब इसका गुणक प्रभाव नहीं होता है।

परिपक्वता से टीम के सदस्यों का आदर्श वितरण 2 से 5 मध्य स्तर के इंजीनियरों के नेतृत्व में है। अगर हम जूनियर इंजीनियरों के बारे में या वासिलिव के बारे में बात कर रहे हैं - तो 1-2 से अधिक प्रति लीड नहीं होना चाहिए (या जो व्यक्ति उनके लिए जिम्मेदार है)। सिर्फ इसलिए कि वह शारीरिक रूप से अधिक लोगों पर ध्यान देने में असमर्थ है। 5 लोगों के लिए प्राथमिक कोड की समीक्षा पहले से ही काम के समय का आधा हिस्सा ले सकती है। इसके अलावा, नेताओं के पास अभी भी अन्य टीमों और ग्राहक के साथ सभी प्रकार की बैठकें हैं, इसलिए वह नियमित इंजीनियर के रूप में 100% काम नहीं कर सकते हैं।

यानी हम यह कह सकते हैं कि टीम मैच्योरिटी पिरामिड के अंदर, हमें अतिरिक्त स्थिरता के लिए अलग-अलग उप-टीमों से छोटे पिरामिड का निर्माण करना चाहिए।

पिरामिड के ऊपरी स्तर के लिए - यह बहुत महत्वपूर्ण नहीं है कि आपके पास कितने लोग हैं जो शीर्ष पर हैं, यदि आपके पास 2 निम्न स्तर हैं - वे पूरी परियोजना को बाहर निकाल देंगे। ज्यादातर मामलों में पिरामिड सही नहीं होगा, लेकिन यह डरावना नहीं है। मुख्य बात यह है कि नीचे से पर्याप्त लोग हैं।

पर्यवेक्षकों के पिरामिड में ध्यान में न रखें - अर्थात्। जो लोग पूरी दिशा का नेतृत्व करते हैं और प्रबंधन में हस्तक्षेप किए बिना कई परियोजनाओं पर प्रक्रिया को नियंत्रित करते हैं।

एजाइल का प्रोडक्ट ओनर टीम का हिस्सा है, लेकिन प्रबंधन प्रक्रिया में हस्तक्षेप नहीं करना चाहिए। यदि वह माइक्रो-मैनेजमेंट में शामिल होना शुरू करता है या आपके पास तुरंत 5 उत्पाद स्वामी हैं, तो आपको बड़ी समस्याएं हैं। लेकिन ये पहले से ही सक्षम परियोजना प्रबंधन और ग्राहक संबंधों के मुद्दे हैं। यदि आप इस जाल में गिरते हैं, तो उलटा पिरामिड पहले से ही आपकी सबसे छोटी समस्या है।

एक और बात यह है कि जब बहुत से लोग इस परियोजना का नेतृत्व करना चाहते हैं, और आप, एकमात्र व्यक्ति के रूप में, जो काम करता है, साल्टीकोव-शेड्रिन के काम को याद रखें, "एक आदमी ने दो जनरलों को कैसे खिलाया।" या यह कहानी । लेकिन ऐसी स्थिति "टीम परिपक्वता पिरामिड" का उपयोग करके भविष्यवाणी करना आसान है और ऐसी परियोजना पर नहीं।

एक सक्षम कंपनी में, टीम की संरचना जैसी चीजों को परियोजना के बिक्री चरण के रूप में जल्दी योजनाबद्ध किया जाना चाहिए। फिर वे एक परियोजना प्रबंधक का चयन करते हैं जो लीड की टीम का निर्माण करेगा और उनकी मदद से पिरामिड का निर्माण करेगा, परियोजनाओं को देखा जाएगा और आकाशगंगाओं पर कब्जा करेगा।