تطوير عقد الإلكترونيات. حساب المشروع




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

ما المشاريع التي لا ينبغي النظر فيها


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


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

ما الذي نحتاج إلى طرحه لتقييم فرص نجاح المشروع؟


  1. لماذا تحتاج المؤسسة إلى منتج معين (أهداف إنشاء المنتج)؟ نحن بحاجة إلى معرفة الصيغة الأكثر دقة لمهمة العمل ، لذلك نقوم بتصفية الحالمين مع "الفكرة الرائعة" التالية لحصيرة الحمام الآلية ، مع بلوتوث وتطبيقات الهاتف المحمول.
  2. من هو البادئ للمشروع (DM)؟ نكتشف من المسؤول عن التكنولوجيا ومن يخصص الميزانية. عادة ما يكون هؤلاء أشخاصًا مختلفين ، ويتطلبون أساليب مختلفة من حيث المبيعات.
  3. ( )?
  4. . : , , , .?
  5. ( , )?
    . , , , .
  6. ( )? , , , . « » =)
  7. ( .., )?
  8. ?

    • — :
      1. (, )?
      2. ?
      3. (), ? -? ?
    • — : . , , . « », , .
    • ? ? ? — .
  9. ? — :
    • (, )?
    • (, )?
    • ?
    • , ?
    • ( )?
  10. () ( )? «», - . , 9 .
  11. ? , . , , .
  12. (, , , )? « , ». , -.
  13. ? : , .
  14. ? – .
  15. ? (, , , , ). . ?
  16. ? ?
  17. (, , )?
  18. ? .


-




لذلك ، يلبي العميل والمشروع جميع المتطلبات ، نبدأ التقييم. التقييم غير دقيق وغير لائق. إذا لم يكن لدينا بعد المعارف التقليدية ، نحصل على تقييم غير لائق مع انتشار كبير. كتب TK - تلقى تقييما غير دقيق. بدون المعارف التقليدية ، درجة تحمله ± 400٪ أو أكثر. يسمى هذا مخروط عدم اليقين: الرسم البياني حول الواجهات ، ولكن جوهر المشاريع المختلفة هو نفسه. كلما عرفنا أكثر ، قل الشك. لا تدخر الوقت والجهد في المعارف التقليدية.




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



يبدأ الاجتماع بمناقشة عامة للمشكلة لتشكيل فهم مشترك من قبل جميع المشاركين. بعد ذلك ، تم إنشاء هيكل هرمي للعمل ( WBS ) للمشروع .
بالنسبة لجهاز واحد ، يتم تخصيص أجزاء البرامج والأجهزة. بالنسبة للنظام ، تتم إضافة أجزاء مختلفة مثل برنامج الاختبار وأجهزة المحاكاة وجزء الخادم وما إلى ذلك. تنقسم الأجزاء الناتجة إلى أجزاء أصغر ، على سبيل المثال ، فروع الأجهزة إلى مراجعتين للوحة PCB والتصميم. المرحلة التالية هي تقسيم الأجزاء إلى مهام منفصلة. إذا كان كل شيء واضحًا مع التنفيذ ، فيجب أن تكون المهام صغيرة. المهمة "كتابة البرامج الثابتة" بشكل قاطع لا تناسب. نعتبر المهام المحددة العادية مع تصنيفات صغيرة ، على سبيل المثال: "MCU I2C Driver" ، "Raise the Project" ، "E3 Scheme".
لا يجب عليك تقييم مدى تعقيد المهام مسبقًا ، لأن تعقيدها وعلاقاتها لن تتضح إلا عندما تكون جميعها مكتوبة على السبورة.

يتم تعيين جميع المهام في ساعات العمل. الطريقة هي تقييم خبير . يمكن أن تأخذ الساعة قيمًا من عدد من السلطات: 2 ، 4 ، 8 ، 16 ، 32 ، 64 ، 128 ... تظهر المهام التي تحتوي على تقييم لمدة 128 ساعة أو أكثر عندما يكون التنفيذ غير واضح. هذا يعني أنه من المفيد القيام بعمل لتوضيح المتطلبات ، والتحقق من قابلية تطبيق التكنولوجيا ، وأحيانًا مجرد تفريق وتدخين جوجل.
وفقًا لملاحظاتي ، من الممكن زيادة دقة التقييم ، أولاً وقبل كل شيء ، طلب رأي المطورين الأقل خبرة. لذلك يتعلمون تقييم المهام بشكل أسرع من تلقاء أنفسهم. إذا كان مهندس مرموق قد تحدث بالفعل ، يميل الجميع إلى الاتفاق ببساطة مع رأيه. وعندما يبدأ العمل في المشروع ، من المرجح أن يتم حل المهام ليس من قبله ، ولكن من قبل أولئك الذين لم يقولوا أي شيء. سنستمر في سماع تقييمهم ، ولكن ليس في الوقت المناسب.
عندما يتم تقييم جميع المهام ، نلخص النتائج ونضيف 30٪ إلى البرنامج لتصحيح الأخطاء و 30٪ أخرى لاختبار البرنامج. هذه الأرقام مأخوذة من إحصائيات المشاريع المنجزة.
ونتيجة لذلك ، تظهر الصورة التالية على اللوحة:



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

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

يتم إدخال التصنيفات المستلمة من نادي وانغ في Redmine. EasyWBS مناسب لإضافة المهام بسرعة في شكل مرئي:




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






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









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

والآن - دعنا نناقش في التعليقات مناهجك لتقييم المشروع!

All Articles