Hackathon 敏捷项目管理的艺术

启动并推进任何事项会遇到的『问题or困扰』

解决的套路
如何两天做一个产品出来?
首先, 要明确『如何达到目标』, 即怎么样才算『赢』? 定义清楚什么算赢才能全程走对方向.

自己常常有个标准, 会认定事情必定要如何如何做才算"正道". 但其实如果这个正道无法让你赢, 你就要面对现实去调整自己的路数. 改成『会赢』的路数. 即使你不爽那些"会赢的人"的做法, 你也要去观察并分析他们提取出赢的套路, 然后去实践.
只要还『参赛』说明你还选择置身其中, 不论是不想还是不敢离开, 改成能赢的路数吧. 你认为的"正道"不重要, 个人干不过系统的. 更何况你凭啥保障你认为的正道就是真理.
妈蛋上面的建议真是让人听着太不爽了很理性很现实但是听着感觉很操蛋
所以, 我们改路数, 但取『折中』做法. 我还是要『执行我的理念』却也要做到『赢的办法』, 两者都兼顾. 会累, 但能力会提升吖, 算磨炼协作能力吧
注意咯, 虽然用『折中做法』, 但还是要将更多的时间跟精力妥协给自己不认同的『真正能赢的办法』

做时间管理的整体思路跟背后原因
首先, 摸清『目的』
你要赢, 有哪些因素能帮你最后赢这件事. 现实情况优先, 你自认为的理念往后排排

估算

先估算出"整体"一共有多少时间available去完成这产品, 第一版的无bug可用版

估算出『总体时间』后, 罗列出"必须要完成的任务"并估算这些任务要花多少时间, 包括吃喝玩乐休息等时间都要估算. 最后大概能算出"真正"有多少写代码时间

为了赢抓重点

然后要注意别安排过多的无法完成的任务, 应该抓住『最主要』的功能保障能做完. 这个挺反人类的, 但务必要做到. 先做出『第一版可用的产品』是最重要的

千万别把自己推到"无法完成任务"的境地, 果断砍掉大部分『花哨的』, 只做『必要的』由此看出, 一开始就定义清楚『怎样才算赢』多重要, 它帮忙定义出什么是『必要的』

实战阶段如何安排

抓出项目中『最大的风险』并在实作阶段优先解决

这样任务就能顺利推进了. 分析出项目会遭遇的『最有风险的步骤』一开始就解决掉, 就能一路打顺风球了

解决了最大风险再去『铺基础』做主干部分

填补细节

在完成一版能完整跑下来的产品后, 再去动小地方, 修饰细节以及做小功能

找实际用户测试产品

自己一个人or even三四个人无法测出很多产品问题或bug, 要是有50个真实用户使用, 必定能发现完整些的问题. 然后及时修掉, 不能等『评委』用时发现烂掉, 就GG了

防止预期外的事件

无论面对的是『大』『中』还是『小』项目, 如何管理项目? 诀窍为何?

假设有三个月时间

就是那种"不做会死的"任务, 那种"在最后如何没有搞定就死定"的功能一定要第一时间完成并排除此危机

就是must have以及should have这些功能, 产品能完整跑下来的必要功能.

慢慢修补添加, 让产品迭代演化起来

再次强调, 以上一通"猛操作"之前, 定义清晰『什么才算赢』才能确保你不会走偏

整体思路

先定义『成功』, 然后搞清楚 "什么是风险" "什么是主线" "什么是支线" , 才能排出优先顺序
根据『成功』的定义排定优先级, 先解决风险, 再做主干
保留三分之一的测试时间
先主干, 再支线
果断砍掉不必要功能, 确保做出能用产品而不是花哨产品, 只做must have/should have. 砍掉could have/nice to have. 等最后有时间再补上.

项目是活的

这是一个需要大写加粗的真相. 做真实项目才会发现跟你一开始的预想是不一样的. 项目自己会在真实环境中演化.

你要准确抓住此项目花的工时与人力. 不, 你是没办法抓的. 因为项目是活的. 你唯一有办法抓的是, 仅仅是"什么是『成功』"这个定义而已. 紧紧把握怎样才叫"这项目是成功的", 然后尽可能去逼近这个成功. 这是你唯一能把握的.

谈谈为啥留那么多测试时间

人性弱点根深蒂固, 别傻傻反抗. 了解并分析出人性弱点后, 利用它. 通过安排来"避开"或"利用"它才是聪明的活法

反正时间都会被浪费掉, 那么就掉个顺序, 保障时间浪费在『安全的事情上』

所谓我狠起来, 连自己都套路

以上是管理项目/时间的方法分享能用在人生各项事务上哦