The Development Lifecycle of a Feature: Part One

Posted by Natalie DeCario on October 15, 2013 at 12:01 PM
Natalie DeCario

We love putting out new features. They’re attractive to prospective customers, they continue to keep our current customers happy and they even keep our competitors on their toes. We like for the outside to think that we churn out these new features with no problem, but there’s a whole development lifecycle that the feature has to go through. We want to share that lifecycle with you in a two part series. Part One will talk about the initial feature request, the development stages and the final stage which is deployment. But the development doesn’t stop when the feature gets deployed. Part two will explore things like defects and new tasks that are related to the new feature.

Let’s start at the beginning which is where the feature is first requested. We get requests from two places: our BackOffice customers or from one of our internal departments such as porting. New features ideas can be sent to features@voipinnovations.com. Once we get the feature request, the first thing we do is approve, deny, or table (saving the request to be evaluated at a later date) the request. For the feature request to be approved, we need to go through some questions.

  • Is this actually possible to do?
  • What resources will it take to complete the feature? (technical, financial, manpower)
  • Is this something that will benefit our customers as a whole?

Development LifecycleOnce we go through these questions and determine that the feature request is approved, we then need to start the information gathering stages. At this point we’ll get in touch with the original person who made the feature request to figure out what their expectations are for the new feature. We need to determine how the feature will work on a technical level, how it could affect other things in the BackOffice and more importantly, how it is supposed to help the customer. While written documents can be packed full of great explanations and details, screenshots can be a huge help so we know what the customer is expecting on a visual level. To let you in on an office secret, when we want something new built we take a screen and then add the things we want in Paint and hand it off to our developers. Yeah, they’re that good that they can take a Paint picture and turn it into something real and functioning in the BackOffice!

Now that all the general information is collected and we know what the customer is expecting, it’s time for our developers to start building the feature. This is another stage where we go back and forth with the customer so we can make sure that we’re building it so it’s functional and what the customer wants to see. Once it’s approved by the customer and by our team, it’s ready to be deployed. We do have a few rules in place when it comes to deploying things: we never deploy things on a Friday and we have designated people who are responsible for hitting that big green DEPLOY button.

This all sounds like a nice and easy process, right? For the most part it is. But after we hit that DEPLOY button, the feature is subject to defects that may not have been accounted for or there might be certain tasks that need done to improve it. These topics are going to be what we focus on in Part Two of this series. Check back into our blog or visit our social media sites next week for Part Two. Another option is for you to subscribe to our blog (that box right there under our social media buttons) so you won’t miss any of our blog posts!

Tags: VI News

New Call-to-action
Back to Blog Home >>

Subscribe to Email Updates

Recent Posts

Posts by Topic

see all