انترنت الأشياء- أكاديميا وعمليا في الوطن العربي

انهيت قبل أيام مساق شبه طويل من معهد MIT حول انترنت الأشياء Internet of Things (IoT) المساق زخم بالمادة الاكاديمية والتطبيقية ويحتوي بعض الرياضيات والبروتوكولات التي تستخدم في هذا المجال. المساق يعرض بعض التطبيقات التجارية لتسليط الضوء على “ما قد” يحصل في المستقبل سواء داخل المنزل، في الشارع، في الحكومة، وأي مجال آخر.

الموضوع مشوّق خاصة عند عرضه من قبل جهابذة الانترنت وبروتوكولات الاتصالات- أحد المحاضرين هو البروفيسور تيم لي برينر Tim Breners-Leeو هو من ابتكر الـ web protocol: HTTP.. وغيره من الأساتذة المساهمين في بروتوكولات أخرى مثل RFID, AES encryption, indoor localization, triangulation, 802.15.5 protocol, BLE, Lo6WAN.. وغيرها، طبعا الموضوع يهتم بشكل كبير بموضوع الأمان security وself-driving cars الخ.. طريقة الشرح، وربط المفاهيم مع بعضها البعض، وإيصال المعلومة بطريقة ممتعة تجعلك تلتهم الأبحاث والكتب.. وتجعلك تتحسر على الواقع التعليمي في بلادنا. لا أعني بذلك ان نكون مثل الـ MIT لكن ولو 10% من التعليم الشيّق لا أحد يمانع ذلك. على العموم، رابط المساق هنا

من وجهة نظري كمتخصص بالبرمجيات والتطبيقات (خبير متواضع امام الكثير منكم طبعا، ولا تزيدني الخبرة الا تواضعا) ان التكنولوجيا العملية (مش فيسبوك وسناب شات يعني) هي الحل البديل والمنطقي لكثير من مشاكلنا في الوطن العربي- سواء من خلال تطبيقات الـ IoT او غيرها المعروفة حاليا.

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

مشاكل التأمين الصحي، الطوابير في اخذ مواعيد الأطباء، زحمة السير، المدارس وقت الثلج، امتحانات التوجيهي، إطلاق العيارات النارية، ارتفاع أسعار السلع (والشكوى ضدها) وغيرها من المشاكل يمكن حلها بتوفير تطبيقات وsensors وتقارير real time reports وaction items بدون الحاجة للعمل مع الحكومة لتوفيرها. سؤال على الطاير: ما الذي يمنع شركات الاتصالات من تزويد الناس بحالة الشوارع من خلال استشعار قوّة إشارة الموبايل (وليس المقصود التجسس مثل ما يدّعي البعض) وما الذي يمنع المستشفيات من توزيع اسورة wristband للمرضى وتحسس الإشارات الأساسية من الجسم وارسال عيار الدواء للمريض على موبايله دون الحاجة الى زيارة المستشفى (خاصة لو ان المريض يحتاج لأكثر من ساعة للوصول الى المستشفى). ما الذي يمنع شركات التأمين على السيارات والتامين الصحي من رصد سرعة أي سيارة مؤمنة وإدخالها كأحد معطيات التأمين وتقييم الضرر… ما الذي يمنع المدرسة من مراقبة الطلاب باستخدام RFID tag على الكتب او حتى على أوراق أسئلة التوجيهي لكشف تسريب الأسئلة… يوجد الكثير من الأفكار وتطبيقها غير مكلف كوقت ومال- ويمكن عرض هذه التجارب على عدّة دول لتحسين حياة الناس

البنية التحتية في البلاد العربية بشكل عام غير فعّالة، الا ما ندر في بعض الدول، والحكومات بشكل عام غير جادّة في توفير الحياة المريحة للناس (لما كنت ساكن بمصر تجد ان المواطن يتعب حتى يستطيع ان يعمل ابسط الأشياء التي يحتاجها الانسان- ربنا يعينكو) وبالتالي إيجاد حلول عصرية (تقنية) من نفس الشعب (الشركات) هو الحل الأسرع والاوفر والانجح

 

إدارة مشاريع البيانات الضخمة- عوامل النجاح وأساسيات العمل BigData project management success factors

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

مشاريع البيانات الضخمة ليست بسيطة، وتحتاج الى الكثير من التركيز على التفاصيل في كل مهمة يعملها المطورون- وهذا هو العامل الأهم في كل المشاريع أصلا- لكن مشكلة مشاريع البيانات الضخمة انها تعتمد على مبدأ: Distributed systems وهو بحد ذاته موضوع شبه معقّد (او غير بسيط). النقاط التالية اعتقد من الضروري الالتفات اليها وبحثها عند الشروع بأي مشروع للبيانات الضخمة:

  1. عدم تضخيم الأمور: البعض يعمد الى تضخيم حجم العمل وصعوبته وطول المدة المطلوبة للعمل- انتبه لأولئك لأن الحافز الأساسي لهم هو اما فرض كلفة أكبر للمشروع او مدة أطول واهم حافز أنهم لا تتوفر لديهم الخبرة المطلوبة لأداء العمل- وبالتالي يحاول المطوّر ان يطلب وقت أطول لإنجاز المهمة المطلوبة. يجب تعيين الكفاءات الصحيحة للمشروع والتفاوض بشدّة مع الخبراء منهم (عادة الخبراء في هذا المجال يتقاضون مبالغ عالية لتنفيذ ما هو مطلوب)
  2. الدراية والعلم بالشيء: يجب (5 خطوط تحت كلمة يجب) ان يكون مدير المشروع على دراية كاملة بالأدوات والتطبيقات المستخدمة في المشروع. الدراية التي أتكلم عنها لا تقتصر على قراءة بعض الـ blogs او صفحات من ويكيبيديا… بل تتعدى ذلك لفحص البرامج وتتبع سطور الـ source code إذا اقتضى الامر وحتى كتابة بعض البرامج للتأكد من فعالية التطبيقات والخدمات الملموسة من المشروع. بما أنى تطرقت لموضوع الأدوات والتطبيقات التي تص البيانات الضخمة، الكلمات المفتاحية التالية تجدها في غالب مشاريع البيانات الضخمة والتي يجب ان تبحث في تفاصيلها وأساليب استخدامها وفائدتها وحتى ترقّب التحديثات التي تصدرها الشركات لهذه التطبيقات:

Graph databases, data models, schema and schema-less data structures, polyglot persistence, lambda architecture, batch processing, speed processing, in-memory processing, Apache projects: Spark, Hadoop, Flink, NiFi, Avro.

Functional programming, Data frames, elasticsearch, kibana, Zeppelin, key/value database

  1. استخدام الأدوات المناسبة لادارة المشروع: ويتضمن ذلك إدارة مهام الفريق وحتى الـ source code وحفظه باستخدام أدوات مثل GiT مع الاخذ بعين الاعتبار الصلاحية المسموحة لكل من أعضاء الفريق فيما يخص الـ source code. بما ان مشاريع البيانات الضخمة تكون جديدة على الفريق يُفضّل ان تعتمد منهجية مرنة لادارة المشروع: Agile project management لأن القرارات الإدارية والتقنية قد تتغير مع مرور الوقت وبالتالي يجب كسر القواعد الرتيبة في إدارة المشروع. أيضا يجب استخدام أدوات مناسبة لمساعدة المبرمجين ومدير النظام لتحديث المخرجات بسهولة واصدار نسخة من المخرجات في فترات مجدولة مثل nightly builds فيما يلي بعض الكلمات المفتاحية لادوات إدارة المشاريع وتشغيل المخرجات DevOps

Scrum, Agile, standup meeting, ticketing system, JIRA, Git, Docker, LDAP, Jenkins, SSH, DONE DONE, refactoring, burn down, gitolite, redmine, build script.

  1. اجراء المقارنات ومقارنة القراءات Benchmarking: من الأفضل عمل الـ benchmarking بين التطبيقات المراد استخدامها قبل الشروع بالتطوير وخاصة فيما يتعلق بالـ I/O performance واستخدام الذاكرة والمعالج memory and CPU consumption والـ benchmarking يستعمل بالطبع نفس المعطيات (المدخلات) ومقارنة النتائج بين التطبيقات المستهدفة
  2. تعيين خبراء في المجال المطلوب: لا تتوقع ان يستطيع أي مبرمج ان يعمل في مشاريع البيانات الضخمة بدون خبرة في مشاريع سابقة، الخبرة في مشروع او أكثر ضروري لنجاح المشروع- الا إذا كان الهدف من المشروع هو التعلم وليس لإتمام مشروع للعملاء او أحد منتجات الشركة

التقييم السنوي في شركات البرمجيات و الاتصالات

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

و حتى يكون التقييم واضح و صريح و علمي، يتم عمل نموذج للتقييم يحتوي بنود رئيسية و فرعية، و كل بند له علامة (درجة) و عادة تكون من 1-10 او كنسبة مئوية و تكون العلامة او النسبة مقسّمة مثل 1-4 سيء، 5-7 جيد، 8-10 جيد جدا… الخ.

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

التقييم، كما هو باقي المهام الادارية في شركات البرمجة و الاتصالات، و للأسف ورثت الادارة من الشركات التي تعمل في صناعات أخرى- يعني اجراءات قسم المالية و شؤون الموظفين و الادارة العامة بشكل عام في شركات البرمجة هي نفسها التي تجدها في شركات اخرى مثل الاستيراد و التصدير و المصانع و البناء و المقاولات- لا يخلو الامر من بعض الفروقات و التي لا تتجاوز 15% كامل الاجراءات.

تقنياّ، اغلب الموظفين يتبع سياسة “انا بعمل اللي بيقول مديري اعمله” او سياسة “انا بعمل المهام اللي بتخلي مديري مبسوط” او بسياسة “انا المهم ما اخلي مديري يزعل مني” او بسياسة “رح أأسفن كل زملائي و اطلع نجم بعيون مديري”… و نادرا ما تجد من يتبع سياسة “انا رح اتعب عشان اتعلم خبرة جديدة في الشركة” او سياسة “معقول تطوير البرمجة المثالي مثلما انا بشتغل حاليا؟”

و بسبب ان الغالب يعمل ليعيش لا يعيش عشان يعمل، تجد ان اهتمامه بالتقييم بالغالب يتمحور حول المنصب او الـ title الذي يتقمصه و الزيادة المالية التي سينالها بعد التقييم، و المحزن ان الشركات تلعب على نفس الوتر و تريد من التقييم السنوي معرفة الموظف الذي يستحق المنصب او الزيادة اكثر من اهتمامها بما يمكن للشركة ان تستفيد كتكنولوجيا من الموظف الذي يرزح تحت التقييم.

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

و لتقييم اداء المبرمج و المهندس او مدير المشاريع البرمجية، يجب ان يكون هناك قراءات واضحة للتقيم: عدد المشاريع المنجزة، عدد الـ features الجاهزة للسوق من اي منتج product، عدد الـ transactions/sec التي وصل لها النظام، و غيرها من الـ performance  KPIs

اذا لم تتوفر هذه المقاييس او الادوات التي يمكن ان تقييس المعطيات، سيكون التقييم نظري و يتبع “الاحاسيس و المشاعر” من المدير و الموظف بنفس الوقت- الموظف “حدق” و يعلم علم اليقين ان الشركة لا تملك الادوات المناسبة لرصد القراءات لاستخدامها في التقييم و بالتالي يلعب على وتر “رح اخلي المدير يحبني” لان التقييم يتبع الاحاسيس لا الارقام.

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

للتخلص من العشوائية في التقييم حتى الوصول الى طريقة عملية للتقييم نواسطة ادوات فعالة يمكن تدريجيا العمل على:

  1. فصل التقييم المالي عن التقييم التقني: بمعنى ان لا يكون تققيم الاداء و الخبرة و التطور لدى الموظف مقترن اقتران كلّي بالزيادة السنوية
  2. جعل التقييم التقني مقرون بما هو جديد تقنيا في الشركة من الموظف و ليس ما تم عمله خلال السنة بنفس الطريقة المعتادة: السبب ان التكنولوجيا تتطور بسرعة، و اذا تم استخدام نفس التقنيات على مدى سنتين فهذا ينذر بعدم التطور مع الواقع التكنولوجي
  3. عمل التقييم كل ربع سنة- و اصبحت شركات كثيرة تعتمد هذا الاسلوب منذ عدة سنوات- و ذلك لتعديل اداء الموظف و زيادة كفاءته فورا بدل ان يتأخر تصويب الاوضاع لنهاية السنة
  4. جعل التقييم انشائي و ليس رقمي (علامة) لحين توفر الدوات المناسبة: التقييم الانشائي يعطي مجال افضل للتعبير عن الاداء من كل جوانبه افضل من اعطاء رقم “ناشف”
  5. رفع سقف التوقعات من الموظف ليتوافق مع الواقع التكنولوجي (سياسة جلد الذات): يعني لو انت في شركة تطوير لنظام محاسبة- عليك ان تقارن المنتج و منجازاته بما هو موجود في السوق العالمي- لأن السوق لا يرحم تقنيا و يجب على الاقل ان تكون بنفس المستوى الذى وصل اليه غيرك حتى تتمكن من الامتياز سواء كموظف او كشركة

و دمتم دام فضلكم

ملاحظات (مرة أخرى) على نتائج مقابلات المبرمجين

كنت قد كتبت مقالين اثنين عن ملاحظاتي حول بعض المقابلات التي اجريتها في السنوات السابقة في هذا المقال و هذا المقال.

المقالان في سنة 2011 و 2012… و الآن اكتب في نهاية 2014  عن نفس الموضوع

للأسف كل ما ذكرته في المقالين ينطبق على المقابلات التي اجريتها خلال شهر نوفمبر 2014 و للأسف مرور فترة من الزمن يفرض رفع سقف التوقعات و خاصة لوظيفة مبرمج تطبيقات موبايل- mobile developer

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

المشكلة الأكبر في المقابلات الاخيرة اني قابلت من لديهم من سنة الى ثلاث سنوات خبرة في تطوير برامج آندرويد- و التي من المفترض انها سهلة الاستخدام و التعلّم و التطبيق- على الاقل مقارنة بنظام iOS  و تطبيقاته (بشكل نسبي)

لا زال المتقدم للوظيفة يتطلع للامور الاساسية في العمل و هي:

  1. الراتب $$$$$$: بالعربي كم رح اقبض آخر الشهر- و فوق السؤال سؤال ثاني: “بنزل الراتب آخر الشهر ويللا بيتأخّر؟؟”
  2. التسلسل الوظيفي: بمعنى المتقدم للعمل يريد ان يعرف من مديره و ما هي خبرته و اسلوب عمله- و هذا شيء جيد، و لكن الاجابة على هذا السؤال غير مفيدة للمتقدم للوظيفة (يعني مستحيل رح اجاوبه مديرك ازعر و بيضرب أسافين و رح يحرث عليك ليل نهار)
  3. ساعات العمل و بيئة العمل: واضح جدا ان المتقدمين مهتمين بمعرفة اوقات الدوام، و هذا يدل على ان للمتقدم للعمل حياة أخرى يهتم بها و تشغل جزء من وقته
  4. طبيعة العمل: يهتم بعض المتقدمين للعمل بمعرفة انواع عملاء الشركة، و طبيعة التطبيقات التي تطورها الشركة- معظم المتقدمين لا يكترث لطبيعة عمل الشركة

معظم المتقدمين (على الاقل من قابلت في الفترة الحالية) يتنقل بين الشركات بسرعة اكبر من السنوات السابقة- يعني كل 6 اشهر بشركة و احيانا كل 3 اشهر بشركة، بينما في السابق كان معدل مكوث الموظف فالمبتدئ في اول شركة يعمل بها ما بين 2-5 سنوات- طبعا سرعة التنقل بين الشركات يدلّ على اكثر من معلومة و أهمها ما يُعرف بـ turnover rate و هو دليل على عدم استقرار الشركات في البلد سواء ماليا او كإدارة للموارد البشرية و بيئة العمل و نشاط الشركة.

أسئلتي في المقابلات و خاصة لمن لديه “خبرة” في السوق لا تكون في مجال البرمجة نفسها و انما بالمفاهيم الاساسية و سبب وجود هذه المفاهيم و اماكن تطبيقها عملياً… و للأسف تجد القليل من المتقدمين للوظيفة ممن يدرك سبب وجود برمجيات معينة او اسلوب نشأتها. و للأسف طريقة سماع السؤال و تحليله من المتقدم تكون متسرّعة و تحتوي الكثير من “الفتوى”- للأسف هذه الظاهرة لا تزال منتشرة الى الآن

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

الدوام بعد اجازة العيد

معظم الناس- موظفين، طلاب مدارس، طلاب جامعات- يجدون صعوبة في العودة الى العمل او الدراسة بعد الاجازات الطويلة- خاصة التي تكون اكثر من 5 ايام.

مثلا الاجازة التي خرجنا منها مؤخرا… بدأت يوم الخميس مساء و انتهت بنهاية يوم الثلاثاء- يعني 5 ايام بالتمام و الكمال.

يوم الاربعاء هو يوم دوام رسمي- طبعا لما تشوف الشوارع بتلاقيها فاضية، الموظفين اخذوا تتمة الاسبوع كاجازة من رصيد اجازاتهم السنوية، الطلاب ايضا لم يذهبوا الى المدارس- إما بقرار من المدرسة (مدارس الخاصة) او بقرار من الاهل او الطالب نفسه ان لا يذهب للمدرسة يومي الاربعاء و الخميس.

المشكلة ليست بمدة الاجازة و لا حتى باعتبار يومي الاربعاء و الخميس (منطقيا) كيوم اجازة، المشكلة الاهم او السؤال الاهم: ما الدافع الذي يدفع اي شخص ان يتقبل و يرغب بالدوام بعد الاجازة؟؟

للأسف، القليل من الناس يجد التوازن بين الراحة و العمل، يعني قليل من الناس يقول بعقله “بكفي 5 ايام راحة، لازم بكرا اروح اشتغل” او “ارتحت من قرف المدرسة 5 ايام، خليني اشوف دراستي و زملائي بعد الاجازة”… طبعا من ينطبق عليهم هذا النوع من التفكير لا يتجاوز 10%

طيب، ليش ما بنحب نداوم؟؟ في ما يلي رأيي الشخصي:

  1. عدم انعكاس أثر العمل (او الدراسة) على الشخص: بمعنى، يقول الشخص بعقله “شو الفايدة اني اشتغلت هاليومين او لأ؟؟” او يقول بعقله “بقدر اعمل اللي بعمله بهاليومين الاسبوع الجاي، ما في شي خطير لازم اعمله”… او “لن اتطور او اكتسب اي خبرة او معرفة جديدة اذ اشتغلت بالهيومين او ما اشتغلت”، او يقول “بنزين مشوار الروحة ع المكتب و الرجعة خسارة بالهيومين”… الخ… يعني اشتغلت او ما اشتغلت مش فارقة- يسري الكلام على الطلاب.
  2. عدم حب طبيعة العمل او الدراسة: للأسف نحن نعمل لنعيش و ليس رغبة منا للعمل سواء كحب للعمل نفسه او للقطاع الذي نعمل به- يعني يمكن ان تجد محاسب مخلص في عمله و لكنه قد يكون يعمل كمحاسب عشان الراتب آخر الشهر او لأنها الشغلة الوحيدة اللي بيفهم فيها و هو في قرارة نفسه يحب ان يعمل في صناعة الالبان و الاجبان مثلا، او يحب ان يكون راقص فلامنجو:) و بالتالي، يجد صعوبة في الذهاب الى الدوام بعد فترة “الخلاص” من الدوام في الاجازة
  3. الروتين في المكتب و المدرسة: نفس الطقوس تمارس يوميا في الشركات و المدارس و الجامعات… تصحى من النوم، تصل الشركة بالازمة، تشرب نسكافيه، تقول “صباح الخير”، بتفتح موضوع بسيط، تبدأ بعمل قائمة بما ستفعل في اليوم (و يكون تقريبا مشابه لما فعلت قبل اسبوع او شهر او سنة) تتعامل مع الموظفين نفسهم… اللي لم تتغير شخصياتهم او افكارهم او حتى ملابسهم… فترة غدا، قهوة و شاي، اجتماعات يعرض كل واحد فيها انه احسن من الكل، صوت عالي من المدراء حبا بالسلطة و فرض الواقع الوهمي، و بالنهاية العودة للبيت… يعني ما في بيسوى الدوام… فـ “لويش اداوم؟؟”

لن نصبح شعب منتج ما دمنا لا نجد انفسنا راغبين بالعمل، و للاسف طبيعة العمل و الاشخاص التي تعمل معهم لن يكونوا “مفصّلين تفصيل” على ذوقك، و للاسف الحياة صعبة و ليست مليئة بالورود و الابتسامات، و لكن الشطارة ان تتقبل الواقع و تتأقلم معه قدر المستطاع- من منا كان يحب ان يذهب للمدرسة؟ يعني ممكن بعض السنين كانت جميلة، و لكن المدرسة و المدرسين و الطلاب و الامتحانات و العلامات شيء ممل و بطيء الحركة و غير عملي في بعض الاحيان- بس بدك تتحمل و تعيش… على قولة الاميركان….. Life is hard, then you die

ASAP

كلمة نذكرها و نقرؤها كثيرا خاصة في البريد الاليكتروني emails و بالأخص في المراسلات ما بين الادارات و الموظفين.. و ايضا في المراسلات مع الزبائن.

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

استخدام كلمة ASAP و غيرها من التصرفات الادارية الكلاسيكية اصبحت بلا جدوى، مثل رفع نبرة الصوت في الاجتماعات، و الصراخ على التلفون و “رقع” سماعة التلفون عشان الكل يعرف انه “المعلم” معصب- الجيل الجديد من الموظفين موديل 89 و طالع لا تنفع معه هذه الاساليب- اذا امه و أبوه ما بطلعلهم يرفعو صوتهم عليه، مين انت يا مدير تا تبعث “ASAP” او “يا بتعمل الشغلة الفلانية يا بشوف تصرّف ثاني معك”… كله ما بنفع.

و بالمقابل، و للانصاف، هناك الكثير من المهام التي يجب عملها ASAP فعلا، و تحتاج للتركيز و الاهتمام من الكل و لكن هذه المهام تذوب مع مهام اخرى كثيرة مهمة و مصبوغة بنكهة الـ ASAP و بالتالي لا يصبح ASAP و لا احد يستفيد، لا صاحب العمل، و لا الموظف، و لا حتى الزبون.

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

سبب استعمالنا لهكذا مصطلحات هو

  1. عدم الثقة بالآخر: و بالتالي ارسال كلمة مثل ASAP يراد بها ان تبعث رسالة للمستقبل اني لا أضمن انك ستقوم بما اطلبه منك- طبعا عدم الثقة يأتي بعد عدة مواقف حصلت بين الطرفين
  2. عدم تحمل المسؤولية: فعندما يرسل احدهم ASAP و كأنه يقول: “انا قلت انه الشغلة مستعجلة و دبّر حالك خلصها، و اذا ما خلصتها مش مشكلتي”
  3. عدم القدرة على وزن المجهود المطلوب: بمعنى ان المرسل لا يعرف ما هو المطلوب فعلا من المهمة و بالتالي “يرمي” كل ما هو مطلوب للمستقبل دون معرفة ما المتطلبات المطلوبة للعمل او اي مراسلات سابقة متعلقة بالمهمة
  4. أوامر من المدير: المدير يقول للموظف “لازم نعمل كذا و كذا ضروري جدا”… و بالتالي الموظف يرسل ايميل بنفس منطق مديره. و أيضا المدير يفرض على الموظفين طريقة “النق” كأسلوب لمتابعة العمل (راجع نقطة 1)

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

شركات التكنولوجيا في الاردن (و الوطن العربي)- الجزء الخامس

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

و لكن.. يجب إحداث تغيير مفيد لجميع المتورطين في هذا القطاع- و افضل التغييرات هي التي تبدأ في “المناطق الحساسة” لتنعكس بالتالي على المناطق الاخرى- المنطقة الاكثر حساسية هي: الموظفين (التقنيين- employees) و خيراتهم.

التغيير في الخبرات يأتي (و هذا اجتهاد شخصي) باتباع “خارطة الطريق” التالية:

  1. إثبات الخبرة: لنكن واقعيين- معظم ما تقرأه في السيرة الذاتية لأي شخص هو عبارة عن كلام لا أكثر- و اثبات ما هو مكتوب بالسيرة الذاتية لا يمكن اثباته الا عن طريق المقابلات و الاهم من ذلك العمل الحقيقي بعد “الفوز” بالوظيفة. و بالتالي الموظف (developer, IT admin, network engineer, system integrator, …) يستطبع إثبات خبرته بطريقة اسهل و اسرع من الطريقة الكلاسيكية (مقابلات) و ذلك عبر نشر اعماله على الانترنت و وضع اشارات لها في مواقع تقنية- و أهمها GiT, stackoverflow, .NET community, PHP community, CISCO groups, … هذه المواقع يجب استخدامها كسيرة ذاتية للراغبين بالعمل و هي الاساس في التوظيف و البحث عن الكفاءات.
  2. طريقة البحث عن الوظيفة: للأسف يبحث التقني عن الوظيفة و ليس العكس- بمعنى ان التقني يجب ان يكون المتلقي لعروض العمل و ليس العكس. التقني في الوضع الحالي يرسل سيرته الذاتية لكل الشركات بكل الوسائل (email, linkedin, facebook…) ليجد فرصة عمل او حتى مقابلة مع شركة… الاصح ان يقوم التقني بعرض خبراته و انجازاته (حتى لو كان حديث التخرج- و هذا مش عذر) و تقوم الشركات بالبحث عن الشخص المناسب لوظيفة او مشروع ما.
  3. إختيار التخصص و اسلوب العمل: المقصود التخصص التقني مش التخصص الذي تختاره بعد الثانوية- خلص بعد ما دخلت صناعة التكنولوجيا عليك اختيار التكنولوجيا التي تريد العمل بها (و التركيز عليها).. بالامكان اخذ خبرة باكثر من مجال و لكن يجب التركيز على موضوع او موضوعين على الاكثر. مثال: web development… قد تعتقد ان هناك الكثير من الناس يعملون في هذا المجال و ان لا مجال لك لنيل مشروع او وظيفة بسهولة (لانه السوق مليان web developers)- و هاي حجة ضعيفة- بالنهاية اذا اثبت انك عندك common libraries, utilities, custom made designs.. و عندك framework لتطوير اي موقع بتوفير 50% من وقت التطوير الكلاسيكي لأي موقع..يمكنك الفوز بأي مشروع او وظيفة- و خاصة اذا كانت لديك تقنيات مثبتة و سهلة و سريعة لتطوير مواقع باللغة العربية و تتعامل مع مشاكل ال encoding, fonts, RTL, rendering, responsive design…etc
  4. خلق الفرص بدل البحث عنها: يعني بدل ما تبحث عن مشروع او وظيفة في ال web development حاول ان تبتكر طريقة افضل و اجمل لعرض المواقع (في التاريخ الغابر كانت هناك مواقع معمولة بالكامل بـ flash macromedia) او على الاقل حاول تغيير النمط السائد في المواقع الاليكترونية- مثال: هل فكرت ان تعمل HTML tag جديد بمواصفات جديدة؟ هل فكرت بـ module جديد يمكن تركيبه على راوتر CISCO مختص بادارة الـ traffic للشبكات الاجتماعية يتمكن بطريقة ما بادارة البيانات في الاماكن الاقل حظا في سرعة الانترنت (افريقيا الوسطى)؟