Факторы, влияющие на html вёрстку (Часть 2: Работа PM и Рабочий процесс)

    Продолжение...


    Эта статья является продолжением Части1:
    Работа HTML кодера
    .

    Работа PM


    1. Однозначное толкование требований, пожеланий
    и воли клиента.


    Худший вариант:
    Пожелания клиента передаются PM’ом кодеру как есть (расплывчато,
    невнятно)
    Требование или задача формулируются, например, так: «Сделайте это
    более зелёным», «увеличьте шрифт», «отодвиньте этот блок влево»,
    «оформите эту страницу в общем стиле».
    Хорошая практика:
    PM, на сколько это возможно,
    выясняет требования и пожелания клиента и передаёт уточнённые
    требования кодеру. Требование или задача формулируется, например,
    так: «Используйте вот этот #0BB822 зелёный цвет». «Увеличьте шрифт
    до 18 пикселей», «сдвиньте блок на 3 пикселя влево».
    Влияние:
    Чем более неоднозначное и расплывчатое
    требование, тем больше времени необходимо потратить на его
    выполнение. Отсутствие чётких критериев увеличивает разницу
    в видении конечного результата заказчика и производителя (помните
    картинку с качелями и разным виденьем результата разными участниками
    проекта)
    Не стоит обольщаться мнимой самостоятельностью, данной клиентом в решении
    каких-либо вопросов, т.к. самостоятельность логично предполагает
    отсутствие строгой приёмки (критической оценки) со стороны
    клиента как таковой. На практике клиент всегда просит изменить
    или поменять какие-то вещи снова. Следует свести вариативность
    к минимуму
    Действия:
    1. PM:Выяснить все неоднозначности, сформулировать
    чёткие критерии приёмки. Внимательно отнестись к мелочам.
    Использовать технику «Правильно ли я вас понял?» и другие
    2. HTML кодер: Информировать PM’а о всех вопросах и возникающих
    неоднозначностях

    2. Понимание происходящего и составных
    процессов вёрстки.


    Худший вариант:
    PM не понимает сущности процесса
    вёрстки, выбирает неподходящую последовательность работ кодера
    в проекте, урезает время, уменьшает объём работ.
    PM не видит или не понимает влияние дизайна на функционал (когда
    дизайн заставляет менять работу функциональности).
    Хорошая практика:
    PM однозначно понимает в каких
    местах своего проекта и на какой стадии ему необходимы работы
    с HTML. Понимает и учитывает возможные риски, проводит мероприятия
    по их предотвращению.
    PM замечает места в которых дизайн влияет на функционал. Если данное
    место критично — обсуждает с проектной командой изменения; если
    нет — обсуждает с клиентом «перерисовку» с учётом существующих
    возможностей.
    Влияние:
    Непонимание, из чего состоит результат, и каким образом этого результата достигнуть,
    приводит к существованию активностей, неучтённых в оценке. Это, как следствие,
    ведёт к перерасходу проектного времени.
    Исходный материал для кодинга – статическая картинка демонстрирующая
    частный случай работы сайта. Результат – динамический сайт. Соответственно,
    приёмка происходит не по идеальным условиям, отображённым на картинке,
    а по текущей (актуальной) ситуации.
    Пример: На входе есть PSD (или несколько PSD)
    для собственной CMS. При первой оценке кажется, что адаптация
    дизайна может состоять только из таска «нарезка и натяжка на CMS».
    Однако, CMS — это не просто главная страница. Это и страница результатов
    поиска, страница архива новостей и статей и т.д. Неучтённые страницы
    имеют свои особенности и элементы, не отображённые на PSD и нуждающиеся
    хотя бы в минимальном привидении к общему стилю. Значит, нужен
    новый таск — адаптация оформления существующих блоков к новому
    дизайну. Этот таск не возможно сделать сразу. Он растягивается,
    так как, включая новую функциональность, у клиента появляются
    новые вопросы и пожелания к дизайну новых страниц (клиент, покупая
    CMS может вдруг захотеть включить функциональность, которая есть
    в CMS, но не предполагалась вначале). Создаётся ситуация аврала
    и перерасхода проектного времени. Т.к. время было оценено для
    видимых страниц на начало проекта (а это, допустим, одна главная
    страница), но по обязательствам мы должны адаптировать CMS для
    клиента, а его новые требования вкладываются в это обязательство.
    Действия:
    1. Рабочий процесс: PM, предоставляя дизайн HTML
    кодеру на ревью, получает экспертное заключение о возможных проблемных
    местах, местах влияния дизайна на функционал, вопросы, которые
    следует уточнить у клиента.
    2. Рабочий процесс: Проводить «дни открытых дверей»,
    когда коллеги объясняют друг другу специфику и особенности своей
    работы, обсуждают сложности и мероприятия по их устранению.
    3. Рабочий процесс Конспектировать решение проблем
    или сами проблемы в локальном Wiki (либо как документы, описания,
    FAQ) создавая, таким образом, базу знаний.
    4. PM: Известить HTML кодера о предстоящих работах.
    Обсудить возможные существующие «узкие места», узнать вероятность
    какой-то незапланированной активности, обсудить риски и мероприятия
    по уменьшению их последствий.
    5. HTML кодер: Оценить свою активность по проекту,
    указав всю деятельность по выполнению поставленной задачи. Выставлять
    проценты выполнения тасков в существующих проектных трэкинговых
    системах. Извещать о случившемся риске, консультироваться в возникших
    вопросах.

    3. Понимание условий и ограничений используемой платформы или
    проекта


    Худший вариант:
    PM соглашается с требованиями
    клиента полагаясь на лёгкость реализации или на существование
    подобного функционала в системе.
    РМ владеет только базовыми знаниями о системе.
    Хорошая практика:
    Идеальный вариант, когда PM
    хорошо знает систему в которой работает (имеет разносторонний
    опыт работы с системой) и в обсуждении с клиентом опирается на
    свой опыт.
    Более реалистичный вариант, когда PM обращается к консультанту
    проекта (или опытному девелоперу), чтобы оценить трудозатраты
    на создание (изменение) функционала или обсуждаемых работ.
    Влияние:
    Знание ограничений системы
    позволит ещё на стадии постановки клиентом задачи оценить возможность
    и трудозатраты реализации, не допустить ситуации, когда необходимо
    отвечать по обязательствам, а решение вопроса требует больших
    незапланированных затрат времени и ресурсов, нестабильных решений
    («костылей») и т.д.
    Действия:
    1. Рабочий процесс: Использовать в проекте консультанта
    с таском «Консультирование» (кроме этого таска он в проекте может
    не участвовать).
    2. PM: До начала проекта изучить систему, проконсультироваться
    с коллегами(либо консультантом) и изучить предыдущий опыт работы
    своих коллег.
    3. Рабочий процесс: Конспектировать решение проблем
    или сами проблемы в Wiki (документы, описания, FAQ).
    4. Рабочий процесс: Проведение общих мероприятий
    по повышению уровня компетенции по используемым системам (знание
    системы и её ограничений необходимо и кодеру. См. пункт 7. Работы
    HTML кодера).

    4. Объективность.


    Худший вариант:
    PM не может расставить
    приоритеты по проекту в критических ситуациях, трактует текущую
    ситуацию в проекте далеко от истинного положения вещей. Выбирает
    быстрые, а чаще авантюрные решения.
    Хорошая практика:
    PM имеет и предлагает
    последовательность работы для экстренного варианта течения проекта,
    проверяет и переставляет работы по ситуации, старается использовать
    стабильные решения, видит весь проект целиком, консультируется
    с проектной командой перед принятием решения (даже если известно,
    что мнение проектной команды будет отличаться).
    Влияние:
    No comments

    5. Контроль проекта и отдельных частей
    на разных этапах.


    Худший вариант:
    PM проверяет проект в конце.
    Хорошая практика:
    PM проверяет результаты по
    ходу проекта на каждой стадии (по вехам (milestones) или по завершению
    таска и т.д.), осуществляет оперативный контроль.
    Влияние:
    Не контролируя проект на каждой
    стадии, PM увеличивает вероятность перерасхода проектного времени
    и срыва сроков сдачи. Положение ухудшается тем, что, в случае
    проведения контроля в конце, отвечающим за текущую ситуацию в
    проекте, по видению PM’а, является только HTML кодер (если таск
    «натяжка» последний в проекте). А также тем, что всё равно необходимо
    снова привлекать ресурс для девелопмента, тестинга и, возможно,
    перенатяжки.
    Пример: Имеет место проект, в котором дизайна
    на его начало нет. Девелопмент прошёл без прототипа и без дизайна,
    только по функциональной спецификации. Клиент прислал свёрстанный
    дизайн или PSD, и после этого в проект вступает HTML кодер. Ситуация:
    в дизайне нарисована часть функционала, которая отличается от
    той, что сделана. Причём реализация разницы может потянуть ещё
    на 20%-60% уже потраченного на девелопмент времени. Как следствие
    — простой HTML кодера и срыв сроков сдачи.
    Действия:
    1.РM: Осуществлять контроль на всех стадиях (и
    в промежутках) проекта.

    6. Эффективные коммуникации.


    Худший вариант:
    PM обсуждает общие для проекта
    моменты с каждым участником проекта раздельно. Участники проекта
    общаются и решают оперативные вопросы тоже «каждый с каждым».
    Обсуждение проекта в IM занимает много (или даже больше)
    времени, чем выполнение задачи. Возникает необходимость обсуждать
    рабочие моменты с несколькими людьми одновременно (кроме этого
    ещё и одно и тоже).
    Хорошая практика:
    Все участники проекта в курсе
    изменения и обсуждения общих для проекта деталей.
    Влияние:
    Общение «каждый с каждым» всегда
    приводит к тому, что упускаются какие-то детали по проекту, важные
    для всех его участников (детали, изменения, последовательность
    выполнения задач и т.д.).
    Действия:
    1. Рабочий процесс: Конспектировать результаты
    общения, извещать о результатах всех участников проекта. По возможности
    обсуждать общие детали при максимуме участников проекта.
    2. Рабочий
    процесс:
    Назначить строгие даты и время совещаний по проекту с условием обязательного
    присутствия всей команды. Подведение итогов (срез).

    Рабочий процесс


    1. Наличие одного отчётного органа, одной цепочки, одного постановщика
    задачи.


    Худший вариант:
    Необходимость отчитываться перед несколькими людьми, получать задания из нескольких мест.
    Хорошая практика:
    Возможность отвечать перед одним
    определённым человеком (чаще всего — PM'ом проекта)PM несёт ответственность и принимает все ключевые решения,
    ставит задачи и т.д.
    Влияние:
    Когда надо отчитываться перед
    несколькими людьми, то это выглядит следующим образом: рассказать
    первому, обсудить, ответить на вопросы. Рассказать второму, обсудить,
    ответить на вопросы. Рассказать первому, что решили со вторым,
    обсудить, ответить на вопросы. Рассказать второму комментарии
    и то, что решили с первым (дай бог, чтобы у второго не было комментариев
    или предложений). Таким образом, решение проблемы не начинается
    раньше её обсуждения. Несмотря на видимую нелогичность таких действий,
    они случаются. Особый драматизм в том, что они случаются как раз
    в самый неподходящий момент – когда по проекту итак идёт перерасход
    времени (т.к. кроме PM’а в контроль за проектом включается новые
    люди — более высокие руководители. И каждому из них необходимо
    войти в курс дела и принять новые решения).
    Переложив первый закон Паркинсона для этой ситуации: чем больше
    людей занимаются одной и той же проблемой, тем больше хаоса.
    Действия:
    1. Рабочий процесс: Решения принимать по цепочке.
    Приложить как можно больше усилий, чтобы не отрывать конечного
    исполнителя от работы над задачей. Обсуждения проводить группой.

    2. Наличие и соблюдение стандартов и требований.


    Худший вариант:
    Отсутствие стандартов или
    их несоблюдение.
    Хорошая практика:
    Наличие и соблюдение стандартов.
    Влияние:
    Несоблюдение и отсутствие стандартов
    приводит к повторению из проекта в проект одних и тех же ошибок
    (нестыковки, нелогичности, перерасход времени и т.п.). Наличие
    стандартов позволяет не только избежать ошибок, но и повысить
    качество конечного продукта. Использование стандартов должно быть
    доведено до такого уровня, чтобы оно стало автоматическим процессом
    и не заставляло задумываться или вспоминать «как там по стандарту»,
    а позволило сосредоточиться на решении задачи.
    Пример: Очень простой пример того, как, казалось
    бы, незначительная вещь влияет на логику или время проекта. В
    одном из стандартовпринято помечать *(звёздочкой) поля, обязательные
    к заполнению слева от названия поля. Несоблюдение и отсутствие
    контроля над исполнением привело к тому, что на разных формах
    проекта часть звёздочек была слева, часть справа. Т.к. оставлять
    такое не логично, то было потрачено время на приведение всех подобных
    мест к стандарту.
    Действия:
    1. Рабочий процесс: Вводить и ратифицировать стандарты.
    Некоторое время осуществлять контроль над их соблюдением.

    3. Наличие и культивация базы знаний, прошлого опыта и т.д.


    Худший вариант:
    Опыт нигде не конспектируется, база знаний отсутствует.
    Хорошая практика:
    Информация – нематериальный актив компании, который требуется беречь и сохранять.
    Часто бывает так, что один человек знает то, чего не знают другие. В таком
    случае отсутствие этого человека в проекте – риск проекта.Существование базы
    знаний — путь к повышению квалификации и опыта.
    Пример: Электронная библиотека, локальное Wiki
    — хорошие примеры организации базы знаний (при условии периодического
    пополнения полезными статьями).
    Действия:
    1. Рабочий процесс: После проекта конспектировать
    потенциальные для повторения в других проектах места (описание
    «проблема – решение», инструкции по осуществлению каких-то действий).
    2. Рабочий процесс: Довести до каждого сотрудника
    сведенья о существовании базы знаний и пропагандирование (поощрение)
    её развития.
    3. Рабочий процесс: Создать централизованное электронное
    хранилище с книгами в электронном виде (папка на сервере). Создать
    специальный раздел в локальном Wiki с рецензиями, отзывами и рекомендациями
    на существующие книги.
    Напоследок хочется пожелать Вам побольше интересных проектов, нового опыта и хорошей практики.

    Понравилась статья? Подписывайся на RSS
    . Впереди будет много интересного. В сфере интересов:
    вёрстка, управление проектами, юзабилити.

    Источник: Блог о web-разработке
    и способах её улучшения
    Поделиться публикацией
    Реклама помогает поддерживать и развивать наши сервисы

    Подробнее
    Реклама
    Комментарии 11
    • НЛО прилетело и опубликовало эту надпись здесь
      • +6
        1) А у кого-то сейчас и есть то самое "раньше" в котором эта статья есть :))

        2) Плагиат? Набирал каждый символ сам. Буду рад, если подкрепите сказанное ссылками.Мне эта тема интересна. В этой же статье, но в блоге указано, что исследования продолжаются и я всегда рад расширить статью Вашими дополнениями к хорошей и плохой практике и к действиям которые следует применить.
        • НЛО прилетело и опубликовало эту надпись здесь
    • +2
      хех... до чего понимаю насчёт не врубающихся в тему PM'ов! Довелось в таких местах поработать - больше не хочу. Сидит какая-нибудь девочка с образованием "типа манагер", обещает заказчику с три короба и торопит разработчиков, при этом её совершенно не волнует, а КАК это, собственно, делается. А "биг босс" понимает в этих делах ещё меньше, вот и берёт на работу таких девочек, ибо в их понимании главное - не техника, а менеджмент. ИМХО - в айтишной среде начальство должно быть выходцами из технарей, инача вот такая лажа и будет получаться.
      • НЛО прилетело и опубликовало эту надпись здесь
        • +2
          Хорошая статья, можно провести несколько параллелей с кулинарией:

          - Однозначное толкование требований, пожеланий и воли клиента
          Шеф повар должен однозначно узнать у клиента, какой степени прожарки он хочет свой стейк.

          - Контроль проекта и отдельных частей на разных этапах.
          Если повар пробует блюдо в конце процесса приготовления, то результат может оказаться совсем не тот, что он ожидал. В случае если делать пробы в ходе приготовления, то результат оказывается гораздо лучше.
          • 0
            Именно. Он должен не только пробовать на разных стадиях, но и выбирать ингридиенты сам. В хороших ресторанах шеф повар сам ездит на рынок к своим поставщикам и выбирает ингридиенты лучшего качества. Кроме того, он пробует и подливу и соус и т.д. Конечно это увеличивает цену блюда...
            • 0
              Неожиданное сравнение, если честно. Особенно, когда читаешь его в момент записи мультика «Рататуй» на болванку :)
            • 0
              Блин. Советы полезные реально. И я понимаю что вы стараетесь полаконичнее их изложить...
              Но все же - вот бы еще полаконичнее...)
              Советы тем легче принять к исполнению, чем легче их запомнить. Даже заголовки сбивают: придумайте может иконки для подпунктов...
              Может так:
              "НАХ"
              "Гут"
              "Потому что"
              "Вывод"

              ? ))))
              • 0
                Была мысль в формате Mind maps сделать карту по статье. В следующий раз обязательно попробую. Из-за обьёма разбил текст на 2 части.

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.