过去的2019年有很多事情值得总结，做得好的事情，涉及商业秘密，不宜宣扬。疫情肆虐，封闭在家，闲得无聊，总结些失败的案例，以儆效尤。
记得19世纪末，有位叫开尔文的物理学家说：“物理学的大厦已经建成，晴朗天空中只剩下了两朵小乌云…”。100多年后的某一天，有个程序员也有了类似的感觉。公元2019年初，我觉得有了新的Python后台加入，我们的开发团队已经组建得比较完整了，意气风发，当然晴朗天空中也只剩下了两朵小乌云，一是团队的需求分析工作比较薄弱；二是团队技术栈太多，各司其职，缺乏沟通。为了提高团队凝聚力、战斗力，提高团队管理水平，我兴冲冲的报名参加了Scrum培训。
那么多培训，为什么要选择Scrum呢？我也有过一番深思熟虑：
刚过去的2019年是部门历史上很重要的一年，也是我自己很重要的一年，这一年有很多事情值得总结。
18年年底C#后台开发离职，大家都认为后台开发不宜再用C#了，连离职的C#自己都这么认为。当时领导问我去C#之后的后台技术方案，我稍作考虑之后，决定使用Python。很多小伙伴不解，我记得当时领导听了我的想法之后，第一句话就是：我以为你要选Java呢。确实如此，我本身就是做Java出身，写了快10年Java了，我为什么决定用Python呢？其实考虑还挺多的：
动不动就亲自上阵，是技术人员刚刚转型管理后常常犯的错误。刚开始我也经常这样，总觉小活儿分分钟钟就能解决，不好意思去和下属说；麻烦的问题交给下属处理，又觉得会让他们浪费过多的时间，甚至担心以前挖的坑会坑了下属。
这种想法是非常狭隘的，因为都是从个体的角度出发的，我们是一个团队，不存在谁坑谁，浪费谁时间的问题。我们都知道木桶理论，木桶的容量是由最短的那那块板决定的。作为老员工，主管亲自上阵也许可以做到最好，但是项目开发是团体赛而不是个人赛，团队里的短板一定会成为团队的瓶颈。团队不是主管一个人独舞的舞台，优秀的管理者要能坚定地把下属推到舞台的聚光灯下。
理想很完美，但是现实是困难的，项目工期紧张，不给新人慢慢成长的机会。身为主管，做为一个有经验的老员工，只好迎难而上。一旦投入开发工作，工期就排得满满的了，一旦工期延误，就会影响后续的测试，非常紧张，带团队的事情就只能希望团队多发挥一些主观能动性了。恰逢多事之秋，刚加入的新人就被晾在一边了。结果被领导发现了：你天天手忙脚乱的，你要多花点时间带带新人啊。唉呀，我真是太难了。
如何平衡自身工作与团队工作的关系，管理者有时候都没有意识到自己正处在这样的困境里。作为主管把时间投入具体的开发任务，看似保证了具体任务的进度，但很可能就会影响项目整体的进度，这是很容易忽视的问题。
平衡团队工作，一是保证其他团队成员工作顺利推进；二是确保团队发展不受限㓡。这些事情毫无疑问都是需要时间的，具体的任务也需要时间，究竟哪个更重要，哪个更紧迫，这很考验管理者的敏感性。如果工期特别紧张，必须要投入开发任务，那就要把任务拆得细一些，绝不能长期沉浸在具体事务里忘掉了团队。
一、信息化道路上的思想启蒙与文艺复兴
很多年以前，西方国家对我们实行技术封锁，我们必须向他们付出高昂的价格去购买他们的产品和服务。2010年，我上大学，几个同学拉我出去创业，做个小商城，我记得在当时，只要一谈起做项目，所谓的系统架构全都是Dell、IBM服务器配Oracle数据库。我印象很深，当时Oracle数据库特别的贵，没有标准的报价，业务量越高价格越高，而且还按核卖，CPU多少核，价格就乘多少。我心想，Oracle这也太能赚钱了吧！就一个看不见摸不着的软件，凭什么收这么多钱，服务器贵也就罢了，毕竟这么大，几个小伙伴一起才抱得动，抱着服务器的感觉多踏实。Oracle凭什么？
前两天一位同事跑过来和我说，咱们APP里医生列表的排序可以改进一下，因为我们有关注医生功能，医生列表应该把用户关注的医生排在前面。
这个需求不难理解，对用户来说，我关注了的，自然是因为这个医生与众不同，否则关注与不关注有什么区别呢。把关注的医生置顶就是迎合用户，增加用户粘性的作法，很多APP都有这种设计。
近两年来很多互联网公司都开始推行scrum敏捷开发，其实Scrum问世至今差不多20年了，scrum直到最近才开始被国内企业熟练使用，说明了两个问题：
前几天参加了ScrumMaster培训，培训非常棒，给Scrum中文网点赞。培训过程中认识了不少从事不同行业、不同岗位的新朋友，很多朋友来自传统行业，有不少是做软件外包、制造业的，这出乎我意料，我之前一直认为只有互联网公司才能用scrum。有的朋友直言：“甲方要求使用Scrum开发，我得好好学习一下Scrum，回去才有理由怼他们。”虽然这话让人哭笑不得，但这确实可以证明Scrum的影响力越来越大了。
很多APP里的都有好友关系，那么一般都会有这样的需求，用户可以为自己的好友设置备注，类似微信里的“备注名”，这个功能很实用，很常见，常见到大家会下意识觉得这个功能好简单，实际上细想一下这个功能还挺伤脑筋的呢。
首先数据结构比较简单，好友关系其实就是多对多的用户关联，好友关系表里再加个备注字段就可以了。存储比较容易，难就难在怎么展示。备注信息假如只能在好友详细信息页面查看，对用户来说就太不实用了，产品经理会要求所有出现好友昵称的地方都要显示为备注名（谁让微信是这么做的呢），比如下面这些页面：
今天不知道怎的和老婆讨论起说话方式的问题，我一听忽然就想起老婆曾经说和她们公司的程序员交流特别费劲，总是一句话说不明白，开会啰哩啰嗦半天也不知道他们说的啥。我作为一个正常的程序员，我忽然发现我也有这个问题，于是我就从自身出发，思考这个问题的原因，想了好久，今天提到这个问题嘛，我就想解释一下我作为一个程序员，为啥会有上述问题：
程序员作为一个职业，当然也有其职业习惯，程序员们互相交流，往往并不会用大量语言去从头到尾详细描述一个事物，他们描述自己的工作，喜欢逐个介绍其中的特点，往往很难一句话简明扼要的说出一个事物。
