程序员通常都有这种缺点：遇到自己不会的技术后，碍于面子，打心眼里不愿意求助别人，更不想把这种状态让领导知道，因为自认为这是一种低能的表现，导致最后被动的被别人发现。提早的主动暴露问题，确实能规避很多问题，让项目朝良性发展方向，但是这是有前提的，除非你的老板是个开明的人，否则你主动暴露问题，不开明的老板就认为你能力欠缺，最终的绩效评估受伤的还是你自己啊……

在工作中经常会遇到这样的人，尤其是新人。按照自己的思路做了好久，也没把事情搞定。研发里的敏捷开发，每日展会，快速反馈，快速交付和这个有异曲同工之妙。

我的做法是让程序员做之前先自述流程和思路，然后分解任务尽可能细，我可以估摸着后面可能会出问题的点，他不说我可以提前问，但有人就是细不了，那我会要求他每天提交代码，这样我的每天的事会多。还有一种是在任务分解和预估时间有的人总是过于乐观，以致我都不太相信，但又想看看这次是不是真有惊喜，有点矛盾😂我想问问老师我的做法可以有啥调整改进，或者有别的建议，毕竟现状我也有些无奈，自我感觉也并不轻松～

突然想起之前做过一个项目，经理把模块功能都分清楚了，把有联系功能的人分租2-5人一组。每个组都有一个或两个大牛，因为项目比较紧，项目经理说的最多的句话就是及时沟通，及时反馈，及时解决。在时间维度就有很好的把握，从项目立项之初，也是按老师递推演进的方式，计划SIT,UAT,灰度发布等时间结点按照倒推的方式进行，也给项目重要结点预留时间，最后结果是大家基本很少加班，验收没什么问题，还给我们多放几天假等等。那个时候我就觉得在这个项目经理下做事最有效率，事情安排妥当，把可能会遇到事情，做一部分预知，对于无法预知的也能让人尽早提出来，及时解决

之前有个习惯喜欢给接口参数搞个什么默认值，这样可以支撑更多的不同情况，但是忘记思考这个参数到底是不是一个重要的参数，如果是就要尽早暴露出去

做需求流程没搞清就动手做，写到出问题的地方卡住了。一直卡在谁也不告诉，知道被问起进展才知道厌恶了进度。

这篇文章真好。其实这是个心态问题，怕失败，怕别人批评。遇事积极求助是好事，不是懦弱和无能的表现，这也是一个让人成长的过程。自己搞的话，优点是自己记忆深，缺点是慢；向别人求助，与之相反。但工作不是上学，不能影响项目进度，项，团队是相互支撑的，你工作进度延迟会影响其他人的进度。搞不定及时求助是开放，有团队精神的表现，在团队中不能只考虑自己，一定要从大局考虑，这样，也助于自己提升自己的格局。我在这个问题上有比较深的教训，这篇文章很赞。

我的管理方法是：一个问题解决时间超一个小时，还没思路的话，一定要去寻找帮助，聊一聊，团队成员必须遵守这个纪律

尤其是能力与位置不匹配的时候，心里障碍愈发顽固

确实，最大的障碍是心里障碍。

Fail Fast，提前暴露问题，我写代码为了保证不崩溃，经常会兼容各种奇葩问题，或者给个默认值，听完这一讲如梦方醒啊！

我在带团队（研究生团队）做项目的时候经常遇到这种问题，大家总是要等到每周例会的时候才说遇到了什么什么问题，老师也反复强调了几次遇到问题要及时说，但是听的人不多，不过我已经养成了一旦发现自己暂时解决不了的问题就及时找老师讨论。但团队还是要做工作的，我想到的解决方法是用Scrum的每日站会，这样能及时了解大家的状态。

最近我的一个case总是失败，偶尔分到一次地址，其他的很多次都分不到，我看隔壁项目的同样的case已经合进了master，以为他们能跑过，一定是我这边有什么问题，折腾了很久，最后去问隔壁组他们也拿不到，如果早点暴露问题和沟通就好了，可能还是太畏惧沟通，畏惧和别人交流，尤其是求助型的

刚工作时自己确实有这种一条路走到黑，挨于面子不好意思问，所以工作效率确实低效。后面慢慢接触到不同的人，不同的做事方式，慢慢懂得求助他人的道理。这篇文章其实不仅仅适用于程序员，在生活中也适用。

遇到问题不及时提出，会不会跟文化有关呢？因为领导不希望看到有问题，无论怎样都会受到指责

这种方式就是代码入口先写卫条件的工作化