समय सीमा सार

स्रोत: टॉम डेमार्को "समय सीमा परियोजना प्रबंधन उपन्यास ”

मैंने अपनी राय में, परियोजना प्रबंधन पर किताब, सभी "नमक" को निचोड़ने की कोशिश की। मैं इसे जनता के सामने पोस्ट करता हूं।



1. यदि कोई व्यक्ति यह महसूस नहीं करता है कि वह सुरक्षित है, तो वह बदलाव का विरोध करेगा।
2. नेता को सफलतापूर्वक काम करने के लिए परिवर्तन आवश्यक है।
3. अनिश्चितता से व्यक्ति जोखिम से बच जाता है।
4. जोखिम से बचने के लिए, एक व्यक्ति सभी नए अवसरों और लाभों को याद करता है जो उसे बदल सकता है।
5. यदि आप कर्मचारी उत्पादकता के बारे में परवाह करते हैं तो धमकी सबसे अनुचित प्रकार की प्रेरणा है।
6. कोई बात नहीं आप क्या धमकी देते हैं, कार्य अभी भी पूरा नहीं होगा यदि शुरू से ही आपने इसे पूरा करने में बहुत कम समय लिया।
7. इसके अलावा, अगर लोग असफल होते हैं, तो आपको अपने वादों को पूरा करना होगा।
8. नेतृत्व के लिए हृदय, कण्ठ, आत्मा और गंध की आवश्यकता होती है।
9. अधिक सुनो, कम बोलो।
10. एक परियोजना का प्रबंधन करने के लिए, इसके जोखिमों का प्रबंधन करने के लिए पर्याप्त है।
11. प्रत्येक परियोजना के लिए एक जोखिम सूची बनाएं।
12. उन जोखिमों को ट्रैक करें जो परियोजना को विफल कर रहे हैं, न कि केवल अंतिम जोखिम।
13. प्रत्येक जोखिम की संभावना और लागत का आकलन करें।
14. प्रत्येक जोखिम के लिए, एक संकेतक को परिभाषित करें - एक लक्षण जिसके द्वारा आप यह निर्धारित कर सकते हैं कि जोखिम एक समस्या में बदल जाता है।
15. प्रबंधन को बुरी खबर देने के लिए सुलभ (संभवतः अनाम) चैनल बनाएं।
16. नुकसान कम करें।
17. प्रोजेक्ट की सफलता के लिए प्रयास करने के बजाय अनावश्यक प्रयासों को कम करके प्राप्त किया जा सकता है
नई जीत।
18. जितनी जल्दी आप अनावश्यक काम को रोकते हैं, पूरी परियोजना के लिए बेहतर है।
19. अनावश्यक रूप से नई टीम बनाने की कोशिश न करें; पहले से गठित और काम करने वाली टीमों के लिए टीम में देखें।
20. प्रोजेक्ट की समाप्ति के बाद भी टीमों को एक साथ काम करने के लिए छोड़ दें (यदि वे खुद चाहते हैं), ताकि आपके द्वारा प्रतिस्थापित किए गए नेताओं को बुरी तरह से काम करने वाली टीमों के साथ कम समस्याएं हों।
21. विचार करें कि एक टीम जो आगे काम करना जारी रखना चाहती है, वह किसी भी परियोजना के मुख्य लक्ष्यों में से एक है।
22. जिस दिन हम प्रोजेक्ट की शुरुआत में हारते हैं, उसका मतलब है कि वह दिन जितना अंत में खो जाता है।
23. व्यर्थ में एक दिन बिताने के लिए एक हजार और एक तरीके हैं और इस दिन को वापस लाने के लिए नहीं।
24. अपनी मान्यताओं को मॉडल करें और इस बारे में अनुमान लगाएं कि कार्य प्रक्रिया कैसी होगी।
25. इन मॉडलों पर चर्चा करें।
26. प्रत्येक परियोजना के आकार को परिभाषित करें।
27. माप की इकाई की पसंद के साथ पहले से उत्साही मत बनो - अगर बाद में आपको वास्तविक डेटा के साथ काम करना है, तो अमूर्त इकाइयां शुरू करने के लिए नीचे आ जाएंगी।
28. साधारण लोगों के आधार पर जटिल मेट्रिक्स का निर्माण करें (जो किसी सॉफ़्टवेयर उत्पाद में गिनना आसान हो)।
29. पहले से पूर्ण परियोजनाओं के लिए श्रम उत्पादकता की गणना करने के लिए ऐतिहासिक डेटा एकत्र करें।
30. जटिल सिंथेटिक मेट्रिक्स की गणना के लिए सूत्रों पर कार्य करें जब तक कि परिणाम सबसे सटीक रूप से प्राप्त नहीं होते हैं, तब तक संग्रह डेटा में निर्दिष्ट कार्य की मात्रा के लिए अमूर्त इकाइयों के अनुपात को दर्शाते हैं।
31. पूरे संग्रह डेटाबेस के माध्यम से एक प्रवृत्ति रेखा खींचना जो जटिल सिंथेटिक मैट्रिक्स के मूल्यों के अनुपात के रूप में काम की अपेक्षित राशि दिखाएगी।
32. अब प्रत्येक नई परियोजना के लिए यह सिंथेटिक मीट्रिक के मूल्य की गणना करने और काम की अपेक्षित मात्रा निर्धारित करने में इसका उपयोग करने के लिए पर्याप्त होगा।
33. प्रदर्शन लाइन पर "हस्तक्षेप के स्तर" के बारे में मत भूलना और सामान्य प्रक्षेपवक्र से अनुमेय विचलन को निर्धारित करने में एक संकेतक के रूप में इसका उपयोग करें।
34. एक अच्छी विकास प्रक्रिया और इसका निरंतर सुधार बहुत ही योग्य लक्ष्य हैं।
35. लेकिन अभी भी काम करने के लक्ष्य और उद्देश्य हैं।
36. एक से अधिक पद्धति सुधार लाने का प्रयास एक विनाशकारी व्यवसाय है। कई तकनीकों और कौशलों में सुधार लाने के उद्देश्य से कार्यक्रम इस तथ्य की ओर ले जाने की संभावना है कि शर्तें केवल बढ़ेंगी।
37. एक मानकीकृत विकास प्रक्रिया का खतरा यह है कि नियमित संचालन के दौरान, लोग किसी परियोजना को विकसित करने में समय और प्रयास को बचाने के अवसर को नोटिस नहीं कर सकते हैं।
38. अत्यधिक बड़ी टीमों के संबंध में, मानकीकृत प्रक्रिया का कड़ाई से पालन किया जाएगा जब तक कि यह सभी को काम पर महसूस करने की अनुमति देता है (इससे कोई फर्क नहीं पड़ता कि यह परियोजना के लिए उपयोगी है या नहीं)।
39. यदि आप उनकी रुचि नहीं रखते हैं, तो आप लोगों से अलग तरीके से काम करवा सकते हैं। उन्हें बदलने के लिए, आपको स्वयं को समझना (और सराहना करना) चाहिए, वे क्या कर रहे हैं और वे किस लिए प्रयास कर रहे हैं।
40. लोग तेजी से सोचना शुरू नहीं करेंगे अगर प्रबंधन उन पर दबाव डालेगा।
41. अधिक ओवरटाइम, कम उत्पादकता।
42. थोड़ा दबाव और ओवरटाइम समस्या पर ध्यान केंद्रित करने, समझने और इसके महत्व को महसूस करने में मदद कर सकता है, लेकिन निरंतर दबाव हमेशा खराब होता है।
43. शायद प्रबंधन दबाव लागू करने का इतना शौकीन है क्योंकि यह नहीं जानता कि स्थिति को कैसे प्रभावित किया जाए, या क्योंकि वैकल्पिक समाधान उन्हें बहुत जटिल लगते हैं।
44. एक भयानक कूबड़: दबाव और ओवरटाइम काम केवल एक समस्या को हल करने के लिए डिज़ाइन किए गए हैं - एक बुरे खेल में एक अच्छा चेहरा बनाए रखने के लिए।
45. अस्पष्ट विशिष्टताओं से संकेत मिलता है कि परियोजना के प्रतिभागियों के बीच अनसुलझे संघर्ष हैं।
46. ​​एक विनिर्देश जिसमें आवक और जावक सूचनाओं के प्रकारों की कोई सूची नहीं है, को भी ध्यान में नहीं लिया जाना चाहिए। इसका मतलब है कि यह कुछ भी निर्दिष्ट नहीं करता है।
47. एक परियोजना जिसमें कई पक्ष शामिल हैं, आवश्यक रूप से हितों के टकराव का सामना करेंगे।
48. सॉफ्टवेयर सिस्टम बनाने और वितरित करने की प्रक्रिया सभी प्रकार के संघर्षों का केंद्र है।
49. अधिकांश कंपनियों में जहां सॉफ्टवेयर बनाया जाता है, कोई भी विशेष रूप से संघर्ष समाधान के साथ नहीं होता है।
50. संघर्ष समझ और सम्मान का हकदार है। संघर्ष का अनप्रोफेशनल व्यवहार से कोई लेना-देना नहीं है।
51. सभी को रिपोर्ट करें कि आप सभी प्रतिभागियों के हितों को ध्यान में रखने की कोशिश करेंगे, और यह सुनिश्चित करेंगे कि ऐसा हो।
52. बातचीत करना मुश्किल है मध्यस्थता करना बहुत आसान है।
53. अग्रिम में घोषणा करें कि यदि परस्पर विरोधी दलों के हितों का पूरी तरह या आंशिक रूप से विरोध किया जाता है, तो समाधान की तलाश को एक मध्यस्थ में स्थानांतरित कर दिया जाएगा।
54. मत भूलो: हम बैरिकेड्स के एक तरफ हैं। दूसरी तरफ समस्या खुद है।
55. मानव उत्प्रेरक हैं। वे एक स्वस्थ टीम बनाने में मदद करते हैं, रिश्ते, लड़ाई की भावना। यहां तक ​​कि अगर वे कुछ और नहीं करते (और एक नियम के रूप में, वे ऐसा करते हैं), परियोजना में उनकी भूमिका सबसे महत्वपूर्ण में से एक बनी हुई है।
56. यह हमें लगता है कि सबसे बुरी चीज कुछ जानना नहीं है। वास्तव में, यह सुनिश्चित करना बहुत खराब है कि आप जानते हैं कि यह वास्तव में कब नहीं है।
57. एक भयानक धारणा: ऐसा लगता है कि जो टीमें टाइट डेडलाइन सेट नहीं करती हैं वे तेजी से काम पूरा करती हैं!
58. बैठकें छोटी होनी चाहिए। ऐसा करने के लिए, आपको यह सुनिश्चित करने की आवश्यकता है कि लोग उन बैठकों को छोड़ने से डरते नहीं हैं जिनकी उन्हें आवश्यकता नहीं है। सबसे आसान तरीका है कि पहले से ही एजेंडा प्रकाशित करें, और फिर हमेशा सख्ती से पालन करें।
59. अधिकारियों के अपमान और दुर्व्यवहार से लोगों की रक्षा करें।
60. याद रखना: काम में डर = गुस्सा। जो नेता अपने अधीनस्थों पर चिल्लाना पसंद करते हैं और उन्हें अपमानित करते हैं और उनका हर संभव तरीके से अपमान करते हैं, वे वास्तव में किसी चीज से डरते हैं।
61. कभी-कभी स्थिति से बाहर निकलने का एकमात्र तरीका इंतजार कर रहा होता है। जब तक समस्या अपने आप नहीं सुलझती या जब तक आप इससे दूर होने का कोई रास्ता नहीं खोज लेते तब तक प्रतीक्षा करने का प्रयास करें।
62. चमत्कार अवश्य होते हैं, लेकिन उन पर भरोसा न करना बेहतर है।
63. क्रोध और ललक - यह वह सूत्र है जो व्यवसाय की असफलताओं के लिए जिम्मेदार हैं जो बुरी कंपनियों में लागू होने लगे हैं।
64. क्रोध और कंजूसी किसी भी अच्छी कंपनी के वास्तविक लक्ष्यों के सीधे विपरीत है - अपने कर्मचारियों के संबंध में उदार और देखभाल करना।