6月29日、共同でアリババR＆D演奏練習主催のR＆D部門とPMI、TeambitionのAlibabaの効果は杭州西渓公園の活動に開催されますがリーンアジャイルプロジェクト管理を集中します。イベントの詳細と登録ができます行くために私を指します。
プロジェクト管理の目的は何ですか？プロジェクト管理を支援するためにデータを使用する方法、不確実性に直面して動作しますか？そして、何のデータは、プロジェクトマネージャに注意が必要なのですか？ここで八尾シュウ、シニアプロジェクト管理の専門家が飛んで豚の技術の記事を共有するには、我々はあなたにいくつかのインスピレーションをもたらすことを願っています。
序文
プロジェクトマネジメントは、2018年最新PMBOK第6版では、例えば、更新の進化に時間をかけて専門的なプロジェクト管理の専門家の多くは、1つの規律でまとめた後、20世紀半ばのアメリカ航空プロジェクトに由来し、開発されましたアジャイルプロジェクト管理の方法は、タイプに適応計画の進捗状況、その上に新しいプロジェクトマネージャーの値とを引っ張ることを提案しました。グローバルIT企業は、広く普及して少なく、安全で、リーン、DevOpsチームある瞬間には、これらの新規な方法論は、まだ完全に、より体系的なプロジェクト管理を置き換えることはできません、効率的な製品開発や製造段階に着目しました。
プロジェクト管理の目的
多くの場合、学生を中心に聞いて、プロジェクトマネージャは、ほとんどの権限を言って、私たちは鍋ので戻りますように、第2、ない未来は、誰もが、プロジェクトマネージャーをやりたいん。実際には、我々はあなたの手をたたくと残して、製品の実装プロセス、プロジェクト世辞戦場、そして最終的には性急なエンディングの各、私たちの脳をラッキングプロジェクトマネージャープロジェクト計画の多くを参照してください。それは「経営」という言葉と思われるので、そのように、我々は誤ってそれだけで学ぶために、すぐにちょうど立つ学んだ学び、最終的リーン研究所の科学、知識、方法論を考慮し、しませんでした官僚行動の後退、と思いました絵看板は、学校のDevOpsチームは、顔だけ良いものを磨くことを学びました。
なぜプロジェクトべきでしょうか？なぜプロジェクト管理？私たちは何を管理していますか？それは、タスクを完了するために、ちょうどキャンペーンスタイルにですか？それはちょうど良い業績評価に毎年ですか？私たちはしばしばビジョンの中に制限されたフィールド、常に路地ににに、無意識でよりよく、より経済的な方法の結果の目的を考える身体のアイデンティティです。路地の中を歩いて、前進、バックで、でも好転ないではありません。道そこに他の多くの選択肢があると見て、状況を見て行くことにボレーを跳躍するときのみ、そのレーンのうち、思考。この時点では、唯一の自然は聞いて：なぜあなたは投影したいですか？なぜ需要がこれらのアイテムを持っていますか？どの製品の特性を変更する必要がありますか？どのようにR＆Dチーム開発活動壊しますか？誰がクリティカルパス上にありますか？どのくらいの時間を過ごすために？すべてのR＆D前回ことと配信の品質に応じて確保するには？製品ラインのビジネス目標の実現を確保するには？どのようにリスクプロセス、問題を監視するには？最後に、どのようにより投資プロジェクトに戻りますか？対象会社の事業年度かどうか？今年は赤字か黒字となり、収益ましょうか？
ゆっくりと自分の気持ちダウン尋問のようなシリーズは、最高経営責任者（CEO）の視点ではないでしょうか？右、はい。このプロジェクトは、適切な方法とプロジェクトの日常管理を使用して、最もミッションクリティカルなコア事業を識別することができ、毎日のルーチンが何であるかを区別するために、一時的な義務であるかどうかを疑問視しながら、このプロジェクトは、企業の日々の活動を組織しています。
アップを開始し、チームが小さい、7-8パーソナルルーム、叫ん通信による通信の時代には、管理コストは、優先順位付け、比較的小型で直接実行されない、または失うものさえ何もすることができます。しかし、後にアップし、少し過失チームの体重は、サンクコストはあまり、それが直接、企業の生存に影響を与えます。
スコープ、コスト、スケジュール、品質、および同社の非常に一貫性を懸念している、企業の経営陣はコアが自然に重要なプロジェクトの管理に落ちます：いくつかの要因プロジェクト管理トライアングル。
なぜデジタル管理プロジェクト
インターネット企業は、不確実性の多くのユーザーは、競合他社が、市場は、我々はどのように行うか、未知の顔に直面する必要がありますか？唯一の二つの方法：
- テスト、迅速なプロトタイプを達成するために小さな領域に、階調テストまたはA / Bテストを向上させる高速フィードバック効果、次の反復最適化に関連して動作し、フィードバックを受け取ります。
- 測定は、露出の問題を使用して正確に定義された寸法、正確、かつタイムリーなデータ収集、データ分析を測定する試験結果を継続的に最適化することを確認します。
どのように多くのチームメンバー、どのようにプロジェクトのスコープ（コードの行、プロパティ、開発工数の数）、どのくらい：測定データを分離することができない、私は正確な数字を言うことができない、プロジェクトのサイズを記述する際に持参しなければならなかった、多くのプロジェクトマネージャーを見てきましたプロジェクトサイクル、どの程度の事業費、どのようにビジネスの目標は？多くの人々も、OPEXとCAPEXを伝えることができなかったではなく、ROIを言及します。数字の欠如に敏感なデジタル環境についての話の欠如、のではなく、誰もが仕事で唯一のハード技術のほとんどでさえPDを、その結果、全身の思考の内部環境のデジタル解析を使用しての習慣を奨励し、育成しているため、稀に理由を尋ねていない、通信十分なスペースとプロジェクトの進捗のも主観的、曖昧な説明は、理解、コミュニケーションや非効率的に差が生じている間。
なぜ我々は仕事でデジタル習慣について、それを話すべき？
- 数値は定量化できる目標です。企業の動作の詳細については、例えば、計画している、当連結会計年度の事業目標、コスト見積もり、それは様々なプロジェクトを実装するためにあらゆるレベルにまでする必要があり、各ノードは、毎月予測するように、逆を導き出すことができるようにしても、行くことにした、四半期ごとの営業結果。私たちが意識的にタイムリーな調整行動を目標とするよう一方、組織行動の過程では、ベースラインとして使用することができます。
- 数値は、より客観的、より正確に詳細を説明します。デジタル事実は間違った判断を下すだろう、多くの場合、簡単に自分の感情、偏見、誤解の欺瞞感の人々よりも信頼性が高いです。より客観的な引数は、より詳細な、より多くのそれは意思決定や通信に使用されているかどうか、精査に耐えることができ、単に私たちの脳をラッキングよりもはるかに優れています。
- デジタル駆動力です。プロジェクトマネージャーのコアバリューは、プロジェクトの目標達成を確実にするために、プロジェクトの戦略を調整するために、リスクや機会を特定し、傾向を識別し、有効なデータを多数のデータ分析にする必要があります。残念ながら、現実には、ほとんどのプロジェクトマネージャがやっている予備情報、事実収集の仕事です。どのように意思決定、読み込む方法を、収集した情報が重要ではないと言うことはなく、一般的な、自動化され、データ視覚化市場を確立しなければならない、あなたが収集した後に統合する方法に力を入れていません。
プロジェクトマネージャが心配である必要がありますどのようなデータであり、
表に示すように、プロジェクトの焦点の異なる段階が同じではない、有用な情報を掘るための適切かつ効率的な手段が存在しなければなりません。
注意：青根は、アリ・ストップ・研究開発コラボレーションプラットフォームで述べた外部のクラウド効果と呼ばれ、以下同じ
事实上，AONE已经能基本提供收集以上所有信息的功能。很多大型的IT企业一直不遗余力的在寻找合适的工具管理各类信息，因为历史遗留问题，不得不花费大量的时间、精力打通所有的信息通道，迁移、整合数据，而AONE已经帮助我们弯道超车，实现了完整的需求产生、生产、集成、发布、部署。在飞猪，我们更进一步，针对特定的应用场景，基于AONE的数据，二次开发，用魔法石生成了重点项目的定制化项目数据大盘。
飞猪项目数据大盘实践
那么数据大盘包含了哪些内容呢？
首先，从19财年业务策略开始梳理重点战役结构，用一张图画出各战役之间的关联（以下为示意图），并明确负责的项目经理和产品经理，形成第一级的项目目录。重点在：
- 分清楚项目发起人和项目集经理。我们经常容易把这两个角色弄混，一个项目会出现好几个管理者，在不同场合项目经理的名字不一样。项目经理是第一责任人，必须是直接指挥、跟踪、汇报项目的执行人，明确其唯一性和权威性并广而告之很重要，能加速问题解决和减少沟通误解。
- 整合项目结构，合并相关联的，并广泛沟通。
- 目标明确再立项。
设定统一的项目里程碑规范。以前项目的里程碑计划很随意，可有可无，大小不一。容易造成：颗粒度太小，外部干系人看不懂；颗粒度太大，缺少对项目组内的指导。现在采用统一的M系列里程碑定义，明确项目考核的时间点和标准，严格执行重要里程碑（M1&M4）的评审制度，有效的管理干系人期望，并随时度量下一个里程碑的可实现性。这样的好处是：
- 用统一的术语规范的项目执行的质量标准。
- 里程碑评审增加项目执行的严肃性和完整性，做到有始有终，防止虎头蛇尾，帮助持续改进。
- 增加沟通有效性，项目的评审结果和跟踪直观、易读、统一。
整理AONE项目空间，明确产品线、项目组合、项目集、项目的结构关系。需求、测试、缺陷、发布全部落入AONE，在魔法石生成对应的报表结构，层层钻取细节信息。
- 在飞猪产品线下设置子产品线，所有需求都直接在对应的子产品线下创建，遵循统一的规范模版，这样才能保证所有需求属性一致，方便魔法石度量。
- 所有重要项目在PMO注册、创建，不允许私建项目。简化项目结构，只允许两层项目归属关系，避免过深的项目结构带来的责任不明确。
- 由PMO组织重点项目例会，项目集经理向项目发起人汇报项目状态，方便及时调整策略、暴露问题，解决冲突，同步信息。
建设项目经理的责任制，要求项目经理必须对项目整体表现给出信心判断，依据AONE里的项目健康度信息形成项目晴雨表，红绿灯直观表现出项目的健康状态。要注意的是：
- 项目状态是项目经理的主观判断，是报告里为数不多的非客观评价，但不能省略，整体判断项目健康状态，同时也给出责任人的承诺
- 项目的趋势比单点状态更重要。对持续告警的项目，要开始专项治理。
针对需求管理，首先明确不同角色的责任和合作方式。清晰的项目边界是成功的关键。项目启动初期，应该花大量的时间和精力明确需求范围、优先级、技术方案，而不是盲目开工，毫无纪律的边讨论边干活，不断返工，最后越做越困惑。比如，下面的两个实例，
- 项目A，对各类需求范围的管理都很严格，需求总量只出不进，每月评审上线效果，在后期果断丢弃低优先级的需求保证项目按时完结。
- 而项目B，各类需求都在缓慢增长，实际表现就是项目做的像日常，未来没有规划，想到什么就做什么，目标不明确。
使用按优先级分类的需求累积流图，识别项目核心交付内容，通过日常监管防止项目边界蔓延，做到有始有终，清空桌面再结项。
测试计划可以使用甘特图，测试过程中要有定期（每日/每周）进展推进图。项目后半段的时候，往往是测试的白热化阶段，有些项目可能需要用日会结合缺陷报告重点推进，识别出阻塞测试的缺陷，是否需要组织特殊小分队集中解决难题，是否需要不断升级警告直到团队的高层领导桌面上，要能结合进展明确指出问题以及解决办法，而不要罗列繁琐的细节。
缺陷分析，在宏观上，要能指出质量问题是否收敛，解决速度是否够快，识别重点问题集中区；微观上要就重点问题清单，点对点分析原因、找出解决方案、给出实施计划。缺陷不仅仅是质量风险，也是工作量，不管是修复问题，还是提出新需求，都是整个项目的新增工作量。实际上，缺陷也是可以预测的，根据千行缺陷率、改动代码行数、修复工时、合适的数据预估模型，就能更合理的估计产品上线时间，而不是总倒排工期。做到符合一定质量标准的产品才允许上线，杜绝只开发不测试、只测试不修复、无纪律上线等一系列严重影响用户体验的行为。
风险管理一直是项目管理的难点。首先，我们只能管理看得到的风险，有些风险也不可避免的会实现，更不用说那些完全无法预测的风险。其次，风险管理更考验项目经理个人的经验和敏锐。AONE提供了风险管理的功能，但“重风险识别，轻用风险应对分析”的现象还是比较普遍。AONE中提供的风险汇总视图（下图左）只能单维度的展现风险严重性，缺少可能性指标，于是我们在数据大盘里加上了风险矩阵（下图右），按严重性、可能性划分出9宫格，把注意力集中在矩阵右上角，一目了然。
人力资源投入是大家都很感兴趣的一个话题。AONE暂时不提供相关统计，我们只能另外开发小工具，由团队TL每月填写各项目参与人员的数量。资源分配可以宏观上帮助研发团队规划项目投入，不仅仅对过去的资源投入分析总结，更重要是可以整体上预计未来的资源分配是否能支持业务需求。
理论上，大家填好AONE里的需求工时估计，计算出来的工作总量应该是最准确的资源耗费成本，也可以生成项目的工作量燃尽图，以此能准确的预测项目实际上线、验收的日期。但实际执行中面临挑战太大，需求拆分不明确导致工时估计落实困难，而不得不折中由TL来汇总人力资源分配信息。
经过半年的项目规范、数据运营落地实践，从S1半年的项目需求交付周期回顾，我们发现:
- 强管控的需求交付周期明显短于平均值。
- 交付周期中占比较大的是需求分析阶段，表征就是项目前期需求、目标不明确，导致后期开发赶工，测试压缩，最后的结果自然就不够好。
- AONE的使用规范统一化非常重要，对需求的跟踪、更新不及时就会造成数据偏差。在使用好项目例会同步信息的同时，通过关联代码和需求自动汇总状态变化信息，让数据更准确。
项目管理体系的未来
我经常被问到PMO是干什么的？很多人直接把PMO和过程改进、提高研发效能相等，我觉得PMO应该承担的责任是：首先，协助分解战略，合理部署资源，把关项目立项，整合项目结构。其次，建立系统的适配的管理规范，拉通上下游，让研发团队如同工厂生产线一般有质量、有效率的交付产品；最后，赋能项目经理，提高管理水平。优化、提效应该是一以贯之的持续改进。
经过半年的数据建设，飞猪技术部运行的项目已经逐渐规范，完成了两个重点战役的M4验收，明确了项目边界，逐步培养项目经理们的数据意识，倡导大家追问业务目标，量化过程指标，每个迭代都及时收集业务反馈，保证用户价值在运营、产品、技术、客满团队之间的顺利传递，并形成闭环。当然，我们依然面临巨大的挑战：
- 用户价值的追问、传递必须持之以恒的坚持下去。
- 日常需求和弱管控的项目开发支持不够。
- AONE中沉淀了大量的数据，需要人性化的自动收集和分析焦点问题。
- 项目的迭代规划、定期演示尚未制度化。
- 项目经理赋能不够，只有越来越多的优秀项目经理成长起来，才能更广泛的保证系统健康运行。
这半年，有成功交付上线的项目，也有目标不明确业务效果不明显而被叫停的项目，我们为成功喝彩，也为挫败反思，至少我们已经迈出了第一步。希望有一天能真正实现项目的可视化、可度量、可预测，希望有更多的人有热情投身项目管理。未来的路还很长，我们还需努力。
在此文结尾，不得不提到龙幽、欧旋两位数据挖掘专家过去5个月中对PMO工作的倾力支持，总是容忍并及时满足需求方提出的各种琐碎、奇葩、紧急的要求，衷心感谢！！
原文链接
本文为云栖社区原创内容，未经允许不得转载。