在四月份在和一个朋友合伙接了一个软件项目，项目的基本功能 是：用户做好每个员工的工资表明细，给每一个员工发送工资表邮件。
用户要求，要实现项目高度灵活，通用，易于扩展，接下来经过一个月的时间折腾，实现项目所要求的基本功能。最终的结果是，界面差强人意都不够，勉强实现功能，没有架构，也不便扩展，自己做的东西，自己都不满意，更谈不上客户显认可。以此为背景，切合自己的实际谈谈对小型项目管理的看法，欢迎大家拍砖，抛砖引玉吧。首先来谈一下经验教训。
一， 结合自身的技术功能，合理提出项目的目标，是保证项目顺利完成的前提。把用户的需求分类，满足用户的基本需求，满足用户提出的一到两个兴奋需求。一开始，我 们的目标是：运用WPF富客户端技术，建立灵活通用界面美观的应用，应用MVVMLight框架，整体架构分为接口层，实现层，通用层，数据通讯层，业务逻辑层，表现层。在实现做的过程中，由于项目开发成员其中的一个，是新接触WPF，另一个对MVVMlight应用不够成熟，最终项目接口层添加了基本的接口，新增加的需求也没有严格添加接口方法，采用mvvmlight 时，上传文件文本框不显示上传文本框路径，邮件服务器密码不能实现双向绑定，最终mvvm结构被打破，最后架构混乱，无所谓结构。作为小型项目，功能不复杂，开发周期短，如果采用多层架构，运用新的技术，无疑增加了项目的不确定因素，增加了项目的复杂度，最终导致项目不可控，在客户看来，就这么几个小功能一个月还没搞定。
二， 优先培训，事半功倍。在实际开发中，项目成员不可能每一项目技术都精通，在开发人员对某一个技术没有掌握时，结果业务逻辑层做好后，UI不会做，不得在等UI层做好后，整合项目调试，而我对MVVM应用不成熟，在做的过程碰到技术问题，一时解决不了，延误了项目进度。最后一个周末，他对我进行SVN的培训，我对他进行WPF界面培训，做出界面层数据绑定的例子，都需要好几天，如果事前培训，则事半功倍。
三，整理好需求用例，明确项目执行完整过程，有利于项目的整体设计，是减少编码量的重要方法。我们的项目分工是，我写需求用例，他负责需求调研，最终的结果是，经过两个人带出来的需求用例，存在重复和重叠部分，最终在结构设计的时候也存在重叠的部分，增加了工作量。
四，进行有效的沟通，是保证项目进展的有效办法。有实际沟通过程中，最好进行当面沟通，最有效果，不建议采用即时通讯工具，这样一方在编码设计，一方又问问题，聊天一方打乱了另一方的思路，另一方面往往在设计而忽略了沟通，起不到实际效果。
建议：
1，在同一地点开发，这样有利于解决问题，减少沟通时间、技术成本。同时，双方在碰到问题时，多人在一起，有利于结队编程，有利于发现的解决问题。
2，制订项目计划，有效评估项目风险，制订项目功能优先级。