skillup

技術ブログ

プロジェクト管理

KPT法について

投稿日:

プロジェクトを進めていく上では、いいこと、悪いこと様々あるかと思いますが、

  • よかったものは続け(Keep)、
  • 問題点に関しては直視し(Problem)、
  • 改善を試みる(Try)

のが良いかと思います。上記をKPT法などというようです。

プロジェクトの進行区分となる、ある程度短い期間(2、3ヶ月)で行うのが適切かもしれません。

以前のプロジェクトでもありましたが、年1とかでやっていたのと、振り返ろうにも散々問題が出尽くした後だったり、振り返った後、メンバーの大部分が入れ替わってしまって効果が薄くなってしまった・・・などの経験がありました。

フィードバックが生きるレベルの期間で行うことが大切ですね。

さらに改善案に関してはメリット、実行難易度(コスト)、優先順位などを考えておくと良いかと思います。

改善案の全てが実行できるわけではないので、実行難易度が低く、メリットが大きいものが優先です。

-プロジェクト管理

執筆者:


comment

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

関連記事

no image

障害報告などでの伝える情報の視点

障害の重要度(後続タスクにブロックがあるかいなか)、調査原因(仕様不理解、設計考慮もれ、ケアレスミス)、影響度(画面単位などで) 障害が起こっているデータ(あるいはスクショなどで伝えられるか) 再現プ …

no image

プロジェクトにおける改善(主にコミュニケーション関連)

今まで複数のプロジェクトに参加してきましたが、そこで大切なコミュニケーションについて書かせていただきました。 コミュニケーションって言葉、多義的であまり好きではないのですが(汗)現実的に伝わりやすいた …

no image

アジャイル開発について

エンジニアとして仕事をしてから7〜8年立ちましたが、その間9割近くはいわゆるアジャイル開発でやってきたと思っていました。今は比較的大規模な開発をしておりますので、ウォータフォールですが・・・ が、先日 …

no image

テスト分類について

一般的なテスト工程での分類や個人的に大事だと思うこと Contents1 全プロセス共通1.1 テストデータ作成バッチ1.2 ローカル、開発、ステージング、本番の分岐2 PT(プログラムテスト)、単体 …

no image

ドキュメント作成(要件定義〜設計)のポイントについて

4月から新しいプロジェクトが始まり仕事がドキュメント作成(要件確認書、基本設計、詳細設計)などをしております。この仕事自体が自分にとってあまりなじみのないものだったので、そこで思ったことなどを。 Co …

アーカイブ