项目开发一半,让主要成员又去忙别的,让不懂这个项目的人重新接手开发 - 总结

安得权 2013-08-19 04:13:04
a.项目原来成员没有成就感(自始至终他没有完完整整把这个项目做完)
b.接手人困难重重(之前他都没有参与,半路杀进来)
c.接收人遇到问题后,要进行大量的沟通(这个大家的时间。。。时间就是金钱啊,还不说一些 说不清,道不明的问题)
d.项目没有负责人 (主要成员:忙别的去了,觉得这项目我不管了;接收人:我会负责吗?)
e.项目的严谨性遭到损坏(项目刚开始定义的规范和默契没有了,各写各的。 )

以上直接导致项目的工期、质量和成本受到损害。


欢迎继续总结
多提建议 O(∩_∩)O哈哈~
...全文
1176 51 打赏 收藏 转发到动态 举报
写回复
用AI写文章
51 条回复
切换为时间正序
请发表友善的回复…
发表回复
安得权 2013-08-20
  • 打赏
  • 举报
回复
@All 团队合作的基础:模块 - 功能 风险成本的控制 - 这个主要看管理者的水平 项目进度的控制 - 制定一个合理的详细的工作计划(在合理的设计上) 1、原型 2、设计图(结构图、模块 - 功能拆分图、功能解释图) 3、接口文档、模块间通信结构图和解释图(后两者也可以包括在2) 4、测试指引(单元测试指引、功能测试指引、模块测试指引、通信测试指引、整体测试指引)用于给测试用例编码团队编写对应测试用例的文档集 5、当前迭代编号 成功的各有特色 扑街蛋疼的基本一样 求有特色 合理的训练是训练,不合理的训练是磨练 - 很有道理,希望能永远记住你这句话,保持斗志 执行力和沟通,这个只能慢慢培养,和公司的文化息息相关,希望大家都朝着积极的方向发展 政治问题,不想总结,就像某位兄弟说的一样:不在其位,不谋其政 就这么多了,结贴 ,谢谢大家
朗晴 2013-08-20
  • 打赏
  • 举报
回复
合理的训练是训练,不合理的训练是磨练。
安得权 2013-08-20
  • 打赏
  • 举报
回复
引用 40 楼 sp1234 的回复:
可能有人不想得罪人,可能有以为小公司恰好适合高薪养那种“总是在找出同事们的问题时很能说、但是自己一做东西就不行”的人。但是我以前以为小公司也应该尽量少养这类人。因此不论是大公司还是小公司,虽然入职时的技术水平高低不同,我们都应该强调相同的做人态度。少讲是非,多找方法。
少讲是非,多找方法。 +1 是是非非谁能说得明白,自己懂得分辨真真假假即可
安得权 2013-08-20
  • 打赏
  • 举报
回复
引用 46 楼 sjyforg 的回复:
把自己的工作做好就行了,其它的你管不了的。
一般开发中,技术性问题不大,尽力在搞明白需求中。。。
安得权 2013-08-20
  • 打赏
  • 举报
回复
引用 40 楼 sp1234 的回复:
可能有人不想得罪人,可能有以为小公司恰好适合高薪养那种“总是在找出同事们的问题时很能说、但是自己一做东西就不行”的人。但是我以前以为小公司也应该尽量少养这类人。因此不论是大公司还是小公司,虽然入职时的技术水平高低不同,我们都应该强调相同的做人态度。少讲是非,多找方法。
不是不想得罪人,是不能得罪,除非你不想在这干了,那你随便干 同事还得相处,事情还要做,不是么 关于您说的,进公司应该强调做人的态度问题。 自己觉得:公司只有职位不同(我觉得职位高低问题 仁者见仁智者见智),角色不同,各司其职 安排任务的别太把自己当回事,小兵也别太不把安排任务的当回事 就行
申江渔夫 2013-08-20
  • 打赏
  • 举报
回复
把自己的工作做好就行了,其它的你管不了的。
安得权 2013-08-20
  • 打赏
  • 举报
回复
引用 39 楼 sp1234 的回复:
[quote=引用 31 楼 g4_magicvr 的回复:] 在大公司做过的朋友估计很清楚这个概念 模块化生产的优点其实很多人不理解 其实你参考一下工业生产的流水线标准化作业就明白了 同样一个螺丝钉 你买哪个厂家哪个车间哪个工作人员生产出来的都是可以一样用的 编程也一样 小作坊和大公司的本质差别就在于 大家的单位产品来说 大公司的事标准化零件 小作坊就是个人随心所欲的大小不同的组件 这样就导致了 大公司我随便这个人调那个部门 那个人调这个部分 他们都可以马上拿着已经有的模块开始鼓捣 很快就可以上手 小作坊嘛……换人 你开玩笑?
我以前也以为是这样的,以为大公司就是“机器化大生产”。 后来通过3、4年在“经典的”小公司里观察,终于发现,往往不是这样的差别。在过去我们在大公司做经常面对挑战(那些超级大公司的挑战),所以并不觉得是什么机器化,而一切也都是艺术。只不过大公司的员工的工作态度和技术素质明显高一大块而已。 大公司的老板,许多一般都是经过特别的心理上的历练,比较会处理好“任人唯亲”的问题,自己可以为了公司大业而超越俗人的层次。而小公司的老板,虽然心比天高,往往因为私心杂念更为泛滥、甚至心胸狭隘,结果多年的理想遇到了一两个心腹跟自己“撒娇”,就放弃了、就顺从了心腹的主意了。 [/quote] 亲,工作几年了
安得权 2013-08-20
  • 打赏
  • 举报
回复
引用 34 楼 djnick 的回复:
[quote=引用 33 楼 g4_magicvr 的回复:] 开发的最小单位是功能 功能之上 全部是可以单独更换的(除非你不再支持这个功能) 所以 是不是同一个团队 甚至是不是同一个设计师 处理同样的问题时没有什么本质上的不同的 (不要说主设计……那纯粹只是因为所有的东西都要看 所以上手时间更久而已 而且……做到主设计的时候 那已经很牛逼了)
可以介绍些关于设计的资料和书籍吗?亲~~~[/quote] 开发的最小单位是功能 +
安得权 2013-08-20
  • 打赏
  • 举报
回复
引用 37 楼 sp1234 的回复:
尽量不要搬弄是非,尽量理解别人。 除非你真的有能力,但是如果你有能力做这个,你就不会发这样一个帖子了。所以要先看懂自己能不能做事情,再指责别人的问题。
是啊,如果能真容易搞定 就不会发帖了 做起来困难重重,且返工比较严重 测试也很纠结,很多问题前边都没有,越改越离谱 接手后,项目需求就不懂,还一直催着完成。无奈中。。。
todd_leftcode 2013-08-19
  • 打赏
  • 举报
回复
那就重新开发嘛! 老板觉得这样干划算,咱程序员就不用操成本的心(SB老板肯定是有的,但一般死得快不易遇见)。 代码即文档, 作为一个程序员, 拿到代码, 应该就可以了解项目情况。 当然前提是拿到的是代码,不是密码。 所谓铁打的营盘,流水的兵, 换人本不是什么兵家大忌。 当然能给个把星期交接时间最好。但如果实在调济不过来,人还得换, 工作还得做,企业还得经营。 关键是代码质量,保证不了代码质量, 别说换人, 原班人马睡醒一觉再回去继续干都干不下去的。
  • 打赏
  • 举报
回复
引用 1 楼 starfd 的回复:
人心散了,项目必败啊。。。。 a:执行力差 b:风险成本 c:沟通成本,风险成本 d:负责人都没有,曹,这项目谁布置的??谁来检验进度的? e:地基都没了。。。。
+
  • 打赏
  • 举报
回复
可能有人不想得罪人,可能有以为小公司恰好适合高薪养那种“总是在找出同事们的问题时很能说、但是自己一做东西就不行”的人。但是我以前以为小公司也应该尽量少养这类人。因此不论是大公司还是小公司,虽然入职时的技术水平高低不同,我们都应该强调相同的做人态度。少讲是非,多找方法。
  • 打赏
  • 举报
回复
引用 31 楼 g4_magicvr 的回复:
在大公司做过的朋友估计很清楚这个概念 模块化生产的优点其实很多人不理解 其实你参考一下工业生产的流水线标准化作业就明白了 同样一个螺丝钉 你买哪个厂家哪个车间哪个工作人员生产出来的都是可以一样用的 编程也一样 小作坊和大公司的本质差别就在于 大家的单位产品来说 大公司的事标准化零件 小作坊就是个人随心所欲的大小不同的组件 这样就导致了 大公司我随便这个人调那个部门 那个人调这个部分 他们都可以马上拿着已经有的模块开始鼓捣 很快就可以上手 小作坊嘛……换人 你开玩笑?
我以前也以为是这样的,以为大公司就是“机器化大生产”。 后来通过3、4年在“经典的”小公司里观察,终于发现,往往不是这样的差别。在过去我们在大公司做经常面对挑战(那些超级大公司的挑战),所以并不觉得是什么机器化,而一切也都是艺术。只不过大公司的员工的工作态度和技术素质明显高一大块而已。 大公司的老板,许多一般都是经过特别的心理上的历练,比较会处理好“任人唯亲”的问题,自己可以为了公司大业而超越俗人的层次。而小公司的老板,虽然心比天高,往往因为私心杂念更为泛滥、甚至心胸狭隘,结果多年的理想遇到了一两个心腹跟自己“撒娇”,就放弃了、就顺从了心腹的主意了。
threenewbee 2013-08-19
  • 打赏
  • 举报
回复
引用 11 楼 wanghui0380 的回复:
皇上不急,你急啥?? 公司难道看不到问题,如果公司看到问题,还这么搞。兄弟,立马走呗,神来了都不成 如果公司没看到问题,兄弟,还是立马走呗。都乱成这样了,你们都看不见,明显心就不在这块
就是这样,不在其位,不谋其政。
  • 打赏
  • 举报
回复
尽量不要搬弄是非,尽量理解别人。 除非你真的有能力,但是如果你有能力做这个,你就不会发这样一个帖子了。所以要先看懂自己能不能做事情,再指责别人的问题。
djnick 2013-08-19
  • 打赏
  • 举报
回复
引用 35 楼 g4_magicvr 的回复:
[quote=引用 34 楼 djnick 的回复:] 可以介绍些关于设计的资料和书籍吗?亲~~~
实战出真知…… 喜欢的话 直接去应聘一个大公司爽一下呗 比如华为啊 小企鹅啊 有点软啊 某娘啊 某巴巴啊神马神马的[/quote] 华为 埃森哲那些 很多都是系统维护,我现在就跟进着一个这样的功能修改,不能说原来的系统设计的不好,但我就是不知道他里面的逻辑,我手上除了usermanu什么也没有了。 我想问下一个模块在开发好后应该出来些什么文档?
g4_magicvr 2013-08-19
  • 打赏
  • 举报
回复
引用 34 楼 djnick 的回复:
可以介绍些关于设计的资料和书籍吗?亲~~~
实战出真知…… 喜欢的话 直接去应聘一个大公司爽一下呗 比如华为啊 小企鹅啊 有点软啊 某娘啊 某巴巴啊神马神马的
djnick 2013-08-19
  • 打赏
  • 举报
回复
引用 33 楼 g4_magicvr 的回复:
开发的最小单位是功能 功能之上 全部是可以单独更换的(除非你不再支持这个功能) 所以 是不是同一个团队 甚至是不是同一个设计师 处理同样的问题时没有什么本质上的不同的 (不要说主设计……那纯粹只是因为所有的东西都要看 所以上手时间更久而已 而且……做到主设计的时候 那已经很牛逼了)
可以介绍些关于设计的资料和书籍吗?亲~~~
g4_magicvr 2013-08-19
  • 打赏
  • 举报
回复
开发的最小单位是功能 功能之上 全部是可以单独更换的(除非你不再支持这个功能) 所以 是不是同一个团队 甚至是不是同一个设计师 处理同样的问题时没有什么本质上的不同的 (不要说主设计……那纯粹只是因为所有的东西都要看 所以上手时间更久而已 而且……做到主设计的时候 那已经很牛逼了)
g4_magicvr 2013-08-19
  • 打赏
  • 举报
回复
引用 30 楼 djnick 的回复:
你的意思是,模块开发好后就不用维护了?如果发现有问题怎么处理呢?重新开发模块? 如果客户有新增的功能,又如何处理呢?如果改动不大,重新开发模块成本不是比修改模块高出很多吗?
是的 模块一般除了本身开发它的团队的人心血来潮之外是不会去维护它的(除非有bug 那不叫维护 叫修理) 什么叫做模块化 一个大的功能模块里面是有小的功能模块的 增加一个功能 往往只是需要在大的模块里面增加一个小的模块 那时不需要对原有模块进行修改的 只需要新建一个模块 然后把已有的模块里面的用的到的小模块全部复制过来(甚至是直接下辖那个模块),然后编写相关的小模块加入新的大模块中,然后迭代之前的模块就可以了 那部分有问题 直接拆了换掉(这也就是为什么要用接口通信的原因) 大模块全部由问题 换大模块 小模块由问题 只需要换小模块 这就是迭代
加载更多回复(31)

7,765

社区成员

发帖
与我相关
我的任务
社区描述
.NET技术 非技术区
社区管理员
  • 非技术区社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧