非技术人员如何管理技术人员
“I attend a ton of product planning meetings” — a statement you may hear from many senior developers nowadays.
“我参加了大量的产品计划会议”-您可能会听到如今许多高级开发人员的发言。
The stereotype that Developers sit at a desk and code all day is farther from the truth than ever before. The position is no longer a siloed role, especially as one gains experience and takes on additional responsibilities.
开发人员整天坐在办公桌前进行编码的刻板印象比以往任何时候都更加远离事实。 该职位不再是一个孤立的角色，尤其是当一个人获得经验并承担其他职责时。
The role of a developer requires a ton of cross-team collaboration — even more so when working for a startup. Most of these interactions are with Designers or Product Managers.
开发人员的角色需要大量的跨团队协作-在初创公司工作时更是如此。 这些交互大多数与设计师或产品经理进行。
For a Developer to collaborate effectively, they should understand the characteristics that are valued by other cross-functional teams.
为了使开发人员有效地进行协作，他们应该了解其他跨职能团队重视的特征。
There are several articles from a Developer’s point of view on what qualities/skills a Designer or a PM should possess to collaborate effectively with them. However, as a former PM, I hope to share my insight from the other side.
从开发人员的角度来看，有几篇文章介绍了设计师或PM与其有效协作所应具备的素质/技能。 但是，作为前总理，我希望与对方分享我的见解。
Apart from the technical abilities, there are 4 non-technical aspects of a successful Developer that makes cross-functional collaboration both enjoyable and efficient.
除了技术能力，成功的开发人员还有4个非技术方面的要求，可以使跨功能的协作既愉快又高效。
1. They Adapt Their Development Approach to Match the Business Needs.
1.他们调整自己的开发方法以满足业务需求。
2: They Work on Interesting Problems and Not Interesting Technologies.
2：他们研究有趣的问题而不是有趣的技术。
3: They Can Identify Unarticulated Customer Needs.
3：他们可以确定明确的客户需求。
4: They Invest Time in Learning Why Before They Share How.
4：他们先花时间学习为什么要分享他们的方式。
＃1 他们调整自己的开发方法来满足业务需求。 (#1. They Adapt Their Development Approach to Match the Business Needs.)
In an ideal world, the same execution plan could be applied to every problem all the time. However, in reality, we all know that is never the case. The development approach we select depends on several dynamic factors such as project scope, delivery timeline, feature priority, competitive threats, market trends, etc.
在理想的世界中，可以将相同的执行计划始终应用于每个问题。 但是，实际上，我们都知道情况并非如此。 我们选择的开发方法取决于几个动态因素，例如项目范围，交付时间表，功能优先级，竞争威胁，市场趋势等。
The best collaborative Developers are flexible in their development approach. Instead of exploring reasons to push back or eliminate these factors, they adapt their execution plan to meet business needs with appropriate technical trade-offs.
最好的协作开发人员在他们的开发方法上很灵活。 他们没有探究推销或消除这些因素的原因，而是通过适当的技术折衷调整了执行计划来满足业务需求。
They understand a short-term sub-optimal solution that is adopted by customers early is better than a well-architected solution that is released late and receives no customer adoption. Improving a product in subsequent iterations is significantly easier than making a customer switch from a competitor product.
他们了解客户较早采用的短期次优解决方案要比延迟发布且没有客户采用的结构完善的解决方案好。 在后续迭代中改进产品要比让客户从竞争对手的产品中切换来要容易得多。
This adaptable quality is appreciated by cross-functional roles, as in the world of agile development, these fast-paced and unpredictable scenarios happen all the time.
跨职能角色赞赏这种适应性质量，因为在敏捷开发的世界中，这些快节奏且不可预测的情况一直在发生。
＃2：他们研究有趣的问题而不是有趣的技术。 (#2: They Work on Interesting Problems and Not Interesting Technologies.)
I have worked with so many engineering teams where a Developer has requested that I budget time in the next quarter so they can explore an “interesting” technology.
我曾与众多工程团队合作，开发人员要求我在下一季度预算时间，以便他们探索“有趣的”技术。
When asked why, their reasoning was often something along the lines that this technology can help improve our product or some key metrics, or that other companies are also shifting to this new tech stack.
当被问到为什么时，他们的推理通常是指这项技术可以帮助改善我们的产品或某些关键指标，或者其他公司也正在转向这种新技术。
Sometimes investing in an exploration step is the right move. But, in most cases, a technology-led approach is not an impactful pitch if a developer wants to get others on board with their idea as well.
有时，投资勘探步骤是正确的举动。 但是， 在大多数情况下，如果开发人员也希望其他人也加入他们的想法，那么以技术为主导的方法就不会产生什么影响。
Developers who have the best pitch always use a differentiated product feature or a remarkable improvement to existing customer experience as the primary driver — the new technology is only used as a release vehicle to offer that unique value.
拥有最佳音调的开发人员始终将差异化的产品功能或对现有客户体验的显着改善作为主要驱动力-新技术仅用作发布工具以提供独特的价值。
I love collaborating with such developers. They are always excited to build outstanding products that have a broad customer impact rather than upgrading the stack to the latest technology.
我喜欢与这样的开发人员合作。 他们总是很高兴能够开发出具有广泛客户影响力的出色产品，而不是将堆栈升级到最新技术。
＃3：他们可以确定明确的客户需求。 (#3: They Can Identify Unarticulated Customer Needs.)
A successful product has a ton of fans rather than a ton of features. To build fans, a team has to release unforeseen product value that delights existing customers.
成功的产品具有大量的粉丝，而不是大量的功能。 为了培养粉丝，团队必须发布无法预见的产品价值，以吸引现有客户。
In my experience, even when the PM is looking for such opportunities, the best Developers will also look at the telemetry or usage logs to come up with additional insights. With time they tend to build a holistic understanding of the product too, which allows them to identify unarticulated customer needs.
以我的经验，即使PM正在寻找这样的机会，最好的开发人员也会查看遥测或使用日志，以提供更多见解。 随着时间的流逝，他们也倾向于对产品建立全面的了解，从而使他们能够确定明确的客户需求。
A product builds a cult fan base by delivering such unexpected features over multiple releases. A team with members who are all interested in identifying such opportunities has a massive chance of developing a product with high adoption and phenomenal retention metrics.
产品通过在多个版本中提供此类意外功能而建立了狂热的粉丝群。 一个由对这些机会都有兴趣的成员组成的团队，很有可能开发出具有高采用率和惊人保留率的产品。
＃4：他们先花时间学习为什么，然后再分享方式。 (#4: They Invest Time in Learning Why Before They Share How.)
I have seen a lot of times engineers don’t challenge why and what from a PM. Their focus is only on building an execution plan for the project. When it comes to cross-team collaboration, the developers with such a mindset are not considered best partners.
我已经看到很多次工程师不质疑PM的原因和原因。 他们的重点仅在于为项目建立执行计划。 当涉及跨团队协作时，具有这种思维方式的开发人员不被视为最佳合作伙伴。
The most collaborative engineers feel comfortable learning the why and what of a project. They spend time raising appropriate clarifying questions and suggesting improvements to the potential solution. Only after they fully fathom the reasoning for the feature, they build a technical strategy.
协作最多的工程师会很轻松地学习项目的原因和内容。 他们花时间提出适当的澄清问题，并提出对潜在解决方案的改进建议。 只有充分了解了该功能的原理后，他们才能制定技术策略。
A PM greatly appreciates such developers because it ensures the project hypothesis is thoroughly validated before we start the execution stage. Moreover, it brings everyone on the same page from the start and hence makes the execution journey a lot easier.
项目经理非常感谢这类开发人员，因为它可以确保在开始执行阶段之前就对项目假设进行了充分验证。 而且，它从一开始就将所有人带到了同一页面上，因此使执行过程变得容易得多。
In the case of Developers, above non-technical qualities are not only beneficial for becoming better collaborators, but these soft skills also aid in accelerating one’s career trajectory.
对于开发人员而言，以上非技术素质不仅有利于成为更好的合作者，而且这些软技能还有助于加速其职业发展轨迹。
In my early years as a PM in Microsoft, I got to work with a team of four engineers where every developer had most of these characteristics. It is still one of the most rewarding times of my career — not only did we deliver a successful product, but I also got four friends for life.
在Microsoft担任PM的早年，我与一个由四名工程师组成的团队合作，每个开发人员都具有大多数这些特征。 这仍然是我职业生涯中最有意义的时期之一-我们不仅交付了成功的产品，而且我还得到了四个终身的朋友。
As they say, it takes a village to build a successful product, and to have a healthy operational one, a clear understanding of each other’s expectations is vital.
正如他们所说，一个村庄要构建成功的产品并拥有健康的运营产品，对彼此期望的清晰了解至关重要。
I have seen many experienced Engineers who possess these exceptional qualities also explore the possibility of transitioning to a Product Manager role. Many have not only successfully made this transition but have also excelled in their new PM role as well. If you are also interested in such a move, please read one of my earlier articles:
我已经看到许多经验丰富的工程师具有这些非凡的素质，他们还探索了转变为产品经理职位的可能性。 许多人不仅成功完成了这一过渡，而且在新的PM角色方面也表现出色。 如果您也对这种举动感兴趣，请阅读我之前的文章之一：
非技术人员如何管理技术人员
扫一扫
477
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
