项目管理

误区 之前我没有项目经验，在上一家公司的项目管理上，我只是照葫芦画瓢。 产品发起，整个项目没有项目经理这一说。或者说有，但却真的感受不到，一丁点也感受不到。 产品发起会议，或者开发发起会议。无论谁来发起会议，一般都会针对于某一具体需求或者某一具体实现方式。 没有具体的任务规划，任务拆得不够细致。这个和开发自身有关系。当然那时的公司确实没有一些指导性质的模板和导师。 任务分得不够细致，就会导致工期评估差距比较大。 各种O们的临时紧急需求，很多O没有技术背景和项目管理背景。很多时候提出的需求都是发生在项目开始过程中。 都是很急的需求，不得不重新估算时间和排期。开发为了避免延期风险，就是让产品排优先级，然后我们根据优先级估时。 直到有必要的需求都在这个迭代中计划上。 没人全局把控，产品从产品角度，开发从开发角度，业务从业务角度。始终没有一个最终的协调人。 产品在对各种O的对话中，气场和身份不足，导致需求基本是提出就会安排。即便是请出青岛总负责人出面沟通，最终的结果一般就是接受。 之前我们是青岛为开发，北京为产品、UI、前端、测试。异地沟通。电话会议是常有的事情，私下的临时沟通电话更是家常便饭。 信息同步、开会、理解程度 都会造成沟通上的成本增加。 紧急需求上线后，三个月没人反馈。问了才知道，财务提的需求他们没用过。 开会一般都会临时决定，发起人会准备资料

1、项目方向 项目加 是一款 免费的 项目管理工具 ，分本地化部署和云端SaaS两种使用方式。产品Slogan为“ 专注项目管理，让协作更高效 ”，使命为“ 基于多种项目管理方式，解决多种协作应用场景下的效率提升问题" 。官网为： https://www.xiangmujia.com 2、团队文化 项目加 团队成员来自知名的互联网、软件公司，拥有多年的项目管理经验和深厚的技术背景，成功研发过多款互联网产品和大型的软件外包项目，也参与过多个创投性产品的研发和探索，并一起工作多年，对团队协作和产品体验有很深的体会和洞察，是极简主义和授权团队的推崇者。团队文化包括如下 老板称号 团队内部互称老板，打破陈旧的职级束缚。 授权团队 我们认为只有做到授权团队，才能最大程度的尊重人才，组织架构才能做到真正的扁平化，更能打造出自组织团队。 最佳协作奖 作为协作产品的创造者，每位团队老板都在追求协作的高效和有效性，都在不断探索最佳的协作实践，并不断自我完善和相互分享。团队每个季度会通过投票制，选举出最佳协作奖一起共勉。 3、产品初心 任何一个产品从0到1或从1到10，过程中都会牵扯多个团队和多干系人的协同，怎样 让协作更高效并有效 ？是每个团队都会面临的 关键问题， 也是 最头疼的问题 。 项目加 团队也不例外，也选用过国内外很多协作产品，但又基于一定的使用体验不好、团队用不惯

1.type_list.js var columns = [ { field : 'selectItem', radio : true }, { title : '分类id', field : 'id', visible : false, align : 'center', valign : 'middle', width : '80px' }, { title : '分类名称', field : 'name', align : 'center', valign : 'middle', sortable : true, width : '180px' }, { title : '上级分类', field : 'parentName', align : 'center', valign : 'middle', sortable : true, width : '180px' }, { title : '排序号', field : 'sort',//与数据库查询的属性一一对应 align : 'center', valign : 'middle', sortable : true, width : '100px' }]; $(document).ready(function () { //给删除按钮绑定删除事件 $("#formHead").on("click",".btn

这本书是2009年初买的，当时我刚入行一年多，在技术之外，对于个人职业发展、工程组织、业务、公司、行业都还是懵懵懂懂，有很多的困惑和思考，或不知道如何破局，或不知道自己想的是否正确。这本书可以说是在黑暗中给了我一盏明灯，给我解惑，给我信心，让我能更踏实、安心一些。我也是由此知道了作者阿朱，并且从那时就开始关注他。 直到今日，这本书出版已经9年过去了，但我觉得这本书仍然很有价值，特别是对于刚入行，或者是对项目管理感兴趣的朋友。这本书没有庞大深奥的方法论，有的是问题、场景、思考、处理。非常的贴近大多数企业应用服务公司现状，在09年，CMM/CMMI好像还没有烂透，仍然有很多公司以此标榜自己，很多公司都在努力通过认证。知道怎么过审、复评，但却仍然做不好项目，是很常见的现象。这本书的出现，说句烂大街的话，就是“填补了国内该领域的空白”。 这本书可以给你的： 软件公司组织结构中的关键角色都是谁，他们主要在干些什么、怎么组织的？（组织结构篇） 中小型项目的实施过程可能出现什么问题？怎么处理？不同角色都在做些什么？应该怎么做？（过程管理篇） 如何认识激励考核？（激励考核篇） 身处这片江湖，个人应该如何自处？（职业发展篇） 未来什么样？（未来趋势篇） 关于修行（心路成长篇） 来源： oschina 链接： https://my.oschina.net/u/991164/blog/1612964

　　软件项目的生命周期包括项目启动阶段、项目规划阶段、项目执行阶段、项目控制阶段和项目收尾阶段。项目启动阶段的任务是识别客户需求内容，对客户提出的需求内容进行可行性分析、评估和立项。项目规划阶段的任务是为拟研发的软件项目制订一个详细的解决方案。为各种可交付成果准备工作计划。项目执行阶段就是具体实施项目规划中制订的各项工作内容。项目控制阶段任务是定期监测与度量项目执行情况阶段各项工作进展情况，识别是否有偏离计划之处，对于项目执行过程中出现的问题，及时发现并采取纠正措施，以确保项目目标实现。项目收尾阶段是交付产品以及总结经验教训。 　　一、项目启动阶段 　　（1）项目识别。开发部门接到业务部门提出的客户需求后，对客户需求内容进行确认，对客户需求做可行性研究分析，通过与客户进行交流 沟通 、分析评估后，对需求的可实现内容和不能实现的内容达成一致意见，开发部门对于确认的需求内容纳人公司整体项目管理体系中管理。并配合与业务部门撰写出详细的项目需求说明书。 　　（2）项目立项。软件项目通过评审后就可以进行立项，编制需求开发任务书。软件公司接到项目任务后，首先由公司项目管理办公室按照公司IT项日管理流程，为新项目建立信息档案，编制项目代码，启动项目开发工作。 　　二、项目规划阶段 　　（1）项目范围规划。包括给出项目背景描述、项目目标描述，对项目工作结构进行分解（WBS）

概述 INTEWORK-TPA(Test Project Administrator, 以下简称TPA) 是一款集成的测试项目管理工具，它可以管理测试过程中的所有数据，包括需求、用例、样件、计划、报告和缺陷等；传统的管理方式一般基于多个软件，多是基于对单一过程的管理，缺少严谨的管理思想和过程的跟踪，作为测试项目管理的一体化解决方案，TPA 更关注于测试项目流程的管理，在一套系统中对各个过程做到有效地跟踪和覆盖。 产品介绍 • 测试需求管理 TPA 的项目管理是以需求为核心，支持查看基于需求的统计信息，例如需求覆盖情况、对应用例的执行情况及对应用例测试产生的缺陷等统计信息。 ♦ 支持第三方工具测试需求的导入 ♦ 支持测试需求和测试用例、计划、缺陷、报告关联 ♦ 强大的数据统计功能 • 测试计划管理 每个测试计划可以指定开始、结束时间、负责人和所需执行的测试用例等信息。同时提供完善的统计功能，项目管理者可以直观查看项目计划执行的状态，帮助用户减少繁琐的统计工作，把更多的精力投入到项目管理中。 ♦ 支持测试用例开发计划和测试用例执行计划的建立 ♦ 支持对不同类型测试计划完成情况的追踪 ♦ 支持将自动测试计划导入 TAE 执行 ♦ 支持手动测试计划导出 • 测试用例管理 通过新建不同层级的包或直接继承需求管理模块中的层级结构来分层管理测试用例，这个模块中的树形结构

错误一：错误的需求调研阶段，导致很多项目永远无法结束! 在软件行业，在界面设计没有正式展现给客户之前，所有的工作都处于需求调研阶段。其实建筑行业已经给我们做好了先例：客户买房子之前是先要看看样板 房和模型的，什么都看不到这房子你敢买么?除非你不是自己住! 而在我们所学的软件工程概念模型中，这是三个阶段：需求调研、需求分析、概要设计。 在客户把他们想要管理的业务模块以及与之相关的业务数据，流程，表单交付你的时候，你千万不要把这个阶段定性为需要调研结束，写出《需要规格说明 书》就可以了。大量的实践证明，在概要设计阶段所衍生出来的需求工作量是之前的5~10倍，甚至更多，因为这要看设计人员的业务沟通能力和建模水平。 有实施经验比较丰富的项目管理人员总结说，在中国实施软件项目，必须以咨询方式展开：要推出自己的方案，而不能完全按照客户来提需求作项目。这是一 种很好的解决思路，但无法解决所有实施项目的难题。这种解决方案的前提，要么项目实施者有成熟的业务模型，要么有成熟的产品(包含了成熟的业务模型)，否 则是不可能做到的。但如果没有3~5年在同一行业，同一领域的实施经验和理论总结，没有哪家IT企业能达到这样的前提要求。 其实得出这样结论的深层原因，是因为国内多数企业管理思想不成熟，更谈不上完善的业务模型，所以客户的思维一定程度是发散的，还未形成系统。甚至还 有些客户的领导，脑子中有很多新鲜的点子

大数据所设计的技术：数据采集、数据存储、数据管理、数据分析与挖掘四个环节 数据采集阶段的工具是ETL， 数据存储：结构化存储SQL和非结构化存储，半结构化存储NoSQL 比较典型的NoSQL存储包含：Google的BigTable /Amazon 的Dynamo /Apache的Hbase Hbase数据存储、MapReduce数据分析 HDFS数据访问 智慧城市参考模型： 1.感知层：智能感知能力，信息采集 2.通信网络层：传输网络 3.数据存储与管理层：资源管理 4.数据及服务支撑层：技术 5.数据应用层：应用整合 整体管理： 1.制定项目章程的内容：母受风需背，策欺妙玉批 1.项目的目的，或批准项目的理由，即为什么做这个项目 2.委派的项目经理的职责和权利 3.项目的主要风险，如项目的主要风险类别 4.项目的总体要求，包括项目的总体范围和总体质量要求 5.项目的总体里程碑进度计划 6.可测量的项目目标或成功的验收标准 7.发起人或其他批准项目章程的人员的姓名和职责 8.概论性的项目描述和项目产品描述 9.总体预算 10.项目的审批要求，即在项目的规划、执行、监控、收尾等过程中，应该由谁来做出那种审批 2.制定项目章程的作用： 1.确定项目经理，规定项目经理的权利 2.正式确认项目的存在，给项目一个合法的地位 3.规定项目的总体目标，包括项目的范围、质量、成本、进度等 4

　　对项目管理来说，回款是重中之重的，我们应该怎样把项目管理和回款关联在一起呢?最近也是做了一个项目，因为持续要不到回款，甲方还持续不断的提新需求，以此要挟导致我们非常被动，因此我想在此对项目外包提一些拙见。 　　每个项目都是需求确定了，先付款30%，项目开发完成一半时，需要再付款30%,完成上线后，甲方会给剩余的资金。基本前两个阶段都容易通过，最后阶段是经常困扰我们的，我们应该怎在做项目的时候去控制呢？ 1、如果甲方之前就有系统，并且需要把之前的数据迁移到我们的新系统之中，我们应该首先完成自己的系统，得到甲方的认证后，我们先迁移部分数据，系统能够正常使用，且数据也是正确的，这时候我们需要先得到回款之后，再把数据完全给他们迁移完成 2、如果甲方没有数据要迁移，那我们一定要把控好整个项目，不要把源码发给他们，对于项目的部署，应由我们自己人完全把控，在得到回款之后才可让他们的人去接手（项目之中是不存在甲方开发人员的） 目前想到了这些，先记录一下，后续可补充 来源： https://www.cnblogs.com/Cuimc/p/11806318.html

0.前言 本人14年12月份，从网站开发组转到了移动开发组，自己的java两年半工作经验变成了 objective-c 零经验。 2015年1月份新启动了一个移动项目，年后因为人事变动，自己从辅助开发变成了"核心"开发，目前项目基本接近尾声， 下面进行总结，希望对一些人能有帮助, 另外也希望iOS大牛进行指导 1.项目介绍 项目属于一款社区类软件，包含小组/帖子，视频，文章，评论，推荐搜索，即时通讯，好友，第三方登录/分享，推送等，涵盖 常用app的基本功能 2.项目使用的第三方开源库 http://github.ibireme.com/github/list/ios/ 整理了比较常用的iOS第三方组件，以及github上的统计 项目使用了CocoaPods(类似java中的maven)管理常用的第三方库,一些特殊的单独引用,下面介绍下比较好用的几个 1. AFNetworking 目前比较推荐的iOS网络请求组件，默认网络请求是异步，通过block回调的方式对返回数据进行处理。 需要注意的是AFNetworking对服务器返回的ContentType要求比较严格，默认只支持application/json的返回。所以可能需要添加对text/html返回的支持，否则可能无法获得返回数据。 另外就是文件上传， 这里推荐使用第二种 [formData