关于项目开发管理上的个人总结 Jesseliu

2019-12-01 本文已影响0人 jesseliu

一直以来我还是更致力于训练自己的逻辑思维、抽象思维能力以及构建属于自己的产品方法论，再加上我更愿意自己从产品设计到开发完成整个流程，不太习惯于协同工作，同时也发现自己多少受了葫芦的一些影响，更重创意以及玩法，而不是太注重开发上的落地、管理和推进，所以想要做的更好还是要补足还不够的部分。

因为关于项目的书也没太关注过，我的方向更偏向于技术和玩法向，这里只是为了整理出自己的一些思路出来做个存档。

1、对人的了解

我喜欢处理事情大家以沟通商量的态度去做，但放到项目里其实很容易就成众矢之的，如果你是处于完全管理的情况下还好，当你并不处于这么一个位置的情况下，人际关系复杂，有的人性格强硬不好沟通，有的人不愿意承担，希望别人把事情做的更全面，有的人把所有事情都推到某一个人身上，这时候就需要有足够的耐心，要吗让每个人对自己的项目都具有主动性，让每个人在项目中感觉到自己的重要性，而不仅仅只是完成一份工作，要吗自己做到最细，深入到每一步都掌控住，但人的精力毕竟有限，只是单一项目还好，如果手上有很多线，那么很容易就会遗漏掉一些东西。

2、对时间的了解

单个项目时你只需要串性处理就可以了，但面对多线时一定要做好自己的时间规划，不要被某个单线所左右，找到主要的线索跟。

3、对技能的了解

一个产品涉及到不同的岗位，每个岗位之间有一定技术壁垒，就像我自己虽然有开发基础，但是听起JAVA的那一套还是有听睡着的感觉，所以一定要对开发或者设计等等都有一定程序的理解，至少某些名词或者逻辑要搞清楚，比如我本行做设计，那么设计的掌控我就可以做到完全不用担心。

4、对流程的了解

其实这是我最看重要熟悉的一点，这也是我之所以要写这个思路存档的原因。

对于项目我整理出来了最重要的三问：

1、给出问题，有什么问题需要解决？

2、给出解决方案，怎么解决？是否需要其它人员的参与？

3、给出期限，什么时候可以解决？

这是我认为的在产品开发中比较好的流程：

1、需求讨论

主要角色：产品、主程、其它人员

产品讲解功能需求，主程去判断需要什么人员，然后由主程召集对应人员参与讨论，看看对于功能上有什么异议，这个时期可能因为对功能的实现方式的不确定会不断的增加关联人员进来，所以暂时还是不要进行排期工作。

2、排期讨论

主要角色：所有人员

当所有相关人员都已经了解了产品需求后，再开始进行排期讨论，每个人列出自己手上的项目，如果这些项目不重要，那么可不可以暂缓，如果手上事情重要，那么给出日期，这里的基本步骤线性图是这样的：

“整理每人手上的工作—某些工作能不能交给别人解决-现有工作什么时候完成-什么时候开始进行新工作-给出时间-为什么需要这么长时间”

当然可能出现中间插入的事情，所以要为每个人的排期多预留一部分时间

3、立项

主要角色：所有人员

准备好相关的资料，主要是以下几点

1、为什么要做

2、产品功能讲解

3、排期

4、人员和资源需求

4、开发阶段

主要角色：产品、开发

这个阶段基本就是重复三问就可以

5、测试

主要角色：产品、测试、开发

由开发人员提交需求给测试人员，并给出测试用例，测试人员根据测试用例完成测试报告，出现问题交给开发人员进行解决，没有问题提交项目管理人员进行上线。

6、上线并回测

主要角色：产品、测试、开发、运维

项目管理人员把产品提交上线后还要进行回测，这里是为了避免生产环境和测试环境不一致有可能导致产品出现问题。

5、对角色的了解

因为某些公司对于角色划分做不到很清晰，也就导致哪些事情该什么人做并没有清晰的界限，所以能忙的过来就尽量多做些事情吧。

6、对业务的理解

产品一定要对自己原型的业务了解透彻，哪怕在一开始你只知道自己想要实现一个什么功能，当然如果你有一些开发经验的话最好能有一套自己认为的实现逻辑，然后在跟开发沟通的过程中再深入了解到整个业务的实现逻辑，慢慢把自己需要的功能是怎么实现的形成一个清晰的思路。

7、对前景的了解

很多项目走着走着就容易转牛角尖，逐渐意识不到自己未来作出的这个东西有没有价值，这其中包括对项目的前景、个人的前景、市场方向的前景，不要做没有价值的事情。

8、对成本的了解

公司需要考虑成本和收益，如果做一个不够优秀的功能却需要大量的开发资源投入，或者说基于现有的资源只能做到这个样子，不是最优解但受限于资源只能做到如此那么就要考虑一下应不应该做了。

因为最终我的兴趣点还是专注于产品的玩法，所以这些只是让自己的思路更清晰一些，具体流程还是看各自的公司，但当你的产品思路与整个公司的流程规范有冲突的话要看个人选择。