今年有个新项目,我常驻客户现场,充当项目经理的角色,但是感觉自己做的有点失败; 现在客户现场的情况如下特点: 1、客户给我们的任务都是先让我们做,看到我们的结果,再自己出标准,2、事情做好后,老是给出自相矛盾的标准,(像,“有快有好”这样的), 又要机器少又要并发高,想着把矛盾的标准整合在一起,来回倒腾, 3、客户随时增加新需求,想到什么,就加入什么,他们开一次会,就变一次;;1、下边的同事意见比较大,感觉 我 没法把需求确定,2、我是做开发的,一般都是做确定性的事情,对下边分配任务,一般都不会分配难点大的事情并确定交付时间爱你,但是同事看到自己没有见过的事情,会拒绝思考,不想做, 时常会出现赶时间,我亲自上手做       //   我理想的工作环境应该是: 1、客户先把背景给我们,然后根据这个背景来确认目标, 变的话,可以说背景变了  2、同事按时完成任务(我给时间= 我能完成的时间* (2到3)),只有真正有技术难点的话,我们一起搞   ;;;总之,事情有逻辑发展规律,任务完成上按部就班;   

想问的事情,是,我应该以什么心态面对变化, 现在对频繁的变化、任务的推迟,现在是有点焦虑的??

4 6 收藏


直接登录
最新评论
  • 熊绎 IT solution 01/09

    扯淡吧,这么做能做的好的??

    签合同之前要确定范围,假设,依赖,和周期,风险并且把这些都写在SOW里面双方签字,这个是有法律效力的

    项目一开始就需要确定需求,需求完成后写FS和URS,然后甲方签字。需求变更需要走变更流程,如果超过范围需要发CR。沟通要定好计划,比如每周周会,每月项目干系人会议,有问题甲方不回复,几个工作日向上汇报等等。

    像你这样胡乱做项目,结果就是换几手人,然后项目挂掉。最好的结果也是勉强完成然后尾款拖很长时间

    • 成了大叔 软件开发 01/10

      我们的合同都修改了三次了; 我们部署完一个仿生产环境后,才开始谈合同内容的事情; 我也不知道我上边的领导是如何想的

      • 熊绎 IT solution 01/10

        开始做了才谈合同?那就没什么好说的了,明摆着送给甲方吃了。

        领导能如何想,还不是求爹爹告奶奶各种惯着甲方只求签下合同算自己的业绩

        至于以后的执行么,就丢给你这样的具体的负责人

        执行好不好那是你的问题,反正合同是我签的,业绩是我的

        尽快走人吧,以后数不尽的坑让你跳

  • 王小二 java/C 01/09

    对呀,没有合同么?

    • 成了大叔 软件开发 01/10

      有合同,但是甲方不介意修改合同的,因为我们做的时候,甲方还没有确定合同范围;我们做的时候,一直在修改, 只给我们一个合同意向

      • 熊绎 IT solution 01/10

        这连最基本的商业规则都不遵守了,那还搞个屁啊

        早点走人吧

  • 胤瑜 C#中级工程师 01/10

    同一楼说法,虽然我是个打酱油的,大项目也跟了几个,大部分都是先确定需求,BA在中间斡旋。届时DEV会提出问题,直到BA和客户,BA和DEV。双方达成一致,签字画押。开始进入迭代。在这期间,BA会把文档,Case,什么的准备好!随时沟通发现问题及时解决。大方向是一定的。小地方再讨论即可。(主观感受,感觉这样靠谱!因为有一天我也会成为这样的人,虽然现在是个打酱油的!)

    • 大头大头 码农 01/12

      大神,要学习这类项目管理的流程得从哪里学习啊?

      • 胤瑜 C#中级工程师 01/13

        我是个写代码的,跟着打酱油,项目管理这部分还没到那个等级!跟着公司的大牛走流程,大致是这样。主要看公司的制度。有些公司是一个开发干好几样活,像我们公司,开发就是开发(DEV部门),QA(测试),BA(确定客户需求),Project(整合迭代周期,算时间,量化工作统筹项目进度),TW(负责翻译文档,词条处理),Admin(环境配置,一般由DEV兼职)  项目经理(DEV头头代理。)

  • New sking 爪哇程序猿 01/10

    这种项目我做过一个。

    前期:公司为了进入这个项目,启动资金什么都没有,前前后后来了十几人,把初始版本上完后。爹不亲,娘不爱,项目组撤到5人左右。(大概6个月)

    中期:公司各种催促,甲方各种修改需求,项目组撤到3人左右。(大概14个月)

    后期:终于甲方确认可以交付,前前后后脱了12个月,项目组只有1人。

    不说甲方怎么样,甲方肯定利益最大化。问题是公司这边,一个70万的项目,前前后后脱了3年多,中期项目各种变更需求,项目经理最后自己都做得很无语。

    处理方式:

    1.一定要确定需求,特别是初当项目经理,为了搞好所谓客户关系,很软弱(不敢态度强硬,怕影响领导对自己的态度),导致客户方需求变更频繁。

    2.对队员,一定要做好调解安抚工作。任何团队都是人的工作,如果团队对你印象特别糟糕,以后你不可能再做管理工作(特别是外派,驻现场这类的,很容易团队流失)。

    3.必须把情况反应到上面去,至于什么办法,转弯什么的都可以,要求销售必须把合同定下来,否则前面任何工作都是无用工。(结局自己知道,多发不讨好。)

    • New sking 爪哇程序猿 01/10

      我是中期过去填坑的,当时不知道是什么情况,做了8个月,累死累活,结果外调到其他地方,不过当时期望再回到那个项目组,所以持续关注着。结果发现,如果甲方不给力,自己这边做多少都是无用功。

      中期我到另外项目组去了,这边经理非常强势,合同规定得非常死,多一点都不做,和甲方闹得很僵,但是甲方硬是把第一期的项目接了,现在留着那里做第三期了。那边的甲方确认项目交付很墨迹,但是硬是因为项目经理强势,早早就把项目结了。

      最后我到北京当项目经理,也非常强势(对队员,对甲方都强势,他们初入这行,对需求不懂,又太多自己的想法,必须按照我的想法做,不然项目完成不了),万幸4个月左右项目交付。然后团队分拆,因为太强势了,队员对我口碑不太好,结果半年后,都说,我们太怀念你了。你在我们至少知道做什么,目前这个项目经理做得生不如死。

      口碑不好,但是技术还行,上面的项目经理拉我过去做技术经理,累死累活半年,和甲方很happy,项目也上线了,甲方死活不结项,我因为家里出了事情,就回武汉了。后来问那个项目现在情况怎么样,已经2年了,项目还是没有结项,一期都没有结项。

      你以为和甲方关系好,甲方认为你好欺负,死活让你继续维护,不结项,不付款。

      • 成了大叔 软件开发 01/10

        你以为和甲方关系好,甲方认为你好欺负,死活让你继续维护”,是的,是这样的情况;但是强势,应该如何做的强势??:有些不该我们做的事情, 或者 需求的变动,我当时都是反对的或者让他们确定最终的具体需求, 但是他们给我们不在客户现场的老大打电话; 我的老大 ,是开发出身, 技术比较好, 在他看来完成客户的需要都不是问题;但是现场的情况是: 做不做 和 做到什么程度 的问题

        • New sking 爪哇程序猿 01/10

          所以才是问题,必须要有合同保证(是人力外包,还是项目外包)。所谓的沟通,和甲方必须明确范围,没有明确的范围都是无用功。甲方才不会为他们的信口胡言买单。

          特别是现在这种情况,说白了,公司把你扔在那里,你没有确定自己的职责范围,你一直以一个技术员的身份,任何东西不加分辨,都接下来(多少活,多少成本,老总不一定清楚,你要和老总说明白,不然底下人都跑光了,你一个人干啊)。

          所有的东西都是讲成本的,你要和老总把这些说明白。驻场开发,最容易出的问题就是,客户看着你们不忙,信口开河的乱提需求。哪怕是玩,我们也要把时间人力成本算清楚,才能做开发。都接下来,忙死了,客户方一直不喜欢你们的demo,你们一直做下去?

           

          • 成了大叔 软件开发 01/10

            是呀,我也发现自己一直以开发的角度来考虑问题;没办法摆正自己的位置;

    • New sking 爪哇程序猿 01/10

      签合同的时候,自己这边必须有一个特别了解需求的,不然一个甲方的简单需求会把人搞死。

      甲方普普通通的监控,我填坑8个月里面,做成一个全方位监控系统,然后就没有其他项目组开发这里面的功能了。最后做技术经理前,到处救火,发现用的都是我做的那一套(我很自豪这点,都没有人说这个做得不行)。

  • Rsoft javalinuxhaoop 01/11

    1:学会拒绝

    2:版本控制

  • 一股心塞的感觉。需求不确定,净把程序员折腾

  • 猫猫   01/25

    其实很简单,这个业务你们团队根本没人知道怎么做。

    举个例子,客户到饭店点个鱼香肉丝,你厨师问要放鱼吗?你说清楚,我来给你做。

    客户就蒙了,我也不知到放啥啊,先放鱼看看吧,不对再做。

    你现在就相当于那个厨师。所以会很纠结。你们缺少业务分析和架构,只能做着看,小公司或者进去不熟悉的业务领域就是这样的,基本没跑。

  • 龙雀 野生程序员 02/07

    1. 不确定需求一定不要做
    2. 学会拒绝,解释不可能腥,直接让它选择一个
    3. 做版本控制,一次迭代开一次会