# 評価ダイアログのまとめ ## 時系列 - 5/14 - inputミーティング - 5/17 - 開発開始 - 5/21 - この辺が当初の結合期限 - ライブラリ使用不可能 - 5/24 - 代替ライブラリも使用不可能 - 5/25〜26 - air-closetアプリでやってるのと同じ実装に - これが結構厄介。saga actionに登録して使わなきゃいけないけど、もともとmoduleに切り出して使ってたから基本propsで渡ってくるactionsだけを違うところで発火しなくちゃならない - 5/26夜 - API、domain層の変更が必要なことが判明 - 5/27 - Android修正のためのデザインinput - 木曜夜 - 5/28 - デザインレビュー（間に合わず） - 5/31 - デザインチェック完了 - 6/1 - master取り込んで最初のstgビルド（オーダー画面で死ぬ症状が出始める） - 原因はmiguelさんのビルド環境にあってmasterにはない可能性が高い - 6/2〜3 - pickssログインできない問題（前から存在） - 3日に解決 - 6/4 - ビルド調査開始、adhocビルドできるようにした - 6/7 - ビルド調査終わり、ビルドから総合まで完了 --- - 反省点 - 見通しの甘さ - 期限の引き直しをする際に、必ず以下を確認する - 今回起こった問題の詳細と、解決難易度 - 解決策はどこを変更するか、それによって引き起こされる可能性のある問題は何か - バッファは置くべきか、どの程度が適切か - メンタル的には、「後に予定が詰まっている」という状態が正常な判断を妨げたように思う - 今後は正常な判断を下すためにも適切にバッファを置くことを心がけたい　PL側も予定を立てる際により生産的な予定立てができる - デバッグ・障害点特定 - 効率的ではないデバッグをしていたせいで、問題にたどり着けなかったり、的外れな結論を出してしまったりした - 最初から問題点を探ろうとしない　5割〜6割の範囲に絞り込んだら、そこからは雰囲気でやらない - しっかりlogを追っていく　丁寧にやる - 連絡の質と速度について - どうしても連絡が遅くなってしまうケースが多い - 完璧な連絡を心がけてしまうことが多い - 誰にとっても有用な連絡をしようと心がけてしまう - 第一に案件進行に必要な情報を渡す - 詳細説明は二の次　もしくはリベさんやレビュー担当者向けだけにすればいい ### 反省点 - PickssDBが汚い - 環境が違うことで切り分けがしづらくなる - but プロダクト的に問題がないか否かの -