c******n
发帖数: 16666 | 1 理想状态下 这2个问题都不该发生
次理想状态下 有足够时间在弄可行性分析和其他啥额外准备工作的时候剔除这些不稳
定因素
实际生活中 根本做不到啊。。
我们这边本来就是这么几个人 提需求和提供数据的人本身自己有时候都没搞清楚要弄
什么。。
我这边又忙得要死 很多项目同步进行，压根没时间细查，一直都是假定他们按照最开
始我们讨论结果 在我给的模板上，把数据准备好了。
但是往往只有到真要开始做了才发现 我日这都是什么鬼东西啊，要么缺东西，要么整
个他们自己理的逻辑都是错的。像我现在手头一个，之前也谈得不错，要做个互动手册
，逻辑略微复杂。我让他们整理个简单的步骤列表，也别上flow chart了，结果证明这
是个错误。。尼玛逻辑混乱不说了，丫整理出60多步都是大步骤，下面细的啥都没写，
真要做出来要有150多步。凭空内容多了，逻辑多了不说，尼玛UX都有大问题了。。
而且一个个都是大忙人，要么wfh要么出去开会，这些细步骤怕是还我要自己推出来 |
l*********s
发帖数: 5409 | 2 always take the words of your other party with a big grain of salt, ask them
to prepare design documents beforehand. |
c******n
发帖数: 16666 | 3 比较悬 下次push下试试
对方都是研究人员
每次给的逻辑链都是有问题的 各种boundary condition从来不考虑。。。
them
【在 l*********s 的大作中提到】
: always take the words of your other party with a big grain of salt, ask them
: to prepare design documents beforehand.
|
d******e
发帖数: 2265 | 4 agile 啊
【在 c******n 的大作中提到】
: 理想状态下 这2个问题都不该发生
: 次理想状态下 有足够时间在弄可行性分析和其他啥额外准备工作的时候剔除这些不稳
: 定因素
: 实际生活中 根本做不到啊。。
: 我们这边本来就是这么几个人 提需求和提供数据的人本身自己有时候都没搞清楚要弄
: 什么。。
: 我这边又忙得要死 很多项目同步进行，压根没时间细查，一直都是假定他们按照最开
: 始我们讨论结果 在我给的模板上，把数据准备好了。
: 但是往往只有到真要开始做了才发现 我日这都是什么鬼东西啊，要么缺东西，要么整
: 个他们自己理的逻辑都是错的。像我现在手头一个，之前也谈得不错，要做个互动手册
|
d******e
发帖数: 2265 | 5 agile 啊
【在 c******n 的大作中提到】
: 理想状态下 这2个问题都不该发生
: 次理想状态下 有足够时间在弄可行性分析和其他啥额外准备工作的时候剔除这些不稳
: 定因素
: 实际生活中 根本做不到啊。。
: 我们这边本来就是这么几个人 提需求和提供数据的人本身自己有时候都没搞清楚要弄
: 什么。。
: 我这边又忙得要死 很多项目同步进行，压根没时间细查，一直都是假定他们按照最开
: 始我们讨论结果 在我给的模板上，把数据准备好了。
: 但是往往只有到真要开始做了才发现 我日这都是什么鬼东西啊，要么缺东西，要么整
: 个他们自己理的逻辑都是错的。像我现在手头一个，之前也谈得不错，要做个互动手册
|
w********m
发帖数: 1137 | 6 daily scrum吧，
找一个认识的哥们做scrum master。
首先定个两周的sprint，先从story到todo。确定好issue的dependency。
对方不能完成的记录backlog。
然后项目黄不黄，都跟你无关了。 |
c******n
发帖数: 16666 | 7 恩 你们说的有道理
我本来是很反对这个的 怕给自己多事
不过现在看来 这个同样可以作为工具反制他人！
【在 w********m 的大作中提到】
: daily scrum吧，
: 找一个认识的哥们做scrum master。
: 首先定个两周的sprint，先从story到todo。确定好issue的dependency。
: 对方不能完成的记录backlog。
: 然后项目黄不黄，都跟你无关了。
|
g*****g
发帖数: 34805 | 8 需要一个 PM定 scope, 人一多，PM的价值就体现出来了。完不成任务不要紧，责任清
楚。 |
|
c******n
发帖数: 16666 | 9 恩 我原老板/PM 跳槽跑了
不光pm没了
他之前的活也都是我在做
新老板忙着站稳脚跟烧三把火ing。。。
【在 g*****g 的大作中提到】
: 需要一个 PM定 scope, 人一多，PM的价值就体现出来了。完不成任务不要紧，责任清
: 楚。
|
c*********e
发帖数: 16335 | 10 哎，碰上个没编程经验的老板，你就等着奇葩事情发生吧。
【在 c******n 的大作中提到】
: 理想状态下 这2个问题都不该发生
: 次理想状态下 有足够时间在弄可行性分析和其他啥额外准备工作的时候剔除这些不稳
: 定因素
: 实际生活中 根本做不到啊。。
: 我们这边本来就是这么几个人 提需求和提供数据的人本身自己有时候都没搞清楚要弄
: 什么。。
: 我这边又忙得要死 很多项目同步进行，压根没时间细查，一直都是假定他们按照最开
: 始我们讨论结果 在我给的模板上，把数据准备好了。
: 但是往往只有到真要开始做了才发现 我日这都是什么鬼东西啊，要么缺东西，要么整
: 个他们自己理的逻辑都是错的。像我现在手头一个，之前也谈得不错，要做个互动手册
|
s********r
发帖数: 394 | 11 你说的确实是软件研发的常态，我们常接外包项目，深有同感，有些项目甚至做到一半
客户公司就倒闭了，这些超出技术的问题更是闹心。
我们的解决方案就是精简核心功能，迅速推出mvp，根据客户反馈来进行迭代，像一般
的erp，crm系统，第一版通常在2-3周由首席工程师写好，马上部署到prod server，同
时设好staging，之后迭代周期一般为2-3天。
这时候如果客户挂了，损失也很小。如果需求大变，也只是后端改写，前端设计和ios/
android工程师在前期根本不介入。用户反馈进来后才开始写测试脚本，这一阶段基本
前期所有代码都会大改和重写，但架构在首三周已经被搞定，这时候很容易就加进去辅
助人员，比如测试，前端，应用，数据库人员。
这样分阶段实施，阶段成果都是可验证的，每期收款也有依据了。
客户介入早要注意数据保护，因为数据表变动也很大，要保证数据表变化不能造成数据
损失
★ 发自iPhone App: ChineseWeb 8.7
【在 c******n 的大作中提到】
: 理想状态下 这2个问题都不该发生
: 次理想状态下 有足够时间在弄可行性分析和其他啥额外准备工作的时候剔除这些不稳
: 定因素
: 实际生活中 根本做不到啊。。
: 我们这边本来就是这么几个人 提需求和提供数据的人本身自己有时候都没搞清楚要弄
: 什么。。
: 我这边又忙得要死 很多项目同步进行，压根没时间细查，一直都是假定他们按照最开
: 始我们讨论结果 在我给的模板上，把数据准备好了。
: 但是往往只有到真要开始做了才发现 我日这都是什么鬼东西啊，要么缺东西，要么整
: 个他们自己理的逻辑都是错的。像我现在手头一个，之前也谈得不错，要做个互动手册
|
