`

最近一个项目的反思(转载)

 
阅读更多

入行这些年,没多少成功的经验,失败的经验却越来越多。今天花点时间好好的反思一下,老是稀里糊涂的可不行。我下面写的不针对任何人,就事论事。

 

一、无管理核心

 

  缺少了这个重要的凝聚力,下面的人可以说是在单兵作战,一盘散沙,各自为战,怎么可能把项目做好。还有下面的这些问题:

  1、团队成员碰到的问题无法得到及时的协助和解决,会让人有越来越多的挫折感。

  2、无人管理开发文档,开发任务没有科学的制定会拆分。

  3、由于没人督促,readmine形同虚设,完全没发挥他的作用。

  4、人员不能被合理的分配,成员之间的协作越来越少,甚至有隔阂。

  5、不能有效的控制需求,一会儿做这个,一会儿做那个,最后什么也没做成,士气越来越低。

  6、项目中遇到的意见不统一、冲突,都不能有效的协调好,团队成员思想不能一致。

  7、无法把控开发人员们的进度。

  8、阶段性成果,没有安排时间及时确认。

  接下来的那些问题很多都是因为无管理核心导致的,联动效应。

 

二、需求混乱

 

  规范点的说,需求的管理应该只有一个进口一个出口,拿到需求后,先做个分析,分解细化,然后再转换成可执行的操作,画原型,制作效果图。

  现在的情况是出现开发与规划不符的情况时候,直接与开发人员确定需求,今天要这样改,明天那样,不断的变化,得不到控制,原先的开发计划不断的插入新的功能修改,完全不按照计划来了,最后当然不能在指定日期完成预定功能了。

  开发人员没有参与到需求的讨论中,听需求的人,在把需求传达给开发人员,经常会出现偏差,最后开发人员买单,将做好的功能页面等再推翻,修改,费时费力,还影响开发人员的心情。

  经常会纠缠于一些需求的细节,一步到位,力求达到最好的用户体验与效果。我个人觉得用户体验的好坏是需要真正的用户用过以后才能确定的,在开发阶段是快速的将一个可用的软件拿出来,以后再根据各种数据为基础,改进用户体验。项目的开发都是渐进明晰的,一开始的开发肯定不能预料到各个方面,既然预料不到,就把重要的先做好,以后再改,有了可用软件,什么都好说。

  还把测试人员给拖累了,经常会抱怨开发人员临近上线才开始提交代码测试,抱怨开发人员自己不好好测试。临近上线还要一堆BUG。完全没有留时间给他们,让他们很难做,有时候是快到上线日了,软件都还没有,根本没有测试的东西,别人很忙,自己却很清闲。

三、不懂业务

 

  开发开始前,应该让开发人员们使用市面上面相关的软件,实际操作下,体验流程。实际操作的效果比嘴上说要有效的多。在操作的过程中,就能体会到市面上的软件哪些地方做的不好,哪些地方做的好,真正换位到用户的位置上。大家嘴上常说要换位思考,但实际操作起来真的很难,但让自己做一个真正的用户就方便很多。

  开发人员不懂业务,是个软肋,导致很多问题。第一个是最大的问题。

  1、无法质疑需求的合理性,上面传达下来的需求即使有错,也继续编码,最后就是返工。

  2、很难对项目提出一些比较好的建议,有时候也不能有效的和最高决策人沟通。

  3、开发人员自己估算工作量的时候,会有一些偏差。

  4、代码的设计会有影响,懂业务能更好的设计代码的结构,扩展等

       5、技术提高的访问www.cgzhw.com 游戏编程网很不错的技术网站。

四、沟通阻塞

 

  1、测试人员与开发人员之间:

  一开始测试人员不熟悉系统,提了许多易用性方面的问题,还有一部分BUG在开发人员眼中并不是问题——就是那样设计的。在提出后,放到readmine上面,分配给测试人员认为的相关开发人员,到这里都很自然顺畅。但是挂在readmine上面的这些问题就这样挂着了,不修改也不反馈,不了了之了。他们的工作很难展开,测试与开发之间出现了小隔阂,团队的凝聚力越来越低。

  后面经过大家的讨论,给出一个解决方案。需要一个中间的管理人,让他去分析提交上来的问题,根据他的理解定位这个问题属于谁,再由他转给某个开发人员,由这个人来追踪。测试人员的工作也单一了,不会老是由她来催促修改问题。

   2、Web端与服务器之间:

   这次的项目是需要不同终端互相协调的,web端需要服务器端提供接口协助,让那边提供接口却总是一拖再拖,迟迟不给,即使在readmine中开个任务,还是没有在预定的时间中给接口,一催二催三催,没有结果。这里也缺少个中间的协调人,需要这个人做沟通,安排时间,分配人力,满足web端的需求。开发人员之间是平等的,不存在指挥的关系,谁也管不动谁。开发人员之间出现了小隔阂,团队凝聚力再次降低。

   3、开发人员与需求提供人员之间:

   需求的提供有从最高决策人那里直接发出,有时候也会通过另外几个人员发出。由于需求的一直变化以及传达的时候经常出现偏差,导致了开发人员不在非常相信他们,对于他们提出的需求,经常会做反复的确认,但最后还是会改。他们做的原型或设计的流程,与最高决策人做一一确认有点不现实,这样经常会导致被推翻,直接影响了开发人员,开发人员在实现了以后也要返工。这个地方缺少了个需求的管理者,需要他来制服需求,这头猛兽在摧残着各个相关人员。反复无常的变化,让他们的工作也很难展开。开发人员与需求提供人员之间出现了小隔阂,团队凝聚力势必再次降低。

分享到:
评论

相关推荐

    向谁学课件【转载】.ppt

    【向谁学课件——掌握...总的来说,"向谁学课件【转载】.ppt" 提供了一个全面的学习框架,强调了多元化的学习方式和持续学习的重要性。无论是在哪个领域,遵循这些方法,我们都能有效地提升自我,适应不断变化的世界。

    售前工程师的成长---一个老员工的经验之谈(转载)&售前修炼&售前必备

    【售前工程师的成长之路】 售前工程师在IT行业中扮演着至关重要的角色,他们既是技术专家,又是销售顾问。...在IT售前这个特殊的职位上,每一位工程师都是一份宝贵的资源,他们的成长与公司的业绩息息相关。

    软件开发人成长经历(转载)

    "软件开发人成长经历(转载)"这个主题,旨在分享一位软件开发者从初学者到专业人士的蜕变过程,帮助那些渴望在这一行业中提升自己的人们找到方向。通过阅读《程序员感语.pdf》这样的资料,我们可以学习到许多关键的...

    一个设计文档的模版!!

    这个模版提供了一个全面且结构化的框架,可以帮助开发者创建规范、易于理解和维护的设计文档,从而提升整个项目开发的效率和质量。在实际应用时,应根据项目特性进行适当调整,确保文档内容贴合项目需求。

    转载天大一位学长的帖子

    后来,作者抓住了一个加入另一个电子系实验室的机会,从事嵌入式设计工作。这里的工作环境更加规范,有明确的人员分工、进度管理和文档系统,使他首次体验到了标准的项目管理流程。在这个实验室,他参与了多个大型...

    1968年图灵奖获得者

    在那里,他不仅继续发展和完善自己的研究成果,还积极参与了多个重要项目的研发工作。贝尔实验室汇聚了众多顶尖科学家和技术专家,这样的环境无疑为海明提供了宝贵的资源和支持。 #### 对计算机科学的贡献 除了...

    设计文档 标准模版例

    - 文档通常包含版权说明,保护知识产权,规定未经许可不得复制或转载。 - 封面页应展示部门、作者、版本信息等,以确保文档的完整性和追溯性。 2. **文档更新记录** - 文档的更新记录有助于跟踪其演变过程,记录...

    你可以被人称作SEOer吗?.docx

    ### SEOer的专业素养及其在行业中的现状分析 #### SEOer的概念及重要性 ...同时,企业和客户也应该增强辨别能力,选择真正有能力提供高质量服务的SEOer进行合作,共同营造一个更加健康、可持续发展的网络环境。

    第二学期学区主任述职报告.docx

    我们将继续深化改革,创新工作方法,加强师资队伍建设,努力为农村孩子提供公平而有质量的教育,让每一个孩子都能在这片蓝天之下健康成长、全面发展。 感谢大家的聆听,期待与各位同仁携手共创学区更加辉煌的明天!...

    音乐学科带头人述职报告.docx

    - 罗雨寒老师和况峥峥老师的随笔被各类名师工作室转载,获得局领导的高度评价。 3. **活动参与**: - 帮助教研员开展各类教学教研活动,为新教师提供上岗培训。 - 担任香洲区教学论文评比、青年教师赛课等活动的...

Global site tag (gtag.js) - Google Analytics