|
|
This is a tricky topic. Conventional wisdom says that when you are planning a new product, it is very important to get user feedback through the process, multiple times. The logic: When the team is working on a new application or software product, they tend to get too involved with their own thoughts, their rationale and seek to believe that these are exactly what the users want. There are a number of products that were developed without user feedback and testing, and a large number of those do not really set the user community on fire, many of them are downright failures, since the users really are not looking for the workflows that the team thought would be loved by the users.
To try and ensure that the people involved in the application design and development remain close to what the users want, and also get a chance to vet their design and prototypes, typically a restricted user testing is done. A sample of users are taken, and depending on the current state of development of the application, either screen shots, or prototypes, or the working product is shown to the users and they are encouraged to use the application or evaluate whatever has been given to them. Viewing the interaction of users with the software is invaluable to the design team, since it gives them a fair idea of what the users like, what they dislike, and whether they are comfortable with the workflows that are being shown to them.
So far so good; however, over the past few years, there is another thought that is gaining attention. A number of new hardware and software applications have become successful where the application is meeting a need that users may not have thought about, and in such cases, user testing and feedback may not be the sole criteria on which to go by. It would be very much possible to think that some of the great apps on the iPhone, such as Instagram or others were not really designed and launched after user feedback.
Instead, you had a committed set of application developers who knew what they wanted, and were passionate about what they were doing. If some users did not like it, this would not have shaken them. In such cases, what happens is that even very honest user feedback would not have been the right way to go about; and this is the concept that is now shaking development companies around the world. When you are trying to build something in the area of the web / tablets / phones / Facebook app, a lot of stuff that is being worked upon is new, or atleast the workflows being developed are new. In such a case, the companies do not even go in for user feedback, instead working on releasing the software, seeing the amount of user acceptance and then tweaking (or dropping) the application, and go on. This makes life difficult for companies that have worked the traditional way, and which depend on user feedback as a way of validating new stuff that they are doing.
Some great books from Amazon on usability and user feedback:
| A Common Sense Approach to Web Usability |
The FlowingData Guide to Design, Visualization, and Statistics |
Designing with the Mind in Mind |
|
|
|
|
In many cases, especially for small projects / new teams, the Product Manager is typically somebody who is also not very experienced. The idea is that the Product Managers who are highly skilled or with a lot of relevant experience are assigned to the teams that are doing more important work. But this can sometimes result in significant problems for the project, to the extent that the project can become unsuccessful. There is an argument that people need time to get experience, and working in smaller or less important projects is necessary to groom people, and that may be a fair and true argument, but there is no getting around the fact that this can cause a lot of problems for the team.
When you have a team with newer people, there is a far less acceptance of what is possible and what is not. People have not had the time or the experience to learn a dose of realism, and figure out the speed at which things move as a part of software project development. When you add an inexperienced Product Manager to the mix, things can get even more complicated.
Consider the case whereby the team is working on a new feature, and something that is not really a copy of another product’s feature. In such cases, the team can have a lot of fresh ideas when working on the requirements and design of the feature, and when you have a user experience designer working on the project, the person will have a lot of ownership of the design of the feature. Now, based on some experience in such situations, what I have typically observed is that feature requirements are not really closed for long periods of time, or get closed and are then re-opened some time later. This would typically happen when the user designer has an idea, and then when it is implemented, the team members or even the designer has some modification of the idea, and far worse, the modification is seen as an improvement.
Now, if you are in the shoes of the project manager, in order to get the project moving, you can appreciate incremental improvements in the product as described above, but if these happen all the time, the schedule (even if you are using Scrum or other Agile methods) will never really get close to a conclusion. In such cases, what you really look for is a strong Product Manager who can take calls about whether the feature is good enough for customers, even when it is not perfect (and this may seem strange to a lot of people, but successful project management is about striking a balance between the improvements that you make to the application, and also about the discipline needed in the project in order to get achieve progress in the schedule).
In all such cases, a strong Product manager can ensure that after some due iteration, the feature requirements and design are closed, or even more, when newer queries are raised, they need to be striking improvements before they are allowed to be open. A good Product Manager is worth his or her weight in terms of gold if they are able to make these kind of calls and ensure that the schedule is adhered to.
A number of different models such as:
1. Agile
2. Clean room
3. Iterative
4. RAD or rapid application development
5. RUP or rational unified process
6. Spiral
7. XP
8. Lean
9. Scrum
10. V model
11. TDD or test driven development, and maybe others,
have been developed for increasing the efficiency of the software development process. As you see from the list above, the spiral model is also one of them. This article is focussed entirely up on the spiral model of software development and its advantages and disadvantages.
The spiral model of software development is a result of the combination of prototyping in stages as well as the design in stages. This model has been developed to get a model with the combined advantages of both the approaches namely:
1. Top down approach and
2. Bottom up approach
Another name by which this model is commonly known as is “the spiral life cycle model” and it has been named so because it implements the spiral development process. The spiral model is considered to be a systems development method or SDM and mostly finds its use in the industry of information technology or IT. This model also has some of the features of the water-fall model of software development incorporated in to it. Spiral model of software development has been designed for projects which are quite large, complicated and expensive. Many a times the spiral model of software development is confused with the helical model at first glance; although there is a considerable difference between them, such as the helical model making use of the dynamic programming approach. This approach is followed for the optimization of the architecture of the software system before decisions regarding the design are taken since they may cause problem.
This spiral model came in to existence in the year of 1986 designed by Barry Boehm although this model was not the first to take into consideration iterative development type of development methodology. The spiral model of software development as mentioned above combines the features of water-fall model of software development with the iterative development or prototyping as it is more commonly known as. The spiral model of software development has facilitated the ease of incremental release of the software product and also the incremental refinement of the software system or application. The spiral model of software development is also popular since it includes the explicit risk management within the scopes of the software development. It also provides benefits in terms of the following mentioned aspects:
1. Identification of the major risks whether be it managerial or technical.
2. Determination of the factors leading to the lessening of the risks.
All these added advantages help in maintaining a control over the software development process. The spiral model involves the substantial refinement of all the key products one by one for the following purposes:
1. Requirements definition and analysis
2. System designing
3. Software designing
4. Implementation of the code.
The key products are treated as the extension of an earlier product in each of the iteration of every cycle. This model makes use of almost the same phases of the development as mentioned below:
1. Requirements
2. Specifications
3. Architecture
4. Design
5. Implementation
6. Testing
7. Deployment, and lastly
8. Maintenance
The additional phases are:
1. Planning
2. Risk assessment
3. Building of prototypes
4. Creation of simulations
Like any other process, each and every phase of the spiral model is documented. The creation of the documentation keeps on going side by side the development process. A continuous stream of produced products is made available to the user to review.
Disadvantages of the spiral development process:
1. Highly customized
2. Limited reusability
3. Different applying method for every software system or application
4. Budget related risks.
| Agile and Iterative Development |
Software Development Using Scrum |
Agile Estimating and Planning |
|
|
|
|
In today’s world, especially for those folks who work in the high tech industry, there are a lot of distractions to getting their work done. With social networking sites, especially such networks as Facebook and Twitter taking up a large amount of time of people (and with studies now calculating that office workers can spend a sizable portion of their office times on social networks), there can be a huge impact on the productivity of people. Now, it is not only the organization that suffers from this productivity loss, but individuals are also impacted. For somebody who gets easily distracted, it is not even necessary that these social networking applications be available on their machine, with even a common very useful application such as email proving to be a loss to productivity.
Consider the following scenario. You are doing some work, and are somewhat focused on it, and if it is somewhat complex, it takes time to think through and figure out a possible scenario, and then suddenly a small email popup appears, and you are distracted enough to click on the popup and see what the email message is about. However, in all this, what happens is that the original issue you were working on is lost, and if you were slowly making some progress on a complex issue, it will take time to get back to the issue. Now, this is something that happens to a sizable number of people, even if they do not explicitly realize the productivity loss that they are suffering. However, if you are more disciplined, there is a higher chance of you being more productive and hence being able to showcase your abilities further (and this results in an advance in your career as compared to that of your colleagues).
So what can you do ? The first thing I did was to turn off the pop-up that shows when a new email comes in (with a positive impact on the many presentations I do in office, where the pop-up coming in the middle of a presentation was very distracting). The next thing, and this was inspired by the message I saw from a very productive person in the office was: Set times to handle email, rather than be on the beck and call of email. For example, there was a person who had set a signature that mentioned: “I check email at every 3 hour intervals, checking email at 9 AM, 12 PM, 3 PM, and 6 PM; and if you need to get some information urgently, call me.”
Such a message was very impressive, and presented a great picture of the person as a disciplined person who would respond to your email, but not immediately. Further, there was a good indication of when you would get a response. I spoke to the person who had set this message, and I learnt that he follows this rule, only making an exception for emergencies; and his colleagues consider him one of the most productive members of the team. Something that you could try and see whether this works for you.
| What’s a Disorganized Person to Do? |
Getting Things Done: The Art of Stress-Free Productivity |
18 Minutes: Find Your Focus, Master Distraction, and Get the Right Things Done |
|
|
|
|
|
Software Jobs If you have the following profile, and are looking for a job in India or in the US, please send an email to getitjobsindia@gmail.com
1. Software developer in Java / C / C++ / C# with experience more than 2 years
2. Software quality tester with experience more than 2 years
3. Product Management for a software company
4. Program Manager / Project Manager for a software company
5. User Interface Designer / Graphics Designer / Visual Designer
6. Tech Writer
7. Software products support
|
Recent Comments