跨部门职责模糊导致执行低效

原话 · @Anonymous

I worked for a Japanese corporation, and a big part of their HR policy, was to move staff around the company. It was usually in 1- or 2-year stints (people would spend their entire careers at the company, so they could do this). Eventually, they would end up doing longer stints, where they would specialize.They would couple this with things like standardized coding and documentation styles, common tools, etc. Training on these standards was a regular thing for all staff.The idea was that they could rapidly move experienced staff around. It also helped staff to understand how their work was applied in an integrated system (having “blinders” on, is a fairly typical issue, with dedicated employees).It generally worked, but relied on their particular culture, and introduced a fairly significan

原话 · @Anonymous

> and most managers fail to punish at least some of these slow learners of theirsFalse, they punish by not crediting that work as work.Glue work, keeping things tidy, dealing with that annoyance that everyone else has been able to get away with suffering through (and ignoring), all of this will be worth approximately 0 at performance review time because your time is a zerosum game that is traded off with highly visible, political, and otherwise rewardable work.It's been my experience that in larger companies you generally have to play in the framework.(I'd roughly draw the line at 1000+ employees), at quite small companies (or as a self employed &#x2F; entrepreneur, roughly <200 employees) you should follow the path of highest EROI on your efforts regardless of who's job it is. In the gap

原话 · @Anonymous

I disagree with the centralization thought. I'm working on a project to create a central AI platform for a very large corporation. As you can imagine, such a large company already has several different platforms made by different branches within it. Each branch has something they are relatively happy with. But corporate sees this redundancy as waste, so they want to consolidate it into one.The problem with one is the same with any other single source: you are stuck with whatever they offer on whatever timelines they provide. You are sharing this with a hundred thousand other people, so it's not tailored to your use case, but either made as generic as possible, or full of irrelevant features. Both of these cases make it worse for you.I have often made in house libraries either based on or c