プロジェクトの成功とは？

先日、社内で

プロジェクト成功の定義は？

という議論をしました。

アジャイルやリーンとしては「価値提供」かと思います。

素早く、価値を提供出来る事が成功かと。

これをもっと具体化した目標値が達成出来れば、

成功かと思います。

議論では、

問題があっても対応出来ていれば成功

イテレーションが回せていれば成功

などなど。

どれも成功だと思いますが、

議論になるという事は、

成功基準をプロジェクト開始前に決めていない証明でもありますね…

しかし、プロジェクトとしては成功しても、

エンジニアとしては納得行かない点も多くありそうですね。

あそこは、あーしておけばよかったー

とかとか

設計視点や、コード視点など、

それぞれ視点を変えると、後悔が無い事の方が少ない気もします。

プロジェクトとしての成功

個人としての成功

などなど、複数の定義はあってイイ気がしますね！

しかししかし、改めて考えると目標達成と後悔は違いそうですね。

目標は達成しても後悔する事はありそうです。

目標値はあくまで目標値で

完璧な仕事というか、完璧な業務というか、

後悔のない仕事というか、後悔のない業務

は難しいですね。

改めて、

目標以外の視点で「ふりかえる」事も大事ですね。

ヒアリングの違和感

仮説を立てて、聞くではなくて、

仮説を立てて、見せて、見る

昨年あたりから、

ヒアリングは何かが違う気がしています。

単純にインタビューのテクニックが無いだけとも言えますが…

何か、違和感がずっとある状態です。

そして、最近、再度『アントレプレナーの教科書』を読んで、

顧客開発のファーストステップである

顧客発見フェーズでのヒアリングが違うのかな

って、思い始めました。

顧客発見フェーズにて、

発見できた顧客や支援者に対してのヒアリングは問題無い？

いや、ここはまだ分かりません。

発見した顧客へのヒアリングは

相手も本気で回答する可能性は高い気がします。

ただ、これまでのヒアリング経験では、

相手が本気で考えていないというか、本気で答えていない気がしています。

フォーカスも合っていない感じがありました。

いまは、それよりも、

動くものを見せて、相手の反応を見る

方が収穫が多いと感じています。

相手の本気度も分かり易くなるというか、

事実が発見し易くなるというか、

フォーカスも合っている感じがします。

いや、フォーカスが合っているか、ずれているかが分かり易いだけかもしれません。

具体的な話になり易い気もします。

この点ですかね。

違和感は。

もちろん、どちらも仮説があるのは前提条件です。

ヒアリングより、見せる＆見る　

問いかけるより、見せる事、

聞くより、見る事

そのほうがフォーカスも合い、具体的な話になり易い。

もしかすると、ヒアリングも基本は、聞いて、相手の反応を見る

という事なのかもしれませんが…

この違和感、もう少し考えたいと思います。