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