إدارة الترتيب

لنتحدث عن إدارة الترتيبات. لماذا هذا فجأة؟ نعم ، لأننا في TeamLead Conf نحب مناقشة الآلام والمشكلات ، لكننا لا ننسى الحلول. بالتأكيد كل شخص لديه مشاكل مرتبطة بترتيبات العمل.

"لا يتم تنفيذ الترتيبات ،" الكابتن Evidence

الألم معهم ، في المقام الأول ، هو أن الاتفاقات لم يتم الوفاء بها - الجميع يعرف ذلك ، حتى صديقنا ، الكابتن Evidence ، الذي سيساعدنا في هذه المقالة.

يبدو ، ما هي المشكلة؟ الكثير من الأشياء لن تسير كما نود. على سبيل المثال ، الأيام المشمسة ليست دائمًا في سان بطرسبرج. لذا ، ما هي المدينة ، يأتي الناس ، أحبها. ما لا يحدث بالطريقة التي نريدها ليس دائمًا مشكلة خطيرة حقًا.

ومع ذلك ، في هذه الحالة ، يدعي Stas Mikhalsky أن المشكلة أكثر من خطيرة. بموجب الخفض ، سوف نفهم ما يؤدي إلى حقيقة أن الاتفاقية لا يتم تنفيذها ، وكيف ، في النهاية ، جعلها غير قابلة للتدمير.


حول المتحدث: شارك Stas Mikhalsky في تطوير الويب منذ عام 1998. انتقل من مبرمج مبتدئ بيرل إلى مدير التطوير في Biglion. شارك في تطوير عشرات المشاريع بحضور كبير وقدم دعمهم.

لماذا هذه مشكلة

الأعمال والقيادة من فرقنا ونحن ، كقادة الفريق ، ننتظر النتيجة. قد لا يؤدي إكمال المهمة في الوقت المحدد إلى نتيجة ، ولكن هذه قصة مختلفة.

العمل والنتيجة شيئان مختلفان ، لكن دعنا نتحدث عن هذا مرة أخرى.

والنتيجة هي نتيجة العمل - استكمال المهام والمشاريع والمشاريع الفرعية. هناك تقسيمات مختلفة ممكنة ، ولكن بطريقة أو بأخرى ، يتكون العمل من بعض الإجراءات ، كل منها في الواقع نتيجة لاتفاق.

يبدو أن كل شيء واضح: عندما لا نقوم بإجراءات ، فإننا نخرق الاتفاقات.

دعونا ننظر في الأمثلة القياسية. الامتثال لمعيار نمط الكود هو اتفاق مع مطور معين. لا يرد الفريق بأكمله بصوت واحد: "نعم ، يا حكيمة ، سوف نلتزم بنمط الشفرة" ، لكن الجميع يقول شخصيًا إنه يعد بالالتزام به. إطلاق الإصدار يوم الجمعة أو الاثنين هو أيضا اتفاق. مهما فعلنا ، سألنا شخص ما عن هذا ، أو قررنا نحن أنفسنا أن هذا ضروري لشيء ما ، إذا كانت النتيجة متوقعة منا ، فهذا إجراء يتم اتخاذه كجزء من الاتفاقية.

- إذا قررنا أنفسنا أنهم يتوقعون منا هذا - فهل هذا اتفاق؟
- نعم اتفاق مع نفسه ولكن هذه حالة خاصة.

الآن الشيء الأكثر إثارة للاهتمام هو في الواقع عكس ذلك: اتفاقية فاشلة = إجراء فاشل.

أي ، لا يتم تعطيل الاتفاق إذا لم يتم تنفيذ الإجراء ، ولكن الإجراء الذي لم يتم تنفيذه هو نتيجة اتفاقية فاشلة . لم نفعل ذلك ، لأننا لم نوافق على ذلك ، إما أننا لا نريد حقًا ، أو شيء آخر. في المركز هي مشكلة الاتفاق. وبالتالي ، نحصل على صورة يؤدي فيها اتفاق فاشل إلى إجراء غير مُحقق ، والذي يؤثر بالطبع على جودة العمل ، وفي النهاية يؤدي إلى عدم تحقيق نتائج.

أريد أن أنقل إليكم فكرة أن المطورين ، والواجهة الخلفية ، والواجهة الأمامية ، والمختبرين ، وقادة الفرق ، ومديري التطوير ، كلها بعض الوظائف والأدوار التي نقوم من خلالها بعمل شيء ما. ولكن إذا نظرت إلى الأعلى قليلاً ، فإن كل عملنا هو إبرام الاتفاقات وتنفيذها. إنه مثل UDP - كل شيء آخر ملفوف في اتفاقية. إذا لم نكن نعرف كيفية إبرام الاتفاقيات بشكل صحيح ، فيمكننا أن نكون واجهة أمامية أو خلفية ممتازة ، ونكتب رمزًا ممتازًا ، ولكن لن تكون هناك نتيجة.

على العكس ، إذا تعلمنا كيفية إنشاء الترتيبات الصحيحة ، فعندئذٍ:

• توفير الكثير من الوقت ؛
• يقلل بشكل كبير من النفقات العامة لجميع الضوابط والتفكيك ، وما إلى ذلك ؛
• يمكننا حقا القيام بعملنا.

ما يجب القيام به

"تأكد من تنفيذ الترتيبات"

دليل الكابتن

هذا واضح للجميع ، حتى قبطان الأدلة ، ما عليك سوى التأكد من تنفيذ الاتفاقيات ، ولا تحتاج إلى القيام بذلك حتى لا يتم تنفيذها.

النموذج الكلاسيكي لكيفية تحقيق ذلك:

1. افهم الأسباب.
   
2. تحديد واتخاذ إجراءات لمعالجة هذه الأسباب وتغيير النتيجة.
   

لنتحدث أكثر قليلاً. هناك ثلاث جهات فاعلة:

1. ترتيب للتعامل معها.
   
2. اضطراب يحدث لترتيب.
   
3. أسباب الفشل.
   

إذا نظرت إلى كل هذا من جميع الجوانب ، فمن المحتمل أن تفهم ما هي المشكلة وكيفية تحسين الوضع. آمل أن الموقف يتطلب التدخل ، يتفق الجميع.

ما هو الترتيب؟

يتكون الترتيب من جزئين: الالتزام والوعد. والفرق بينهما هو أنه يتم الالتزام ، والوعد .

الوعد هو فضلات ، إنها رسالة لشخص تعهدت به. من حيث المبدأ ، لا يمكن إعطاؤها ، لأن هذه مجرد رسالة إعلام. لكنني أتعهد بهذا الالتزام. لذلك ، فإن الالتزام بدون وعد أفضل بكثير من وعد بدون التزام. نواجه هذا الأخير في كثير من الأحيان.

بصراحة ، يبدو لي أن المشكلة برمتها هي أنه ليس كلنا (ونحن أيضًا) وليس دائمًا ، عندما نبرم اتفاقيات ، نفكر في الالتزامات. نحن لا نتخذ قرارات بوعي دائمًا ونفهم حقًا ما يهددنا به هذا الوعد. نومئ فقط: "نعم ، نعم" ، سنغادر ، لكننا لا نتحمل التزامنا معنا - وهذه مشكلة كبيرة.

في الواقع ، لا يزال الأمر أكثر تعقيدًا ، لأن الترتيبات مختلفة في النوع:

• كجزء من مسؤولياته المباشرة ، على سبيل المثال ، اكتب التعليقات في التعليمات البرمجية ، أكمل الإصدار في البيئة.
• خارج العمل الرئيسي ، على سبيل المثال ، لمراقبة مدى صلة المعلومات في الويكي ، اقرأ كتابًا ، اذهب إلى الدورات التدريبية.
• غيّر السلوك ، على سبيل المثال ، ابدأ القدوم إلى العمل في ساعة معينة ، أو تابع الوقت الذي تقضيه في المهمة.

هذه اتفاقيات مختلفة تمامًا ، ويعاملها الناس بشكل مختلف ، وتحتاج إلى العمل معهم بطرق مختلفة تمامًا.

كقاعدة ، يتجاوز نطاق العمل الرئيسي الأسئلة ، والتي هي إلى حد ما أكثر أهمية ، كما يبدو لي ، من مستوى الترميز الحالي للمطور ، لأنه يمكن تحويله من خلالها. إذا كان الشخص يعرف كيف يتعلم ، فهذا يختلف تمامًا عما لو كان قد تعلم للتو البرمجة بسرعة وبدون أخطاء في 10 سنوات. في بعض الأحيان قد يكون الاتفاق مع مطور لقراءة كتاب أصعب بكثير من مطالبته بتوثيق الكود. لكن الأمر أكثر متعة عندما يتعلق الأمر بتغيير السلوك.

مثال كلاسيكي ، عندما كان من غير المهم أن تذهب إلى 10 أو 12 ، لأنه ، إذا كان أي شيء ، يمكنك البقاء والتحسين ، والآن تحتاج إلى أن تكون في مكان العمل في موعد لا يتجاوز 11 ، لأن العمليات وما إلى ذلك. إذا وافق الشخص ببساطة: "نعم ، حسنًا ، سأحضر الساعة 11 غدًا" - هذا ليس تغييرًا في السلوك ، ولكنه إنجاز. إذا اتضح أنه لهذا فمن الضروري ، ربما ، إعادة بناء الحياة - للنوم مبكرًا قليلاً أو عدم لعب Warcraft ، فهذا يعني أن الشخص نفسه يجب أن يتغير. هذا صعب ، والأهم من ذلك ، لا يمكن السيطرة عليه ، مثل أي مشروع.

لذلك ، من المهم جدًا فهم نوع الاتفاق الذي نتحدث عنه. تعتمد درجة التفصيل على نوع الاتفاق الذي نحاول إبرامه.

الاضطرابات

لا تنهار الاتفاقات فحسب ، بل تنهار ، أولاً ، بشكل غير متوقع ، وثانيًا ، عند خط النهاية - لأنها أكثر متعة. على الرغم من أن هذا غير متوقع ، إلا أنه عادة ما يكون عند نقطة يمكن التنبؤ بها. أعرف دائمًا متى ستنهار الاتفاقية.

نحن نعمل الآن في فرق ، لقد مر عصر الفردي وأجهزة الكمبيوتر المرآب. لدينا فريق وعمليات وكل ترتيب في سلسلة. إذا انهار ، فكل شيء ينهار. إذا لم يقرأ شخص ما الكتاب ، فمن حيث المبدأ ، لن يحدث أي شيء سيء أو ينقطع ، ولكن في غضون عام لن يكون فريقك فجأة أفضل من الآن. بالنسبة لي ، هذا الملف أكبر بكثير من ساعتين من فشل جميع الأنظمة.

الاختلالات مختلفة أيضًا.

الفشل هو نوع الفشل المفضل لدي ، الأكثر صدقاً والأكثر ضرراً. اتفقنا ، وعد الشخص ولم يفعل - يحدث ذلك. هذا تفصيل بسيط ، لأن كل شيء واضح معه.

هناك المزيد من الخيارات غير السارة ، مثل التنفيذ الرسمي.

التنفيذ الرسمي هو عندما يطور المطور ليلة الجمعة (لجراب البيرة للإلهام) 40 ساعة من وقت العمل للمهام التي قام بها في الأسبوع. في الواقع ، الشخص الذي أبرم هذا الاتفاق معك لا يتلقى أي شيء في الوقت الحالي. إذا لم يكن تسجيل الوقت ضروريًا للضغط على الجميع ، ولكن من أجل فهم إحصائي كم من الوقت تستغرق أنواع مختلفة من المهام ، وما هو متوسط ​​الخطأ ، وما إلى ذلك ، فإن هذا التنفيذ يفسد المبادرة بأكملها. لن تكون هناك إحصائيات ، لأن البيانات مأخوذة من الرأس. ونتيجة لذلك ، لم يتم الوفاء بالاتفاق ، على الرغم من أنه يبدو أن شيئًا ما تم القيام به ، وكل شيء على ما يرام.

تكمن المشكلة في أننا لا نسجل دائمًا تحقيقًا رسميًا كاتفاق مكسور. خاصة إذا كنت نفسك غير مهتم للغاية. على سبيل المثال ، أنا قائد فريق ، أخبرني المدير من فوق: "اكتب ساعة ، وإلا سأعاقب الجميع!" جئت إلى الفريق وبثت أنني بحاجة لتسجيل الساعة ، وإلا فسيتم معاقبة الجميع. ونتيجة لذلك ، تم تسجيل الساعة بطريقة أو بأخرى ، أنا راضٍ - لدي شيء لأريه المخرج. أنا شخصياً أشارك في هذا التخريب ، وبالنسبة لي التنفيذ الرسمي مهم. بالنسبة لموفر المهمة ، هذا غير مقبول.

يختلف الاستبدال قليلاً عن التطبيق الرسمي للنموذج ، ولكنه في الواقع هو نفس المحاولة لانتهاك الاتفاقية. فقط بدلاً من رؤية المهمة المكتملة ، يتم إنشاء بديل. باستخدام مثال تسجيل الوقت ، يبدو الأمر كالتالي: "لتسجيل وقت كل مهمة ، أحتاج إلى 5 دقائق. في المجموع ، هذه ساعتان في الأسبوع. يا له من جيد. لقد قمت بمهمة لم أكن أنوي القيام بها خلال 4 ساعات. لكنني فعلت أكثر مما وعدت به ، ولم أكن أفكر في الوقت.

هذه محاولة لإعطائك شيئًا بحيث تكون متأخراً في الشيك ، ولكنها في الواقع أيضًا انهيار. المشكلة هي أنه ، كقاعدة عامة ، لدينا مجموعة من الأشياء الأخرى ، الوقت غير المضمون ليس أسوأ شيء. نحن نتغاضى عن أنفسنا.

أكرر: الاتفاق المعلق هو ناقص العمل ، والنتيجة ناقص.

كيف تنجو في عالم من الترتيبات التي لم تتحقق؟

يمكنك أن تذكر ببساطة: "هل تتذكر أننا نسجل الساعة؟". عندما يتعلق الأمر بتغيير السلوك ، فإن التذكير هو مخطط جيد. أكثر الملصقات تعليقًا ماكرة تدعم نموذج السلوك: "الوقت المتعهد - وفر القندس!". في الواقع ، نذكرك ببساطة أنه كان هناك اتفاق ، دون التحقق من حالته في الوقت الحالي.

يمكنك أن تكون أكثر ثباتًا قليلاً وتسأل عن كيفية تنفيذ الاتفاقية ، سواء كان الشخص قد فعل شيئًا بالفعل. هذا يختلف عن تذكير في أنه يجبرك على إعطاء نوع من الإجابة المفصلة. لكنك تضع الشخص قبل الاختيار: أن تكذب أو لا تكذب. الإجابة ، بالمناسبة ، ليست واضحة للجميع. بمعنى ما ، أنت تدفع الشخص إلى السيء. السؤال هو نوع كامن من التحكم - يبدو أنه تم طرحه ، ولكن لم يتم التحقق منه. كذب الرجل ، لكننا تركناه في ضميره.

يمكنك التحقق من :

• بالنتيجة ؛
• خطوة بخطوة
• على الديناميات.

التحقق من النتيجة التي ناقشناها بالفعل. السؤال هو ماذا نفعل إذا كانت النتيجة غير مرضية ، لكننا سنعود إلى ذلك لاحقًا.

من خلال الخطوات والديناميكيات ، من الممكن التحقق من تحقيق اتفاق داخل العمل وخارجه. على سبيل المثال ، أقنعنا شخصًا بملء قاعدة معرفية ، ووضعنا مخططًا للخطة معه ، ونذهب وفقًا لهذه الخطة - لا يزال هذا قد زال. ولكن ماذا عن تغيير السلوك؟ الشخص إما يسجل الوقت أو لا يسجل ؛ إما يأتي في الوقت المحدد أم لا. من السخف تتبع هذا التحول بالخطوات والديناميكيات - اليوم تأخر نصف ساعة ، غدًا 25 دقيقة ، بعد غد 20.

أكبر مشكلة في التحقق هي أن هذا ليس ممكنًا دائمًا. وبالنظر إلى أن الاتفاقات تتم طوال الوقت ومع العديد من الأشخاص ، فإن هذا أيضًا يتطلب الكثير من العمالة .

نموذج إداري يقضي فيه المدير كل الوقت تقريبًا على التحكم في تنفيذ المهام ، ولكنه لا يعمل بشكل جيد في تكنولوجيا المعلومات. نعم ، وهذا هو القرن الماضي. آمل أن يموت مثل هذا النهج للإدارة يومًا ما ، مثل الديناصور الأخير.

بدلاً من التحكم ، دعنا نفهم بشكل أفضل سبب حدوث الانهيار فعليًا - لماذا لم يفي الشخص الذي وعدنا به.

أسباب الانهيار

ربما تكون هذه قائمة غير مكتملة ، ولكن فيما يلي الأمثلة الأكثر بروزًا:

• موافقة غير معقولة. يوافق المرء على ذلك ، لأنه من المحرج أن يرفض: أنت قائده أو مجرد شخص محترم ، أو يريد بصدق مساعدتك ، إنه يحبك ، أو لا يحب أن يرفض على الإطلاق.
• خطأ في التقييم. قد يفكر الشخص ويوافق ولكن يخطئ في التقييم. ثم يأتي ويقول: "نعم ، لقد وعدت ، لكن العمل كان ضعف ما توقعت".
• تغيير الأولويات: "انتهيت تقريبا ، ولكن بعد ذلك جاء Vasya ، لديه مشكلة أكثر أهمية ، لذلك أنا آسف".
• نقص الموارد - فقط ليس الوقت الكافي.
• ظروف غير متوقعة - سقط البيانو من فوق.
• التخريب

غالبًا ما يكمن وراء كل الأعذار ملك الاتفاقات المحبطة - التخريب . عندما لا نريد أن نفعل ولا نريد أن نعترف بأننا لا نريد أن نفعل ذلك ، نحصل على التخريب. شرب 40 ساعة في الأسبوع للمهام باستخدام طريقة الوخز هو التخريب. إن القدوم إلى العمل في الساعة التاسعة صباحًا وشرب القهوة يعد تخريبًا. إنه يقوم على إحجام عن القيام به ، وهو ما لم يتم التعبير عنه صراحة.

في الواقع ، هناك أسباب أكثر منهجية للانهيار . ما قلناه يكمن على السطح ، وإذا تحفر بعمق ، فهناك ثلاثة أسباب فقط:

1. نوع الترتيب لا يؤخذ بعين الاعتبار.
   
2. لم يتم الاتفاق على نوع الترتيب.
   
3. وعد بدون التزام.
   

علاوة على ذلك ، قد تكون الفقرة الأولى والثانية موجودة في نفس الوقت. عندما نبرم اتفاقية ، لا نفكر فيما نتفق عليه. غالبًا ما يبدو هذا كالتالي:

- Aegeus ، افعل ذلك!
- حسنا ، سأفعل ذلك! - وهرب.

يمكن القيام بذلك عندما نتحدث عن العمل في العمل ، على سبيل المثال ، حول كتابة وحدة نمطية: "تنفيذ المهمة 28 بسرعة." لكن هذا لا يمكن القيام به عندما يتعلق الأمر بالتحضير لاجتماع في تجمع على سبيل المثال. بطريقة جيدة ، من أجل إعداد خطاب في اجتماع ، تحتاج إلى الجلوس ، وتصنيفه ، وشرح مدى أهميته ، وما إلى ذلك. ولكن غالبًا ما نقوم بكل شيء بنفس الإيقاع : "افعل هذا" أو "انظر ، لا تتأخر بعد الآن!" - وركض .

يحدث أننا نتفق ، كوننا في فهم مختلف حول نوع الاتفاق. مثال كلاسيكي هو توثيق التعليمات البرمجية. في الماضي ، ربما تغير كل شيء ، ولكن عندما صادفت هذا الأمر ، كان لدي أنا وزملائي نقاش مستمر حول ما إذا كان يجب على المطور توثيق الرمز أم لا. كقائد ، أعتقد أنني يجب أن. يعتقد المطور أن الشفرة تعمل جيدًا ، نظرًا لعبء العمل والأولويات المتغيرة باستمرار.

لا يتم الكشف دائمًا عن تضارب في فهم نوع الترتيب. غالبًا ما نعتقد أن هذه الاتفاقية لا تحتاج إلى توضيح ، وتعزيز ، لأن كل شيء واضح بالفعل: فقط خذها وافعلها. يعتقد المرؤوس أنه يريد منه من فوق ما لا يريد أن يفعله. ثم يبدأ التخريب .

الوضع الأكثر شعبية ، كما قلت ، هو وعد بدون التزامات. الاتفاق الذي أدى إلى الوعد ، لكنه لم ينشأ عنه التزام ، لن يتم الوفاء به لسبب أو لآخر: سوف يسقط البيانو ، وسيشتت انتباه الشخص ، وسيحدث شيء آخر.

في الواقع ، في ظروف تعقيد الأنظمة ، شدة التغييرات: عندما نكتب جميعًا في عجلة من أمرنا ، نطرحها بسرعة ، ونعيدها ، وبعبارة أخرى ، في ظروف الكون ، يمكن أن يحدث شيئًا دائمًا يمنع تنفيذ الاتفاقية. بالطبع ، يمكنك التحكم في كل خطوة ، وتسخير كل حالة لكل من مرؤوسيك ، ومحاولة مساعدته على تنفيذ اتفاقنا. ولكن بعد ذلك لن يكون هناك ما يكفي من الوقت لأي شيء أكثر من سحب كل شيء بنفسك.

الفرصة الوحيدة لتحقيق الاتفاقية هي أن الشخص يريد تحقيقها.

إذا كانت لدي رغبة في تنفيذ الاتفاقية ، فسوف أتعامل مع جميع المشاكل التي تطرأ: مع البيانو المتساقط ، وحقيقة أنني أخطأت في التقييم ، وما إلى ذلك.

هذا مشابه لإيديولوجية سكروم ، تمامًا مثل تعقيد المهمة غير معروف تمامًا. نجري بعض الافتراضات مع وجود خطأ في التجربة السابقة ، ثم نقوم بالتقييم ، ثم نقوم بكل شيء لإغلاق الركض. نحن نقر بأن نعم ، سيكون من الصعب ، أن نرتكب خطأ في مكان ما في التقييم ، وأن النظام قد يفاجئنا ، لكننا سنفعل ذلك فقط لحل المشكلة.

مع الترتيب ، يجب أن يحدث نفس الشيء كما هو الحال مع العدو السريع في سكروم. الشخص الذي التزم بفعل شيء ما عليه فعل ذلك. كل شيء بسيط!

تلخيص ما قيل عن أسباب فشل الاتفاق:

• الوعد ليس ضمانة.
• السيطرة صعبة.
• يتم الكشف عن الفشل على الحقيقة.

من الواضح ما يجب فعله: ما عليك سوى إنشاء اتفاقيات دائمة يسهل إدارتها والذهاب أخيرًا إلى جزر البهاما.

دليل الكابتن

بمعنى آخر:

• كما هو - يبدو النظام الآن على هذا النحو: ترتيبات هشة إلى حد ما يصعب إدارتها.
• لتكون - يجب أن تكون: اتفاقيات غير قابلة للتدمير ، تكون إدارتها شفافة وليست شاقة.

بالنسبة لموقف تحليل GAP القياسي ، "أن نكون" هو الهدف النهائي الذي نسعى إليه ، ولكن ليس حقيقة أننا سنصل. لكن يجب أن نسعى.

يبقى تحديد ماهية الاتفاق القوي وكيفية إدارته.

اتفاق قوي

اتفاق قوي - هذه التزامات حقيقية يتم إبرامها مع شخص ملزم. هذا مهم جدا. تحدثنا عن الالتزامات ، مثل بعض الحزم التي يجب نقلها ، والآن سنتحدث قليلاً عن شركة نقل هذه الحزمة.

تؤدي الترتيبات التي تتم مع شخص اختياري إلى تناقضات. إذا كنت تتخيل العمل في شكل دفق من الاتفاقيات التي يتم إرسالها في اتجاهات مختلفة على دفعات ، فعندما تحاول إبرام اتفاقية مع شخص اختياري ، كن مستعدًا لحقيقة أنه مع احتمال 50٪ ستضيع الوقت. لذلك ، فإن أول شيء نبدأ به هو زيادة سعر الكلمة.

سعر الكلمة

يجب أن يفهم كل من زملائك بشكل مثالي أن التزامات الخدمة هي وظيفتهم الرئيسية. هذا هو جوهر عمله. الشفرة المكتوبة ، الإفراج المفرغ هي مشتقات للوفاء بالالتزامات. لذلك ، أحاول التحدث مع الناس على وجه التحديد حول الالتزامات وأن المشكلة ليست في عدم كتابة الرمز أو عدم وجود نتيجة. هذا نتيجة والكثير من الألم. لكن جوهر المشكلة هو أننا بعد القيام بالالتزام ، لم نجد طريقة لتحقيقه.

, , , . , , , , « — — — » . , , — , , , .

, , . - . , , 10 3. , — .

, .

, — . — , .

, , .

, — : « , ».

— , . , — . , .

— . , .

, , , .

, - — .

« » . , — . , , . , . , - . , , , , :

1. , .
   
2. , .
   

, , . — — , . - . , , , . , . .

, , «» :

• .
• .
• .

— , , , , , .

, . , .

, .

. , , : , , . , , , , . , — , - , . — .

, . — , «» . , — . - , . :

— , !
— .

-: «, , . 10:55. , ».

, , 5 — , , . , : , .

— — , .

?

, : ? 4 , , - :

1. ?
   
2. ?
   
3. , ?
   
4. , ?
   

. , . , .

: «, - , , , !» , , , .

, . . - , , , , .

« » . — . , , — .

« » , - , . , , — . , . , , .

, :

• .
• .
• , , — , .
• « » . , .

, Excel, : , , , . , .

?

, , , . , …

? ? — : — , — , — .

, «» , , . «» — - . « » , « ?» « ?»

…

, TeamLead Conf , , . . , , , Call for Papers .