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.

    Also popular now: