李保存

讲稿@
http://libaocun.com/wp-content/uploads/2009/07/Journey.ppt

Code @
http://balionweb.googlecode.com/svn/trunk/SoftwareQualityControl/

Finally, I delivered my first talk. Kind of excited, you can imagine.

PPT can be found @

Let me know what you think of it.

Update

This article was originally posted @ http://blogs.msdn.com/bali_msft/archive/2009/06/02/my-pm-talk-in-sjtu.aspx

All great designs come from deep understanding to customers. In my case, I’d like to design the email service for information workers(IW) as I am one of them. Basically they are hired to get things done. Modern projects, or tasks in smaller granularity, are getting too complex to be accomplished individually. So people have to work together – we call it collaboration. Consequently they have to communicate. They are forced to communicate. Email solves the problem of logistics and synchronization so that communication could happen between different time frames and locations, so it is still indispensable currently. But it is far from perfect, sometimes it is a trouble. Can it be done any better? Let us have a try. This new thing is called Pmail.

Entities

First of all, let us keep in mind that tasks are actually what IWs really care about. They are much happier if they can complete assigned task without touching emails. Right? Completion of tasks is what they are trying to achieve. Second, when they have to communicate, they care about distilled information they are expecting while writing/reading emails. You will not get any additional credit through presenting your idea by writing a poem. Senders and recipients come last. Without them, communication can’t happen. These two entities get lower priorities because if distilled information can be gained by other means, say search engine or anonymous DL, who cares them?

Again – email for IWs is all about tasks, not messages. This is the most fundamental philosophy differentiating Pmail’s design from others.

Problems – an abused tool in workplace

By nature, current email systems allow one sends anything to any number of persons at anytime anywhere. Gradually it turns out true that something that can be anything can do nothing actually. Theoretically any email should be of your interest; otherwise sender will not send it to you. Realistically it is so easy to be over-used:

• Email overload. You might probably find everyone around you is complaining about too many emails. Doubt? Open you email clients, see how many unread mails you have. NY Times reports, E-MAIL has become the bane of some people’s professional lives. This occurs likely because of complicated job nature, but I’d say often it is actually because of poor email prioritization. Can you easily tell which email is much more important than others? Or emails tell its priority to you?
• Hard to map emails to one’s day-to-day jobs. How many times you have to search your emails to dig certain messages out because you need something?
• Mail thread discussions often go wild. Do you find you are in trouble figuring out what is going on when suddenly looped in a thread?

At a glance

Pmail’s primary design goal is to help team get jobs done efficiently – under right timing, priorities, order and resources. Everyone would have a clear picture about how his work contributes to team success.

Pmail would also aim to minimize communications as much as possible. Leave users alone please. In task-centered email design, all emails will fall into one of below four categories:

Persona/User scenarios

Key scenarios that Pmail addresses include:

• Know big picture for better prioritization – Steven, who is a developer in a software development team, came to his office in a morning. He opens bird view of pmail to check how his tasks (or WBS in more general term) fits into the entire team progress. He notices one of his tasks, task8, is in critical path according to updated plan(never expect plan is really locked after lock-down). This task is automatically prioritized to p0(highest priority) by Pmail. It is about implementing a feature according to design specification by feature PM.
• Maintain dependencies – Steven goes ahead to open task8 and find this task depends on two resources, 1) one LHS virtual machine, which has been completed by task7. VM address and credential are also attached. Nice! 2) PM spec. It is also claimed completed.
• Main email threads around tasks –Steven opened the spec document in team Sharepoint server, and he finds several points are not clear for him. Then Steven starts a mail conversation with relative PM, Joanne, against this task. The mail thread is linked to task8 and its status is open.
• Drive team work flow – Joanne received a catch-the-ball mail from Steven about p0 task8, so it is a shadow p0 task for her as well. Joanne can check task details in the Pmail. She quickly comes up with answers regarding Steven’s questions and writes back a here-you-go email to Steven. Steven receives the email and get unblocked. Steven closed the email thread by several sentences. This mail thread is traceable in task8 and can’t be replied any more as it is closed. Several hours later, Steven completes task8 and closes it in Pmail. When Steven re-visits the bird view page of Pmail, he finds task8’s color turns green due to status change. Steven then picks up another one unblocked taks, task9.
• Maintain team discussion – Task9 is about designing a new feature F9. Deliverable is reviewable dev design spec. Steven has two options about solving a technical problem, but not sure which way to go. He then sends a collective-effort discussion mail to the whole team. Since this is not a catch-the-ball mail, team mates will treat it with best efforts, but Steven still gets several great feedbacks. When he feels the problem is solved, he summarizes the thread with several sentences and closes the thread.
• Check history – One year later, Steven transfers to another team and his replacement, Eric, would like to better understand why F9 is designed this way. He opened Task9 in Pmail, check the mail thread and better understand original design decision.

Demo/UI Mock-up

Bird view will look like above diagram. In following task view, you can see all mail threads about one task are at your finger tips.

Mail view will also a bit different. Every mail has a TaskID field to help you get the whole context conveniently.

Key features in Pmail

In addition to biggest differences we covered before, you might also get excited when seeing below features.

• Sometimes feature-rich is not a good thing. It is so easy to reach this point when email system is designed for multiple purposes after several releases, say home usage included. But in any event, Pmail will provide a button to show/hide features(say, increase/decrease indent) which I don’t use in last month. Get me a simple world.
• Mouse hover will show abstract of email(user could assign, or automatically select) before deciding to read it
• Send me SMS notification when a selected critical thread gets new replies. No special carrier service needed, input my cell phone and go
• For discussion mails, send brainstorming results or decision made, and then close the thread by marking it as un-reply-able
• Enforce sequential replies, for example fill in a excel table
• Automatically memorize folder or url of files you are editing, and go to Pmail, it can be attached to the email by a hot key, say “ctrl+shift+v”
• mailURL(say, steven-task9-show-me-money-88; don’t use GUID, please) which can be shared across the clients. Don’t to forward again
• Automatically send out ping for dead catch-the-ball emails after pre-configured interval times out
• Play video/audio right inside the mail client
• Mail web client also provides web API like Facebook. OWA kills programmability.
• Tag everywhere – one mail thread might relate to more than one task. It is not a good idea to put a mail in one folder exclusively.
• Don’t allow send active documents to team for review, put it on shared place(say, Sharepoint) and send a link

I am interested in your thoughs on it. Let me know. Thank you.

Nowadays software is getting so complex that it needs incredibly more and more people to build it. For example, there are 9000 engineers working on Vista simultaneously. In certain sense, you can call that it is a labor-intensive industry. Ideally, it would be best to put all people in one place; however there are also lots of sound reasons to build global development teams.

Pros and Con

Why bother to build global development team?

• New talents pool – Software development needs so many persons with similar attributes. In Microsoft Company wide, top 3 hiring criteria are smart, passion for technology and fit to company values such as openness, continual self-improvement and mutual respect, etc. From various studies, supply of talented IT staffers isn’t keeping up with demand. And it won’t change anytime soon. Even when Microsoft is cutting 5000 jobs now, we still have another 2000~3000 job openings there. What to do if enough qualified hires can be not found within US? Go outside.
• Lower cost – let us straightly go to data. Annual pay for Level “59″ is about $74,000 in US, while same level is paid about $20,000(~RMB150K equally) in China. Another slight fact – It costs about $1.5 to go most common places in Shanghai…
• Close to market – Most innovative ideas often comes out of interactions with customers. And customers’ requirements vary from country to country. So best way to serve a local market is to be in the market.
• Specific knowledge – Cross-nation acquisition for specific technologies is another reason to build global development. You can’t(or not able to) move all folks to HQ.

Like many other things, challenges always go with benefits hand in hand. You can’t take only part of it. Fair enough.

1. Distance – People who work on the same software can’t work alone, they have to exchange information and make decisions. Less than 3 minutes conversation is often enough for slight but frequently arising communication needs, for example, “Could you show me the bug in your environment?” Distance makes it impossible to stop by one’s office. Network bandwidth is another issue introduced by distance. Why it matters? Suppose one team has to copy large file sets from another remote team daily, it would be a problem. The file sets can be growing amazingly big – for example, daily SQL Server build is about 300GB.
2. Time zone – Would communication a real headache since modern technologies such as email and telephone have been there for quite a long time? But the things are no one is there when you are working due to time zone. You have to wait another day to get an email response. When you rush to office to check it, the most frustrating but concise reply could be – “What do you mean by <insert anything you assume others should understand>? How can I help you?”
3. Culture/Language – Master level of English is unbalanced in global teams. There are dozens of ways to say “A beats B” in English, but only several of them are understandable for general public; dialect is another obstacle. For example, Chinese folks often have hard time pronouncing letter “L”, as a result, words like “girl” might sound weird sometimes.
4. Junior team – In my organization, most hires right come out of college. We are raw smart, but less experienced. It is hard to deny that some key ingredients for great engineers just take time – design skills, debugging techniques, influencing capabilities. This is not a cutting-corner example.
5. Conflicts between hierarchical management and local branding – By organization hierarchy definition, many business units have existence in China. STB, Live, Online Service, etc. They functions nearly independently of each other and reports to US. But from the perspective of customers/partners/talents, it looks a bit confusing because there are so many Microsoft’s.
6. People development – folks in remote sites are not equally exposed to development resources such as face-to-face training, library, mentors, etc.
7. Governing issue – due to well known concerns, something confidential can’t be moved out of US.

How-to

There are several factors playing critical role in deciding appropriate distributed development model. At least you should consider project type, team seniority, team size, team culture, communication cost and history.

• Build trust first. No matter how adaptable a new team is, it always takes time to fit into a specific team culture. So starting with easy jobs to build team moral and credibility is the safest steps before moving forward. Beyond this, the new team can target increased ownership.
• Decide on team coupling level. From highest to lowest, the level could be: pseudo random assignment, same branch same feature/component, same branch different feature/component, different sub branch but same main branch, different main branch & clearly defined data contract. Avoid circular dependency.
• Come up with communication plan. Minimized communication is not always the best, especially for relatively junior teams. The best way to develop people is to work with senior folks on daily basis as much as possible. So you have to make tradeoffs here based on various inputs.
• Shared lab if possible. If you have to copy large files across the ocean frequently, consider doing your job on a lab down in remote team. If you have to do copying, make sure the files meet most critical quality requirements before doing so, for example, a build verification test.
• People development plan. Regular staff exchanging plan such as Marco Polo and Silk Road program, getting a mentor, record trainings, etc.
• Local brand management. Externally shown as one image; internally run by functionality as usual.

Fast Company recently published its version of the world’s top 50 most innovative companies. Although I would question why Intel is among top10, what surprised me most is the fact that Hulu is listed #3. I know there might be political things about the particular order, as it goes with most ranking, but it would be also interesting to find out “why Hulu, not others”.

Origin

Hulu, an online video streaming company, managed to do something which YouTube failed to do. Copyright is one of YouTube’s headaches, but it is incredible positive thing for Hulu, because it is built intentionally aimed to server property content by two major stream media dogs, NBC Universal and Fox.

{YouTube, watch someone’s DIY video} VS { Hulu, watch TV & Movies online legally} -> Similar but different market niche.

People might be asking, why NBC and Fox executives don’t rely on YouTube to serve their plays? You can imagine following conversation which probably happened behind the scene:

This is the first site who delivers property video to your computer for free. Traditional Media Company gradually realized that they have to embrace the changes if they are not able to prevent them. It is online streaming, in this case. Hulu has more than 120 sources now.

Key is property content sources are nonrenewable rare resources.

Independence

Hulu’s CEO said to capital angels, “I don’t think you’ll be seeing the name Fox or NBC on the site hardly at all, Hulu is about the shows, not the networks. The shows are the brands that users care about.” Another quote, “the key to Hulu’s success is its freedom to operate essentially as a stand-alone company…”

From startup’s perspective, captical can be good thing, or bad thing. It can help you grow much faster, but it can also easily enable you miss your initial goals. Capital often appoints some seemingly smart guy, who is with XYZ MBA degree or n years of experience in ABC company, to take over the company as one of its investment agreements.

That is indeed one of the worst investment risk controls, although it happens again and again. Give money to most passionate guys, and letting them be passionate always is the only way to maximize the probability of getting most out of your investment.

Feature?Solution? Experience!

Question: If you are given a task to build a video streaming site within less than 3 months, what would you do?

We were taught this way:

1) Identify who will be using your site

2) Draw use case diagram

3) List scenarios for each user role

4) To support each scenarios, figure out needed features

5) Design/Code/test your features

6) Go live

7) Yeah! Party! :- )

If you follow this in your next interview, I can almost guarantee a pass. Do we miss anything? Actually we missed most critical one – Experience! Experience is a combination of brand/feeling/easy-to-use/enjoyable process. For example, given below requirement:

“Design something which is used to sit on, commonly for use by one person. It often has the seat raised above floor level, supported by legs.”

People will respond immediately, “Chair!”. You may notice that there are at least hundreds of types of chairs in the world, if not thousands of, if not millions of. Only most imaginative ones who deeply understand that particular set of users’ needs, care about their feelings and eventually apply those into product designs can do the best work. Let us take a look at “art of chair”.

Be COOL, in show time, although you might have the similar hard time figuring out what some of them really are. Just like someone said about iTune – “iTune is not selling features. iTune is selling experience.”

Hulu’s key experiences:

1) Simple

2) Larger screen

3) High-resolution video

4) Clutter-free

5) Quality control

6) Free to users

7) No download

Obsessed with users