读懂程序员

最近项目中一些交流的问题让我很是触动。从最早的程序员，到后面的管理人员，再"沦落"到现在的程序员，我感觉自己应该反思下程序员某些典型的话语中的深层次含义，避免一些沟通中的误解。

1 "应该可以一周完成"

之前是程序员的时候，每当我说这句话上头都会质疑是否真的可以完成，通常沟通过后都会留一段缓冲时间。因为程序员通常是比较实诚和乐观的，说出"应该"的时候通常也基于"如果一切顺利"和"需求不变更"的前提。而这些在软件开发的过程中往往是不可能的。如果轻易接受这样的预测，项目通常最后会陷入无尽的加班加点，甚至还会延期。所以当我后来管理小团队的时候也谨慎接受程序员这样的估计，认真确认后也通常都会加一些裕量。现在又"沦为"了程序员，公司文化使得管理人员一般在程序员估计的基础上还要压缩，所以计划变成了笑话，延期的项目一堆堆，不延期反而成为了特例。

2 "这个功能很有吸引力""这个功能很不好用"

昨天跟策划沟通一个功能的时候，我和组员说感觉有个功能别扭、不好用，没想到策划回了一句："这是你们程序员的想法，用户可不会这么想"。这句话感觉有点熟悉，之前也听过这样的话。那是因为程序员跟策划或项目经理提建议说："这个功能很有吸引力"后得到的回复。当程序员认为"这个功能很有吸引力"时候可能是真正的期待在使用产品的时候有这种功能，同时也可能是因为实现功能所能带来的技术方面的挑战所激发的自我满足感。面对这样的话就要慎重对待，读懂字里行间透露的意图。不过当程序员认为"这个功能很不好用"就很可能实际就是如此了，程序员作为一个产品的开发者，很难想象他们在不认可的情况下可以全身心投入到这个产品。一个无法得到集体认同的产品也很难在竞争的市场中有所表现。所以想提醒策划同志，这样的话可以说，但不能在不合适的情况说，这样不仅无法解决问题，更伤害团队成员间的感情。

3 "这个是可以实现的"

程序员说这句话的时候通常漏掉了"但是……"，实现起来可能需要硬编码、可能需要特殊处理、可能需要一些晦涩的手法……，总之是有点勉强。这句话不同于斩钉截铁的"这个可以实现"，所以需要特殊关注可能漏掉的"但是"。如果是硬编码，需要考虑是否可以提取一套模型进行统一处理。如果需要特殊处理，就应该考虑是否是流程有不合理的，需要进行调整。如果需要晦涩的手法，就应该再次认真确认是否有一些通用的技术也可以解决现有问题。

4 "这个先这样吧！"

十有八九到最后产品交付的时候还是这样。延迟改善的结果在时间和技术的双重压力下通常就是不改善。所以接受这句话的同时就要做好"最后也是这样"的准备了。

最后想说的是程序员是产品的开发者，是思想和策划的实践者。如果产品开发中忽视了来自这个角色的"声音"，再好的策划和设计也会无法真正落地。无论你是管理者，还是自身就是一个程序员，都请了解程序员！