Since my philosophy on product development is so closely aligned with requirements definition, I don’t know how you can begin a new product development without creating a team first.
The team should not be composed of only technical contributors, but also domain experts (internal or external), stakeholders from various company departments, and finally the user community.
Once the team is assembled, you can begin to define product offerings, value, cost, etc. With timely marketing input up-front, coupled with manufacturing and service personnel voicing their inputs from the beginning, you can see a product concept emerge.
My advice is to keep the team involved all the way through development and deployment gaining feedback as you go.
So if it’s a question of technology or team, I always choose team first. What do you say?
-Gary
When it comes to technological solutions, you want a firm that has a proven track record of excellence. As one of the first software and hardware consulting firms in the Northeastern United States, Advanced Decisions is a leader in the industry. Our strength is not only in the experience that we bring, but also in our approach to developing solutions.
Showing posts with label technology. Show all posts
Showing posts with label technology. Show all posts
Wednesday, November 28, 2012
Wednesday, November 7, 2012
Smartphones and Service Technicians
Smartphones will soon replace laptops as the primary tool for service technicians.
Companies are realizing that laptops are expensive to maintain in the field, and no longer present a clear-cut alternative to a smartphone. In addition, many service personnel already have a smartphone with them at all times for communication needs.
Advances in core technologies have made smartphones quite capable for the diagnostic tests and troubleshooting of field service personnel. And new smartphones will still support legacy systems via USB adapters just as laptops do.
The main thing lacking is apps that integrate information for service technicians, which is no easy feat. The apps must be smart and collect data from various sources, including diagnostic test information, part procurement, customer and warranty information, and incident and problem reports to name a few. It is this total integration in a simple package that will be a game changer.
Please share with me your experience with moving your service personnel to a mobile platform.
-Gary
Companies are realizing that laptops are expensive to maintain in the field, and no longer present a clear-cut alternative to a smartphone. In addition, many service personnel already have a smartphone with them at all times for communication needs.
Advances in core technologies have made smartphones quite capable for the diagnostic tests and troubleshooting of field service personnel. And new smartphones will still support legacy systems via USB adapters just as laptops do.
The main thing lacking is apps that integrate information for service technicians, which is no easy feat. The apps must be smart and collect data from various sources, including diagnostic test information, part procurement, customer and warranty information, and incident and problem reports to name a few. It is this total integration in a simple package that will be a game changer.
Please share with me your experience with moving your service personnel to a mobile platform.
-Gary
Monday, September 24, 2012
Changing to a New Embedded Development Platform
I imagine that for you, as for me, changing to a new firmware development platform is a serious undertaking.
We have all used plenty of development platforms and software development kits (SDKs) from various manufacturers in our careers--and since most of them share a great degree of commonality, we are comfortable with changing to a new embedded development platform. However, I find that the significant challenge lies in discovery of the differences between what we have used and are familiar with and the nuances of the new platform.
Changing to a different development platform is typically accompanied by a change in chip family and / or manufacturer. I find that truly mastering the new platform involves both reading through the reference materials while working with the new tool kit. (For application programmers, the creation of the ubiquitous "Hello World" software program is still the typical starting point.)
But embedded programmers face a different set of challenges. We actually have to get the hardware working first for any software to run (i.e. the Board Support Package (BSP) and the accompanying evaluation board).
In many embedded development projects, product hardware is designed and developed in parallel with the new firmware. Since the product hardware is usually based upon reference designs from the chip manufacturer, making sure the SDK's board support package works properly with the manufacturer's evaluation board is a natural first step.
I start by installing the SDK on my development computer, getting it operational and integrating it with the source control program that I plan to use. Since a typical microprocessor or microcontroller can be configured in so many ways I focus on modifying the BSP to get the evaluation board operational as close to the final product configuration as possible. Once I can demonstrate that I can configure the BSP to control the evaluation board specific hardware (e.g. LEDs blinking, testing memory, exercising I/O, and communication via USB, Bluetooth, RS232 or LAN) then I am ready to turn my attention to developing the product firmware. Often the initial firmware evolves to the boot-up diagnostic software for the embedded product.
What tips or process do you suggest when transitioning to a new embedded development platform?
-Gary
We have all used plenty of development platforms and software development kits (SDKs) from various manufacturers in our careers--and since most of them share a great degree of commonality, we are comfortable with changing to a new embedded development platform. However, I find that the significant challenge lies in discovery of the differences between what we have used and are familiar with and the nuances of the new platform.
Changing to a different development platform is typically accompanied by a change in chip family and / or manufacturer. I find that truly mastering the new platform involves both reading through the reference materials while working with the new tool kit. (For application programmers, the creation of the ubiquitous "Hello World" software program is still the typical starting point.)
But embedded programmers face a different set of challenges. We actually have to get the hardware working first for any software to run (i.e. the Board Support Package (BSP) and the accompanying evaluation board).
In many embedded development projects, product hardware is designed and developed in parallel with the new firmware. Since the product hardware is usually based upon reference designs from the chip manufacturer, making sure the SDK's board support package works properly with the manufacturer's evaluation board is a natural first step.
I start by installing the SDK on my development computer, getting it operational and integrating it with the source control program that I plan to use. Since a typical microprocessor or microcontroller can be configured in so many ways I focus on modifying the BSP to get the evaluation board operational as close to the final product configuration as possible. Once I can demonstrate that I can configure the BSP to control the evaluation board specific hardware (e.g. LEDs blinking, testing memory, exercising I/O, and communication via USB, Bluetooth, RS232 or LAN) then I am ready to turn my attention to developing the product firmware. Often the initial firmware evolves to the boot-up diagnostic software for the embedded product.
What tips or process do you suggest when transitioning to a new embedded development platform?
-Gary
Wednesday, August 22, 2012
How Managers and Engineers Tackle Projects Differently
They say you can’t understand someone’s perspective until you’ve walked a mile in their shoes. Having been both a developer and a manager it’s interesting how the goals, desires and pressures on each differ. Ideally this wouldn’t be the case, but reality doesn’t always match up.
As a developer I always wanted to create the best work possible. If I could use cool new technologies and learn something in the process, even better. I took pride in the products we created, but was more focused on improving my skills and growing as a developer.
As a manager (and I noticed this more as I advanced more) I was focused on balancing competing priorities from customers (internal and external), delivering results as cheaply and quickly as possible, without sacrificing quality, of course, and shielding my development team from all the stuff that makes them less productive.
At times these differences caused conflict. Maybe trying a cool new untested technology is not the best business decision when you need to get something out quickly. Sometimes there was an opportunity to stretch one of your teams with an assignment, sometimes not.
Differing pressures are always going to cause conflict, but with a good dose of mutual trust and understanding they don’t have to be disruptive. As a manager I always tried to do my best to make sure my developers knew that I knew where they were coming from, and then tried to explain where I was coming from--and mostly it seemed to work.
What experiences have you had in this area? I’d love to hear.
Judi
As a developer I always wanted to create the best work possible. If I could use cool new technologies and learn something in the process, even better. I took pride in the products we created, but was more focused on improving my skills and growing as a developer.
As a manager (and I noticed this more as I advanced more) I was focused on balancing competing priorities from customers (internal and external), delivering results as cheaply and quickly as possible, without sacrificing quality, of course, and shielding my development team from all the stuff that makes them less productive.
At times these differences caused conflict. Maybe trying a cool new untested technology is not the best business decision when you need to get something out quickly. Sometimes there was an opportunity to stretch one of your teams with an assignment, sometimes not.
Differing pressures are always going to cause conflict, but with a good dose of mutual trust and understanding they don’t have to be disruptive. As a manager I always tried to do my best to make sure my developers knew that I knew where they were coming from, and then tried to explain where I was coming from--and mostly it seemed to work.
What experiences have you had in this area? I’d love to hear.
Judi
Tuesday, July 31, 2012
Do Business and Engineering Get Along?
A comment from David B on our recent blogpost on process fanatics got me thinking. He points out that there is often a “dichotomy in point of view and approach between technically focused people and business solutions folk. The more effectively you can get them to ‘walk a mile in each other's shoes’, so to speak, the better the odds of developing technical software solutions that meet--or even exceed--the needs of the end user.” So true!
I’ve been on both sides, and this is definitely apparent. Unfortunately, the solution is not as clear, but I think a respect for what each group brings to the table is a great place to start.
Business people think that engineers often look down on them because they don’t understand all the things the engineers do, and this makes them “stupid,” though in reality, they bring a lot to the table. Who would take that cool technology and turn it into dollars to pay those engineering salaries without all the other functions of a business?
On the other side, business people often think that engineers are putting up unnecessary roadblocks regarding what they can deliver and when. It’s easy to ask for the moon, but it’s not so easy to deliver it. Understanding a bit about the technical challenges of developing a new product would go a long way.
Do any of you work in a company where this problem has been solved or somewhat alleviated? What did you do?
-Judi
I’ve been on both sides, and this is definitely apparent. Unfortunately, the solution is not as clear, but I think a respect for what each group brings to the table is a great place to start.
Business people think that engineers often look down on them because they don’t understand all the things the engineers do, and this makes them “stupid,” though in reality, they bring a lot to the table. Who would take that cool technology and turn it into dollars to pay those engineering salaries without all the other functions of a business?
On the other side, business people often think that engineers are putting up unnecessary roadblocks regarding what they can deliver and when. It’s easy to ask for the moon, but it’s not so easy to deliver it. Understanding a bit about the technical challenges of developing a new product would go a long way.
Do any of you work in a company where this problem has been solved or somewhat alleviated? What did you do?
-Judi
Friday, June 24, 2011
Making the same mistakes
I hear it over and over again from technology execs – I know we should spend the time writing specs or working on our process or on architecture or designing a good UI or testing or documenting or - fill in the blank.
Yet, time and time again, I see companies making the same mistakes. It kills me! I asked myself “why do they do it?” After all, it’s so easy to improve your delivery time and quality a little bit at a time. I know it’s hard to find a place to start, but for some companies I see, anything would help them. When in doubt, remember that good requirements make everything else easier!
Then I remembered something I’ve heard repeatedly “The pain of the change must be less than the pain of the status quo”. I get that change is tough, but some of these changes (i.e. good requirements definition) are not that painful. I think a more accurate assessment would be “The fear of the unknown must be less than the pain of the status quo”
Do any of you have less than optimal practices in your product development? We all do, in one way or another. Things can always be better. Why do you stay where you are?
Yet, time and time again, I see companies making the same mistakes. It kills me! I asked myself “why do they do it?” After all, it’s so easy to improve your delivery time and quality a little bit at a time. I know it’s hard to find a place to start, but for some companies I see, anything would help them. When in doubt, remember that good requirements make everything else easier!
Then I remembered something I’ve heard repeatedly “The pain of the change must be less than the pain of the status quo”. I get that change is tough, but some of these changes (i.e. good requirements definition) are not that painful. I think a more accurate assessment would be “The fear of the unknown must be less than the pain of the status quo”
Do any of you have less than optimal practices in your product development? We all do, in one way or another. Things can always be better. Why do you stay where you are?
Subscribe to:
Posts (Atom)