The birth of a FOSS application
Friday January 19, 2007 (09:01 PM GMT)
By: Brice Burgess
Late in 2005, my brother needed free, easy to use mailing list software to reach out to some 3,000 fans he acquired while touring the country with his band King Wilkie. As his technical expert, I was unable find a FOSS application that met his need for a free, simple, Web-based newsletter that provided the flexibility of mailing subgroups. I decided to roll my own under the GPL -- partially to give back to the FOSS community, partially to practice new programming techniques, and partially to provide a solution. What I learned may be as valuable as the software I helped create.
Before deciding to create yet another mailing list application, I had to ask myself whether it was worth the effort. Was the software-to-be significantly different than what was already available? Could I collaborate on an existing project to achieve my goal? Would it take too much time?
I searched Google and popular software repositories Freshmeat, SourceForge.net, and Hotscripts with keywords like "HTML Mailer," "PHP Mailing List," and "Newsletter." I discovered many mailers, but none matched my requirements. I needed software where subscribers' field values dynamically define what address groups they belong to. This would allow the band to mail volunteers in New York, for instance, by creating an address group named "NY Volunteers" matching subscribers who checked that they wanted to be a volunteer, and who selected New York as their state.
Since I could not find an existing project that matched my needs, nor one I could contribute to without forking, I had to ask myself if I had the development time. The good news is that I was on an extended holiday, working out of a Virginia basement. I had the time to spend and a relatively loose deadline, so I decided to begin my first "serious" open source project. I soon learned that such projects require more devotion than most people imagine. I sat down with pen and paper and planned my feature set, named the project bMail (I usually prefix my projects with "b," my initial), built the program's HTML skeleton, and sifted through the Open Source Web Design site to establish a look and feel. I created the bMail project on SourceForge.net and set up version control.
Early bMail development was kludgy, lacking in peer review or community feedback, and done in haste to meet the band's minimal requirements. When it reached a "usable" state in February 2006, I decided to make initial announcements on Freshmeat.net and Hotscripts.com. These sites are the New York Times of FOSS scripts, and their listings are free, re-occurring full page ads. The publicity brought in interest from the public, and with the public came the need to make things better. The incompleteness, lack of documentation, and ugly code practices were, frankly, embarrassing. All of a sudden bMail became a daunting task -- there was more to be done than could be accomplished by a single unpaid person. My milestones seemed far-reaching, and my forums were full of sysadmin 101 responses.
To top things off, I received a cease and desist letter about the bMail name, which turned out to be the same as an established Windows-based mass mailer. I was ready to abandon ship. It would have been easy to fold. After all, I had already accomplished my main goal of providing "usable" mailing list software for the band.
Positive public reaction, however, gave me new inspiration. A handful of users expressed true interest in the project. I began to receive translations, the first being Romanian. Corinna Thoeni, an Italian developer, inquired on pitching in and now maintains an experimental SVN branch. Stephane Faroult, a French SQL expert, volunteered his advice. Carey Williamson avidly volunteered his support in the forums. A community was forming, and it proved to be a source of ideas and motivation. I began work began on refactoring the framework, and in late April 2006 the project was renamed poMMo -- short for "Post Modern Mass Mailing Organizer," "Penniless, Open Mass Mailing Organizer," or "Piece Of My Mother's Okra."
Thinking about starting your own FOSS project? Here are some resources and doctrines to consider.
* Use the proper tools
o Version control (SVN or CVS)
o Sourceforge.Net
o Trac
* Community Necessities
o Forums
o Mailing lists
o IRC
* Open policy
o Public mailing lists
o Trust in users
o Development roadmap
o Development blog
* Support
o Developer and user documentation
o Friendly, prompt support
* Preparation
o Be prepared to take responsibility
o Time dedication
o Timely bug and security fixes
* Eye candy
o Online demonstration/video
o Screenshots
o Nice logo
The community soon became poMMo's lifeline, and I began committing more time to the project. My developer buddies soon noticed all the time I was spending on poMMo, and asked "Why poMMo? Why not PHPList?" It's the de-facto FOSS newsletter mailer, sporting advanced features such as subscriber fax. I told them, "You'll see." I wanted to create a simpler alternative, a choice, another fish in the FOSS pool. While I certainly could have forked a trimmed-down hard-coded version of PHPList that would have worked for the band, the flexibility I envisioned in poMMo's customizable subscriber fields and filtering groups required a different architecture than what existed in all the other newsletter applications I saw.
Above all, poMMo is a collaboration effort. I'm always disappointed to hear open source project members say that they had "their developer" modify an aspect of the program without ever hearing from that developer or seeing any of the code. This is not progressive. I hope to transition poMMo development efforts to a wider group of individuals. I am always happy when others seek to help out, maintaining open discussion and policy. Admittedly, having detailed contributor guidelines and strong documentation would help, but this project is still in its infancy. We do have a game plan, however -- a vision for version 1.0.
And so poMMo development continues, as it strives to fill the niche of a simple, flexible FOSS mass mailer that the world can find utility in. We introduced the third framework rewrite in December, and that is beginning to stabilize. Rowan Walker, an Australian HTML wizard, has contributed a breathtaking theme that can be seen in the online demo. A slew of logos have been submitted, and the program has been translated to 12 languages so far. I have not asked anyone for their contributions -- they have all come out of the blue by good people around the world.
At this point the software is far from complete. The community forums and feature list grow, the bugs come and go, developers hope for donations, and downloads increment. Such is the life of a Free Software project.
Tuesday, January 23, 2007
Monday, January 22, 2007
Measuring project health: Part One
http://www-128.ibm.com/developerworks/rational/library/jan07/bittner/index.html
Measuring project health: Part One |
|
Level: Introductory Kurt Bittner,Program Director, Emerging Technologies, IBM 15 Jan 2007 from The Rational Edge: What project managers choose to measure as a gauge on performance generally receives the team's special attention. Naturally, project health depends on accurate metrics, but more importantly it requires that the right things be measured. This article describes some of the fallacies associated with traditional software project metrics, then focuses on effective measurement during the Inception phase.Most organizations use measurements in various ways to assess performance or effectiveness of various courses of action. Without measurement they have little more than subjective observation to determine whether things are on track; measurement is inevitable. But measurement is a tricky thing -- many times you cannot directly measure what you really want to know about, as in cases where you measure increases in output (productivity) when you really would like to know about effectiveness of resource utilization. There is a more subtle aspect to measurement: People pay attention to things being measured, and assume those measured things are important. Even when measurements are not directly tied to rewards, they will work to improve their performance in areas where they perceive they are being measured. Perception is key: Sometimes managers overtly say one thing and reinforce something else through measurements, effectively undermining their stated objectives. Measurement implies that the thing being measured is meaningful. Here's the point: People look to the measurements for cues about what is important. They will interpret this information, and they will often change their behavior to deliver what they think the people directing the measurement want. This effect shows itself in a number of ways -- from telling managers what they think they want to hear when asked "how is the project going?" to reporting sometimes more, sometimes fewer, hours than were actually worked, depending on whether they think working more hours than expected is a good thing (often the sign of a "hero culture") or a bad thing (working more hours than expected is sometimes a sign of a project in trouble). The best way to counter the unintended consequences of measurement is to be completely transparent about what you are measuring and why, which requires you to be completely transparent about project goals and how measurements relate to project goals. This is the first in a series of articles that addresses measurement in the iterative software development lifecycle. It describes some of the fallacies associated with traditional software project metrics, then focuses on effective measurement during the Inception phase. Subsequent installments will cover measurement during the Elaboration, Construction, and Transition phases. Before you decide what to measure, you need to decide what is important. Most organizations focus on goals that fall into three areas:
The essence of project management is to manage these trade-offs in an acceptable way to achieve the desired result. In order to do so, targets need to be set for these four areas. Most projects measure cost and time, but scope and quality affect cost and time and need to be measured as well. In fact, most measures of project success must include more than cost and time -- the delivered solution needs to do something useful (scope) and must do so with acceptable quality. "Prediction is very difficult--especially about the future." -- Niels Bohr A goal is a kind of prediction -- a statement about what will constitute success at some point in the future. Reality may fall short of the goal, or, if you're lucky, it may exceed the goal. In statistical terms, project results are random variables, and goals are estimates of desired values for those random variables. The key thing to remember about random variables is that actual observations are centered around an average, or mean value. The spread of the distribution, called its variability, indicates the degree to which observed values will vary from the mean. In a symmetrical distribution, values are equally likely to fall above the mean as below it, and the most likely value, the mode, is equal to the mean. Figure 1 shows a typical normal probability density function, so called because most observations fall into this sort of distribution.  Figure 1: Normal probability density function, which illustrates that actual observations may vary from the expected (or average) One of the key mistakes that people make about goals is that they specify only one number for a goal -- the expected value (or mean value) to be achieved. But reality is variable -- and to take this into account we need to establish tolerances for goals, within which performance is considered acceptable. Doing so is a useful exercise, because it forces you to consider the amount of variability you will find acceptable, and it will prevent unnecessary focus on minimizing irrelevant variability while maintaining focus on important variance. Measurement and iterative development One of the principal benefits of an iterative approach is that it makes a conscious effort to reduce variance over the course of the project, as shown in Figure 2 below. Note that this illustration turns the sample from Figure 1 on its side, achieving a very narrow distribution toward the end of the iterative lifecycle.  Figure 2: The iterative development approach reduces variance over the course of a project The line labeled "x" represents the expected value of an estimate, while the dashed lines above and below this line represent the expected variation around these estimates. Over the course of the project, the variation decreases as risks are retired as shown in Figure 3.  Figure 3: Risk, which greatly contributes to variance and unpredictability, is reduced over time in an iterative project Each of the four phases shown in Figure 3 -- Inception, Elaboration, Construction and Transition -- focus on mitigating different types of risks. As a result, the goals for each phase differ as well. This means that the measurements used to track progress toward project goals need to change phase by phase. Among the absolute worst practices followed by many organizations is "detailed planning, then measuring to plan." Planning and measurement, by themselves, are not bad things, but the timing employed by most organizations actually does more to encourage the wrong behavior than any other single practice. Here's what normally happens:
Why does this sort of thing happen? The problem is not planning per se, but rather planning in the absence of reality and in opposition to experience. The problem is planning in detail things that cannot be planned at all, because not enough is known, and then holding the team "accountable" for adherence to the fabrication. A better approach is to understand where the project needs to end up, and then to use flexibility in steering toward that goal continuously throughout the entire project. In order to do this, you need to be looking for the right information at different points in the project. What's wrong with detailed up-front planning? While the preceding discussion touches upon what is wrong with planning in detail at the project outset, the practice is so pervasive and such a part of the project management tradition that it needs special attention to discourage its use. Briefly, creating and managing to a detailed plan early in the project is wrong because:
So if measuring the project against a detailed project plan is not the right approach, what should be measured to ensure that a project is on track?
Deciding what to measure -- phase by phase The short answer is, you need to measure different things at different points in the project. The project can be broken into the four phases of the unified process (Inception, Elaboration, Construction, and Transition), each of which focuses on a different set of goals pertaining to their different associated risks. That is, each phase focuses on mitigating a different set of risks. But before we get to a discussion of risk, it's important to understand the broad goals we recommend for each of the phases, as shown in Figure 4.  Figure 4: Goals and objectives associated with each of the four lifecycle phases This article and subsequent articles will describe how to establish appropriate measurements to determine if the project is on track to achieving these goals. What to measure in the Inception phase The Inception phase has the following goals:
Every project needs to be funded for at least the Inception phase; funding for subsequent phases will depend on the outcome of the Inception phase. The focus of the Inception phase is on mitigating the risk that the project might be either economically undesirable or technically infeasible. For this, the team must explore the benefits and costs of the project so that a firm decision can be made about whether to proceed. At the end of the Inception phase, the stakeholders agree that the project is feasible and that the business case for the project is achievable if the project proceeds as planned. Everyone must agree that the project is viable -- that is, that the project is worth doing, and the time and cost estimates are credible. If these things cannot be agreed, then it is best to forego the project and turn your attention to more worthy projects. Measurement in this phase is focused on answering the following questions:
The first two questions are the hard ones, and will dictate the answer for the third question. In the next two sections we will discuss how to measure the business benefit and expected cost, and how to factor these answers into an overall measurement plan. The expected business benefit establishes constraints on what the business is willing to spend to obtain those benefits. At this phase of the project, precise estimates are not needed; rough estimates should be sufficient to establish that there is clear value in pursuing the project. Business benefits are usually expressed in terms of net present value, which takes into account the time-value of money obtained, as well as risk. Mathematically, it is defined as:  where the "end of the project" is really the lifespan of the solution and r is the discount rate, or required rate of return, of the project. Some attention should be given to choosing the required rate of return to make sure that it adequately accounts for the risk of the project. Typically the required rate of return is based on projects of equivalent risk. Ignoring the initial investment (covered in the next section about project cost), the business benefits are estimated by the future cash flows arising from the solution -- both the positive ones related to increased revenues as well as negative cash flows resulting from expected maintenance. Supporting evidence for the business benefit estimates usually includes market research data for new products or services, business cost data for projects focused on cost reduction, or both. As the NPV formula implies, the specific timing of the estimates is important; benefits received sooner are much more valuable than benefits received in the future. The benefits for projects driven by compliance regulations are easier to estimate. The project benefit is estimated by the penalty avoidance. The timing of the benefits of compliance is still important, however. Assessing technical viability and estimating overall project cost Obtaining estimates on the expected cost can, in theory, be obtained from parametric estimation models based on historical cost data2, but the scarcity of available data relevant to the project at hand usually means that you must build some small but representative part of the system in order to extrapolate project cost and schedule data. It helps to choose a few representative scenarios and develop the software to deliver them. Doing this will usually confirm whether or not your assumptions about the project's technical complexity are correct, even if you have to "stub out" a fair amount of the system functionality. Even if you have parametric estimation models, the early prototyping effort will help you to validate the parametric estimates. From this early prototyping effort, two main results emerge: a qualitative assessment of whether the project is technically feasible, and quantitative measures of project schedule and cost. The raw data obtained from the early prototyping is typically fed into one or more estimation models to derive cost information. Using more than one model is a useful way to cross-validate estimates -- wide differences in predictions provided by the models are signals that you should analyze your assumptions more carefully. Figure 3 presented an expected risk curve for the project, with risks peaking in the early Elaboration phase and declining afterward. Note that this curve represents the ideal risk profile you should strive for; you will achieve that only if you are actively and aggressively managing risk. There is nothing magical about the mere passage of time that causes risks to decline in number and severity. In order to bring risks under control, you must have a sense of what risks you face and when you expect to mitigate them. Many projects collect a risk list, usually early in the project; but unless the risk list is used as a key management tool, it will do little good. It is not enough to simply collect a risk list; you also need to map the risks onto iterations in an overall project plan, then later plan activities that will mitigate the risks assigned to the iteration as part of the iteration plan. In the early mapping of risks to iterations you don't need to create a detailed plan of project activities; just mapping risks to iterations is good enough for now. Doing so will give you a sense of whether you are addressing risks early enough. As you assign the risks to iterations, make sure to assign big risks to early iterations. In order to do this mapping, some exploration needs to happen in the Inception phase to even understand what risks you may face. Mapping out these risks and then making some educated guesses about what kind of work will need to happen in order to address the risks will give you a sense of what resources will be required, by iteration. Again, the goal is not to create a detailed plan but to provide a general roadmap for project staffing. This staffing model (or "map" if the word "model" sounds too formal) will provide input to the overall cost estimate by establishing timing for the costs.
Determining financial viability is usually a two-step process. First, there is often a time to market factor to consider: sometimes if a solution cannot be delivered to market within a specific time window, the project is not worth completing. If the time to market requirement can be met, then the NPV of the proposed solution is calculated. If the NPV is negative then the project is not worth pursuing. If the NPV is positive then the project may be worth pursuing, provided that it does not compete for funding with other higher-valued projects.3 Factoring risk into goals tends to be subjective and is best accomplished by increasing the variability of the estimates -- in effect, by widening the "margin for error". Most estimates in this phase are, in reality, highly subjective and can be off by wide margins. The most valuable question to ask about an estimate is not "is it accurate?" but "how wide a range of values is possible?" Alternatively, variability in the estimates can be accommodated by increasing the required rate of return for the project in the NPV calculation. Typically, a number of scenarios are analyzed to determine the expected case and the worst case values for NPV. Often the decision to go ahead with a project is based on whether the worst-case NPV is within acceptable limits. Once the solution is deployed, the estimated NPV will become important as a measure against which actual results are compared. While estimated NPV remains the most important measure in the Inception phase, other measures must be considered for those projects that will be funded:
Over the course of the project, you will need to be gathering data and comparing it to expectations to keep the project on track. You will not have a lot of data on the following measures in the Inception phase, but you need to have mechanisms in place to gather the data before you leave the phase. In all these measures, trends are more important than absolute values.
In all of these, the estimates are fairly coarse. For things like planned work, a map of scenarios onto iterations is sufficient. How to work with these measures in the subsequent phases of the project will be the topic of subsequent articles. Taken together, these initial measures, coarse as they are, provide a framework for measuring project progress and health that will be used throughout the project to determine whether the project is on track. It is worth noting that determining not to fund a project is a perfectly acceptable outcome of the Inception phase and should not be regarded as a failure so long as the decision is based on measures of the business value to be delivered and the technical feasibility. In fact, deciding not to further fund the project may be the best possible outcome if it frees resources for other more worthy projects. The goal of every project team should be to increase the probability of project success while minimizing time and cost. This general goal ties back to the general goals of the business, which are to deliver some improved capability to its customers within a desired time frame and with acceptable quality and within acceptable ranges of business value delivered. Using the right measurements will help achieve these goals by providing clear guidance to team members about what is important. Clear measures are those that are visibly tied to project performance and project health, and that actually help the team to deliver successfully. Keeping measures simple helps the team focus. And simple measures have other benefits as well: they reduce reporting overhead, and make interpretation of the measurements easier as well. Measuring the right things will encourage healthy project behavior, while measuring the wrong things is not only a waste of time and resources, but also sends the wrong message to the team about what is important. Varying the measures according to the lifecycle phases lets people focus on the risks and issues that are of greatest importance, at the time when this attention will have the greatest impact. While we say that the value of the iterative approach is to reduce project risk over time, reinforcing this message with the right measurements enables the team to put this into action. In the Inception phase, measurement is mainly focused on establishing the financial and technical viability of the project, and in so doing establishing cost and overall schedule and risk mitigation goals for the remainder of the project. Financial viability is based on analyses of market needs and opportunities, expressed in terms of cash flows over time, while technical viability is assessed through one or more prototypes that explore alternative technical approaches, as well as their costs and benefits. By the end of the phase, the information obtained from these exploration will provide the bases for a measurement framework that will be used later in the project to determine whether the project is on track. This article was drawn from material initially presented in Managing Iterative Software Development Projects, by Kurt Bittner and Ian Spence, and published in 2006 by Addison-Wesley. 1 If the reference to the albatross is confusing, I encourage you to read "The Rime of the Ancient Mariner" by Samuel Taylor Coleridge. 2 E.g., models such as CoCoMo II, Coarse-grained Wide-band Delphi (i.e., consensus-based estimates), and function point analysis (including "use-case points"). 3 Project portfolio management is actually a little more complex than suggested here, due to project interrelationships, but for now we'll leave it at this. We will return to portfolio management concerns in a later article. |
Web 2.0 marketing: What it can do for you
http://www.microsoft.com/midsizebusiness/businessvalue/webmarketing.mspx
Web 2.0 marketing: What it can do for you
Today's Web technologies offer richer, more interactive methods for midsize companies to target new audiences and measure marketing results. But you must research the options — and caveats — carefully before jumping into this fast-paced new world of marketing.
In Summary:
| • | Compared to traditional methods, online marketing is increasingly flexible and affordable for small and midsize companies. |
| • | Social networking advertising and blogs, in particular, require that you regularly update the content and concept. |
| • | Software services that track customer behavior on the Web simplify the task of measuring results. |
The advent of Web 2.0 characterizes the shift in the World Wide Web from a collection of static sites and experiences to a global space where broadband connections and multimedia applications deliver deeper content and richer interaction between individuals. Some of these Web 2.0 services and companies have appeared out of nowhere to quickly change the dynamics of Internet marketing and advertising. For example, the online video sensation YouTube was founded by two young California entrepreneurs in February 2005; less than two years later it was sold to Google (in October 2006) for $1.65 billion.
This is good news for midsize marketers, because new applications such as blogs, wikis, and online video advertising can level the playing field with larger companies, since these tools are far more affordable than traditional advertising methods. Yet, given the wide array of options, confusion reigns when it comes to selecting online marketing strategies.
A cool appraisal of the world of Web marketing can help ensure that your company spends its Internet marketing dollars wisely. The overview below provides some of the more popular online marketing methods and how you can take advantage of them.
1. Social networking sites
Characterized by YouTube, Facebook, and MySpace, these sites allow people to upload content such as videos or personal profiles. Wildly popular with young people, marketers are starting to invest in social networking advertising. (Microsoft provides the digital advertising technology for Facebook, the second-largest networking site.)
The good: Marketing on such sites helps companies reach a younger, arguably more fickle audience that is beginning to ignore traditional advertising. Unilever, for example, promotes its Axe deodorant on a MySpace page dedicated to what it calls "Gamekillers" — people who interfere with a young man's efforts to find dates.
What to watch out for: Anyone can set up a MySpace page, but it pays to keep the concept fresh, as Volkswagen learned with its 2005 launch of a profile for a character in its commercials. Already, Volkswagen marketers told The New York Times, the "Helga" profile is losing appeal as other marketers have invaded MySpace. As well, recent reports in the San Francisco Chronicle and other media indicate that members of such sites are becoming disgruntled with the way advertisers are targeting them.
2. Blogs
Online journals of commentary and chat, blogs are everywhere on the Web. The corporate world is now using them to subtly market their products or develop a brand image. Microsoft engineers blog about Windows Internet Explorer and other products, for example, while General Motors runs a blog that discusses topics ranging from auto racing to car design.
The good: Executed correctly, blogs give marketers a chance to build an informal dialogue with customers. Companies can test new product ideas, for instance, to see how customers react. Blogs are generally inexpensive, too, costing perhaps $2,000 to $5,000 for design.
What to watch out for: To be successful, marketers must spend time regularly updating blogs, which makes them a high-maintenance option. As well, blogs must be honest. Wal-Mart posted a blog about a couple traveling across the United States and parking their motor home at Wal-Mart stores. But it was revealed that the blog was a fictional story written by Wal-Mart's public relations firm, and the retail giant wound up with a major credibility problem. With blogs so common — it's estimated that 35 million of them clutter the Web — it's tough to distinguish yours from all the others. Your best bet is to drive traffic to your blog by marketing it through other channels, such as within e-mail newsletters or online ads.
3. Podcasts
Podcasts are audio programs that can be downloaded and played anytime on an MP3 player, and they can hold a user's attention like a good book. Whirlpool, for example, has developed a series of 20-minute "American Family" podcasts that cover topics such as making Halloween costumes or managing a gambling addiction.
The good: While not directly "selling" Whirlpool products, the podcasts attempt to give consumers a reason to know and like the Whirlpool brand before they shop for a washer or dryer, says Audrey Reed-Granger, Whirlpool"s public relations director, who creates the podcasts. "These are people who want to listen to good programming while in their cars, or as background when they're working at home," she says.
What to watch out for: Since marketers can only measure the number of podcast downloads, it's impossible to know whether people actually listen to them, warns Eric Weaver, director of strategic marketing for the Seattle marketing firm Girvin.
4. Intelligent press releases
These "direct-to-consumer" press releases about products or company services can be written with search-friendly terms and then placed with online news sites that index or "aggregate" them and send headlines to subscribers.
The good: A company selling marketing tools or services, for instance, might write releases with terms such as "accelerate sales cycle" to direct search-engine users to company information. Windows Internet Explorer 7.0 will create opportunities in this area, as it has features that simplify subscribing to news feeds.
What to watch out for: News feeds and releases have saturated the Internet, and it can be difficult to make your release to stand out from the rest. Make sure to invest in high-quality copywriting services, so that your press release headlines and storylines are credible, compelling, and appropriate to your customer base.
5. Targeted advertising
Search-engine advertising — where companies pay to have their Web site displayed on search-engine results — has been big for several years. But now companies can target their ads within the context of what people are reading online.
The good: Using technology and services from companies such as AdValiant, Touch Clarity, and Pulse 360, for example, a mortgage company's ads might appear in articles about home improvement or real estate. It can also target ads to readers within a geographic area, such as states where the mortgage company operates.
What to watch out for: Most targeted advertising contracts stipulate that the advertiser pays a certain fee per click. In case an ad generates a surge in clicks, be sure to set limits on what you are willing to spend without notification from the marketing company.
Measure what you do
Web 2.0 marketing has one great advantage: Technology today makes it easy to measure results. For example, through conversion-tracking services, Web traffic can be analyzed to determine how many site visitors actually do what marketers desire — read about a product, order a product, or subscribe to a newsletter. ClickTracks, one online tracking service, charges $500 for a package that measures basic activity on a Web site, according to the company's site. For companies posting blogs, firms such as BlogPulse and Technorati can help them track who is linking to a blog site and what’s being said about it.
With so many options available — and most of them priced at a small percentage of the cost of television, print, or radio advertising — experts advise experimenting a bit to determine which method or combination of methods suits your customers. With the right approach, a company can take advantage of Web 2.0's incredible reach and the opportunity it affords to connect with customers in an entirely new way.
A journalist for more than 20 years, Douglas Gantenbein writes often on technology for Microsoft. His work has appeared in Business 2.0, Scientific American, Popular Science, and other magazines.
Thursday, January 18, 2007
魂を込めずに作られたルールに意味はない。
●杓子定規に規約を守るためだけに作業するもの、目的を忘れてルールのための作業に没頭する者がいるのだ。実質的な障害は目立ちにくいが、彼らが周囲に与える悪影響は小さくない。
●魂を込めずに作られたルールに意味はない。経営書の名著ビジョナリーカンパニー２ではこう強調する。企業にとって、正しい基本的理念があるのではない。大切なのは、従業員がどれだけ基本理念に陶酔しているかだ！
●プロジェクトの目的を忘れ、形だけ当てはめようとすると、ルールのための仕事をしているようになってしまう。このような状況を目の当たりにするたび、悲しい思いに包まれる。
ブリッジＳＥとは
http://aicoach.tea-nifty.com/offshore/2004/07/post_4.html
オフショア開発中、ブリッジSEがキーマンであると思います。プロジェクト成功できるかどうかブリッジSEレベルによってかわります。
ブリッジＳＥとは
オフショア開発では、大規模なプロジェクトを通じて、大幅なコストダウンを狙います。ところが、単に費用削減を狙ったオフショア開発では、期待するほどの効果があがらなかったり、社員の定着率の悪さから事業継続が困難になるという事態が発生します。
そこで、日本と中国の文化や言葉の壁を越える鍵として、ブリッジＳＥと呼ばれる職種が脚光を浴びるようになっています。
IT Square「5分でわかるIT｜オフショア開発とブリッジSE」によると、
ブリッジSEとは、ITのスキルだけでなく言語や文化など両国間(例えば中国と日本)のビジネス習慣を熟知し、間に立って円滑に業務を進められるよう指示できるSEのことです。 SEの能力に加え、プロジェクトマネージャーとしての能力、そして言語力が求められていることが分かります。さらに、開発パートナーの指導、教育、管理が行える人材であれば、納期の厳守に加え、高品質なシステム開発が期待できます。 http://www.sw.nec.co.jp/lecture/word/offs/
ブリッジＳＥには様々な定義がありますが、本ブログでは次の通りとします。
ブリッジＳＥとは、中国ソフトウェア開発プロジェクトで日本企業と中国企業との間に入ってコミュニケーションの橋渡しをする【中国人】責任者のこと。日本のお客様と中国ベンダーとの間で、見積りやチームのスケジュール、および相互のフィードバックによる結果など全体を管理する【中国人】ＳＥ（システムエンジニア）と定義することもできます。
最近では、主に日中間を結ぶブリッジSEの人材派遣サイトが登場しているようです。
本ブログの定義に従うと、ブリッジＳＥはプロジェクトの勘所を押さえる重要な役割が期待されているため、人材派遣サイトから簡単に調達できるような職業ではありません。
一般的なブリッジSEへの期待事項
・ 日本語と中国語が両方できること
・ プロジェクト管理や設計業務
中には、「主に中国とのオフショア開発における契約内容の把握、スケジュール管理、要員管理、リスク管理によりプロジェクトを推進」という要求もあるようです。
正直なところ、このような高度な職務を遂行する中国人ＳＥにはほとんどお目にかかったことがありません。本当に優秀な中国人は、すでに副総経理クラス(会社役員）の重責を担っています。
つまり、会社経営に忙しくて、特定プロジェクトを担当するブリッジＳＥとして採用するのは非常に困難であるといえます。
これまでは、「ブリッジＳＥ」という職種だけが先行して実態が伴わない状況が続いていましたが、今後はプロジェクト成功に貢献する本物の橋渡し人材が求められます。
-------------------------オフショア開発中、ブリッジSEがキーマンであると思います。プロジェクト成功できるかどうかブリッジSEレベルによってかわります。
第1回 WhyとHow、どちらで悩みますか？
http://jibun.atmarkit.co.jp/ljibun01/rensai/eh01/eh01.html
第1回 WhyとHow、どちらで悩みますか？
野村隆
2005/3/2
| 将 来に不安を感じないITエンジニアはいない。新しいハードウェアやソフトウェア、開発方法論、さらには管理職になるときなど――。さまざまな場面でエンジ ニアは悩む。それらに対して誰にも当てはまる絶対的な解はないかもしれない。本連載では、あるプロジェクトマネージャ個人の視点＝“私点”からそれらの悩 みの背後にあるものに迫り、ＩＴエンジニアを続けるうえでのヒントや参考になればと願っている。 |
■ITエンジニアの経験年数と悩みとの関係
ITエンジニアとしてのキャリアは何年になりますか。連載の第1回の冒頭としては乱暴か書き方かもしれませんが、皆さん、いかがですか。
3 年以下であれば、悩みはまだ少ないでしょう。石の上にも3年とはよくいったものです。まずは3年を目安に無我夢中でキャリアを磨いてください。3年持たな い人はエンジニアに向いていないのでしょう。多くのITエンジニアを私は見てきました。その中で、ITエンジニアとしてイマイチだったと感じた人が、営業 や人事など、まったく別の職種で大活躍している例を多く知っています。ITエンジニアとしてのキャリアをあきらめることは恥ずべきことではありません。自 分の進むキャリアを思い切って変えて、自分に向いた職種を探すことの方が大切なことです。
ITエンジニア歴が3～5年程 度になると、見えない壁に当たって悩み始めている人が多いかもしれません。そういう人は、これまでの数年間で自分が磨いてきたスキル、例えば、コンピュー タ言語、ミドルウェア、パッケージソフト、ハードウェアなどの知識やスキルといった何かが身に付いたでしょう。その身に付いたスキルを使う作業で、仕事上 1回区切りがつき、次のキャリアというか専門領域に踏み込むときに悩みが表れることもあるかと思います。
それは次のような悩みです。いままで磨いてきたスキルをそのまま生かした道を進むべきか、それとも別の路線のスキルを磨くべきか。
せっかく磨いたスキルだから生かしたい。が、磨いたスキルそのものは、IT業界でいつまでも重宝される保証はありません。だからこそ、悩み始めるのだと思います。
そしてITエンジニア歴が5～10年程度の場合は、悩みはより深くなっていることがあるのではと思います。30代前半くらいから、いくつかの専門領域を 持ったが、このままITエンジニアとしてスキルを積んでいく人生が正しいのか、それともマネージャや課長といった管理職としてのスキルをつむことが正しい のか？ 後者のスキルを会社からも求められることが多い中で、自分の進むべき道が見えなくなってしまうことがあると思います。
こうした悩みは、ITエンジニアの先輩に聞くまでもなく前からあった話です。ただ、技術革新の速度を考えると、悩み始める時期がより早くなっているのでは ないかと思います。しかし、そうしたことを前提にすべきでしょう。技術革新の波のスピードは止めようがなく、スピードに抗うよりはむしろ、そうしたスピー ドを前提として、自分自身のキャリアのことを考えないと精神的にも、キャリア的にも持たなくなっていると感じるからです。
つまり、ITエンジニアにとって悩み多き時代になっているのです。IT業界のエンジニアは程度の差こそあれ、皆悩んでいるのです。
では、悩み多き時代をいかに乗り切ればいいのでしょうか。悩みの根本原因を理解して、対応を考えないと対症療法で終わります。そこで、悩みの根本原因について考えてみましょう。
■悩みの根本原因：現状を打破したいが……
多くの人は次の図1に表したように、図の右と左のどちらに進むかを悩んでいるのです。
 | ||||||||
| 図1 悩みの図。右に行っても左に行っても不安になる しかし、どちらに進むにしても悩みから解放されるわけではありません。そもそも進む方向が決まっていれば悩みはないわけですが……。 ITエンジニア（技術系）に進む場合は、以下のような不安があると思います。
プロジェクトマネージャ（プロマネ。または管理系）に進む場合は、以下のような不安があるでしょう。
現状を打破したい、だけど何をしていいのか分からない、という人は多いでしょう。 この場合、ITエンジニアとしての成功体験に引きずられて、常に技術中心に考えてしまうのではないでしょうか。だからといって、自分がスーパー技術者で、 ほかの技術者よりもはるかにエンジニアとして優れているか、というとそういうわけではないでしょう。ITエンジニアとして今後10年、20年やっていく絶 対的な自信、論理的な根拠もないでしょう。 これらは結局、いったい自分は何になりたいのか、どうありたいのか、という根本的な疑問を抱えてしまっているわけです。 ■株の取引で重要な考え方ここでちょっと話題をかえて、株の取引の話をしましょう。 インターネットを活用した株の取引が盛んです。例えば日本経済新聞には個人投資家のことを伝えるニュースが毎日のように掲載されています。さらに、各種週刊誌には「注目銘柄100選」や「ボーナスで買いたい値上がり銘柄50選」といった記事がよく掲載されています。 株式投資においては、週刊誌の注目銘柄を読んで投資するような、Howに固執した「初心者」は負けることが多いでしょう。短期的な金もうけしか考えない、 つまり投機的投資をしている限り、偶然、1回や2回は勝つでしょうが、結局いつか大負けして、結果として損をします。初心者にとっての株式投資は、宝くじ を買っているのとあまり異なりません。How To本とか雑誌のお勧めに従って株を買って、株価が上がることを祈っているだけです。1回1回の取引の勝ち負けに一喜一憂しているわけです。 つまり「初心者」はHowに固執しているといえます。 一方、「株式投資のプロ」は機械的に利益を得ようとします。期待収益が計算されており、リスクを数値化して管理・マネージしているのです。いい方を換える と、株に期待する収益を理解しているので、株でここまでもうけよう、例えば、10回取引して取引元本に対して10％の収益を実現しようといったことが管理 されているのです。 なぜ株を買うのか。それは期待収益10％を実現するため、というWhyがしっかりしているのです。 そうなると、「株式投資のプロ」は1回1回の取引の勝ち負けはあまり気にならなくなります。10回、20回という取引のトータルでの負けの金額を少なくし、勝ちの金額を増やすよう、確率を管理するのです。つまり、損をマネージしているから勝つといえるでしょう。 整理すると、「株式投資のプロ」は、なぜ株を買うのかを理解している、Whyを把握しているので、「マル秘の注目銘柄100」とか「ストップ高間違いなしの20選」というような、本質的でない、表層・小手先のHowに固執しないといえます。 ■技術ではない軸を考える：HowではなくWhy話をIT業界に戻しましょう。IT業界においても、How To本は世の中にあふれています。やれ「Excel」や「Word」の入門本から始まって、Java、ネットワーク、データベースなどのHow To本はたくさんあります。 確かに手先の技術は重要です。ITエンジニアとしてIT業界にいる以上、ITに関する何らかの技術を持っていなければならないでしょう。開発プロジェクト を進めるうえで、「私は頭がいいですが、ITスキルがありません」という人がいたとして、そういう人と仕事がしたいと思いますか（新人などの場合は別とし て）。そういう人がシステム開発プロジェクトで戦力になるでしょうか。答えはノーです。 しかし、テクニックに依存していると、手先のテクニック、つまり、Howに振り回されるようになります。株式投資の「初心者」と同様、Howに固執してしまうと、結局、Howを追い掛けるだけで、いつまでたってもHowを永遠に求めるだけになってしまいます。 前述の、悩みの図では、手先のテクニックを右側のプロマネに求めて会得するか、左側のエンジニアに求めて会得するかの違いでしかありません。Howを追い掛け回して終わりなき旅を続け、いつまでたっても不安は解消されません。 そうではなく、Whyの軸、なんでこんな仕事をしているのだろう、という軸を考えましょう。図示すると、悩みの横軸をHow、それに対して、縦軸にWhyの軸を入れた図となります（図2）。
■Whyを求めれば将来への悩みは解消されるIT 業界におけるWhyは、例えば、システム開発プロジェクトを成功させよう、パッケージ開発事業を成就させよう、企業の成長に貢献するシステムを作り上げよ う、という意識、つまり、ITビジネスを成功させるための前向きな考え方です。なぜかというと、ビジネスの視点からすると、ITの手先の技術はあくまでも 手先の技術であって、ビジネス成功のための手段でしかないのです。ITビジネスを成功させるという意識を持っていないと、手先の技術が目的となってしま い、目的と手段を取り違えてしまいます。目的と手段を取り違えてしまうと、いつまでも本質的なことが理解できません。 冒頭にも書いたように、ITエンジニアとして最初の3年くらいは何も考えず、エンジニアとしての道を求道すべきです。このときは、技術取得が目的であってもいいでしょう。Howにこだわる時期です。それはそれで構いません。 経験を重ねるに従い、いつかのタイミングで、Howだけでなく、Whyに気付いて、Whyの方向に向かって自分のキャリアを積むよう志向しなくてはいけま せん。ITの研究開発に従事するごく一部の純粋なITエンジニアを除き、ビジネスマンとしてIT業界に身を置くITエンジニアは、経験年数を積むに従い、 How以上にWhy、つまり、手先の技術よりもITを活用したビジネスの成功への意識付けを持たなくてはなりません。換言すれば、そういう意識改革がなさ れれば、Whyを求めるという方向性が明確化されるので、ITエンジニアとしての将来への悩みは解消されるでしょう。 ■WhyとHowの座標軸WhyとHowの座標軸という考え方を活用すると、例えば、Why志向の前向きな人は、エンジニアの方向に進んでも、プロマネの方向に進んでも、あまり変わりがないということがいえるでしょう。図示すると図3のようになります。
方向性としてWhy志向なので、ITビジネスの成功に向けたキャリアを形成しています。ある意味、エンジニアとしてもプロマネとしてもあまりスキルを身に 付けていない（横軸のHowの軸で進歩が少ない）という難点がありますが、管理職、特に上級管理職として一定規模の組織をリードする人はこういうキャリア を今後志向するべきでしょう。 まだ若い人、管理職手前の方、若手管理職の方は、以下のような曲線のキャリアをイメージし てみてはどうでしょうか。つまり、近いうちはエンジニア、またはプロマネとしてのスキル――横軸のHowのスキルを身に付けます。ただし、一方での、IT ビジネスの成功という縦軸のWhyを忘れずに日々ちょっとずつでも縦軸のスキルを伸ばし、いつかのタイミングで縦軸志向にシフトするという考え方です（図4）。
こういうキャリア曲線をイメージしながらキャリアを積むことができれば、技術者としてのキャリアに関する悩みは減るのではないかと思います。主要な理由は以下のようになるでしょう。
皆さんの理解を助けるために、あえて後ろ向きの考え方を書きましょう。 皆さんの身の回りに、以下のようなキャリアパスを歩んでいる人はいませんか。例を挙げると、技術スキルが低く、やる気もないけど成り行きで会社に残ってい る20年選手のSE（左下に向かっている矢印の例）とか、管理スキルが低く、プロジェクトにおいて何かといい訳を探しては遅れを報告し、保身に回りながら 他人のアラを探して他人の足を引っ張るダメ課長代理（右下に向かっている矢印の例）とかにありがちなキャリアパスです（図5）。
こうなってしまっては、縦軸のWhyの軸でポジティブな領域に戻るためには結構な時間がかかります。それはそうでしょう。何年も、場合によっては10年以 上かけて、後ろ向きの根性を持ち続けてきたわけですから、ITビジネスの成功という前向きな気持ちに戻ることは大変な苦労でしょう。何も色の付いていない 若手は、縦軸のWhyについてゼロからの出発となりますが、こういう人は、縦軸のWhyの意識改革はマイナスからのスタートとなるわけです。 ■悩み解消への考え方どうですか。HowとWhyの違いはご理解いただけましたか。Whyの軸の重要性を把握できましたか。 前向きな態度なんて格好悪い、そんな時代じゃないんだよね、というシニカルな方、いつまでたっても新入社員ではないのですから、斜に構えた態度はやめましょう。もっと前向きに、自分の仕事として、IT業界での仕事を考えましょう。 IT 業界でのエンジニアの悩みは、Whyの軸を伸ばせばいいのだ、とシンプルに考えましょう。物事を難しく考えると、できることもできなくなります。さらにい えば、物事を難しく考える人は、自分が失敗したときに、「理論が難しかったからできなかった。」といういい訳ができるから、という理由で物事を難しく考え るのではないでしょうか。シンプルに考えましょう。自分にいい訳をするほど格好悪いことはありません。 Howばかりが多い世の中で、Whyの軸を考慮に入れ、エンジニア（技術系）に進むにせよ、プロマネ（管理系）に進むにせよ、Whyの軸で常にポジティブであり続けるよう留意しましょう。 では、今回のトピックはここでオシマイにします。次回からは、具体的にどうやってWhyの軸においてポジティブになるかについて、具体的に考えていきます。 |
Subscribe to:
Posts (Atom)
ブリッジSEレベル
◇一般
基本能力
◇良い
基本能力＋管理、提案能力
◇とても良い
基本能力＋管理、提案能力＋戦略的な能力＋人間関係
------------------------
→基本能力
・設計スキル
・日本語の会話力
・日本語の読解力
・日本語の作文力
→管理、提案能力
・プロジェクト管理能力
・見積の作成能力
・提案能力
→戦略的な能力
・調整力
・開発作業を自分がやるより他人に任せる
・性格
例えば：相手の考えを聞き、相手の立場で考える
…
→人間関係
-------------------------------------皆さんの内容を拝見して、日本のブリッジＳＥって、まるでスーパーマンのように感じています。
今の中国では、このようなブリッジＳＥは恐らくいないだろうと思っています。
なぜかと言うと、
・プロジェクト管理能力
・見積の作成能力
までの能力を備えている人は、皆部長とか、少なくとも、ＰＭになっているからです。
ブリッジＳＥが進捗管理、見積、リスク予測まで担当すると、ＰＭの仕事はどうなるだろう。
私が思っているブリッジＳＥは極簡単です。
ブリッジＳＥ＝ブリッジ＋ＳＥ
ブリッジ：
・日本語の会話力
・日本語の読解力
・日本語の作文力
・人間関係
ＳＥ：
---------------------------------------------・用件分析能力
・提案能力
・設計スキル
発注者側からのＢＳＥに対して
マネージメント力
技術力
コミュニケーション力
リーダーシップ
など、多くのスキルを期待していると思います。