لوحة المتصدرين

منذ منتصف العام 2001 وحتى بدايات 2013 وأنا أُدير شركة استشارات لتطوير الشبكات، وفي عام 2006 كانت الشركة –التي بدأتها وحدي- مزدحمة بالعمل مما دفع زوجي "Drew McLellan" للانضمام للشركة بساعات عملٍ كاملة، وكانت الغالبية العظمى من عملنا تتم عن طريق الاستعانة بفريق عمل خارجي، لنقوم بتطوير مشاريع لوكالات التصميم. لكن الآن –في 2014- وجدنا أنسفنا في الجانب الآخر من علاقة العميل بالمطور، ألا وهو جانب العميل. أطلقنا مشروعنا الأول "Perch" كمشروعٍ جانبي للشركة، والآن أصبح هذا المشروع هو كل ما نقوم به، ومازلنا نستطيع البقاء كفريق واحد يتكون من عضوين فقط عن طريق تعاوننا مع موظفين مستقلين ووكالات خارجية. في البداية استعنا بالمصادر الخارجية في مهام التصميم فقط، لكن فيما بعد قمنا بالاستعانة بهم للتطوير أيضًا. وهذه بعض الأشياء التي تعلمتها من كوني عميل وليس صاحب عمل. أخبرهم بالتطوّرات بشكل منتظم كنت أشعر دائمًا أننا نجيد التواصل مع عملائنا، كنا نسألهم باستمرار ونبلغهم بتطورات المشروع أولاً بأول، ولذلك عندما كان يقوم العملاء بالسؤال عن تطورٍ ما، كنت أشعر بالضيق والغضب. كنا نشعر أننا نتواصل مع عملائنا باستمرار ونادرًا ما كنا نتأخر عليهم في تسليم شيءٍ ما، لذلك افترضت أن العملاء سيتفهمون أننا إذا لم نتصل بهم لنذكر مشكلةً ما، فإن العمل يجري كما هو مطلوب وسيتم التسليم في موعده. كعميل، أدرك الآن أني حتى لو كنت أرى أكواد البرامج يتم الانتهاء منها والمصممين يتواصلون معي، أشعر دائمًا بالشك من إذا كانوا على الطريق الصحيح أم لا، فقد رأيت كيف أن مشاريع بعض الشركات تتوقف خطواتها الرئيسية على إنهاء عملٍ ما تم الاستعانة فيه بمصادر خارجية، فمثلا: قد تقوم بشراء إعلان ليتم بثه مباشرة في نفس الوقت الذي تبدأ فيه مزايا منتجك بالتواجد فعليًا. فإذا كان من الضروري أن تحجز للإعلان مقدمًا ليتم بثه في وقتٍ ما، لكن تأخر المشروع نفسه في الظهور فستكون الأموال التي دُفِعت لشراء الإعلان قد ذهبت هباءً. وبسبب التوتر الناشئ عن الجهل بما قد يحدث، والخوف من الخسارة المادية، يصبح من السهل أن تتحول إلى ذلك العميل الذي يلح باستمرار في السؤال عما إذا كان العمل قد انتهى أم لا. من البديهي أنك حين تقدم خدمة ما أن تلتزم بفعل ما قلت أنك ستفعله، في الوقت الذي قلت أنه كافٍ له، لكن مع ذلك فبالإضافة لهذه المتطلبات البديهية، فإن عملية تحديث العميل بالتطورات بشكل منتظم تساعده على أن يضع خططًا لأمورٍ ما تعتمد على ما تقوم به أنت من عمل، وستضع حدًا للرسائل والمكالمات التي من نوعية "هل انتهى العمل أم لا؟". حدد بالضبط ما ينبغي مراجعته، وكيف اعتدنا أن نتذمر من أن عملائنا، لا يُراجعون ولا يُجرّبون أي شيءٍ من العمل الذي قمنا به، فبالرغم من أننا عرضنا العمل على منصاتهم وجعلناه متاحًا للمُراجعة في أي وقتٍ ممكن. ولكن حين أعدت النظر في الأمر، وجدت أننا قد افترضنا افتراضين خاطئين، أولاً هو أن العميل لديه من الوقت ما يكفي ليراجع كل ما عملناه بمجرد انتهائنا منه، والثاني هو أنه يفهم ويعرف كيف يراجع ذلك العمل. نعمل الآن مع أحد المطورين ممن يستخدم حاليًا منصة "Trello" ليس فقط لينظم مهامه، بل أيضًا يستخدمه كوسيلة لنا –نحن عملاؤه- لنتمكن من متابعة العمل الذي يقوم به، وفي أيٍّ من المراحل هو. أستطيع إلقاء نظرة على "Trello" من أي مكان لأعرف عن كل مهمة إذا كانت قيد التنفيذ أم انتهت بالفعل. ومن ثم أستطيع الرجوع وإلقاء نظرة على منصة العمل الرئيسية لأستوعب التغيير الذي حدث. حتى وإن كان العميل لديه القدرة على الاطلاع على تطوراتك وتحديثاتك للمشروع، قم بتوفير وسيلة لهم ليعرفوا أي الأجزاء عليهم النظر إليها وفي أي وقت، فهذا سوف يوفر الكثير من وقت عملائك، ويجعلهم جزءًا من عملية التطوير. بالإضافة إلى وجهة النظر الأخرى التي حصلت عليها، والتي تحسن بشدة من طريقة تواصل العميل بالمطور، فقد اكتشفت طُرقًا أخرى يستطيع الموظفون المستقلون بها المشاركة في العمل الذي يعملون لصالحه. أعلمهم بالتّكاليف كصاحب عمل لديه منتجاته، هناك العديد من الأمور التي أرغب في أن أحصل على المساعدة فيها، ولكن تعيين مستشار بساعات عمل من دون أن أفهم طبيعة عمله هو أمرٌ مرعب، ماذا لو كلفني ذلك أكثر مما أتوقع؟ أو ماذا إذا كان ما أحتاجه حقًا هو الدعم المستمر ليس إلا؟ إذا استطعت أن تجعل خدماتك الاستشارية تشبه في طبيعتها المنتجات الملموسة من خلال الطريقة التي تعلن عنها، ستجعل الأمور أسهل بكثير لأصحاب العمل الذين لا يعلمون حقًا ما يحتاجونه وما هي الميزانية المناسبة له. هذا المصطلح يسمى "productized consulting" والذي يتضمن صياغة الخدمات بشكل منتجات تتسم بأن لها ساعات عمل محددة وسعرًا ثابتًا أو مصاريف شهرية محددة. وكمثال لبعض الشركات التي حولت خدماتها المستقلة لمنتجات، انظر لمقال "Brennan Dunn المُعنون: 3 Great Examples of Productized Consulting Services. أهداف العمل أهم من تجميله أعتقد أن أهم شيء تعلمته من كوني عميلاً هو أن عبارة "جيدٌ بما يكفي" كافية جدًا. كمطور، فأنا أحتاج المزيد من الوقت لأخرج بعملٍ رائع، لكن مؤخرًا شعرت بأننا عادة ما يُطلب منا أن نختصر في العمل، ولا نصل فيه لدرجة الإتقان التي نستطيع أن نفعلها. لكن كعميل، بالرغم من أني اعلم أن القرار قراري، لكني أحتاج دائمًا لمن يقول لي "هذا العمل سوف يفي بالغرض". أنا لا زلت أحب أن أتقن كل شيء، لكن أحيانًا، من المهم أن تخرج شيئًا ما للنور، حتى لو اضطررت للقبول ببعض الخدوش البسيطة. فمثلاً، قد قمنا في الفترة الأخيرة بإعادة بناء نظامنا الداخلي بما يسمح للعملاء بالدفع مقابل منتجاتنا والحصول على رخصة بذلك، لقد انتقلنا من التعامل مع "PSP" إلى "Stripe" وقمنا ببعض التغييرات الأخرى التي ستمكننا من تنفيذ ما نخطط له في المستقبل. وقمنا بذلك باستخدام لوحة قيادة "Dashboard" بدائية للغاية، مع عدد من المهام التي يمكن جعلها أوتوماتيكية من خلال واجهات متعددة "API" لم تنته حتى الآن. بالنسبة للشركة ولعملائنا، كان أهم شيء هو الأجزاء التي يتعاملون معها مباشرة، وكانت الخدوش التي تحدثنا عنها من قبل مجرد مشكلة تواجهنا نحن، نستطيع التحسين فيها مع الوقت. حتى تستطيع العمل بهذه الطريقة مع الموظفين المستقلين ستحتاج تغييرًا في العقلية أولاً ثم في طريقة عرضك ووصفك للوظائف التي تطلبها. من أهم الأسباب التي جعلتنا نكره شعورنا بأننا نقوم بعملٍ غير متقن هو أننا اعتدنا فيما قبل أن نتعاقد على عمل منتجٍ واحد محدد، وتنتهي مهمتنا بمجرد انطلاق المشروع، وكنا نعلم أن مهما كانت الحالة التي سيظهر بها المشروع ستبقى دائمًا هي الحالة التي سيظل عليها. والآن فنحن حينما نُعيّن مطورين، نبحث عمّن لديه رغبة في إنشاء علاقة عمل مستمرة. ونأمل أن هذه العلاقة تعطيهم الثقة اللازمة ليشعروا أنه عندما نطلب منهم أن ينشروا عملاً قاموا به فلن تكون هذه هي نهاية عملهم. إذا كنت أكتب أحد الأكواد لشخصٍ ما الآن، أعتقد أني كنت سأشجع هذا النوع من العلاقات أكثر مما كنا نعمل في السابق، فبدلاً من لوم العميل الذي يريد أن ينشر عملاً ما لم ينته تمامًا بعد، كنت سأحاول أن أساعده ليصل لنقطة ما لا نكون فيها قد تركنا العمل ليقوم به غيرنا. الفواتير: قاتل العلاقات إن العديد من مواضيع الموضحة أعلاه يتم التأثير عليها بطريقة بناء، ونقل المشاريع ودفع فواتيرها أيضًا، فبينما كانت فاتورتنا الأخيرة لم تُرسَل بعد حتى يتم الانتهاء من العمل، فإن العملاء عادة ما يرون أن الفواتير هي وسيلة للسيطرة علينا إلى أن ننتهي من أحد العناصر، وهذه طريقة قاتلة بالنسبة للعمل إذا كان لديك النية في خلق علاقات جيدة مستمرة. العديد من موظفينا المستقلين الآن يدفعون الفواتير أسبوعيًا أو كل أسبوعين عندما يعملون على تنفيذ شيءٍ لنا، وأنا أحب هذا الأسلوب جدًا، فإذا طال وقت العمل فإننا سنضطر أن ندفع أكثر لهذه الزيادة في أيام العمل –مع احتمالية تأخير أخرى إذا حجز العميل مهامًا أخرى- لكن الوظيفة ككل لا تحتاج إعادة التفاوض عليها. هناك عدم توازن كبير في علاقة العميل بالمطور، فالعميل عادة ما يُحكم سيطرته على أجر المطور، حيث لن يدفع له إلا حينما يرى أن نتائج عمله مُربحة. أما المطور فعادة ما يكون متحفظًا في معلوماته، وفي أغلب الحالات يكون هو الشخص الوحيد الذي يفهم تمامًا الجزء الأكبر من طبيعة عمل العميل، فقد يشعر المطور كما لو أن عمله لا يحظى بالتقدير المطلوب، بينما يشعر العميل كما لو أن المطور ينفق الكثير من الوقت على أشياء تافهة. بالطبع يوجد عملاء يعاملون المطورين بطريقة سيئة مهما بذل المطورون من جهد في إتقان العمل أو في محاولة التواصل معهم، وبالرغم من ذلك، أعتقد أن الكثير من العلاقات تصبح متوترة بسبب عدم التوازن الذي يسببه نظام الدفع في المنظومة ككل. معًا أفضل في النهاية فإن أفضل العلاقات على الإطلاق بين المطور والعميل ينبغي أن تكون ذات منفعة للطرفين، شريكين في العمل يعملان سويًا لمصلحة كلٍ منهما، يفهمون كيف يتواصلون سويًا لتحقيق أهداف العمل، يبدو ذلك مثاليًا، وهو كذلك، لكني بدون أن أضع نفسي في موضع العميل لم أكن لأستطيع أن أقَدِّر ذلك. ترجمة -وبتصرف- للمقال: Lessons Learned by Being the Client، لصاحبته Rachel Andrew.

بُنيت jQuery على لغة جافاسكريبت، وهي لغةٌ غنيّة وقويّة في حدّ ذاتها. يُغطّي هذا الدّرس أساسيّات لغة جافا سكريبت، وبعض الأخطاء الشّائعة الّتي يرتكبها المبتدئون بها. يُفيد هذا الدّرس القادمين الجدد إلى عالم البرمجة، ويفيد أيضًا المبرمجين بلغات أخرى الّذين لم يسبق لهم الاطّلاع على الجوانب المميّزة لـJavaScript. فيما يلي برنامج JavaScript بسيط يُضيف رسالةً إلى صفحة ويب: // أنشئ دالّة لإلقاء التّحية على شخص // وأسندها إلى المُتغيّر `greet` var greet = function( person, message ) { var greeting = 'Hello, ' + person + '!'; log( greeting + ' ' + message ); }; // استخدم الدالّة لتحيّة Jory، بإمرار اسمها ورسالة التّحيّة greet( 'Jory', 'Welcome to JavaScript' ); // استخدم الدالّة لتحيّة Rebecca، بإمرار اسمها ورسالة مختلفة greet( 'Rebecca', 'Thanks for joining us' );مُلاحظة: في المثال السابق، استخدمنا الدّالّة log. وهي دالّة مُساعِدة متوفّرة في الأمثلة في هذه السّلسلة فقط، وليست متوفّرة تلقائيًّا في JavaScript، يمكن استخدام log في محرّر النّصوص البرمجيّة في هذه السّلسلة، ولكن ستحتاج إلى استخدام console.log محلّها في النّصوص البرمجيّة خارج السّلسلة، وعندها ستُطبع نتائج النّصّ إلى طرفيّة المتصفّح الّذي تستعمله. // create a function that will greet a person, // and assign the function to the `greet` variable var greet = function( person, message ) { var greeting = 'Hello, ' + person + '!'; log( greeting + ' ' + message ); }; // use the function to greet Jory, passing in her // name and the message we want to use greet( 'Jory', 'Welcome to JavaScript' ); // use the function to greet Rebecca, passing in her // name and a different message greet( 'Rebecca', 'Thanks for joining us' );النّتيجة النّتيجة مطالعةلم نخض في أعماق لغة JavaScript بعدُ. شبكة مُطوّري موزيلّا (MDN) مصدر ممتاز (بالإنكليزيّة) لتعلّم JavaScript بتفاصيلها، وخصوصًا دليل JavaScript على الشّبكة. أكثر المواضيع أهمّيّة لك الآن: نظرة عامّة على JavaScriptالقيم والمتغيّرات والمكوّنات الحرفيّةالدّوالّعبارات الدّوالّ المُستدعاة فورًاالمصفوفاتمصادر إضافيةشبكة مُطوّري موزيلّا: JavaScriptChrome Developer Tools OverviewFixing these jQuery: A Guide to DebuggingChrome Developer Tools Cheat SheetChrome Dev Tools: 12 Tricks to Develop Quicker (فيديو)ترجمة (بشيء من التصرف) للجزء الأول من سلسلة  jQuery Fundamentals لمؤلّفتها Rebecca Murphey.