I attended the HCIR 2010 workshop last Sunday on “Bridging Human-Computer Interaction and Information Retrieval”. Dan Russell from Google gave the keynote. This is a guy who is passionate about what he does, and it seems that his job is to study how people search, including how they think about searching, how they conduct searches, how they use search interfaces, etc. and to figure out how they could do it better.
One of the biggest problems that exists, he believes, is that there is no training or education for search. The overwhelming majority of people just do not know how to search well. For instance, he found that most people don't know that you can use control-F on almost every program in order to find a word or phrase. This is something that most techie people take for granted when they are looking for something. For certain searches, you look at the results in Google, you pop open one of the results that looks promising, and then you control-F to find your keyword on the page and see if it is what you're looking for. The step of using control-F obviously speeds things up greatly. According to Dan this is something that most people just don't know about. I was skeptical and so I mentioned it to someone I know who is a professional (college educated, works in an office, etc.) and he knew that you could do that in Excel but didn't realize that it worked in all programs. I was sort of astounded by this, which was something that Dan had mentioned happens to him all the time. So for search instead of making the results somehow better, there may be a lot more value in training the user and providing tips or heuristics to help the user while they are searching.
Sunday, August 29, 2010
Sunday, July 11, 2010
Hiring - finding out what you're really looking for
I've spoken to a few people recently about hiring. They were in an initial stage where they've said to me that they needed to find someone for a tech position. And in each case when I've asked for detail about the profile needed, it turned out that the person was not that clear on what they exactly needed. Everyone who has done hiring has been in this situation. You know you need someone and think you know what you need, but as soon as you start looking, you start to realize that you're really not sure.
Obviously it would be best to know before you start talking to candidates. For many hiring managers, though, it seems that they start by browsing ads posted by other companies to make a profile. And then the process of interviewing people is the way that they figure out what they are actually looking for.
One easy and obvious way to get a handle on this is to do the job yourself for a little while. Of course this depends on the job and company, but if you can, you'll clearly get the best sense of what's needed. This of course happens naturally in small, growing companies, but isn't always an option.
Another thing to do is focus on creating a good practical test for the job. For technical positions this is a necessity. And I believe that the best practical test simulates real work as opposed to theoretical problems or logic puzzles. So when you put together the test for what the candidate needs to know, you should be reviewing real work problems and tasks.
These are two things that have worked well for me. I also try to keep in mind that when you don't really know what you're looking for, not only can you make negative impressions on candidates, but - worst of all - you may not realize it when you find the right person.
Obviously it would be best to know before you start talking to candidates. For many hiring managers, though, it seems that they start by browsing ads posted by other companies to make a profile. And then the process of interviewing people is the way that they figure out what they are actually looking for.
One easy and obvious way to get a handle on this is to do the job yourself for a little while. Of course this depends on the job and company, but if you can, you'll clearly get the best sense of what's needed. This of course happens naturally in small, growing companies, but isn't always an option.
Another thing to do is focus on creating a good practical test for the job. For technical positions this is a necessity. And I believe that the best practical test simulates real work as opposed to theoretical problems or logic puzzles. So when you put together the test for what the candidate needs to know, you should be reviewing real work problems and tasks.
These are two things that have worked well for me. I also try to keep in mind that when you don't really know what you're looking for, not only can you make negative impressions on candidates, but - worst of all - you may not realize it when you find the right person.
Wednesday, June 23, 2010
Least amount of process principle
The least amount of process needed to do something is the right amount of process. For me this is a management principle that is akin to Occam's razor in science, where the simplest explanation is the correct one. As obvious or simple as this principle may be, it is violated all the time.
My main concern is with software development, but this principle is more universal for management, especially of creative work. The reason why this principle works is that all processes are carried out by a unique set of people who are all unique in their skills, personalities, and characters. As such, too much process will stifle the group and not allow the individuals to emerge and achieve.
This also means that you will encounter real difficulties when you take a defined process and try to implement it, because a defined process relies on roles that people have to play. You may get a group to enact a defined process, everyone playing their roles, but with time the process and roles will evolve based on the individuals. Of course this customization of the process is a good thing if you understand what's happening, and don't try to force things back to the defined process.
My main concern is with software development, but this principle is more universal for management, especially of creative work. The reason why this principle works is that all processes are carried out by a unique set of people who are all unique in their skills, personalities, and characters. As such, too much process will stifle the group and not allow the individuals to emerge and achieve.
This also means that you will encounter real difficulties when you take a defined process and try to implement it, because a defined process relies on roles that people have to play. You may get a group to enact a defined process, everyone playing their roles, but with time the process and roles will evolve based on the individuals. Of course this customization of the process is a good thing if you understand what's happening, and don't try to force things back to the defined process.
Wednesday, May 19, 2010
Kanban vs Scrum
I recently came across a great free book written by Henrik Kniberg and Mattias Skarin called, "Kanban and Scrum - making the most of both". It includes the most concise description of each development process that I've seen.
For Scrum, your overall concern is with timeboxing everything, making sure that there are short cycles and short meetings that are strictly adhered to. With Kanban, your main concern is with limiting the amount of work in progress. By limiting how many items are in each phase of development, your aim is to establish an on-going flow. It seems to me that Scrum is better geared for new product development and Kanban is better for existing products that need maintenance and new features. There is obviously much more to each and I recommend you read their book.
For Scrum, your overall concern is with timeboxing everything, making sure that there are short cycles and short meetings that are strictly adhered to. With Kanban, your main concern is with limiting the amount of work in progress. By limiting how many items are in each phase of development, your aim is to establish an on-going flow. It seems to me that Scrum is better geared for new product development and Kanban is better for existing products that need maintenance and new features. There is obviously much more to each and I recommend you read their book.
Monday, February 15, 2010
Business Value is Always the Goal
When you are creating software for a business, the creation of business value is always the goal. In general there are only two ways that business value is created. Either you are saving money because you make a process more efficient or you create new revenue with a new process, product, or feature.
As the goal of software development, it means that we are not even considering the qualities of systems that software developers are generally concerned with. So it makes absolutely no sense to create a system that is really easy to maintain if that increases the cost of the system so that it doesn't provide business value. These qualities have to be understood as constraints and they are understood in terms of trade-offs. If you are absolute about them, then you will have a hard time creating a successful system. This seems completely reasonable and obvious, but it happens all the time. Always remember: the cost of the system has to be less than the business value created.
As the goal of software development, it means that we are not even considering the qualities of systems that software developers are generally concerned with. So it makes absolutely no sense to create a system that is really easy to maintain if that increases the cost of the system so that it doesn't provide business value. These qualities have to be understood as constraints and they are understood in terms of trade-offs. If you are absolute about them, then you will have a hard time creating a successful system. This seems completely reasonable and obvious, but it happens all the time. Always remember: the cost of the system has to be less than the business value created.
Thursday, December 17, 2009
The Daily Scrum or Morning Meeting
A scrum or morning meeting is the best way to get control of a development process. Having it in the morning seems like the most natural part of the day for everyone to synchronize, obviously, before everyone has started working. Not first thing in the morning because everyone needs time to have some breakfast, review new email, read the news, and get settled in. About a half-hour should do it. The other good thing about having it in the morning is to ensure that everyone gets to work on time, which gets to the essence of how a scrum works - peer pressure. When someone is late to the meeting, it is not just clear to their manager, but to the whole team. So they are not letting their manager down, they are letting the team down.
During the meeting, each member of the team goes over what they have accomplished since the day before and what they are working on. According to strict principles, the meeting is not supposed to become a status meeting run by the project manager (technically the role is supposed to be called a scrum master, but I don't like that name). Personally I like having the project manager run the meeting. I prefer the direction that it gives. And you still end up with the peer pressure because everyone is listening.
During the meeting, each member of the team goes over what they have accomplished since the day before and what they are working on. According to strict principles, the meeting is not supposed to become a status meeting run by the project manager (technically the role is supposed to be called a scrum master, but I don't like that name). Personally I like having the project manager run the meeting. I prefer the direction that it gives. And you still end up with the peer pressure because everyone is listening.
Sunday, December 13, 2009
Using Humans in Your System Design
A mistake that a lot of people make when creating software is to try to automate everything. When you are making software for a business, you are generally automating a process and there is often a desire or drive that people have to make software that automates the whole process. They get into an all-or-nothing frame of mind that, unfortunately, usually ends up with nothing getting deployed, or, even worse, software that gets deployed which tries to do it all and fails, disrupting the business and wasting a lot more money.
There are many different strategies and methodologies to deal with this situation. Agile is probably the most popular and successful. One of the main tenets of Agile is to deliver business value as soon as possible. And in most situations in order to deliver that value quickly, you obviously can't program everything. And if you can't program everything, you are going to have to learn how to design humans into your system. This is something that a lot of software people seem uncomfortable with because they view the system they are building purely as a piece of software and think that automation is the ideal. But full automation is not necessarily the goal, creating business value is. (I'll have more to say on this in a later post.)
Subscribe to:
Posts (Atom)
