Organizing by Customer Value
Opened this issue · 1 comments
Organizing by Customer Value 顧客価値による組織化
In a small one-team product, organizing by customer value is trivial. The more teams, the more they become like cogs in the large development machine. Like Charlie Chaplin in Modern Times, their jobs is to turn screws but have no idea how the customer will use the product… or who that customer actually is. How to scale and keep a customer focus?
小さい１チームによるプロダクトにおいては、顧客価値による組織化なんてとるにたりないものだろう。より大きなチームでは、大きな開発マシンの歯車になったようになっていく。チャップリンの「モダンタイムス」のように、我々の仕事は回転させることに必死になり、顧客がプロダクトをどう使うか、はたまた実際顧客が誰なのかなんてことは全く考えなくなってしまう。どうやってスケールさせながら顧客にフォーカスを当て続けられるのだろう？
Cross-functional Teams 機能横断チーム
Having cross-functional teams is important for keeping the customer focus. With functional specialized departments, we create process-steps and the previous person in the process becomes “our customer”. But these internal customers are not real customers. With cross-functional teams, we change the whole perspective and give an item to the team and let the team as a whole focus on a customer-centric feature. The team, being in a short time-period will need to figure out how to parallelize the work done within the Sprint period… and keep their customer focus.
機能横断型のチームを持つことは顧客にフォーカスし続けるために重要である。機能特化した部門では、我々はプロセス-ステップを作ってしまい、全工程のプロセスにいる人が「私たちの顧客」になってしまう。しかし、社内の顧客は現実の顧客ではない。機能横断型チームにおいて、我々は全体の見え方を変え、１つのアイテムを１つのチームに与え、チームを顧客中心のフィーチャーに集中させることができる。短い期間にいるチームは、スプリント期間内にどう仕事を並走させながら終わらせるかに集中しなければいけないし、顧客にフォーカスし続けなければいけない。
Feature Teams フィーチャーチーム
Like with cross-functional teams, feature teams focus on the customer and is a way of organizing around customer value. Feature teams take a customer-centric feature and “do it all.” It allows the team to speak the same language as the customers and to remove the barriers between customers and actual users… much less hand-offs.
機能横断型チームのように、フィーチャーチームは顧客にフォーカスし、顧客価値を中心に組織化する手段である。フィーチャーチームは顧客中心の機能を扱い、その全てを実行する。チームは顧客という同じ言語を話、顧客と実際のユーザの間にある障壁を取り払うようになる。無干渉主義はずっと少なくできる。
Specialize in customer dimension
A common misunderstanding of feature teams is that it means abandoning specialization altogether. Part of this misunderstanding comes from the false dichotomy between either specializing in one component or not specializing at all—which we’ve covered extensively in our writing on feature teams. Part of the misunderstanding comes from the belief that specialization is a one-dimensional thing—specializing in a component. But specialization is multi-dimensional.
フィーチャーチームに関するよくある誤解は、専門性というのを完全に諦めなければいけないというものだ。この誤解の一部は、一つのコンポネントへ専念するか全く専門化しないか、という誤った対立から来ている。また誤解の一部は、専門化というのは１次元、つまり１つのコンポネントに専門化するのだという信じられてることから来ている。しかし専門化というのは多次元なのだ。
LeSS brings users and developers closer together because the user-perspective is almost always lost in traditional large product groups. Feature teams are one way of organizing by customer value but not the only one. The principle of preferring specialization in customer domain also leads to other structuring decisions. For example:
LeSSはユーザと開発者を近づけてくれる、なぜならユーザ視点は伝統的な大きなプロダクトグループでは常に見失われてしまうからだ。フィーチャーチームは顧客価値によって組織化する一つの方法であるが、唯一の方法というわけではない。顧客ドメインの中で専門性を志向する原則は他の構造的な決定を促してくれる。例えば、
Banks create mobile apps for banking services on mobile devices. The product groups are typically organized by platform: (1) the IOS teams, and (2) the Android teams. These teams are feature teams and they are specialized in the technical dimension—namely, the platform. Alternatively, they can be organized in customer domains such as (1) mobile payments, (2) admin, and (3) reporting. This leads to the teams implementing the same type of features on multiple platforms instead of implementing many types of features on one platform.
銀行はモバイルデバイスで銀行サービスを提供するモバイルアプリケーションを開発している。開発グループはよくプラットフォームごとに組織される：(1)iOSチーム、(2)Androidチーム。これらのチームはフィーチャーチームであり、技術的な次元、すなわちプラットフォームにおいて専門化されている。一方、顧客ドメイン、すなわち(1)モバイルペイメント、(2)管理、(3)レポートといった具合に組織化することもできる。これはチームが一つのプラットフォームに多くの種類の機能を実装する代わりに、複数のプラットフォームに同じ種類の機能を実装することになる。
Which specialization dimension is better? Traditional organizations tend to specialize in technology dimensions. Why? Perhaps that is perceived as more difficult and hence specializing in that dimension leads to faster development? But in LeSS we prefer specialization in the customer domain to increase collaboration with real users and remove hand-offs.
どの次元で専門化するのがベターなのか？伝統的な組織では技術面で専門化する傾向にある。なぜか？多分、その方がより難しく、したがってより早く開発できると感じられるからでないからだろうか。しかしLeSSにおいては、より現実のユーザとコラボレーションができ、無干渉主義を排除できる顧客ドメインに専門化することが好まれる。
The assumption in traditional organizations is that specializing around technology is ‘better.’ But is this true especially as the industry matures (and ages) and polyglot programming is common? And is it true from the customer perspective? Scrum and LeSS have a tendency to prefer specialization into the customer dimension.
伝統的な組織においては、技術周りの専門化がよりよいという推測がある。しかし、産業が成熟し、多言語プログラミングが当たり前の状況においてそれは本当なのか？そして顧客視点においては本当なのだろうか？スクラムやLeSは顧客面に専門化することを好む傾向にある。