一项目计划：
1.项目计划并不是一边将自己所熟悉的工作内容留给自己一边不停的说这个工作量太大，让MM来协助，你要这样的话我建议你当老总找个秘书。
2.开会：
开会的目的是解决问题，不是休息，不是一个会可以开它半天，要讲究效率；开会时在讨论大家所关心的问题，而不是几个组员的问题，如果几个人有问题可以会后来解决，而
不是让大家等你们，直到你们解决完问题，才让大家散会。
二.项目管理：
1.负起责任:
让你管项目，你就得负起这个责任，不是让你的其他组员写代码而你在一边喝茶，老总问你怎么样了你只说差不多，可以了，也不是等到项目结束时你还没有将其他组员写的代
码合起来，而让他们陪着你加班。也不是你在老板面前一直说好了，而你所负责的代码直到两个项目完成时还未修改完，等到项目实施差不多时客户反馈的问题还是你的。
2.承担责任:
让你管项目，你就承担起这个责任，不是在老总面前说进展顺利，而客户将问题反馈时，你说你不是很清楚，这些代码不是我写的，是mm是写的，将责任推卸给他人。
3.人员管理:
不管出于什么目的千万不要在项目开始时让你的组员就写操作手册，那不仅是对软件开发过程的误解，而且是对组员的最大不尊重。
4.当你不了解的时候千万别乱说：
我不知道几个写代码的同事对设计模式有多少了解，如果你了解了你就不会说别人代码乱（当然我承认我对设计模式理解不透），不要在一个工程下建立很多个文件夹，然后
给每个数据表写一个CS，然后说这是你的所谓的三层架构，CS是对象的实例，不是代码的分离器，不要为了三层而三层，思路开阔点，不要老师教你一你就是一，先将自己的事做
好，这样你会赢得更多的尊重。
三.项目实施：
1.编码:
编码标志着项目的开始，在编码之前请确定好你的数据库建设是否完整，没有确定之前请不要开始操作数据库，数据库是基础，就像盖楼时的地基，如果地基没有建立好你就去
盖楼，然后在盖楼中的过程中去修补你的地基的大小，我想这样即使能盖起一栋大楼，但是他的质量会打折扣的。这样建设起来的系统最终是用户不停的给你反馈问题，你也不停
的在修改他们。
2. 客户反馈：
每个组员都有在客户那里实施项目的经历，而这种实地的实施恰恰是在客户那里解决问题，这是难得的获取新的需求的最好机会，所以每个个实施的员工应该带回来一个客户问
题反馈的文档，这些文档应该大家聚在一起探讨最好的解决办法和系统中新等等创新点，千万不要只是将问题修改了事（我到现在没看到公司其他员工写回来这样的文档，更不用
说讨论了。即使我写回来的几个项目反馈也没没有进行讨论，这点真的让我很吃惊）。
四.人际关系：
1.同事关系： 同事也是一个团体，可以说是一个冲锋在前线的的战斗队伍，大家要讲的就是以团队的力量去取胜，只有大家密切合作才能取的胜利，同事之间的关系应该是最简
单的，而且是最有战斗力的，不要讲太多的关系，关系越简单越有战斗力，希望同事不要把政府的那一套带进团队的合作里，特别是软件行业里，如果你非要讲究那些东西的话我
建议你去政府当官，那里才有你的前途，如果你在公司而且是在一个开发团队里的话你绝对是一个祸害。
2.个人修养：
大家都是二十几岁的小伙子，真是年轻气盛的时候，而且大家都是受过高等教育的，所以在年轻气盛的时候千万不要学那些泼妇行为，几个人一起说他不是，转过去又说另外一
个的不是，如果你乐此不疲的话，我真为你担心。注重个人修养。
五 个人发展:
曾经看过这样一个故事，说一只老鼠跳进一个米缸，发现有很多米，结果就放心的吃起来，越吃越胖，没想到那个米会完，知道有一天他吃完米想跳出来的时候，发现缸太深了
，他肥胖的身体已经跳不出来了。希望每个人都不要成为米缸中的老鼠，继续奋斗，这样蛋糕才能越大，你吃到的也越多。上次去全球遥感大会时给我上了一堂生动的课，因为那
里的一家参展厂商给我留下了很深的影响，有个女的用英语在那里不停的在跟不同的客户去探讨…….
祝大家前程似锦~~！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
