لن يطلب أحد من المطور كتابة التعليمات البرمجية دون الوصول إلى جهاز كمبيوتر ، ولكن العديد من الشركات تعتقد أنه يجب عليه العمل بطريقة ما دون القدرة على الاستفادة الكاملة من قدراته العقلية. وهذا أمر غير واقعي.
لذلك دعونا نتناول قائمة من اثني عشر شيئًا يمنع المطورين من الدخول إلى حالة التدفق وتحقيق أقصى قدر من الإنتاجية. سأحاول الانتقال من أهم الأشياء إلى الأقل أهمية. اقترح خياراتك وتعليقاتك!
إذا شكك شخص ما فيما إذا كان الأمر يستحق إنفاق المال والجهد على ذلك ، يكفي أن نتذكر كم يدفع للمبرمجين. حتى زيادة الإنتاجية بنسبة 10٪ تعتبر مبالغ نقدية!
1) الاجتماعات والمشتتات الأخرى
في رأيي ، فإن تشتيت انتباه المطور هو أضمن طريقة لقتل إنتاجيته في مهدها. لا يستطيع ببساطة أن يأخذ ويستمر من المكان الذي قاطع فيه. يحتاج أولاً إلى العودة إلى العملية ، ومن ثم لا يزال يمر عبر سلسلة الأفكار الكاملة إلى اللحظة المناسبة - وهذا وحده يمكن أن يستغرق نصف ساعة أو أكثر. وكلما حدثت مثل هذه الفواصل ، كلما زاد تراكم التهيج ، انخفضت جودة العمل ، والمزيد من الأخطاء ، ويمكن متابعة هذه القائمة.
"في كثير من الأحيان يتم تشتيت انتباهي عندما أحاول بدء مهمة ، كلما زاد الوقت المنقضي بين المحاولات. إذا كنت قد سحبت طوال الصباح ، فلا يوجد شيء يدهشني أن اليوم أصبح غير منتج "- مطور مجهول مع Reddit
حسنًا ، ماذا عن الاجتماع؟ اختلافهم الوحيد عن عوامل التشتيت الأخرى هو أنهم مخططون مسبقًا. وذلك يجعل الوضع أسوأ. من الصعب على المبرمج أن يتقدم في حل مشكلة إذا كان يتوقع انقطاعًا في العمل مقدمًا. لذلك ، إذا اضطر في ساعة أو ساعتين إلى حضور اجتماع تخطيطي ، فعلى الأرجح لن يتمكن من القيام بأي شيء مهم لأي من مشاريعه - بعد كل شيء ، تستغرق معظم المهام الهندسية وقتًا أطول.
كما قال بول جراهام: "يمكن أن يقتل اجتماع واحد نصف يوم: ينقسم الوقت إلى فترتين ، حيث لا يمكنك القيام بأي شيء جاد".
كيف تتجنب هذا الوضع؟ تم رسم كل شيء على هذا لفترة طويلة ، لذلك لا توجد أعذار. تحتاج فقط إلى وضع المسوِّقين في بداية اليوم ، أو على سبيل المثال ، قبل الغداء مباشرة ، حتى لا تشغل الناس عن العمل دون الحاجة.
2) التقطيع
من بين جميع أنواع المديرين ، أولئك الذين يتدخلون لأي سبب ، ربما يكون أسوأ تأثير على إنتاجية الموظفين. بالطبع ، يتأثر هذا أيضًا بحقيقة أن هذا النوع الخاص يميل بشكل خاص إلى تنظيم مجموعة من الاجتماعات ويطلب اهتمام المطورين لأسباب غير متوقعة. لكن هذه ليست النقطة الوحيدة. تظهر مثل هذه الإجراءات انعدام الثقة ، ونتيجة لذلك ، يشعر الناس بأنهم يعتبرون غير قادرين على أي شيء ويشككون في مهاراتهم المهنية. حتى إذا كان المبرمج لا يزال لديه بعض الدوافع للعمل على الرغم من الانقطاعات التي لا تنتهي ، فإن مثل هذا الموقف سيثبطها تمامًا. لا تقتصر العواقب على انخفاض واحد في الأداء. غالبًا ما يجبر المديرون المتطفلون الموظفين على مغادرة الشركة ، أو على الأقل الفريق.
3) غير واضح
يمكن توضيح عدم الوضوح من خلال العديد من الأمثلة المختلفة. على سبيل المثال ، تقرير خطأ بروح "لا يعمل هنا ، أصلحه!" من الواضح أنه لا يعطي المطورين جميع المعلومات اللازمة للعمل. بالمناسبة ، في هذه الحالة بالذات ، قد يساعد تقديم نموذج لتقارير الأخطاء.
أو حالة أخرى: متطلبات غامضة لجزء من المنتج. مع مثل هؤلاء المطورين التمهيديين ، يبدأون ببساطة في القيام بما يتخيلونه هم أنفسهم ، ثم يأتي المدير مع وصف أكثر تفصيلاً لسلوك المستخدم المتوقع ، ويجب عليهم جميعًا البدء من جديد.
تنتمي الأولويات المحددة بوضوح إلى نفس الفئة. يقضي المبرمجون الكثير من الوقت في تحريك عقولهم حول ما يجب أن يبدأوا به ، على الرغم من أن تجنب ذلك سيكون أمرًا بسيطًا للغاية. حسنًا ، إذا اضطروا إلى إبلاغ المدير عن سبب انخراطهم في هذا الأمر وليس هذا (على الرغم من حقيقة أن أحدًا لم ينص على الطلب) ، فيمكنك التأكد من أن هذا سيجعلهم رائعين.
4) مديري النورس
هل سمعت بهذا من قبل؟ هناك مدراء لا يشاركون في سير العمل على الإطلاق ... باستثناء تلك اللحظات عندما يقررون فجأة الغوص على شخص ما وارتكاب خطأ. "هذا ليس جيدًا ، وهذا أيضًا ، لكنه لا ينظر على الإطلاق" ، وطار. يجب أن أعترف ، أحب المقارنة ، لكن الظاهرة وراءها أكثر شيوعًا مما نود. يؤثر هذا السلوك على المطورين بشكل سيئ للغاية: ثم يضطر الكثيرون إلى العمل في مزاج جيد لساعات ، ويخرج شخص من البث طوال أيام العمل.
5) سرقة الغار
هل حدث لك يومًا أن ينسب أحد المديرين أو المبرمجين الآخرين لنفسك ما عانيت عليه لعدة أسابيع؟ يضع المطورون مهنيتهم فوق كل شيء. سرقة مزايا الآخرين مثل إنكار كفاءة الشخص من أجل تضخيم نفسه. لقد وضعت هذه النقطة عالية بما فيه الكفاية لأنني أعتقد أن مثل هذه الأشياء تؤدي إلى موقف متوتر للغاية ، والذي يمكن أن يؤدي لفترة طويلة إلى "إسقاط" أداء الفريق بأكمله.
6) المفروشات: الضجيج والحركة وتصميم مساحة العمل ...
قد يبدو الأمر غريبًا بالنسبة للأشخاص من المهن الأخرى ، ولكن بالنسبة للمبرمجين ، تقرر البيئة كثيرًا في سياق العمل. قل الضوضاء البيضاء - ضجيج مكيف الهواء ، ضجيج السيارات والشاحنات من الشارع - تساعدهم على التركيز بشكل أفضل. هذا هو السبب في أن الكثير منا يعمل مع سماعات الرأس! بالمناسبة ، اكتشفت مؤخرًا RainyMood - شيء رائع!
ومع ذلك ، إذا تم تصميم المكتب بحيث يكون هناك دائمًا بعض الحركة حول الشخص ، فسيكون لذلك تأثير عكسي. بالإضافة إلى ذلك ، إذا تم تثبيت الشاشات بطريقة تجعل المديرين يرون باستمرار ما هو موجود على الشاشة ، فهذا يخلق ضغطًا غير ضروري وأسبابًا غير ضرورية لإلهاء المطورين عن العمل.
7) تعويض حدود المشروع
في إدارة المشروع ، يتم استخدام هذا المصطلح للحالات التي تنمو فيها أحجام المشروع بشكل لا يمكن السيطرة عليه. يحدث هذا عادة عندما لم يتم تعريفهم وتوثيقهم بشكل صارم في البداية أو لم يتم رصدهم في العملية.
بسبب إزاحة الحدود ، تتطور الاستعلامات البسيطة نسبيًا إلى وحوش مرتبكة تلتهم الكثير من الوقت! وفي معظم الحالات ، يبدأ هذا عندما يكون المنتج قيد التطوير بالفعل.
خذ على سبيل المثال وظيفة بسيطة:
- الإصدار الأول (قبل التنفيذ): يتم تعريف الوظيفة بأنها "عرض خريطة الموقع"
- الإصدار الثاني (عند انتهاء التكرار الأول تقريبًا): يتغير الوصف إلى "عرض خريطة موقع 3D"
- الإصدار الثالث (عندما ينتهي التكرار الثاني تقريبًا): يتغير الوصف إلى "عرض خريطة موقع ثلاثية الأبعاد يمكن للمستخدم الانتقال إليها"
8) عملية تحديد ميزة المنتج
قد يبدو الأمر غير مفهوم للوهلة الأولى ، ولكن في الواقع ، كل شيء بسيط. إذا كان الأشخاص المسؤولون عن المنتج يحددون أولوياتهم دون اختبار فرضياتهم (من خلال التعليقات أو بأي طريقة أخرى) حول اهتمام الجمهور بفرص معينة ، ويرى المطورون أن هذه الفرص ببساطة لا يتم استخدامها ، فسيكون لديهم الشعور بأن عملهم لا معنى له ، وسوف ينهار الدافع. نريد جميعًا أن نشعر بأننا نترك بعض التأثير على العالم ، وهذا مهم بشكل خاص للمطورين!
9) تجاهل الديون الفنية
يعد الواجب الفني قرارًا واعيًا بالسماح بتمدد معين في اختيار الحلول وكتابة التعليمات البرمجية من أجل طرح المنتج بشكل أسرع. ينشأ قدر معين من الدين التقني في أي مشروع حتمًا ويمكن أن يساعد في المواعيد النهائية على مسافات قصيرة. ومع ذلك ، على المدى الطويل ، يزيد من تعقيد النظام وبالتالي يبطئ المطورين. غالبًا ما يقلل الناس بعيدًا عن البرمجة من تأثير هذه العمليات على الإنتاجية ويتطلبون المضي قدمًا بدون توقف - في هذه الحالة تبدأ المشاكل في الظهور. إذا بقيت إعادة الهيكلة دائمًا خارج قائمة الأولويات ، فلن تتأثر إنتاجية الموظفين فحسب ، بل ستعاني أيضًا جودة المنتج.
10) مجموعة متنوعة من الأدوات والمعدات
يستخدم المطورون يوميًا العديد من الأدوات لكتابة التعليمات البرمجية ودفعها ودمجها. كلما تمكنوا من أتمتة العمليات ، كان ذلك أفضل. وغني عن القول أن الأدوات القديمة سيكون لها تأثير مباشر على الأداء. كما أنه يقرر الكثير مما يتم العمل عليه - على كمبيوتر محمول واحد أو على شاشة إضافية. إذا قارنا أسعار الحديد برواتب المبرمجين ، فإن زيادة الإنتاجية بنسبة 5٪ ستدفع بالتأكيد جميع التكاليف! تحتاج فقط إلى تزويد الفريق بالمعدات والأدوات التي يفضلون استخدامها (للمعدات ، يجب أن يكون الحل فرديًا ، للأدوات - الجماعية).
11) وثائق إرشادية
في عملية تدريس البرمجة ، تعلمنا جميعًا أنك بحاجة إلى البدء في إضافة التعليقات إلى الشفرة في أقرب وقت ممكن وفي كثير من الأحيان. كانت الفكرة أنه سيكون من الأفضل إذا كانت هناك تعليقات كثيرة أكثر مما لا يكفي. لسوء الحظ ، أساء العديد من الناس فهم هذا وقرروا أن كل سطر يحتاج إلى تفسير. لهذا السبب لدينا عينات مثل هذه ، من
مقالة جيف أتوود "كود بدون تعليق":
r = n / 2; // Set r to n divided by 2
// Loop while r — (n/r) is greater than t while ( abs( r — (n/r) ) > t ) { r = 0.5 * ( r + (n/r) ); // Set r to half of r + (n/r)
}هل تفهم ما يفعله هذا الرمز بشكل عام؟ لذلك لم أفهم أي شيء. المشكلة هي أنه يقال الكثير عن كيفية عمل كل شيء ، ولكن ليس كلمة عن سبب الحاجة لذلك. إذا افترضنا وجود خطأ في البرنامج ووجدت جزءًا من الرمز تحت غطاء المحرك ، فلن يساعدك ذلك في معرفة الموقف.
12) المواعيد النهائية ضيقة للغاية
ترتبط النقطة الأخيرة بميل المديرين إلى مطالبة المطورين بتقدير الوقت الذي سيحتاجون إليه تقريبًا ، ثم الضغط عليهم لتقليل هذا التقدير ، ثم مساواة التاريخ النهائي بالمهلة النهائية بطريقة سحرية! في الوقت نفسه ، يعتقد المديرون أنه نظرًا لأن المطورين "يحددون المواعيد النهائية بأنفسهم" ، فهذا يعني أنهم قد اشتركوا في الموعد النهائي المقابل ويجب اعتبارهم خيارًا معتمدًا نهائيًا يمكن نقله إلى الإدارة العليا.
يعتقد المطورون أن مثل هذا الموعد النهائي هو جنون كامل وأنه من المستحيل الالتزام به ؛ هناك خلاف في الفريق ولا يمكن لأحد التركيز.
ولكن هل يتعلق فقط بالمطورين؟
إذا نظرت إلى جميع هذه النقاط الـ 12 ، فستلاحظ أنها ، في معظمها ، ذات صلة بكل من يشارك في المشاريع. إنه فقط في حالة المبرمجين ، فهم حاسمون بشكل خاص ، لأن عملهم يتطلب انغماسًا عميقًا في العملية.
إذا لاحظت أن بعض النقاط المذكورة هي نموذجية لشركتك ، فسيكون من الجيد أن تتابع هذه القائمة مع فريق المطورين ، وتبني حوارًا معهم ، وتعرف أين تنشأ المشاكل وأفضل السبل لحلها. مهما قالوا ، من المهم للغاية أن تأخذ هذه التعليقات والتعليقات على محمل الجد. على مدار الثلاثين عامًا الماضية ، تغير الكثير من حيث التكنولوجيا ، ولكن المبدأ الأساسي للعمل الجماعي يبقى كما هو: عند مناقشة الأداء ، من الضروري مراعاة العامل البشري. حسّن عمليات عملك والبيئة وعادات الفريق ومنحهم الفرصة لإخبارك بكيفية تحقيق أقصى قدر من الإنتاجية.