ثمانية قواعد للإنتاج الفعال للبرمجيات

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

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

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

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

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

لمن هذا؟

اسمحوا لي أن أقدم إخلاء مسؤولية هامًا وهامًا وهامًا هنا.

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

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

القاعدة رقم 1: افهم عقلية تكنولوجيا المعلومات

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

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

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

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

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

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

القاعدة رقم 2: لا تخلط بين إنتاج البرمجيات وأساليب تطوير البرمجيات

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

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

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

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

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

القاعدة رقم 3: استخدم التخزين الثابت كامتداد لذاكرة الإنسان

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

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

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

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

هذه التقنية تخدم غرضين.

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

ثانيًا ، أنت تصفى عقلك ، وتتخلص من المشكلة التي كانت تزعجك. الآن عقلك جائع للتحدي القادم. يا له من زيادة الإنتاجية!

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

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

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

القاعدة رقم 4: توقف عن إضاعة الوقت في تقدير الوقت الرسمي

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

إذا كان الأمر لا يمكن التنبؤ به ، فكيف يفترض بمديري المشاريع تقديم جدول زمني للمشروع والالتزام به؟

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

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

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

أود أن أبرز نتيجتين مهمتين للطريقة الموصوفة أعلاه.

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

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

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

القاعدة رقم 5: فهم تكلفة تبديل المهام وأولويات ألعاب الخفة

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

عقل المطور هو بالتأكيد رصيد كبير في تطوير البرمجيات. هل أنت ، بصفتك مدير مشروع ، مهتمًا بفهمه بشكل أفضل ووضعه في موقع يقدم فيه أفضل أداء؟

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

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

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

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

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

تمام. الآن بعد أن حددنا فكرة تبديل المهام ، دعنا نرى كيف تعمل في تجربة فكرية واقعية (إذا جاز التعبير).

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

الآن ، دعنا نكرر نفس التجربة العقلية. هذه المرة ، سنعمل باستمرار على تبديل مهام المهام بين المطورين دون سبب (مهم). كل يوم ، يحصل كل مطور على مهمة جديدة للعمل عليها. والأفضل من ذلك ، دعنا نبدلها كل ساعة. متى سينتهون ، في رأيك؟ ربما أبدا.

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

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

هذا سيناريو واقعي يحدث كثيرًا ، للأسف.

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

القاعدة رقم 6: استخدام المراجعات المعمارية كطريقة لتحسين تصميم النظام

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

اسمحوا لي أن أقدم لكم القليل من مؤشراتي المجربة والصحيحة حول ذلك.

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

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

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

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

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

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

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

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

القاعدة رقم 7: لاعبي الفريق القيم

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

لقد لاحظت العديد من الأشخاص يعملون على مستويات مختلفة ورأيت كيف أثرت صفاتهم الشخصية على تقدم المشروع. أود أن أقدم المؤشرات التالية المتعلقة بالصفات الشخصية الأكثر فائدة في العمل الجماعي.

التواصل

الجودة الأولى والأهم بالطبع هي القدرة على التواصل.

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

التواصل ليس مهارة ثنائية نعم / لا ؛ إنها أكثر من مجرد نافذة لنقل المعلومات. كلما اتسع نطاقه ، كان تبادل المعلومات أسرع وأوضح.

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

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

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

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

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

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

جزء آخر من مهارة الاتصال هو القدرة على ضبط المستمع.

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

فهم نقاط القوة والضعف

دعونا نركز على صفة شخصية أخرى ضرورية للاعب الفريق.

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

هذا هو المكان الذي يأتي فيه جو الفريق الودود للمساعدة.

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

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

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

القاعدة رقم 8: التركيز على تنظيم العمل الجماعي

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

بناء الخبرة

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

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

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

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

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

منع هذا عن طريق فتح إمكانيات التعلم في مكان آخر لهم. اجعلهم على اطلاع بالمشاريع والمجموعة التكنولوجية للشركة ، وافتح تحديات جديدة. إذا كانت اهتماماتهم تقع ضمن نطاق المشروع ، فستحصل على مكافأة مضاعفة تتمثل في إبقاء فريقك في مواجهة التحدي وتوسيع مجموعات مهارات الفريق المفيدة في نفس الوقت. However, any self development is good to avoid boredom, even if it doesn't intersect with immediate project needs. As long as the team expert brains are engaged, they keep supporting already-learned project areas in the back of their minds.

When leaving the company, team experts take a big portion of expertise with them. One of the countermeasures you can use is to widely disseminate documentation that can be updated on the fly. Think of the “persistent memory storage” mentioned earlier.

Still, a project manager would love to duplicate knowledge in team member heads if possible. Having two of every expert would be a simple solution for that, albeit twice as expensive. But there is a leaner way to do it. The trick is to let most of your developers develop expertise in multiple areas, so that each project aspect is covered by at least one deep expert. At the same time, chose a few senior members to grow the breadth along with the depth of their expertise. Usually, this role is best played by a team development lead or an architect. The team lead interacts with all team members and participates in all task implementations. They can tap into each and every aspect of the project, understanding all of its internals. This way, even if you lose one of the experts, the leader can take over and keep on the project progressing until you can hire and train the replacement.

Another flavor of same idea is to cross-train developers in adjacent areas, letting them to observe, learn, and occasionally try their peers' work. Keep in mind that this cross-training needn't be extensive, so it doesn't disrupt focus on developers' primary tasks and doesn't impede productivity. Developing expertise across leadership and cross-training developers builds you a cushion of protection against unforeseen life culprits and allow you some time to maneuver with project resources.

Minimizing Distraction

Software development is a chain of complex and creative problem solving. Even though, with industry development, these complex problems get more and more automated, the work doesn't become easier. It still involves a large amount of art and individual insight, which is very hard to predict and sometimes even harder to wrangle.

Developers are the edge of the weapon. Their concentration is equivalent to the hardness of the weapon's tip. Increase their focus and you'll cut through problems like a hot knife through butter. Distract them and you'll end up clumsily poking at the butter with a blunted stick.

This cannot be over emphasized: Non-problem-solving work can be intensified with motivation or extra effort. For problem solving work, you need maximum detachment from the mundane world. It is difficult to leave all everyday problems behind, and a good project manager should build a quiet development environment in both the physical and mental senses. A developer's workplace should be analogous to a sensory deprivation tank.

Physically, this is implemented as a closed work space. Every team member should have a cube at least where they can dive into solitude. It is preferable to avoid loud noises and aisle conversations. Quick interpersonal communications should be maintained by emails and chats. Large groups should use closed rooms for their meetings to not distract others. This is a pretty standard picture for office life as it used to be.

Unfortunately, the open space paradigm is being adopted more and more widely even in large offices. I would warn against his fad. Even worse, together with open spaces, top management encourages in-place team conversations. That is, in essence, shouting to a person in another row over an uninvolved team member's head. A developer that is interrupted by loud conversation twenty times a day won't have a shred of concentration left. Certainly a major performance killer.

Allowing for a Learning Curve

Knowledge itself is power. This is especially true for such a complex industry as IT. Every task here has its regular cycle: learn, research, implement. The learning phase in particular is invaluable. Not only does better understanding allow better and faster implementation, there are certain knowledge thresholds that must be passed in order to achieve something at all. Of course, there is no point in over-learning either. Each skill should match the production need and not much above it.

However, often, developers are pressured in the opposite direction; to stop learning and to do nothing but produce. Learning is perceived as wasted effort, as it doesn't move the task progress bar. This seems like a really easy problem to solve, sitting at home and reading this article. Yet in the real life, the slightest work pressure turns every manager into that demanding idiot who insists that everybody “stop learning and start doing something already.” I swear, I have heard those exact words so many times throughout my career… A good manager and team leader should understand that learning is an important part of the process even if it doesn't directly increment the progress bar.

Building a Competitive Development Workshop

The tips and tricks presented above are a subset of effective software production expertise. By understanding and applying them in real life, you'll improve your production effectiveness little by little. If you think they are largely unconnected and lacking a theoretical base, you are absolutely right.

I would like to highlight that building a competitive development workshop is not a single-discipline task. It requires knowledge and expertise in multiple adjacent areas. Building such expertise is a hard work. There is no single theoretical base or idea that would solve all your problems at once. Believing in such a silver bullet just serves to distract you from the real goal.

Try out these tips at work to see if they are worth adopting permanently. If you find them useful (or not), leave a comment below and share your experience!