暗い時まで--あるプロジェクトの悲惨な経験を覚える.

最近プロジェクトをして、オンラインになってから順番に3つのオンラインバグを発見しました.まるで私が入社してから今までにないことです.本当に除名されるような気がします.ここで、プロジェクト全体の過程を復元し、プロジェクト管理でミスした点を記録し、再びミスが発生しないことを望んでいます.
1.プロジェクトの背景
1.1参加者
1.2項目タイムライン

4月13日プロジェクトの需要について事前に討論し、プラグインの協力者AがUIレンダリングを開発し、データサポートと報告のロジックを提供することを決めた.

は4月17日、広告主C側との応用ロジックを決定し、referを通じて広告源を確定する案を決定した.

5月25日A方の人員は変動して、広告は無期限に延期されて、A方は同時に広告レンダリングロジックを改版することを提出して、当方が広告コンポーネントライブラリを提供して、全面的に広告レンダリングの方案をつなぎます.

5月30日に当方の開発が完了しました.A側は一時的により高い優先度の需要があり、スケジュールがなく、連調時間が引きずられている.

6月1日にC側が連調にアクセスし、C側サーバがhttpリンクであることを発見し、referスキームはurlパラメータスキームに変更された.C側は全リンク連調を走りたいと思っていたが、広告バックグラウンドのテストサーバが外部ネットワークアクセスをサポートしていないため、テストリンクがずっと通じないため、切断方式を使用しなければならない.双方の交流が困難である.

6月7日にAB側の初歩的な連調が完成し、広告の初歩的な展示が行われたが、A側は広告関連の挿入論理を改造しなければならない.またC側は引き続きコミュニケーションが緩慢で、BC側の連調は完成したが、BD双方は

を連調しなければならない.

6月11日A方はまだ期日がないので、6月15-20日に

を調整する予定です.

6月15日にAB方連調が完成したが、C方はまだ開発中の

である.

6月20日BD双方の調整が完了し、6月21日に

をオンラインにすることを約束した.

6月21日C側は一部の機種で文案が長すぎると隠され、一時的に修正され、オンライン時間が6月25日

に変更されることを発見した.

6月25日A方は夜になってからオンラインになった.また、手Q 70%-90%の階調と微信アプリケーションを同時にオンラインにした.

6月26日B方は緊急に手Q論理を修復し、A方は再びオンラインになり、オンラインになった後、広告がクリックできないことを発見し、CGIがドメインをまたいでいることを調べ、再び戻った.

6月27日にオンライン上にIOSの低バージョンの広告画像が展示されていないことを発見し、css互換性の問題であることが判明し、再びオンラインになった.

2プロジェクトで発生した問題
製品側:

多方面協力時間点はコントロールされておらず、持続時間が長すぎて、すべてのbuff時間

を引きずった.
開発側:

は全リンクテストを行わずに急いで

にオンラインになった.
プロジェクトの品質は永遠に第一位で、オンラインになってから返品しても時間に間に合わない.できるだけ全リンクテストを行い、全リンクテストの必要性を十分に明確にしなければならない.

全体の慎重な思考を行わず、多端衝突の問題を理解していない

プロジェクトの開発前に影響を及ぼす状況をよく考えなければならないが、今回の手Qと微信の衝突はA側の学生の注意が必要だ.でも考えたほうがいい

プロジェクトの問題はアラームを起こさなかった

ドメインを越えた問題があると考えていたが、確認したり、テストの学生に注意したりしなかった.テストの同級生はリストを切るため、fiddlerにドメイン間ヘッダを設置し、この問題を省略した.
H 5フロントエンドのいくつかのクラシックピット:ドメイン間、キャッシュ、互換性
fidderスライスに判断条件を加え,他のドメイン間で無視されることを防止する.

    static function OnBeforeResponse(oSession: Session) {
        if (m_Hide304s && oSession.responseCode == 304) {
            oSession["ui-hide"] = "true";
        }
        //       
        if (oSession.host.Contains("news.ssp.qq.com")) {
         oSession.oResponse["Access-Control-Allow-Origin"] =  "http://test.view.inews.qq.com";
         oSession.oResponse["Access-Control-Allow-Credentials"] = true;
        }
    }

テストの学生は互換性の問題を提出したが、

を十分に重視しなかった.
テストの学生は口頭である機種の広告画像が展示されていない問題を提起して、必ず現れるかどうかを確認したことがありますが、間違ったのは必ず現れることを偶然に聞いたことがあります(私は絞めて、これも間違って聞くことができますか?!)だからネットが遅い原因だと思って、重視していません.
その結果、flexはサブノードheight:100%の失効を引き起こし、画像の高さが永遠に0になるという問題が、IOS 10以下の機種でしか現れず、PCもAndroid(4.3以上)も良好に表現されている.
やはりテストの学生は厳格にテストリストを提出して、同時にテストの学生が提出したいかなる疑問点を重視します.
3まとめ
この件では、プロジェクトに問題が発生するかどうかの特徴をまとめました.

バグリストの前のバグも

はありません

プロジェクト重大延期

の協力者が多く、調整が困難である

.

すべての人はプロジェクトに対して盲目的な楽観を持っています

以上の場合、項目の多くは問題があってテストされていない.今回の責任は主に私にあり、事前に警報を出さなかった.私が入社したばかりの頃、リーダーは私に「種目をしても勝先考敗しないで、やる前にどこが一番間違いやすいか考えてみよう」と繰り返した.どうして何年もやったのか,かえってこの戒めを忘れてしまった.やはりうっかりしました.
就職して4年、こんなに惨めなことはありません.一度も後退したのは事故です.彼の妹の後退は2回、オンラインになったのは3回で、本当に惨めです.
そして私は子豚のペッキーを捨てて、新しい人形に変えて、幸運をもたらすことを望んでいます.
4後記
2018-06-29日20:30に杭州行きの高速道路で、微信群の中でまた叫んで、オンラインのバグがあると言って、広告主のC側がデータをクリックしていないことになります.私がこのニュースを手に入れたとき、もし本当に私の鍋だったら、さもないと辞職したほうがいいと思っていました.週末を楽しく過ごす気持ちは一瞬にして異常に悪くなったが、私はまた考えてみると、オンライン事故は交通事故より強い.それから嘉興サービスエリアで、私はちょうど半分のバグ検査のコミュニケーション会を開いたばかりで、その時の考えも簡単で、死んでも尊厳があります--確かに多くのことがあったので、もう勝手に鍋を振る勇気がありませんでした.ありがたいことに、最後は広告のバックグラウンドDの問題です.
意外にも多くの仲間がこの文章に注目して慰めてくれて、ありがとうございました.これらはすべてフリーウォーターですね.実はプロジェクト管理も日常の仕事の中で注目されている点です.この問題に対して、本文ではいくつかの点を少なく述べました.
4.1技術的影響力の形成
実はプロジェクトに多くの問題が発生して、私が最も悲しいのは、技術の影響力の崩壊です.ビルを建てるには数年かかるかもしれませんが、破壊するには一瞬しかかかりません.私たちは半年をかけて、技術的な影響力を少し育成したばかりで、今回破壊されたのはきれいで、この後遺症はまだ長く続くかもしれません.これも私がなぜ辞職の考えを芽生えたのかの原因です.本当に悲しいです.
4.2点この種目の鍋
もう何日も経っているので、この時に鍋を分けに来たのは心が穏やかになったのではないでしょうか.まず、誰もが鍋を持っています.これは間違いありません.
開発は技術案の具体的な実現者として、大きな鍋を占めても問題ない.テストの学生にも鍋がありますが、新しい入社を考えると、開発の学生は強いので、鍋を担う割合は適切に減らすべきです.製品の学生は時間点でコントロールし、プロジェクトを統一的に計画する上で主な責任を負わなければならない.