今日推荐开源项目：《小猿做题 mathAI》
今日推荐英文原文：《The Problem of Estimating》
今日推荐开源项目：《小猿做题 mathAI》传送门：GitHub链接
推荐理由：以前做题不会也想不出还没有答案的时候，小猿搜题这样的搜索 app 兴许就能成为一线生机。而这个项目虽然暂时并不能帮你解决太复杂的问题，但是如果你写一堆加减乘除的算式给它的话，它能通过图像识别看懂之后给你个答案出来——当然，不是搜出来而是自己做出来的。尽管在现在的版本中它只能做做简单四则运算，但是这只是个基础而已，它还有很大的发展空间。
今日推荐英文原文：《The Problem of Estimating》作者：Robert Field
原文链接：https://medium.com/@snarfoid/the-problem-of-estimating-fcb9e4527950
推荐理由：估算越多就越容易出现不确定因素，这在哪里都是一样的
The Problem of Estimating
Estimating problems is commonplace, especially in the world of high tech, and is a valid exercise. What could be more natural than wanting to know how long something will take to finish? How long till my table is ready? When will my pizza arrive? When are you going to check in? All estimates. Every answer satisfies that basic need to know, even though every one is a guess. Maybe a very educated guess, based on data or heuristics, but still a guess.When the problem at hand is simple, a guess is fine. If my table took fifteen minutes instead of the alleged ten, I sucked it up. I didn’t starve. No one went to the hospital. It was inconsequential. An estimate then, for an inconsequential problem, is perfectly fine. There are no real repercussions. Now guess what? Not all problems are like this. If your Mom has stroke, it matters if you get her to hospital within the hour. That is not a problem you want to under estimate.
Let’s take the stakes up a notch to my high tech world. I got tasked with estimating the scope of a very large project for a large client. The client wanted to know, quite naturally, how much effort the project was. In other words, how much was it going to cost them? Once you start talking real money, estimates do have consequences. Everyone loves coming in under budget, but over budget is way, way different. Things get really uncomfortable in that case.
So I pondered over the problem set, got the basic holes ironed out. resolved all the dependency issues, and determined how to split up the work among our teams. Like I said, it was a large project, and so my estimates were large. With something so big, I felt a real need to build in some flexible time to deal with unforeseen issues and the inevitable bugs that would also arise. I’ve been through this before, and nothing really ever goes just the way you plan it. The bigger it is, the less likely it is to go well.
My boss nearly coughed up his liver when I showed him the numbers. He was adamant that there was no way we could deliver these numbers to the client. It was just unacceptable. So we bargained. This shouldn’t take so long, that we can skip testing, and the other thing can be done in parallel. If everything went super smoothly, maybe, just maybe, it would work. So the numbers came down, not where I wanted, and not where my boss wanted either. But the new numbers were deemed acceptable for presentation.
Work began. Code got checked in. Testing started. Hooray, the project was released. Except, not hooray. Horror. There were critical bugs right from the start. Every time we would solve one, two more came in. We were drowning, and the client, not surprisingly, became, shall we say, unhappy. They were quite rightly pissed, as they should have been.
My take away lessons from this unfortunate episode were two-fold. First, going in with my original numbers would have made the client unhappy from the start. Assuming they wanted to proceed from there, we would have in theory delivered a quality product, resulting in a happy customer. Instead, we chose a short-term trick to get the client to accept, then both made the client unhappy and made ourselves look bad, damaging our relationship. The lesson is that risk is very real, and the consequences of missing an estimate can be high.
Second, any project comes with ups and downs. You should know in advance what the real goals are. You have likely heard the of the project management triangle. Pick two: cheap, fast, good. In my example above, we clearly, though perhaps unconsciously, picked cheap and fast, unknowingly sacrificing quality. Knowing our client, our guiding principles should have been cheap and good, thus ignoring our time to completion, or, dare I say, going with my original numbers. But the client had an alleged deadline, things got negotiated around, and we wound up in a mess.
So as wonderful as estimates are, sometimes things take as long as they take. You can’t plan for everything single thing, but you can plan for how you want to deal with the problem and where your biggest risk is.
下载开源日报APP：https://openingsource.org/2579/
加入我们：https://openingsource.org/about/join/
关注我们：https://openingsource.org/about/love/
