فلسفه DevOps، زمانی که توسعه با نگهداری نرم افزار ترکیب شود، هیچ کس را شگفت زده نخواهد کرد. روند جدیدی در حال افزایش است - DevOps 2.0 یا BizDevOps. این سه جزء را در یک کل واحد ترکیب می کند: تجارت، توسعه و پشتیبانی. و همانطور که در DevOps، شیوه‌های مهندسی اساس ارتباط بین توسعه و پشتیبانی را تشکیل می‌دهند، و در توسعه کسب‌وکار، تحلیل‌ها نقش «چسب» را بر عهده می‌گیرند که توسعه را با کسب‌وکار متحد می‌کند.
من می خواهم فوراً اعتراف کنم: ما فقط پس از خواندن کتاب های هوشمند اکنون متوجه شدیم که یک توسعه تجاری واقعی داریم. به لطف ابتکار کارمندان و اشتیاق سرکوب ناپذیر برای بهبود، به نوعی گرد هم آمد. تجزیه و تحلیل در حال حاضر بخشی از فرآیند تولید توسعه است، به طور قابل توجهی حلقه های بازخورد را کاهش می دهد و به طور منظم بینش را ارائه می دهد. من با جزئیات به شما خواهم گفت که چگونه همه چیز برای ما کار می کند.
معایب DevOps کلاسیک
هنگامی که محصولات مشتری جدید تصور می شود، یک کسب و کار یک مدل ایده آل از رفتار مشتری ایجاد می کند و انتظار تبدیل خوبی را دارد که بر اساس آن اهداف و نتایج تجاری خود را می سازد. تیم توسعه به نوبه خود تلاش می کند تا کدهای بسیار خوب و باکیفیت بسازد. از امیدها برای اتوماسیون کامل فرآیندها، سهولت و راحتی نگهداری محصول جدید پشتیبانی کنید.
واقعیت اغلب به گونه‌ای توسعه می‌یابد که مشتریان فرآیند نسبتاً پیچیده‌ای را دریافت می‌کنند، کسب‌وکار با تبدیل کم گیر می‌کند، تیم‌های توسعه‌دهنده تعمیر پس از تعمیر را منتشر می‌کنند و پشتیبانی در جریان درخواست‌های مشتریان غرق می‌شود. آشنا بنظر رسیدن؟
ریشه شر در اینجا در حلقه بازخورد طولانی و ضعیفی است که در فرآیند ایجاد شده است. کسب‌وکارها و توسعه‌دهندگان، هنگام جمع‌آوری نیازمندی‌ها و دریافت بازخورد در طول اسپرینت، با تعداد محدودی از مشتریان ارتباط برقرار می‌کنند که تأثیر زیادی بر سرنوشت محصول دارند. غالباً آنچه برای یک فرد مهم است برای کل مخاطب هدف معمولی نیست.
درک اینکه آیا یک محصول در جهت درست حرکت می کند یا خیر، با گزارش های مالی و نتایج تحقیقات بازار ماه ها پس از عرضه همراه است. و به دلیل محدود بودن حجم نمونه، فرصتی برای آزمون فرضیه ها بر روی تعداد زیادی از مشتریان فراهم نمی کنند. به طور کلی، معلوم می شود که طولانی، نادرست و بی اثر است.
ابزار جایزه
ما راه خوبی برای فرار از این موضوع پیدا کردیم. ابزاری که قبلا فقط به بازاریابان کمک می کرد، اکنون راه خود را در دستان کسب و کارها و توسعه دهندگان پیدا کرده است. ما شروع به استفاده فعالانه از تجزیه و تحلیل وب کردیم تا به فرآیند در زمان واقعی نگاه کنیم، اینجا و اکنون برای درک آنچه در حال رخ دادن است. بر این اساس، خود محصول را برنامه ریزی کنید و آن را برای تعداد زیادی از مشتریان عرضه کنید.
اگر در حال برنامه ریزی نوعی بهبود محصول هستید، بلافاصله می توانید ببینید که با چه معیارهایی مرتبط است و چگونه این معیارها بر فروش و ویژگی هایی که برای کسب و کار مهم هستند تأثیر می گذارد. به این ترتیب می‌توانید فوراً فرضیه‌های با اثر کم را از بین ببرید. یا، برای مثال، یک ویژگی جدید را برای تعداد قابل توجهی از کاربران ارائه کنید و معیارها را به‌موقع نظارت کنید تا بفهمید که آیا همه چیز همانطور که در نظر گرفته شده کار می‌کند یا خیر. منتظر بازخورد در قالب درخواست یا گزارش نباشید، بلکه بلافاصله فرآیند ایجاد محصول را کنترل کرده و به سرعت تنظیم کنید. ما می‌توانیم یک ویژگی جدید ارائه کنیم، داده‌های آماری صحیح را در سه روز جمع‌آوری کنیم، در سه روز دیگر تغییراتی ایجاد کنیم - و در عرض یک هفته یک محصول جدید عالی آماده است.
می‌توانید کل قیف، همه مشتریانی که با محصول جدید در تماس هستند را ردیابی کنید، نقاطی را که قیف به شدت محدود شده است را شناسایی کنید و دلایل آن را درک کنید. هم توسعه‌دهندگان و هم کسب‌وکارها اکنون این موضوع را به‌عنوان بخشی از کار روزانه خود نظارت می‌کنند. آنها همان سفر مشتری را می بینند و با هم می توانند ایده ها و فرضیه هایی برای بهبود ایجاد کنند.
این ادغام تجارت و توسعه همراه با تجزیه و تحلیل، ایجاد محصولات را به طور مداوم، بهینه سازی مداوم، جستجو و دیدن تنگناها و کل فرآیند را ممکن می سازد.
همه چیز در مورد پیچیدگی است
وقتی یک محصول جدید ایجاد می کنیم، از ابتدا شروع نمی کنیم، بلکه آن را در یک وب از خدمات موجود ادغام می کنیم. هنگام آزمایش یک محصول جدید، مشتری اغلب با چندین بخش تماس می گیرد. او می تواند با کارمندان مرکز تماس، با مدیران در دفتر، می تواند با پشتیبانی یا در چت های آنلاین ارتباط برقرار کند. با استفاده از معیارها، می‌توانیم ببینیم، برای مثال، بار روی مرکز تماس چقدر است، بهترین روش برای پردازش درخواست‌های دریافتی. ما می توانیم بفهمیم که چند نفر به دفتر مراجعه می کنند و نحوه مشاوره بیشتر به مشتری را پیشنهاد می کنیم.
در مورد سیستم های اطلاعاتی دقیقاً همینطور است. بانک ما بیش از 20 سال است که وجود دارد و در این مدت یک لایه بزرگ از سیستم های ناهمگن ایجاد شده و هنوز هم کار می کند. تعامل بین سیستم های پشتیبان گاهی اوقات می تواند غیرقابل پیش بینی باشد. به عنوان مثال، در برخی از سیستم های قدیمی محدودیت هایی برای تعداد کاراکترها برای یک فیلد خاص وجود دارد و گاهی اوقات این کار سرویس جدید را خراب می کند. ردیابی یک باگ با استفاده از روش‌های استاندارد بسیار دشوار است، اما استفاده از تجزیه و تحلیل وب آسان است.
ما به نقطه ای رسیدیم که شروع به جمع آوری و تجزیه و تحلیل متن های خطا کردیم که از تمام سیستم های درگیر به مشتری نشان داده می شود. معلوم شد که بسیاری از آنها منسوخ شده اند و ما حتی نمی توانستیم تصور کنیم که آنها به نوعی در روند ما نقش داشته باشند.
کار با تجزیه و تحلیل
تحلیلگران وب ما و تیم های توسعه SCRUM در یک اتاق قرار دارند. آنها دائماً با یکدیگر تعامل دارند. در صورت لزوم، متخصصان به تنظیم معیارها یا دانلود داده ها کمک می کنند، اما اکثراً خود اعضای تیم با سرویس تجزیه و تحلیل کار می کنند، هیچ چیز پیچیده ای وجود ندارد.
برای مثال، اگر به برخی وابستگی ها یا فیلترهای اضافی برای نوع محدودی از مشتریان یا منابع نیاز دارید، به کمک نیاز است. اما در معماری کنونی به ندرت با این مورد مواجه می شویم.
جالب اینجاست که پیاده سازی تجزیه و تحلیل نیازی به نصب یک سیستم فناوری اطلاعات جدید نداشت. ما از همان نرم افزاری استفاده می کنیم که بازاریابان قبلاً با آن کار کرده اند. تنها لازم بود در مورد استفاده از آن توافق شود و آن را در تجارت و توسعه پیاده سازی کرد. البته، ما فقط نمی‌توانستیم آنچه را که بازاریابی داشت، بپذیریم، باید همه چیز را دوباره پیکربندی می‌کردیم و به بازاریابی به محیط جدید دسترسی می‌دادیم تا آنها در یک زمینه اطلاعاتی با ما باشند.
در آینده قصد داریم نسخه بهبودیافته نرم افزار تجزیه و تحلیل وب را خریداری کنیم که به ما امکان می دهد با افزایش حجم جلسات پردازش شده کنار بیاییم.
ما همچنین به طور فعال در حال یکپارچه سازی تجزیه و تحلیل وب و پایگاه های داده داخلی از CRM و سیستم های حسابداری هستیم. با ترکیب داده ها، تصویر کاملی از مشتری در تمام جنبه های لازم به دست می آوریم: بر اساس منبع، نوع مشتری، محصول. خدمات BI که به تجسم داده ها کمک می کنند به زودی در دسترس همه بخش ها قرار می گیرند.
به چه نتیجه ای رسیدیم؟ در واقع ما تجزیه و تحلیل و تصمیم گیری در مورد آن را بخشی از فرآیند تولید قرار دادیم که تاثیر مشهودی داشت.
تجزیه و تحلیل: پا روی چنگک نزنید
و در نهایت، من می خواهم نکاتی را به اشتراک بگذارم که به شما کمک می کند در روند ایجاد یک تجارت توسعه کسب و کار دچار مشکل نشوید.
- اگر نمی توانید تجزیه و تحلیل را به سرعت انجام دهید، تجزیه و تحلیل اشتباه انجام می دهید. شما باید یک مسیر ساده را از یک محصول دنبال کنید و سپس افزایش دهید.
- شما باید یک تیم یا فردی داشته باشید که درک خوبی از معماری تحلیلی آینده داشته باشد. شما هنوز باید در ساحل تصمیم بگیرید که چگونه تجزیه و تحلیل را مقیاس بندی کنید، آن را در سیستم های دیگر ادغام کنید و از داده ها مجددا استفاده کنید.
- داده های غیر ضروری تولید نکنید آمارهای وب علاوه بر اطلاعات مفید، زباله‌دانی عظیم با داده‌های بی‌کیفیت و غیرضروری نیز هستند. و این زباله ها در صورت عدم وجود اهداف مشخص در تصمیم گیری و ارزیابی اختلال ایجاد می کنند.
- به خاطر تجزیه و تحلیل، تجزیه و تحلیل نکنید. اول، اهداف، انتخاب ابزار، و تنها پس از آن - تجزیه و تحلیل تنها در جایی که تأثیر خواهد داشت.
این مواد به طور مشترک با Chebotar Olga ().
منبع: www.habr.com