会議時間と開発時間の節約の間には関係要素がありますか?


10

私はプロジェクトに取り組んでおり、定期的(通常は毎週)の非公式の会議を開いて、プロジェクトのステータスとGUIについて話し合っています。

私はそこにいる唯一の開発者です。他の4〜5人はIT以外の経歴を持っています。

この会議にはいつもより長い時間がかかりましたが、ある時点で、私の同僚の1人がプログラムのいくつかのフィールドと、それらがどのように満たされるかについて質問しました。私は答えて、私が気付いたディスカッションで、私のプロセスは完全に間違っていると思いました。

しかし、それについて事前に話し合ってエラーを見つけたので、かなり迅速に変更できます。

このことを考えながら、開発時間を節約することに関して、会議時間の間に要因があるかどうかを自問しました。

たとえば、会議時間を1分にすると、開発時間をX分節約できます。

もしそうなら、これは私たちの会議がどれくらいの頻度でどれくらいの長さであるべきかを定義するのに役立ちます。

(明確にするために:会議の長さを大まかに決定することさえできても、より良い会議をしたくありません。会議時間と開発時間の間に関係がある場合、私は主に興味があります!質問の理由:好奇心! )


他の方法と比較して、会議で理解し、理解を確認できる要件はどれくらいありますか?
JeffO 2016年

@JeffO:他にどの方法を参照していますか?
hamena314 2016年

「要件を理解したと思ったが、ミーティングで間違っていたことがわかった」というのは、ミーティングを増やす必要があるという意味ではなく、組織が要件定義プロセスを改善する必要があるということです(そうですね、それはと言う方が簡単です)。
SJuan76 2016年

数百万年の進化の後、人間はまだコミュニケーションにひどく失敗しています。会議の成功は、参加者のコミュニケーション能力に依存します。理解の「能力」も。優れたコミュニケーターによって行われる同じ会議はあなたに多くの時間を節約でき、私の現在のプロジェクトマネージャーのような誰かによって行われるまったく同じ会議はあなたの時間を浪費するでしょう。そして会社にたくさんのお金。IMO要因はありません。
ライヴ

他のドキュメント、図、電子メール、またはその他のミーティング/ワンワンワンセッションを取得していますか?
JeffO 2016年

回答:


14

「彼らが必要である限り、もはや。」

ここで気づくのは、節約された開発時間までのミーティング時間は決して直線的ではないということです。チーム、会社、このトピックの場合、1時間の会議で2時間の開発作業を節約できます。10時間の会議がある場合、さらに1時間の会議で開発作業を0節約できる可能性があります。地獄、それはあなたの中断や士気への影響が原因で-2時間の開発作業を節約するかもしれません。

結局、会議の全体のポイントは、コミュニケーションとコラボレーションが物事を成し遂げるのに役立つということです。会議があなたが物事を成し遂げるのを助けていないなら、彼らは殺されるべきです。


6

ではない正確に。

顧客/利害関係者を理解することで、開発時間を節約できます。そして、会話は理解を容易にするのに十分な長さである必要があります。ただし、すでに理解していると思われる機能について話し合っても、必ずしも理解が向上するとは限りません。

部屋の誰も誤解や誤った仮定の疑いがない場合は、部屋を出てください。剪断時間と圧力が対立を押しのけて調和を生み出すことを期待して、「議論」を人工的に長引かせることは絶望的で士気をそそります。

また、コミュニケーションはスキルと運の組み合わせであることを忘れないでください。議論は必ずしもコミュニケーション(相互理解)を意味するものではありません。現場で作業する時間が長くなるほど、また一緒に作業する時間が長くなるほど、悪い仮定を明らかにするのが上手になります。

それまでは、「敏捷性」が役立ちます。

「短い」会議をキープし、粗UIのモックアップや実装できるだけ早くを各会議の後に-あなたもうまく前に容疑者の完全な理解を持っています。UIやモックは、誤解を明確にするための資料として役立ちます。会議間の時間は、誰もが解凍し、言われたことを反省するのに役立ちます。また、ショーアンドテルの資料をコードで実装すると、開発も実際に開始されます。(そして、あなたの顧客/同僚はこれを聞いて興奮します!)

そして、最悪のシナリオは、目に見えるコードの小さなチャンクを実装したときです。完全にベースから外れていて、それを捨てます。しかし、もしあなたが少しの時間しか捧げなかったなら、投資は大きな誤解を明らかにすることで大きな利益をもたらします。

また、会社は開発時間を気にしません。それは人の時間を気にするだけです。総コストを計算する手段として、気をつけてください。)したがって、人の時間を最小化するバランスを探す必要があります。コードの作成に費やされた時間ではありません


3

そこには一般的に適用できるような相関があるとは思いません。それは、会議と、開発に関連してそこで行うことによって本当に異なります。

あなたが説明する状況では、数分で、悪いまたは不十分に理解された要件から、より良い要件に移行しました。要件が適切であることは、開発時間に直接的な影響を与えることがわかっています。

しかし、あなたの会議が会社のステータス会議のようなものだったらどうでしょう。良い情報を共有して、会社の状況を把握したり、他の状況を把握したりします。ただし、ほとんどの場合、プロジェクトの開発時間には影響しません。開発の観点から見ると、その間ずっと「無駄」でした。

十分な会議に参加しなければならない場合、いくつかは本当に生産的であることに気づき始めます(たとえば、小さな開発チームと適切な要件のセットを取り、アーキテクチャのホワイトボードを開始します。 。)。また、まったく生産的ではない、または生産性が低下しているものもあります(顧客がログインページに「ログイン」と「ログオン」のどちらを表示するかについて15分の議論があった場合、その終わりに、誰も知らなかった、そしてそれは後でまでテーブルに置かれなければならなかった)。

TL / DR:会議、人、会議の目的によって異なります。


「ログイン|オン」の部分はお馴染みのバイクシェディングの
hamena314 '25
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.