今日推薦開源項目：《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/
