概要
たたのポエム 課題の運用についてなんとなく意識してることを書き出してみる。とくに誰かに教えてもらったわけでは無いので自身が無い。本は読んでは要るがうろ覚え自分書いといてできてないじゃんってのは、スミマセン
課題をよく読む
- なにが問題でなにを解決したいか
- スケジュールを確認
- 予算、工数
- 何をもって完了するか
- 実装するための情報に不足はないか
なにが問題でなにを解決したいか
- 課題起票者はたいていなにか困ってるから起票している。
- 起票者が書いてる対応が本当に問題を解決するのか？
実は勘違い？
- 実はこちらが対応するものでは無い場合がある。
- すでにある機能で代用できる。その機能自体を依頼者が知らない
課題の登録が適切か？
〇〇で表示がおかしいので確認してください → コメントのやり取りで別件の依頼を書かれる
- 素直に別課題で起票してもらう。
- 別の要望が書かれるとコメントのやり取りが長くなりがち、あとで読むときにかなり苦痛になる。
タスクの粒として大きい場合は分けて起票してもらう
- Backlog だと親子課題で運用してもらうと良い
スケジュール
- 課題に登録された期日が無理な場合相談する。
- 課題起票者が見積りできてない場合もある。
- 調査が必要な場合、いつまでに一時回答して、実装スケジュールを切る。
何を成果物として報告するか
- 証拠を見せる
- HTML 見た目の修正 → スクショ(クロスブラウザチェック)
- 表には出ない裏側の調整 → 動作確認の徹底
- 日頃から作業ログを取る癖をつけておくと良い。
実装するための情報に不足はないか
- 処理の条件は？データフォーマットは？データの件数は？
- デザインでいうと、フォント、サイズ、色、マージンは？
- 着手する前に不明点は荒い出しておけば、実装後の手戻りなどが軽減できる。
- いい感じでって言われるのが常ではあるが、そこは向こうに本気になってもらう(たまに本当にこだわりとか指針が無い場合があるが、設計、デザイン費もらえるチャンス)
おまけ
- 5W1H ( 新入社員時代に上司言われるアレ、今も得意じゃない。 ）
- GTD
- 参考:顧客が本当に必要だったもの
- 継続は力なり―大器晩成エンジニアを目指して(第 9 回 ログのすすめ)