البحث في الموقع

عندما بدأت عملي كاستشارية تطوير مواقع للعملاء كان علّي أن أتعلم العديد من الأشياء، خصوصًا بعد أن تحوّلنا إلى شركة منتجات وذلك بإطلاق تطبيق خاص بنا (يُدعى Perch). أهمّ هذه الأشياء هي طريقة التعامل مع طلبات إضافة الميزات في الوقت الذي يكون فيه "مالك" الموقع الذي تنشئه ليس عميلًا واحدًا، وإنّما الآلاف. عندما تقوم بإنشاء موقع ما لعميل ما، وكان هذا العميل يطلب إضافة ميزات معيّنة إلى الموقع قد تكون معقّدة، تتطلب وقتًا طويلًا أو تجعل واجهة الاستخدام (user interface (UI صعبة الاستخدام، عندئذ قد ترفض أو تنفذ هذه الطلبات إذا أصرّ العميل على إضافتها وكان مستعدًّا للدفع مقابلها، ففي النهاية المشروع مشروعه هو، وعليه أن يتحمّل تبِعات إضافتها إذا كانت تؤدي إلى تعقيدات أكبر. إنّ إضافة كل المقترحات إلى المنتج قد تكون مستحيلة، لأن المُنتج يُستخدم بشكل مباشر من قِبل الآلاف من الزبائن، وما يبدو سهلًا أو بديهيًّا لمستخدم ما يمكن يكون مُربكًا لمستخدم آخر. لذلك فإن إضافة العديد من الميزات الدقيقة من أجل تلبية جميع المتطلبات ستؤدي إلى واجهة استخدام معقّدة ومُربِكة، ناهيك عن الوقت الذي يُستغرق من قِبل المستخدمين للتعرّف على المنتج. بالنسبة لي اعتبر هذا الأمر مهمًّا جدًّا خصوصًا عند العمل على منتجاتي الخاصّة، فالبساطة هي من القيم الجوهرية لدينا. سأستعرض في هذا المقال الأمور الأساسيّة التي تعلّمتها عند إضافتي للعديد من الخصائص والميزات إلى Perch خلال السنوات الخمس الماضية. ماهي المشكلة التي تحاول حلها؟يميل الأشخاص إلى طلب ميزات محدّدة جدًّا، وهم بذلك يقومون بتقديم الحل بدلًا من شرح المشكلة. يواجه العديد من المطوّرين هذا الطلب: "قم فحسب بإضافة زرّ هنا" دون معرفة المتطلبات التي ينطوي عليها هذا الخيار. توّقع أن تواجه العديد من هذه الطلبات عندما تمتلك منتجًا ما. لا يقضي الزبائن أوقاتهم في استنباط الأفكار من أجل منتجك، وإنّما يقومون بذلك لأنّ مشروعهم الخاص يتطلّب تلك الفكرة أو الميزة، وبذلك يقومون باقتراح الحلول اعتمادًا على حالة الاستخدام use case الخاصّة بهم في ذلك الوقت. ولتجنّب ذلك، يجب عليك معرفة المشكلة التي يواجهها المستخدم، ما الذي يحاول المستخدم تحقيقه من خلال الحلّ الذي اقترحه؟ يمكنك عن طريق التساؤل بهذه الأسئلة أن تتوصّل إلى معرفة الاحتياج الحقيقي للمستخدمين وتقديم الحلول فورًا، في بعض الأحيان، دون الحاجة إلى إضافة ميزات إضافيّة. انتقل من الخاص إلى العامما الذي ينبغي عليك فعله عندما تُحدّد المشكلة وتتضح لك حالة الاستخدام use case لشيء في منتجك لم يكن ممكنًا أو كان ممكنًا بصورة جزئية فقط؟ بطبيعة الحال ستنطلق وتبدأ بتطويرها فورًا، خصوصًا في المراحل المبكرّة للمنتج. عندما يحدّد الزبون عيبًا في مكان ما من مُنتجك ستبدأ حينها بالتخوّف من فقدان الزبائن. عند هذه النقطة وقبل أن تُسرع إلى البدء في كتابة شفرة الميزة الجديدة، عليك أن تخفّض حماسك وتقرّر أي نوع من الإضافات هي التي تحقق أهداف المنتج وتُلبّي احتياجات أغلبية الزبائن. إذا قمت بتحديد حالة استخدام أكثر عمومية فمن المرجّح إنّ الأشخاص الآخرين ستكون لديهم المتطلّبات نفسها. وإذا لم تكن تعرف بعد ماهيّة تلك المتطلّبات فعليك أن تضع الميزة جانبًا لغرض دراستها والنظر فيها. في Perch، عندما أردنا تجميع المزيد من طلبات الميزات المتشابهة أصبحت لدينا العديد من تلك الطلبات في قائمة المهام backlog، وبذلك أصبح بإمكاننا المحاولة لتطوير ميزة تمثّل الحلّ للمشكلة العامّة. قد تكون هذه الميزة مختلفة جدًّا عن الحلول الخاصّة التي يقترحها الزبائن، لكنّها تحل المشاكل التي واجهتهم جميعهم. اختر ما يصنع فرقا للأغلبيةمن السهل أن تشعر بالإرهاق من طلبات الميزات إذا كنت تمتلك منتجًا مشهورًا. لكن ماذا لو كان عدد كبير من تلك الطلبات مناسبًا وتعتقد بنفسك بأنّها تصلح لأن تكون إضافات رائعة؟ في بعض الأحيان تكون طلبات الميزات ذات ترتيب اعتمادي؛ أي أنّ عليك إضافة ميزة معيّنة لكي تتمكّن من تفعيل شيء آخر. ومع ذلك يحصل أحيانًا أن تجد نفسك أمام العديد من الخيارات ذات القدر نفسه من الروعة والأهمّية، فأيّها تطوّر أولًا؟ اعتدت في مواقف كهذه أن اختار الميزة التي تخدم أغلبية الزبائن. يُتيح لك هذا النهج أيضًا إجابةً جيّدة للاقتراحات المُلحّة لإضافة ميزة تُستخدم من قِبل عدد قليل من الزبائن، فبإمكانك أن توضّح لهم بأنّك ترتّب الطلبات حسب عدد الأشخاص الذي يحتاجون تلك الميزة. طور من أجل الزبائن المثاليين وليس اللحوحينشخصيًّا، أرغب في إضافة الميزات التي تفيد الأشخاص الذين تتوفر لديهم صفات مطابقة لملف الزبون المثالي customer profile لدينا. إنّ نظام Perch كان موجّهًا دائمًا إلى سوق المصمّم والمطوّر المِهني، فهو يفترض، على سبيل المثال، إنّ الشخص الذي يُنشئ الموقع لا بدّ أن يعرف كيف يكتب شفرات HTML. هنالك العديد من الأشخاص الذين يرغبون باستخدام Perch لكنّهم من المقيّدين باستخدام أداة تصميم وإنشاء المواقع WYSIWYG website building ويعتقدون إنّ Perch يجب أن يدعم ذلك. بعض من هؤلاء يكون صريحًا جدًّا في التعبير عن خيبة أملهم تجاه Perch لعدم احتوائه على أدوات لغير المبرمجين، وهم يشيرون بذلك إلى أننا مخطئون في صرف النظر عن هذا الجانب من العمل. إنّ دعم هذا النوع من الزبائن من خلال برنامج كهذا سيجعل Perch أداة مختلفة جدًّا وأقلّ جذبًا لمطوري واجهات المواقع ومصمّمي المواقع الذين نخدمهم. عند النظر في طلبات الميزات نرجع دائمًا إلى المستخدمين، ونبحث عن الميزة التي تصنع الفرق الأكبر لأغلبية الأشخاص في المجموعة. إنّ نسبة الأشخاص ممن يمتلكون رخصة Perch الذين قاموا بطلب تذاكر الدعم الفنّي أو النشر في المنتديات هي 25% فقط، و10% فقط هي نسبة الذين قاموا بذلك لأكثر من مرّة. إنّ أغلبية زبائننا يقومون بقناعة باستخدام هذا المنتج وشراء الرخص لمواقع جديدة بدون التحدّث إلينا أبدًا. يجب أن تسعى وراء آراء تلك الأغلبية القنوعة، لا تغيّر الميزة التي يحبونها ويجدونها مفيدة بسبب قلّة من الأشخاص اللّحوحين. اعرف متى تقول "لا"على الرغم من أنّ كلّ ميزة مقترحة يجب النظر فيها، تدوينها، وضمّها إلى مجموعة من المتطلّبات الأخرى المشابهة، ألا إنّه من المهم أن تعرف متى تقول "لا" وترفض طلب إضافة ميزة معيّنة. فالمنتج يجب أن يُمتلك من قبل شخص، شخص أو فريق ذو إمكانية تجعله يقرر أيّ الميزات التي لا يجب إضافتها. عندما تتخذ القرار بشأن ميزة ما، عليك أن تأخذ بعين الاعتبار المشاكل التي وُجد المنتج من أجل حلّها، بالإضافة إلى ملفات الزبائن المستهدفين customer profile، وبفعل ذلك تكون قد صنعتَ مرشِّحًا للأفكار الجديدة، وطريقة لتوضيح قراراتك للزبائن الذين قد يشعرون بخيبة الأمل تجاه خيارك. عليك أن تدرك أنّك لست زبونك لقد قمنا بإنشاء Perch لنُلبّي رغباتنا الخاصّة، حاله حال العديد من المنتجات الأخرى التي تمّ إطلاقها من قبل الاستشاريين. كان الإصدار الأول منه هو ما كنّا بحاجته حقًّا؛ منتج وُجد لأجل الأشخاص الذين يهتمّون بمعايير المواقع والمحتويات المنظمة. ثمّ بعد ذلك كان علينا أن نتعلّم من التغذية الرّاجعة feedback، حيث كان علينا قبول بعض الأمور التي كنّا نعتقد بوجوب رفضها بينما هي في الواقع من المتطلّبات الحقيقة للأشخاص الذين نشعر بأنهّم يلائمون المنتج بشكل مثالي. أنا اعتقد بأنّ البرنامج يجب أن يكون قابل لتلقّي الآراء. نحن نواصل تطوير أفضل الممارسات والمعايير الحديثة للمواقع من خلال العمل على إكمال منتجنا، على الرغم من أنّ هذه القيم لم تعُد مهمّة بالنسبة للعديد من زبائننا، بينما هي في الحقيقة جوهر المنتج. نحن نواصل المضي قدمًا مع الحفاظ على البساطة التي نسعى إليها منذ البداية وذلك بوضع تلك القيم الأساسية في الاعتبار، الفهم العميق للمشاكل بدلًا من قبول أولّ حلّ مُقترح، بالإضافة إلى الاستماع إلى آراء زبائننا المهمّين. ترجمة -وبتصرّف- للمقال Managing Feature Requests لصاحبته: Rachel Andrew. حقوق الصورة البارزة: Designed by Freepik.

بعد أن قرأت مؤخرا مئات طلبات التّوظيف التي وصلتنا على موقع Work At A Startup خرجت بجملة من النّصائح في ما يخصّ كتابة السير الذاتية للمبرمجين الذّين يتقدّمون بطلب للتّوظيف في شركة ناشئة: أبق السّيرة الذّاتية قصيرة، ففي هذه المرحلة المُبكّرة قد يقرأ سيرتك شخص لا يقوم بهذا النّوع من العمل كوظيفة بدوام كامل (يعني لن يقوم بذلك شخص مُختّص في التّوظيف) لذا ساعده في المحافظة على وقته. أبقها موجزة، فالشّركات النّاشئة تختلف عن الشّركات الكبرى لأنّها لا تبحث عن سيرة ذاتية تحتوي جميع لغات البرمجة وأطر العمل المختلفة التي سمعت بها. فمن المعروف أنه يستحيل أن تتقن جميع هذه اللّغات فلا أحد يستطيع القيام بذلك لكن يجب التّركيز في المقابل على الأشياء التي تقوم بها بشكل ممتاز مع شرح يفسر براعتك. أبق محتوى سيرتك المهنيّة وثيق الصّلة بالمنصب المعروض فلا داعي لذكر أنّك عملت في مجال البيع بالتّجزئة مثلًا إلّا إن كانت الوظيفة المعروضة تتعلّق مثلا ببرمجة تطبيقات لهذا النوع من النّشاطات. شخصيّا لن أكون مهتما بهذا النّوع من التّجارب وأعتبر عرضه في سيرتك حشوًا عديم الأهميّة. بصورة إجماليّة، تبحث الشّركات النّاشئة عن موظّفين استثنائيّين وبارعين في المهمّات المحدّدة التّي تكلّفهم بها سواء تعلّق الأمر ببناء الـ back-end أو الـ front-end. تحتاج في سيرتك الذاتية إلى: إثبات أنك استثنائي في شيء تفعله. أن تبدو رزينا ومُتوازنًا. وإذا كان هناك شيء في سيرتك الذّاتية لا يحقّق أحد هذين الأمرين المذكورين فمن الأفضل أن لا تُضمّنه. أعلم أنّ هذه القواعد لا تنطبق على التّوظيف في الشّركات الكبرى لذا عليك تعديل سيرتك الذاتية بما يتناسب مع الوظائف التّي تتقدّم إليها، أمّا الأمر الأكثر أهميّة من السّيرة الذاتيّة نفسها هو أن تُدرج في رسالتك الإلكترونيّة الأسباب التّي تحفّزك للعمل مع هذه الشّركة النّاشئة وأن تتناسب أسبابك مع تلك الشّركة على وجه الخصوص فلا شيء يُرحّب به صاحب مشروع/ شركة ناشئة أكثر من رسائل من أشخاص يبدون اهتمامًا وشغفا بمشروعه. ترجمة -وبتصرّف- للمقال The Startup Resume لصاحبه Justin Kan. حقوق الصورة البارزة: Designed by Freepik.