小项目的管理感受―――做事就是做人
1、第一周阶段总结：
目标要明确，即每一项工作达到什么目标，要提出时间、步骤、进度、质量等方面的具体要求，能够量化的则要量化，不能量化的也要有质的要求。如果没有具体要求，只是笼统地提一两句话，那就不好操作，人们不明白具体目标是什么、该朝什么方向努力，就不会有压力和动力，工作质量和效率就会受到影响。有些目标要求还要落实到担当者。
2、第二阶段总结：
必须将项目任务细化、具体化，然后落实到具体的开发人员的头上，并制定好明确的开发日程，按照开发日程严格监控项目开发进度，固定周期检查先项目进度，发现项目延迟，直接定位到哪项任务、哪个开发人员发生延迟，延迟的原因，解决方案都明确出来，并要求赶上进度的期限，在该期限内重点监控延迟的任务。
要掌握项目组当中每个人的能力水平，这样在项目开发过程当中需要调配人员开发任务的时候才得心应手，不至于新手负担太重，老手过于清闲，平衡项目当中的人员任务量，平均的推进项目进度。
本来打算项目结束之后，召集项目组的全体成员聚一次，吃个饭，不过后来想想，项目都结束了吃饭联络感情好像作用不是很大，遂决定，提前到项目的开发关键时期之前，这样可以承前启后，激励大家，同时联络感情在之后的工作能更好的团结协作。
3、第三阶段总结：
一定要保护好项目的核心主程人员，有钢使在刃上，不能让这样的成员将时间花费在文档，和重复性的编码工作上，让他们主要负责解决技术难题。
4、第四阶段总结：
开发之前就要确定好开发环境版本，尽可能提早真机或实际情况下的测试，尽早提供系统的原型给客户演示，找客户确认，不断地找客户确认，跟紧客户的思路。
哎！郁闷！项目出现问题了，验收阶段，客户提出了一些之前没有的需求，还说这些是我应该早就想到的，崩溃，哪有项目开发的人主动增加客户的需求呢！真受不了这个四川老了，当初需求一点没有提，现在验收阶段提出了一堆问题，闹死个心了，跟开发人员一协调需要整个调整程序结构，连带着开发需要两周时间来完成，这个客户却只给我两天还是周末，要求项目按原来流程走，啊！！！我该怎么办？？……………………………………问题解决了：只不过要加点班，全当吸取教训积累经验了。
5、第五阶段总结：
但凡是设计项目需求的相关问题都要以邮件的方式进行确认，并且邮件的标题就要写明：项目名称-需求内容，如此做就是为了日后方便查找，在项目需求出现冲突的时候，可以把又见拿出来作为证据，切记这一点，凡是确认的东西都要保留文档，形成资料。
每个不经意提到的要求，都要进行记录并分析，能不能形成正式需求，能够形成的，就及时确认，不能形成的也要留好记录，写明缘由，作为以后该需求废除的依据。
其实，反思自己，也有很大责任，存侥幸心理，对项目的理解不够，归根结底还是项目的经验不足，把握项目的需求能力欠缺，以后要在这个方面加大投入精力，涉猎各个方面的项目。更要站在需求分析师德角度上来考虑问题，而不是站在一个项目开发者的角度，这样就更能把握项目的需求，如果一个项目坐下来自己都认为用着麻烦，或者没什么用的时候，那么这个项目肯定很失败，及时客户勉强接受，那么要想达到长期合作希望就很渺茫。
6、第六阶段总结：
项目开发之初就要明确的问题：项目开发所选用的语言、开发环境的版本、系统上线之后安装的系统环境（操作系统版本、辅助的软件版本环境等），以上这些问题是最基本的需求要明确的问题，如果开发之初稀里糊涂，到项目结束的阶段很可能造成开发、上线、以及后期维护一系列的问题，而且造成这些问题的责任还都要项目承接开发方来背。
领导一定要有威严，对待下属，办不好做不完的事情，可以再给一次机会，如果还做不好，必须采取惩罚手段（逐出项目组或直接辞退），对待下属切不可一再的纵容，否则天长日久就没人听你的了。
项目终于进入到验收阶段了，由于质量控制做的还不错，基本没出现什么问题，准备周末大家伙一起聚个餐，增进一下感情，算是宣告项目圆满结束吧！呵呵！
7、第七阶段总结：
项目结束验收该准备的东西有很多，系统需要统计的数据也有很多，诸如：系统代码行数、系统画面数、系统测试bug数、系统测试bug的详细记述列表、系统开发环境版本、最终的可执行程序、详细设计文档等。（注意：这些文档都要仔细整理，验收的时候要及时拿出来讲解）
项目验收会议注意事项：
a、首先一定要明确系统的功能范围，固守住这个范围，系统就实现哪几项功能，其他的一概不知道，分清自己的职责，不是自己的活，一丁点都不要沾，一旦沾了，就很有可能会扩大化，进而不可收拾，让人认为这也是你项目中的一个部分了。
b、项目验收会议上，作为项目开发的乙方，只需要做好两件事情：1、详细介绍整个项目周期，每段时间内都完成了哪些工作，如果有延迟需要阐述延迟的原因，但切记不要说由于哪一方的原因，而只针对问题点来进行阐述。2、介绍系统实现了哪些功能，每个功能是怎么样的，系统达到一个什么样的性能指标等。3、都有编写了那些文档，每份文档的内容都是什么，做个简单的阐述。4、详细阐述都做了哪些方面的测试，测试的点数是多少？测试出的bug都有哪些？现在这些问题都是否存在（这方面设计产品的质量，是客户所关心的）。阐述完成以上四点之后，就不再发言，配合项目的发起人员来补充说明。
c、如有人提出问题，首先判定是否在本项目范畴以内，如果不在，直接说不清楚、不知道，即便心里很明白也说不清楚，直接说非本项目范畴，不清楚无法回答；如果在本项目范围内，则直接阐述本项目的该项需求具体是什么样子的，现在项目实现的是什么样子的，已经达到了当初项目的需求，不要被人提出的问题带偏了轨道。总之，记住一点，就是直说本项目以内的东西，相关的和以外的内容一概不谈。
d、如有人提出一个功能点的时候，首先判断是否是本次项目需求以内的，如果是则作答，如果不是直接反驳此功能点并非本次项目需求，如果需要可以作为下期项目的需求来做，本次项目并没有。
e、验收会议上，把了解项目的人划为一方，不了解项目的人划为一方，做总结发言的时候就说了解项目的人能听懂的本项目的术语，回避说不了解项目的人懂的相关术语及业务内容的话，要让不懂项目的人提不出来问题，懂项目的人，都能够满意现在的实现已经达到了开始的需求。
f、注意发言时的技巧（任何会议的场合只要发言都要如此）：1、开场白，再简单的回忆也要有开场白。2、语速要慢、声音要大、讲解PPT的时候，一页一页的讲，注意听者的表情（听者的表情能够直接反映出他们是否能够理解你所说的内容，是表情木然，还是轻松点头）。3、讲解的时候重点突出项目最开始的设计意图、着重点是什么（这样做就是为了圈定项目的范围，使得之后在讨论的时候不至于提出偏离项目的问题）。4、明确会议的目的，对偏离会议主题的讨论，及时作出定义迫使其停止（不至会议拖沓，失去中心进而缩短会议时间）。
g、会议上有发言的时候，一定要提前准备，进行策划，从会议的流程上，发言的内容以及发言的技巧上面进行安排。
今天开了项目的验收会议，虽然通过了，但是对自己的表现很不满意，事出突然没做准备是一个原因，再有就是发言的时候声音太小，语速太快，听者表情木讷。说了一些项目相牵连的方面，涉及到了验收领导业务内的东西，勾起了他们表现业务能力的欲望，提了很多不相关的问题，偏离了验收这个会议的主题，致使会议时间严重拖长。很失败！前事不忘后事之师！希望通过总结下次再有机会的时候好好表现一下！呵呵！！
本文出自 “一路悠扬” 博客，谢绝转载！