Factors affecting the html layout (Part 2: PM Work and Workflow)

Continued ...

This article is a continuation of Part 1:

HTML coder operation .

PM work

1. Unambiguous interpretation of requirements, wishes

and the will of the client.

Worst case:

The client's wishes are transmitted by the PM to the encoder as is (vague,

unintelligible)

A requirement or task is formulated, for example, like this: “Make it

more green, increase the font, move this block to the left,

"Design this page in a general style."

Good practice:

PM, as far as possible,

ascertains the requirements and wishes of the client and passes the specified

coder requirements. The requirement or task is formulated, for example,

like this: "Use this # 0BB822 green color." "Increase the font

up to 18 pixels "," move the block 3 pixels to the left. "

Impact:

The more ambiguous and vague

the requirement, the more time you need to spend on it

performance. Lack of clear criteria increases the difference

in the vision of the end result of the customer and the manufacturer (remember

a picture with swings and different visions of the result by different participants

project)

Do not flatter yourself with the imaginary autonomy given by the client in the decision.

any questions because autonomy logically suggests

lack of strict acceptance (critical evaluation) by

customer per se. In practice, the client always asks to change

or change some things again. Should reduce the variability

to a minimum

Actions:

1. PM: Clarify all ambiguities, articulate

clear acceptance criteria. Carefully treat the little things.

Use the technique “Did I understand you correctly?” And others

2. HTML Encoder: Inform PM about all issues and issues.

ambiguity

2. Understanding what is happening and compound

coding processes.

Worst case:

PM does not understand the essence of the process

layout, selects the wrong sequence of work coder

in the project, cuts time, reduces the amount of work.

PM does not see or understand the influence of design on functionality (when

design makes change the work of the functionality).

Good practice:

PM clearly understands what

the places of his project and at what stage he needs work

with html. Understands and considers possible risks, holds events

to prevent them.

PM notices places where design affects functionality. If given

location is critical - discussing changes with the project team; if a

No - discusses “redrawing” with the client, taking into account the existing

opportunities.

Impact:

Misunderstanding of what the result consists of, and how to achieve this result,

leads to the existence of activities that are not included in the assessment. This, as a result,

leads to an overrun of project time.

The source material for coding - a static picture showing

special case of the site. The result is a dynamic site. Respectively,

Acceptance is not in accordance with the ideal conditions shown in the picture,

and on the current (actual) situation.

Example: At the entrance there is a PSD (or several PSD)

for your own CMS. At the first assessment, it seems that adaptation

design can consist only of the task "cutting and stretching on the CMS".

However, CMS is not just the main page. This and the results page

search, archive page of news and articles, etc. Unaccounted pages

have their own features and elements that are not displayed on the PSD and need

at least in the minimal ghost to the overall style. So need

new task - adaptation of the design of existing blocks to the new

design. This task can not be done immediately. It stretches,

since, including the new functionality, the client appears

New questions and wishes for the design of new pages (customer, buying

CMS may suddenly want to include functionality that is

in CMS, but was not intended at the beginning). Creation of a situation of trawling

and overrun project time. Because time has been estimated for

visible pages at the beginning of the project (and this, for example, one main

page), but by commitment we have to adapt the CMS for

customer, and his new requirements are invested in this commitment.

Actions:

1. Workflow: PM, providing HTML design

coder for review, gets an expert opinion on possible problem

places, places of influence of design on functionality, issues that

should be clarified with the client.

2. Workflow: Hold “open days”,

when colleagues explain to each other the specifics and characteristics of their

work, discuss the difficulties and measures to eliminate them.

3. Workflow Outline Problem Solving

or the problems themselves in the local wiki (either as documents, descriptions,

FAQ) thus creating a knowledge base.

4. PM: Notify HTML coder about upcoming jobs.

Discuss possible existing bottlenecks, find out the probability

some unplanned activity, discuss risks and activities

to reduce their effects.

5. HTML coder: Evaluate your project activity,

specifying all activities to perform the task. Exhibit

performance percentages of tasks in existing project tracking

systems. Notify risk exposure, consult in arising

issues.

3. Understanding the terms and conditions of the platform used or

of the project

Worst case:

PM agrees with the requirements

customer relying on ease of implementation or existence

similar functionality in the system.

RM has only basic knowledge of the system.

Good practice:

Perfect when PM

well knows the system in which he works (has a versatile

experience with the system) and in discussion with the client relies on

your experience.

A more realistic option when PM calls a consultant

project (or an experienced developer) to assess the labor costs

on creation (change) of a functional or discussed works.

Impact:

Knowledge of system limitations

will allow even at the stage of setting the task by the client

and labor costs of implementation, to prevent situations where it is necessary

answer for obligations, and the solution of the problem requires large

unplanned time and resources, unstable solutions

("Crutches"), etc.

Actions:

1. Workflow: Use consultant in project

with the consultancy task (in addition to this task, he may

do not participate).

2. PM: Before starting a project, examine the system, consult

with colleagues (or consultant) and explore previous work experience

my colleagues.

3. Workflow: Outline Problem Solving

or the problems themselves in the wiki (documents, descriptions, FAQ).

4. Workflow: Conducting general events

to increase the level of competence of the systems used (knowledge

system and its limitations is necessary and the encoder. See point 7. Works

HTML coder).

4. Objectivity.

Worst case:

PM can not arrange

project priorities in critical situations, treats the current

The situation in the project is far from the true state of affairs. Picks

quick and often adventurous decisions.

Good practice:

PM has and offers

sequence of work for the emergency version of the project,

checks and rearranges work on the situation, tries to use

stable solutions, sees the entire project as a whole, consults

with the project team before making a decision (even if it’s known

that the opinion of the project team will be different).

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 verifies results by

the progress of the project at each stage (by milestones) or upon completion

task, etc.), carries out operational control.

Impact:

Not controlling the project on each

stage, PM increases the likelihood of cost overruns

and the failure of deadlines. The situation is worsened by the fact that, in the case

control at the end responsible for the current situation in

the project, according to PM’s vision, is only an HTML coder (if task

“Stretch” last in the project). And the fact that you still need

again attract resources for development, testing and, possibly,

re-tightening.

Example: There is a project in which the design

at its beginning there is no. Development went without a prototype and without design,

functional specification only. The client has sent rolled

design or PSD, and after that the HTML coder enters the project. Situation:

in the design part of the functional is drawn, which differs from

the one that is made. Moreover, the implementation of the difference can still pull

20% -60% of the time already spent on development. Consequently

- simple HTML coder and deadline for delivery.

Actions:

1. PM: To exercise control at all stages (and

in between) the project.

')

6. Effective communication.

Worst case:

PM discusses common to the project

moments with each project participant separately. Project participants

communicate and solve operational issues, too, "everyone with everyone."

IM project discussion takes a lot (or even more)

time than doing the task. There is a need to discuss

working moments with several people at the same time (except for

also the same).

Good practice:

All project participants are in the know

Changes and discussion of common for the project details.

Impact:

“Every-one” communication is always

leads to the fact that missing some details on the project, important

for all participants (details, changes, sequence

performing tasks, etc.).

Actions:

1. Workflow: Outline Results

communication, report on the results of all project participants. Whenever possible

discuss common details at the maximum of project participants.

2. Worker

Process: Assign strict dates and times for project meetings with mandatory

the presence of the whole team. Summing up (cut).

The working process

1. The presence of one reporting body, one chain, one director

tasks.

Worst case:

The need to report to several people, get jobs from several places.

Good practice:

The ability to respond to one

by a certain person (most often by the PM of the project) PM is responsible and makes all the key decisions,

sets tasks, etc.

Impact:

When to report to

by several people, it looks like this: tell

first, discuss, answer questions. Tell the second, discuss,

answer the questions. Tell the first that you decided with the second,

discuss, answer questions. Tell the second comment

and what was decided with the first one (God forbid that the second has no comments

or suggestions). Thus, the solution to the problem does not begin.

before discussing it. Despite the apparent illogic of such actions,

they happen. The particular drama is that they happen just

at the most inopportune moment - when the project is overspending

time (since except PM'a in the control of the project includes new

people are higher leaders. And each of them must

get up to date and make new decisions).

Having shifted the first Parkinson's law for this situation: the more

people deal with the same problem, the more chaos.

Actions:

1. Workflow: Make decisions by chain.

Make as much effort as possible so as not to tear off the final

artist from work on the task. Discussions hold a group.

2. Availability and compliance with standards and requirements.

Worst case:

Lack of standards or

their non-compliance.

Good practice:

Availability and compliance with standards.

Impact:

Non-compliance and lack of standards

causes the same errors to be repeated from project to project

(inconsistencies, irrationality, time overruns, etc.). Availability

standards not only avoids mistakes, but also increases

quality of the final product. The use of standards should be

brought to such a level that it becomes an automatic process

and did not make you think or remember "how is it according to the standard",

and allowed to focus on solving the problem.

Example: A very simple example of how it seemed

would a minor thing affect the logic or time of the project. AT

one of the standards is to mark * (asterisk) fields, mandatory

to the fill to the left of the field name. Failure and absence

control over the execution led to the fact that on different forms

The project part of the stars was to the left, the part to the right. Because leave

this is not logical, then time was spent on bringing all such

places to standard.

Actions:

1. Workflow: Introduce and ratify standards.

Some time to monitor their compliance.

3. Presence and cultivation of knowledge base, past experience, etc.

Worst case:

Experience is not outlined anywhere, the knowledge base is missing.

Good practice:

Information - an intangible asset of the company that you want to protect and preserve.

It often happens that one person knows what others do not know. In such

the absence of this person in the project - the risk of the project. The existence of a base

Knowledge - a way to improve skills and experience.

Example : Electronic Library, Local Wiki

- good examples of knowledge base organization (subject to periodic

replenishment useful articles).

Actions:

1. Workflow: After the project take notes

potential for repetition in other projects places (description

"Problem - solution", instructions for the implementation of some actions).

2. Workflow: Bring to each employee

Information about the existence of a knowledge base and promotion (promotion)

its development.

3. Workflow: Create a centralized electronic

storage 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.

Finally, I would like to wish you more interesting projects, new experience and good practice.



Like this article? Subscribe to RSS

. There will be a lot of interesting things ahead. In the area of ​​interest:

layout, project management, usability.



Source: Web Development Blog

and ways to improve it