Факторы, влияющие на 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-разработке
и способах её улучшения