Biz Product Learnings
0 likes276 views
- Domain expertise needs to be documented before implementation begins, as a consultant with 10-15 years of experience in the domain helped a project that had been struggling for six months make progress within four months. - User empathy is important, as simple features like grouping names were found very useful by users despite being easy for developers to implement. - Content should be called content rather than data, as this shifts perspectives to prioritize things like user involvement and content creation tools. - Architectures need to be understandable to executives in order to guide a project successfully rather than resulting in a "rough ride".
Biz Product Learnings
- 1. Biz app solutions Some experiences and lessons learned By Kinshuk Adhikary Note : 際際滷s not in any particular order, use own judgement in ordering them...
- 2. The user empathy element In one product, the most used region of the solution was a simple grouping of some names. Called MyGroup or something. The developers would have spend less than a few hours in implementing it. Yet it was considered a very useful feature by most user groups. It is really hard to predict what user groups will find useful. The only way to get those into a product is to build a culture of user empathy in the technical teams, a sense of respect for the user. A certain amount of technical humility is a key to providing good solutions.
- 3. The domain expert In a product related to pension funds, an 80 page document was created by a consultant, a real domain expert. Without this, the implementation team had been foundering for six months. With it, the product saw its first version in the next four months. Before all else, domain expertise needs to be documented 10-15 years of actual experience in the domain helps Expert ought to also have been an user, in several user roles Describes not the product alone, but a 100 related things
- 4. It is about content , stupid Most business solutions are about the aggregation/creation of content, about content processing, and content delivery. Seen in this perspective, the responsibility of the solution provider is a never ending cycle, not an end-point. Stop calling it data. Call it content, see how everyone's viewpoint changes. When you call it content, things like ETL, data migration, and user involvement from early stages come right up to the surface, instead of being after-thoughts. Content creation tools become a separate concern.
- 5. Architecture for the CxO This was in the EJB 1.0 days. The CxO wanted EJBs, so he could compete in the market. The developers suffixed every class name like this, xyzEJB.java. And everyone was happy. Without the CxO's developing an architectural perspective, it can be a rough ride. There are just 3 things to know (see below). Components that do specific specialized things when instructed. Events that cause a thing to be done Connectors pipes through which the data and instructions flow between the components The CxO is the most important person in the product. Without a diagram that he/she understands, the teams are lost.
- 6. We love to chat So here is this amazing e-learning product, about a 1000 classes. And what do most users latch on to when it is in use ? The Chat and Discussion module ! None of the pedagogy experts visualized the load on it, so everyone had to rush to refactor the entire module. Give users half a chance and they will love to chat, discuss, tweet. Collaboration modules are easily the ones that will see the most performance load.
- 7. User interface A good user interface has another name, it is called habit. Whatever it is that user's are habituated to in other applications that they use, is what they instinctively look for in any new UI. Which obviously means the usual office applications and popular public internet applications The same or similar visual cues and legends; maybe only a few, very few departures, to signal a distinctiveness. An inventive creative UI is not the best way to make the user comfortable. In fact it can backfire sometimes.
- 8. Too much too soon Information architecture is all about presenting the content in a way that users can relate to. It is possibly the most difficult part of the solution. Too much text Too much typing Too many clicks Too many fields on the form Too many alerts Too many pages to accomplish an unit of work Navigation Drill down hypertexts Page reloads Tabular listings Dashboard graphs and charts Seems there is no easy way out except to find out the best fit.
- 9. Versioning Software is inherently iterative. Sometimes it is even recursive. The versioning guy is the focal point of many things features, marketing, testing, development, design, roadmap, furture(s)... Maybe not enough time is spent on discussing all the things that collect around that single thing called version number. Versioning granularity defines development maturity.
- 10. Meeting users physically Developers are human beings. They carry a picture of the users in mind after they actually meet them. Users are human too. They love to share, throw bouquets or brickbats. User conferences are a necessity and a need. Obvious. See also Milieu of the developers, a later slide.
- 11. Application security So you think your web application is secure ! Really ? The lack of knowledge about the rudiments of application level security is amazing. Most well known public web applications are vulnerable in some way or the other. I have also been quite put off that many many developers get into difficulties on authorization APIs like ACEGI. Checkpoint : Roles, Principals, Permissions, ACLs Checkpoint : SQL Injection and XSS Injection Checkpoint : HTTP basics Checkpoint : many more, but at least the above !
- 12. A new generation of users Ten years ago, users would see an Error Page in your application, put a finger on their cheek, and say Oh, how silly of me, I must have made a mistake. A new generation is around. They say things like look at this stupid application, I actually have to move to another page to create a time entry !. Just this beware of silliness in solutions from now on. There is a factor of unforgiveness in the new kind of users, that ought to be somehow built into design, development and testing but I am not sure how.
- 13. Intelligence capture After many years, one can almost instinctively point to 20% of a solution and say herein lies the knowledge, the real intelligence. The remaining 80% are usually the mechanical parts. For a few dollars one can purchase tools and jigs and fixtures that would make creating that 80% a simple task. When one sees such intelligence not in a pin-pointed location but generally scattered, it is a red flag. In that case, instead of a lego toy, it is probably a noodle. Noodles affect the enterprise in many cost-ineffective ways.
- 14. Meeting the future with the solution Sooner or later, a solution comes up against a fairly common set of concerns. How much easier would things be if these were considered right at the beginning, considered, not necessarily implemented. Entity models and hierarchy Data migration Identity management Integration issues likely to arise Reports Push-pull-publish-subscribe Load distribution Goes on and on...
- 15. Quality firsts Most development teams do not have structured testing approaches or test teams. Most pay lip service to unit testing they think it is something that testers do. And most important, the idea that quality comes from early and informed interventions by the first people, a set of good architects and design guys, is a rare thing to find. Quality arrives from a sales and marketing perspective Quality in software is very similar to the interactions between a good publisher, an editor, and an author. And of course, the book in the hands of the user.
- 16. Agile's achilles heel Agile methodologies seem to be modelled on the request- response paradigm. To quickly create something that is just good-enough. To use recursive small iterations to create a product. Small jigsaw puzzles, yes. Complex ones, no. It is not possible to increase complexity, completeness and consistency by simplistic assumptions. The whole has to be visualized before the parts. Think of a problem space as a big bug'. It is about disintegrating the big bug into small ones, and controlling the number of secondary bugs as you put all of them into a box. If you cannot see the roadmap, you cannot control the bugs.
- 17. Where is the customer ? One of my most hilarious moments was with a couple of guys building what they called a Billing module. To create bills for hours worked etc. To be sent to customers. With aged bills. But the application, a superb one about the work itself, had no concept called customer. At the modelling stage they had somehow forgotten that a customer, explicit or implicit, was needed in a billing scenario. And introducing one now would change the models quite a bit. Red faces everywhere. Amazing things happen. And a camel is a horse designed by a committee A few years ago, an enterprise level software nearly bought a company down. Someone had improperly priced goods-in-stock, so the software always showed slightly lower inventory. The problem was traced to its root cause only after a slow Christmas sale and contradictory buy instructions led to the company's warehouses getting flooded.
- 18. Milieu of the developers For business solutions, it is difficult when the development team lives and works in a space that is too different from the real business environment. Consider a brilliant student or intern who has only a theoretical concept of a workplace. There are only certain kinds of problems that can be tackled by such a person. This understanding lies at the root of a successful distributed development environment. How to send work out, and then collect it back in. Comprehension is the first benchmark of communication. Constructive feedback is the second.
- 19. Effort estimates Most of the talk about estimating software efforts in terms of man-hours and people is actually quite ridiculous. Consider : Pieces that used to take a month of effort about 6 years ago, take a few hours nowadays with the right tools and IDEs. Not knowing all this, and asking the developer to estimate the effort, is like asking the barber if a haircut is needed. In most teams, there are only a few among the large hordes of them who (can) make a large difference. Some developers can deliver 3 times as much as another, or 10 , or even 15. There is no fall back, there is no replacement for a person. There is nothing called knowledge transfer. When a key person leaves, a new project silently replaces the older one, with few able to differentiate. Elapsed time is not a mutable variable.
- 20. St. Paul's Cathedral on a clear moonlit night There are only very few architects. The distance between them and the implementors is vast. Their relationship with the business folks is strange too. They can be commissioned by a patron, not really hired by an employer. When all these gaps are bridged, you get a cathedral that outlasts the flux. It is NOT about engineering alone.