初めての上流工程

感想

上流工程の仕事を知ることで、メンバー(自分)がどういう行動をするとプロジェクト的に良くないかを知れた。そうならない行動を今後心がけようと思う。

自身の担当する仕事だけではなく、プロジェクト全体を把握してどういう人が何をしているかを知った上で働ければ、自身の仕事がどういう目的か、何をするのかをよりはっきりと認識して働けそう。

プロジェクトやシステムが何を目的として動いているかを知ることでどういう行動を取ればいいかはっきりすると思う。手間を惜しまずにドメイン知識をつけるべく質問は多くしていきたい。

設計の順序

客が提示する課題を深掘りし、見える要求から見えない要求までを見つけだし、原因を見つけ分析し解決策を考え出してからその解決策をプログラムで作り上げる

見積もり

3時間以内のタスクまで分割するとやりやすそう

必ず最初に提示した見積もりを順守する、というよりは、早めにアラートを出すことの方がまとめる人からしたら重要

バッファを含めるのは必須(どこにもそう書いてあった）

要件定義がしっかりできていないと、実装者が本当の目的を知らないでコードを書き進めてしまう可能性がある

目的が「応募者を手作業で集計していたものをシステム化する」、手段が「応募方法を電話・葉書を無くしてWebからの申し込みだけにする」の場合

集計するデータ（どういうデータが）欲しいのかを把握しないとバラバラな集計結果しか集められなくなる

Web以外の申し込み方法があるならWebでの申し込みに穴があってもいいか。と考える可能性がありそう

「目的」を共有することが大事

何のためのシステムなのか知っているのと知らないのとでは作るものが変わってきそう

遅れやできないを隠して進めてしまい、後で発覚することで問題になってしまう（設計に限らず）

成果物をあらかじめ念頭に置いておくとわかりやすそう

今までPMなど取りまとめる人が何をしているのかをあまり知らなかったが、PMの仕事を知ったことで、自分自身が取るべき行動や影響がわかった

どういう行動が求められるか

進捗遅れなどのアラートを早めにあげること

やってみてできないことを早く白状すること

プロジェクトにどういう影響を与えるか

アラートが遅れることでプロジェクト全体が遅れてしまう

会社の信頼を失墜させてしまう可能性

要求をヒアリングするにあたり、顧客と開発サイドで知っていることが異なる

お互いに、自分たちが知っていることを相手側も知っているとは思わないこと

自分が「知らない」ことを知ってもらうこと

実際にヒアリングを行う前にヒアリングでの成果物を想定する

ヒアリング会議の冒頭で共有する

代替案を考えること、それを却下されることでより一層理解が深まる

手持ちの道具が限られてると、その道具で解決できることしか想像できない

担当している機能など、細かいものよりも、システム全体やシステムの目的に目を向けて開発にあたる