小项目的管理感觉———作事就是作人

一、第一周阶段总结： 

        目标要明确，即每一项工做达到什么目标，要提出时间、步骤、进度、质量等方面的具体要求，可以量化的则要量化，不能量化的也要有质的要求。若是没有具体要求，只是笼统地提一两句话，那就很差操做，人们不明白具体目标是什么、该朝什么方向努力，就不会有压力和动力，工做质量和效率就会受到影响。有些目标要求还要落实到担当者。

 

二、第二阶段总结：

      必须将项目任务细化、具体化，而后落实到具体的开发人员的头上，并制定好明确的开发日程，按照开发日程严格监控项目开发进度，固定周期检查先项目进度，发现项目延迟，直接定位到哪项任务、哪一个开发人员发生延迟，延迟的缘由，解决方案都明确出来，并要求遇上进度的期限，在该期限内重点监控延迟的任务。

     要掌握项目组当中每一个人的能力水平，这样在项目开发过程中须要调配人员开发任务的时候才驾轻就熟，不至于新手负担过重，老手过于悠闲，平衡项目当中的人员任务量，平均的推动项目进度。

    原本打算项目结束以后，召集项目组的全体成员聚一次，吃个饭，不事后来想一想，项目都结束了吃饭联络感情好像做用不是很大，遂决定，提早到项目的开发关键时期以前，这样能够承前启后，激励你们，同时联络感情在以后的工做能更好的团结协做。

三、第三阶段总结：

      必定要保护好项目的核心主程人员，有钢使在刃上，不能让这样的成员将时间花费在文档，和重复性的编码工做上，让他们主要负责解决技术难题。

四、第四阶段总结：

    开发以前就要肯定好开发环境版本，尽量提前真机或实际状况下的测试，尽早提供系统的原型给客户演示，找客户确认，不断地找客户确认，跟紧客户的思路。

哎！郁闷！项目出现问题了，验收阶段，客户提出了一些以前没有的需求，还说这些是我应该早就想到的，崩溃，哪有项目开发的人主动增长客户的需求呢！真受不了这个四川老了，当初需求一点没有提，如今验收阶段提出了一堆问题，闹死个心了，跟开发人员一协调须要整个调整程序结构，连带着开发须要两周时间来完成，这个客户却只给我两天仍是周末，要求项目按原来流程走，啊！！！我该怎么办？？……………………………………问题解决了：只不过要加点班，全当吸收教训积累经验了。

五、第五阶段总结：

    但凡是设计项目需求的相关问题都要以邮件的方式进行确认，而且邮件的标题就要写明：项目名称-需求内容，如此作就是为了往后方便查找，在项目需求出现冲突的时候，能够把又见拿出来做为证据，切记这一点，凡是确认的东西都要保留文档，造成资料。

    每一个不经意提到的要求，都要进行记录并分析，能不能造成正式需求，可以造成的，就及时确认，不能造成的也要留好记录，写明原因，做为之后该需求废除的依据。

其实，反思本身，也有很大责任，存侥幸心理，对项目的理解不够，归根结底仍是项目的经验不足，把握项目的需求能力欠缺，之后要在这个方面加大投入精力，涉猎各个方面的项目。更要站在需求分析师德角度上来考虑问题，而不是站在一个项目开发者的角度，这样就更能把握项目的需求，若是一个项目坐下来本身都认为用着麻烦，或者没什么用的时候，那么这个项目确定很失败，及时客户勉强接受，那么要想达到长期合做但愿就很渺茫。

六、第六阶段总结：

    项目开发之初就要明确的问题：项目开发所选用的语言、开发环境的版本、系统上线以后安装的系统环境（操做系统版本、辅助的软件版本环境等），以上这些问题是最基本的需求要明确的问题，若是开发之初稀里糊涂，到项目结束的阶段极可能形成开发、上线、以及后期维护一系列的问题，并且形成这些问题的责任还都要项目承接开发方来背。

    领导必定要有威严，对待下属，办很差作不完的事情，能够再给一次机会，若是还作很差，必须采起惩罚手段（逐出项目组或直接辞退），对待下属切不可一再的纵容，不然天长日久就没人听你的了。

    项目终于进入到验收阶段了，因为质量控制作的还不错，基本没出现什么问题，准备周末你们伙一块儿聚个餐，增进一下感情，算是宣告项目圆满结束吧！呵呵！

七、第七阶段总结：

        项目结束验收该准备的东西有不少，系统须要统计的数据也有不少，诸如：系统代码行数、系统画面数、系统测试bug数、系统测试bug的详细记述列表、系统开发环境版本、最终的可执行程序、详细设计文档等。（注意：这些文档都要仔细整理，验收的时候要及时拿出来说解）

项目验收会议注意事项：

a、首先必定要明确系统的功能范围，固守住这个范围，系统就实现哪几项功能，其余的一律不知道，分清本身的职责，不是本身的活，一丁点都不要沾，一旦沾了，就颇有可能会扩大化，进而不可收拾，让人认为这也是你项目中的一个部分了。

b、项目验收会议上，做为项目开发的乙方，只须要作好两件事情：一、详细介绍整个项目周期，每段时间内都完成了哪些工做，若是有延迟须要阐述延迟的缘由，但切记不要说因为哪一方的缘由，而只针对问题点来进行阐述。二、介绍系统实现了哪些功能，每一个功能是怎么样的，系统达到一个什么样的性能指标等。三、都有编写了那些文档，每份文档的内容都是什么，作个简单的阐述。四、详细阐述都作了哪些方面的测试，测试的点数是多少？测试出的bug都有哪些？如今这些问题都是否存在（这方面设计产品的质量，是客户所关心的）。阐述完成以上四点以后，就再也不发言，配合项目的发起人员来补充说明。

c、若有人提出问题，首先断定是否在本项目范畴之内，若是不在，直接说不清楚、不知道，即使内心很明白也说不清楚，直接说非本项目范畴，不清楚没法回答；若是在本项目范围内，则直接阐述本项目的该项需求具体是什么样子的，如今项目实现的是什么样子的，已经达到了当初项目的需求，不要被人提出的问题带偏了轨道。总之，记住一点，就是直说本项目之内的东西，相关的和之外的内容一律不谈。

d、若有人提出一个功能点的时候，首先判断是不是本次项目需求之内的，若是是则做答，若是不是直接反驳此功能点并不是本次项目需求，若是须要能够做为下期项目的需求来作，本次项目并无。

e、验收会议上，把了解项目的人划为一方，不了解项目的人划为一方，作总结发言的时候就说了解项目的人能听懂的本项目的术语，回避说不了解项目的人懂的相关术语及业务内容的话，要让不懂项目的人提不出来问题，懂项目的人，都可以满意如今的实现已经达到了开始的需求。

f、注意发言时的技巧（任何会议的场合只要发言都要如此）：一、开场白，再简单的回忆也要有开场白。二、语速要慢、声音要大、讲解PPT的时候，一页一页的讲，注意听者的表情（听者的表情可以直接反映出他们是否可以理解你所说的内容，是表情木然，仍是轻松点头）。三、讲解的时候重点突出项目最开始的设计意图、着重点是什么（这样作就是为了圈定项目的范围，使得以后在讨论的时候不至于提出偏离项目的问题）。四、明确会议的目的，对偏离会议主题的讨论，及时做出定义迫使其中止（不至会议拖沓，失去中心进而缩短会议时间）。

g、会议上有发言的时候，必定要提早准备，进行策划，从会议的流程上，发言的内容以及发言的技巧上面进行安排。

今天开了项目的验收会议，虽然经过了，可是对本身的表现很不满意，事出忽然没作准备是一个缘由，再有就是发言的时候声音过小，语速太快，听者表情木讷。说了一些项目相牵连的方面，涉及到了验收领导业务内的东西，勾起了他们表现业务能力的欲望，提了不少不相关的问题，偏离了验收这个会议的主题，导致会议时间严重拖长。很失败！前事不忘后事之师！但愿经过总结下次再有机会的时候好好表现一下！呵呵！！