Starting the solution
Iterative development
Iterative development techniques don’t always appear to do much in the way of upfront design, relying instead on frequent releases of software to gauge the design’s suitability. Although this approach can certainly work, it can be time-consuming if the initial releases are not very close to what is needed, or if the problem is so poorly understood or defined by the stakeholders that any solution is bound to be wide of the mark. In any event, it is usually more efficient to begin the discovery of need with abstract models and conversations, instead of concrete implementations.
Unfortunately, many projects begin with a proposed solution—in our terms, this means starting in the fourth quadrant, the Future-How. By starting here, the development team must hammer and cajole the solution into some semblance of what is needed, and at the same time attempt to discover what is really needed. Many practitioners find that they are forced to start in the Future-How quadrant, move back to the Future-What view to find out what is really needed, and then proceed once more to the Future-How view of the solution.
No matter how you are developing software, the important part of this process is the discovery, by both you and your stakeholders, of the real needs of the solution.
Essential business
The functional needs can be presented to you in the form of a business use case (BUC) scenario, a collection of atomic functional requirements, or properly crafted user stories. The level of detail that you address before thinking about the solution will vary depending on your project strategy and the way in which you are working with all the stakeholders. Chapter 9 is devoted to strategies for getting from needs to solutions. An understanding of the non-functional needs of the essential business is important to crafting a valuable solution. The non-functional requirements—such things as usability, look and feel, operational, environmental, security, and so on—must be considered when making choices about the solution. The non-functional needs are largely responsible for specifying the kind of user experience appropriate for the intended audience.
Determine the extent of the product
The task of business analysis is to determine what the work should be in the future and how the product can best contribute to that work. As noted earlier in this text, business use cases are responses to requests from the outside world for the work’s service. The optimal response is to provide the most valuable service (from the outsider’s point of view) at the lowest cost in terms of time, materials, or effort (from your organization’s point of view), and in the most pleasing and encouraging manner (from the end user’s point of view). Thus the product you craft should be a contributor to the optimal business use case—one that makes the product cheaper and faster and more convenient and all of the other things your project is to deliver
~Igor Ilin
Adjacent Systems and External Technology:
ReplyDeleteIt is good to understand the nature and technology of the adjacent systems before including them. Adjacent systems are some kind of systems which reside adjacent to the work. They receive data or services from the work and then, supply data back to the work. The scope of the work is shaped by aspirations of the adjacent systems.
There are three type of adjacent systems: Active, Autonomous and Co-operative.
Active Adjacent Systems: In active systems, humans' interaction is involved by having some initial objectives. They provide data, asl questions or give choices to achieve the objective. It is a direct interaction without having any third person's collaboration. Active adjacent systems are able to interact with the work; this interaction can occur face to face, by telephone, via a mobile device, with an automated machine, or over the Internet.
For example related to the TD bank, when customer visits the branch and ask question to the customer service representative, then customer get direct response from them. This is how active adjacent systems work.
Autonomous Adjacent Systems: This includes one-way communication to external bodies.
For example, when your credit card company sends you a monthly statement, you (the card holder) are an autonomous adjacent system. You passively receive the statement with no interaction. You are acting independently, or autonomously, as seen from the viewpoint of the work of the credit card company.
Co-operative Adjacent Systems: Cooperative adjacent systems are automated systems that collaborate with
the work during the course of a business use case, usually by means of a simple request–response dialog. A cooperative adjacent system might be an automated system containing a database that is accessed or written to by the work, an automated system that does some computation for the work, or any other automated system that provides a predictable and immediate service to the work.
Designing the User Experience
ReplyDeleteDesigning the whole of the customer experience is the best practice to come up with a commodity that makes the public want to purchase it and/or use it. Experience design is a powerful topic and one that we recognize to be ahead of the scope of this book. However, we shortly mention it here because this type of design is beginning to perform a bigger part in our improvement activities.
Innovation
Innovation, the word here, means thinking differently about the issue to find a fresh and improved practice to do the task, or in some situation to discover better work to do. This chapter bring in some innovation triggers. These approaches recommend innovations to identify fresh and better solutions.
The triggers are convenience, connections, information and feeling.
costs benefits and risks
ReplyDeleteNaturally enough, choosing a solution is not just a matter of drawing a few
lines on process models and hoping for the best. You have the responsibility
to come up with the optimally valuable product—that is, optimally valuable
to its owner. This implies that the cost of your solution must be in proportion
to the benefit it brings to the owner. There is little point spending $10
to develop the product if the benefit it brings is worth only $1—unless, of
course, the $1 saving is part of a repetitive process and is applied thousands
of times.Similarly, the risk must be in proportion to the benefit and cost. Risk in
this case consists of the likelihood of a potential problem becoming a real
problem, together with the downside impact if the problem becomes real.
Value is the important thing to remember here—value to the owning
organization. Sadly, we don’t spend enough time measuring value, because
it is too difficult; instead, we measure cost because it is easier to measure. It
is safe to say that we measure things only when it is easy to do so: It is easier
to measure productivity than it is to measure customer loyalty; it is easier
to measure cost than it is to measure effectiveness. As a consequence, we
get productivity and ticked-off customers; we get cheap but practically useless
systems. Clearly, our projects should decide what it is that provides real
value, and build according to that understanding.
TD bank always keep in mind values and the risks while performing updates and launching new products