离线下载
PDF版 ePub版

梦里风林 · 更新于 2018-11-18 07:00:35

团队技能

如何管理开发时间

管理开发时间,需要维护一个简明且实时更新的计划。一个工程计划是一个估计,一个时间表,一系列取得进步的里程碑,还有对你的团队或者你的时间在每个任务的估计和安排。这也应该包括你需要记得去做的其他事,比如与质量保障人员见面,准备文档,或者订购设备。如果你在一个团队里,工程计划会是一个共同承认的协议,不论是在开始,还是进行的过程中。

功能工程计划存在的意义是帮助做出决定,而非展示你是如何组织的。如果一个工程计划太长或者不是最新的,它对做出决定将是无用的。现实中,这些决定通常是关于独立的个人的。计划和你的判断让你决定你是否应当把任务从一个人身上移到另一个人身上。里程碑标识了你的进步。如果你有一个奇妙的工程规划工具,不要被为工程创建一个表面巨大设计(Big Design Up Front)所迷惑,但可以用它保持清晰和实时性。

如果你没有一个里程碑,你应该采取即时的行动,比如通知你的 boss 工程已经滑过的部分中进度的完成。这种估计和时间表可能不会在开始时很完美,这会产生这样一种幻觉,你能够填补工程的上一个部分中错过的日志。你可以。但这很可能是因为你低估了那个部分或者高估了一部分。所以工程进度的完成已经滑过了,不管你是否喜欢。

确保你的计划包括了:内部团队会议,写代码,文档,规划周期活动,集成测试,处理外部关系,疾病,休假,已有工程维护,还有开发环境维护。工程计划可以作为一种为局外人或你的 boss 准备的关于你或你的团队正在做的事情的视图。因为如此,所以它应该是短且及时更新的。

如何管理第三方软件危机

一个工程通常依赖于它所不能控制的组织,第三方软件危机是每个相关的人都必须意识到的。

永远也不要把希望放在蒸汽上面。蒸汽是任何所谓的尚未可用然而声称可用的软件。这是最确定的一种破产的方式。仅仅怀疑一个软件公司在某个日期对于某个软件产品的某个特性的承诺是不明智的。更明智的做法是完全忽略它,并且忘记你曾听说过这种事。不要在你的公司使用的任何文档里写下这些东西。

如果一个第三方软件不是蒸汽,它仍然是有风险的,但至少它是一个可以处理的蒸汽。如果你正在考虑使用第三方软件, 你应该早点投入一点精力去评估它。人们可能没听说过,评估三个产品的适合性要花两个星期还是两个月,但这必须尽可能及早做。没有合适的估计,集成的代价不能被准确计算。

理解已有的为某个特殊目的的第三方软件的适用性是非常见仁见智的东西。这是非常客观的,并且通常住在专家心里。如果你发现了那些专家,你可以节省很多时间。很多时候,一个工程会如此完全地依赖于第三方软件,以至于如果集成失败了,工程就失败了。像时间表里写的那样清晰地表达了危机。如果危机不能被尽早消除,试着订一个为意外准备的计划,比如可用的第二方案,或者自己写下功能点的能力。永远不要让时间表依赖于蒸汽。

如何管理咨询师

使用咨询师,但不要依赖他们。他们是神奇的人,非常值得尊敬。因为他们看过许多不同的工程,他们通常比你知道更多具体技术,甚至是编程技术。最好的使用他们的方式是像家教那样用例子教学。

然而,他们通常不能像正常员工那样用相同的感觉融入团队,可能仅仅是因为你没有足够的时间去学习他们的优点和缺点。他们的工资更低。他们更容易离开。如果公司做得好,他们可能得到的更少。有些可能是好的,有些可能与平均水平一致,有些可能挺糟糕,但希望你对咨询师的选择不会像你对雇员的选择那样仔细,这样你会获得更多不好的咨询师。

如果咨询师要写代码,你必须在你使用它们前仔细 review。有着大段带风险的代码,你到不了工程的终点。事实上这对所有的团队成员都是成立的,但你通常有更多与你接近的团队成员的知识。

如何适量交流

仔细考虑会议的代价:这花费了随参与者数量倍增的时间。会议有时候是必要的,但越小越好。小会议的交流质量更好,过度浪费的时间更少。如果一个人在会议感到厌烦,把这当做会议应该更小的标识。

非正式交流值得做任何事情去鼓励。更多有用的沟通工作在同事间的午饭可以进行,而非其他的时间。许多公司没有意识到或者不支持这一点,这是一种遗憾。

如何直言异议以及如何避免

异议是一个做出好决定的绝佳机会,但这需要被谨慎处理。你可能会觉得你充分的表达了你的想法,并且在决定做出前,你的意见已经被听取。这种情况下,没有什么可以再说的,你应该决定你是否要支持这个决定,即使你不同意它。如果你可以在自己不同意的情况下,支持这个决定,就这样说实话。这展示了你是多么有价值,因为你是独立的,不是一个唯唯诺诺之人,同时是一个尊重决定的团队成员。

有时候一个你不同意的决定,会在决策者没有充分听取你的观点前做出。你应该在公司和集体的基础上评估是否应该提出这个话题。如果在你看来这只是一个小错误,这可能不值得重新考虑。如果在你看来这是一个大错,你当然必须提出异议。

通常,这不是一个问题。在一些充满压力的环境下,在一些个人因素下,这会导致事情个人化。例如,一些非常牛逼的程序员在他们有好的理由认为一件东西是错的时候,缺乏挑战决议的信心。在最糟的情况下,决策者是不安全的,并会把这变成一个对权威的挑战。最好记住,这种情况下,人们会用他们大脑中爬虫动物的部分来做出反应。你应该私下提出你的争议,然后尝试展示新的知识是如何改变决议做出的基础的。

不管决议是否被推翻,你必须记住你永远不能说出“我的话撂这了,我早就这样告诉你了”这样的话,因为这个决定已经得到了充分探讨。

上一篇: 个人技能 下一篇: 评判