يشرح الكاتب في هذا المقال تجربته في عالم سريع النمو من التطوير بدون شيفرة برمجية وتأثيره على على مستقبل إدارة المنتجات.
يجلب عدم وجود شيفرة برمجية تطويرًا لجمهور جديد. المصدر: glazestock.com لصاحبها Rudyitas
كنتُ -يقول الكاتب- مدير منتجات لمدة 10 سنوات حتى الآن، وذلك إما كجزء من فريق أو أنشأت فرقًا جديدة كاملة، أو كمؤسس لشركة ناشئة صنعت منتجًا. كان مفهوم إدارة المنتجات مفهومًا جديدًا إلى حد ما بالعودة إلى عام 2009 في المملكة المتحدة على الأقل وخاصةً في المنظمات الكبرى، فقد اعتقد مديرو المنتجات أنهم يواجهون صعوبةً اليوم في شرح ما يفعلونه للأصدقاء والزملاء، وقد كان ذلك أسوأ بكثير في ذلك الوقت. لكن جاءت نقطة التحول الكبيرة بالنسبة لي مع إصدار كتاب Lean Startup لصاحبه إريك رييس Eric Ries في عام 2011، وبالتالي كان لدينا طريقة أو حركة لاتباعها وتأييدها، ثم تغير كل شيء.
تُعَد حلقة الاستجابة المتمثلة في البناء-القياس-التعلم من المكونات الأساسية لمنهجية كتاب Lean Startup. وتتمثل الخطوة الأولى في اكتشاف المشكلة التي يجب حلها، ثم تطوير منتج الحد الأدنى Minimum Viable Product -أو MVP اختصارًا- لبدء عملية التعلم في أسرع وقت ممكن. يمكن للشركة الناشئة بعد إنشاء منتج الحد الأدنى MVP العمل على ضبط العملية التي تشمل القياس والتعلم ويجب أن تتضمن مقاييسًا قابلة للتنفيذ يمكن أن توضح السبب والنتيجة.
اقتباسالمشكلة أنه يُفترَض أن تكون هذه العملية سريعةً للغاية، فهي كذلك من الناحية النظرية، ولكن نادرًا ما تكون سريعةً من الناحية العملية حسب تجربتي.
الاعتدال في تقليل الهدر
لا يزال نهج كتاب Lean Startup يُستخدَم على نطاق واسع بوصفه الأسلوب الواقعي لبناء المنتجات والشركات الناشئة، ولكن الشيء الذي لم يتغير هو طبيعة تكوين الفريق، والأشخاص الذين تحتاجهم لإنشاء منتج ما.
لقد أُنشِئت جميع فرق المنتجات تقريبًا بحيث تكون مكونةً من مدير المنتجات Product Manager -أو PM اختصارًا- ومدير المشروع أو محلل الأعمال والمصمم وفريق التطوير. لا يزال منتج الحد الأدنى MVP يتطلب هذا الفريق متعدد الوظائف من الأشخاص ومدة بضعة أشهر في أحسن الأحوال أو فترة أطول بكثير في الواقع لجعل هذا المنتج في متناول العملاء، ونعني بمنتج الحد الأدنى MVP منتجًا وظيفيًا وليس صفحة هبوط أو نموذجًا أوليًا تفاعليًا.
أحب أن أكون جزءًا من إنشاء منتجات جديدة وإيجاد حلول جديدة للمشاكل وللمشاريع الجديدة، فهذا ما يناسبني، ولكن كنت دائمًا محبطًا بعض الشيء بسبب الوقت والمال اللذين يتطلبهما إنجاز المهام.
يُعَد إنفاق ما يزيد عن 50 ألف جنيه إسترليني ومدة 6 أشهر للحصول على منتج الحد الأدنى المُفترَض بمثابة حكم بالإعدام، أو على الأقل جهدًا كبيرًا بالنسبة للشركات الناشئة في المراحل الأولى، خاصةً تلك الشركات التي ينتهي بها الأمر باستخدام الوكالات لبناء منتجاتها. سترتفع التكاليف الشاملة قريبًا حتى لو كنت تقنيًا أو كنت محظوظًا بما يكفي ليكون لديك تقني كمؤسس مشارك.
ستتعلم بسرعة بصفتك شخصًا منتجًا لديه عقلية تجريبية أن الأخطاء هي ببساطة طريقة أخرى لتنفيذ الأشياء، لذا يجب أن يكون لديك ذهن متفتح وأن تهتم بما يمكن أن يحل مشكلة العميل على أفضل وجه، وما الذي سيؤدي المهمة التي يحاولون إنجازها.
يمكنني تعلم البرمجة بدلًا من الاعتماد على فريق كامل لإنشاء منتج الحد الأدنى MVP، أو بالأحرى اعتدتُ أن أكون قادرًا على ذلك. لقد صنعتُ "لعبة حاسوبية" عندما كان عمري 11 عامًا لحاسوب كومودور 64 (نسخة هوبر) وبعت شرائطًا منها في المدرسة، ولكنك تشعر مع كتابة شيفرة برمجية أنك متخصص في مجال واحد فقط، وحتى هذا يتطلب الكثير من الوقت والالتزام لمجرد الحصول على الأساسيات، كما أنني لست مصممًا محترفًا ولا بأي شكل من الأشكال، ولكنني أعرف المبادئ الأساسية فقط، فقد أنشأت نماذجًا أوليةً تفاعليةً وهي جيدة للحصول على بعض الملاحظات الأولية، ولكنها ليست منتجًا مناسبًا في النهاية.
لحسن الحظ، هناك شيء ما يحدث الآن في عالم تطوير المنتجات استجابة لدعواتي ودعوات العديد من الأشخاص المحبطين حول العالم لتحسين جميع هذه الأمور، حيث سنتحدث عن ذلك الآن.
الدخول في حركة التطوير بدون شيفرة برمجية
صادفتُ أداة Webflow منذ حوالي 4 سنوات، حيث كانت ولا زالت منافسًا لووردبريس Wordpress، واستخدمتُها لإنشاء مواقع الويب دون الحاجة إلى تعلم كتابة شيفرة برمجية. ولتوفير بعض المال عند الاضطرار إلى توظيف شخص آخر، وقد تطورَت كثيرًا منذ ذلك الحين وتُعَد أداةً مهمة، لكنها لا تزال في النهاية مجرد أداة للواجهة الأمامية، إذ ستحتاج إلى قاعدة بيانات خلفية وسير عمل لإنشاء منتج وظيفي كامل. إذا أردت مثلًا إنشاء نسخة من موقع Medium مع خطة عضوية وأسعار متدرجة وما إلى ذلك، فلا يمكنك استخدام Webflow فقط، إذ توجد العديد من مواقع الويب ومنصات أنظمة إدارة المحتوى CMS المتاحة.
اقتباسلقد ظهرت في الآونة الأخيرة فكرة استخدام منصة السحب والإفلات، وهو نهج التطوير المرئي الذي يمكن لغير المبرمجين من خلاله صنع الأشياء.
أمضيتُ الأشهر الثلاثة الماضية في هذا العالم الجديد الشجاع بلا شيفرة برمجية دون هدف محدد، حيث جربت إنشاء سوق وإنشاء تطبيقات داخلية للمساعدة في جمع البيانات والمؤثرات المرئية وإنشاء رد آلي صوتي. لا يزال هناك منحنى تعليمي كبير قبل أن تبدأ في توقع أنه يمكنك طرح تطبيق لائق ينفّذ كل ما تحتاجه بسرعة، فكل منصة لها حيلها الخاصة، ويستغرق الأمر بعض الوقت لمعرفة ما هي قادرة على فعله.
اقتباسالحيلة الحقيقية هي معرفة كيفية الجمع بين أدوات مختلفة بدون شيفرة برمجية للعمل مع بعضها البعض، وبناء مكدس منها لا يحتوي على شيفرة برمجية بصورة أساسية.
سيكون الأمر مختلفًا لكل مشروع، لذا يُعَد الوصول إلى النقطة التي تعرف فيها فطريًا طريقةً لتطبيق ما تريد تحقيقه هو المكان الذي تكمن فيه المهارة الحقيقية. وهنا أدين بالفضل إلى الأسطورة بين توسل Ben Tossell من منصة Makerpad الذي يُعَد مصدر مصدر إلهام حقيقي في هذا المجال.
الخبر السار هنا هو وجود أدوات للتطوير بدون شيفرة برمجية فعليًا، فلا حصر للاحتمالات. كذلك، تظهر الابتكارات الجديدة التي لا تحتوي على شيفرة برمجية بصورة أسرع مما يمكن أن يقوله إطار عمل روبي أون ريلز Ruby On Rails، كما صعدت المنتجات التي بدون شيفرة برمجية إلى المراتب الأولى على موقع برودكت هنت ProductHunt.
أركز حاليًا في هذه المرحلة من رحلتي على إنشاء منتجات الحد الأدنى MVP. أعتقد أنه الوقت المثالي لإنشاء منتجات MVP السريعة التي تنفّذ ما نحتاجه بالنظر إلى ما هو متاح الآن من حيث الأدوات التي لا تحتوي على شيفرة برمجية وما تقدمه.
يمكنك إنشاء تطبيقات الويب أو التطبيقات الأصيلة Native والواجهة الخلفية وإدارة سير العمل وبدء الأحداث ودمج المدفوعات وغير ذلك الكثير؛ لكنني متأكد من أن أي شيء سيكون ممكنًا في القريب العاجل، فأيّ شيء يمكن تنفيذه مع شيفرة برمجية سيُنفَّذ بدونها.
تأثير التطوير بدون شيفرة برمجية على مستقبل المنتجات والتصميم والبرمجة
لا بد أن يكون لحركة التطوير بدون شيفرة برمجية -مثل أيّ ثورة جيدة- نصيبها من النقاد والمتشككين، ويمكن أن تفترض أن المبرمجين هم الكارهون الأكبر، ولكنني لم أشهد الكثير منهم في الواقع، والسبب هو أن البرمجة بمعناها النقي لا يمكن أبدًا أن تندثر، إذ لا بد من شخص يبرمج جميع المنصات والأدوات التي ستبتكر عالمًا دون شيفرة برمجية. يرغب المطورون في تبني عدم وجود شيفرة برمجية وتعلم المهارات بأنفسهم، وينطبق الشيء نفسه على المصممين، إذ أننا ننتقل إلى عصر جديد من صنع الأشياء.
لذا يمتلك مديرو المنتجات الآن فرصةً مهمةً للغاية في أن يكونوا قادرين على الجمع بين طرقهم المُجرَّبة والمُختبَرة لتحديد المنتجات والميزات التي يجب إنشاؤها مع إنشائها فعليًا، وستنخفض أوقات التسليم والتكاليف، وستظهر وظائف جديدة، وسأكون سعيدًا في ذلك كله.
ترجمة -وبتصرُّف- للمقال The Future of Product Management is No-Code Development لصاحبه Martin Slaney.
أفضل التعليقات
لا توجد أية تعليقات بعد
انضم إلى النقاش
يمكنك أن تنشر الآن وتسجل لاحقًا. إذا كان لديك حساب، فسجل الدخول الآن لتنشر باسم حسابك.