今天是周末，和大家说说我的成长故事。
我叫珍妮兔。出生在南方的一个小城市。
在报大学志愿的时候报了当时很热门的计算机专业。现在很庆幸当时的选择，因为IT行业现在仍然是和金融行业并驾齐驱的领先行业。
每次有人问我是做什么的，我都特别自豪的说我是做IT的!
大学的专业课里，有硬件也有软件。我当时的感觉是软件可以很快地出结果。
举个例子，比如说用Turbo C写一个加法，一句话就写好了。
但是如果用汇编语言的话，要写长篇大论才能完成简单的加法运算。我当时就想：
这么麻烦——还不如我自己来算。。。
当时的这种想法挺小白，不过就是当时的这种想法，让我决定未来要在软件领域发展。
和很多计算机专业的同学一样，毕业后我成为了一个软件开发工程师。和其他计算机专业的同学不一样的是，我光荣地成为了研发部14个同事当中唯一的妹子工程师。
说到这儿，肯定有很多人会自动脑补那些程序媛被众星捧月的场景：
其实真正的圈内人士都知道：
不存在的。
在一个每个人都累得像“人类最好朋友”的环境里，每个人能把自己的工作做完就很了不起了。周末加班也是日常便饭。
除了搬砖，当时我还作为我所在的项目的接口人，与外部客户对接。
外部客户是一个善良和蔼的男士——除了他喜欢经常改需求。我猜大概是从那个时候开始，我知道了“抓狂”是怎样一种体验吧。
直到我来到另一家公司：微软。
最开始我是在Office事业部，做现在的Office 365的前身——Office Live Workspace这个产品的测试和测试开发——也就是做手动测试和测试自动化的工作。
在这里工作我的最大的感觉就是整个人都好了很多。主要是因为工作任务很清晰，规范很清楚，比如有代码规范，代码签入前的评审流程等等。而且现有的代码的可读性很好，上手快，debug起来也心情顺畅。
这是我第一次体验到良好的研发过程带来的巨大好处——这种感觉就像是在35°的盛夏热浪中，突然走进了一座冷气十足的大型购物中心，整个人都神清气爽。
后来我作为项目经理加入了STCA(微软亚洲搜索技术中心）的一个卓越工程团队，帮助必应搜索的一个跨北京西雅图的大型团队大幅缩短了他们的基线发布周期。
前些时候，我帮助现在公司的一个团队解决了他们自从组建团队以来困扰他们已久的一个问题——需求定义不清楚。
指导团队做改进之后，全体团队成员的匿名反馈显示：“需求定义不清楚”的痛点得到了明显减轻。(请每个团队成员对这个痛点的变化情况进行-5分到5分的匿名打分，0分表示痛点没有变化，-5表示痛点加剧到无法忍受，5表示痛点减轻到完全消失。综合所有打分结果，平均分为2.4分，所有打分均为正分。)
我热爱我的工作。不仅仅是因为我擅长软件研发过程改进这个领域(拥有CSM，SAFe大规模敏捷咨询顾问SPC, PMP，CTAL等认证)，还因为我在帮助这些团队的时候，我感到我也帮助了那个多年前刚毕业、对软件研发满怀热情和梦想，却在现实中苦苦挣扎的自己。
这就是我的成长故事。
如果你的团队也在承受一些研发协作的现实问题，欢迎阅读原文关注“轻松做软件”。让我们一起来面对问题、解决问题，用先进的软件研发实践帮助团队可持续地提升效率，发掘软件研发的真正乐趣，实现最初的梦想!
END
预告：下周我会发一篇长文专门讲如何搞定一个大家普遍比较头疼的问题：需求变更，敬请期待:)
嗨，我是敏捷教练珍妮,
前微软亚洲搜索技术中心卓越工程顾问,
我的目标是帮助所有IT人更轻松地做软件！
如果你喜欢本文，或者对下面的文章感兴趣，
欢迎扫描二维码关注阅读.
小型研发团队如何处理来自多方的大量需求？
如何管理用户期待？
为什么加班是反模式？
怎么样才算软件做得好？
扫一扫
8万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
