8、9、10三月，需求依旧爆棚，相比纯业务功能的开发，数据的汇聚、整理、分析、统计成为重点，具体细节不一一展开，按如下关键词：任务计划、项目沟通、项目流程、客户汇报、业务关注、时间评估、管理笔记做一些笔录，持续更新：
    1、计划安排：
        1.任务计划安排前，根据经验自己对任务做一个工作量预估。
        2.任务的粒度细化到不可再分、对内根据系统模块分解到开发人、给外汇时封装成产品功能模块。
        3.计划制定前，请成员预审需求、评估任务量，再和开发、测试一起确认时间，由成员承诺。
        4.安排任务多人完成时，指定一个牵头人。
        5.大的需求，组织讨论，小的需求，点对点沟通，口头沟通的需求要落实到文档。
        6.任务分配根据人员特点（善于思考型、踏实肯干、粗枝大叶型）安排难易程度对应的任务。
        7.紧急需求多时，一次尽可能只给成员分配较少任务并约定完成时间、完成后再约定下一个任务。
        8.根据任务分配情况，安排新任务给相对空闲的开发、测试人员。
        9.业务测试过程中发现的问题整理成清单，尽可能一次性转交测试人员，避免碰到一个提一个。
        10.形成人员的备份机制，不局限某个模块只能由某个开发人员做。
        11.加班如遇特殊情况不能陪同，托管工作给指定接口人。
        12.成员加班晚，第二天要根据情况保证人力参与白天工作。
        13.对于一周的新任务，考虑到周一综合症，一般在下半天安排效果较好。

   2、项目沟通
        1.重要事项亲历亲为。
        2.每周的项目周报，除了知悉公司外，同步知悉客户。
        3.需求的分析及客户确认用原型图。需求的确认启动开发，必须业务部、信息化部、公司三方达成一致。
        4.技术实现上会就会，不会就不会，和时间的多少没有线性关系。
        5.控制好工作节奏，多和领导沟通，自己的经历正是人家过去的重现。
        6.沟通项目当前存在的问题时尊重客观事实和软件开发规律，就事论事、做不完的跟客户说明原因，该拒绝的果断。
        7.上线前的客户运作，除了项目层面的客户沟通，也请领导高层向客户高层沟通。
        8.强调需求变更会影响项目计划的执行，变更需要付出代价（优先策略：时间调整、功能调整、人力调整）。
        9.遵循‘少即是多、进度为质量服务‘的原则。
        10.项目风险且一时对得不到公司资源倾斜时，也可借助客户的力量（下下策）。
        11.客户的跟催，多耐心少急躁，多自省少借口，多客观少主观。
        12.交付时间的答复，不能当下给出的待评估后再给。
        13.沟通过程，多‘是的、可以、数字性的‘表述、少‘可能、好像、应该’。

   3、项目流程：
      需求频繁且变化多时，与客户沟通好，按1周～1.5周一轮迭代的节奏。
      每次汇报后产生的新需求、遗留需求、待开发的功能按如下方式安排开发计划：
         1.整理《项目跟踪表》，含：新需求、遗留问题、关联影响（指导测试做关联模块的验证）
         2.测试人员将已明确的开发任务登记到BUG管理系统
         3.需求人员与开发、测试人员评审需求
         4.负责人牵头需求、开发、测试人员确定开发、测试、发布时间计划。
         5.与客户反馈交付时间点（对于小需求的交付时间可以直接答复、大需求要内部讨论再答复）。
         6.项目进度跟踪，以天为单位，请测试人员更新《项目跟踪表》。
         7.需求验证
             1）开发提交代码后，测试人员分别开展系统测试（关注功能的需求吻合度、边界异常验证和业务流程准确性），需求人员开展业务测试（关注界面交互、业务符合度）。
             2）需求人员发现的问题，属于开发BUG登记到BUG管理系统、需求BUG与开发人员、客户澄清，如不影响版本发布时间直接加入在研版本、如影响则提交变更请求，与客户沟通得到变更认可或与开发沟通得到变更认可。
         8.升级前，针对环境数据的准备，编写《升级注意事项（含数据清理、数据准备等）》给测试人员交代。
         9.升级后，需求人员在演示环境走业务测试（建议离正式演示前2天完成升级验证，提前1天环境冻结。）
         10.上线前，与客户沟通准备事项（含压力测试、工程部署、资料交付、培训计划、试运行计划等）

   4、客户汇报：
         1.小型周汇报，提前1天完成业务测试、提前1天和客户接口人知会（客户号预约客户领导）。
         2.大型月汇报，提前2～3天完成版本升级，提前2天完成业务测试，提前1天冻结版本。
         3.客户汇报前的技术准备：
            1）拿客户的演示笔记本做产品验证，验证操作系统、浏览器兼容性问题，检查项目所需的第三方插件的安装情况。
            2）产品验证过程中，当天发现的问题，按汇报时间倒推评估，重要问题当天加班解决（如页面报tomcat错误、点击报浏览器JS错误），不重要的安排人力第二天解决（如：页面默认显示的业务条件。
            3）汇报前，与客户一起核对汇报PPT中的文字、截图。
            4）汇报前，与客户走一遍系统，将系统汇报的重点地方与客户沟通。同时，将系统还存在的问题与客户沟通清楚（如XX工具的弹出页面点击关闭后导致IE浏览器卡死，要等到7～8S才响应过来的）并告知客户在汇报时的规避方法。
            5）客户用讲稿汇报时，配合客户翻PPT到讲稿中相应的位置。
            6）正式汇报前安排测试人员、第三方公司的人员进行技术保障（已有帐号退出系统，服务器不做重启等操作）。
         4.项目初期注意界面UI友好，中期注意数据的规范及业务流程正确，后期注重统计数据的真实、准确。
         5.版本的技术问题、项目进度的问题、用户需求的问题、沟通协调的问题，实事求是汇报客户。
         6.汇报前与客户业务接口人沟通汇报内容、汇报方式，掌握领导听取汇报时关注的点。
         7.汇报前，关注业务部门的需求、信息化部门的建议、更要关注客户领导的关心点。
         8.汇报思路：
            1）抓住业务主线给客户讲故事，结合不同客户关注的角度出发，让平台能融入不同客户的日常工作。
            2）信息化前是什么样，信息化后是什么样（提高日常办公的效率、平台统计的数据提升客户的业绩等）。
         9.汇报步骤：
            1）上一次汇报会上提出此次要汇报的内容，列一个清单。
            2）本次汇报工作解决了哪些问题（新功能开发&缺陷修正和界面优化&其他问题[如项目文档、帮客户做的其他事情等）。
            3）遗留的问题和接下来要解决的问题分别有哪些，估算解决时间。

    5、业务关注：
         1.关注平台的数据输入、处理、输出数据的完整性、准确性、关联性。
         2.抓住平台的建设理念，所有业务模块围绕该理念开展需求分析、设计。
         3.降低线上复杂的业务操作流程（更多考虑结果数据的录入、留痕，流程多了很难同时在线协同办公）。
         4.技术实现的同时要考虑业务机制的配套。
         5.考虑现实性[在现有业务规章制度的环境下运行]、前瞻性[业务层面的发展方向]、可行性[技术是否支持]。
         6.关注和周边平台的数据结构一致和标准

    6、时间评估：
         1.时间评估，尽量让开发、测试人员自己评估和承诺时间（结合自己做的预估进行权衡）。
         2.任务粒度，测试任务分解到最小颗粒度，让测试任务清晰明确。
         3.任务缓冲，不管是答复客户的交付时间、与友商约定的联调和交付时间，均预留冗余（通常按正常计划时间的10%），应对可能会出现的风险（如：协调的时间、人力投入、技术瓶颈、成员病假、客户变更需求、汇报时间提前、第三方公司配合跟不上）。非紧急情况，系统测试关闭到客户汇报之间建议预留1～2天冗余（头一天完成本轮版本的系统测试关闭、第二天上午完成增量升级、第二天下午完成业务验证）。

   7、管理札记：
         1.任务明确、给予空间——不给成员模棱两可的任务
         2.狠抓住干、适当放权——适时跟踪团队成员的任务
         3.敢于承担、顶住压力——创建一个不受外界过多干扰环境
         4.讲究诚信、承诺到位——诚信待人，承诺的事情说到做到
         5.主动沟通、理解包容——宽容待人，包容别人的错误。
         6.用人不疑、疑人不用——建立信任，促进相互协作
         7.功劳大家、黑锅自己——让团队成员更多地专注于工作本身