告诉我的经理，有一个计划很重要 [英] Telling my manager that having a plan is important
问题描述
问题：
我的经理目前认为，设计很重要，但对于所有的项目来说，这些项目并不重要。我认为，他认为重要的是设计，但不是必要的，泥浆编程的大球可以完成工作。
有什么方法讨论（话题，例子等）规划设计的重要性？我正在寻找在我的权力范围内做代码peon的事情做，说或改变，所以答复如雇用其他高级，弱电成员等对我来说并不是很有帮助。 >
或者，他是对的，我是应该重新思考我的发展方式的人吗？
一些背景：
本质上，我们的团队由三个强大的开发人员，一些软弱的开发人员组成，还有一些人，在我看来，甚至不应该在现场。
我们没有专门的建筑师，所以作为非官方团队领导者的三个最强大的开发人员有些期待着设计除了最简单的项目之外的所有项目，除非经理决定泥球足够好。他们还负责自己（有时候是多个）正在进行的项目，同时指导和帮助他人。这导致了这些个人可以接受的，但是从一周到一周的全部工作量。
我对这个团队描述背景的三点： p>
- 没有时间同步程序，提供培训课程，代码评论已经从地图上下载。换句话说，弱者必须自己学习。
- 当较弱的成员被给予一个项目并允许简单地开始编码而不用考虑时，开发需要更长的时间，花费更多的时间QA，而且这样一个维护头痛的时候，三年级的人都害怕甚至触摸它。
- 弱势的团队成员一般都有态度，但不是态度，反之亦然，但没有其中一个似乎有两个。
总结：
经理是一个聪明但固执的人谁会听理由，但你必须说服他彻底的为什么。
目前没有足够的时间注入任何培训方法，从日常职责发展，任何人都不会很快被雇用，以减轻一些负担。
与团队中可用的个人创建更好的代码的唯一现有方法是通过为他们设计他们的项目，指导他们执行的过程，因此我们有这个问题。
编辑
我想巩固到目前为止，我从答案中得到了什么其中一些是直观的，但不是日常的（imo）最想想的东西：
管理员如指标。但是，福勒认为（我同意）生产率和质量是不可估量的。此外，我没有办法把这些指标累积为peon。 （感谢Novelocrat& duffymo）。
总是会有人才的混合，你必须呈现学习环境我们在此支持在态度上，但我认为需要其他工具来创造这种环境。 （感谢duffymo）。
吸引弱者，减轻强力的工作量另外（作为？的结果）呈现学习环境，让较弱的开发商通过给予他们小的原子部分来设计（经过批准）来加强他们的设计技能。这样可以消除更强大的开发人员的责任，教导弱点，并且可能是经理人可以接受的解决方案，因为它不需要高薪员工的时间。 （感谢duffymo&汤姆·安德森）
2个词语：记事本建筑
你不能改变老板的思维方式，除非你成为老板，在大多数情况下。
你说没有时间的设计，并考虑分配的项目，深度设计会议和代码审查等...我同意。
您需要做的第一步是获得你的领导更平易近人作为领导者的最大的一部分是领导者，这意味着他们必须得到信任和尊重才能成功领导任何事情。
下一步是开始获得小的开发商在表演之前思考。大多数开发人员只需要潜入代码是非常普遍的，但是花费几分钟甚至可以在失败时取得成功。我会假设你会得到某事，无论是口头上还是写出什么工作要完成，假设，尝试以下。
在记事本中：
记下需要完成的任务（程序，功能，无论如何）。
编写需要做的事情为了在组件级别完成此任务。
- 将新字段添加到表
- 使用新字段更新现有对象
- 添加新的服务调用从grater获取奶酪
在他们指出他们认为需要做的事情之后，让他们走到其中一个线索，问他们的想法，然后领先，然后只需要一会儿，或者同意他们的笔记或建议不同处理事情的方法，并查询是否有任何可能丢失的问题。开发人员关于他们正在工作的域名的问题，而不是通过查看并为他们做的。
现在，您有一个半详细的项目任务列表以及一个基本的系统的设计。
接下来让你的潜在客人在早上休息一下时间去问问jr如何进行项目，并向他展示一些的设计。如果设计可以使用一些改进，再花5-10分钟来解释更好的方法，并提出实施方案，不要为他们做，引导他们取得成功。
所以，总而言之，如果你的潜在客户可以每天多花20分钟时间和你的小时。开发人员在潜水之前需要额外30分钟，您应该在噩梦维护和质量保证周期内节省吨数。
The question:
My manager currently believes that design is important, but not crucial for all but the most ambitious projects. It is my opinion that he thinks it is important to design, but not necessary and that big ball of mud programming can 'get the job done.'
What are some methods of discussing (topics, examples, etc) the importance of planning and design? I'm looking for things to do, say, or change that are within my power as 'code peon', so answers such as, hire another senior, fire weak members, etc. aren't very helpful to me.
Alternatively, is he right and I'm the one who should rethink my approach to development?
Some background:
Essentially, our team consists of three strong developers, a few weak developers, and some people who, in my opinion, shouldn't even be in the field.
We have no dedicated architect, so the three strongest developers who act as unofficial team leads are somewhat looked to in order to design all but the most trivial of projects, unless the manager decides that 'ball of mud' is good enough. They are also responsible for their own (some times multiple) ongoing projects while mentoring and helping others. This leads to an acceptable, but full work-load from week to week on these individuals.
My point of describing the background is three-fold for this team:
- There is little time to peer-program, give training sessions, and code reviews have fallen off the map. In other words, the weak must learn on their own.
- When the weaker members are given a project and allowed to simply start coding without thought, the development takes longer, spends way more time in QA, and is such a maintenance headache later, the senior three are scared to even touch it.
- The weak team members generally have the attitude but not the aptitude, or vice versa, but no one among them seems to have both.
To summarize:
The manager is an intelligent, though stubborn man who will listen to reason, but you must convince him thoroughly of the 'why'.
There is not enough time currently to inject any training methods that take away from daily duties of development and no one is likely to be hired anytime soon to alleviate some burden.
The only current method of creating better code with the individuals that are available on the team is by designing their projects for them and guiding them through the process of implementation, thus, we have this question.
Edit
I wanted to consolidate what I've taken from the answers so far; Some of these are intuitive, but not something most think about from day-to-day (imo):
Managers like metrics. True, but as M. Fowler believes (and I agree) productivity and quality is immeasurable. Besides, I don't have the means to accumulate the metrics as 'peon'. (thanks Novelocrat & duffymo).
There will always be a mix of talent, you must present a learning environment We are supportive in this in attitude, but I think other tools are needed to create this environment. (thanks duffymo).
Engage the weak, alleviate the workload of the strong In addition (as a result of?) to presenting the learning environment, engage the weaker developers in strengthening their design skills by giving them small, atomic parts of the project to design (with approval) themselves. This removes responsibility from the stronger devs, teaches the weaker, and may be an acceptable solution for the manager as it doesn't take time from his higher paid employees. (thanks duffymo & Tom Anderson)
2 words: Notepad Architecture
You can't change the bosses way of thinking, unless you become the boss, in most cases.
You say there is no "time" for design, and thinking about the projects that are assigned, for in depth design meetings and code reviews, etc... I would agree.
The first step you need to do is get your "leads" more approachable. The biggest part of being a lead is being a leader, which means they have to be trusted and respected in order to successfully lead anything.
The next step is to start getting the jr. developers thinking before acting. It is quite common for most developers to just want to dive into code, but taking a few extra even minutes can spell a success over a failure. I would assume you get "something" whether verbal or written about what work to get done, with that assumption, try the following.
In Notepad:
Write down the task that needs to be done (program, feature, whatever).
Write what things need to be done in order to accomplish this task at a component level.
- "Add new fields to table"
- "update existing objects with new field"
- "Add new service call for getting cheese from grater"
After they have finished pointing out what they think will need to be done, have them goto one of the leads and ask him what they think, the lead would then take just a few moments and either agree with their notes or suggest different ways of handling things and check to see if anything might be missing by asking the jr. developer questions about the domain they are working in, not by looking through and doing it for them.
Now you have a semi-detailed project task list as well as a basic design for the system.
Next have your leads take a coffee breaks worth of time to go in the morning and ask the jr how there project is going, and show him some of the design. If the design could use some improvement, take an additional 5-10 minutes to explain the better way and suggest an implementation of it, don't do it for them, guide them to be successful.
So, in conclusion if your leads can take an extra say 20 minutes a day, and your jr. developers take an extra 30 minutes before diving in, you should save tons on the after end in nightmare maintenance and QA cycles.
这篇关于告诉我的经理，有一个计划很重要的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
