<style> .reveal { font-size: 20px; } </style> # Introduction to the CEE.neXT initiative --- # : Agenda : * [When it all started and why ?](#/2/3) * [Global objectives of CEE.neXT initiative](#/3/4) * [Data review process (How what & why)](#/4/5) * [Expectations and possible outcomes](#/5/6) * [What else ?](#/7/8) * [Q&A](#/8/9) --- # When it all started and why ? * Engineers already struggling with repeated Pulp\Candlepin\Performance issues for Sat 6.6. * April 2020 was the GA of Sat 6.7 and by june 2020 our case-queue was overflowing. * 3000+ cases on June 2020 itself. * Many cases were related to one common issue and like that many such batches of issues were there. * Many unique and complex issues were also found related to some of the cases. * Why that much rise in the number of cases ? * Lack of proper documentation for the common problems and procedures (known or unknown). * Lack of initiatives to fix such problems in the product itself. * Lack of automated checks to prevent running into a known issue. These were good enough reasons for someone to take an immediate action and that resulted in adaptation of the **Trend Analysis** effort which is now known as CEE.neXT among the entire CEE pillar. --- # Global objectives of CEE.neXT initiative * Reduction of incoming volume of support cases by understanding the reasons behind the surge and solving them to best possible extent. * **Don't workaround** a problem repeatedly but solve it within the product once so that it never occurs again. * Collect user feedbacks\requests and try to identify product & user exp improvement opportunities if present any. * Improve documentation around usage\configurations of the product and trobleshooting methodologies around known as well as unique issues. * Pre-detect an issue by analyzing certain inputs and provide an accurate\near-accurate solution that can mitigate the same. * The idea is not only to reduce the effort of manual troubleshooting for a greater number of support cases but also to deflect support cases from being opened as much as possible. * All of the above are applicable for any support cases or BZs outside of pre-determined raw data but still shows an noticiable impact on either the product or the user experience. --- # Data review process (How what & why) &nbsp; Let's cover this part in a live demo. &nbsp; Open this [script](https://raw.githubusercontent.com/jainnikhil30/cases/master/case_category.py) and these two docs i.e. [Process Overview doc](https://docs.google.com/document/d/1uHhU9wW-2FjQyjHi64yZ2Jvfi8CqcQSdq2Uyy1suPio/edit#heading=h.5d5vg76mxvsp) / [Volume Analysis sheet](https://docs.google.com/spreadsheets/d/1HcXVC5cTFw1szFQaunJNJ3_inr2YlkTH00by_CzTIDI/edit#gid=1499904024) and these will help in understanding the workflow of the review process. --- # Expectations and Outcomes * It's not about how an enginner have handled a support case technically but it's about what he\she might have missed\overlooked to capture and report\fix\improve\automate. * If an issue has been left unnoticed\ignored but that can bite back later, nominate it for the discussion among the group. * The same goes for any feature requests done by any user and that has been ignored (intentionally or not). * If there are multiple known bugs identified for a case but it is only associated with one or two BZ, ensure that the case is associated with other applicable BZs as well. * Either attach the right KCS to a case that supports the investigation or else nominate a KCS creation opportunity. * If content of an existing KCS\Documentation can be improved, make sure to do so if that helps to avoid recurrence of a problem or helps to troubleshoot it better. * Never miss an opportunity to nominate any known or newly created KCSs for AIR\ASA\SupportShell rules\Top Content Solutions as long they have met the right conditions. Continued .... --- Continued .... * Not to file any bug without discussing with entire review team or without identifying it as a valid bug. * Not to file any product RFE, without getting consent from the PM (AshishH) during bi-weekly sync up. * When reviewing any support cases under a specific category, don't ignore issues unrelated to the same but document it for further discussion. * When opportunity to create a KCS is present, reach out to the case owner first about it and if that is possible, the same opportunity can be passed onto any KCS1 candidate willing to create the KCS. * Apart from these, if any latest trending problems are being identified in your day to day tasks, feel free to document it and bring it in for the discussions. --- # What else ? As you might have observed, that the analysis we do, It already involves all basics from SQI\CQI\TQI of a case or KCS and more. Even though SQI\CQI\TQI are not entirely and officially the goals of this project, There are no restrictions in doing so. Rather, it adds to your quaterly goals and also gives you the opportunity to share your feedbacks with the respective associates about what they did good and what they could have improved. --- # Q&A * I hope you now have an idea of * what **CEE.neXT** is ? * how it can affect the product as well as user experience around it ? * and how you can contribute to the success of the same going forward ? * It's the right time to ask any questions that you may have but if none, I wish all the very best to everyone. Welcome to the team ..! --- # THE END > "For Satellite, the end is always a new begining of something surprising.."