MikroScript

CeuConsult is generally involved in projects where they deploy and create multiple networking Infrastructures using Mikrotik, Ubiquity, Cisco, Juniper, etc networking devices. As the network grows bigger, several challenges and dependencies arise. They found updating system configuration on a routine as a humongous task. Two very important challenges are faced on a regular basis

 

• They have to manage a group of servers for executing periodic Python scripts at multiple instances (approx. 40 instances per server) based on data load. When the data load decreases they have to terminate such instances and the servers too. 

• Tedious job for the network engineer/technician to log into each system and push new configurations. It sometimes takes days to complete a cycle of devices to update.

• Further, due to security threats, they need to change the device password regularly. Cause of the engineer or technician's high attrition rate leads to poaching by competitors. It becomes highly necessary to change network topology and credentials to avoid any unforeseen circumstances.

​

With the team's brainstorming on multiple ideas and probable solutions, we have finalized the goal we intend to achieve as described below. 

​

Goal

​

"Is to develop a web and native application to automate the repeated tasks via scripts through scheduling on a periodic interval".

The product was further named as MikroScript.

 

Leading to:

• There is no need to write commands manually each time. Just select the job and execute it.

• Executing and managing the task is easy and time-saving.

• Increase in efficiency and accuracy with the monotonous task being eliminated.

​

Market analysis and competition research were conducted to ascertain further its market size and any similar products available in the market. No such product was exactly or close to available what we intended to develop besides the currently available scope to automate the script execution is very limited to the hardware i.e. juniper, Mikrotik, etc. They have their script runner which lacks usable functionality and is very cumbersome to set up. 

I used a more optimistic approach for market sizing via a Top-down approach where finding the total market and then estimating
what our share of that market can be. 

Further, I conducted a feature table comparison with the researched competitors, any close by i.e. direct, indirect, or potential. Similar to the sample shown below

​

​

​

​

​​

​

​

​

​

Customer Interviews & Inputs

 

We set up multiple interviews with expected users and customers to better understand the real pain in operations. Based on the inputs and feedback, we developed multiple personas of a Manager, Technician, Tech Lead, and Network owner. 

 

Below is the sample user persona of a technician in the field, whom we presumed to be an active application user. 

​

User Persona

​

​

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

​​​Development of MVP - Minimal Viable Product​

 

A POC cum MVP was developed to conduct the critical work of running scripts on multiple devices in the network. From the initial idea to developing an MVP and deploying at the customer end for testing, it was done within 3 months. 

​

Below is the screenshot of the actual application at work;

​​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​​

​

​

​​​​​​Feature Research & Preliminary Prioritization

​

Post the MVP success, we conduct a detailed requirement gathering and analysis. Further assumptions and risks was finalized based on the available information. We finalized with the customer the minimum criteria for success and started with the conceptualization of the solution. 

​

We developed a long list of features envisioned by the customers and categorized them based on their functional and non-functional requirements. The feature list was first refined using the MOSCOW Method i.e. Must have, Should have, Could have, Wish / will not have.  

​

Taking into consideration of must-have features, the following list of features was finalized;

• Logging

• Multi-Session

• Scheduler

• Multi Job

• Reporting

• Macros

• Automated Reporting

• Script Marketplace

• Publishing Script Marketplace

• IPv6 Support

​

​

Prioritization

​

Feature prioritization is analyzed via the business value vs effort matrix, to develop the roadmap for further product development.  

​​

​​

​

​

​

​

​

​

​

​

​

​

​

It has been finalized to develop 2-3 features per quarter depending on the engineering complexity and business value.

​

Product Roadmap 

​

Based on the above analysis, a product roadmap for development and delivery is developed to provide the desired business value to the client ASAP. 

​​

​

​

​

​

​

​

​

​

​

​

​​

​

Product Development

​

Initially, low-fidelity wireframes were developed to finalize with the customer the functional requirement of the product. Further high-fidelity wireframes were developed to have the look and feel of the product. ​

​​

​​

​​

​​

​​

​​

​

​

​

​

​

​

​

​

​

​

Epics, Features, and User stories are developed in detail with the required acceptance criteria. Grooming sessions were conducted on a timely basis with clarification if any with the customer was done pro-actively. T-shirt sizing was used to get the high-level estimation of the features whereas planning poker was conducted to get the required story points. 

​​

​

A sample user story

​

Title: Mikroscript Application Logging History Screen

​

As a logged-in user, I want to access and view my logging history on the mikroscript application so that I can review my upcoming and previous run scripts. 

Description: 

 

• The page for "History" on the app needs to be developed as part of this story. 

• The user should be able to access and view his/her upcoming and previous bookings with options to edit the upcoming bookings. 

• UI should be as per the attached Figma designs. Screenshots are also attached for reference. 

​

Acceptance Criteria: 

 

• The UI of the "Logging History" page should be as per the screenshot attached. 

• The Figma link for reference is: <https:// link to be provided>. 

• Following is the information of each field to be displayed: 

  • Logging History

    • ​Title Header: Logging History

  • Logging History Review Buttons 

    • HTML Type: Multi Button Selection 

    • Values: Upcoming & History 

    • By default select the option: "Upcoming" 

    • Validation: At least one of the buttons should be selected

 

In the upcoming tab - Show all the forthcoming logs after the current date.

In the history tab - Show all the past logs before the current date. 

​

• Script Details Box

  • Right Detail Box: 

    • Displays the script type (Image with a number) with the selected device as per the design. 

    • The scripting details are presented one after the other based on the latest dates. 

• Left Detail Box

  • Contains the following reservation details data 

    • No of times (#times) 

    • Date (DD.MM.YYYY) 

    • Time (24 Hr) ​

• Cancel Button: To cancel the selected booking 

• Edit Button: 

  • HTML Type: Edit button 

  • Clicking the edit button redirects the page to the "Script Details" page with prefilled data as per the current log.

• API endpoint to be used to get the script details for the logs

  • API endpoint: https://rms.com/user1/scriptDetails

  • HTTP Method: GET 

• Reference Link: 

  • Swagger Documentation for API: <http://swaggerLink.com/tableReservationDetails> 

​

​

Scrum Methodology

​

Scrum methodology was chosen for the product development life cycle. 2 weeks of sprint was finalized and resource planning was done accordingly to develop a self-sustaining and directive team. 

​​

​​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

Product V.1.0

​

The following is the screenshot of the first final version of the product shipped to the client and deployed in their system. 

​​

​​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​​​​​​​​Product Metrics 

​

Depending on the product outcomes, the product metrics may shift or change. Here are some suggested metrics we were tracking; 

 

Business Performance Metrics

​

• Monthly Recurring Revenue (MRR) 

• Customer Lifetime Value (CLV) 

• Customer Acquisition Cost (CAC) 

• User base growth (%) 

• Monthly new users (%) 

• Avg. Revenue per User (ARPU) 

• Annual Recurring Revenue (ARR) 

​

Product Performance Metrics

​

• Daily Active User (DAU) 

• Session Duration 

• Time to Onboard 

• Number of scripts logged per day, week & month

• Customer Satisfaction Score (CSAT) 

• Net Promoter Score (NPS)

​

Product Development Performance Metrics

​

• Velocity 

• Release Time 

• Escaped Defects due to requirements 

• Story Bugs

​

​

Continuous Development & Innovation

​

In-depth research on the features & design of the product with wireframes was developed by the team under me. We need to design the system for the general B2B market with a global footprint. Common language & easy to use interface with lean design, are the utmost need for this application. Navigating the user seamlessly with intuitive UI, easing the scope of understanding with the addition of new features and functionality. 

We fundamentally need to consider the varied types of users interacting with the system. Ranging from different nationalities and professional spheres, making sure the system delivers as intended.