1
xkeyideal 2019-05-13 15:18:56 +08:00
福报厂的做好就很好,PM 必须会写代码。
很大程度上,研发的劳动强度,取决于 PM 修改需求的速度 |
2
coderY 2019-05-13 15:31:19 +08:00
最好优先确定网站整体风格再出 demo。譬如固定下拉框的样式和交互,凡是页面上的下拉框全用这种样式和交互。作为一个前端,因为某一个无足轻重,无关痛痒的 UI 组件要调整底层 DOM 交互是很痛苦的
|
3
treelion OP |
4
treelion OP @coderY 是的,我也是这个意思。
我刚来的时候就问过前端用什么框架,也给 UI 说过最好找前端同学沟通确定清楚这些,然而领导好像并不知道有这么一回事,听了就过了,再也没见他提过……甚至提的要求越发过分,让 UI 出所有页面的完整 DEMO。 |
5
loveour 2019-05-13 16:06:42 +08:00
特别痛恨某种情况,产品其实希望达到的效果,A 方式可以,B 方式也可以;然后出于他好心也好无意也好,定了 A 方式,其实实现起来特别麻烦,B 方式很简单,偏偏没采用。要说 A 效果真的特别好,麻烦也要搞,那我觉得没问题。但是明明两个都可以,这个时候就很不爽。产品定样式还是要和开发沟通的,至少也要有个需求宣讲会,两边坐下来一起谈一下吧。
|
6
xenme 2019-05-13 16:14:24 +08:00 1
这种要是我是开发,我觉得很喜欢。
1. 能实现,想办法实现就行了,做完了 signoff 别来扯皮 2. 不能实现,技术做不了,直接打回去,完结 两边沟通不好的就是互相扯皮,然后改来改去。虽然这是必须的 |
7
treelion OP @xenme 不啊,按我领导的意思,就是没有“打回去”这种情况。
给的就是要的结果。 能做就做,不能做也得做。这就是我觉得扯皮的点,对于开发来说,第二种情况是存在的。 如果真的开发最后说动了领导,让产品这边改,其实我们工作量也非常大的。 |
8
donyee 2019-05-13 16:31:23 +08:00
领导想的是理想情况啊,实际情况呢,需求就是会经常变动的...
|
10
hdyl 2019-05-13 16:35:36 +08:00
没有需求评审会么?
|
11
treelion OP |
12
taresky 2019-05-13 17:46:59 +08:00
这样做绝对不行,需求必须要开发一起评审。
领导是傻逼,他可能没有完整的项目经验。 我对敏捷开发的流程理解: 1. 先出低保真原型,简洁的产品文档。所有参与者一起讨论需求,完善细节。 2. 出完整的设计图,同时后端开始设计接口。 3. 设计图给到前端,过不了过久后端出了一部分接口,正好调试。 |
13
taresky 2019-05-13 17:47:54 +08:00
除非你们 CEO/CTO/PM 为同一个人,否则你们领导的做法只会让大家频繁出错,效率降低。
|
14
Leigg 2019-05-13 21:33:29 +08:00 via iPhone
领导 sb,完。
|
15
treelion OP @taresky 我来之前告诉我是敏捷,我之前也是敏捷。
现在这样如果算瀑布的话,也很奇怪的感觉。 需求方面基本上是使用方说要什么,领导就让我们做什么,我之前还要 argue 一下,发现完全没用,现在也就随他去了。。 |
16
MonoLogueChi 2019-05-13 22:31:43 +08:00 via Android
我有的时候也会找我们的兼职产品讨价还价,问问能不能改一点需求,比如三天工期,但是如果改一点,可能两天甚至一天就能完成
|
17
NaiveSimpleYoung 2019-05-13 22:52:39 +08:00 via Android
做两个迭代把问题暴露出来先
|
18
micean 2019-05-13 22:56:14 +08:00
有开需求评审会么?
|
19
nmgwddj 2019-05-13 23:28:37 +08:00
有开需求评审会么?
|
21
telun 2019-05-14 11:58:06 +08:00 via iPhone
先出方案,再找开发评审,你按最好的方案做,不要一开始就考虑开发的事,最终需求是博弈出来的,如果一开始就是妥协出来的,那产品就不会有突破了
|