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