• 30岁,之前一直做开发,领导让试水项目管理,但是真心不适应,有过来人指点一二吗?

    2016/08/18 Chess 22 评论  , 

如题。刚跳槽到目前的公司,之前一直是奋战在一线的纯码农。可能领导觉得我30+了还只是写代码不太好吧。给了我一个机会去负责某个项目。

但是进去之后才发现难呀。这边项目经理不只是催人干活,协调资源。而是定需求,想方案,排进度,催人干活,搞不好还得自己挽起袖子干。总之,一切以结果为导向,进来一个月了远离了正式的编码,但是业务得懂,技术得懂。更重要的是,思考思考再思考。没有专门的产品经理定方案。头疼ing。结果直接向领导汇报,上门更大的领导有时还会关注,真得感到压力山大了。再也回不到纯粹编码的时光了。

有过来人分享一下类似转变的心路历程吗?谢谢~

4 5 收藏


直接登录
最新评论
  • Umbrella123 技术支持 2016/08/18

    把自己的心态和角色定位换一换就可以了,祝好

  • 恒_   2016/08/18

    just do it

  • 木杉 web开发 2016/08/19

    最主要的是  别人写了一堆bug  你还得负责修改,算算还不如自己去写!

  • Kenneth hired worker 2016/08/19 精华评论

    Never Never  do coding by yourself  because it is not what you should do.

    As you said, your job is to 催人干活,协调资源,定需求,想方案,排进度,催人干活. This is all what you should do.

    To supervisor and client

    weekly meeting to report your supervisors and client
    write down your client’s requirement and set up the time. Don’t forget to leave some buffer.
    make milestone chart and schedule for project.
    Don’t allow your client to change requirement frequently.

    To team

    do Daily Standup Meetings to know the progress
    do weekly meeting to review team member ‘s progress. 1.Let your teammember to report their progress If they did not finish , ask why and how? 2. Update latest news to your team members.

    To yourself

    take time to study PMP. you will know how to run a project.

    For further discussion, please describe the situation you are in.

    Last and most importantly, Congratulations on your promotion!

  • 诸葛不亮 Qt/C++程序员 2016/08/21 精华评论

    如果在小公司,或者项目型公司作过,其实就感觉没啥了……

    我前后两家公司都是项目型,接项目做。一个项目平均几十万,1-4人参与

    于是一般进公司做了一两个项目后,就会开始独立承担项目……然后需求、设计、开发、管小弟、调试、测试、交付、沟通,啥都要管。多做几次,其实也就这样,比起开发就是业务方面的琐事多了一些,但其实没专职的产品那么忙

     

    刚转型时,只是不习惯这种节奏罢了,实际的工作内容,对开发人员都不是很困难,就是麻烦

    这时候,最主要就是管理好自己的时间了,因为开发是没法用碎片时间进行的

    需求方面,和客户沟通好后,掌握在自己手里,总比掌握在PM手里好多了不是么?

    开发人员管理方面,这类项目经理一般都是技术做的好于是被提起来负责整个项目。所以宝贵的可以用来开发的大块时间,最好用来设计程序架构,开发核心功能,把框架搭起来,把基调定下来,然后剩下的工作就是添砖加瓦,这些只要前期设计好了,可以很清晰的分块来做,按照小弟们的开发能力分发下去就行

     

    至于进度上么……实际开发时间必然大于销售预期时间,这个大家都懂。所以拖进度并不是大问题,前提是客户能理解,能接受。这个就看你怎么和客户沟通了,客户那边搞定了,老板那边不会刻意为难的

    • 诸葛不亮 Qt/C++程序员 2016/08/21

      测试方面,小公司得自己负责,大一点的会有专门的测试人员。所以其实也不麻烦,毕竟文档已经由测试人员负责了,技术人员只负责提供技术支持

       

      如果测试人员是全程参与的,比如会参与单元测试,或者测试文档、方案设计和开发并行进行,那用类似结对编程的方式工作就行了

      如果测试人员是后期参与的,安排和测试内容相关的开发人员后期结对就行,当然一般还是负责核心功能和框架设计的人员参与,一般就是TL自己

      但其实不麻烦,因为中后期文档工作基本收尾了,碎片时间减少,工作时间稳定,可以安心做测试,和做开发时配合测试差别不大。只不过身为TL,需要注意好时间的掌控,对于哪些东西要先测,哪些慢慢来,哪些bug得马上改,哪些暂时退后,心里要有谱。

       

      并且后期测试进度,一定要和上级及客户随时沟通——因为对项目交付和产品上线时间点影响最大的,也最无法预测的,就是测试阶段。这方面沟通好了,即使时间点超了,也问题不大

       

      • 诸葛不亮 Qt/C++程序员 2016/08/21

        和客户沟通的方法

        站在客户的角度,或者说业务的角度去谈,而不是站在开发者的角度去谈。与客户沟通,和与PM沟通是两码事。

        核心在于,让客户直到,并且感觉到,你花的时间,是切切实实在为他实现需求,不会让他觉得时间和金钱白花了。

         

        这点怎么做到呢?主动提细节和变更,而不是等客户提。和客户是谈业务,但不代表不能谈技术和设计。你可以和他沟通,你们现在进度到哪儿了,在做什么功能,你们整体的架构是怎么设计的,然后就可以设身处地的和客户谈,我觉得这个功能可以这么这么做,我觉得文档里这里说的不清楚,要么我们这么做,加点这个那个如何?

        这不是给自己揽活,这是把不可控因素掌握在自己手里。需求必然会变更的,需求必然会增加的,由你主动发起的变更,比由客户发起,要好做得多。

         

        测试阶段的沟通,则是换个说法,典型就是屡战屡败和屡败屡战——你们发现的不是bug,而是功能的不足、纰漏,你们测试时做的不是修bug,而是完善功能,提升用户体验。

        当然,遇到真的是bug,而且是影响比较大,而且用户能直接感知到的,那最好老实承认,分析出现的原因、解决的策略,摆开来说最好——这样一来能表明态度,二来能够体现这个bug的产生不是由于管理混乱造成的,你们有成熟的经验和机制来解决它。

         

        也就是说,与客户沟通的过程中,可以表明不足,可以表明哪些东西做不了,哪些做不好,哪些没做好做出问题。但绝对不能让客户觉得你们的流程不行,你们的管理不行——前者只是关系到你们东西做的好不好,后者直接关系到以后的东西还能不能让你们做

        • 诸葛不亮 Qt/C++程序员 2016/08/21

          和领导沟通的方法

          和直接上级沟通,就和作为开发时与PM、TL沟通差别不大,唯一区别就是说话的角度转变一下,比起扣需求细节、技术细节、时间细节,更多的是谈整个流程的把控,整个设计的思路。沟通方式和内容可以参考与客户沟通。

          和间接上级,也就是更高层沟通,那些大领导不会有精神关注具体的工作内容,所以沟通时相比于和直接上级沟通,要更多侧重于进度方面——所以,和客户沟通要主动,要频繁,觉得哪里不清楚,或者开发到一个结点了,就马上发起沟通。客户那边说通了后,拿这个和大领导汇报,领导会相当满意

          大领导关心的是进度,或者换个说法,客户的满意度。客户满意了,或者至少能接受了,大领导就不会找你茬

        • 诸葛不亮 Qt/C++程序员 2016/08/21

          开发方面,到TL后,更多的不是直接参与开发了,而是参与设计和Code Review

          TL经常也是技术核心,在初期,要负责设计好程序架构,并且把主体结构搭起来,剩下的都能交出去。

          这时就体现出做需求的重要了——需求由TL做,然后由TL设计框架再分发开发任务,比需求由PM做,要好得多,因为TL知道该怎么把需求变成代码。

          于是,分发工作前,被分发人要开个会。找个有白板的小会议室,就谈这个需求该怎么实现。在白板上把流程图,或者UML设计好,然后记笔记,或者拍照留档,让小弟就照着这个直接填代码就行

          小弟代码写到一定程度,主动发起Code Review,保障开发的质量和进度的稳定。一般找三个点看一下就行:

          1、完成流程图/UML图向代码的转换,搭建起代码结构时——这时是最适合重构的,开发者已经明确了需求和思路,你需要确定他打算的实现方式对不对,适合不适合,不适合就重构,但这个重构很简单。Review重点:设计模式

          2、开发过程中,时不时看看,比如倒茶倒咖啡时逛一逛,瞅一瞅,聊一聊。这时关注的就是开发质量,并且可以提高开发进度——开发必然会遇到卡结点的,如果是业务不熟的结点,作为TL刚好能帮忙。如果是技术结点,作为技术转型的TL,也刚好能帮忙

          3、功能点做完了,提交了,准备下一个功能点时,拿出一开始留档的设计图,拿出需求文档,一个个点对着核一遍。有出入的敌方,深入沟通确认,是实现上的出入,还是需求没作对。需求没做对的,需要修,实现上的出入,调整设计,以便安排后续的开发工作

           

           

          应该完了。工作三年半,做了七八个项目,独立负责的项目也有四五个了,从几十万到百来万不等,经验就这些了

  • RayHoward   2016/08/21

    听起来像是项目经理CTO产品经理三合一的工作

    • 诸葛不亮 Qt/C++程序员 2016/08/21

      其实绝大部分公司并没有那么明确的职能分离,毕竟就这么点人。更多的一般是根据业务或者技术划分部门,部门经历就是大领导。部门里根据业务划分几个大组,大组组长就是PM,同时一般还是CTO。然后下面每个项目/产品的负责人是TL,这个人一般就是有能力有资历的开发人员提拔起来的。楼主的情况就很像是这种TL

  • EthanJ   2016/08/21

    我也在经历这个过程,刚从研发转管理,一样的困惑,一样的迷茫。指挥别人干活的感觉不如撸起袖子自己干的感觉好。

  • re   2016/08/22

    感觉是你的思想还没转变过来,你现在有这个问题,感觉主要是你没有站在一个比你原来的位置要高的位置去看待问题。

    你需要考虑更多的事情,而不是仅仅写代码了

  • 旺旺 java 2016/08/22

    做架构师吧,这个好

  • 放宽心态,多问问那些有经验的,交流学习

  • 一加一   2016/08/23

    我和你有一样的困惑,美工组小组长。自己也在做,还要协调组员的工作,感觉有点累。

  • 赤脚吉恩   2016/08/23

    我也有此经历,一直写程序都是程序员思维,管理要学的很多.

  • 洪裕灏 程序猿 2016/08/24

    是的,我一般是分配任务,拆分评估需求,然后下面就是把控了,但一般不会自己干,做好review,然后陪加班,哈哈哈

  • ~亮 java程序员 2016/08/24

    国内也只能转成管理,国外都有好多的程序员开发经验长了去了

     

  • 一直要有目标很重要,无论生在哪里成长的始终是自己