You have multiple projects going on, and you need to pick up a new project... well, let's take a step back and look at this from the high level.
Projects A B C D unfinished. What are their statuses? Are they on time? If they aren't, how did they get behind? How they got behind, will it happen to your new project? Do you have the resources to finish these projects on time? Do you have the resources to finish these projects at all?
Project E to be started: Do you have the resources to finish it? Even start it? Do you know what the end result needs to be? Do you know the intermediate steps to get there?
Do you have help internally, both above and below you? What assistance can these people offer?
You need to answer these questions, or at least most of them. These are the questions that help project management. Time - resources - talent - know what you have and what you need!
Without more specifics, I can't really help you more.
It’s not specific to software projects, and it’s very light on methodology, but I’ve found it really useful when planning projects. At that middle stage when you’re getting lost, it’s useful to look back to this planning process to see where your problem is, and thus how to solve it.
I’d urge you to read the chapter (and chapter 10, which has practical suggestions on how to implement the approach), but if you want a slightly shorter and less well-written summary:
“Projects” are desired outcomes that require more than one step to achieve them.
The “natural” (i.e. best suited to our brains) way to plan projects is:
Define purpose and principles
What’s the project trying to achieve? (Purpose.) What standards and policies should we satisfy whilst trying to achieve the objective? (Principles.)
With client work, it’s usually up to the client to decide the purpose, and at least some of the principles. However, they may not have though about it themselves, so you may well need to listen to them carefully from the outset, read between the lines, and figure out what will help them. Thinking about the purpose of a project can stop you getting stuck on a particular task — you may realise the task isn’t even necessary to achieve the purpose.
You may well have some principles that you like to adhere to (e.g. your idea of “clean code”), but remember the client probably has theirs too (e.g. getting IT projects done quickly), and they’re the ones writing the cheques.
Envision the outcome
What would success look like?
This can involve high-level outcomes (e.g. the client’s staff enter 20% more orders per day thanks to your OrderTron.NET Enterprise Edition CX) and more specific definitions like a spec — which is where I imagine your static designs come in.
All of this lets you know what you’re aiming for, and thus helps you figure out how long it will be before you’re done.
Brainstorm
How can we achieve the outcome?
Once you’ve got a clear idea of what success would look like, your brain will, almost without your control, start generating ideas about how to get there. Allen suggests noting all these down, without judging whether they’re good ideas or not, to take advantage of your brain’s creativity.
Organize
Right, how can we actually achieve the outcome?
Now that you’ve got ideas about how to achieve the outcome, you organise them into a plan. Split the project up into components (e.g. database, validation, user interface), figure out priorities (e.g. the user interface has to support IE 6), and map out sequences (e.g. the data model will need to be fleshed out before we can start design the interface).
You’ll be doing this repeatedly throughout the project.
Identify next actions
What can I do?
Now that you’ve got an organised project plan, what’s the next physical action that can be done to move the project forward?
There will probably be lots, and they’ll probably be tiny, e.g. create a folder for the project in our source control repository, do a first draft of the data model, Google ASP.NET validation).
Once you’ve got some next actions, that’s enough planning for now. Do them. You’ve now got a plan to come back to when things need reorganising.
Although I’ve listed these in order, you’ll move through all the stages lots of times during a project. For example, nitty gritty implementation details (5) can force you to redefine the successful outcome of the project (2) given the principle of keeping costs limited (1), or brainstorm new implementation approaches (3), which leads to you reorganising who works on which modules (4).
Also, this process applies to really large projects (e.g. implement an order entry system for a client) and really small “projects” that are part of a large project (e.g. implement the validation layer for the order entry page of the order entry system). Whenever you’re lost in the middle of a project, check that for whatever bit you’re working on that you know what the purpose is, and what the outcome should look like.
If you’re vague on the outcome, figure it out in more detail. Refer to the spec. Ask colleagues. Google. Etc.
Take heart. None of this is easy. An approach like Allen’s is good to help stop you getting lost, but the skills you use at each stage of the approach can only be learned by years of hard work, mistakes and experience. If you’re having trouble figuring out whether to do the database first or not, you might just need more actual programming practice.
But the fact that you’re thinking and asking about how to do projects better means you’re already doing more than lots of people ever do. Good on you, and best of luck.
There are books and web-sites beyond one's ability to count to answer your question, in brief and in depth and for all manner of projects. I suggest you read the responses to your question here, but check Amazon and Google around. I think that Tom Gilb's book is still one of the best, certainly if you could only afford one book and bought this you wouldn't regret it.
From all the published sources and my many years of project management I distil only one piece of advice:
Stop starting new projects until you learn how to finish old projects.
You are the professional...and you are the only one that can give the answers. If you don't know what is more important, no book will help you and you are in the wrong job.
Having this said, I wish that there more like you asking for advise... to help you in the time management field where most people need help.
There are many methodologies but if my feelings about your need are right, all you need is two softwares and alot of discipline: MS project(or something similar) excel(or other spreadsheet)
Make a detailed plan - detailed enough to tell you at the end of each day if you fell short or exceeded your plan. But not to detailed - you need time to work and not just toy with dreams and plans for the future.
in the excel make a log: task ! plan hours ! actual hours in days where you accomplish less then 90% of your actual planing - are very hard days with a lot of over time - you want to go to sleep and fix everything tomorrow -don't! Spend an hour to log what went wrong... phone calls, meeting... everything.
You have to problems 1. You don't know to make good estimations. 2. you jump from one task to another loosing valuable setup time.
You will be late in the next project as well and that is unavoidable... but if you will understand where you loose time. You will make more realistic plans and become a better manager.
*If these thumb rules are not enough - the PMI.org has good website, good course, good book and good people with their PM certification- you can find such expert or become one.
But I really believe that when a professional looks at hard data he can make decisions: 1. I can't speak 4 hr with that client everyday without charging him for the time. 2. That task took me way too long - I need to concentrate, next time I'll do that on the weekend after everybody is gone... shut down the cellphone and finish the job in half time
etc...
I strongly advice you to find someone that will teach how to use project management correctly, mainly - how to move unfinished work to the future - it's crucial that you will have the real picture of your status and not just have a list of tasks (marked as finished/ not finished) - You will learn alot from analyzing well maintained plan (well not a plan anymore - but actual work!)
And just to make sure it doesn’t get lost in my tl;dr answer above, ‘The Design of Design’ by Fred Brooks is a great whole book on the project planning (and execution) process.
It compares IT projects with architecture/construction projects, which works because the author managed IBM’s OS 360 project and the construction of his own beach house.
It discusses design (i.e. creativity and inspiration) as much as project management, but it’s well worth a read for its in-depth discussion of complicated real-world projects that actually happened, and got finished. It’s simultaneously a great discussion of theory and a great discussion of practice.
发布评论
评论（5）
您有多个项目正在进行，并且您需要选择一个新项目……好吧，让我们退后一步，从高层角度来看待这个问题。
项目ABCD未完成。他们的现状如何？他们准时吗？如果不是，他们是怎么落后的？他们是如何落后的，你的新项目会发生这种情况吗？您有资源按时完成这些项目吗？您有资源来完成这些项目吗？
即将启动的项目 E：您有资源来完成它吗？还启动吗？你知道最终的结果需要是什么吗？您知道到达那里的中间步骤吗？
你在内部有上级和下级的帮助吗？这些人可以提供什么帮助？
您需要回答这些问题，或者至少回答其中的大部分问题。这些是有助于项目管理的问题。
时间-资源-人才-知道你拥有什么和你需要什么！
如果没有更多细节，我真的无法为您提供更多帮助。
You have multiple projects going on, and you need to pick up a new project... well, let's take a step back and look at this from the high level.
Projects A B C D unfinished. What are their statuses? Are they on time? If they aren't, how did they get behind? How they got behind, will it happen to your new project? Do you have the resources to finish these projects on time? Do you have the resources to finish these projects at all?
Project E to be started: Do you have the resources to finish it? Even start it? Do you know what the end result needs to be? Do you know the intermediate steps to get there?
Do you have help internally, both above and below you? What assistance can these people offer?
You need to answer these questions, or at least most of them. These are the questions that help project management.
Time - resources - talent - know what you have and what you need!
Without more specifics, I can't really help you more.
David Allen 的书“Getting Things Done” 概述了项目规划的绝佳方法。
它不是特定于软件项目的，而且它的方法论非常简单，但我发现它在规划项目时非常有用。在中间阶段，当你迷失方向时，回顾一下这个计划过程，看看你的问题出在哪里，以及如何解决它是很有用的。
我强烈建议您阅读本章（以及第 10 章，其中提供了有关如何实施该方法的实用建议），但如果您想要一个稍短且写得不太好的摘要：
“项目”是期望的结果，需要多个步骤才能实现。
规划项目的“自然”（即最适合我们的大脑）方式是：
定义目的和原则
该项目想要实现什么目标？ （目的。）在努力实现目标的同时，我们应该满足哪些标准和政策？ （原则。）
对于客户工作，通常由客户决定目的，以及至少一些原则。然而，他们自己可能没有考虑过这一点，所以你很可能需要从一开始就仔细倾听他们的意见，读懂字里行间的意思，找出对他们有帮助的方法。思考项目的目的可以防止您陷入特定任务 - 您可能会意识到该任务甚至不是实现该目的所必需的。
您很可能有一些您喜欢遵守的原则（例如您的“干净代码”想法），但请记住客户也可能有他们的原则（例如快速完成 IT 项目），并且他们是编写代码的人支票。
设想结果
成功是什么样的？
这可能涉及高水平的结果（例如，由于您的 OrderTron.NET 企业版 CX，客户的员工每天输入的订单多了 20%）和更具体的定义（如规范）——我想这就是您的静态设计的用武之地.
所有这些都可以让您知道自己的目标是什么，从而帮助您弄清楚需要多长时间才能完成。
头脑风暴
我们怎样才能实现这个结果？
一旦你清楚地知道成功是什么样子，你的大脑就会在几乎不受你控制的情况下开始产生关于如何实现成功的想法。艾伦建议记下所有这些，而不判断它们是否是好主意，以充分利用大脑的创造力。
组织
对了，我们怎样才能真正实现结果？
现在您已经有了关于如何实现结果的想法，您可以将它们组织成一个计划。将项目拆分为多个组件（例如数据库、验证、用户界面），确定优先级（例如用户界面必须支持 IE 6），并规划出顺序（例如在开始之前需要充实数据模型）设计界面）。
您将在整个项目中重复执行此操作。
确定下一步行动
我可以做什么？
现在您已经有了一个有组织的项目计划，下一步可以采取哪些实际行动来推动项目前进？
可能会有很多，而且可能很小，例如在我们的源代码控制存储库中为项目创建一个文件夹，制作数据模型的初稿，Google ASP.NET 验证）。
一旦您有了下一步行动，现在的计划就足够了。做他们。您现在已经有了一个计划，可以在事情需要重组时再回来考虑。
尽管我已按顺序列出了这些阶段，但在项目期间您将多次经历所有阶段。例如，在考虑到限制成本 (1) 的原则下，具体的实施细节 (5) 可能会迫使您重新定义项目的成功结果 (2)，或者集体讨论新的实施方法 (3)，这会导致您重新组织谁适用于哪些模块 (4)。
此外，此过程适用于非常大的项目（例如，为客户实现订单输入系统）和作为大型项目一部分的非常小的“项目”（例如，为订单输入系统的订单输入页面实现验证层） 。每当你在一个项目中迷失方向时，检查一下你正在做的任何事情，你是否知道目的是什么，以及结果应该是什么样子。
如果您对结果含糊不清，请更详细地弄清楚。请参阅规格。询问同事。谷歌。等等。
振作起来。这一切都不容易。像艾伦这样的方法可以很好地帮助您防止迷失方向，但是您在该方法的每个阶段使用的技能只能通过多年的努力、错误和经验来学习。如果您无法确定是否先处理数据库，您可能只需要更多实际的编程练习。
但事实上，你正在思考并询问如何更好地完成项目，这意味着你已经比很多人做得更多了。祝你好运。
Chapter 3 of David Allen’s book ‘Getting Things Done’ outlines a great approach to project planning.
It’s not specific to software projects, and it’s very light on methodology, but I’ve found it really useful when planning projects. At that middle stage when you’re getting lost, it’s useful to look back to this planning process to see where your problem is, and thus how to solve it.
I’d urge you to read the chapter (and chapter 10, which has practical suggestions on how to implement the approach), but if you want a slightly shorter and less well-written summary:
“Projects” are desired outcomes that require more than one step to achieve them.
The “natural” (i.e. best suited to our brains) way to plan projects is:
Define purpose and principles
What’s the project trying to achieve? (Purpose.) What standards and policies should we satisfy whilst trying to achieve the objective? (Principles.)
With client work, it’s usually up to the client to decide the purpose, and at least some of the principles. However, they may not have though about it themselves, so you may well need to listen to them carefully from the outset, read between the lines, and figure out what will help them. Thinking about the purpose of a project can stop you getting stuck on a particular task — you may realise the task isn’t even necessary to achieve the purpose.
You may well have some principles that you like to adhere to (e.g. your idea of “clean code”), but remember the client probably has theirs too (e.g. getting IT projects done quickly), and they’re the ones writing the cheques.
Envision the outcome
What would success look like?
This can involve high-level outcomes (e.g. the client’s staff enter 20% more orders per day thanks to your OrderTron.NET Enterprise Edition CX) and more specific definitions like a spec — which is where I imagine your static designs come in.
All of this lets you know what you’re aiming for, and thus helps you figure out how long it will be before you’re done.
Brainstorm
How can we achieve the outcome?
Once you’ve got a clear idea of what success would look like, your brain will, almost without your control, start generating ideas about how to get there. Allen suggests noting all these down, without judging whether they’re good ideas or not, to take advantage of your brain’s creativity.
Organize
Right, how can we actually achieve the outcome?
Now that you’ve got ideas about how to achieve the outcome, you organise them into a plan. Split the project up into components (e.g. database, validation, user interface), figure out priorities (e.g. the user interface has to support IE 6), and map out sequences (e.g. the data model will need to be fleshed out before we can start design the interface).
You’ll be doing this repeatedly throughout the project.
Identify next actions
What can I do?
Now that you’ve got an organised project plan, what’s the next physical action that can be done to move the project forward?
There will probably be lots, and they’ll probably be tiny, e.g. create a folder for the project in our source control repository, do a first draft of the data model, Google ASP.NET validation).
Once you’ve got some next actions, that’s enough planning for now. Do them. You’ve now got a plan to come back to when things need reorganising.
Although I’ve listed these in order, you’ll move through all the stages lots of times during a project. For example, nitty gritty implementation details (5) can force you to redefine the successful outcome of the project (2) given the principle of keeping costs limited (1), or brainstorm new implementation approaches (3), which leads to you reorganising who works on which modules (4).
Also, this process applies to really large projects (e.g. implement an order entry system for a client) and really small “projects” that are part of a large project (e.g. implement the validation layer for the order entry page of the order entry system). Whenever you’re lost in the middle of a project, check that for whatever bit you’re working on that you know what the purpose is, and what the outcome should look like.
If you’re vague on the outcome, figure it out in more detail. Refer to the spec. Ask colleagues. Google. Etc.
Take heart. None of this is easy. An approach like Allen’s is good to help stop you getting lost, but the skills you use at each stage of the approach can only be learned by years of hard work, mistakes and experience. If you’re having trouble figuring out whether to do the database first or not, you might just need more actual programming practice.
But the fact that you’re thinking and asking about how to do projects better means you’re already doing more than lots of people ever do. Good on you, and best of luck.
有无数的书籍和网站可以简单而深入地回答您的问题，并适用于各种项目。我建议您阅读此处对您的问题的答复，但请检查亚马逊和谷歌。我认为 汤姆·吉尔布的书仍然是最好的书之一，当然，如果你只能买一本书并买了这本书，你就不会后悔。
从所有已发布的资源和我多年的项目管理经验中，我只提炼出一条建议：
停止开始新项目，直到你学会如何完成旧项目。
There are books and web-sites beyond one's ability to count to answer your question, in brief and in depth and for all manner of projects. I suggest you read the responses to your question here, but check Amazon and Google around. I think that Tom Gilb's book is still one of the best, certainly if you could only afford one book and bought this you wouldn't regret it.
From all the published sources and my many years of project management I distil only one piece of advice:
Stop starting new projects until you learn how to finish old projects.
不，没有这样的书适合您*...
您是专业人士...并且您是唯一能够给出答案的人。如果你不知道什么更重要，那么任何书都无法帮助你，你就做错了工作。
话虽如此，我希望有更多像您这样的人寻求建议……在大多数人需要帮助的时间管理领域为您提供帮助。
有很多方法，但如果我对您的需求的感觉是正确的，那么您所需要的只是两个软件和大量的纪律：MS项目（或类似的东西）Excel（或其他电子表格）
制定详细的计划 - 足够详细，足以告诉您如果您未达到或超出计划，则每天结束时。但不要太详细——你需要时间去工作，而不仅仅是沉迷于梦想和未来的计划。
在Excel中创建一个日志：任务！计划时间！实际时间
在你完成实际计划不到 90% 的日子里——这是非常艰难的日子，有很多加班时间——你想睡觉并明天解决所有问题——但不要！花一个小时记录出了什么问题……电话、会议……一切。
你必须遇到问题
1.你不知道如何做出正确的估计。
2.您从一项任务跳到另一项任务，从而浪费了宝贵的准备时间。
您在下一个项目中也会迟到，这是不可避免的……但如果您了解自己在哪里浪费了时间。你将制定更现实的计划并成为更好的管理者。
*如果这些经验法则还不够 - PMI.org 有好的网站、好课程、好书和拥有 PM 认证的好人 - 您可以找到这样的专家或成为其中之一。
但我真的相信，当专业人士查看硬数据时，他可以做出决定：
1. 我不能每天和那个客户聊4个小时而不向他收取时间费用。
2. 这项任务花了我太长时间 - 我需要集中注意力，下次我会在周末所有人都离开后这样做...关闭手机并在一半时间内完成工作
等等...
祝你好运
阿萨夫
No there is not such book for you*...
You are the professional...and you are the only one that can give the answers. If you don't know what is more important, no book will help you and you are in the wrong job.
Having this said, I wish that there more like you asking for advise... to help you in the time management field where most people need help.
There are many methodologies but if my feelings about your need are right, all you need is two softwares and alot of discipline: MS project(or something similar) excel(or other spreadsheet)
Make a detailed plan - detailed enough to tell you at the end of each day if you fell short or exceeded your plan. But not to detailed - you need time to work and not just toy with dreams and plans for the future.
in the excel make a log: task ! plan hours ! actual hours
in days where you accomplish less then 90% of your actual planing - are very hard days with a lot of over time - you want to go to sleep and fix everything tomorrow -don't! Spend an hour to log what went wrong... phone calls, meeting... everything.
You have to problems
1. You don't know to make good estimations.
2. you jump from one task to another loosing valuable setup time.
You will be late in the next project as well and that is unavoidable... but if you will understand where you loose time. You will make more realistic plans and become a better manager.
*If these thumb rules are not enough - the PMI.org has good website, good course, good book and good people with their PM certification- you can find such expert or become one.
But I really believe that when a professional looks at hard data he can make decisions:
1. I can't speak 4 hr with that client everyday without charging him for the time.
2. That task took me way too long - I need to concentrate, next time I'll do that on the weekend after everybody is gone... shut down the cellphone and finish the job in half time
etc...
Good luck
Asaf
只是为了确保它不会在我上面的 tl;dr 答案中迷失，'弗雷德·布鲁克斯 (Fred Brooks) 的《设计的设计》 是一本关于项目规划（和执行）过程的精彩全书。
它将 IT 项目与架构/建造项目进行了比较，之所以有效，是因为作者管理了 IBM 的 OS 360 项目以及他自己的海滨别墅的建设。
它讨论了设计（即创造力和灵感）以及项目管理，但它非常值得一读，因为它对实际发生并完成的复杂的现实项目进行了深入讨论。它同时是对理论的精彩讨论和对实践的精彩讨论。
And just to make sure it doesn’t get lost in my tl;dr answer above, ‘The Design of Design’ by Fred Brooks is a great whole book on the project planning (and execution) process.
It compares IT projects with architecture/construction projects, which works because the author managed IBM’s OS 360 project and the construction of his own beach house.
It discusses design (i.e. creativity and inspiration) as much as project management, but it’s well worth a read for its in-depth discussion of complicated real-world projects that actually happened, and got finished. It’s simultaneously a great discussion of theory and a great discussion of practice.