• 软件开发具体执行者注意事项


    一、需求和页面表现形式一定要全部思考清楚、问清楚、写清楚!

    立字据!!

    一定强调写!而不是口头,因为所有功能不是一天就能开发完的,一切没有写清楚的内容,以后就特别糟糕!!

    一定强调首选全局把握,首先把所有需求都理解清楚,而不是忙着功能实现!

    1.1决策者问题:

    1)一般需求文档有了,应该是先让开发人员先看,有疑问地方,写下疑问。

    然后需求人员口头解释一遍。

    最后开发人员提出疑问并记录清楚回复。

    对于业务非常熟悉的开发人员,可以省去口头解释需求这一步,直接问需求人员问题。

    2)但没经验的需求人员的上了就是说,根本不给你提前看需求文档的机会。

    然后以前没接触的需求必然听的模棱两可,最后不得不仔细看需求文档。有疑问马上找需求人员问清楚,写下来。

    3)老板兼职需求人员,上了就是说,根本不给你提前看需求文档的机会。

    然后以前没接触的需求必然听的模棱两可,最后需求文档非常简单,比说的还粗略!!

    然后如果你是新人一定要细心再细心(因为在小公司是没有原型设计、静态开发,只要需求文档和口头描述),如果你是老人,有疑问马上问清楚,并且立刻完善需求文档重发给老板,

    如果老板懒得要(或少部分技术术语看不懂),你自己一定要有修改后的详细需求存档,一定要先全局把握,写清楚!

    1.2执行者问题:

    经常会出现开发人员忘记了,需求人员也忘记了,然后锅往往是开发人员背。

    需求人员理由是:我当时说清楚了,你也没有什么疑问,你为啥现在却有问题了?

    鬼知道他当时是说清楚了,你忘记了,还是他根本就没说!

    如果需求人员是你老板兼职,那你千万别去反驳,主动认错,才是解决问题的开始。

    因为你们本质上是雇佣关系,不是同级别同事关系,更不是朋友关系。

    1.3解决方案:

    1.31、需求人员必须说:

    1功能点写清楚,并且口头解释清楚!

    2数据来源:哪些Excel的哪些列?存入数据库那些表的那些字段?

    写清楚,并且口头解释清楚。

    3 确定以现有的技术、人员、时间、资金投入一定能够实现!

    1.32、开发人员必须:

    1 所有功能点完全理解,并且清楚具体实现的步骤,并且记录清楚思路。

    2 数据来源完全理解,并且清楚数据导入数据库的具体步骤,并记录清楚。

    3 清楚接口编写的具体步骤,并记录清楚。

    以上任何一点不清楚必须马上问清楚、写下来!!

    二、对决策产生意见和分歧时。

    特别是改bug和改需求时,特别是老板兼职需求人员时。

    0 执行者,首先千万不要马上就去反驳决策者或发表自己的看法,而是仔细听,弄明白决策者的目的,弄清楚他到底需要你做什么、做成什么样。

    1 执行者,不要轻易提出意见和建议,特别是不宽容的决策者。

    2执行者,提的建议, 若决策者不采纳,执行者可以保留意见,但必须执行。因为决策者有决策的权利和对决策结果负责责任,而执行者无权也无责。

    3若执行者尽职责了,但没到达预期结果,决策者却把责任归咎于执行者的无能或低能,那么执行者要尽快准备另谋出路了,跟着这样的船长是走不远的,反而会让自己变得自卑和胆怯。

    想想有点小难受,但实际就是这样。要知道,人家是决策者或老板,你是人家花钱聘请的员工而已,你们不是朋友关系,更不是同一级别。

     ----------------------------------------------------------

    案例分析一:

    最近我一直在被老板骂,我非常窝火,今天分析下。

    老板分给我和同事小C任务,完成一个页面,分工是:C赋值多张Excel导入数据库,我赋值设计数据库和程序。老板看页面,当然会发现一些问题,于是骂我办事不力。程序问题我就认了,但大部分都是数据问题导致计算结果不符合要求。所以先是去比较客气的说:小C仔细肯某页面检查下数据问题。

    但是第二次老板看功能依然有数据问题,依然骂我。我很窝火,解释说数据不是我导入的,不是我的责任。但老板生气的说:我哪知道是谁的问题,我只看最后显示结果!于是我狠狠的去骂C,你对这页面,把数据检查好,不要让我背锅!! 老板指责我说:你不给他指出具体问题他怎么改?小C心中当然对我有怨气,老板这么说他当然更这么想。好吧,我去找出了各种数据问题,帮小C与外部数据提供方商量解决方案,然后让小C按照方案去解决。

    这不等于我替小C干了本该由小C自己被骂和检查的事,且导致小C埋怨?我并不是小C的上级,不过是一个吃了两年工饭和刚吃一年工饭的人合作完成一件事而已,老板也没说让小C听从我安排。

    我想着才是问题根源:我和小C同老板管理和安排,我对小C没有管理权,也就理应不对小C负责。 但由于老板不懂技术,它只看最后结果,而我是最靠近结果上游执行者,所以所有问题他都找我,所以批评也都传递给我。

    由此,引发下面的思考:

    你不可能让老板去学技术,你只能给老板一个简单的可操作的责任判断依据:准备一个正确的数据,让老板确认程序的正确性和完整性。同时用一些错误数据测试,总结出能一定程度容错的判断逻辑。其他数据,若出现错误,让老板直接去找小C。

     还有:尽量不要与一个被动的人合作,被动的表现:一件事情完成了,它不会主动向上级汇报;完成不了,他也不会主动向上级告知难处以让上级去协调经验丰富的前辈相助。他就这样捂着,直到最后被上级询问和责骂。 我不是他上级,合作结果更糟糕,我(替他)被上级责骂,然后替他完成一些他自己能完成的任务。 

    *程序员必须保证程序功能的正确和完整性:
    1)用一个正确的测试数据,运行程序,程序功能执行结果必须是正确和完整的。
    就必须保证: 字段存储、业务计算公式、业务判断逻辑、权限逻辑、安全机制、错误机制(记录和提示) 等正确和完整的。
    2)用一个错误的测试数据,运行程序,程序功能执行结果的错误,必须是可解释原因的。
    就必须保证:能一定程度容错的判断逻辑 正确和完整。
    3)需求变更后,例如:数据存储结构改变(添加、删除、修改数据结构)、计算规则改变,
    程序员应重新思考 功能具体实现过程的可行性,
    若不行,应要求对方给一个可行的方案,例如计算规则。
    若可行,程序修改后应满足1和2。
    此过程,应该管理者应修改合同,按新任务计算新任务时间,而不应让执行者背黑锅!
    4)若1、2、3成立,则数据录入错误,导致可解释原因的程序执行错误结果,而非程序bug。
    应追究录数据提供者失查和数据入库者失查责任。而不应让上游执行者背黑锅!

    *依赖与外部的任务

    依赖于别人的任务,应该优先级要排在最前面;
    依赖于别人的任务,有疑问,把所有问题汇总后,统一提出。
    别人说的话,要仔细听和看,立刻思考它的具体实现过程,快速产生疑问,马上问清楚。而不是马上执行,执行的过程中突然发现有疑问! 茶都凉了!

    --------------------------------

  • 相关阅读:
    SQL Server 内存数据库原理解析
    SQL Server 利用游标解决Tempdb究极竞争-DBA-程序员需知
    SQL Server 利用锁提示优化Row_number()-程序员需知
    SQL Server并行死锁案例解析
    SQL Server In-Memory OLTP 无损PPT分享
    SQL Server优化器特性-动态检索
    SQL Server 隐式转换引发的躺枪死锁-程序员需知
    SQL Server 优化器特性导致的内存授予相关BUG
    SQL Server优化器特性-位图过滤(Bitmap)
    SQL Server优化技巧之SQL Server中的"MapReduce"
  • 原文地址:https://www.cnblogs.com/hao-1234-1234/p/11813272.html
Copyright © 2020-2023  润新知