HTML लेआउट को प्रभावित करने वाले कारक (भाग 2: पीएम कार्य और वर्कफ़्लो)

जारी रखने के लिए ...

यह लेख भाग 1 की एक निरंतरता है :

HTML एनकोडर का काम ।

पीएम काम करते हैं

1. आवश्यकताओं, इच्छाओं की असंदिग्ध व्याख्या

और ग्राहक की इच्छा।

सबसे खराब स्थिति:

ग्राहक की इच्छाएं पीएम द्वारा एनकोडर को प्रेषित की जाती हैं (अस्पष्ट,

अस्पष्टता से)

उदाहरण के लिए, एक आवश्यकता या कार्य तैयार किया जाता है: "इसे करें

अधिक हरा "," फ़ॉन्ट बढ़ाएँ "," इस ब्लॉक को बाईं ओर ले जाएँ ",

"सामान्य शैली में इस पृष्ठ को डिज़ाइन करें।"

अच्छा अभ्यास:

जितना हो सके पीएम

ग्राहक की आवश्यकताओं और इच्छाओं को स्पष्ट करता है और निर्दिष्ट पास करता है

एनकोडर के लिए आवश्यकताओं। एक आवश्यकता या कार्य तैयार किया जाता है, उदाहरण के लिए,

इस तरह: "इस # 0BB822 हरे रंग का उपयोग करें।" “फ़ॉन्ट बढ़ाएँ

18 पिक्सेल तक "," ब्लॉक 3 पिक्सेल को बाईं ओर ले जाएँ। "

प्रभाव:

जितना अस्पष्ट और अस्पष्ट

आवश्यकता है, जितना अधिक समय आपको इस पर खर्च करने की आवश्यकता है

निष्पादन। स्पष्ट मानदंड की कमी से फर्क पड़ता है

ग्राहक और निर्माता के अंतिम परिणाम की दृष्टि में (याद रखें

झूले के साथ एक तस्वीर और विभिन्न प्रतिभागियों द्वारा परिणाम का एक अलग दृश्य

परियोजना)

निर्णय में ग्राहक द्वारा दी गई काल्पनिक स्वतंत्रता से बहकावे में न आएं

किसी भी प्रश्न के बाद से स्वायत्तता तार्किक रूप से बताती है

द्वारा सख्त स्वीकृति (महत्वपूर्ण मूल्यांकन) की कमी

ग्राहक के रूप में इस तरह के। व्यवहार में, ग्राहक हमेशा बदलने के लिए कहता है

या कुछ चीजों को फिर से बदल दें। भिन्नता को कम किया जाना चाहिए

एक न्यूनतम करने के लिए

कार्रवाई:

1. PM: सभी अस्पष्टताओं का पता लगाएं, तैयार करें

स्पष्ट स्वीकृति मानदंड। छोटी-छोटी बातों का ध्यान रखें।

तकनीक का उपयोग करें "क्या मैं आपको सही तरीके से समझता हूं?" और अन्य

2. HTML कोडर: सभी मुद्दों और उत्पन्न होने के बारे में PM को सूचित करें

पूर्वाग्रहों

2. क्या हो रहा है और घटकों को समझना

लेआउट प्रक्रियाओं।

सबसे खराब स्थिति:

पीएम प्रक्रिया का सार नहीं समझते हैं

टाइपसेटिंग, एनकोडर कार्य के गलत अनुक्रम का चयन करता है

परियोजना में, समय में कटौती, काम की मात्रा कम कर देता है।

पीएम कार्यक्षमता पर डिजाइन के प्रभाव को नहीं देखते या समझते हैं (जब

डिजाइन आपको कार्यक्षमता का काम बदल देता है)।

अच्छा अभ्यास:

पीएम स्पष्ट रूप से समझते हैं कि कौन

उनके प्रोजेक्ट के स्थान और उन्हें किस चरण में काम करने की आवश्यकता है

HTML के साथ। समझता है और संभावित जोखिमों को ध्यान में रखता है, घटनाओं को रखता है

उन्हें रोकने के लिए।

पीएम ने उन जगहों को नोटिस किया जिनमें डिजाइन कार्यक्षमता को प्रभावित करता है। अगर दिया जाता है

स्थान महत्वपूर्ण है - परियोजना टीम के साथ परिवर्तनों पर चर्चा करता है; अगर

नहीं - ग्राहक के साथ "redrawing" पर चर्चा करता है, मौजूदा खाते में ले रहा है

अवसरों की।

प्रभाव:

परिणाम क्या है, और इस परिणाम को कैसे प्राप्त करें, इसकी गलतफहमी

मूल्यांकन में बेहिसाब गतिविधियों के अस्तित्व की ओर जाता है। इसके परिणामस्वरूप,

डिजाइन समय के एक अतिवृद्धि की ओर जाता है।

कोडिंग के लिए स्रोत सामग्री - एक स्थिर चित्र दिखा रहा है

साइट का एक विशेष मामला। परिणाम एक गतिशील साइट है। तदनुसार,

चित्र में दिखाई गई आदर्श स्थितियों के अनुसार रिसेप्शन नहीं होता है,

लेकिन वर्तमान (वर्तमान) स्थिति के अनुसार।

उदाहरण: इनपुट पर एक PSD (या कई PSDs) है

अपने खुद के सीएमएस के लिए। पहले आकलन में, ऐसा लगता है कि अनुकूलन

डिज़ाइन में केवल एक कार्य "CMS पर कटिंग और स्ट्रेचिंग" शामिल हो सकता है।

हालांकि, सीएमएस केवल एक मुख्य पृष्ठ नहीं है। यह और परिणाम पृष्ठ

खोज, समाचार और लेखों का संग्रह पृष्ठ आदि। बेहिसाब पन्ने

अपनी विशेषताओं और तत्व हैं जो PSD पर और आवश्यकता में प्रदर्शित नहीं होते हैं

कम से कम एक न्यूनतम भूत में समग्र शैली के लिए। तो जरूरत है

नया कार्य - मौजूदा ब्लॉकों के डिजाइन का अनुकूलन एक नए के लिए

डिजाइन। यह कार्य तत्काल करना संभव नहीं है। वह खिंचा हुआ है

नई कार्यक्षमता सहित, ग्राहक प्रकट होता है

नए पेजों के डिजाइन के लिए नए प्रश्न और सुझाव (ग्राहक खरीद)

CMS अचानक कार्यक्षमता को सक्षम करना चाहता है

CMS में, लेकिन पहली बार में अपेक्षित नहीं)। एक आपातकालीन स्थिति निर्मित होती है

और परियोजना के समय की देखरेख। क्योंकि समय का अनुमान लगाया गया है

परियोजना की शुरुआत में दृश्य पृष्ठ (और यह कहते हैं, एक मुख्य है

पृष्ठ), लेकिन दायित्वों के लिए हमें CMS के लिए अनुकूल होना चाहिए

ग्राहक, और उसकी नई आवश्यकताओं को इस दायित्व में निवेश किया जाता है।

कार्रवाई:

1. वर्कफ़्लो: पीएम एचटीएमएल डिज़ाइन प्रदान करके

एनकोडर समीक्षा के लिए, संभावित समस्याग्रस्त पर एक विशेषज्ञ की राय प्राप्त करता है

स्थान, स्थान जहाँ डिज़ाइन कार्यक्षमता को प्रभावित करता है, समस्याएँ

ग्राहक के साथ जाँच करनी चाहिए।

2. वर्कफ़्लो: आचरण "खुले दरवाजे के दिन",

जब सहकर्मी एक दूसरे को उनकी विशिष्टताओं और विशेषताओं के बारे में समझाते हैं

काम, कठिनाइयों और उन्हें संबोधित करने के उपायों पर चर्चा करें।

3. वर्कफ़्लो आउटलाइन समस्या को हल करना

या स्थानीय विकी में स्वयं समस्याएँ (या दस्तावेज़, विवरण के रूप में,

सामान्य प्रश्न) इस प्रकार ज्ञान का आधार बनता है।

4. PM: आगामी काम के HTML एनकोडर को सूचित करें।

संभावित बाधाओं पर चर्चा करें, संभावना का पता लगाएं

कुछ अनियोजित गतिविधि, जोखिम और गतिविधियों पर चर्चा करें

उनके परिणामों को कम करने के लिए।

5. HTML एनकोडर: प्रोजेक्ट पर अपनी गतिविधि को रेट करें,

कार्य को पूरा करने के लिए सभी गतिविधियों का संकेत। प्रदर्शन

मौजूदा परियोजना ट्रैकिंग में प्रतिशत निष्पादन कार्य

सिस्टम। जोखिम के बारे में सूचित करें, के मामले में परामर्श करें

मुद्दों।

3. इस्तेमाल की गई प्लेटफ़ॉर्म की शर्तों और सीमाओं को समझना या

परियोजना

सबसे खराब स्थिति:

पीएम आवश्यकताओं से सहमत हैं

कार्यान्वयन या अस्तित्व में आसानी पर निर्भर ग्राहक

सिस्टम में समान कार्यक्षमता।

आरएम प्रणाली के केवल बुनियादी ज्ञान का मालिक है।

अच्छा अभ्यास:

आदर्श जब पी.एम.

अच्छी तरह से उस प्रणाली को जानता है जिसमें यह काम करता है (बहुमुखी है

सिस्टम के साथ अनुभव) और क्लाइंट के साथ चर्चा में निर्भर करता है

आपका अनुभव

एक अधिक यथार्थवादी विकल्प जब पीएम एक सलाहकार से संपर्क कर रहे हैं

श्रम लागत का अनुमान लगाने के लिए परियोजना (या अनुभवी डेवलपर)

चर्चा के तहत कार्यक्षमता या कार्य को बनाने (बदलने) के लिए।

प्रभाव:

प्रणाली सीमाओं का ज्ञान

क्लाइंट द्वारा कार्य को सेट करने के चरण में संभावना का आकलन करने की अनुमति देगा

और आवश्यक होने पर स्थिति को रोकने के लिए कार्यान्वयन की श्रम लागत

दायित्वों को पूरा, और इस मुद्दे को हल करने के लिए बड़ी आवश्यकता है

समय और संसाधनों के अनियोजित खर्च, अस्थिर समाधान

("बैसाखी"), आदि।

कार्रवाई:

1. वर्कफ़्लो: प्रोजेक्ट में एक सलाहकार का उपयोग करें

कार्य परामर्श (इस कार्य के अलावा वह परियोजना में कर सकता है)

भाग नहीं)।

2. पीएम: प्रोजेक्ट शुरू करने से पहले सिस्टम का अध्ययन करें, सलाह लें

सहकर्मियों (या एक सलाहकार) के साथ और पिछले कार्य अनुभव का अध्ययन करें

उनके सहयोगियों।

3. वर्कफ़्लो: आउटलाइन समस्या का समाधान

या खुद को विकी में समस्याएँ (दस्तावेज़, विवरण, अक्सर पूछे जाने वाले प्रश्न)।

4. वर्कफ़्लो: आम घटनाओं का संचालन करना

उपयोग की जाने वाली प्रणालियों में क्षमता के स्तर को बढ़ाने के लिए (ज्ञान)

एनकोडर के लिए सिस्टम और उसकी सीमाएं आवश्यक हैं। पैराग्राफ देखें 7. काम

HTML एनकोडर)।

4. निष्पक्षता।

सबसे खराब स्थिति:

पीएम सेट नहीं कर सकते

महत्वपूर्ण परिस्थितियों में परियोजना की प्राथमिकताएं, वर्तमान की व्याख्या करती हैं

परियोजना की स्थिति चीजों की वास्तविक स्थिति से बहुत दूर है। चयन

त्वरित और अक्सर साहसिक निर्णय।

अच्छा अभ्यास:

पीएम के पास और ऑफर हैं

परियोजना के पाठ्यक्रम के आपातकालीन संस्करण के लिए कार्य का क्रम,

जाँच और पुनर्व्यवस्थित स्थिति के अनुसार काम करता है, उपयोग करने की कोशिश करता है

स्थिर समाधान, संपूर्ण परियोजना को समग्र रूप से देखता है, संजोता है

निर्णय लेने से पहले परियोजना टीम के साथ (भले ही यह ज्ञात हो

कि परियोजना टीम की राय अलग होगी)।

प्रभाव:

कोई टिप्पणी नहीं

5. परियोजना और व्यक्तिगत भागों का नियंत्रण

विभिन्न चरणों में।

सबसे खराब स्थिति:

पीएम आखिर में प्रोजेक्ट की जांच करते हैं।

अच्छा अभ्यास:

पीएम ने चेक किया परिणाम

प्रत्येक चरण (मील के पत्थर) या अंत में परियोजना की प्रगति

कार्य, आदि), परिचालन नियंत्रण करता है।

प्रभाव:

प्रत्येक पर परियोजना को नियंत्रित नहीं करना

चरणों में, पीएम ओवरस्पीडिंग डिज़ाइन समय की संभावना को बढ़ाता है

और समय सीमा को पूरा करने में विफलता। स्थिति इस तथ्य से खराब हो गई है, के मामले में

वर्तमान स्थिति के लिए जिम्मेदार, अंत में निगरानी

परियोजना, पीएम के दृष्टिकोण के अनुसार, केवल एक HTML एनकोडर है (यदि कार्य है

"खिंचाव" परियोजना में अंतिम)। और यह भी तथ्य है कि आप अभी भी जरूरत है

फिर से विकास के लिए एक संसाधन आकर्षित, परीक्षण और, संभवतः,

perenatyazhki।

उदाहरण: एक परियोजना है जिसमें डिजाइन किया गया है

इसकी शुरुआत में कोई नहीं है। प्रोटोटाइप के बिना और डिजाइन के बिना विकास हुआ,

केवल कार्यात्मक विनिर्देश द्वारा। क्लाइंट को भेज दिया

डिजाइन या PSD, और फिर एक HTML एनकोडर परियोजना में प्रवेश करता है। स्थिति:

कार्यक्षमता का एक हिस्सा डिजाइन में तैयार किया गया है, जो इससे अलग है

वह जो बनाया जाता है। इसके अलावा, अंतर के कार्यान्वयन को भी खींच सकते हैं

20% -60% समय पहले से ही विकास पर खर्च किया। एक परिणाम के रूप में

- सरल HTML एनकोडर और ब्रेकडाउन डेडलाइन।

कार्रवाई:

1. आरएम: सभी चरणों में व्यायाम नियंत्रण (और

बीच में) परियोजना।

6. प्रभावी संचार।

सबसे खराब स्थिति:

पीएम ने परियोजना पर चर्चा की

प्रत्येक परियोजना के प्रतिभागियों के साथ अलग-अलग क्षण। परियोजना प्रतिभागियों

"प्रत्येक के साथ एक" भी, परिचालन संबंधी मुद्दों को संप्रेषित करें और हल करें।

IM में किसी प्रोजेक्ट पर चर्चा करने में बहुत अधिक (या इससे भी अधिक) लगता है

कार्य करने की तुलना में समय। इस पर चर्चा करने की जरूरत है

एक ही समय में (इसके अलावा) कई लोगों के साथ काम के क्षण

एक ही बात)।

अच्छा अभ्यास:

पाठ्यक्रम में सभी परियोजना प्रतिभागियों

परिवर्तन और चर्चा के विवरण परियोजना के लिए आम है।

प्रभाव:

संचार "प्रत्येक के साथ प्रत्येक" हमेशा होता है

इस तथ्य की ओर जाता है कि परियोजना पर कुछ विवरण, महत्वपूर्ण

इसके सभी प्रतिभागियों (विवरण, परिवर्तन, अनुक्रम) के लिए

कार्य प्रदर्शन, आदि)।

कार्रवाई:

1. वर्कफ़्लो: परिणामों की रूपरेखा

संचार, सभी परियोजना प्रतिभागियों के परिणामों को सूचित करें। हो सके तो

अधिकतम परियोजना प्रतिभागियों के साथ सामान्य विवरण पर चर्चा करें।

2. कार्यकर्ता

प्रक्रिया: परियोजना की बैठकों के लिए सख्त तिथियां और समय निर्धारित करना अनिवार्य है

पूरी टीम की मौजूदगी। समेटना (काटना)।

कार्य प्रक्रिया

1. एक रिपोर्टिंग निकाय, एक श्रृंखला, एक निदेशक की उपस्थिति

कार्य।

सबसे खराब स्थिति:

कई लोगों को रिपोर्ट करने की आवश्यकता है, कई स्थानों से कार्य प्राप्त करते हैं।

अच्छा अभ्यास:

किसी को जवाब देने की क्षमता

एक निश्चित व्यक्ति द्वारा (सबसे अधिक बार - परियोजना के पीएम द्वारा), पीएम जिम्मेदार है और सभी महत्वपूर्ण निर्णय लेता है,

कार्य आदि सेट करता है

प्रभाव:

कब रिपोर्ट करना है

कई लोग, फिर ऐसा दिखता है: बताओ

पहले, चर्चा करें, प्रश्नों का उत्तर दें। एक दूसरा बताओ, चर्चा करो

सवालों के जवाब। पहले वाले को बताएं कि आपने दूसरे के साथ फैसला किया है,

चर्चा करें, प्रश्नों का उत्तर दें। एक दूसरी टिप्पणी बताओ

और जो पहले (भगवान ने मना किया था कि दूसरा कोई टिप्पणी नहीं है) के साथ तय किया गया था

या सुझाव)। तो समस्या का समाधान शुरू नहीं होता है

इस पर चर्चा करने से पहले। इस तरह के कार्यों की स्पष्ट असंगति के बावजूद,

वे होते हैं। विशेष नाटक यह है कि वे बस होते हैं

सबसे inopportune क्षण में - जब परियोजना की देखरेख होती है

समय (क्योंकि पीएम के अलावा, नए प्रोजेक्ट नियंत्रण शामिल हैं

लोग उच्च नेता हैं। और उनमें से प्रत्येक की जरूरत है

अद्यतित रहें और नए निर्णय लें)।

इस स्थिति के लिए पहले पार्किंसंस कानून को नीचे रखना: अधिक

लोग एक ही समस्या में लगे हुए हैं, अधिक अराजकता।

कार्रवाई:

1. वर्कफ़्लो: एक श्रृंखला में निर्णय लें।

जितना संभव हो उतना प्रयास करें ताकि फाइनल फाड़ न हो

किसी कार्य पर कार्य करने वाला। समूह द्वारा विचार-विमर्श किया जाता है।

2. मानकों और आवश्यकताओं के साथ उपलब्धता और अनुपालन।

सबसे खराब स्थिति:

मानकों का अभाव या

उनका गैर-अनुपालन।

अच्छा अभ्यास:

उपलब्धता और मानकों का अनुपालन।

प्रभाव:

गैर-अनुपालन और मानकों की कमी

प्रोजेक्ट से प्रोजेक्ट में बार-बार वही गलतियाँ होती हैं

(विसंगतियां, विसंगतियां, समय उगता है, आदि)। उपलब्धता

मानकों से न केवल गलतियों से बचने की अनुमति मिलती है, बल्कि वृद्धि भी होती है

अंतिम उत्पाद की गुणवत्ता। मानकों का उपयोग होना चाहिए

उस बिंदु पर लाया गया जहां यह एक स्वचालित प्रक्रिया बन जाती है

और आपको ऐसा लगता है या याद नहीं है "जैसा मानक है"

और समस्या को हल करने पर ध्यान केंद्रित करने की अनुमति दी।

उदाहरण: यह कैसे लग रहा था की एक बहुत ही सरल उदाहरण

एक मामूली बात परियोजना के तर्क या समय को प्रभावित करेगी।

मानकों में से एक आवश्यक क्षेत्रों को * (तारांकन के साथ) चिह्नित करने के लिए स्वीकार किया जाता है

फ़ील्ड नाम के बाईं ओर भरने के लिए। गैर-अनुपालन और अभाव

निष्पादन पर नियंत्रण ने इस तथ्य को जन्म दिया है कि विभिन्न रूपों पर

तारों का प्रोजेक्ट हिस्सा बाईं तरफ था, दाईं ओर का हिस्सा। क्योंकि छोड़ने के लिए

चूंकि यह तर्कसंगत नहीं है, ऐसे सभी को लाने में समय व्यतीत किया गया

मानक के लिए स्थानों।

कार्रवाई:

1. वर्कफ़्लो: मानकों का परिचय और पुष्टि करें।

कुछ समय के लिए उनके अनुपालन पर नियंत्रण रखने के लिए।

3. ज्ञान के आधार, अतीत के अनुभव आदि की उपस्थिति और खेती।

सबसे खराब स्थिति:

अनुभव कहीं भी उल्लिखित नहीं है, ज्ञान आधार गायब है।

अच्छा अभ्यास:

सूचना एक कंपनी की अमूर्त संपत्ति है जिसे संरक्षित और संरक्षित करने की आवश्यकता है।

अक्सर ऐसा होता है कि एक व्यक्ति जानता है कि दूसरे क्या नहीं जानते हैं। ऐसे में

यदि यह व्यक्ति परियोजना में नहीं है, तो परियोजना का जोखिम। आधार का अस्तित्व

ज्ञान उन्नत प्रशिक्षण और अनुभव का मार्ग है।

उदाहरण : डिजिटल लाइब्रेरी, स्थानीय विकी

- ज्ञान आधार के आयोजन के अच्छे उदाहरण (समय-समय पर विषय

उपयोगी लेखों के साथ पुनःपूर्ति)।

कार्रवाई:

1. वर्कफ़्लो: प्रोजेक्ट के बाद की रूपरेखा

अन्य परियोजनाओं में पुनरावृत्ति के लिए संभावित स्थान (विवरण)

"समस्या - समाधान", कुछ कार्यों के कार्यान्वयन के लिए निर्देश)।

2. वर्कफ़्लो: प्रत्येक कर्मचारी को लाओ

ज्ञान का आधार ज्ञान और वकालत (पदोन्नति)

इसका विकास।

3. वर्कफ़्लो: एक केंद्रीकृत इलेक्ट्रॉनिक बनाएँ

इलेक्ट्रॉनिक रूप में पुस्तकों के साथ भंडारण (सर्वर पर फ़ोल्डर)। बनाने

समीक्षा, समीक्षा और सिफारिशों के साथ स्थानीय विकी में विशेष खंड

मौजूदा पुस्तकों के लिए।

अंत में, मैं आपको और अधिक दिलचस्प परियोजनाओं, नए अनुभव और अच्छे अभ्यास की कामना करना चाहता हूं।



क्या आपको लेख पसंद आया? आरएसएस की सदस्यता लें

। आगे कई दिलचस्प बातें होंगी। रुचियों के क्षेत्र में:

लेआउट, परियोजना प्रबंधन, प्रयोज्य।



स्रोत: वेब डेवलपमेंट ब्लॉग

और इसे सुधारने के तरीके