アリババ開発における私の効率的なアルバイトスキルのまとめ

[ライブブロードキャストプレビュー] 99元のクラウド仮想マシン × 9元のクラウドネイティブアーキテクチャ√

序文

仕事で PRD、技術的ソリューション、テストケースを自分で作成する必要がない場合、この記事は貴重な 15 分を無駄にするだけでなく、何のメリットもないため、無視して構いません。

背景

多くの新規採用労働者は、工場内で最も時間のかかる作業はコーディングのほかに多くの雑務があると報告しています。たとえば、プロジェクトによっては、通信およびドッキング関連の作業の割合が 70% 以上であることもあります。 . %、実際のコードの作成とセルフテストには 1 ～ 2 日しかかかりませんが、詳細な内容の作業時間を前に入力するのは不便で、非常に苦痛です。同僚への愛と保護から、ちょっとした助けになればと思い、パートタイムの仕事のスキルをここで共有することにしました。

会議を効率的に開催する方法

会議の主催者として

まず、カンファレンスの発起人として、皆さんに以下のことを意識的にしていただきたいと思います。

事前に書類を準備しておく

技術ソリューションのレビューなどの会議資料を事前に準備します。レビューする前に、少なくとも完全な技術文書を作成し、事前に会議に参加する上流および下流の開発者と非公開で合意を調整し、文書を作成する必要があります。スケジュール内に掲載されます。一番嫌なのは、計画のレビューをしなければならないのに、上流も下流も頭を悩ませていることです。結局のところ、「会議後の確認」というアクションがたくさん残っていることです。 3 会議での「会議後の確認」には、深刻な情報格差があるはずです。すべてのレビュー型プログラムはセミナーに発展するべきではありません。目の悪い作業者がどこに投稿すればよいか分からないように、慎重にスクリーンショットを大量に作成しましたので、スケジュールの説明に投稿することも、スケジュールのコメント欄に投稿することもできます。

招待時間をコントロールする

私には友人がいます。第一に、この友人は実際には私ではありません。第二に、この友人には 1 時間以上続く会議には出席しない癖があります。なぜなら、1時間を超える会議は、オンラインでの失敗の振り返りでもない限り、間違いなく長く、臭く、不確実な点が多いからです。技術的な解決策であれ、製品の解決策であれ、第一線の技術者であれば、十分に対応できると思いますが、大規模なチームの場合、この種の会議に代表者を派遣するだけで十分だと思います。 PD は開発中に不在にする必要はなく、開発が存在するかどうかをテストする必要もありません。したがって、全員が十分な準備を整えながら、会議に実際にどれくらい時間がかかるかを合理的に評価できることを願っています。私の経験によれば、5 人日以内のビジネスニーズの場合、技術ソリューションのレビューは 15 分に制御でき、10 人日以内のニーズの場合、技術ソリューションのレビューは約 30 分に制御できます。1 時間の技術ソリューションレビューは、複数のサブドメインの共同レビューまたはフルリンクの技術ソリューショントークに適しています。「ブレンディングインターフェース契約書」「ラッチング開発進捗状況」「○○プロジェクト技術日報」などの個別項目の情報同期は10分、長くても10分あれば十分です。10 分あれば本当に多くのことができます。10 分以内に特定の問題を明確に説明できないことに気付いた場合、私の提案は、会議をスキップして、コミュニケーションが必要な人に直接行くことです。スツールを移動して彼の隣に座り、ペアプログラミングを行います。

他に空きがあるか事前に確認してください

私には友人がいます。第一に、この友人は実際には私ではありません。第二に、この友人にはスケジュールの都合を思い出させるために送られてきた招待状には参加しない癖があります。なぜなら、あなたが会議の参加者として本当に重要であるなら、少なくとも誰かが事前に挨拶と背景を説明する必要があるからです。第二に、事前に開始する必要があります。事前に開始するので、コア担当者が適切かどうかを確認する必要があります。ご利用いただけます。

最後の手段として一時的な会議を必要とする、予定外のニーズや緊急のオンライン案件がたくさんあることを理解しています。しかし、プロの移民労働者として、もし 10 回の会議のうち 8 回が臨時雇用だとしたら、私は本当に尋ねたいのです。あなたの移民労働者の辞書には「計画」という言葉は存在しません。個人的な経験: 打ち上げ時期が 15 日以内であることが明らかな場合、PD は少なくとも 2 日前までに PRD レビュー会議の予約を入れ、開発が技術計画を明確にした後、PRD レビュー会議への招待状を送信する必要があります。少なくとも2日前までに技術計画検討会議を開催してください。視力の悪い作業者が参加者が忙しいかどうかを確認する方法が分からないことを防ぐために、次の写真を掲載します。

会議の参加者として

会議資料を事前に読む

本来、会議には必ずテーマがあり、主催者は事前に資料を用意し、相手が率先して出してくれない場合は、自分から率先して資料を求めてから会議に参加する必要があります。3回連続で打ち合わせをしているのに、何も資料を用意していない場合は、「この作業者はもうあなたをあまり必要としていない」と判断して、あなたがいるのといないのとでは大して変わらないので、会議に行くことは考えられません。。

同僚とお互いにバックアップし合う

通常の制作チームや技術チームは、プロジェクトの初期段階や、「AE 注文最適化に関するディスカッション」、「23 年間の XX 協定の境界」など、重点を置く前のプロジェクトで、かなり不可解な名前の会議への招待状を頻繁に受け取る必要があるかもしれません。バージョンアップコミュニケーション』などなど。各種会議、PD、開発、テストなど、皆さんお忙しいときは1人でも出てくれると嬉しいです。同様に、開発チームとしても、特定の人の参加を必要とする特定の事項がない限り、クロスドメイン要件とフルリンククロストークミーティングでは、ドメイン内のインターフェイス担当者の存在のみが必要です。

時間が合わない会議は事前に通知する必要があります

会議が自分の時間と競合する場合は、暫定的にクリックするか、寛大に拒否し、会議の主催者を積極的に同期して、誰がバックアップとして会議に参加するかを確認できます。バックアップがある場合は、事前に相手に背景を説明し、困惑した表情でバックアップを会議に登場させないようにする必要があります。バックアップがない場合は、相手に直接伝えることもできます。結果は 2 つしかないためです: 1. あなたは非常に重要なので、会議は再スケジュールされます; 2. あなたは非常に重要ではないので、会議は予定どおりに開催されます。つまり、会議室で何人かが電話をかけてきて、全員が 3 分を無駄にした後で、電話の向こうで気まずそうに「都合が悪い」と言うのを聞くよりも、はるかに心地よいのです。

誰もが境界線の感覚を持っていることを願っています

RRD レビューや技術ソリューションレビューなどの正式な場では、全員が互いに干渉すべきではありません。製品ソリューションをレビューする際、開発学生は技術ソリューションの詳細について PD に質問せず、要件を自分自身で理解することに集中してください。技術的な解決策を検討する際、PD がテーブル構造の設計やシステムアーキテクチャなどの技術的な詳細にあまり関与しないことを望みます。タオを聞くことにはさまざまな職業や専門分野があります。そうしないと、全員の時間を無駄にするだけでなく、紛争が増えるだけです。

テストで怒られない方法

技術的ソリューションを検討する前に背景を明確にする

全員が PRD レビューに参加する場合でも、この開発の要件の範囲は技術ソリューションのレビュー中に繰り返す必要があります。全員が一貫した理解を持っていることを確認してください。

発売が近づいているときや発売後に要件が不足していることに気づくのは本当に恥ずかしいことです。

必ず自分自身をテストしてください

単体テスト、統合テスト、ページクリックボタン。

実装可能なセルフテスト計画を実装するために最善を尽くす必要がありますが、多くの作業者がテスト依存症候群に陥っていることに気付きました。テスト注文を作成し、あらゆるターンでトレースを作成し、すべてのテストを取得します。必要ない、本当に不要だ。作業者の中には、自分の製品のデバッグパッケージさえインストールせず、トレースを捕捉するためにフロントエンドかテストを探す人もいます。人事部には、すべての生産チームと技術チームを検査して、携帯電話にテストキットをインストールしていないチームを確認することを強くお勧めします。

テスト中に裏で何かを約束しないでください

オンライン変更 (機能コードのリリース、構成項目の変更など) の起動時間やリスク範囲については、PD であっても、開発を依頼する運用であっても、テストの裏側で判断を下さないでください。

いわゆるテスト人日 = 1/2 開発者人日です。この大まかな見積もり戦略は、開発とテストの内部スケジュールにのみ適しています。深刻な状況での評価には、テスト仲間による個人的な評価が必要です。

他の開発者から叱られないようにするには

まずは商品を探してください

クロスドメイン協力の場合、特に新機能の開発が含まれる場合、開発者は互いの製品を直接バイパスせず、他のチームの開発を直接見つけることをお勧めします。

私たちはPDの力を信じなければなりません。クロスドメイン協力のすべてのリクエストは、まずタイムリーに PD に報告されます。PD にスケジュールと優先順位を伝えた後、開発チームを割り当て、連絡します。無用なトラブルは避けてください。コールドスタートをしないでください。

原因と結果をわかりやすく説明する

チーム間でコラボレーションする場合、特に開発者間のコミュニケーションでは、事前にビジネスの背景を迅速かつ完全に説明することが期待されます。実際には、あるチームの開発は、誰もが思っているほど、別のチームのビジネスに精通していません。

助けや協力が必要なときは、必ず事前に書類や言葉を整理し、xxxのため相手からのxxxxの助けが必要であることを明確にしてください。

PMのやり方

プロジェクト管理のトピックは膨大でよく理解できませんが、ここでは開発を学ぶ学生向けに比較的単純で実践的な作業スキルのみを紹介します。

群衆を引っ張る

はい、それはまずディンディングループを形成し、xxxワークグループを形成することを意味します。会議グループは使用しないでください。よろしくお願いします。たくさんのプロジェクトを見すぎて、1週間先延ばしにして話し、100の会議グループを開き、スケジュールの基準や講演者がどこにいても異なっていました。

参加しているすべての生産および技術労働者がグループにいることを確認してください
グループのお知らせをタイムリーに更新します。グループのお知らせには次の内容を含める必要があります。

子域1：对应开发、对应PD、对应测试子域2：对应开发、对应PD、对应测试
技术方案评审时间：xxxxx联调时间：x'x'x联调环境：dpath(xxxx)提测时间：xxx发布时间：xxxx
PRD: 链接1、PRD: 链接2技术方案：链接1、链接2

情報の変更はすべての関係者にタイムリーに報告され、グループ内で同期される必要があります。

デート

技術的なソリューションのレビュー、テスト、リリース計画のレビュー

これらの会議は、予定時刻に従って 2 日以上前にスケジュールする必要があります。そうしないと、時間はますます混沌としたものになってしまいます。明後日に技術ソリューションのレビューが必要であることが明らかな場合は、たとえ今日一言も書いていない場合でも、まず予約を取る必要があります。

技術的なソリューションに精通している

10 人日以内の小規模なニーズの場合、テクニカルインターフェイス担当者またはテクニカル PM は、記述する必要のないコードも含め、すべてのソリューションの技術的な詳細を確実に理解する必要があります。大規模なプロジェクトの場合は、少なくとも自分のグループのさまざまなサブドメインと外部プロトコルの変更を理解する必要があります。たとえば、サブドメイン A は、サブドメイン B が使用できるように新しいフィールド abc を追加する必要があることがわかります。abc の実装ロジックを知る必要はありませんが、ここに新しい abc があることは知っておく必要があります。そうしないと、フルリンクカンファレンスに参加する価値がなく、大きな目で人々を見つめたり、小さな目で見つめたりすることになり、私が質問しても分からなくなり、非常に恥ずかしいことになります。

技術的な解決策を要約する

すべての文書をまとめた別の文書を作成することは、非常に重要です。特に多くのサブドメインが関係する場合は、完全なリンク図を描くのが最適です。この図は、詳細が多すぎる必要はなく、見苦しくても問題ありません。フローチャートと UML の両方を使用できます。重要なのは、クロストーク中に依存関係を整理しやすくするために、変換に関与する必要があるサブドメインと、上流と下流を示すことです。また、チームが開発の途中で問題を抱えていることが判明したときに、開発の途中で作業が中断されるのを避けることができます。追加の介入が必要になり、誰もが当惑することになります。私はお互いを責め合うのが一番嫌いです。

フルリンク会議に積極的に参加する

これが大規模なプロジェクトで、あなたが特定のサブドメインのテクニカルインターフェイス担当者、つまりドメイン内 PM にすぎない場合 (大規模なプロジェクトでは、ほとんどの同僚がこの役割を担っています)。その場合、PDM または PTM がたまたま喜んで参加しない限り、さまざまなプロジェクトの毎週の会議、毎日の会議、および集中会議に参加することは、避けられない責任です。また、参加される場合は人的資源の節約のため、情報のアップロードや配信の際には他の作業者を引きずらないようにしてください。

率先して PMO に助けを求めましょう

プロジェクトに PMO の役割があることを初めて知ったとき、私は彼/彼女に非常に真剣にいくつかの質問をしました。特に開発中であり、ビジネスが要件の範囲を繰り返し変更しているドラマプロジェクトの場合は特にそうでした。私「PMOには一時的な新規要求を断る資格があるのですか？」相手「いえ」私「では、不当な変更を断る資格は誰にあるのでしょうか？」相手「分かりません」私「じゃあどうするの？」あなたにはそうする権利があるのですか？PMOには「PRDサインオフ後の一時的な変更を拒否する権限」「プロジェクトメンバーを追放する権限」など、プロジェクト内で最大の権限を与える必要がある…残念だ。現時点では、PMO 学生の力はまだ比較的限られています。私の知る限り、第一線で活躍する技術学生の観点から、提供できる主な支援には以下の点が含まれますが、これらに限定されません。

会議室を探します。会議室が必要であるが、予想される期間内に会議室を予約できない場合は、PMO に連絡して調整することをお勧めします。
ラックを引っ張ります。残念ながら、プロジェクトの進行中に不快な紛争が発生した場合、それがチーム間のテクノロジー間の情報のギャップであれ、ビジネス要件の一時的な変更であれ、タイムリーに PMO に同期し、PMO からの調整を求める必要があります。一人で戦わないでください。
リスクを報告します。開発またはテストの進行に影響を与えるすべての既知のリスクと事項は、できるだけ早く PMO に同期される必要があります。特に、各サブドメインマネージャーの注意を引く必要がある重要な問題は、できれば各サブドメインマネージャーによってエスカレーションされる必要があります。 PMO。
逮捕。実際にそうなった場合、開発やテスト中に技術側が現プロジェクトの初期評価漏れに気づき、PDや他チームの開発介入が必要になるため、PMOが主導となって調整するのがベストです。リソースを保護し、テクノロジー間で直接通信しないようにします。

著者｜柯州

元のリンク

この記事は Alibaba Cloud のオリジナルコンテンツであり、許可なく複製することはできません。