التكاليف الخفية والسرعة الحقيقية في عملية تطوير المنتجات

كانت فرقة وو تانج كلان على حق

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

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

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

الدروس المستفادة من الإخفاقات

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

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

مثال على ذلك: 

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

ولو فهم المستثمر الأسباب الكامنة وراء عدم فعالية الفريق فهماً أفضل، لاستنتج أن الفريق لا يستخدم إمكاناته إلا في 60-70%. ومن شأن تحسين المعدات وتخصيص بضعة أيام عمل لأتمتة العمل أن يحل المشكلة.

ولسوء الحظ، عليه الآن أن يدفع لمطور آخر سيعمل على نفس المعدات وستكون كفاءته أيضًا عند 60-70%.

الحل أ:

• الفريق (2 x مطور أقدم للخدمات المشتركة): $20k / شهر
• السحابة الخدمـــات 200$ / شهر
• أجهزة جديدة للمطورين: $10k

تبلغ تكلفة المشروع من الآن $20,200/شهرياً

إجمالي الإنفاق في 12 شهراً 12 * 20,200 + 10,000 + 10,000 = 1 ت ص 62 ت 252,400

الحل ب:

• الفريق (2 x مطور أقدم للخدمات المشتركة): $20k / شهر
• مطور جديد (1 x مطور أقدم للخدمات المشتركة): $10k / شهر

من الآن تكاليف المشروع $30,000/شهرياً

إجمالي الإنفاق في 12 شهراً 12 * 30،000 = $360،000

يحقق مطوران يعملان بطاقة 100% تقريبًا نفس ما يحققه ثلاثة مطورين يعملون بطاقة 60-70%. وسيدفع المستثمر أكثر من $ 100,000T أكثر مقابل نفس قدرة المعالجة في السنة بسبب قرار تصميم خاطئ!

بناء منتج مثالي مثل مطاردة الأرنب

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

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

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

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

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

من الجيد معرفة كل شيء عن شيء ما وشيء ما عن كل شيء

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

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

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

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

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

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

معدات قوية قبل أن تذهب

في سياق احتياجات التواصل المتزايدة، تسجل أدوات مثل Whimsical وMiro وMural وFigma وBalsamiq زيادة مذهلة في شعبيتها.

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

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

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

يمكنك (ويجب عليك) أن تكون كسولاً

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

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

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

أظهر ثقتك وتشارك المسؤولية وانفتح على تواصل حقيقي ثنائي الاتجاه بحيث المنتج سيكون أفضل، وسينزاح عبء القيام بكل شيء بمفردك عن كاهلك الذي غالبًا ما يكون مستنزفًا للمؤسسين ورواد الأعمال! في The Codest، نحن نترجم هذا المبدأ ليس فقط في المشاريع، ولكن أيضًا في العمليات الداخلية - ولعل هذا هو السبب في أننا نتمتع بمعدلات استبقاء عالية لكل من العملاء والموظفين (قصة حقيقية، كلاهما> 90%).

عالج نفسك بقليل من الكسل، وانقل المسؤولية بجرأة وتخلَّ عن أي عمل زائد عن الحاجة غير ضروري للمضي قدمًا - فالوظائف التي قد تكون "لطيفة" يمكن أن تنتظر دائمًا.

التركيز على إيجاد الإجابات الصحيحة

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

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

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

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

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

الاستنتاجات

بالنظر إلى جميع المشاكل المذكورة أعلاه، يمكننا ملاحظة العديد من المشاكل التي تظهر بانتظام في عملية التصميم:

- التركيز المفرط على الربح وتجنب النظر إلى الإخفاقات,

- عدم الدقة وعدم تصوير الأخطاء الخاصة بالأشعة السينية,

- مطاردة المنتج المثالي الذي يدور في رأسك، ولكنه ليس ما يحتاجه السوق,

- التنفيذ المفرط لعمليات الكتاب المدرسي - الإفراط في التطوير والإفراط في التصميم,

- عدم مرونة العمل الجماعي وإجبار الموظفين على البقاء في مجالات تخصصهم فقط,

- التواصل غير الفعال,

- الميل إلى إعادة اختراع العجلة.

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

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

عندما لا تكون كافيًا تمامًا، فأنت على الأرجح تبالغ في الاستثمار. هل لديك الكثير من المال؟

اصمت وخذ أموالك! وإلى جانب ذلك

1. لا تقدم Scrum لمجرد ممارسة Scrum.
2. إيلاء المزيد من الاهتمام للهفوات في العملية.
3. ضع أهدافًا أصغر يمكن تحقيقها وقابلة للقياس على المدى القصير - بشكل عام، التزم بالحد الأدنى.
4. في بعض الأحيان خريطة الطريق يكفي لإعطاء الفريق إحساسًا بالهدف المشترك وإشراكهم في العمل الفعال هنا والآن.
5. قم ببناء فريق جيد لتتمكن من منحه الحرية التي يحتاجها.
6. قم دائمًا بالتشكيك في مجموعة الأدوات الحالية - ابحث عن التحسينات الممكنة في ورشتك.
7. صمم العملية من منظور الشخص الكسول - كما لو كنت تريد أن تفعل أقل قدر ممكن.

اقرأ المزيد:

CTO التحديات - توسيع نطاق ونمو منتجات البرمجيات

أي قاعدة بيانات تختارها لنوع بياناتك المحدد في مشروع البرنامج الخاص بك