Mobabel

Just One Pure ITer

Category: Project Management

0

Project Management

[转]如何才能写出好的软件设计文档？

作为一名软件工程师，我花了很多时间在阅读和撰写设计文档上。在磨砺了数百篇文档之后，我发现，优秀的设计文档与项目的成功之间有着密切的联系。 这篇文章将介绍怎样才能写出一份优秀的设计文档。 为什么要写设计文档？ 设计文档也就是技术规范，用于描述你打算如何解决问题。已经有很多文章说明了为什么在开始编码之前要先写设计文档，这里不再赘述，不过我想再补充一句： 设计文档是确保正确完成工作最有用的工具。

0

Architect&CTO

[转]哪个技术火就选哪个？热闹驱动开发的技术选型使不得！

本文的主题是技术选型，作者总结了他见过的各种不靠谱的技术选型方式，比如有的团队会根据社交媒体上的讨论来决定选择哪种架构，也有的团队会跟风走，哪个热门就选哪个。但总体来看，这样简单粗暴的方式一定会为未来埋下隐患。那为什么这样说？我们应该如何做正确的选择？且听作者细细道来。另本文译者余晟，曾经是主力程序员、技术文章的写作和翻译爱好者，现在在沪江负责研发和软件架构。欢迎关注他的个人公众号“余晟以为”，了解一位非典型 IT 人员对世界的看法。 软件开发团队所做的软件架构或技术栈的决策，很多并没有经过踏实的研究和对目标成果的认真思考，而是不准确的意见、社交媒体的信息，或者就些是“热闹”的玩意。我称这种作派为“热闹驱动开发（Hype Driven Development，HDD）”，眼见它的危害，我赞成更专业的做法，就是“脚踏实地的软件工程”。下面我们一起看看HDD的来龙去脉，想想能如何改进。

0

Skill

[转]转型项目经理，鬼知道我经历了什么

15年初，我怀揣着实现一个人生小目标的梦想加入到一家初创公司，希冀能见证公司产品从0到1，从1到10，融资从A到C。可是半年后，虽然产品从0到1是有了，但由于运营模式的限制，从1到10走的很难，用户规模上不去，融资也是没有影子。我开始焦虑起来，这样下去，我要当上总经理，出任CEO，迎娶白富美的人生小目标，可是要萎掉的啊。 于是，那时还是程序猿的我，渐渐”多事”起来：

0

Team

[转]少数派的力量：25%的人就能影响全局 | 《Science》最新研究

今天这篇文章，是关于《Science》的一篇研究，关于少数派如何改变世界。我觉得对管理、对创业、甚至对社群运营、对理解币圈，都很有启发，所以翻译过来并加上我自己的理解，分享给你们。   记得曾经看过一个关于火烈鸟迁徙的纪录片片段。刚开始只有少数的火烈鸟率先飞离湖面，然而少有同伴注意到。 这些少数派在接下来几日不断地飞回来，尝试看看能否激起更多同伴的回响，虽然这只小部队每天都在壮大，但是每次都只是吸引很少一部分同伴。 直到有一天，依然是这只小部队，但是带动了全部的火烈鸟群起飞迁徙。

Business presentation Free Vector 0

Skill

[转]技术演讲是不少技术领导人的拦路虎，5个小技巧你一定要知道！

你好，我是余晟，一个老程序员，一路坎坷走来，积累了些技术品牌和演讲的经验，今天，想跟大家分享如何做好技术演讲。 技术演讲，是树立个人和公司技术品牌的重要手段。相比撰写技术文章，它的效果也更生动、更直接，加上现场的互动，以及后续媒体的报道，往往能给人留下更深刻的印象。 但是做技术演讲也比写技术文章更难，因为做技术演讲时，你没有反复修改的机会，你必须直面观众、实时答疑，你的错误会被放大甚至广为传播…… 技术好的人未必能写得好技术文章，技术文章写得好的人也未必能做好技术演讲。不过，技术演讲也不是像天书一样无法琢磨，只靠天赋灵感，还是有一定章法可循的。下面，我就提供几条做好技术演讲的个人经验。

0

Architect&CTO

[转]架构师不写代码，能行吗？

  从什么时候起，技术角色的提升就意味着脱离技术与交付？CTO 不写代码已经引起诸多争议了，架构师也不写代码，能行吗？ 当我面试架构师职位的候选人时，我通常会问一个这样的问题：“你认为架构师是否应该做一些编码工作？”而通常会得到下面两个反馈之一： “不，我正在寻找一个不再需要编码的职位。” “我喜欢继续编码，至少是少量的编码，但可能不会有时间这样做。” 与此类似，当问及其他一些架构师最近做过多少编码的工作，通常得到的答案是： “有一段时间没有编码了。”

0

Skill

[转]大部分人没法一直做技术，但转管理也需要规避四大陷阱

国内的技术环境先天性地决定了，随着年龄增长还能一直深耕技术的程序员非常少。大部分人在某些特定的时间节点前都面临着转管理岗的抉择。管理工作并不比做技术轻松，难度上甚至可以说更大，一不小心还会踏入很多管理陷阱。本文就想跟大家聊聊，做技术的大牛们，当自己的技术达到一定的高度时，如何避免掉入管理的陷阱当中。

0

Team

[转]怎样在大公司混成中层干部？

一个霾香浓郁的下午，老G约我来到望京的一家星巴克，一把鼻涕一把泪地向我哭诉了他和他的CTO之间那些不可告人的故事。 老G有家行业网站，靠卖广告盈利可观，无奈增速较慢。去年，他听说巨头们靠做AI挣了大钱，再回头瞧瞧跟自己黑手黑脚干起来的骨干，恨得牙根直痒痒：这帮人的能力和视野，限制了我公司的发展，耽误了我上市发财！于是，他四处寻觅，重金从BAT某家请来了一位CTO。

[汇总]敏捷实施经验 0

Agile

[汇总]敏捷实施经验

1. 失败 放心吧，敏捷开发搞不起来！ 从零实施敏捷开发 敏捷中国十八年目睹之怪现状 敏捷走到头了！ 被捧上天的Scrum敏捷管理为何不受大厂欢迎了？ 敏捷开发将走向消亡，我们该如何应对 “敏捷”适用于汽车软件开发吗？ 敏捷软件开发，需要消亡 https://timdenning.com/agile-software-development/ 敏捷思维（知）+ 把敏捷的思维应用到实践（行），和把敏捷不加选择地、机械地用到各个地方是两码事，尤其是老板把敏捷的各类工具固化为监督员工劳动率的工具的时候更可怕。 同意，敏捷开发严重制约创造力和深入理解的能力. 敏捷化开发不是一堆规则，而是一种思想，一种思考和做事的方式。假如仅仅是停留在敏捷开发的各种规则的使用上，那只能说这个理解太过肤浅了 敏捷开发就是个渣渣，是一群没啥技术能力的人想出来的控制有技术能力的人的办法，就像项目管理里面的人不再是人，而且一种资源，毫无人性！ 大多数斥责敏捷的人无非是把自己定位为工具人，别人让干什么就干什么，然后把自己的状态甩锅到“敏捷”身上！ 公司为了敏捷而犯下的十大错误 第十、从上而下地实施敏捷 第九、“实施”变革 第八、聚焦输出 第七、忽视客户和用户 第六、敏捷仅面向 IT 第五、敏捷只限于团队层面 第四、敏捷只为更快的交付 第三、用瀑布式管理实施敏捷 第二、应用不变的流程及工具 第一、想要变得敏捷   汽车软件转型的困惑与痛点 杨修文的新书《智能汽车电子与软件：开发方法、系统集成、流程体系与项目管理》 本文节选自此书的第九章《转型软件的痛点与困惑》，这不就是我们当下正在面临的痛点么？且看段落标题： 互相低不下的头颅...