当我输入此内容时，一些开发人员正在创建他的启动应用程序，这将使他成为百万富翁。 好吧，足够富有以维持他的小生意并激励他创造更多。 目前，其他一些开发人员正在Google Play商店或Apple的Appstore或那里的网站上发布其革命性的应用程序或游戏。 寄予厚望和辛勤工作。 可能改变他们的生活。 这些赚钱或变得流行的小方法确实改变了我们的生活。 不仅从新软件创新简化了我们的生活的角度来看，而且从更改者的角度来看，那些构建了人们会说“谢谢您！”的东西的人。 或“您为我节省了很多时间！”。

“滑铲”开始

但是开发人员有时必须从某个地方开始。 他们必须学会用困难的方式解决容易绕开的问题。 而且，很可能他们会在第一家向他们提供报价的公司中这样做。 因此，这开始了他们作为开发人员的职业生涯。 以我的经验，到目前为止，这条路还很长。 我已经看了很多，并提交了很多行代码（在分布式VCS中仅占很小的比例）。 所以我发现也许我需要分享经验。 我并不是要警告别人关于其他开发人员的事情或炫耀。 简而言之，因为我想念那些刚开始学习的日子。 弯曲和前卫。

好吧，这听起来有些陈旧和陈词滥调，但是我不得不再说一遍。 在家中的软件开发与公司驱动的软件开发无关。 当开发人员进入公司环境时，他只是陷入沸腾的油中。 入锅。 如果他没有跳下锅，那么他以后很有可能会幸存下来。 问题是之后发生了什么，为什么大多数开发人员会允许他们不应获得的待遇？ 不是因为他们是开发人员，而是因为他们是人类。 当我们在隔间后面开始时需要了解时，很有可能在这些墙后面是饥饿的人们，他们将您视为他们的资源（或身体 ）。 没有太多的爱情空间（好的，不是那种意思）。 这听起来很糟糕而且很激进。 似乎每个经理，老板或主管都放在同一篮子里。 尽管我相信有相当不错的和有爱心的老板，但我也知道与我合作的5家公司中，只有1家具有足够礼貌的特质，这样我每当生病时都会感到很舒服，必须在银行或发生自行车事故。 当然，有好多好老板为我们提供谦虚的赞赏，但也有另一面。

知道了

不知道您的老板是否知道，但是您知道。 他们做错了。 并且您应该对此保持安静。 您上班时，会看到他们犯的所有这些错误，领取薪水，做事，回家，吃饭，睡觉，忍受这种疾病，直到您发现疾病已经吞噬了您的整个职业。 好。 否。只需告诉他们有关问题。 他们不会同意，他们很有可能改变他们对昨天与之交谈的沉着和服从的雇主的看法。 但是你会在乎吗？ 从这个角度来看，我不能忽略。 为什么？ 因为当您几年后辞职时，很可能再也没有人会记住您了。 也许很痛苦，但这是事实。 好的，如果您没有在网络上发明下一个重要的东西，或者没有组装出人眼所见的最好的Android平板电脑，那么您将在两天内被遗忘。 没有人在乎。

诚实对待自己在环境中认为的错误是至关重要的，您应该始终与老板交谈。 这不是个人的事情，而是为了公司的利益而普遍。 公司将受益，您也将受益，最重要的是集体意志。 还有那些追随您的人。 人们应该始终指出别人犯的错误。 不是取笑他们，而是与他们谈论。 在成为太阳能系统最知名的开发商的过程中，您会看到诸如糟糕的商业策略，公司内部的物流不良，丑陋的项目管理以及咖啡中的大量牛奶等情况。 公开展示您的观点是改变这一观点的最佳工具。 这比抱怨自己休息而不采取任何行动要好得多。 （ 我也不建议在桌子上跳跃时敲打鼓大喊大叫这个问题 ）。

当我以C ++开发人员的身份从事一个大型项目时，碰巧是一个多平台桌面应用程序，而以初级开发人员的身份从事我的第一个严肃项目时，我感到领先的项目经理低估了每个人的事情。除团队负责人（高级开发人员）提出的建议外。 我可能会猜测为什么会有这种行为，但这并没有使我保持沉默。 在某些时候，我试图组织会议，在这些会议上我会公开提及我认为整个项目存在的问题。 我并非总是对的，但是随着时间的流逝，事实证明我确实是对的。 经验不足的执行者很难察觉到经验不足的观察者看到的东西。 总是要尝试欣赏每个人的意见，就像您希望被别人欣赏一样。 如果您对项目有任何想法，即使没有考虑，也要在业务计划或项目管理层中分享。 毕竟，通过这种方式，您可以为公司的利益建立专业的参与度。

惩罚

惩罚是如此，2012年。
惩罚会制造愤怒，愤怒会变成怨恨。 您为什么要让员工不满意？ 不知道。 但是我知道为什么您应该让开发人员满意。 因为它们是生产链中的最终关键。 保持骆驼在沙漠中。

在与前面提到的同一家公司工作时，我曾经被叫到..井，比如说老板办公室，并被告知要删除有关另一家公司工作机会的转推。 我什至被警告说，如果不这样做，我可能会因破坏公司在社交网络上的声誉而被停职甚至被解雇。 我可能会补充说，这是离职的最后原因之一。 几周后，我辞职了。 又为什么呢 因为我被人民的无知，他们的优越感和解决局势的方式所困扰。

绝不能容忍惩罚，以强迫其采取适当的工作方式。 经理在做任何愚蠢的事情之前应该先与员工交谈，这会使他们在集体中失去价值。 当然，我并不是说开发人员或任何其他员工不会犯错误。 但是我猜我们是人，我敢肯定有很多文明的方法可以解决类似的情况。

估算是您创建的，以便您通过分解需求来获得项目背后的总体思路。 此外，您还可以通过估算来估计公司的交付成本，从而保护公司成功完成某个项目的企图的商业价值。 也就是说，估算的主要目的是服务于开发人员，然后是公司。

估算值

估算是开发人员必须做的事情，雇主必须尊重。 这是简单的数学运算。 如果我可以在10分钟内用盛满水的锅从A点步行到B点，主要原则是不要从锅中倒出10％以上的东西，那么双向步行最有可能带我大约20分钟。 当然，我可以在回程中奔跑，并在12分钟内到达最终目的地，但问题是，我很可能会损失一半的水。 如果公司不介意糟糕的软件和意大利面条式代码，那么这可能再也不是问题了，开发人员应该对此感到满意。 问题是当开发人员被迫用装满水的一锅从华盛顿到洛杉矶在两天内运行时，没有从锅中倒出50％的水。 这将与交付软件解决方案时相同。 人们倾向于削减开发人员的估算，甚至为自己无法进行的项目提供估算，这是开发人员所为，无论他的经验水平如何都不允许。 让我们不要误解这个想法，说开发者不应该急着去尝试完成一些紧急的事情，突然出现问题（例如“ 射击星星，撞上月球 ”，那种胡说八道）。 ）。 我要强调的是，一般做法是不考虑将要创建最终产品的人员或团队给出的估计。 不幸的是，这在大多数公司中很常见。 实际上，估计和交付过程完全不同。

当有人给您一个估计时，尝试查看是否存在任何高估或低估的情况，如果没有，请尝试遵守该估计。 因为这是一种告诉您我可以在x天内交付的方式， 所以在此之前的任何操作都会被强制执行且质量很差 。 另外，当有人为您提供项目估算时，是因为您要它。 如果您可以对其进行修改并使估算值适合业务需求，那么您永远都不会从技术角度要求估算值。 在这种情况下，您可能需要的是项目管理估算，其中开发估算将在一定范围内作为时间提及。 毕竟，您永远都不会超出预期。 如果您删除了一个估算，请告诉创建该估算的人。 您需要通过质量来寻求业务价值，这与开发人员无关。 如果您想那样玩，请自己弄清楚如何做。 通常，从估算中扣除的是开发人员或质量检查工程师估算的质量检查时间。 开发人员不应允许这样做。 质量保证是重要的过程，不仅有助于交付项目，而且还可以验证开发人员提供无错误解决方案的能力，这是所有开发人员都应追求的目标。

来自地狱的客户

如何处理要求您构建适当的软件解决方案但未提供适当要求列表或规格的客户？ 嗯，这很简单，有两种方法可以做到这一点。 首先是如果您在一家客户与您的老板就项目性质和需要满足的要求进行谈判的公司工作。 在这种情况下，您作为开发人员将在您和客户端之间拥有缓冲。 当我说在那种情况下，客户不应该知道谁是该项目的主要开发人员 ，拥有他的Skype，Email或GTalk联系人时，请相信我。 为什么？ 因为有些生气的客户第一次发送关于您搞砸的事情的反馈（无论是谁的错）都是您。 还有您的CC老板。 因此，在保持客户端的第一步的企业驱动的环境中满足正在清楚所有你需要做的，得到你需要他改变主意之前的一切。 并记录与客户进行的每一次沟通，每次会议（是的，创建MoM并将其转发给老板）。 这样，当客户的手指指向某人时，您就不必再胡说了。

当您不在公司工作并以自由职业者或自己的公司的身份在家工作时，避免不良客户的另一建议是，首先不要选择不良客户。 糟糕的客户会占用您的时间，使您亏钱（因为您浪费时间），并且使您无法正确完成项目。 动力是工作的90％。

老板无法处理的不良客户的第一个症状是随风指令 （正如Mark Berry所说的） 发生变化，并且没有提供规范。 考虑此类情况时首先想到的一位客户向我提供了一个规范（准确地说，是在我的电子邮件中），该规范实际上是一个Powerpoint文件（.ppt），其中包含另一个应用程序的屏幕截图，并用红色文字进行了拍照。解释。 那是我当时工作的公司收到的第一个规范，也是那种类型的第一个规范。 但是，由于经验不足，并试图在进入的新环境中证明自己，我接受了此文件作为SRS。 最初的估计是一个半月。 完成该项目耗时11个月。 因为两件事。 开发工作按时完成，但随后开始了修复（QA）阶段，客户将在今天报告10个问题，在明天报告120个问题。 在某个时候，他的修复过程变成了功能/更改请求，我们必须进行其他开发，然后通过改变主意，将一切恢复到原来的状态。 如果我在最初的3个月内发布该产品，我个人将赚取数千美元，这需要11个月的时间。 我可能收到了用户的负面反馈，但我希望坚持早发布，经常发布哲学，定期发布更新，以解决实际用户而非客户脑中虚构的朋友报告的问题。 毕竟，整个公司，客户以及作为开发人员的我都失去了太多时间，动力，金钱和脾气，无法继续从事新项目。

始终要求提供规格说明，功能列表或定义项目的任何内容。

不良成长

公司每天成长并充满尘土。 您给了本月薪水的那个昂贵的企业家会说这是每个公司的自然过程，但我认为这是公司的不健康发展。 让我们置身于一家小型公司的总体思路。 我们有5个开发人员和3个项目经理，我们有2个老板（比方说CTO和CEO）。 项目经理应该执行一项简单的任务，称为度量 。 他们获得规格，估计，风险并一起进行度量。 他们可能控制他们领导的雇主的行为，但项目经理绝不是开发商的老板（即使没有确切说出）。 与我们大多数人相反的经历是，项目经理表现得像老板一样。 这不是公司成长的真正问题。 当提到的CTO和CEO决定，如果他们再雇用2个项目经理，使他们与开发人员的数量相等，就会出现问题。 然后游戏开始。 这两位经理将是首席经理 ，其他两位仅仅是项目协调员，而每个开发人员都将只有一位项目经理。 废话！

面对现实吧。 开发人员很难处理。 您不能在家中用愚蠢的自我和情结给他们施加压力。 您可以做自己需要做的事情，而不会因为不太重要的问题而打扰其他人。 项目经理应该不再是开发人员和高层管理人员之间的代理。 每个人都可以将电子邮件转发给公司中的其他几个人。 开发人员不需要秘书来重新发送电子邮件，他们需要经理来处理开发过程中的更改，风险和约束。 是的，开发过程是很神奇的事。 在一家公司中安排更多的项目经理会使情况变得更糟。 在软件开发领域，项目经理通常做的事情是70％的开发人员可以自己做。 你不能说相反的话。

别忘了分享！

参考： 2Dwarfs博客上来自我们JCG合作伙伴 Aleksandar Balalovski的不良开发人员–好老板（I） ， 不良开发人员–好老板（II） 。