نستمر في مشاركة مقتطفات من
دليل البقاء على قيد الحياة للتقليدية المبتدئة من J.H. Rainwater. في السلسلة الأولى ، تحدثنا عن سلالات المطورين الذين عادة ما يتعين على المدير التعامل معهم ؛ الآن دعونا نحاول فهم ما يجب القيام به مع كل هذه الحديقة. يمكن تقسيم الأنشطة التنظيمية في الفريق الفني إلى قسمين - أشياء محلية أو أكثر (مثل مراجعات الكود وإدارة الهندسة المعمارية) وكل ما لم تستعد له حياة المبرمج - أي إدارة الأفراد والعمليات. دعونا نتعامل مع شخص غريب أولاً.
ترتيب الأولويات
أول ما يقرع عادةً قائدًا طازجًا هو انهيار ضخم من المعلومات الأكثر تنوعًا. هذه الحالة منطقية تمامًا: فالأشخاص الذين هم على رأس الفريق أقل انغلاقًا في إطاره ويشاركون في مزيد من العمليات ، لكنه لا يصبح أسهل. ونتيجة لذلك ، يبدأ القائد التقني في الغالب في التفريق - بالنظر إلى واجبه في الرد على كل إشارة ، ينتزع كل شيء دفعة واحدة ، ويقفز من مهمة إلى أخرى ويفتقد ما يحتاج إلى مزيد من الاهتمام.
لا يوجد سوى مخرج واحد - لتصفية دفق المعلومات هذا ، وفصل ما يرتبط مباشرة بالمهمة الرئيسية (إصدار رمز يلبي المتطلبات التجارية ، مع موعد نهائي متفق عليه) ، وإرسال المسار الرئيسي إلى backlog. لكن في البداية ، قد لا تكون معايير الفرز واضحة. للمبتدئين ، يبدو كل شيء مهم.
تعقيد الأمور هو حقيقة أن العديد من المحفزات تثير العواطف التي تمنع إجراء تقييم معقول لأهمية وإلحاح المشكلة. يمكن أن تسبب الإشارات الواردة اهتمامًا (تم العثور على شذوذ غريب في الكود) ، والشعور بالذنب (يتذكر المصمم أنه طلب بالفعل عدة مرات لتنفيذ الوظيفة التي يريد تنفيذها) ، وإخافة (يعبّر المستخدم عن استيائه من التحديث).
من أجل تنظيم جميع الطلبات والمعلومات بنجاح أكبر ، يقترح المؤلف استخدام المصفوفة التالية لمعالجتها:
- كيف تؤثر البيانات الجديدة على نطاق المشروع ، وقرار التصميم ، والموعد النهائي للمشروع؟
- هل مصدر المعلومات موثوق به؟ إذا لم يكن كذلك ، فهل يمكن تجاهله؟
- هل يجب علي الرد على استلام المعلومات على الفور أو هل يمكنني الانتظار قليلاً؟
- أين وكيف لحفظ المعلومات بحيث إذا لزم الأمر يمكن معالجتها بسرعة؟
- ما هي فترة صلاحية المعلومات؟ متى تصبح غير ذات صلة؟
- كيف تقارن هذه المعلومات مع ما هو معروف بالفعل عن المشروع؟
كما ترون ، تساعد هذه المصفوفة على فصل الحبوب عن القشر من عدة جوانب: التخلص من المعلومات عديمة الفائدة أو غير الموثوق بها ، ودفع ما يمكن نقله مرة أخرى ، وتقييم أهمية المعلومات بدقة للمشروع الحالي. ومع ذلك ، فإن الأسئلة حول التوقيت وطريقة التخزين تشير إلى أن المعلومات غير ذات الصلة في الوقت الحالي يجب ألا تُرفض باعتبارها غير مهمة من حيث المبدأ - وهذا تطرف آخر من شأنه أن يقود الفريق إلى الركود على المدى الطويل. سنتحدث أكثر عن هذا لاحقًا ، عند مناقشة مفاهيم "القيادة" و "القيادة".
مشاريع مترامية الاطراف
نقطة الألم التالية هي تقييم الأحجام وشروط العمل. مرة أخرى ، لبعض الوقت ، يكون "السباحة" في هذا المجال أمرًا حتميًا تقريبًا للتزلج المبتدئ - هناك حاجة إلى الخبرة لتتمكن من مراجعة جميع مكونات المشروع في وقت واحد ، وليس في عداد المفقودين أي شيء ، ومن أول محاولة لتعيين كل نوع من أنواع العمل ، بما في ذلك مصطلحات غير مألوفة وكافية. ولكن حتى الخبرة المكتسبة لا توفر من خطأ معين ، ولا يمكن تقليله إلى الصفر. يعيق قانونان وضعا الدقة القصوى في تخطيط العمل على النحو المناسب:
ستستمر أي عملية أطول مما تتوقع. يبدو دائمًا أن شيئًا ما لم تفكر فيه.
بناءً على كل هذا ، يدعو المؤلف إلى معالجة المشكلة فلسفياً. على الأرجح ، كتقريب أولي ، لن تتمكن من مراعاة أي وظائف أقل وضوحًا أو تعقيدات لا يمكن التنبؤ بها ، وستتطلب موردًا إضافيًا لم تقم برهنه. لمثل هذه المفاجآت ، يجب أن تكون مستعدًا وأن تعد فريقًا - لتعليم الناس إعادة البناء بسرعة من أجل "تصحيح الثغرات" ، وتركهم قليلاً من الوقت في الحجز لظروف غير متوقعة. ما لا يمكن القيام به على أي حال هو اعتبار النمو الطبيعي حالة طارئة والبحث عن المذنبين ، لا سيما في الإدارات الأخرى (وهذا يبدو دائمًا مغريًا). لذلك أنت فقط تزرع العداوة بين الفريقين ولا تفعل شيئًا لحل المشكلة.
ومع ذلك ، لا ينبغي للمرء أن يقع في القدرية الكاملة: نمو المشروع مع ذلك هو عيوب في التخطيط. لن تكون قادرًا على التخلص منها تمامًا ، ولكن يمكنك وينبغي عليك تقليل التركيز.
إذا نقلنا قوانين همفري إلى حقائق مبرمج ، يصبح من الواضح أن التخطيط يتدهور لسببين: التحليل غير الكافي للتفاصيل والتقديرات المتفائلة غير الضرورية لمدة تصميم منتج البرنامج. عادةً ما يتجول التفاؤل بين المديرين بطريقة طبيعية: بعد عدة مرات من المواعيد النهائية المحددة ، ستبدأ في اللعب بأمان. بالنسبة إلى التفاصيل ، تأتي هذه المهارة أيضًا مع الخبرة ، لكن من المفيد منذ البداية الحصول على فكرة عامة عن الشكل الذي ينبغي أن تكون عليه خريطة الطريق.
على سبيل المثال ، إذا شرعت في مشروع مسلح بمثل هذه الوثيقة ، فستكون هناك العديد من الكوارث الطبيعية والمتاعب أمامك:
إذا كانت خريطة الطريق أكثر تشابهًا للعينة الموضحة أدناه ، فستتزايد فرص تحقيق نتائج سعيدة بشكل كبير:
بالإضافة إلى هذين السببين ، تسرد Rainwater بعض عوامل الخطر الإضافية التي أبرزها Robert Glass ، مؤلف كتاب حزين حول مشاريع الكوارث في مجال تكنولوجيا المعلومات:
- مواصفات غير كافية لأهداف المشروع
- تطبيق التكنولوجيا الجديدة لهذه الشركة
- منهجية إدارة المشاريع السنوية / المفقودة
- عدم وجود كبار الخبراء في المجموعة
- تعطيل الاتفاقيات من قِبل الشركات المصنعة للأجهزة / البرامج
بحث لغة مشتركة
قد تعتقد أننا نتحدث عن مهارات الاتصال للمواهب التواصلية - ولكن لا ، فإن معنى العنوان أكثر حرفية بكثير. في شركات مختلفة ، يتم تشكيل فرق من المبرمجين على أسس مختلفة. إذا كنت محظوظًا ، فقد تكون مسؤولاً عن الأشخاص الذين يعملون مع مجموعة التكنولوجيا الأصلية الخاصة بك. ولكن في كثير من الأحيان تأتي فرق مختلطة ، حيث يتحدث الموظفون المختلفون لغات مختلفة. هذا الارتباك في بعض الأحيان يجعل الحياة صعبة على القائد.
تتمثل إحدى مهام الريادة في الإشراف على جميع أنشطة الفريق ، للتأكد من أن جميع الشفرات التي تدخل العالم تعمل بجودة عالية وبدون تعقيد مفرط. إذا لم تكن على دراية بالأدوات التي يستخدمها مرؤوسوك عند التطوير ، فستكون يديك مقيدتين. لا يمكنك إجراء مراجعات الكود بشكل مستقل ، فسوف تتعرف على الأخطاء الخطيرة فقط في مرحلة الاختبار ، والتي تقرع إيقاع العمل برمته ، وبصورة تقريبية ، من الأسهل بكثير قيادة السيارة عن طريق الأنف.
ماذا تفعل في هذه الحالة؟ بشكل عام ، هناك طريقتان. إذا كانت مجموعة اللغات والتقنيات ليست كبيرة ومتغيرة ، فلا يمكنك أن تدخر أي وقت وتحاول إتقانها على مستوى أساسي على الأقل. ربما تكون هذه هي أفضل طريقة للخروج - لذلك لا يتعين عليك الاعتماد على أي شخص ، ستتلقى المعلومات مباشرةً ، مما يعني أنه يمكنك تجنب "الهاتف الميت" عند مناقشة الوظائف والمتطلبات والمواعيد النهائية.
إذا لم يكن من الممكن تعلم اللغات اللازمة بنفسك ، فسيتعين عليك البحث عن طرق لتفويض هذه المسؤولية. قم بتكوين نواة المساعدين الذين يمكنهم تزويدك بتعليقات موضوعية وصادقة على كل تقنية غير مألوفة (إذا امتلكها موظف واحد فقط ، فلن تنجح هذه الطريقة بشكل طبيعي).
تعميق معرفتك في القضايا المتعلقة بالتقنيات والأدوات مفيد أيضًا لسبب آخر - هذه هي الطريقة الوحيدة لتصبح رائدة تقنيًا بالمعنى الكامل للكلمة. في نظامه المصطلحات ، يقسم المؤلف مفاهيم "المدير" و "الزعيم". المدير هو الذي ينظم العمل ، ويحل المشاكل اليومية ويتأكد من أن المهام الحالية قد اكتملت في الوقت المحدد وبشكل صحيح. القائد هو استراتيجي يفكر خارج المواعيد النهائية للتحكم ، ويحدد الاتجاه العام للحركة لفريقه ، ويثير العائق ، ويعيد التفكير في العمليات ويحسنها. بطبيعة الحال ، في فريق التطوير ، يتطلب هذا العمل البصري معرفة جيدة بسوق التكنولوجيا. في الخلفية ، يقدّر الرائد التقني باستمرار أن مجموعة الأدوات الحالية قديمة ويجب استبدالها ، وتراقب المنتجات الجديدة ، وفي الوقت نفسه لديها نظرة واسعة بما يكفي لتقييم مزاياها الحقيقية (وليس الوقوع في متلازمة ستانت).
في الجزء الأول من المقال ، تحدثنا عن حقيقة أن القائد لا يحتاج إلى القلق من أنه سيتسرب من العمل مع التكنولوجيا - وبالنسبة لأولئك الذين يصنفون القادة ، فإن هذا الأمر كذلك بالفعل. لكن من المنطقي هنا تكرار التحذير من نفس المكان: لا تأمل في نفس الوقت للتهرب من مسؤوليات المدير. تنطوي الإدارة على تحقيق التوازن بين الدورين ، اللذين يتعارضان في بعض الأحيان ، ولكنهما يظلان متساويين تقريبًا (الإدارة أدنى إلى حد ما) الضرورية لبقاء الفريق. صقل المهارات التنظيمية لصالحك - فكلما قل الوقت الذي يستغرقه الروتين ، كلما زادت سرعة نموك كخبير فني. إذا تم ترك المهام اليومية للصدفة ، فسوف تسود الفوضى ولن تكون هناك أية إستراتيجية بعد الآن.
قطيع قطف
ننتقل الآن إلى المجموعة الثانية من المشاكل - العمل الشهير مع الناس. لنبدأ من البداية: قبل أن نتحدث عن كيفية إدارة مورد بشري ، تحتاج إلى معرفة مكان الحصول عليه. حتى إذا كنت قد حصلت على الفريق الذي تم تأسيسه ، فسوف يثار السؤال عاجلاً أم آجلاً حول تعيين الموظفين. في وقت سابق ، قمنا بتحليل أنواع المبرمجين وأشارنا إلى أولئك الذين يجب ملاحقتهم في المقام الأول. أنت الآن بحاجة إلى فهم كيفية التصرف من أجل تحديد الصفات اللازمة في المرشحين وعدم خيبة أملهم في اختيارهم.
يقدم المؤلف التوصيات التالية للمقابلات:
- إعطاء المرشح مهمة اختبار. حدد لموظف محتمل مهمة سيتعين عليه حلها على الفور ، أو نقلها إلى منزله وحلها في الموعد المحدد.
- تأكد من إجراء اختبار شفوي لمهارات المرشح - حتى تتمكن من تقييم معرفته وقدرته على التفكير بوضوح في المواقف العصيبة.
- قدر الإمكان ، اكتب واجبات الموظف المطلوب ، وجميع المهام التي يتعين عليه القيام بها ، وإعطاء هذه القائمة للمرشح للمراجعة. وهكذا تصبح المحادثة على الفور أكثر موضوعية وكقاعدة عامة أكثر صراحة.
- لا تقصر نفسك على اجتماع واحد. سيكون من الجيد جدًا أن يتواصل المرشح معك ليس فقط ، ولكن أيضًا مع "الأساس" المذكور أعلاه - مساعديك ونوابك والمطورين الرائدين في الفريق. لكن ترتيب عرض مع الفريق بأكمله لا يستحق كل هذا العناء ، فهذا كثير جدًا بالفعل.
- يعد التحقق من الصفات الشخصية والاختبارات النوعية وما شابه ذلك خطوة ممكنة ولكنها اختيارية. لا تلجأ إليه إلا إذا لم يعارض المرشح ولديك أدوات تقييم موثوق بها.
عند الحديث عن التوظيف ، لا يسع المرء إلا أن يذكر الجانب الآخر - إقالة العمال الذين سحبوا الفريق إلى أسفل. هنا تأخذ Rainwater موقعًا صعبًا إلى حد ما وتنصح دون تردد بالتخلص من أولئك الذين أظهروا عدم كفاءة أو إشكالية. أفضل موقف هو سياسة التحذير الواحد: إنها تمنح الشخص فرصة للتحسين ، ولكنها لا تسمح بإساءة استخدام هذا الحق. إذا وقع أحد الموظفين في "القائمة السوداء" وتحدثت معه ، فأنت بحاجة إلى الإشراف على نجاحاته الإضافية بعناية خاصة. وهذا يتطلب بذل جهد إضافي ، لذلك فإن إعطاء فرصة ثالثة هو التبذير غير المبرر بالفعل.
بالإضافة إلى ذلك ، ليس فقط "السبب المشترك" المجرد يعاني عادة من إهمال أحد أعضاء الفريق ، ولكن أيضًا أشخاص محددين للغاية يتعين عليهم تصحيح أخطائه أو تحمل حقيقة أنه يفسد نتائج عملهم. التساهل المفرط ، بالتالي ، يتم دفعه على نفقتهم ومن غير المرجح أن يعزز مركز قيادتك.
تنظيم عمل الموظفين
بيئة معيشية مريحةالكتاب يولي الكثير من الاهتمام لهذا الجانب. إن تحقيق أقصى إنتاجية من موظفيك هو مسؤولية مباشرة للزعيم ، لكن الإنتاجية العالية تتطلب تركيزًا كبيرًا ، ويكون التركيز مستحيلًا إذا كان المبرمج محاطًا بمهيجات من جميع الجهات. لذلك ، يجب على القائد بذل كل ما في وسعه لتزويد الفريق بظروف عمل جيدة.
التوصيات المحددة لتصميم مكتب توفره مياه الأمطار في الأماكن تبدو مثالية إلى حد ما (على سبيل المثال ، في مكتب منفصل للأخ) ، وفي أماكن تبدو وكأنها أصداء لماضٍ بعيد وصعب (يجب أن يكون لدى كل مطور جهاز كمبيوتر خاص به). ولكن لا يزال المبدأ العام معقولًا وقابل للتطبيق: لكي ينجح المبرمجون في أنشطتهم ، يجب أن تتاح لهم الفرصة ، من ناحية ، للعمل في فريق لبعض الوقت ، ومن ناحية أخرى ، لغسيل المخ وحده. لأول مرة تحتاج إلى أماكن تدريب مجهزة بشكل مناسب: قاعات اجتماعات مع أجهزة عرض ، وفرق ترفيهية (من الناحية المثالية) مع طاولات تنس سيئة السمعة أو أجهزة ألعاب. بالنسبة للثاني ، من الضروري تنظيم المساحة المتاحة بحيث يجب صرف انتباه الناس بأقل قدر ممكن عن الضوضاء والوميض والروائح وعوامل تشتيت أخرى. إذا كانت الظروف سيئة ، فدع الموظفين ، وخاصة أولئك الذين يتمتعون بقيمة وموثوقية ، يعملون من المنزل.
يشتمل الحد الأدنى الإلزامي من وسائل الراحة أيضًا على معدات حديثة وعالية الجودة ، والتي يمكن للمطور تكوينها وفقًا لتقديره الخاص. إذا كانت السيارات ضعيفة وعفا عليها الزمن ، فليست هناك حاجة للتحدث عن الاختراقات التكنولوجية ، وليس لديك فقط عملية هادئة خالية من المتاعب. بالنسبة لبرامج الاختبار ، يجب تخصيص أجهزة خاصة تعيد إنتاج خصائص المستخدم القياسية.
ساعات العملتشير كومة واجبات المستشار الفني ، التي حددناها ، إلى أن مدة يوم عمله يجب أن تتضاعف تقريبًا. ولكن هنا يجب أن تكون حذرا. المشكلة هي أنه مع نظام العمل الخاص به ، فإن المدير نفسه ، عن غير قصد ، يحدد النغمة للإدارة بأكملها. إذا جلست في وقت متأخر ، فسوف يفترض العمال أن هناك شيئًا مماثلاً منهم أيضًا. نتيجة لذلك ، يمكن للمعالجة أن تدخل جسد ودم ثقافتك المحلية - وهذا محفوف بالمشاكل.
أولاً ، لن يكون الجميع سعداء بهذا الوضع. بادئ ذي بدء ، سوف تصل المعالجة إلى من يتحملون عبء التزامات إضافية ، مثل الالتزامات العائلية. إذا كان هناك العديد من هؤلاء الأشخاص ، فسيكون الوضع في الفريق متوتراً. حسناً ، وثانياً ، يشير المؤلف ، مثل كثيرين من بعده ، إلى أن ساعات العمل الإضافية من المرجح أن تضر بالإنتاجية - بسبب التعب وبسبب انخفاض الدافع. من الحكمة طلب عمل فعال من المدرسة في الدرس أكثر من غرس العادات التي تؤدي إلى الإرهاق.
توزيع المهام والإشراف عليهادعونا نكون صادقين: حتى الظروف المثالية والجدول الزمني اللطيف في حد ذاته لن يشجع الناس على التنظيم الذاتي والعمل الدؤوب. من بين أمور أخرى ، هناك حاجة إلى رئيس لتوزيع العمل والتأكد من تنفيذه. يجب السيطرة على جزء من وقتك عن طريق التحكم - بالمناسبة ، هذا يساهم أيضًا في التركيز.
ينصح المؤلف بعدم تقسيم "فترات الإبلاغ" أكثر مما يجب على المرؤوسين ، وليس خنقهم بمراقبة مستمرة مع طلب يومي للنتائج. من الحكمة تحديد قائمة المهام لكل أسبوع وتقييم مقدار العمل المنجز خلال نفس الفترة. في الفترات الساخنة بشكل خاص ، سيتعين تعديل القوائم حتى في هذا الفاصل الزمني الصغير نظرًا للأمور العاجلة الناشئة والتغيرات في الأولويات. يجب على القائد أن يضع كل هذه التغييرات في الاعتبار (وفي الواقع الحديث - وأن يضعها في النظم المحاسبية المناسبة).
إذا جاء قائد إلى فريق "أجنبي" مع إيقاع عمل قائم بالفعل ، فمن الجدير أن نطلب من كل موظف أن يرسم مهامه المعتادة بنفس الطريقة. يمكن أن تكشف مثل هذه الوثائق عن الكثير من الأشياء المثيرة للاهتمام - ليس فقط من وماذا تشارك وكيف تم تنفيذ الإدارة من قبل ، ولكن أيضًا ما يفكر فيه الناس عمومًا بشأن مسؤولياتهم.
أما بالنسبة لمحتوى هذه القوائم ، بطبيعة الحال ، في كثير من النواحي سيتم تحديدها من خلال مهارات الموظفين ومتطلبات الشركة. ولكن مع كل هذا ، يطور الكتاب فكرة أنه من الضروري تدوير المهام إلى أقصى حد ممكن - يجب ألا يقوم المطور بالقيام بنفس الشيء من أسبوع لآخر. هناك عدة أسباب لذلك. أولاً ، إنه يساعد في الحفاظ على مناخ صحي في الفريق: لا توجد أي جريمة بسبب حقيقة أن شخصًا ما يحصل دائمًا على أكثر الأشياء غير السارة أو ، على العكس من ذلك ، الأشياء الأكثر إثارة للاهتمام ، وأقل إحساسًا بالروتين والرتابة في العمل. ثانياً ، يحتاج المبرمجون إلى البقاء في حالة فكرية جيدة - حيث تسهم مجموعة متنوعة من المهام في هذا الأمر. أخيرًا ، مع مثل هذا التناوب ، ستكون هناك حاجة إلى الحد الأدنى من الجهد لتشكيل مقاعد البدلاء.
Reinwater تعلق أهمية كبيرة على مقاعد البدلاء. الفكرة الرئيسية هنا هي أنه في حالة المرض ، أو الإجازات ، أو الإقالة ، أو الوفاة المفاجئة لأي من المطورين ، يجب أن يضم الفريق أشخاصًا قادرين على أداء وظائفهم - على الأقل لتلك الفترة ، حتى يوظفون بديلًا. هذا لا يضمن التشغيل السلس للقسم فحسب ، بل يتجنب أيضًا بعض المشكلات الأخرى (على سبيل المثال ، الاعتماد الحاد للشركة على المعالجات). وفقًا لذلك ، من الضروري الحفاظ على اهتمام الموظفين بالتكنولوجيات ذات الصلة ، بكل طريقة ممكنة لتشجيع التعاون والمشاركة في المشروعات "الأجنبية".
بالمناسبة ، رئيسه نفسه غير محمي من عامل سقوط الطوب. لذلك ، بمجرد أن تعتاد عليه قليلاً ، ابدأ في التفكير في من ستخلفه. هذا ليس فقط إعادة التأمين ، ولكنه أيضًا تمرين جيد لتفويض المهام - عند إعداد خليفة ، يتعين عليك عن غير قصد أن تفكر في أي عمل هو الأسهل والأكثر أمانًا لتكليف الآخرين. خلال عمليات البحث هذه المعرفة ستكون مفيدة للغاية.
والأخير: حتى الآن ، كان يتعلق أساسًا بمصالح الفريق والرؤساء ، لكن لا تغفل عن حقيقة أننا ما زلنا نعمل مع الناس. يجب مراعاة التفضيلات الشخصية وخصائص الموظفين كلما أمكن ذلك. يجب ألا تتوقع حراكًا خاصًا من شخص صعب التبديل من شخص إلى آخر ، ويجب ألا تقوم ، لأسباب تتعلق بالعدالة ، بإرسال نظام الفرامل إلى مهمة يخشى عدم مواجهتها وما إلى ذلك. نحن هنا نقف مرة أخرى ضد الأطروحة التي نحتاج إليها لمراقبة موظفينا بعناية ومعرفتهم جيدًا.
الدافع والتشجيع
ولكن بما فيه الكفاية حول السياط ، دعونا نتحدث عن أكثر متعة - تلك ملفات تعريف الارتباط من الزنجبيل التي ينبغي للمبرمجين الحصول عليها من العمل. تسمي مياه الأمطار الأنواع التالية من خبز الزنجبيل (حسب الأولوية): الراتب ، والتقدم الوظيفي ، والكلمة الرقيقة ، وأخيرا ، ملخص الشركات.
فيما يتعلق بالمكافآت ، فإن المديرين الذين تركوا التطوير ليسوا أكثر عرضة للانتقائية ، لكن غالبًا ما يقعون في الطرف المقابل ويقلبون توقعات الموظفين. عند تحديد الأسعار ، ضع في اعتبارك العوامل التالية: الإنتاجية ، الخبرة ، الفعالية ، توقيت المهام ، متوسط المعدل الحالي ، ظروف السوق ومعايير الشركة. من الأخطاء الشائعة رفع الرواتب مقدمًا ، على أمل أن يشجع ذلك العمال على إعطاء كل ما لديهم. , – , .
, , , . , , .
– . , , , (, , «»). . – , . , , , .
, . – , -, , , , . : , . « » , . ( – ) – .