http://www.phparch.com \ November 2018 \ 15How to Knock Down Any Project in Ten Stepswill not be delivered on time, or on
budget.
The task of an experienced project
manager is to take into account all risks:
holidays, illness, delays in implemen-
tation, dependence on other projects
or teams. As a result, the estimates
obtained from developers can be multi-
plied by a certain coefficient, which can
be estimated with previous experience
with a given team. In addition to the
assumptions at the planning stage, esti-
mates may also change. As soon as new
information becomes available, such as
precise requirements or an unexpected
obstacle, you should revise your origi-
nal estimates.
Estimates are important in that
they serve as a basis for long-term
project planning and priority setting.
They cannot be treated as a deadline.
Developers, on the other hand, cannot
treat this as an opportunity to upstage
coworkers by estimating they will
complete work in a shorter period. It’s
not an auction. Keep in mind you are
still part of a team. Remember that
fixed estimates will be used in parallel
by sales or marketing departments and
delays can mean the loss of potential
customers.
Estimates are like models; they don’t
have to be perfect, it’s enough that they
are useful. A good estimation gives
you the chance to identify risks at an
early stage, which in turn gives you the
chance to minimize them. A good esti-
mation builds trust between the team
and the leader. Estimates are more
accurate the smaller the elements of
the system they concern. Smaller tasks
mean shorter reviews, easier to find
errors, and easier testing due to smaller
logical changes.
One way to make better estimates
is through better research. Before you
try to guess how much time it will take,
check it out in the code. See how some-
thing that needs to be developed is
done. Prepare a proof of concept (POC)
to check your library or API capabilities.
Talk to other teams that have done simi-
lar things.
- Lack of Leadership and
Responsibility
You manage things, you lead people.
We went overboard on manage-
ment and forgot about leadership. It
might help if we ran the MBAs out
of Washington.–Read Admiral Grace HopperA leader is a person who should
indicate the direction of product devel-
opment from the technical side based
on the requirements of the business
side. Good software won’t do it by
itself; you need the right people, and
people need a leader, even if they don’t
hold an official position. A leader is a
person from whom the team can learn
good practices by example. This creates
good habits and makes it easier for a
new employee to adopt the prevailing
work culture. This does not mean that
a leader is an infallible person—they
should certainly be open to new ideas
to not only share knowledge but also to
learn from others.
If there is no leader, everyone writes
their own code with no common guide-
lines or standards. In the worst case,
the code will be created as said by the
person who can shout louder (but isn’t
necessarily really smarter).
Example: a duo of architects could
not agree on the solution to use in the
project. It was built on a framework
authored by one of the architects. The
development of the application was not
as dynamic as expected, because the
chosen tool slowed it down. The archi-
tects left their work, the framework was
abandoned, but it is still in use. Why did
this happen? The authority of the posi-
tion turned out to be more important
than the opposition of the development
team. Why is it still in use? There is no
leader who would lead the team out
of this swamp and open it up to other
possibilities.Lack of a leadership is associated with
the lack of a clear division of responsi-
bilities. If we have a product developed
by several teams, no one feels responsi-
ble for its quality, and the product will
suffer as a result. Therefore, it is neces-
sary to determine who owns the project,
who maintains it, who is responsible for
proper operation, and finally who will
be responsible for the delivery of the
whole project.- Lack of Personal
Development
Two managers are talking about
training their employees. The first
asks, “Yeah, but what if we train
them, and they just leave?” The
second responds, “What if we don’t
train them, and they stay?”Many developers are people for whom
their work is a passion. That is why it is
very important to support them in their
development. Sending an employee to
training courses or conferences where
they will gain knowledge and develop
further has a certain cost. But this is
much less than if we wanted to hire a
new specialist in a given field. We can
devote part of the day/week to the
development of open source solutions,
so programmers better understand the
solutions they use on a daily basis.
There is a saying with which I
strongly agree: it is better to invest in an
employee and risk them leaving than
not to invest in them and risk them
staying. Many companies are defend-
ing themselves against engaging in the
development of employees, which will
have a negative impact on both parties
in the future. On the other hand, an
employee who is appreciated and grows
thanks to the company is more involved
and perhaps more connected with such
an employer.