サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
ブックレビュー
luckyman.hatenadiary.org
まずは業務経歴書の裏付け確認から。 ・過去に携わった業務の説明(最近のものから)。 ・各プロジェクトの期間。 ・各プロジェクトの規模(総工数、在籍時の人数等)。 ・各プロジェクトにおける立場、役割。 ・各プロジェクトで担当した工程(設計、プログラミング等)。 ・各プロジェクトの開発環境。 ・各プロジェクトで使った技術。 ・各プロジェクトで修得した技術。 ・各プロジェクトで失敗したこと。 ・各プロジェクトで経験して良かったこと。 次に人物評価。 ・技術者として抱いている夢。 ・どんな技術者になりたいか。 ・仕事をする上で気をつけていること。 ・趣味は何か。 ・休みの日は何をしているか。 ・今何に不満を持っているか。 ・不満に対してどのように解消しようとしているか。 ・今何を勉強しているか。 ・どんなジャンルの本を読んでいるか。 ・最近読んだ本は何か。 ・定期購読している雑誌はあるか。それは何
出来ない理由を鵜呑みにしない。出来ないと言った相手が良く調べていないのかも知れない。思考が停止し、考慮が不足しているのかも知れない。諦めず、食い下がろう。 仕様書は契約書のようなもの。詳細に記述し、委託者と受託者が十分な時間を取って確認する。 要件確認リストを使い、可能な限り要件漏れを無くす。 要件定義書をユーザと共にレビューする。 早期の段階でプロトタイプを作り、イメージを確認する。 変更が見込まれる機能は可変化する。 現場を見学し、現場の声を聞く。出来れば業務を体験させてもらう。 事前に技術検証をしておく。 不明点はユーザに必ず確認を取る。その際、解決策をいくつか用意しておく。 全体の整合性はレビューで防ぐ。 余裕があれば、仕様説明を兼ねて、レビュー会にプログラマーを参加させる。 依頼日 依頼者 システム名 処理名 機能名 変更理由 変更内容 想定リスク リスク対策 適用予定日 適用日
このページを最初にブックマークしてみませんか?
『プロジェクト管理者ノート』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く