Factors Affecting HTML Layout (Part 2: PM Work and Workflow)
To be continued ...
This article is a continuation of Part 1: The
work of an HTML encoder .
PM work
1. An unambiguous interpretation of the requirements, wishes
and wishes of the client.
Worst case: The
client’s wishes are transmitted by the PM to the encoder as it is (vague,
inaudible).
The requirement or task is formulated, for example, as follows: “Make it
greener”, “increase the font”, “move this block to the left”,
“place this page in general style. "
Good practice:
PM, as far as possible,
finds out the requirements and wishes of the client and passes the specified
requirements to the encoder. A requirement or task is formulated, for example,
as follows: "Use this # 0BB822 green color." “Increase the font
to 18 pixels,” “slide the block 3 pixels to the left.”
Impact:
The more ambiguous and vague
requirement, the more time you need to spend on its
implementation. The lack of clear criteria increases the difference
in the vision of the end result of the customer and the manufacturer (remember the
picture with the swings and different visions of the result by different participants in the
project)
Do not be fooled by the imaginary independence given by the client in solving
any issues, because independence logically implies the
absence of strict acceptance (critical assessment) by the
client as such. In practice, the client always asks to change
or change some things again. Variability should be
minimized.
Actions:
1. PM: To clarify all the ambiguities, to formulate
clear acceptance criteria. Take care of the little things.
Use the technique "Do I understand you correctly?" and others
2. HTML encoder: Inform PM about all issues and emerging
ambiguities
2. Understanding what is happening and the composite
layout process.
Worst case:
PM does not understand the essence of the
layout process , selects the wrong sequence of encoder work
in the project, cuts the time, reduces the amount of work.
PM does not see or understand the effect of design on functionality (when
design makes you change the way functionality works).
Good practice:
PM clearly understands
where in his project and at what stage he needs to work
with HTML. Understands and takes into account possible risks, takes measures
to prevent them.
PM notices places in which design affects functionality. If this
place is critical, discuss changes with the project team; if
no - discusses “redrawing” with the client, taking into account existing
capabilities.
Impact:
Failure to understand what the result consists of and how to achieve this result
leads to the existence of activities not taken into account in the assessment. This, as a result,
leads to an overrun of design time.
The source material for coding is a static picture showing a
special case of the site. The result is a dynamic site. Accordingly, the
reception does not take place according to the ideal conditions displayed in the picture,
but according to the current (current) situation.
Example: At the input there is a PSD (or several PSDs)
for its own CMS. At the first assessment, it seems that adaptation
design can consist only of a task "cutting and stretching on CMS".
However, CMS is not just the main page. This and the page of
search results, the page of the archive of news and articles, etc. Unaccounted pages
have their own characteristics and elements that are not displayed on the PSD and need
at least a minimal ghost to the overall style. So, we need a
new task - adapting the design of existing blocks to a new
design. This task is not possible to do immediately. It is stretched,
because, including new functionality, the client has
new questions and wishes for the design of new pages (the client, when buying a
CMS, may suddenly want to include functionality that is
in CMS, but was not intended at first). A situation of emergency
and overspending of project time is created. Because time was estimated for
visible pages at the beginning of the project (and this, say, one main
page), but for obligations we must adapt the CMS for the
client, and his new requirements are invested in this obligation.
Actions:
1. Workflow: PM, providing the HTML design to the
encoder for review, receives an expert opinion on possible problem
areas, places where the design affects the functionality, questions that
should be clarified by the client.
2. Workflow: Conduct “open door days”
when colleagues explain to each other the specifics and characteristics of their
work, discuss the difficulties and measures to address them.
3. Workflow Inspect the solution to problems
or the problems themselves in the local Wiki (or as documents, descriptions,
FAQs), thus creating a knowledge base.
4. PM: Notify the HTML encoder of upcoming work.
Discuss possible “bottlenecks”, find out the likelihood of
some unplanned activity, discuss risks and measures
to reduce their consequences.
5. HTML encoder: Assess your activity on the project,
indicating all the activities to complete the task. Exhibit
the percentage of completion of Taxco in the existing design trekingovyh
systems. Notify about the risk, consult in any
questions.
3. Understanding the conditions and limitations of the platform or
project used
Worst case:
PM agrees with the requirements of the
client by relying on ease of implementation or the existence of
such functionality in the system.
RM owns only basic knowledge of the system.
Good practice:
Ideal when PM
knows the system in which he works well (has versatile
experience working with the system) and relies on
his experience in discussions with the client .
A more realistic option is when PM contacts a
project consultant (or an experienced developer) to evaluate the labor costs of
creating (changing) the functionality or the work under discussion.
Impact:
Knowledge of system limitations
even at the stage of setting the client’s task
, it will allow assessing the feasibility and labor costs of implementation, avoiding situations when it is necessary to
meet obligations, and solving a problem requires large
unplanned expenses of time and resources, unstable solutions
(“crutches”), etc.
Actions:
1. Workflow: Use a consultant in the project
with the “Consulting” task (besides this task he may
not participate in the project ).
2. PM: Before starting the project, study the system, consult
with colleagues (or a consultant) and study the previous experience of
their colleagues.
3. Workflow: Outline problem solving
or the problems themselves in the Wiki (documents, descriptions, FAQs).
4. Workflow: Carrying out general activities
to increase the level of competence in the systems used (knowledge of the
system and its limitations is also necessary for the encoder. See clause 7.
HTML encoder works ).
4. Objectivity.
Worst case:
PM cannot
prioritize the project in critical situations, treats the current
situation in the project far from the true state of things. He chooses
quick, and often adventurous, decisions.
Good practice:
PM has and offers a
sequence of work for an emergency version of the project flow,
checks and rearranges works according to the situation, tries to use
stable solutions, sees the whole project, consults
the project team before making a decision (even if it is known
that the opinion of the project team will differ )
Impact:
No comments
5. Control of the project and individual parts
at different stages.
Worst case:
PM checks the project at the end.
Good practice:
PM checks the results during
the project at each stage (milestones or at the end of the
task, etc.), carries out operational control.
Impact:
By not controlling the project at each
stage, PM increases the likelihood of cost overruns
and failure to meet deadlines. The situation is aggravated by the fact that, in the case
of control at the end,
according to PM’s vision, only the HTML encoder is responsible for the current situation in the project (if the task is the
last stretch in the project). As well as the fact that you still need to
again attract the resource for development, testing and, possibly,
reshuffle.
Example: There is a project in which there is no design
at its beginning. Development took place without a prototype and without design,
only according to the functional specification. The client sent the
design or PSD, and after that the HTML encoder enters the project. Situation:
in the design, a part of the functionality is drawn that is different from the
one that was made. Moreover, the implementation of the difference can pull another
20% -60% of the time already spent on development. As a result
- a simple HTML encoder and a deadline for delivery.
Actions:
1.РМ: To carry out control at all stages (and
in intervals) of the project.
6. Effective communications.
Worst case:
PM discusses project-
specific issues with each project participant separately. Project participants
communicate and solve operational issues, too, "each with each."
Discussing a project in IM takes a lot (or even more) of
time than completing a task. There is a need to discuss
working moments with several people at the same time (besides this
, the same thing).
Good practice:
All project participants are aware of
changes and discussions of common details for the project.
Impact:
Communication “each with each” always
leads to the fact that some details on the project that are important
for all its participants are missed (details, changes, sequence
perform tasks, etc.).
Actions:
1. Workflow: Inspect the results of
communication, notify the results of all project participants. Whenever possible,
discuss general details with a maximum of project participants.
2. Workflow
: Set strict dates and times for project meetings, subject to the mandatory
presence of the entire team. Summing up (cut).
The working process
1. The presence of one reporting body, one chain, one
task director .
Worst case: The
need to report to several people, receive tasks from several places.
Good practice: The
ability to respond to one
specific person (most often - the project’s PM). PM is responsible and takes all key decisions,
sets goals, etc.
Impact:
When you need to report to
several people, it looks like this: tell the
first, discuss, answer questions. Tell a second, discuss,
answer questions. Tell the first that you decided with the second,
discuss, answer questions. Tell the second one the comments
and what they decided with the first (God forbid that the second one has no comments
or suggestions). Thus, the solution to the problem does not begin
before its discussion. Despite the apparent illogicality of such actions,
they do occur. Particularly dramatic is that they happen just
at the most inopportune moment - when the project is running out of
time (because besides PM, new
people are involved in project control - higher managers. And each of them needs
to enter course of business and make new decisions).
Putting the first Parkinson's law for this situation: the more
people deal with the same problem, the more chaos.
Actions:
1. Workflow: Take decisions in a chain.
Make as much effort as possible so as not to tear off the final
executor from work on the task. Discussions are conducted by the group.
2. Availability and compliance with standards and requirements.
Worst case:
Lack of standards or
non-compliance.
Good practice:
Availability and compliance with standards.
Impact:
Non-observance and lack of standards
leads to the repetition of the same errors from project to project
(inconsistencies, inconsistencies, time overruns, etc.). The presence of
standards allows not only to avoid mistakes, but also to improve the
quality of the final product. The use of standards should be
brought to such a level that it becomes an automatic process
and does not make you think or remember “what’s the standard”,
but allows you to focus on solving the problem.
Example: A very simple example of how it seemed
a minor thing would affect the logic or time of the project. In
one of the standards, it is customary to mark * (with an asterisk) fields that are required
to fill to the left of the field name. Non-compliance and lack of
control over execution led to the fact that on different forms of the
project, some of the stars were on the left, part on the right. Because leave
this is not logical, it took time to bring all such
places to the standard.
Actions:
1. Workflow: Introduce and ratify standards.
For some time to exercise control over their compliance.
3. The presence and cultivation of a knowledge base, past experience, etc.
Worst case:
Experience is not outlined anywhere, the knowledge base is missing.
Good practice:
Information is an intangible asset of a company that needs to be safeguarded and maintained.
It often happens that one person knows what others do not know. In this
case, the absence of this person in the project is the risk of the project. The existence of a
knowledge base is the path to advanced training and experience.
Example : Digital library, local Wiki
- good examples of organizing a knowledge base (subject to periodic
replenishment with useful articles).
Actions:
1. Workflow: After the project, outline
potential places for repetition in other projects (description
“Problem - solution”, instructions for the implementation of some actions).
2. Workflow: To bring to each employee
information about the existence of the knowledge base and the promotion (promotion) of
its development.
3. Workflow: Create a centralized electronic
repository with books in electronic form (folder on the server). Create a
special section in the local Wiki with reviews, reviews and recommendations
on existing books.
In the end, I would like to wish you more interesting projects, new experience and good practice.
Do you like the article? Subscribe to RSS
. There will be many interesting things ahead. Interests:
layout, project management, usability.
Source: Blog about web development
and how to improve it.