聊聊impossible person

某天上班路上听到一则讨论how to deal with impossible person的广播,短短几十分钟感觉受益匪浅。回想满是‘高智商低情商’的IT界,不知道身边多少impossible person,他们可能在我们的圈子里,可能是我们的客户,更可能是领导。这类人之所以被称为impossible person,“不可能先生”,因为我们不可能和他们达成共识,不可能进行理智的谈话,他们永远认为毛病出在别人的身上。

这类人群有多种类型,例如依赖型,控制型,竞争型,消极型,自负型,抱怨型,消极型(装可怜)等等,针对每种类型有不同的处理方式,但存在一些通用的原则,帮助我们避免陷入无休止的争论中。

1. 不要尝试改变他们
不可能与他们进行理性的讨论,他们根本不听原因,即便是合理的,所以别在一个点上争执,避免一对一争执,引入第三方团体。不要辩解,因为说服不了他,他也不听原因,因为他觉得就是你的错。不要冲突,因为他就是想挑事的人,擅长颠倒黑白,如果你开始情绪化,被他激怒,这正好是他想要的,就是故意伤害你,让你成为坏人。不要理会他,保持距离,不要跳进他想要的冲突陷阱,别给他发怒的机会,他就会转移到别的地方。
2. 调整自己心态,冷静下来
深呼吸,当你觉得要失去理智,发怒,赶紧离开,或者找其他事情干,让自己远离他,这样避免不理智结果发生而后悔。性格不合,其实两个人本身都没有问题,但他们在一起却没发融洽的共事,是双方沟通问题。避免以牙还牙,不要作为报复或者存在不平衡感,让自己变成了impossible person,将这些不好的特性反过来用在别人身上。将这种过程当做一次成长,当做一次人生课程。当impossible person意识到自己错了,自尊心会让他们的行为导向另一个极端,不要被这种行为所左右。他们就是想找软柿子捏,你想表示和平,谦虚,不一定需要让步,表现出懦弱,要保持自尊心,做自己,找个懂你的人倾述,例如旅行,在线社区,好友等,让自己好起来,不要一个人生闷气。不要老想这件事情,让自己从事更多有意义的事情,认识更多的人,不要让冲突影响到自己的正常生活。千万不要带着情绪卷入讨论中,保持沉默,偶尔幽默一下,表现出中立的态度,就事论事。也找找自身问题,即便自己是对的,站在对方角度自省一下(也会让自己平静下来)。
3. 尝试理解他们,找到value language
即便是impossible person,他们也有自己的诉求,有自己value language,找到他的value language,学会成就别人。
4. 不要让他们成为敌人
如果他还不是那种找茬型的人,可以考虑提出一起思考型问题,大家一起商量,而不是钻到牛角尖,让他觉得你确实在努力解决问题。动态规划,这个属于高级策略,就是要预测到他的下一步计划,而采取相应的反制措施。如果是长期的,实在躲不开的情况,做好打持久战的准备,学习他的策略,提前考虑应对策略,终极策略就是可以准确猜到他下面会怎么做,这时候也要明确告诉他:“你真的非要这样吗?”,至少某种程度让他感受你的坚毅。给自己设置原则和底线,让他知道底线,超出底线绝不能妥协。无论他多需要你,多么强烈挽留,远离impossible person。

我觉得在IT领域重点防治三种人:控制型竞争型消极型
1. 针对控制型的人,因为他们必须要证明自己是对的,喜欢指责别人,所以别试图证明他是错的,或者你做的更好。
2. 针对竞争型的人,他们总想争个高下,没有冲突也要制造冲突。不要受他情绪影响,他们要没无休止的斗下去,要么彻底甩掉你。如果他不肯让步,就让他赢,另找时间再进行研究,别耗下去。同时不要被恐吓到,被控制,或者闹翻,做好自己的事情。
3. 针对消极型的人,他们表面不说,甚至微笑,但下面却在准备攻击,会将来偷偷的爆发出来。这种情况要摸清到底为什么,不要表示出敌意,真心估计他说出真实的想法,沟通到正面解决。

总之,关于impossible person,不要认为这类人不会出现在我的身边,积极面对就好。第一,平常心,保持冷静。准确识别impossible person,treat like a game,like way to grow up; 第二,不要让自己变成impossible person,不要冲动起来。

REFERENCE
http://www.wikihow.com/Deal-With-Impossible-People
http://www.huffingtonpost.com/deepak-chopra/how-to-deal-with-difficul_b_598163.html
http://www.scienceofpeople.com/2014/03/4-types-difficult-people-deal/

聊聊impossible person

一次不错的敏捷实践

角色:
Project Manager(PM), Business Analyst(BA), Tech Lead(TL), Back-end Developer (Dev), Front-end Developer(UI Dev), User Experience(UX), QA(Quality Assurance)

工具:
Trello, Zeplin, Story wall

前提:
客户已经确认需求及范围,解决方案和交互确认

流程:
1. BA拿到客户确认的需求,和Dev,UI Dev 将所有需求划分为N个迭代(每个迭代一般为两周),然后一起给每张卡估点。
2. UX在zeplin中添加视觉稿和交互细节,期间UI Dev和BA会参与。
3. BA画故事墙,包括backlog,in dev, ready for int, dev done, in qa, qa done, blocked。
4. BA写story,列出Acceptance Criteria(AC),每个AC代表一个功能点,同步到trello以及纸质故事卡上墙(一张Story卡被分为前端和后端两部分,前后端分离)。
Dev和UI Dev分别找BA开卡(kick off),需要BA,QA及UX同时在场,确认完的AC,分别在屋里墙和trello把卡拖到in dev,在trello添加自己的名字
5. Dev和UI Dev共同确认契约,制作mock数据。
6. Dev或UI Dev开发过程中,自己在trello中购选AC,表示完成该功能点。
7. Dev或UI Dev开发完成后,找BA和UX sign off卡,得到确认后,将卡片拖到ready for int。如果UX觉得UI没达到预期(经常发生)或者BA觉得AC没有完成,则继续做卡直到sign off成功。
8. 如果同一个功能的前后端都完成了,一般由UI Dev发起进行集成或联调,非mock数据,一般在dev或者qa环境下完成,无误后放到dev done中,等待QA来取测试。
9. QA如果发现bug后分两种情况,如果属于story AC没有完成或者遗漏需要追加AC导致的bug,则把story卡挪回in dev,等待开发修复,如果属于技术型bug或者功能覆盖不全面的bug,QA可以写一张bug卡,放到in QA或者in dev等待开发领走修复。
10. 如果往复直到所有卡都在qa done,表示一个迭代结束。
11. 期间频繁会和客户交流需求,因为在开发过程中经常能发现不清晰或者没有考虑到的实现细节,一般由BA主导,Dev和UI Dev配合完成。
12. 每一周PM会发一封周报给客户并抄给团队,说明上周进度,完成的story卡,消耗的人天,团队成员变化。

站会:
固定时间,一般是每天的早晨,全员参加。
准备一个token,一般是一支笔,可以是任何东西,甚至平台支撑站会。
轮流说昨天story完成情况,以及今天的计划(言简意赅)。为了追踪项目进度和个人完成情况,每个人会用笔画’正’字,每一个笔画代表消耗一个人天,并挪走或领取新的卡片并贴上头像。
PM会询问进度,并更新客户的反馈。

故事墙:
故事墙包括backlog,in dev, ready for int, dev done, in QA, QA done, blocked。
一般蓝色表示后端卡,api卡;黄色代表前端卡,而红色是bug卡,卡上会标明该story的点数。
backlog放一个迭代所有需要做的卡片,BA负责放卡;in dev放正在开发的story,ready for int放前后端完成等待联调的story,dev done表示联调成功,QA可以进行测试,这三个由Dev和UI Dev负责,将卡片从backlog拿到in dev,以及到ready for int,最后到dev done;in QA表示QA正在测试当中,QA done是一个卡完全通过测试,等待上线,这两个由QA负责,从dev done取完成的卡到in QA开始测试,最后到QA done结束;blocked一般存放暂时不做或者由于各种原因没法继续的卡。
一个迭代的结束是所有卡片都在qa done中。
准备团队成员头像,每领一张卡,将自己头像贴到对应卡上,方便大家识别责任人。
一个好的实践是由Dev,UI Dev和QA自己挪卡,及时更新AC,便于PM跟踪进度,随时了解项目压力以提供应对方案。

话题:
估点应该所有Dev一起参加,还是只有TL和BA?
故事卡拆分到多大比较合适?这里根据CRUD拆成4张卡,单独算法或者拥有复杂逻辑部分单独拆开
Dev和UI Dev谁来做mock数据?
在没有jira情况下如何跟踪bug?进一步讨论引入jira的实践

一次不错的敏捷实践