در این مقاله، من تجربه خود را در انتخاب ایده هایی برای توسعه عملکرد محصولاتمان به اشتراک می گذارم و به شما می گویم که چگونه بردارهای اصلی توسعه را حفظ کنید.
ما در حال توسعه یک سیستم تسویه حساب خودکار (ACP) هستیم - صورتحساب. مدت، اصطلاح
عمر محصول ما 14 سال است. در طول این مدت، این سیستم از اولین نسخه های یک سیستم تعرفه صنعتی به یک مجموعه مدولار متشکل از 18 محصول که مکمل یکدیگر هستند، تکامل یافته است. یکی از مهمترین جنبه های طول عمر برنامه ها، توسعه مداوم است. و توسعه نیاز به ایده دارد.
ایده
منابع
5 منبع وجود دارد:
- دوست اصلی یک توسعه دهنده سیستم های اطلاعاتی شرکتی است مشتری. و مشتری تصویر جمعی از تصمیم گیرندگان، حامیان پروژه، صاحبان و مجریان فرآیندها، متخصصان فناوری اطلاعات داخلی، کاربران عادی و تعداد زیادی از افراد علاقه مند به درجات مختلف است. برای ما مهم است که هر یک از نمایندگان مشتری به طور بالقوه تامین کننده ایده باشند. در بدترین حالت، ما فقط بازخورد منفی در مورد مشکلات سیستم دریافت می کنیم. در بهترین حالت، فردی در سمت مشتری وجود دارد که منبع ثابت ایده‌هایی برای بهبود است و اطلاعات ساختاریافته درباره نیازهای مشتری ارائه می‌کند.
- ما فروشندگان و مدیران حساب دومین منبع مهم ایده برای بهبود هستند. آنها به طور فعال و گسترده با نمایندگان صنعت ارتباط برقرار می کنند و سوالات دست اول در مورد عملکرد صورتحساب از مشتریان بالقوه دریافت می کنند. فروشندگان و حساب‌ها باید از تمام تغییرات قابل توجه در عملکرد خود و آخرین به‌روزرسانی‌های نرم‌افزار رقبا آگاه باشند و بتوانند مزایا و معایب راه‌حل‌های مختلف را توجیه کنند. این کارمندان ما هستند که اولین کسانی هستند که متوجه می شوند آیا برخی از قابلیت های صورتحساب به یک استاندارد واقعی تبدیل می شوند، بدون آن که نرم افزار نمی تواند کامل در نظر گرفته شود.
- مالک محصول - یکی از مدیران ارشد ما یا یک مدیر پروژه بسیار با تجربه. اهداف استراتژیک شرکت را در ذهن نگه می دارد و برنامه های توسعه محصول را مطابق با آنها تنظیم می کند.
- معمار، فردی که توانایی ها و محدودیت های راه حل های فناوری انتخاب شده/استفاده شده و تاثیر آنها بر توسعه محصول را درک می کند.
تیم های توسعه و آزمایش افرادی که مستقیماً در توسعه محصول نقش دارند.
طبقه بندی درخواست ها
ما داده های خام را از منابع دریافت می کنیم - نامه ها، بلیط ها، درخواست های شفاهی. همه
تجدیدنظرها طبقه بندی می شوند:
- مشاوره با معنی "چگونه آن را انجام دهم؟"، "چگونه کار می کند؟"، "چرا کار نمی کند؟"، "نمی فهمم...". درخواست هایی از این نوع به خط پشتیبانی سطح 1 می رود. امکان آموزش مجدد مشاوره در انواع دیگر درخواست ها وجود دارد.
- حوادث با معنی "کار نمی کند" و "خطا". پردازش شده توسط 2 و 3 خطوط پشتیبانی. اگر اصلاحات سریع و انتشار یک پچ ضروری باشد، می توان آنها را مستقیماً از پشتیبانی به توسعه منتقل کرد. امکان طبقه بندی مجدد آن به عنوان درخواست تغییر و ارسال آن به بک لاگ وجود دارد.
- درخواست تغییر و توسعه. آنها با دور زدن خطوط پشتیبانی وارد بک لاگ محصول می شوند. اما یک روش پردازش جداگانه برای آنها وجود دارد.
آماری در مورد درخواست ها وجود دارد: بلافاصله پس از انتشار، تعداد درخواست ها برای مدت کوتاهی 10-15٪ افزایش می یابد. همچنین هنگامی که یک مشتری جدید با تعداد زیادی کاربر به خدمات ابری ما مراجعه می کند، درخواست ها افزایش می یابد. مردم در حال یادگیری استفاده از قابلیت های نرم افزار جدید هستند، آنها نیاز به مشاوره دارند. حتی یک مشتری کوچک، هنگام شروع به کار در سیستم، به راحتی بیش از 100 ساعت مشاوره در ماه را می سوزاند. بنابراین، هنگام اتصال مشتری جدید، ما همیشه زمانی را برای مشاوره های اولیه رزرو می کنیم. اغلب ما حتی یک متخصص خاص را انتخاب می کنیم. قیمت اجاره البته این هزینه های نیروی کار را پوشش نمی دهد، اما با گذشت زمان اوضاع یکنواخت می شود. دوره سازگاری معمولاً از 1 تا 3 ماه طول می کشد و پس از آن نیاز به مشاوره به میزان قابل توجهی کاهش می یابد.
قبلاً از راه حل های خودنویس برای ذخیره درخواست ها استفاده می کردیم. اما کم کم به سمت محصولات اطلسی رفتیم. ابتدا توسعه را انتقال دادیم تا کار مطابق با Agile آسانتر شود، سپس پشتیبانی. اکنون تمام فرآیندهای حیاتی در Jira SD زندگی می‌کنند، به علاوه آنها توسط پلاگین‌های مختلف برای Jira، به‌علاوه Confluence پشتیبانی می‌شوند. راه حل های خودنویس فقط برای فرآیندهایی باقی ماندند که برای فعالیت های شرکت حیاتی نبودند. به نظر می رسد که وظایف ما اکنون مقطعی است و می تواند بین پشتیبانی و توسعه بدون پرش از یک سیستم به سیستم دیگر منتقل شود.
از این لینک می‌توانیم اطلاعات مربوط به تمام وظایف، هزینه‌های نیروی کار برنامه‌ریزی‌شده و واقعی را به‌دست آوریم، از گزینه‌های مختلف قیمت‌گذاری برای مشتریان استفاده کنیم و مستنداتی برای نیازهای داخلی و گزارش‌دهی به مشتریان ایجاد کنیم.
در حال پردازش درخواست های تغییر
به طور معمول، چنین درخواست هایی در قالب الزامات عملکرد ارائه می شوند. تحلیلگر ما درخواست را مطالعه می کند، مشخصات و مشخصات فنی سطح بالا را ایجاد می کند. مشخصات و مشخصات فنی را به شخصی که این درخواست را برای تأیید ارسال کرده است منتقل می کند - باید مطمئن باشیم که با مشتری به یک زبان صحبت می کنیم.
پس از دریافت تأییدیه از مشتری مبنی بر اینکه ما یکدیگر را به درستی درک کرده ایم، آنالیزور درخواست را در بک لاگ محصول وارد می کند.
مدیریت عملکرد محصول
عقب ماندگی درخواست های دریافتی برای تغییر و توسعه را جمع آوری می کند. شورای فنی متشکل از مدیر، روسای پشتیبانی، توسعه، فروش و معمار سیستم هر شش ماه یکبار تشکیل جلسه می دهد. در قالب بحث، شورا برنامه های کاربردی را از پس مانده ها تجزیه و تحلیل و اولویت بندی می کند و بر روی 5 وظیفه توسعه برای اجرا در نسخه بعدی توافق می کند.
در واقع شورای فنی با بررسی نیازهای بیان شده در برنامه ها به تقاضاهای صنعت و بازار پاسخ می دهد. هر چیزی که ارتباط کمی دارد، در انبار باقی می ماند و به توسعه نمی رسد.
طبقه بندی درخواست های تغییر و امور مالی
توسعه گران است. بنابراین، ما فوراً به شما خواهیم گفت که اگر درخواست تغییر از طرف مشتری باشد و نه یک کارمند، چه گزینه هایی ممکن است داشته باشیم.
ما درخواست‌های تغییر را به صورت زیر طبقه‌بندی می‌کنیم: نیاز صنعت یا ویژگی فردی شرکت. مقدار قابل توجهی از عملکرد جدید یا یک اصلاح جزئی. اصلاحات جزئی و درخواست های فردی بدون هیچ گونه زواید پردازش می شوند. درخواست های فردی برای یک مشتری خاص به عنوان بخشی از کار پروژه با او محاسبه و اجرا می شود.
اگر این یک نیاز عظیم صنعت نیست و حجم عملکرد زیاد است، ممکن است تصمیمی برای توسعه یک ماژول جداگانه جدید گرفته شود که علاوه بر عملکرد اصلی فروخته شود. اگر چنین درخواستی از مشتری دریافت شود، می توانیم هزینه های توسعه ماژول را پوشش دهیم، ماژول را به صورت رایگان یا با پرداخت جزئی در اختیار مشتری قرار دهیم و خود ماژول را برای فروش قرار دهیم. در چنین شرایطی، مشتری بخشی از بار روش شناختی را بر عهده می گیرد و اساساً اجرای آزمایشی ماژول را بر روی خود انجام می دهد.
اگر این یک نیاز صنعتی عظیم است، ممکن است تصمیمی گرفته شود که عملکرد جدیدی در محصول پایه گنجانده شود. هزینه ها در این مورد کاملاً بر عهده ما است و عملکرد جدید در نسخه فعلی برنامه ها ظاهر می شود.
به مشتریان قدیمی به روز رسانی ارائه می شود.
همچنین ممکن است چندین مشتری نیاز مشابهی داشته باشند، اما برای یک محصول انبوه واجد شرایط نیست. در این صورت، ما می توانیم مشخصات را برای این مشتریان ارسال کنیم و پیشنهاد کنیم هزینه های توسعه را بین آنها تقسیم کنیم. در پایان، همه برنده می‌شوند: مشتریان عملکرد را با هزینه کم دریافت می‌کنند، ما محصول را غنی می‌کنیم و پس از مدتی، سایر فعالان بازار نیز می‌توانند عملکرد مورد استفاده خود را دریافت کنند.
DevOps
توسعه دو نسخه اصلی در سال آماده می کند. در هر نسخه زمان برای اجرای 5 وظیفه دریافتی از شورای فنی در نظر گرفته شده است. بنابراین، در میانه روتین، هرگز توسعه محصول را فراموش نمی کنیم.
هر نسخه تحت مجموعه ای از آزمایش ها و مستندات مناسب قرار می گیرد. در مرحله بعد، این نسخه در محیط آزمایشی مشتری مربوطه نصب می شود که به نوبه خود همه چیز را با دقت بررسی می کند و تنها پس از آن انتشار به تولید منتقل می شود.
علاوه بر سیستم انتشار، فرمتی برای رفع سریع اشکال وجود دارد تا مشتریان به مدت شش ماه با خطاها زندگی نکنند. این قالب میانی به شما این امکان را می دهد که به سرعت به حوادث اولویت اول پاسخ دهید و SLA های اعلام شده را انجام دهید.
همه موارد فوق در درجه اول برای بخش شرکتی و راه حل های داخلی صادق است. برای خدمات ابری با هدف بخش SMB، چنین فرصت های گسترده ای برای مشارکت مشتریان در توسعه محصول وجود ندارد. فرمت اجاره SMB حتی این را فرض نمی کند. به جای درخواست تغییر در قالب الزامات واضح از طرف شرکتی، در اینجا فقط بازخورد و آرزوهای معمولی برای خدمات وجود دارد. ما سعی می کنیم گوش کنیم، اما محصول عظیم است و تمایل یک مشتری برای آوردن چیزی آشنا از سیستم تاریخی قدیمی خود ممکن است با استراتژی توسعه سیستم به عنوان یک کل در تضاد باشد.
منبع: www.habr.com