في حياتي ، رأيت نوعين من الأعمال يتطوران بشكل أسوأ من أي شخص آخر - أصحاب الامتياز التجاري الأول وبائعي شجرة عيد الميلاد. لا يتعلق الأمر بمدى اتساع نطاق التنمية ، عندما ينمو عدد المبرمجين فقط ، بل يتعلق بالتنمية الداخلية. على الفعالية ، باختصار.
على الرغم من أنه من المحتمل استبعاد باعة أشجار عيد الميلاد من هذه القائمة ، إلا أنهم تمكنوا من مفاجأتني قبل حلول العام الجديد من خلال بيع شجرة التنوب الحقيقية. سابقا ، كانت أشجار التنوب والصنوبر فقط. حتى أنني نظرت على الإنترنت إلى كيفية التمييز بين الشجرة والتنوب - لقد كانت حقًا شجرة التنوب.
لذلك ، بقي أصحاب الامتياز 1C فقط في قائمة "معظم الشركات النامية". هناك الكثير من الأشخاص الرائعين الذين يعملون هناك ، ولكن إما أن تكون البيئة على هذا المنوال ، أو أن المكان ملعون - هناك شيء خاطئ معهم.
يفكرون فقط اليوم. ربما يكون السبب هو الربط الصارم لبائع واحد ، والذي يطور كلاً من حلول الإطار والتطبيق. في القرن الحادي والعشرين ، لن يقوم أي شخص في عقله الصحيح ببناء شركة تجارية طويلة الأجل مرتبطة بلغة برمجة واحدة ، وبيئة تنمية واحدة ، وسوق واحد؟ لكن قم بإعداد المكواة بينما تكون ساخنة - من فضلك. عندما يبرد ، سيكون من الممكن التفكير في شيء خطير.
لكن لسبب ما ، يبدو لي أنه لم يتم فقدان كل شيء. يمكنك أن تفعل أفضل.
طرق مختلفة لزيادة الكفاءة هي ، بطبيعة الحال ، مثيرة للاهتمام. ولكن مزيج أكثر إثارة للاهتمام من هذه الأساليب لنشاط معين هو حالة. ويشمل العمليات والتحفيز والأتمتة والأهداف ونظام الإدارة. ليس دائما جميع المكونات في وقت واحد - فقط ما تحتاجه.
دعونا نحاول إنشاء قضية لجزء معين من العمل الذي نعرفه - 1C: الامتياز. إنه مألوف بالنسبة لنا لأنه يتمتع بخبرة في العمل في امتيازات أخرى لعدة سنوات ، بالإضافة إلى أننا نواجه فرنك دائمًا في بيئة رسمية وغير رسمية.
سنقوم بصياغة القضية على أساس الخبرة التراكمية - تم اختبار كل شيء نكتبه تقريبًا على أنفسنا. نحن لا نقنع أي شخص بأي شيء ، مصلحة أكاديمية بحتة. على الرغم من وجود امتيازات كبيرة أخذت هذه القضية في الخدمة ، وهي نفسها تقدم شيئًا ما هناك.
إذا كنت لا تعرف ماهية 1C: الامتياز ، فاقرأ ما إذا كنا نتحدث عن شركة معينة تقدم خدمات لتطوير البرامج وصيانتها.الهدف من هذه القضية بسيط - زيادة إنتاج المبرمجين ، والإيرادات إن أمكن. أو العادم ، لديه خيارات مختلفة. دعنا نذهب. أنا أحذرك - لونغريد.
الوضع الأولي
لا تأخذ كامل الامتياز ، ولكن جزء منه ، والذي سنطلق عليه قسم التطوير. هؤلاء هم الرجال ، مبرمجو 1C الذين يجلسون في المكتب ، ويستلمون المهام من خلال النظام أو من الاستشاريين ، ويقررون ما إذا كانوا ينقلون النتيجة إلى الاستشاريين أو العميل ، عن بُعد.
هناك العديد من هذه الإدارات في الامتيازات الكبيرة للشبكات ، وهناك تنافس بينهما ، وعندما لا يكون لديهم موارد كافية ، يقومون بتبادل المتخصصين والمهام بنشاط. ربما لا يكون ذلك بمحض إرادته ، لكن هذه ليست النقطة - فنحن ننظر إلى قسم التطوير كوحدة أعمال ، وليس كمجموعة من "المبرمجين الحقيقيين".
دعنا نقول قسم التطوير لدينا يتكون من خمسة أشخاص. إجمالي الناتج الشهري المتوسط هو 500 ساعة. من بين هؤلاء ، يتم إغلاق 200 من قبل بطل معين - المبرمج الأكثر خبرة وذكية. 100 ساعة تغلق الثانية ، 80 - الثالثة والرابعة ، 40 - المبتدئين.
دعنا نقول ساعة عمل لعميل يكلف 2000 روبل. دعنا نقول أن لدينا معدل واحد داخلي للمبرمجين - 500 روبل في الساعة. تشير تقديرات بسيطة إلى أن إيرادات الإدارة تبلغ مليون روبل في الشهر ، كما أن كشوف الرواتب في الإدارة لا تتجاوز 25٪ من الإيرادات ، وفي هذه الحالة 250 ألف روبل. توتال ، تحصل الشركة على 750 ألف روبل ، منها تدفع ضرائب على نفس المبرمجين ، حسناً ، وجميع مصاريفها الأخرى. لن نفكر في هيكل الربح ، نحن فقط نفهم أنه غير خطي ، لأنه يحتوي على تكاليف ثابتة ، مثل استئجار مكتب وشراء ملفات تعريف الارتباط.
التنمية ، على سبيل المثال ، مستقرة نسبيا ، لا تقفز كثيرا. ما لم يحدث ذلك ، عندما يذهب البطل في إجازة ، لدينا فشل بنسبة 40٪ ، وأحيانًا يحدث ذلك و 700 ساعة - عندما يحدث مشروع جيد ، ويعمل المبرمجون في عطلات نهاية الأسبوع.
الهدف القضية
سأخبرك فورًا بالغرض من استخدام الحالة حتى لا تصنع لغزًا. نريد أن لا يقدم قسم التطوير لدينا 500 ، ولكن 1000 ساعة شهريًا ، أي ضعف ذلك. لنفس المعدل بالساعة ، مع نفس التكاليف الثابتة ، مع نفس عدد ساعات العمل. يمكننا السماح بنفقات زمنية صغيرة لهذا المشروع - على سبيل المثال ، في غضون 30-50 طن.
من المهم أن نقرر على الفور ما سنفعله في الموقف المستهدف. من ناحية ، نبيع وقت المتخصصين - الساعات التي يقضونها في حل المشكلات. من ناحية أخرى ، نبيع المهام التي تم حلها ونقيمها في ساعات. يبدو أن كل شيء واضح ، لكن الفرق بين نظامي التصنيف مهم للغاية.
دعنا نقول أن 500 ساعة في الشهر هي 500 ساعة عمل حقيقية للمتخصصين. خلال 500 ساعة ، يحلون ، على سبيل المثال ، 200 مشكلة ، بمتوسط سعر يبلغ 2.5 ساعة. اتضح أن كل مهمة تكلف ما متوسطه 5000 روبل. العميل مستعد تمامًا لدفع مثل هذه الأموال ، فهو يعرف السوق ، وبقية الامتيازات لها نفس السعر.
وهكذا تعلمنا حل المشكلة ليس في 2.5 ساعة ، ولكن في 1.25 ساعة.
والسؤال الرئيسي هو كم يمكن بيعها لعميل؟إذا قمنا ببيع الوقت ، فمن المنطقي البيع لمدة 1.25 ساعة. سيكون العميل سعيدًا - أرخص وأسرع. ولكن بالنسبة لنا ، كعمل تجاري ، لا يوجد أي فائدة تقريبًا من مثل هذا المخطط - فقط عميل راضٍ ووقت فراغ للمتخصصين الذين يحتاجون إلى أخذ شيء ما. لنفترض أننا وجدنا المزيد من العملاء ، ونبيع لهم أيضًا مهمة لمدة 1.25 ساعة. نتيجة لذلك ، في شهر ، ما الذي سنحصل عليه؟ نفس 500 ساعة لعام 2000 روبل. ليس هناك معنى.
خيار واحد هو رفع معدل الساعة. لكننا نحل المشاكل بشكل أسرع من المنافسين؟ في الوظائف الصغيرة ، لن يلاحظ أحد هذا بشكل خاص ، لكن في المهام التي تستغرق 40 ساعة سيكون الفرق ملحوظًا بالفعل.
لكن سعر الساعة هو تغيير ملحوظ للعالم الخارجي يمكن أن يثبط عملاء جدد عنا. إنهم لا يعرفون ماذا نفعل مرتين بسرعة؟ الشعارات المكتوبة على الموقع ليست مقنعة بشكل خاص.
يبدو من الأصح متابعة بيع المهمة لمدة 2.5 ساعة. لا يلاحظ العميل أي شيء ، ونحصل على نتيجة طبيعية مستهدفة - القيام بمهام مضاعفة ، وحصلنا على ضعف ما لدينا من أموال.
يمكنك اختيار خيار تسوية - للبيع ، على سبيل المثال ، خلال ساعتين. ثم يرى العميل وفورات ملموسة (خاصة على الكميات الكبيرة) ، يحصل على النتيجة بشكل أسرع ، ونحن في اللون الأسود. علاوة على ذلك ، حتى مع الحفاظ على المعدل الداخلي للمبرمجين.
للبساطة ، سننظر في الخيار عندما نستمر في البيع لمدة 2.5 ساعة. نقوم بتقييم المهمة القادمة باستخدام خوارزمية أكثر تعقيدًا قليلاً - نحتاج إلى تقدير الوقت الفعلي ، وضربها في 2. لكن المزيد في هذا الشأن لاحقًا.
نعم ، لا تزال هناك خيارات غريبة لاستخدام الوقت المحرر ، على سبيل المثال ، تعزيز التنمية الداخلية. هذا سيكون في النهاية.
حسنًا ، هذا كل شيء ، الهدف واضح ، والآن دعنا ننتقل إلى تحليل التغييرات الضرورية.
القضية الرئيسية
يقولون أن هناك دائمًا نقطة تطبيق للقوة تحتاج فيها إلى إدخال رافعة والحصول على أقصى قدر من التأثير. أنا لا أتفق مع هذا - بمعنى أن هذه النقطة موجودة دائمًا. ولكن في هذه الحالة - هو نظام التحفيز.
نظام التحفيز لدينا هو معدل فردي للساعة للعمل المنجز.
هناك العديد من المزايا للمبرمجين فيها ، قليلة للأعمال ، ولكن هناك الكثير من السلبيات.
المتخصص ليس لديه أي سبب على الإطلاق لتبادل معرفته وخبرته. الشيء الوحيد الذي يستحق القيام به هو رفع ملف التعريف الخاص بك. إذا كان كل شيء يتسم بالأهمية ، عندئذٍ يكون من غير المناسب تبادل الخبرات ، بل وأكثر من ذلك للمساعدة في حل المشكلات. إذا علمت أحمق ، فسوف يصبح منافسًا لك ، ولن يشكرك.
إذا كنت تعرف جيدًا ، على سبيل المثال ، راتب (هذا مثل هذا البرنامج) ، بينما لا يعرف الآخرون ، سيكون لديك دائمًا الخبز والزبدة. بمجرد ظهور الراتب الثاني ، سيكون عليك بذل الجهود للحصول على أكبر قدر من العمل.
ما هذا للعمل؟ إذا لم يشارك الاختصاصيون الكفاءات ، فإن رعاية التدريب تقع على عاتق الشركة. من الضروري تنظيم الدورات التدريبية أو الدفع لمنظمات الجهات الخارجية (مثل 1C). والثاني هو الاختناقات في شكل المتخصصين الرئيسيين. إذا كان من بين كل 5 أشخاص فقط يعرف ERP (هذا أيضًا برنامج كهذا) ، فأنت لا تستطيع فعليًا شغل وظائف ERP أكثر مما يستطيع هذا الموظف استيعابه. حتى لو كان بطلًا ، فلن يكون هناك أكثر من 200 ساعة شهريًا. حسنًا ، إما تحمل المخاطر - خذ العمل لتعرفه لاحقًا ، على طول الطريق.
ليس من الممكن للغاية جعل اختصاصات المشاركة. الرؤية يمكن القيام به. لكن ، من كان مبرمجًا ، يعرف أن هناك طرقًا لتقديم المساعدة بحيث لن يتم الاتصال بك من أجل ذلك. يمكنك حتى جعل البطل يعقد ندوة أو إجراء تدريب. وسيقوم بإبلاغ المواد بأمانة - مادة يمكن الوصول إليها على الإنترنت. سيترك المعرفة الحقيقية والعملية لنفسه.
يشبه السعر الفردي للساعة نشاطًا تجاريًا داخل شركة ما ، وهذا "العمل الداخلي" دائمًا هو عنوان IP وليس شركة ذات مسؤولية محدودة.
والكفاءات مهمة ، خاصة في عصر التغيير الذي يحدث بشكل دوري. بالطبع ، هناك هدوء في بضع سنوات - على سبيل المثال ، قبل إصدار ERP ، عندما يكون الجميع قد استوعبوا بالفعل المبتدئ الناعم (هذا أيضًا برنامج قديم ولكنه مفعم بالحيوية). لكن في الفترة 2004-2010 ، على سبيل المثال ، كان "مهندسو المشاريع" الذين يمتلكون المعرفة حول SCP أفضل ما في الأمر. الآن ، على الأرجح ، يعيش خبراء ERP أفضل من أي شخص آخر - لا أعرف بالتأكيد.
يقتل العمل الفردي القدرة على مشاركة حلول العمل وأفضل الممارسات ، لأنه ، مرة أخرى ، هذا لا معنى له. حسنًا ، لقد أعطيت الشخص المعالجة أو النظام الفرعي الخاص بك ، فأغلق 40 ساعة متفق عليها مع العميل في يوم واحد ، وأثار 20 طن. ما الأمر مع ذلك؟ يمكنك بالطبع التوصل إلى اتفاق وإنشاء سوق سوداء داخل القسم ، لكن هذا لا معنى له. من السهل القول: "أعطني المهمة ، سأحلها". في حالة ميؤوس منها ، بالطبع ، سوف يعطيه ، لكنه سيترك الأمر لنفسه بدافع المبدأ.
يمكنك النظر إلى الكفاءات بشكل مختلف: من هو مالكها؟ دعنا نقول بطلك كان مع الشركة منذ عام 2010. قام بالكثير من العمل على تخطيط موارد المؤسسات ، واكتسب الكفاءات. من ينتمون؟
ستقول الشركة - إنهم ينتمون إلينا. عملائنا ، مشاريعنا ، مهامنا. إعطاء الكفاءة. كيفية التقاطها؟ لا تسحب القراد؟ هذا ليس رصيدا ماديا. انه يخاف ، وبكى الكفاءات.
وما هي الكفاءات؟ المنتج أم لا ، دخل من بيع المنتج. شحنها 200 ساعة من قبل ERP ، تلقى ربحين - 400 طن والكفاءات. المال - بالطبع ، هنا ، على الحساب الجاري. يمكنك نقل ، الإنفاق ، الاستثمار. أين هي الكفاءات؟ في هذا الرأس أصلع. ما الذي يمكن عمله معهم؟ في الواقع - لا شيء.
اتضح الرجل تعلم على حسابنا. ليس أننا استثمرنا المال في تدريبه - لا ، لقد حدث ما حدث للتو. ولكن يمكننا الحصول على هذا الربح في طريقة واحدة فقط - للاستمرار في استغلال هذه الكفاءات ، أي على كل عمل تخطيط موارد المؤسسات وضعه وحده. حسنًا ، أو انتهز الفرصة ووضع المبتدئين للحصول على مورد آخر غير قابل للاسترداد.
سبب هذه الحالة هو مبتذلة - نظام التحفيز الخاطئ. ليس الأمر لا يشجع - فهو يحظر مباشرة أي شخص من تقاسم الكفاءات.
نظام التحفيز - ما هو؟ حتى يقوم الشخص نفسه ، بإرادته الحرة ، وبكل حماسة ، بعمل ما هو مفيد للشركة. يجب أن يحل نظام التحفيز محل القائد الذي يمشي ويركل ويحاول أن يشير إلى شيء ما كل يوم.
كيف تتأكد من أن الشخص ، بإرادته الحرة ، يفعل ما هو مفيد للشركة؟ حسنًا ، أولاً ، بالطبع ، لفهم ما هو مفيد للشركة. ثانياً ، التأكد من أن منفعة الشركة تعود بالنفع على الشخص. ليس في شكل بعثات وشعارات ، ولكن حقيقي.
القضية
بالنسبة للحالة ، اخترت الأساليب التي ، في رأيي وتجربتي ، هي الأنسب لتحقيق الهدف - مضاعفة الناتج. بشكل عام ، هناك طرق أخرى كثيرة ، لكننا هنا لا ننخرط في الكتابة ، ولكن في الفعل. أيضا ، تجدر الإشارة إلى أنه لمضاعفة الناتج ، ليس من الضروري تنفيذ جميع الأساليب - غالبًا ما يكفي طريقة واحدة فقط.
الفرق في الشروط الأولية لشركة معينة ، والتي لا أعرف شيئًا عنها. ربما يكون هناك امتياز في العالم أكثر شجاعة ، والذي لديه أقل إنتاج لكل موظف. أنت لست من هذا الامتياز ، لذا فإن قياسك أعلى. ولكن كم أعلى - ليس لدي فكرة. ولكن حقيقة أنه يمكنك مضاعفة الناتج حقيقة.
فما عليك القيام به
مع :
- تحديد وأتمتة وإضافة الأرصدة الأولية لنظام التصنيف ؛
- أتمتة وإضافة الأرصدة الأولية لنظام الكفاءات ؛
- اتخاذ قرار بشأن نظام التحفيز ، أتمتة.
- اختيار معايير استراتيجية الكفاءة ؛
- تعيين ضابط واجب ؛
- التحدث مع المبرمجين.
للقيام:
- مناقشة عامة للمهام القادمة ؛
- اختيار منفذ بالتنفيذ وفقًا للاستراتيجية ؛
- إدارة المساعدة المتبادلة والمحاسبة ؛
- إدارة حالات المهمة.
الآن سوف أوجز بإيجاز كل عنصر. ولكن أولا ، شرح الأتمتة.
الأتمتة
النقطة الموجودة في جميع أشكال الحالة تقريبًا هي الأتمتة. جميع التغييرات التي ستجريها على العمليات والإدارة والتحفيز ، تحتاج إلى أتمتة بسرعة.
كلمة "أتمتة سريعة" سريعة جدًا ، أي خلال اليوم (بما في ذلك انتظار الفرصة لتحديث تكوين قاعدة البيانات). من هنا تنشأ الحاجة فورًا إلى تنفيذ هذه الأتمتة من قِبل قوى الفريق نفسه ، الذي تتطور به. إذا كنت صاحب امتياز كبير ، ولديك قسم آخر لا يخضع لأتمتة الداخلية الخاصة بك ، فأنت لست محظوظًا للغاية ، ولكن هناك حل - أتمتة سرية.
لكل شيء موجود في هذه الحالة ، يكون التكوين الموصوف ذاتيًا المصنوع على الركبة كافيًا. ثم ، في يوم من الأيام ، ستقوم بتحسينه وإنشائه في نظام شركتك ، وإنشاء واجهة مريحة ، إلخ. الآن نحن بحاجة إلى بيانات شبه عارية ، دون ملاءمة وراحة. لذلك ، إذا لم يكن لديك حق الوصول لوضع اللمسات الأخيرة على النظام الموحد ، اصنع بنفسك وشاركه مع الفريق.
إذا لم يكن نظام إدارة المهام الخاص بك موجودًا في 1C ، فلسوء الحظ ، أنت لست محظوظًا - من المحتمل أن تضطر إلى التخلص منه. أو استخدمه كبديل لـ 1Snoy ، إذا كان العملاء عالقين فيه - دعهم يقودون المهام هناك ، لكن الآن ، اجعل نفسك نظامًا بنفسك ، في 1C ، وقم بتحميل البيانات إليه. خلاف ذلك ، لن ينجح شيء - مطورو bitrix24 و JIRA و Github والأنظمة الأخرى ، أعتذر ، لقد أرادوا القرف على احتياجاتك. إذا أضف. لا يزال بإمكانك إضافة خاصية إلى المهمة ، ومن ثم من غير المحتمل أن يكون الجزء المجدول ، وكذلك الأمر هو التقرير.
لأتمتة عمل الفرق الداخلية التي تجلس بجوار بعضها البعض ، أفضل منصة ، للأسف ، 1C.
نظام الدرجات
نحتاج إلى نظام تصنيف جديد - المهمة التي نقوم بها الآن في 2.5 ساعة ، يجب علينا القيام بها في 1.25 ساعة ، والبيع في 2.5 ساعة. اتضح أن المهمة في الحالة المستهدفة لدينا سيكون لها تصنيفان - 2.5 و 1.25 ساعة. واحد هو استثمار حقيقي للوقت ، والآخر هو تقييم معين للعميل. الآن ، في الوضع الحالي ، نعتقد أن هذه التقديرات متساوية (في المتوسط).
أنا شخصياً لا أحب الاحتفاظ بتصنيفين في وحدة واحدة (ساعات). لا أستطيع التوقف عن التساؤل كيف يمكن لأي شخص أن يعجبها على الإطلاق. في الواقع ، هناك المزيد من التصنيفات: الساعة للعميل ، الساعة التي يطلق عليها المبرمج أثناء التخطيط ، الساعة حقيقية. كيف ثم جمع كل ذلك معا ، وتحليله بطريقة أو بأخرى - الشيطان يعرفه.
أوصي النظام من Scrum - لعبة البوكر التخطيط. يتم تقييم كل مهمة بنقاط مأخوذة من سلسلة فيبوناتشي - 1 ، 2 ، 3 ، 5 ، 8 ، 13 ، 21 ، 34 ، إلخ. يعكس التقييم رؤيتك الشاملة لهذه المهمة - مدى تعقيد التنفيذ ، وتكاليف العمالة ، وعدم اليقين ، والطبيعة الإشكالية للعميل في تقديم العمل.
أسهل طريقة للبدء بـ "المرساة" هي تحديد وجود مهمة ذات نقطة واحدة. هذه هي أبسط المهمة الذرية التي تحلها. تبعا لذلك ، فإن مهمة 2 نقطة هو ضعف صعوبة.
يتم إجراء التقديرات عند معالجة الدفق الوارد ، أي عندما تظهر مهمة جديدة. يضع كل عضو في الفريق بصماته ، في النهاية لدينا - 5 علامات (على سبيل المثال الذي وصفه لنا). إذا كانت هناك تقديرات تتباعد بأكثر من عنصر واحد من المسلسل ، فعندئذ نحتاج إلى التحدث وفهم سبب وجود هذا الاختلاف الكبير ، وللقضاء عليه ، إما أن المبالغة في تقدير أحدهما أو يتم التقليل من تقدير الآخر. عندما يتم حل جميع الاختلافات ، يعتبر المتوسط (مجموع التصنيفات مقسومًا على عدد التصنيفات) - سيكون تقييم المشكلة.
إذا قمت بتطبيق النظام "من أعلى" ، فمن الممكن تمامًا عدم ترتيب التصويت ، ولكن وضع التصنيفات بنفسك. ليس لدينا سكروم ، نكتب القواعد بأنفسنا.
إذا كان من الواضح في عملية حل المشكلة أن التقدير قد تم التقليل من تقديره أو بالغ في تقديره ، فيمكنك تغييره بأمان. بطبيعة الحال ، بحلول الوقت الذي يتم فيه إغلاق المهمة ، يجب أن تكون الدرجة النهائية معروفة.
يجب إدخال التقييم في النظام وتخزينه في شكل مهمة الدعائم.
إذا لم تعجبك النقاط ، فيمكنك استخدام ساعات قياسية. لا أوصي بهذا الخيار ، ولكن يمكن تجاهل رأيي. على سبيل المثال ، في فجر الممارسة ، توصلت إلى تقدير مثل "للأفضل" - كم عدد الساعات التي يقضيها أفضل مبرمج لمعرفة مشكلة أو سياق أو عميل أو وظيفة ، وما إلى ذلك ... كل شيء ضروري لمثل هذا "الأفضل" - اكتب الرمز.
من المهم للغاية الآن إدخال الأرصدة الأولية - لتقييم المهام لمدة 1-2 أشهر التي قمت بحلها بالفعل ، ولتقديم تقديرات في النظام. أولاً ، قم بتدريب وتطوير نظام الدرجات الخاص بك. ثانيا ، والأهم من ذلك - الحصول على السرعة الحالية و "سعر النقطة".
على سبيل المثال ، اتضح أنك تبيع 500 ساعة في الشهر مقابل 2000 روبل ، وهذا هو 500 نقطة. ثم درجاتك في الوقت الحالي هو 2000 روبل. بعد إدخال التغييرات ، يجب أن تحصل على 1000 نقطة ، وتبيعها مقابل 2000 روبل وتتلقى ضعف دخلها (كل من الشركة والموظفين).
بقايا الطعام الأولية مهمة للغاية ، لأنه بدونها لن تجيب على السؤال الأساسي - هل نجحت أم لا؟ لا تكن كسول ، من فضلك.
سيكون من المغري عدم تقييم المهام القديمة ، ولكن البدء بمهام جديدة. , , , . – .
«», – .
, . , , ( ).
– . . , . , , .
– . – « » « », , .
– . – . , , , . – , . , , , , .. , .
, – . , . – , . , 10 . , , 100 %.
. . . . , , , .
« », . , - . – , , , , .
– , . , – .
– . , , , , , ( ). , – .
, – . «», «», .
. – . , , ( ). , , .. .
, , , , .
– «» , , . , , , , . , ( , – ).
, , , , « -». , , 10 , 2.
-. «», . «» – , , , . ? – . , 40 % — «». , 15 , , 2 , 500 . 2 . 60% = 600 , .. 266 (600 2.25 ). , 100 ( 10 , 1000 ).
«» 1600 ( 15 , 400 ). , . , .. , 500 , – 1600 . , – . , . , . , , -, .
, . , – . , 2 , 5 - . , , , .
, – , . , .
: – , «» . – , . , – , . .
, , . – , , , .
, . , .
, – - . , , , . , , , .
, . : . – , , , , .
: 70 % – , 30 % – . , . , . , , .
, – , , , ? , . -, . -, . , , . « » – « — ».
, , – , , . , – . . -, , . , , .
– , , . , – , .
«», , , . – , , , . – , , - . .
– , . , – – .
, , . , - «, , , . , . , , . , . „ “? ? , , , , 9-00 . , . – , ».
– , ( ). .
. , . , , , , . , , , . , , , , , .
- , . 5 15 . , – .
– , , . - , .
. , . , , « ».
, , . 1 – , . , , . , , – , , , – - «», , . 1 , - .
, , - , , . : .
– . , , . , – , , . .
, – , . , , . , « », - .
, , , - . , , , , .
. , , – , – . , , .
يتساءل الكثير من الناس - كيف يمكن أن يتضاعف الناتج؟ بسبب ماذا؟ هل نحن قادرون على كتابة الكود بشكل أسرع؟ أو تقليل جودته؟ صفعة والإنتاج؟ كثيرون ، بالطبع ، لا يُطلب منهم ذلك ، لكنهم ببساطة ينكرون ويرفضون. بعد كل شيء ، من المستحيل وجود طريقة مثبتة للتسارع المزدوج ، لكن لا أحد يعرف ذلك؟
المشكلة ، في الواقع ، شائعة - الاتجاه الخاطئ للانتباه. أو ، ببساطة أكثر ، أنت لا تبحث هناك. نقوم بتضييق الموضوع على المبرمجين ، على الرغم من أن المبدأ عالمي.
في رأيك ، ما هي السرعة المثالية لحل مشكلة العميل بواسطة مبرمج 1C؟ إنها مهمة تطوير أو وضع اللمسات الأخيرة. فكر أثناء القراءة ، ستكون الإجابة أقل قليلاً.
دعونا نلقي نظرة على عمل مبرمج 1C. ما رأيك ، كم في المئة من الوقت في الواقع البرنامج (بما في ذلك جميع الجوانب - كتابة التعليمات البرمجية ، وإنشاء البيانات الوصفية ، وتخطيطات ، وما إلى ذلك)؟ 100 ٪؟ 50 ٪؟ 20 ٪؟
الممارسة تبين أنه يحدث و 3 ٪. إذا كنت لا تصدق ذلك ، تحقق من ذلك بنفسك - فهناك برامج متخصصة لمثل هذه القياسات. ولكن هناك طريقة أكثر بساطة - انظر إلى مقدار الكود الذي كتبه المبرمج في يوم واحد ، وقم بتقسيمه على سرعة الطباعة. الرقم الناتج قد يفاجئك.
سيكون عقل المبرمج ساخطًا - حسنًا ، لكن ماذا عن مقدار الشفرة وسرعة الطباعة؟ هناك مهام حيث تحتاج إلى كتابة غبية والكثير. وهناك من تحتاج إلى قراءة الكثير والتفكير والتحليل والمحاولة ، التصحيح لفترة طويلة.
حسنا ، دعنا نذهب على الجانب الآخر. كل يوم الفكر مبرمج ، تحليلها ، حاول. ونتيجة لذلك ، كتب 50 سطرًا من التعليمات البرمجية ، وتم حل المشكلة. جيد ، رمز الصحيح ، يتم فحص كل شيء ويعمل. قضى 8 ساعات.
والسؤال الآن هو: في أي وقت سوف يحل نفس المشكلة بالضبط من عميل آخر؟ إذا أخذ حلًا جاهزًا ، فحينئذٍ حوالي 5 دقائق ، أليس كذلك؟ حسنًا ، بينما يفتح المكون هناك ، بينما الثاني ، أثناء النسخ ، إلخ. وإذا كنت إعادة الكتابة ، مع الأقلام؟ نصف ساعة؟ في الطريق ، سيقوم أيضًا بإجراء مراجعة على الجهاز ، وسيتم تحسين الرمز. 16 مرة أسرع.
حسنا ، إلى الجحيم معها ، مع نسخ الرمز. مثال آخر أنت ، بدلا من إعطاء مهمة واحدة للمبرمج ، أعطيت 10-20 - قلت: هنا هو تعقب ، اختر أي منها وقم به. ماذا سيحدث بعد ذلك؟
سوف تختار مبرمج. في رمز البرنامج ، يعمل مشغل التحديد لجزء بسيط من المللي ثانية (إن لم يكن حالة صعبة للغاية) ، لكن الشخص ليس آلة. بالنسبة له ، فإن الاختيار هو عملية تسير ببطء في بعض الأحيان.
تذكرنا هذه العملية أحيانًا بالاستطلاع في المعركة: لا يقرأ المبرمج فقط عنوان المهمة والوصف التفصيلي ، بل يعلق أيضًا ، ثم يزحف إلى المُكوِّن لفهم السياق. انظروا ، تعثروا - فو ، هذه مهمة تتعلق بالزي الرسمي ، فهناك الشيطان سينكسر ساقه ، في هذا المبتدئ الناعم. لا ، دع كوليان يفعل. 15 دقيقة ضائعة. اضرب في 10-20 ، إلى أي مدى سيتحول؟ تصل إلى 5 ساعات؟
هذا جيد إذا كان المبرمج ذكيًا ولديه سياق كافٍ لاتخاذ قرار. لكنه ، على سبيل المثال ، معجب كبير بالإنترنت ، وذهب للبحث عن حل جاهز - في نفس Infostart ، أو مؤتمر تابع ، أو في مكان آخر. يبدأ وقت الاختيار في النمو بمعدل ينذر بالخطر.
نصف يوم سيختار ، نصف يوم سيعمل. الخسائر - 50 ٪ ، أي يكفي لشخص أن يصدر مهمة بشكل صحيح من أجل مضاعفة الناتج.
حسنًا ، ليس لدينا مشكلة مثل الاختيار. يختار المدير ، أو كبير المبرمجين ، ويقول - هنا ، قم بذلك. لا ، لا أريد ، لا أستطيع ، دع كوليان يعمل بشكل أفضل ، يجيب المبرمج. افعلها ، قلت! - يصر الرئيس.
علاوة على ذلك ، وفقا لفهم الشيء الرئيسي ، جلس المبرمج وفعل. دعونا لا فعالة للغاية ، لكنه يفعل. ماذا يفعل؟ في بعض الأحيان - نعم ، يحل المشكلة. في بعض الأحيان يجلس ويأخذ جريمة. أو تبحث عن أسباب عدم القيام بالمهمة. على سبيل المثال ، تقوم بإعداد قائمة بالمشكلات ، "والتي بدونها لن يكون من المنطقي البدء". أو الإنترنت غبي ، لأن العالم ليس عادلاً.
سأنهي الأمثلة ، على الرغم من وجود العشرات منها بالفعل. اتضح أن للمبرمج حالتان - يكتب الكود أو tupit. تُستخدم كلمة "tupit" بدون دلالة سلبية ؛ فهي ببساطة لم تجد فعلًا أكثر ملاءمة من الاسم "stupor".
لذلك تم وضع المبدأ الرئيسي: انظر إلى أين هو غبي. من غير المنطقي أن تبدأ نمو الكفاءة من خلال عملية كتابة التعليمات البرمجية ، واختيار بيئة تطوير مختلفة (مثل EDT) ، وجميع أنواع الأشياء لتسريع الترميز ، وما إلى ذلك. ضع في اعتبارك أنه عندما يكتب مبرمج التعليمات البرمجية ، يكون فعالاً. هذا صحيح عندما يقرع بأصابعه على لوحة المفاتيح ، أو يرسم بالماوس النموذج ويضيف التفاصيل.
يضيع معظم الوقت عندما يكون المبرمج غبيًا ، وليس حيث يكتب الكود. قلت عدة خيارات.
إذا كنت رئيس المبرمجين ، فتوقف عن النظر في الترميز ، وانظر إلى وقت التوقف عن العمل. إذا كنت مبرمجًا ، انظر إلى نفسك في وقت توقفك. هذا هو المفتاح لزيادة سرعة التنمية.
نعود إلى السؤال - ما هو الوقت المثالي لحل مشكلة العميل بواسطة مبرمج 1C؟ الجواب واضح - صفر. حسنًا ، الصفر مطلقًا غير موجود ، فليكن 5 دقائق. كيف يتم تحقيق هذا الوقت؟ أنت تفهم بالفعل: عن طريق إصدار حل جاهز. جاء العميل ، وفقًا لمهمته ، فأخبرته على الفور - الحل الذي لديك بالفعل. لا أعرف مقدار الأموال التي يجب أن أتناولها ، حسناً ، ليس خلال 5 دقائق من عمل أخصائي ، هذا أمر مؤكد. يمكنك الجدال مع هذا البيان ، ولكن يمكنك التفكير. كم مرة كنت قد حل المشاكل متطابقة؟ ما هي النسبة المئوية للمهام التي تحلها لأول مرة ، ولم يسمع بها شيء من هذا القبيل؟ لديّ ممارسة صغيرة - يبلغ من العمر 13 عامًا فقط ، لكن حتى مع وجود هذا الرقم المتواضع ، أفهم وأرى أنني قد حللت بالفعل نصف المشكلات.
إذا كنت تسلح نفسك بهذا النهج ، فستحتاج إلى كتابة أدوات مخصصة مجردة قليلاً (بدلاً من govnokod السياقية واللحظة) وتخزينها في مكان ما. أول ما ناقشناه ، والثاني لديه الكثير من الحلول.
ثم ذهبت قليلا وراء القضية. أنا لا أحثك على التخلي عن كل شيء والتعامل مع الحلول الجاهزة ، أردت فقط أن أبدي المثالية - التسارع هو ، في الواقع ، ليس التطوير ، ولكن عشرات المبيعات أو مئات المرات. وفقا لذلك ، فإن تسريع توليد دخل الامتياز هو مئات المرات. بينما سنتعامل مع أصغر ، فسوف نتسارع مرتين.
لقد فهمت المبدأ ، فكل شيء سيكون واضحًا وبسيطًا بالنسبة لك. سوف أصف الإجراءات التي يجب تضمينها في عمل القسم ، بهدف واحد - تقليل الوقت الباهت ، واستبداله بالبرمجة.
مناقشة عامة للمهام الواردة
بسيط وحنطي. يجمع المصاحب ، الذي ناقشناه في مقال سابق ، جميع المبرمجين في كومة صغيرة كل صباح ، وهم يبحثون معًا في مهام جديدة.
أول شيء يجب معرفته هو ما إذا كان شخص ما قد حل مشكلة مماثلة. إذا قررت ذلك ، فعيّنه مستشارًا أو أمينًا - لا يهم ما تتصل به. من المهم أن يعرف المقاول من الذي يجب الاتصال به.
إذا لم يقم أحد بذلك ، فسوف نقوم بتبسيط المعايير قليلاً - نحن نبحث عن أولئك الذين عملوا مع هذا النظام الفرعي ، أو هذا المستند ، أو آلية النظام الأساسي هذه. حسنًا ، كما ترى - إذا كانت المهمة تتعلق برسم "المجدول" ، فحينئذٍ يقوم أي شخص يتقن هذه الآلية المذهلة بالفعل. سيكون مستشارا.
إذا كانت المهمة جديدة بشكل عام ولم تكن مألوفة لدى أي شخص ، فأنت بحاجة إلى اختيار ولاعة سجائر - الشخص الذي سيكون أول من يفهم هذا الموضوع. هناك مهمتان رئيسيتان: حل مشكلة وتطوير الكفاءة. في المرة القادمة لتصبح مستشارا في مهام مماثلة. بالطبع ، يدرك الجميع أن التدخين قد يستغرق وقتًا أطول مما يتفق مع العميل - وهذا أمر طبيعي ، فأنت تستثمر في فريقك.
وجود مستشار مهم بشكل خاص للمبتدئين. حتى إذا ، وفقًا لاستراتيجية تطوير الكفاءات الخاصة بك ، فإنك تحظر على المبتدئين أن يسأل أمين المعرض ، فإن مجرد وجوده سيوفر دعماً معنوياً هائلاً للمبتدئين.
حسنًا ، لا تنسَ تقييم المهمة ، بالنقاط - العب تخطيط البوكر.
اختيار منفذ من قبل الكفاءة وفقا للاستراتيجية
كل شيء بسيط هنا. لقد قمت باختيار - ضبط شريط التمرير بين التطوير وزيادة الكفاءات. لذا اختر فنانًا وفقًا لاستراتيجيتك.
على سبيل المثال ، عليك أن تقرر أن المبتدئين يجب أن يحلوا المشاكل غير المألوفة بنسبة 30٪ من الوقت. في النظام ، لديك بالفعل تقرير يعرض النسبة المئوية - عدد الأصدقاء ، وعدد المشكلات غير المألوفة التي حلها. انظر إلى الأرقام وحدد في أي نقطة تصدر مهمة جديدة وغير مألوفة.
سيؤدي وجود استشاري إلى إزالة الإمكانات الزائدة ذات الأهمية من المهمة ، وإعطاء عناصر عملية اللعبة. سيكون من المثير للاهتمام بالنسبة للمبتدئين التعامل مع آليات جديدة ، لأنه سيعرف مدى توفر الدعم ويشعر بها. إذا حددت مسبقًا حدود تطبيق هذا الدعم ، فسيكون ذلك رائعًا بشكل عام: على سبيل المثال ، أعط مبتدئًا للعمل بشكل مستقل لمدة لا تزيد عن يوم واحد ، وبعد ذلك سيقرر الاستشاري ذلك.
درجة وشكل الدعم من استشاري هو اختيارك ، لا يوجد شيء معقد. إذا كان الوافد الجديد جديد تمامًا ، فليس من المنطقي أن يعطيه رابطًا إلى مؤتمر تابع ، وكتاب سميك عن التنمية ، وتشجيع "هيا ، رتب ، يا بني". إنه ببساطة لا يستطيع هضم هذه القطعة الكبيرة ، ويخنقها ، ويمكنك أن تفقد موظفًا. لن يستقيل ، لكنه سيتلقى ضربة كبيرة في أهميته ، قد يصبح مغلقًا وخاملًا.
لا توجد نصيحة محددة بشأن اختيار "حجم قطعة" ، لأن كل شيء فردي تمامًا. مبدأ واحد عالمي: يجب مراقبة هذا الحجم. بالطبع ، إذا كنت ترغب في زيادة الكفاءة ، وليس أهمية خاصة بك. هذه الطريقة للتعبير عن الذات كإعداد مهام غير قابلة للحل تستخدم على نطاق واسع بين المبرمجين 1C لعدم التحدث عنها.
هناك استثناءات - الموظفون الذين يرغبون في معرفة كل شيء بمفردهم. يريدون كثيرًا أنهم يرفضون بشكل قاطع أي مساعدة. هذه هي طريقتهم في زيادة الأهمية - "يمكنني تحديد ذلك بنفسي" ، وكلما كان السياق الذي يتعمق فيه أكبر ، كانت المكافأة أكبر هي الرضا عن النفس. هذه نوعية مفيدة ، ولكنها تتحول أحيانًا إلى هوس - من الأفضل اتباع هذا الأمر ، ووضع حدود (في الوقت المناسب ، على سبيل المثال).
إذا كانت المهمة عاجلة ، أو كان العميل مهمًا لك ، فسيتم إيقاف التجارب ، والذي يفهم أفضل ما يجلس في المهمة. حسنًا ، الكل يعرف ذلك.
إدارة المساعدة المتبادلة والمحاسبة
إذا كان هناك مستشار ، سيكون من الجيد تحفيزه - لإعطاء نسبة مئوية من الدفع بالساعة لحل المشكلة. يعتمد مقدار الاهتمام على درجة المشاركة.
بالطبع ، من الضروري التأكد من أن الاستشاري لن يصبح وقحًا ، ولا يقوم بسحب الغطاء على نفسه عندما يتم تكليف المهمة بالوافد الجديد. لا تنس أن هدفنا لا يستفيد منه الناس بشكل مباشر ، ولكن النجاح طويل الأمد.
حسنا ، يجب عليك اتباع المبتدئين. إذا قررت أنه في هذه المهمة لا يعرف سوى العمل مع "المجدول" ، فلا تدعه يتولى بقية سياق المهمة - أخبره الاستشاري بذلك.
في الواقع ، لا يوجد شيء أكثر لإضافته.
إدارة حالات المهمة
كان هناك
مقال منفصل حول هذا الموضوع ، لن أكرر كل شيء. بالمناسبة ، لم يكن المقال مهتمًا بشكل خاص بـ 1Snikov ، لكن ممثلي السباقات الأخرى من المطورين أعجبوا به - نحن نعمل بنشاط معهم الآن. هذا يعني أنه في عالم البرمجة 1C ، حتى الآن ، ليس كل شيء جيدًا مع طرق زيادة الكفاءة.
عند اختيار ضابط مناوب ، أعطه رابطًا للمقال أعلاه. الشيء الرئيسي الذي يجب عليه فهمه وقبوله وإتمامه هو ضرورة مراقبة حالة المهام.
يجب أن يبدأ كل صباح بإدارة حالة الطقوس. انها بسيطة جدا وسهلة لأتمتة. في النافذة الأولى - المهام الجديدة التي لم تؤخذ إلى العمل بعد. هذه قائمة مناقشة مع الفريق الذي استعرضناه أعلاه. يجب أن تكون نتيجة المناقشة هي إفراغ هذه النافذة.
في النافذة الثانية - المهام المقبولة في العمل ، ولكن ليس وجود منفذ. أفرغت بنفس الطريقة ، بعد مناقشة عامة. بعد المناقشة ، يجب أن تصبح كلتا القائمتين فارغتين. الوقت المسموح للمهمة في أن يكون في الحالة "غير مقبول للعمل" و "لم يتم تعيين منفذ" - لا يزيد عن يوم عمل واحد.
إذا لم تكن المهمة واضحة ، وكان مطلوبًا توضيح العميل - المهمة ، إلى جانب قائمة من الأسئلة ، تنتقل إلى النافذة / الحالة "الإيضاح مطلوب" أو "يتم إرساله للمراجعة" - لا يهم ما يجب تسميته. الحتمية مهمة.
بعد المناقشة (أو قبلها) ، يقوم المراجع بالتحقق من قائمة المرسلين للمراجعة بحيث لا يكون هناك أي تأخير في الحالات. على سبيل المثال ، يتم تخصيص ثلاثة أيام لتوضيح البيان. لقد مرت ثلاثة أيام - يجب أن نكتب إلى العميل حتى لا يتباطأ. على الأرجح ، نسي ببساطة الإجابة.
أثناء مناقشة مع المبرمجين ، نلقي نظرة على نافذة "في العمل". لقد صنفنا: الجميع يفهم من يشارك في هذه المهمة. وفقًا لذلك ، هناك وقت لتكون المهمة في حالة "في العمل" ، مرتبطة بالمقاول ، ويجب مراقبة هذه المرة.
مبتذلة - حتى لا تفوت حدود وقت المعرفة للمبتدئين. إذا تم إعطاؤه يومًا لقرار مستقل ، ومضى ذلك اليوم ، فلن يرفع يده ، وله احتمال كبير ، ولن يقول إنه لا يستطيع التعامل معه. سوف غبي إلى آخر. لا نحتاج إلى ذلك ، لذا فإن التحكم العادي في العمر الافتراضي للحالة سيوفر لنا من الخسائر غير الضرورية ، ومن المبتدئ من الذنب بسبب الغباء لدينا.
النافذة الأخيرة - المهام المكتملة التي تتطلب قبولًا من العميل. هنا المبدأ هو نفسه كما في المرسلة للمراجعة - لقد حددنا موعدًا نهائيًا ، على سبيل المثال ، ثلاثة أيام ، وبعدها نبدأ في تذكير أنفسنا. الهدوء ، واثق ، ولكن المستمر. أكرر ، يمكن للعميل أن ينسى ببساطة ، لديه ما يكفي من أعماله الخاصة.
النهائي
حسنا هذا كل شيء ، الانتهاء من القضية. الرقم الرئيسي الذي تمت مناقشته هو القيمة الجوهرية لوحدة العمل ، أي نقطة. جادلت بأنه يمكن تخفيض هذه التكلفة بمقدار النصف - لإنتاج نفس القدر من العمل في نصف الوقت.
فيما يلي جدولنا الزمني لأحد العملاء (المفتاح في الوقت الحالي):
كما ترون ، قبل تطبيق الحالة (على سبيل المثال ، حتى أبريل) ، كانت قيمة النقطة تتدهور عند نفس المستوى تقريبًا. هذا يعني أننا ، مع إنفاق نفس عدد الساعات ، أنتجنا نفس مقدار النتيجة - بمتوسط نقطة واحدة في 0.9 ساعة.
في الشهر الأول من استخدام الحالة ، انخفضت قيمة النقطة بشكل حاد ، إلى 0.22 ساعة ، أي حوالي أربع مرات. بطبيعة الحال ، يجب أن يؤخذ الشهر الأول في الاعتبار ، لكن لا يمكن الوثوق به تمامًا ، لأنه كان هناك قفزة حادة في إنجاز العمل - العديد من المهام "باهظة الثمن" ، بسبب دورة حياة المهام غير الخاضعة للرقابة ، والتي تم سحبها مثل المطاط ، مغلقة.
الشهر الثاني هو أكثر دلالة وصحيح. أولاً ، لم تعد هناك أية مهام قديمة ستغلق - فكل المهام التي أغلقت في شهر أيار / مايو ولدت في الشهرين السابقين ، أي أثناء تطبيق القضية. ثانيا ، استخدام القضية استقر وأصبحت عادة. النتيجة - 0.33 ساعة لمدة نقطة واحدة ، وهو أفضل بثلاث مرات من قبل القضية.
حسنًا ، بدأ الرقم بالتجول حول المتوسط الموعود - نصف الأصل.
بالطبع ، تم الحصول على نتائج إيجابية ليس فقط لهذا العميل ، ولكن أيضًا لجميع الأعمال بشكل عام. بما في ذلك - على الداخلية ، والتي لدينا الكثير - أكثر من للعملاء الخارجيين.
هنا ، على سبيل المثال ، رسم بياني لإجمالي عدد النقاط المكتسبة:
كما ترون ، قبل الحالة ، قدمنا 400-500 نقطة شهريًا في المتوسط ، ثم ارتفع هذا الرقم إلى 1400 - بزيادة قدرها 3 مرات.
تم قطع كلا الجدولين في أكتوبر ، للأسف - اعتدنا على تنفيذ المهام في جيثب ، ثم انتقلنا إلى Flowcon. الجدول العام ، من مصدرين ، رسم الكسل.
ومن المثير للاهتمام أن نفهم الاعتماد على الأرقام. نحن ، Oknosoft ، نحاول أن نفعل القليل من أجل خدمات العملاء ، أولويتنا هي التنمية. قبل استخدام الحالة ، كانت لدينا مشكلة - استغرق الأمر الكثير من الوقت للعملاء ، وبقي القليل جدًا للتطوير.
سمح لنا استخدام الحالة بالخروج من هذا الفخ - كان لدينا ، على الرغم من أنه لا يزال غير كافٍ ، ولكن لدينا وقتًا أكبر بكثير من أجل التنمية. لم تكن النتيجة طويلة في المستقبل: لقد قمنا بتنفيذ العديد من المنتجات المهمة جدًا بالنسبة لنا.
الأول هو موقع مشروع برمجة أعمالنا (لن أعطيك رابطًا ، وإلا فسوف أتلقى رسالة بريد إلكتروني تحتوي على الموضوع "nmivan ، دعنا نذهب ..."). الكلمة الأساسية هي الموقع ، لأنه قبل أن نجعل فقط تطبيقات الأعمال التي تعمل عبر الإنترنت. تم بناء الموقع على النظام الأساسي metadata.js ، لكن النجاح الرئيسي ليس الموقع نفسه ، ولا المحتوى ، ولكن تحسين النظام الأساسي ومكوناته. يمكنك الآن أيضًا إنشاء مواقع على metadata.js. علاوة على ذلك ، يحتوي الموقع على وظائف CMS و microservices.
المشروع الثاني ، الذي لم يصل إلى الأيدي لفترة طويلة ، كان بلا أوراق ، أي وظيفة إيفاد ورشة العمل ، والعمل من خلال متصفح والتصور بارد (وهذا مهم لإنتاج النوافذ ، على سبيل المثال). إن عمل بلا أوراق من خلال متصفح - على سبيل المثال ، باستخدام ماسح الباركود المتصل بالتلفزيون - سوف يوسع ويبسط بشكل كبير إمكانيات تطبيق الحلول على metadata.js في الإنتاج. خاصة مع مراعاة بساطة العمل مع الأحداث الخارجية في كود metadata.js ، يمكن اكتشافها في أي مكان ، وليس فقط في النموذج النشط ، كما هو الحال في 1C.
تحدث عن المشروع الثالث -
Flowcon.Life . بالنسبة لنا ، من المهم للغاية ، لأنه أعطى مجموعة من المهام المفيدة لتطوير النظام الأساسي. هذا هو المشروع الأول للأشخاص ، وليس للأعمال التجارية.
الرابع بالكاد مثير للاهتمام لك - هذا هو Flowcon ، تكوين لخدمة 1C + المهمة / فريق / إدارة الأعمال.
حسنًا ، أكثر من ذلك - إما أصغر وأكثر مملة ، أو أكبر وأكثر سرية. المجموع ، مثلا ، ست قطع.
هل هو كثير أم قليلا؟ سأوضح لشخصين. الذين يعملون أيضا مع العملاء على تنفيذ المشاريع ، وكتابة المقالات ، وأقسم الكثير مع بعضهم البعض ومع العالم بأسره ، وحتى كسول إلى الجحيم.
كل شيء نسبي. ستة مشاريع في 9 أشهر - الكثير أو قليلا؟ , 6 ( ), – 0.15 0.66 .
, , — , . , , , . , – .
, , . , , .
, , , – . , , , – .
, . , . , , — , ? .
, , . , . , , , , . .
« »
. , , - .
, - – , , . . , – , .
, , . – , – . , – . , .
1 , , , 1 , ? , , - , – .
, , . – . 1.5 – . – . , , «, - , ».
1? لا شيء , – , .
. , – . . , .
?
« , »
– . «» — . , , .
– , – , . , . , . .
, . – , . , , , – «, ?».
? , .. – , , . , , , – : , . , , – .
« , »
– , . . , .
« , -, »
, . , ? ? .
, « », – , .
, . , . ?
, .
« – »
. – , .
« / ///»
– . , , .
« , »
, – . , . , – .
. , . – , .
, – 1, , , . .
« ? ?»
, . – , , . , .
, – 1: , – . – , – .
« , …»
, . , – .
« ?»
. – , – . – .
. - , , .. – , , .. , .
, , . «» — , .
« ?»
, . .
, , – . . – . , , , , – .
, . , . – .. . - , . , .
, . , , . , .
, . , . , , , , .
, , .. , – – . , , , .
«?»
– , , , . – - .
1: , , , «», - . , , . , – , .
, . – , . , , .
(, -, ), 1: , . – , – . «» .
– . – . , «» .