Факторы, влияющие на 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 с рецензиями, отзывами и рекомендациями на существующие книги.