Ok, so I started hacking up some HTML using our corporate branding standards and the free snippets we have. While it was cool and easy for me to just drag a snippet into Dreamweaver and have it appear on the page without any work, there's a lot of customization involved to get it to look exactly the way I want. I just don't know enough HTML to start playing with divs, tables, spans, colwidths, etc. and putting various elements exactly where I need them, nor do I have the inclination. We really do need a full-time expert on this kind of job! It was a good exercise for me to try in any case. I now am familiar with the space, know what kind of expertise is required, how to set up other people to do the same thing, and I know enough to make a case for bringing this kind of expertise into our firm.
My philosophy is: talk is cheap; only by doing do you really know [and what I mean by know is knowing by your gut]. You just gotta experiment and try different things and see what works.
Friday, January 25, 2008
Can't commoditize the "experience"
Here's something that I find interesting.
We've long ago commoditized many kinds of products. Services have been the next to go. We have BPOs happening in India, outsourcing of all kinds to many different types of firms all over the world. Some of it is good, some bad, but they're getting better. The next step up from services some say is the experience. Starbucks may not have been the ones to pioneer this, but they certainly have made it a household word. Starbucks just doesn't give you coffee (a product), or give you mere service; they've transcended into the world of experience.
So what's the point I'm making? Well, if services are becoming commoditized (and many of us are busy still making sure that goes OK), then experiences, which is next down the list, still need to remain close to the customer. We can't outsource the experience. I don't even know what that means or what it would look like! So applying this to software, we have U/X engineers: U/X = User Experience Engineers. Since the GUI is what the user sees as the entire application (users are blissfully unaware of all the middle tier and back-end stuff), we need to ensure their experience with the software is a positive one, not a traumatic one. We also need to show them that we are responsive to their needs. Thus the user experience is something we dare not commoditize and ship overseas. We need to keep this one close to our chests.
We've long ago commoditized many kinds of products. Services have been the next to go. We have BPOs happening in India, outsourcing of all kinds to many different types of firms all over the world. Some of it is good, some bad, but they're getting better. The next step up from services some say is the experience. Starbucks may not have been the ones to pioneer this, but they certainly have made it a household word. Starbucks just doesn't give you coffee (a product), or give you mere service; they've transcended into the world of experience.
So what's the point I'm making? Well, if services are becoming commoditized (and many of us are busy still making sure that goes OK), then experiences, which is next down the list, still need to remain close to the customer. We can't outsource the experience. I don't even know what that means or what it would look like! So applying this to software, we have U/X engineers: U/X = User Experience Engineers. Since the GUI is what the user sees as the entire application (users are blissfully unaware of all the middle tier and back-end stuff), we need to ensure their experience with the software is a positive one, not a traumatic one. We also need to show them that we are responsive to their needs. Thus the user experience is something we dare not commoditize and ship overseas. We need to keep this one close to our chests.
Thursday, January 24, 2008
A BA should be a RAD developer. Maybe Not!
So I've had some more thoughts along these lines.
After delving into the world of Dreamweaver and XHTML, CSS & Javascript [we'll see about AJAX], and talking to a real good front-end developer and senior BA, I've come to realize that my assertion about BAs becoming RAD developers is probably far-fetched. I was eager to learn it and with a bit of training and getting up to speed, I could probably create some workable pages (which I'm in the process of doing).
But I saw after my interactions with these guys that the front-end development I was thinking about is probably going to require someone devoted entirely to that task: a full-time HTML or ASP.Net front-end developer. There are just too many details that would need attending to. This is really a developer task. While I might be able to deliver workable pages (something perhaps good enough to show my users) they probably would be hacked and not very tightly coded; definitely not worthy of production. And I personally wouldn't want to go that route. My interests aren't in developing HTML pages.
So my thoughts have changed. I would say that having a BA along with a front-end developer at the high-cost centers (read: NY, London, anywhere that's close to the user) should be the new paradigm. The front-end IS the application from the user's point of view. If we get that right, everything else follows. But we need to get that right. We need customer involvement in getting there.
So if a BA and a front-end person meet with customers or users and are able to rapidly turn around the requirements into a working, clickable prototype, GREAT! You could have them iterate as much as they need to get it right. And then the front-end developer could deliver working XHTML code to the back-end developers. You can also start utilizing the front-end developer on other projects if the back-end people take a bit longer to deliver their pieces (or maybe not, depending on the methodology you're using: waterfall vs. XP for e.g.).
The main point here is that having a front-end developer to carry out RAD very close to the customer is the item that will start to foster good relationships between IT and business. The business will see that IT is more responsive because IT is able to come back in a few days with improvements in the interface that were requested. BAs will have more definitive answers and be more confident about what they're asking developers to do. And the RAD developer can deliver production-ready front-end code that back-end developers normally want nothing to do with. This is a win-win situation!
In our particular environment, we have branding guidelines we need to adhere to. The branding department has provided us with a framework of html and css (both with and without Javascript) as well as various code snippets. The front-end developer doesn't need to start up from scratch on each project. This makes high-fidelity prototyping or RAD more within reach than ever before.
After delving into the world of Dreamweaver and XHTML, CSS & Javascript [we'll see about AJAX], and talking to a real good front-end developer and senior BA, I've come to realize that my assertion about BAs becoming RAD developers is probably far-fetched. I was eager to learn it and with a bit of training and getting up to speed, I could probably create some workable pages (which I'm in the process of doing).
But I saw after my interactions with these guys that the front-end development I was thinking about is probably going to require someone devoted entirely to that task: a full-time HTML or ASP.Net front-end developer. There are just too many details that would need attending to. This is really a developer task. While I might be able to deliver workable pages (something perhaps good enough to show my users) they probably would be hacked and not very tightly coded; definitely not worthy of production. And I personally wouldn't want to go that route. My interests aren't in developing HTML pages.
So my thoughts have changed. I would say that having a BA along with a front-end developer at the high-cost centers (read: NY, London, anywhere that's close to the user) should be the new paradigm. The front-end IS the application from the user's point of view. If we get that right, everything else follows. But we need to get that right. We need customer involvement in getting there.
So if a BA and a front-end person meet with customers or users and are able to rapidly turn around the requirements into a working, clickable prototype, GREAT! You could have them iterate as much as they need to get it right. And then the front-end developer could deliver working XHTML code to the back-end developers. You can also start utilizing the front-end developer on other projects if the back-end people take a bit longer to deliver their pieces (or maybe not, depending on the methodology you're using: waterfall vs. XP for e.g.).
The main point here is that having a front-end developer to carry out RAD very close to the customer is the item that will start to foster good relationships between IT and business. The business will see that IT is more responsive because IT is able to come back in a few days with improvements in the interface that were requested. BAs will have more definitive answers and be more confident about what they're asking developers to do. And the RAD developer can deliver production-ready front-end code that back-end developers normally want nothing to do with. This is a win-win situation!
In our particular environment, we have branding guidelines we need to adhere to. The branding department has provided us with a framework of html and css (both with and without Javascript) as well as various code snippets. The front-end developer doesn't need to start up from scratch on each project. This makes high-fidelity prototyping or RAD more within reach than ever before.
Thursday, January 17, 2008
A BA should be a RAD developer
I had this idea today and wanted to explore it.
I've been busy reading various books on agility:
I have a lot of ideas and concepts swimming around in my head and am still trying to put it all together. But I'll give it a try.
1) It is far more preferable to be a generalist than a specialist. (or to hire a generalist rather than a specialist). Why? Because you want someone who can adapt. An employee who can do only one thing well and refuses to adapt is more trouble than he's worth. You want someone who'll help out the team in whatever capacity is needed. The truth of the matter is that when you begin a new job, your day to day responsibilities may have little in common with what was originally in the job ad. Many of us may grumble about this but the truth is that the boss needs you to do something here and now and it might not be what you originally had in mind. I think this happens most of the time. I personally would want to work with someone who's eager to learn new skills and take on more varied responsibilities, who begins to get the big picture (and getting the big picture may require taking on many different tasks), and who's willing to go the extra mile to get the job done, even if it's not part of their job description. Even better is someone who actually seeks out new challenges and responsibilities; who having done their job to the letter of the job description asks, "What else or more can I do? How can I move us further along?"
A note here about this: This kind of expansion of a person's role can be perceived as threatening to others on the team or organization who are used to a system or workplace that has ascribed rigid roles and titles (most organizations in general!). Indeed, even I've had thoughts or feelings about people who seem to be "acting-up" or "showing off" or "trying to get ahead" which can breed resentment. All I can say here is that change often feels threatening even when it's for the better and the good of the team. It might be worth it to actually get involved and see how you yourself can help and adapt. It's ok to be swept along in someone else's enthusiasm and to contribute and support that person.
It's been pretty well documented that smaller software teams get much more done than larger ones. However, on those smaller software teams, members don't just subscribe to narrow, rigid roles. They wear many hats. This is exactly why a generalist is more valuable than a specialist. So if you want to build good software, make your teams more lean and make sure that the staff on those teams are willing to learn other skills.
This really struck me when I read "Getting Real". 37signals would never hire an IA (Information Architect). That is just too small a role for their team. They need people who can shine in many areas.
2) Let's face it: In a perfect world, a BA is not necessary. The basic components of a transaction are a customer and a supplier (or software developer in this case). If software developers cultivate those soft skills and learn how to communicate in the customer's language, a BA position would be extraneous. They could just do the requirements gathering themselves. This is an extreme example, of course (and that is why Extreme Programming is thus named!). However, with more outsourcing, offshoring and nearshoring, the BA position has come into its own. We do need customer representatives and SMEs that can stand in for the customer. In an investment bank arena, the BA is really the customer. The BA is in fact the customer (or customer advocate) but also represents the development team. He constantly has to wear multiple hats. Of course I still need to go back to my real customers and have what I think are their requirements validated.
In fact, this latest exercise in going to the users was very revealing. I had really developed my wireframes and prototypes very well. I put some nifty features in there that I thought would wow the users. But I go down to show it to them only to get "uh huh." or "I guess that would be nice". Not the overwhelming compliments I thought they would bestow. What does that tell me? A lot! It tells me that we can design all the coolest, niftiest features in the world, but if the user doesn't care for it, it's a waste of time. It would be great if my piece of software does everything possible with every data set but is it necessary? I realized it's very easy to get ahead of myself and over-design but without real user input to validate, it might amount to nada. That's why it's important not to design too far ahead of development. The waterfall method of stacking up a bunch of requirements months in front of development is not recommended!
3) In my current project, I'm pretty much at the point that development can start. I've got all the keys questions answered. I have wireframes. I've built a prototype using a tool, etc. Now all I need are development resources. Unfortunately the resources are busy working on something else for the next 2 or 3 months! Aaargh. One of the things I was afraid of was going to the user with wireframes, getting them excited about what we were going to do for them only to find out we can't deliver. Not a good way to build relationships.
So I'm idle and started thinking about what I could do. I'm not a fan of the functional spec document which is what traditionally would be written at this stage. However, there's no rush since there's no development team to do anything with it. I would rather do something more useful. I've started the foray into Dreamweaver and XHTML and CSS in an attempt to bring my mockups to life. Our company has code snippets for much of our internal branding standards so I should be able to design my application using those snippets. The end product could then be delivered to the developers who would not need to spend any time doing gui work. I think this would be a huge win and streamline the process. In fact, this is also a great idea for outsourcing as well.
Why not take this one step further? If Ruby on Rails really is that awesome that I can create a blogging site in 56 lines of code, why not use it to create an app for my users? Let 'em have a go at it and get the ultimate feedback! Forget the functional spec. I can hand my development team a working application AND I'll be around to answer their questions. What can be better?
This is exactly why I titled my post "A BA should be a RAD developer". It was tempting for me to sit back on my heels and do nothing, after having spec'd out my first release. But I asked myself, "Where else can I play a role? fill a need or gap?" And being a developer occurred to me. If I could get a html site up, my users would have something to play with and give me even better feedback!
So a Business Analyst's main role is to get the requirements right. The real, surefire way of doing that is getting the users an actual application to play with. Doing that quickly especially if you work in a non-agile environment is of paramount importance, especially if your culture is (as it is where I work) that IT takes forever to get things done.
I'm also looking at this method as a way of spurring management into being more forward thinking about adopting agile. If I can wow my users with useful applications and have them email me and cc my managers about how exciting it was to see the application, I'm betting that Senior IT managers will jump and want to deliver those projects.
I've been busy reading various books on agility:
- Extreme Programming Explained
- Planning Extreme Programming
- Project Management with Scrum
- Refactoring
- 37signals' book: Getting Real
- Agile principles, patterns, and practices in C#
- Agile project management
- Joel on software
I have a lot of ideas and concepts swimming around in my head and am still trying to put it all together. But I'll give it a try.
1) It is far more preferable to be a generalist than a specialist. (or to hire a generalist rather than a specialist). Why? Because you want someone who can adapt. An employee who can do only one thing well and refuses to adapt is more trouble than he's worth. You want someone who'll help out the team in whatever capacity is needed. The truth of the matter is that when you begin a new job, your day to day responsibilities may have little in common with what was originally in the job ad. Many of us may grumble about this but the truth is that the boss needs you to do something here and now and it might not be what you originally had in mind. I think this happens most of the time. I personally would want to work with someone who's eager to learn new skills and take on more varied responsibilities, who begins to get the big picture (and getting the big picture may require taking on many different tasks), and who's willing to go the extra mile to get the job done, even if it's not part of their job description. Even better is someone who actually seeks out new challenges and responsibilities; who having done their job to the letter of the job description asks, "What else or more can I do? How can I move us further along?"
A note here about this: This kind of expansion of a person's role can be perceived as threatening to others on the team or organization who are used to a system or workplace that has ascribed rigid roles and titles (most organizations in general!). Indeed, even I've had thoughts or feelings about people who seem to be "acting-up" or "showing off" or "trying to get ahead" which can breed resentment. All I can say here is that change often feels threatening even when it's for the better and the good of the team. It might be worth it to actually get involved and see how you yourself can help and adapt. It's ok to be swept along in someone else's enthusiasm and to contribute and support that person.
It's been pretty well documented that smaller software teams get much more done than larger ones. However, on those smaller software teams, members don't just subscribe to narrow, rigid roles. They wear many hats. This is exactly why a generalist is more valuable than a specialist. So if you want to build good software, make your teams more lean and make sure that the staff on those teams are willing to learn other skills.
This really struck me when I read "Getting Real". 37signals would never hire an IA (Information Architect). That is just too small a role for their team. They need people who can shine in many areas.
2) Let's face it: In a perfect world, a BA is not necessary. The basic components of a transaction are a customer and a supplier (or software developer in this case). If software developers cultivate those soft skills and learn how to communicate in the customer's language, a BA position would be extraneous. They could just do the requirements gathering themselves. This is an extreme example, of course (and that is why Extreme Programming is thus named!). However, with more outsourcing, offshoring and nearshoring, the BA position has come into its own. We do need customer representatives and SMEs that can stand in for the customer. In an investment bank arena, the BA is really the customer. The BA is in fact the customer (or customer advocate) but also represents the development team. He constantly has to wear multiple hats. Of course I still need to go back to my real customers and have what I think are their requirements validated.
In fact, this latest exercise in going to the users was very revealing. I had really developed my wireframes and prototypes very well. I put some nifty features in there that I thought would wow the users. But I go down to show it to them only to get "uh huh." or "I guess that would be nice". Not the overwhelming compliments I thought they would bestow. What does that tell me? A lot! It tells me that we can design all the coolest, niftiest features in the world, but if the user doesn't care for it, it's a waste of time. It would be great if my piece of software does everything possible with every data set but is it necessary? I realized it's very easy to get ahead of myself and over-design but without real user input to validate, it might amount to nada. That's why it's important not to design too far ahead of development. The waterfall method of stacking up a bunch of requirements months in front of development is not recommended!
3) In my current project, I'm pretty much at the point that development can start. I've got all the keys questions answered. I have wireframes. I've built a prototype using a tool, etc. Now all I need are development resources. Unfortunately the resources are busy working on something else for the next 2 or 3 months! Aaargh. One of the things I was afraid of was going to the user with wireframes, getting them excited about what we were going to do for them only to find out we can't deliver. Not a good way to build relationships.
So I'm idle and started thinking about what I could do. I'm not a fan of the functional spec document which is what traditionally would be written at this stage. However, there's no rush since there's no development team to do anything with it. I would rather do something more useful. I've started the foray into Dreamweaver and XHTML and CSS in an attempt to bring my mockups to life. Our company has code snippets for much of our internal branding standards so I should be able to design my application using those snippets. The end product could then be delivered to the developers who would not need to spend any time doing gui work. I think this would be a huge win and streamline the process. In fact, this is also a great idea for outsourcing as well.
Why not take this one step further? If Ruby on Rails really is that awesome that I can create a blogging site in 56 lines of code, why not use it to create an app for my users? Let 'em have a go at it and get the ultimate feedback! Forget the functional spec. I can hand my development team a working application AND I'll be around to answer their questions. What can be better?
This is exactly why I titled my post "A BA should be a RAD developer". It was tempting for me to sit back on my heels and do nothing, after having spec'd out my first release. But I asked myself, "Where else can I play a role? fill a need or gap?" And being a developer occurred to me. If I could get a html site up, my users would have something to play with and give me even better feedback!
So a Business Analyst's main role is to get the requirements right. The real, surefire way of doing that is getting the users an actual application to play with. Doing that quickly especially if you work in a non-agile environment is of paramount importance, especially if your culture is (as it is where I work) that IT takes forever to get things done.
I'm also looking at this method as a way of spurring management into being more forward thinking about adopting agile. If I can wow my users with useful applications and have them email me and cc my managers about how exciting it was to see the application, I'm betting that Senior IT managers will jump and want to deliver those projects.
Subscribe to:
Posts (Atom)