Продолжение.
Эта статья является продолжением Части 1: Работа HTML-кодером .
работа премьер-министра
1. Однозначная трактовка требований и пожеланий и желание клиента.
Худший вариант: Пожелания клиента передаются ПМ кодировщику как есть (расплывчато, не понятно) Требование или задача формулируется, например, так: «Сделай это больше зеленого», «увеличить шрифт», «переместить этот блок влево», «Оформите эту страницу в общем стиле».
Хорошая практика: в личку как можно больше уточняет требования и пожелания клиента и доносит заданное Требования к кодировщику.
Требование или задача формулируется, например, например: «Используйте зеленый цвет #0BB822».
«Увеличить шрифт до 18 пикселей», «переместить блок на 3 пикселя влево».
Влияние: Более двусмысленно и неясно требование, тем больше времени нужно потратить на это производительность.
Отсутствие четких критериев увеличивает разницу в видении конечного результата заказчика и производителя (помните картинка с качелями и разным видением результата у разных участников проект) Не обманывайтесь мнимой независимостью, которую дает клиент в принятии решения.
никаких вопросов, ведь независимость логически предполагает отсутствие строгого принятия (критической оценки) со стороны клиент как таковой.
На практике клиент всегда просит изменить или снова изменить что-то.
Вариативность должна быть уменьшена к минимуму Действия: 1. ПМ: Выясним все неясности, сформулируем четкие критерии приемки.
Обращайте внимание на мелочи.
Используйте вопрос «Правильно ли я вас понялЭ» техника.
и другие 2. HTML-кодер: Информировать Премьер-министра обо всех вопросах и возникающих
двусмысленности
2. Понимание происходящего и его составляющих процессы компоновки.
Худший вариант: ПМ не понимает сути процесса макет, выбирает неподходящую последовательность работы кодировщика в проекте сокращает время, уменьшает объем работы.
Руководитель проекта не видит и не понимает влияния дизайна на функциональность (когда дизайн вызывает изменения в работе функциональности).
Хорошая практика: Премьер-министр четко понимает, что места его проекта и на каком этапе ему нужна работа с HTML. Понимает и учитывает возможные риски, проводит мероприятия чтобы предотвратить их.
Премьер-министр замечает места, где дизайн влияет на функциональность.
Если это местоположение имеет решающее значение — обсуждает изменения с командой проекта; Если нет - обсуждает с клиентом «перерисовку» с учетом имеющихся возможности.
Влияние: Непонимание того, из чего состоит результат и как этого результата добиться, приводит к существованию деятельности, не учитываемой при оценке.
Это, как следствие, приводит к перерасходу времени проекта.
Исходный материал для кодирования – статическое изображение, демонстрирующее особый случай сайта.
Результатом является динамичный веб-сайт. Соответственно, приемка не происходит в идеальных условиях, показанных на картинке, но по сложившейся (текущей) ситуации.
Пример: На входе имеется PSD (или несколько PSD) для вашей собственной CMS. На первый взгляд кажется, что адаптация дизайн может состоять только из задачи «вырезать и растянуть на CMS».
Однако CMS — это не просто домашняя страница.
Это страница результатов поиск, страница архива новостей и статей и т. д. Неучтенные страницы имеют свои характеристики и элементы, которые не отображаются в PSD и нуждаются в хотя бы в минимальной адаптации к общему стилю.
Итак, нам нужно новая задача - адаптация конструкции существующих блоков к новой дизайн.
Эту задачу невозможно выполнить сразу.
Он растягивается поскольку, включая новый функционал, клиент имеет новые вопросы и предложения по оформлению новых страниц (клиент покупает CMS может внезапно захотеть включить уже имеющиеся функции.
в CMS, но изначально не предполагалось).
Создается чрезвычайная ситуация и перерасход времени проектирования.
Поскольку время оценивалось видимые страницы в начале проекта (а это, например, одна из основных страница), но в силу наших обязательств мы должны адаптировать CMS для клиента и его новые требования включены в это обязательство.
Действия: 1. Рабочий процесс: ПМ, обеспечение HTML дизайна программист на проверку, получает экспертное заключение о возможных проблемных места, места, где дизайн влияет на функциональность, проблемы, которые необходимо уточнять у клиента.
2. Рабочий процесс: Проводить дни открытых дверей когда коллеги объясняют друг другу специфику и особенности своей работать, обсуждать трудности и меры по их устранению.
3. Рабочий процесс Схема решения проблем или сами проблемы в локальной Wiki (в виде документов, описаний, FAQ), создавая таким образом базу знаний.
4. ЛС: Сообщите HTML-кодировщику о предстоящей работе.
Обсудить возможные существующие узкие места, выяснить вероятность какая-то незапланированная деятельность, обсудить риски и меры чтобы уменьшить их последствия.
5. HTML-кодер: Оцените свою деятельность на проекте, с указанием всех действий для выполнения задачи.
Экспонат процент выполненных задач в существующих системах отслеживания проектов системы.
Уведомить о возникшем риске, проконсультировать по возникающим вопросы.
3. Ознакомьтесь с условиями и ограничениями платформы, которую вы используете или проект
Худший вариант: Премьер-министр согласен с требованиями клиент полагается на простоту реализации или существования аналогичный функционал в системе.У РМ есть только базовые знания о системе.
Хорошая практика: Идеально, когда ПМ хорошо знает систему, в которой работает (обладает разносторонним опыт работы с системой) и в обсуждениях с клиентом полагается на ваш опыт. Более реалистичный вариант – обратиться премьер-министру к консультанту.
проект (или опытный разработчик) для оценки трудозатрат создать (изменить) обсуждаемый функционал или работу.
Влияние: Знание ограничений системы.
позволит клиенту оценить возможность еще на этапе постановки задачи и трудозатраты на внедрение, чтобы не допустить ситуации, когда это необходимо отвечать по обязательствам, а решение вопроса требует больших незапланированные затраты времени и ресурсов, нестабильные решения («костыли») и т. д. Действия: 1. Рабочий процесс: Использовать консультанта в проекте с задачей «Консультация» (помимо этой задачи можно использовать в проекте не участвуйте).
14.00: Перед запуском проекта изучите систему, проконсультируйтесь с коллегами (или консультантом) и изучить предыдущий опыт работы их коллеги.
3. Рабочий процесс: Схема решения проблем или сами проблемы в Wiki (документы, описания, FAQ).
4. Рабочий процесс: Проведение генеральных мероприятий повысить уровень компетентности в используемых системах (знания системы и ее ограничений также необходимы для кодировщика.
См.
пункт 7. Работа HTML-кодер).
4. Объективность.
Худший вариант: ПМ не может организовать приоритеты проекта в критических ситуациях, интерпретирует текущую ситуация в проекте далека от истинного положения дел.
выбирает быстрые, и чаще всего авантюрные решения.
Хорошая практика: В ПМ есть и предлагает последовательность работ для аварийной версии проекта, проверяет и перестраивает работу по ситуации, старается использовать стабильные решения, видит весь проект, консультирует с командой проекта перед принятием решения (даже если оно известно что мнение команды проекта будет отличаться).
Влияние:
Без комментариев
5. Контроль проекта и отдельных частей на разных этапах.
Худший вариант: В конце премьер-министр рассматривает проект. Хорошая практика: Премьер-министр сверяет результаты с ход проекта на каждом этапе (по вехам или завершению).
задание и др.
), осуществляет оперативный контроль.
Влияние: Без контроля проекта на каждом этапе, PM увеличивает вероятность перерасхода времени проекта и несоблюдение сроков.
Ситуация усугубляется тем, что в случае осуществляющий контроль в конце, ответственный за текущую ситуацию в проект, по замыслу ПМ, — это всего лишь HTML-кодер (если задача «stretch» — последний в проекте).
А также те, которые еще нужны снова привлечь ресурс для разработки, тестирования и, возможно, перенапряжение.
Пример: Есть проект, в котором дизайн в начале нет. Разработка проходила без прототипа и без дизайна, только в соответствии с функциональной спецификацией.
Клиент прислал макет дизайн или PSD, а после этого в проект приходит HTML-кодер.
Ситуация: конструкция содержит часть функционала, отличающуюся от тот, который был сделан.
Более того, осознание разницы может занять еще больше времени.
на 20%-60% времени, уже потраченного на разработку.
Следовательно - простой HTML-кодер и сорванные сроки.
Действия: 1.РМ: Осуществлять контроль на всех этапах (и
между ними) проект.
6. Эффективные коммуникации.
Худший вариант: Премьер-министр обсудил общий проект моменты с каждым участником проекта отдельно.
Участники проекта Они также общаются и решают оперативные вопросы «все со всеми».
Обсуждение проекта в IM занимает много (а то и больше) время, чем выполнение задачи.
Есть необходимость обсудить рабочие моменты с несколькими людьми одновременно (кроме этого один и тот же).
Хорошая практика: Все участники проекта осведомлены изменения и обсуждение общих деталей проекта.
Влияние: Общение «каждый со всеми» всегда приводит к тому, что упускаются некоторые детали проекта, важные для всех его участников (подробности, изменения, последовательность выполнение заданий и др.
).
Действия: 1. Рабочий процесс: Обратите внимание на результаты коммуникации, оповестить всех участников проекта о результатах.
Если возможно обсудить общие детали с максимумом участников проекта.
2. Рабочий процесс: Установите строгие даты и время для совещаний по проекту с обязательным присутствие всей команды.
Подведение итогов (резка).
Рабочий процесс
1. Наличие одного подотчетного органа, одной сети, одного директора задания.
Худший вариант: Необходимость отчитываться перед несколькими людьми, получать задания из нескольких мест. Хорошая практика: Возможность ответить на один определенный человек (чаще всего ПМ проекта) ПМ несет ответственность и принимает все ключевые решения, ставит задачи и т. д. Влияние: Когда отчитываться несколько человек, то это выглядит так: скажи сначала обсудим, ответим на вопросы.
Второе расскажи, обсуди, ответь на вопросы.
Расскажи первому, что ты решил со вторым, обсудить, ответить на вопросы.
Расскажите еще один комментарий и что с первым решили (дай Бог, чтобы ко второму не было замечаний или предложения).
Так что решение проблемы не начинается до его обсуждения.
Несмотря на кажущуюся нелогичность подобных действий, они случаются.
Особый драматизм в том, что они случаются просто так.
в самый неподходящий момент – когда проект уже перегружен время (потому что помимо ПМ в контроль проекта включаются новые люди являются высшими лидерами.
И каждому из них нужно вникнуть в курс дела и принять новые решения).
Перевод первого закона Паркинсона для этой ситуации: чем больше люди сталкиваются с одной и той же проблемой, тем больше хаоса.
Действия: 1. Рабочий процесс: Решения принимаются по цепочке.
Приложите максимум усилий, чтобы не сорвать финал.
исполнителя от работы над заданием.
Проводите обсуждения в группе.
2. Наличие и соответствие стандартам и требованиям.
Худший вариант: Отсутствие стандартов или их несоблюдение.
Хорошая практика: Доступность и соответствие стандартам.
Влияние: Несоблюдение и отсутствие стандартов приводит к повторению одних и тех же ошибок от проекта к проекту (нестыковки, нелогичности, перерасход времени и т.п.
).
Доступность стандартов позволяет не только избежать ошибок, но и повысить качество конечного продукта.
Использование стандартов должно быть доведено до такого уровня, что это становится автоматическим процессом и не заставлял задуматься или вспоминать «как там по стандарту», и позволил мне сосредоточиться на решении проблемы.
Пример: Очень простой пример того, как это казалось Это будет мелочь, которая повлияет на логику или сроки реализации проекта.
В Одним из стандартов является пометка * (звездочкой) полей, обязательных для заполнения.
до заполнения слева от имени поля.
Несоблюдение и отсутствие контроль за исполнением привел к тому, что на разных формах проекта, некоторые звезды были слева, некоторые справа.
Потому что уходи это не логично, тогда время было потрачено зря привозя все такое сиденья стандартные.
Действия: 1. Рабочий процесс: Внедрить и ратифицировать стандарты.
Следите за их соблюдением в течение некоторого времени.
3. Наличие и развитие базы знаний, прошлого опыта и т.д.
Худший вариант: Опыт нигде не указан, базы знаний нет. Хорошая практика: Информация – это нематериальный актив компании, который необходимо защищать и сохранять.Часто бывает, что один человек знает что-то, чего не знают другие.
В таком В этом случае отсутствие этого человека в проекте является проектным риском.
Наличие базы Знания – это путь к повышению квалификации и опыту.
Пример : электронная библиотека, местная Wiki - хорошие примеры организации базы знаний (при условии периодического пополнение полезными статьями).
Действия: 1. Рабочий процесс: Делайте заметки после проекта создает потенциал для повторения в других проектах (описание «проблема – решение», инструкция по выполнению некоторых действий).
2. Рабочий процесс: Донесите до каждого сотрудника информация о наличии базы знаний и поощрении (поощрении) его развитие.
3. Рабочий процесс: Создать централизованную электронную хранилище с книгами в электронном виде (папка на сервере).
Создавать специальный раздел в местной Wiki с обзорами, рецензиями и рекомендациями по существующим книгам.
В заключение хотелось бы пожелать вам больше интересных проектов, нового опыта и хорошей практики.
Вам понравилась статья? Подписаться RSS .
Впереди будет много интересного.
Области, представляющие интерес: верстка, управление проектами, удобство использования.
Источник: Блог о веб-разработке и способы его улучшения Теги: #HTML #верстка #управление проектами #веб-разработка #разработка веб-сайтов
-
Чтобы Читать И Писать, Нужно Время
19 Oct, 24 -
Контроль Доступа На Основе Поведения
19 Oct, 24
