7月4日, 想着正式工作四年了 7月9日, 公司这边出了点状况, 歇业, 也从公司离职了 7月10日, 衡山溜达了一圈 7月19日, 想着正好加入甜品十一个月了 7月18日, 生日
去年的七月, 也刚好离职, 正在一路北上的旅途中. 情况似曾相识.
一些工作上的review
作为工程师, 似乎很容易陷入, 将做项目, 变成完成任务.
前置是需求, 有产品帮cover, 但是项目的后置, 是结果, 更多的是依赖自己.
需求分析后, 系统设计之初, 就应该考虑: 日志/统计, 考虑如何去衡量"结果".
项目上线后, 要跟!!! 分析及反馈数据, 让更多人了解现状, 以便后续决策.
做事如果没有结果, 会导致可能错误的不断投入精力处理一些不重要的事情, 甚至根本不需要做, 沉没成本
事情做了, 要有一个结果, 好/不好/不好不坏, 无论如何, 自己都要有所感知. 关乎成就感.
如果不好, 就快速失败, 砍掉或者修正, 总之, 不要往错误的方向越走越远.
当然, 这涉及和上下游多沟通交流.
所以, 建议无论产品或者研发, 做完一个项目, 都要有相应的review, 总结并通报相关人员.
人员构成很重要, 要互补, 必要的时候能"千斤顶"
做事多向前走一步, 不要老是停留在自己的"舒适区"/“自留地”, 多走一步, 更高效协作
找准节奏, 快速度过磨合期
不要因为一时繁忙, 因为忙不过来而找人, 痛上一痛再做决定
不要给人找事做!!!!!(一时事太多=> 招人 => 没事干 => 找事干……)
各司其职, 信任伙伴, 不要大跨界或者插手太多, 无谓耗费自己的精力, 你的精力可以在自己擅长的地方发挥更大的作用
没有万能药, 可以实施, 试试, 阵痛, 改进, 最终摸索到适合团队的
一个Sprint只集中精力处理有限的目标. 不要分散了精力.
Sprint, 是用来实现需求的, 而不是用来砍需求的!!!
看板, 从整体一个大看板, 到最终根据业务线逐步拆分, 整个过程用起来感觉很有效.
项目制, 可以先找小的项目试验, 核心成员参与, 先run起来, 成功了再扩大范围. 很多东西不能操之过急.
用好用的工具, 用好工具
mac/邮件/jira/stash/confluence等等, 整个团队达成一致, 高效协作
使用工具的整个过程中, 也势必遇到的各种问题, 例如团队规模的扩大, 业务线增多, 跟上游产品的协作, 配合sprint等等, 这都需要在不同阶段进行调整, 对工作流进行优化, 形成一些约定. 以提高协作效率为第一目标
工具能买就买, 找个工程师花几个人日搭开源的, 以及后续维护, 还不一定好用(这都是隐性的成本), 还不如花钱搞定, 况且如今各类工具成本已经非常低廉了:)
快速实现, 快速验证.
不要一开始就妄图设计一个完美的系统: 需求会改/项目会砍
一开始不要想得太过复杂, 基本流程ok, 上线, 迭代上线完善的功能, 不要一开始就花大力气想直接搞定, 因为这里面很多成本其实是不必要的, 搞不好你花了一周赶完, 上了发现根本毫无用处.
当人肉顶不住的时候, 再考虑做系统. 理由同上, 费劲搞了系统, 结果要么业务没上来, 没达到"人肉"顶不住的情况, 要么就是业务废弃了/砍掉了. 搞系统耗时耗力不一定有用.
很多时候, 无论是产品, 还是研发, 都会忘了最初出发的目的是什么.
产品被一大堆细节淹没, 而研发将大目标切碎逐步做的过程中, 很那有整体的概念.
可以尝试, 可以变换, 但是要明确, 所有人都明确.
一切, 轻重缓急, 排期, 以目标为导向
目标导向, 但同一个时刻, 不要有太多的目标, 不要一个目标未完就想在此基础上尝试新的目标.(精力分散/事情没做透)
不要太过理想主义
这十个月, 经历了很多, 团队由小到大, 项目由1到28, 从0到1, 造了很多轮子, 经历了整个团队协作方式的变更, 经历了磨合的阵痛, 经历了一轮又一轮的sprint, 经历了第一版上线, 到最后第80个安装包, 经历了一次次上线, 一个个活动, 看着后台用户数一点点涨起来, 看着全部api调用一点点涨起来, 然后掉下去>_<#(这似乎是个悲伤的故事……)
但是, 这十个月, 从第一天到甜品, 感受到"家"的气息, 到最终收拾离开, 关小黑屋, 晨会, 愉快地coding, 聚餐等等, 十月风雨, 过得很充实, 也学到很多东西, 感谢所有糖厂的银, 帮助及包容.
闲了一周了, 趁这段时间, 打算做做总结, 重写一些代码, 读完CPython源码及APUE, 还有, 就是学车及休息
整理整理, 想明白一些东西, 再重新启程.
希望明天会更好吧
既然选择了远方, 便只顾风雨兼程, 共勉
wklken
2015-07-24 于深圳
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。