今日推荐开源项目：《What the fafa? wtfjs》
今日推荐英文原文：《How to Ensure Your Software Projects Actually Finish》
今日推荐开源项目：《What the fafa? wtfjs》传送门：GitHub链接
推荐理由：众所周知，编程语言有很多特性，而如果把简单的特性组合组合组合……然后写出一个这辈子都写不出的语句，它就会变得极其不可预测，而这正是考验你对这门语言了解程度的时候。这个项目就是一些千奇百怪让你会大喊 wtf 的 JS 语句合集，仅供学习练手用，请勿在真正的工作中使用这些千奇百怪的玩意儿——那会毫无作为而且完全浪费时间。
今日推荐英文原文：《How to Ensure Your Software Projects Actually Finish》作者：SeattleDataGuy
原文链接：https://medium.com/better-programming/how-to-ensure-your-software-projects-actually-finish-5e0dd7ea46fc
推荐理由：脚踏实地而快速的行动能够切实的保证项目不断前进
How to Ensure Your Software Projects Actually Finish
And avoid them becoming zombified
It’s Monday morning.You struggle to get out of bed.
Your energy is drained.
It’s time to head to work and tackle that death march of a project again.
Somehow this project has been passed around to several teams and yet… it never seems to actually get finished.
Instead, like an undead zombie, it continues to haunt the living. Every implementation team handed the unfinished monstrosity struggles to grasp the scope and complexity.
Management has already poured millions of dollars into getting the technology implemented but it just doesn’t seem to be going anywhere.
Instead of analyzing the root cause of the problem, they simply pour more money and time into the overall project.
This happens at almost every large company at all times. Companies spend millions of dollars to implement technology and sometimes it never gets delivered. Just ask Hertz who is currently suing Accenture for 32 million dollars over a failed project!
So how do you keep your next project from becoming a zombie?
In order to avoid zombifying projects, it is important to keep the momentum moving forward. This means quickly removing roadblocks when they come up, creating manageable milestones, and constantly communicating to ensure everyone is aware of the project’s status. In turn, this keeps projects moving forward and ensures all the stakeholders are on the same page.
Clear Roadblocks Right Away
Roadblocks happen every day in tech projects.Maybe someone doesn’t have access to a data set, teams A and B don’t agree on the design, or perhaps you are awaiting approval for purchasing software from a director who has just gone on vacation.
Roadblocks can quietly drown projects if not dealt with as soon as possible.
In large companies, most technical teams are juggling multiple projects at once. This allows roadblocks to be used as an excuse as to why teams aren’t getting work done on your project; the roadblock relieves the pressure off the adjacent teams. If you are the technical project manager (TPM) or even the tech lead on a project, you can’t allow roadblocks to be an excuse and lose momentum.
Once momentum dies off, it is hard to start up again.
Teams will have to remember what they were doing for your project, they will need to review their code/requirements and they will likely make mistakes because the work is not as fresh in their minds. That is why roadblocks can be deadly to a project. Ignoring them and assuming they will take care of themselves is one way to ensure your project never finishes.
Instead, as soon as a roadblock comes into your team's path, it is important to act towards removing them. Assign a team to be responsible for the roadblock and make sure to follow up with the team regularly so that they know the work is important.
Create Milestones
Being held accountable doesn’t always feel great, but it is necessary.
We all avoid it, and some of us convince leadership we don’t need it.
And when you’re a TPM, it is tempting to think you don’t need to hold people accountable, you don’t want to be the bad guy/girl after all. Of course, then you have that one engineer on the team who keeps delaying finishing a module because of this or that and you realize you have to put clear milestones.
Milestones keep us honest and help us know what we are capable of. Milestones attached to dates create pressure, which forces prioritization. There is a delicate balance of course because some managers will decide everything is a priority and run their team ragged. But great managers will take their goals and prioritize them and then communicate upwards what will actually be done in the next few months.
It provides more information to everyone, it provides real expectations of what can actually be done. In addition, it forces only the work that needs to be done to get done. There are a lot of projects that might not be necessary and can be cut-off.
Yes, management will always push for things to get done faster, but there is really a limit to the speed you can work. Setting milestones doesn’t just keep the technical teams accountable, it forces management to reassess their own needs.
At the end of the day, good PMs will start to get an understanding of the working speeds of teams and individuals which in turn allows them to better assess future work.
Milestones might be stressful, but they provide a clear understanding of what everyone is capable of.
Communication Is Key
This is a cliche concept, right?There are probably thousands of articles talking about the value of communication in every technical field.
So why do people keep saying it?
Because when communication is done well, it helps everyone understand what is going on.
Communication keeps everyone in the loop.
It helps the TPM know where there are roadblocks as well as what is actually done. Most TPMs are just looking at things from a higher level. That means they are trusting the engineers of the various teams to communicate statuses honestly.
Without communication, it can be difficult to know what steps can go forward and what is being held back.
Clarify Your End Point
If you don’t know where you are going and what you want out of your finished project, then how will you know when you are there?Technical projects, in particular, have a nasty habit of never-ending because sometimes no end-point is undefined. Instead, new stakeholders will appear out of no-where demanding new features, and pressuring you to meet their use-cases.
Perhaps the current stakeholder just keeps changing what they want.
This is known as scope-creep.
At first, it starts off small and doesn’t seem like a big deal.
“Hey, could we just add this extra column here or this extra button there?”
Sure, these might be small requests, but it doesn’t take long for everyone to think that they can just make new requests whenever they please.
Hitting a moving target is hard and adding what might seem like small changes to code can be massive changes in the codebase.
This isn’t to say projects and requirements can’t change. There is a balance between improving the end product because it makes sense and just adding features because someone thinks it’s a good idea.
So making sure there is an agreed-upon target ensures that the first version of the product is important and necessary.
Once you have finished the initial version, then you will figure out which features are actually needed. Spending too much time on the backend trying to predict how end-users will use the product and trying to meet every use case will only increase the likelihood of failure.
Conclusion
Keeping projects from becoming zombified isn’t always easy.It requires an engineer or TPM to take the lead and make sure everyone is working together towards a common goal. In addition, they ensure that roadblocks are quickly mitigated to keep the momentum going to avoid teams getting stale or getting caught up in another project.
The truth is keeping projects moving forward is easy, until it’s not. This is where great TPMs come into play. Like a maestro in front of an orchestra, they control the bigger picture.
下载开源日报APP：https://openingsource.org/2579/
加入我们：https://openingsource.org/about/join/
关注我们：https://openingsource.org/about/love/
