小公司如何进行项目管理？

[SlipStupig]

现在公司人非常少，目前就两个人写代码，产品主要面向的是企业甲方客户。
老板意思倾向采用的很传统的方法进行项目管理，而目前采用的是提前把要做的功能列好，然后去卡时间。

总感觉这种方法怪怪的，主要来自几个方面 ：

1. 未来需求变更导致的不确定性, 导致交付难产
2. 前期可能预估和实际施工有偏差， 导致 delay 或者成本不确定性
3. 竞品特性可能导致需求变更
4. 多客户差异化定制，可能导致工程维护困难

大家有什么更好的方法能解决这些问题呢？

[everettjf]

感觉 Scrum 挺适合小公司的。何况大公司也有很多小团队。

例如两周发一次版本，小步快跑。

[yimity]

变更的部分不能重新计划时间么？

[msg7086]

这又是个 million dollar question 了。
实际并没有银弹，就算用 Scrum，也很有可能严重滑坡项目玩崩。
但是总之先从 Scrum 开始试行吧。

[leeg810312]

不是什么都可以靠技术解决。不同客户定制可以用版本管理工具进行分支管理。需求变更和计划实际偏差，需要项目管理和商务共同发挥作用，计划和实际本来就不可能完全一致，只能是尽力减少差距。如楼上所说用 scrum 是一种可行的方法，短周期发布，可以让客户很快看到阶段成果并试用，能马上得到反馈和需求的变更，下一个版本客户就可以看到变化，对于双方的体验都好。重大的变更不要立即承诺，要进行技术评估后再沟通客户，需求变更无论大小都要签字确认，以免扯皮，然后计划也要相应重估，向客户说明。不能按期交付，要提早和客户协商，商务应当发挥作用，不是拉来客户后面就不管了，要是很弱势的乙方，那就开发人员多加班吧。

[php01]

两个人也管理，是有管理瘾吗

[8355]

你们存在的问题不是项目管理 而是需求管理 修改需求必然需要时间进行需求兼容
解决的办法就是要需求控制 , 不要一句话改需求 , 关键看你怎么跟客户去博弈. 如果甲方绝对权威 你做什么都没用.
你能做的只是把你认为不合理的需求或者可能变更的需求放在最后做 做之前跟客户重新确认.

[likeshu]

两个人自觉吧，每周搞个站会可以了。

[nikymaco]

产品初期需求不确定改来改去是很正常的事，因而工作感觉变得没有章法，慢慢习惯就好了。
所以这个阶段工作节奏就变得很重要，人员少就不要搞太复杂的管理流程了，生产方面尽量做到能自动化就自动化，有事当面沟通清楚。
进度方面，不急的时候就每周做一次周报，给老板汇报知晓一下，急的时候就每天做一次简报。省时省心省力。

[huage]

这时候一个优秀的项目管理者就很重要啦。建议引入 PMP 中的项目管理思想，在实际应用中进行融会贯通。

[huage]

所有事情以邮件、正文文档等形式记录下来，发送给双方确认。
事情可以口头的非正式沟通，但是记录必须是正式的，变更必须得到双方高层允许批准才能发生。