今日推荐开源项目：《爬虫教学 Python-crawler-tutorial-starts-from-zero》
今日推荐英文原文：《“Why” is Why Software Implementations Take So Long》
今日推荐开源项目：《爬虫教学 Python-crawler-tutorial-starts-from-zero》传送门：GitHub链接
推荐理由：说到 Python 相信大家都听说过 Python 爬虫这玩意了。这个项目就是一个 Python 的爬虫入门教学，从爬虫的预备知识——爬虫相关和网络相关到如何自己实现一个爬虫，对于有一些 Python 基础的朋友来说作为入门教学来说已经足够了。
今日推荐英文原文：《“Why” is Why Software Implementations Take So Long》作者：Thejus Chakravarthy
原文链接：https://medium.com/@thejus.c/why-is-why-software-implementations-take-so-long-ready-dcab6a503325
推荐理由：先想好为什么而不是做什么和怎么做，这能帮你节省不少走弯路的时间
“Why” is Why Software Implementations Take So Long
Every process starts with a why as in ‘why are we doing this?’Then, you get to what as in ‘what do we do?’
Finally, you get to how as in ‘how do we do it?’
At work, most people encounter a process in reverse, from how to why.
For example: my first job was working for a bookstore with a membership program. They taught me how to suggest joining our membership program. What I was doing was suggesting a customer become a repeat customer. Why I was doing it was because repeat customers tend to spend more, over time, than single customers.
I was only trained on how. It was up to me to figure out the what or the why.
Simple, right? Let’s get a little more complicated.
I was asked to automate web sales in an ERP. Apparently, every order from the website had to be manually altered before it went to the warehouse. Before I started coding or configuring anything, I interviewed the staff. When I asked how they altered the orders, I got step by step directions: first that button, then that field and so on. When I asked what they were doing, they said that certain items were only in one of the two warehouses and there was no way to configure the system to do this automatically. So, when an order came in, a person had to look at all the items and figure out if the entire order could be completed in one warehouse or if they had to coordinate multiple shipments.
When I asked why, I got blank stares or shrugs. This was a decision made outside their control and outside their concern. It just was the way things were.
Photo by Nick Tiemeyer on Unsplash
I think it’s important to point out that this isn’t a problem, as far as the stability of the business goes. Several business have functioned for decades without ever explaining why, even to themselves. “We’ve always done it this way” or “That’s the way I was taught to do it” is almost expected in certain industries.
But this is a problem when trying to implement a software platform.
Software platforms automate or streamline a process at the what level. A faster invoicing, a simpler tax report, a centralized resource planner, that sort of thing. The how in these platforms gets defined by the UI/UX design. If you’re super duper lucky, the interface is intuitive and easy to use. What’s more likely is you are going to be working against the interface, not with it.
A software implementer has to find out the shortest path between system’s how and your business’ how. Over time, the best implementers can connect the dots in days, if not hours. They can show you how to enter your sales orders, how to pay your bills, how to configure the email responses, and so on.
To do this, they have to figure out what you want to do. This part is usually called ‘gathering requirements’ or something similar. Then they can match your what to their platform’s what.
For example, your requirements say that you issue an invoice for every sale. They show you how to issue an invoice and move on. But later, you ask how to issue two invoices for the same sale, one for the deposit and one for the final payment. Well, you didn’t specify that in the requirements and that’ll require additional configuration and different documentation and training and so on. So the process goes back to the requirement gathering stage or the requirements get added to a change order and the process continues.
This breakdown occurs because neither side of the implementation got down into the weeds of why a process exists in the first place. If we knew why, several whats and hows could be put into place. But having to learn all of those hows is time consuming for both the implementer and the implemented.
The solution is simple but not easy.
Spend the time to find the why and what for every part of the business before even considering a new platform. Then, when trying to work with the implementer, focus on the why and the what rather than the how.
This process looks at lot like writing documentation or SOPs or playbooks. Whatever your business wants to call it, it boils down to a clear path from the why all the way to the how of everything you do.
In the end, it doesn’t matter how you accomplish a task.
The thing that matters is why.
下载开源日报APP：https://openingsource.org/2579/
加入我们：https://openingsource.org/about/join/
关注我们：https://openingsource.org/about/love/
