软件外包中常见的七个错误之一 - 不懂用户需求

这是一个致命的错误！一些人对软件项目采取一种“如果你建他们就会来”的策略。那样的项目是彻底的失败，因为它们不能满足用户的需求。
为了避免这种错误，你需要花费一些心思了解那些将会使用你的软件的人。这是确保你清楚地知道你的程序应该做什么的唯一途径。
如果这是显而易见的，继续读下去；大多数人没有足够重视这一点。
了解你的用户给予你关键的点子以使你的程序超出他们的预期。你需要知道：
用户期望软件为他们做什么
他们希望输入什么
他们期望什么的输出
他们将对输出做什么
用户怎样与程序进行交互
程序怎样与现实世界相适应
你必须比大多数用户更好地理解你正在解决的问题。你通过与许多使用者交谈来做到这一点。

好了，让我们来看看当你与10位用户进行交流时事情通常是什么样的。通常会出现以下几种情形：
10位用户中差不多3位完全是在浪费时间。他们并没有真正思考周围的环境，或是他们不想与你分享他们的想法
。一旦你确定某人正是这类人，礼貌但快速地结束谈话。
10位中有4位会提供给你很好的信息，那些你需要知道的东西。在一些问题上，一些人会有一些细微的差别。大多数人告诉你的与其他人相同。这类人为你的程序应该包括的基本功能特性提供了坚实的基础。
剩下的3个人会带给你灵感，或者在你从其他7个人所学到的基础上激发一些很棒的想法。这就像捡到金子一样！

试想一下，其他7个人（也就是用户群的70％）会怎么想，当你创造的程序突破性地超出了他们的预期。

现在有一条通向成功的路了！

提醒一句，当你与用户交谈时，有时你的情绪会有点过火。有些人真的让你拿他没办法。
别往心里去，记笔记吧！
当在讨论中陷入这种情况，你已经找到一个帮他们解决重大问题的机会了。

我知道的一个人，我们经常叫他Pete，他拒绝与那些说“Joe知道什么啊？他只是个搞航运的。”之类话的用户交谈。

严重错误！
Joe知道任务完成的期限，这是电脑应该为他做的。
Joe知道那些未完成的工作（或者那些完成得很差的工作），因为它们让人头疼。
Joe知道发货的最有效率的步骤。
Joe知道那些不涉足航运业的人所不知道的许多东西。

现在，Joe可能无法出来将上面几点都解释清楚，但我保证你在一杯咖啡的时间里可以了解个大概了。以一种有用的形式把你所了解到的组织起来是很容易的。
即使你没从Joe那里学到任何东西，至少在这个项目上他会买你的帐。这很重要，因为将你的程序付诸实施你需要合作。记住，许多人惧怕电脑并且拒绝改变，你可能需要帮他们转变这种想法。

另一个我听过的不和用户交流的借口是“我没有时间。”
对此我想说的是，如果你没有时间和用户交谈，那你哪有时间大干一番呢？省下一些时间、金钱，还有忧伤，第一时间和你的用户谈谈。

根本所在：让你的用户成为最重要的特性。如果你不想要某个特性了，并且它不是业务所必需的，别在上面
浪费时间了，不管别人认为它是一个多么好的想法。

这就是我这次所要说的，与你的用户交谈去吧！
下次我们将说说2号错误；这是一个使许多新手陷入大麻烦的错误。

软件外包中常见的七个错误之二 - 不合理的预期

这是刚接触软件项目的人最常犯的错误。不合理的预期导致失望和失败。
那么，什么样的预期是不合理的呢？

很多人想仅仅写下一些关于他们希望程序做什么的一般想法，在自由职业者拍卖网站上张贴出来招标，挑选一个程序员然后就坐下来等待完成的产品。
不幸的是，事情并不这么简单。你需要花时间和精力去计划，管理，并测试你的软件，以便得到你真正想要的。
雇用一个自由职业程序员不像从船上发射一枚巡航导弹攻击陆地上的目标那样是一项所谓“开弓没有回头箭”的技术。它更像一辆作战坦克，需要开到战场上去，合理地就位，瞄准敌人并在准确的时机开火。为了取得成功，你必须参与这个过程。

一些人仔细地计划他们的项目然后期待所有事都像他们计划的那样进展。
如果是这样就好了！
意外是软件项目的本性。
一些特性最后发现是不切实际的；一些看起来很容易的特性永远无法实现；一些看起来很难的特性结果根本不成问题(只是别保证一定可以）。
你必须有准备，有决心，并且灵活地完成一个相当大的软件开发项目。

一些人想在他们第一个项目上就石破天惊。
不大可能！
你应该从细微、容易管理的地方着手。软件项目规模大了就越发困难，所以还是从一些简单、花费少的地方获取一些经验。
要想学会怎么管理一个软件项目，从一个大项目开始是很痛苦的。
你可能至少有一个小项目你要去完成；也许想为你的网站改头换面，或者一个从你的网站数据库生成报告的PHP脚本。
即使你正考虑自己做这个项目，外包是一个不错的备选方案。这允许你去了解一个你很了解的项目的关键东西。这也让你有时间去完成更重要或更有利可图的任务（特别是当这个项目还没完成）。

有些人期望一个程序员就做出像他们的文本处理器一样功能强大的软件，付给他们同样的价格，如果他们从印度找到一个程序员，价格或许更低。
那种文本处理器可是由一个大公司开发的，它有一个超过百名程序员的团队来创造和维护这些功能特性。他们已经在同一个项目上工作了很多年了。
显然，一个自由职业程序员不可能编出一大帮程序员才能编出的代码。
文本处理器的价格之所以低是因为开发它们的公司数以百万计的出售它们（嗯，不错的公司，是吗？）
对于你想要的特定软件，市场是很有限的。或许你是唯一想买它的人，所以应该全部由你买单。

一个自由职业程序员可以做得非常好的是写一个用户申请，为你解决特定问题。大软件公司无法做到这一点，因为它们不能大量销售你的用户项目。

这就是我要说的，下次我们将看看3号错误，一个让有经验的人比新手还差劲的错误。

软件外包中常见的七个错误之三 - 低估了项目的大小

几个月前，Paul打电话告诉我他正尝试外包软件开发。他想从我这里获得一点建议，但这是很典型的。
结果，paul和他雇用的程序员都发现他们有点低估项目的大小了。
Paul真是既兴奋又着急。他猜想这个程序员正焦头烂额但还必须交付任务。毕竟，程序员们都努力在他们获得工作的自由职业网站上建立良好的声誉。
Paul也很着急，但在这种情况下他又不能插手。他猜想一定有些负面的东西，但不知道具体是什么。
Paul是对的，这对他或程序言都不是个好兆头。
对于这种情况，这里有一些可能的结果：
1）这个自由职业程序员坚持把工作完成。如果是这样而你不给他奖金，你就将成为一个声名狼藉的购买者。
2）这个自由职业程序员匆忙完成并转到另一个项目。只要每个人都同意采取什么样的捷径，这是可以的。如果这个捷径是程序员随机挑选的，事情可能会很糟糕。
3）买者和自由职业程序员对项目进行协商并对价格/功能特性达成一致意见。只有当你和这个程序员之间合作很愉快并且项目已经进行得很远时你可能猜想这么做。
4）当项目无望完成时，自由职业程序员可能直接放弃。在这种情况下，你只好重新再来。

你需要学会估计软件项目的大小。学会这种技能需要时间和经验，但如果你打算做若干个项目这是值得的。你不必把估计的时间具体到天，只是大概地估计一下一件事情需要花多长时间就很不错了。
在开始的一两次里，任何好的自由交易网站都会帮你做到这一点。只要联系网站的维护者并把项目描述发给他们。他们能告诉你这个项目大概得花多少钱。
尤其是那些要求你根据项目花费把项目归到小、中、大类别里那些网站，它们都能做到这一点。

那么Paul到底是怎样陷入上面这种情形的？
他选择了一个经验不足的程序员的最低出价。
Paul是怎么解决这种问题的呢？
结果很复杂。Paul强迫程序员完成项目。即使支付了程序员一小笔奖金，他仍然省下了一些钱。但程序没能满足期望的要求。
这还是说明了一点，付出多少就收获多少。
总的说来，如果Paul恰当地估计了这项工作，多付点钱，结果会比这个好。如果是这样，他会从程序员那里得到他想要的，而不是他能得到的。

这就是我要说的，下一次我们来看看4号错误，对任何对他们的新软件项目兴奋不已的人，这都是一个陷阱。

软件外包中常见的七个错误之四 - 与开发者没有共同观点

你有没有参加过一个已经开始但仍处于早期阶段工作的项目？对任何项目而言，这都可能是一个茫然的时期，尤其是对一个软件项目。
这很像警察来到交通事故现场时。一件事情，五个目击者，三个版本的故事。
不幸的是，很多时候，一个软件项目的早期阶段就像这样。
刚接触软件开发的人经常惊讶于雇用的开发者们从一个文件得出如此之多不同的解释。对一段话甚至一个句子也是如此。
让我们看看我们可以做些什么以防止我们的项目看起来就像那种事故现场。
当雇用一个自由职业开发者，大多数人回答开发者关于项目的问题并且认为如果他没有对项目的特定部分提出哪怕一个问题，那么万事OK；可以开始编码了！
但愿如此！
他们忽略了什么呢？他们忽略了所有的假设：
写项目描述时所作的假设
阅读描述时开发者所作的假设
人的本性使得我们很容易掉进这个陷阱。不然为什么你写下所有东西，从头到尾仔细地检查，你可能还要找个人帮你再检查一遍。
问题是我们倾向于从我们自己的视角写东西，甚至没有认识到我们所作的假设。帮你检查工作的人可能与你有相似的看法，所以并不像你期望的那样有帮助。
注意，你对自己的业务了如指掌，但你的软件开发者可能对此一无所知。
想想你每天在自动驾驶仪里所做的所有事情。向一个刚涉足这个领域的新手解释这些事情，你要花多久？第一次你会忘掉多少应该提到的注意细节？
好了，那么怎样解决或规避这些问题？
你的项目描述必须简明扼要。保持简洁、集中。言辞过多只会使得更容易出项不同的解释。
对于项目最重要的部分，向开发者问一些盘根究底的问题。这样你就可能发现你和开发者所作的一些假设。
尽可能早的从开发者那里获得一些有趣或有用的工作成果。