]]>
]]>
Рейтинг@Mail.ru

Факторы качества и времени html вёрстки

Материал из Веб программирование.

Перейти к: навигация, поиск

Факторы качества и времени html вёрстки.


Содержание

Для кого эта статья?

Html кодерам – начинающим кодерам поможет повысить свой профессиональный уровень; оценить текущую ситуацию в проектах, предупредить негативное течение проекта.Тем,кто ещё только определяется “быть или не быть” больше вкурить о профессии html кодер. Те же, кто в кодинге давно врятле найдут в статье что-то новое для себя, а некоторые вещи даже могут показаться не достойными внимания. Однако стоит помнить,что очевидные вещи для одного - это неизвестный мир для другого,а ваш опыт хорошей практики может быть выходом из сложной сложившейся ситуации для кого-то.

Руководству – узнать, какие мероприятия стоит провести в компании для улучшения рабочего процесса, повышения опыта работников, уменьшения издержек (за счёт уменьшения перерасхода проектного времени и учёта не просчитанных ранее активностей) и повышения качества.

Руководителям проектов (Project managers) – поможет учесть некоторые специфические риски проекта: узнать о неизвестных ранее поглотителях проектного времени и не запланированных активностях; узнать о реальных трудозатратах по некоторым активностям; оценить и улучшить текущий уровень ведения проектов.

Другим участникам web разработок – поможет больше узнать о трудовых буднях своих коллег.

Сгруппированные факторы

-картинка-

Работа HTML кодера

1. Исходные данные и материал для вёрстки.

1.1 Вёрстка дизайна

Худший вариант: Клиент присылает некачественный материал для вёрстки. Материал в форматах pdf, ppt, jpg либо psd со склеенными слоями, растеризованными шрифтами, шрифтами со сглаживаниями; шрифтами, не входящими в поставку Windows. Требования описаны словесно («сделайте красным», «сделайте, как здесь»).

Хорошая практика: Материал для вёрстки должен быть в формате PSD (не исключён другой популярный формат, поддерживающий слои). В PSD используемые слои названы соответственно своему содержимому. Шрифты, не входящие в стандартную поставку Windows, используются только для картинок.

Влияние: Склеенные слои, растеризованный текст и другие не соблюдённые требования к исходному материалу приводят к увеличению времени вёрстки.

Пример: в дизайне используется кнопка в виде картинки. Необходимо сделать похожую по аналогии. При дизайне, каким он должен быть, это займёт около 10 минут. При плохом качестве может занять и 2 часа.

Действия: 1. PM: На этапе выяснения требований дать клиенту ознакомиться с документом по требованиям к графическому материалу. (Содержащему примеры требований. Желательно со скриншотами и пояснениями к каждому пункту).

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


1.2 Редизайн

Худший вариант: Клиент присылает или сообщает ссылки (что ещё хуже) на страницы со свёрстанным дизайном плохого качества (без типовых элементов, содержащим проблемы кроссбраузерности, невалидный код).

Хорошая практика: Клиент присылает свёрстанный код. HTML кодер, PM и другие участники проверяют его качество и наличие необходимых элементов.

Влияние: Если факт плохого качества страниц не озвучен перед клиентом или PM’ом, то за все вытекающие баги ответственность перекладывается на HTML кодера. Тем самым увеличивается время незапланированного фиксинга багов.

В случае со страницами, расположенными в Интернете, прежде чем приступить к вёрстке, кодеру необходим этап переподготовки для создания сайта локально. Это время следует учесть при оценке.

Пример: Чтобы воссоздать локально сайт, где все картинки прописаны в CSS, верстальщику надо отследить путь каждой, прописать его в адресной строке, чтобы скопировать каждую картинку на локальный диск. Количество прописанных в CSS картинок не ограничено.

Действия: 1. PM: На этапе выяснения требования подчеркнуть важность качества входящего материала и последствия плохого: технические (баги, перерасход проектного времени, плохая расширяемость) и негативное влияние на чувство доверия и отношение будущих клиентов (пользователей).

2. PM: Просить клиента прислать свёрстанный код вместо публикации на сайте (если нет FTP доступа). Это позволяет HTML кодеру сразу же работать с кодом «как есть», не занимаясь переподготовкой. Важно отметить, что это ещё и позволяет предотвратить тихое добавление клиентом новых элементов под видом того же плана работ.

3. HTML кодер: Известить PM’а о возможных проблемах, ошибках и качестве материала. Написать, каких элементов не достаёт в новом дизайне. Попросить провести сравнительный анализ нового и старого дизайна (выяснить, что меняется, что добавляется, что убирается и т. д.).


2. Требования к вёрстке (DIV, table, смешанная).

2.1 Вёрстка на дивах

Худший вариант: Проекты с требованием блочной вёрстки (семантическая вёрстка с использованием DIV) выполняются кодерами, не имеющими необходимого опыта, или используется блочная вёрстка там, где она не обоснована.

Хорошая практика: Блочную вёрстку стоит применять в тех местах, где это применение обосновано (субъективное мнение), если: - необходимо соблюдение стандартов; - это единственно-возможный способ реализации; - это требования клиента или платформы; - это способ уменьшить количество багов у web-developer’oв при работе с HTML кодом; - необходимо упростить места соприкосновения клиента с кодом

Умение «верстать на дивах» (и править достаточное количество нетривиальных багов) требует наличия подобного опыта у HTML кодера.

Менее изящная, но стабильная табличная вёрстка покрывает основные запросы к вёрстке в 80% типовых задач.

Смешанная вёрстка - компромисс и способ вобрать лучшее из двух вариантов.

Влияние: Блочная вёрстка привносит вероятность несуществующих при табличной вёрстке багов, таких как: - неправильный рендер браузером; - неправильное или непредсказуемое поведение вёрстки при изменении размера окна, шрифта, размера текста и т.д.; - сложные баги кроссбраузерности.

Подобные баги исправляются достаточно сложно, часто с использованием хаков и незадокументированных возможностей. Решения не всегда кроссбраузерны, расширяемы и надёжны.

Действия: 1. PM и HTML кодер: В начале проекта обсудить вопросы, касающиеся типа вёрстки.

2 PM и HTML кодер: Воспользоваться консультантом, попросить консультации у коллег.


2.2 Требуется табличная вёрстка, а исходный материал на блочной

Худший вариант: Для редизайна проектов, которые были на табличной вёрстке клиент предоставил версию, полностью выполненную в DIV вёрстке.

Хорошая практика: Если предоставленный заказчиком материал выполнен на DIVах, а существующая реализация - на таблицах, то необходимо использовать смешанную вёрстку, а также учесть возможные проблемы адаптации при временной оценке.

Влияние: Если тип вёрстки не совпадает то, надо понимать, что переделывание на новый тип - это уже не редизайн, а фактически создание всего оформления с нуля, что в реальности приведёт к огромному количеству багов, несоответствий и непредвиденных ситуаций.

Тот же результат (создание практически с нуля, а не переделка), если заказчик прислал вёрстку не подходящую для используемой платформы.

Действия: 1. HTML кодер: Использовать смешанную вёрстку (процесса адаптации и багов на стыках двух типов не избежать, однако это минимизирует расход времени в сравнении с созданием с нуля). 2. PM: Понимать и учитывать при оценке, что в подобной ситуации дизайн не берётся как есть. Конечный результат представляет собой симбиоз прошлого решения и клиентского варианта. Любое нововведение чревато багами, множащимися в геометрической прогрессии.


3. Знание проекта (структуры папок, элементов, генерирующих дизайн).

Худший вариант: HTML кодер не знает проект.

Хорошая практика: HTML кодер знает проект.

Влияние: Незнание проекта приводит к тому, что на разбирательство с особенностями реализации системы тратится время, выделенное на выполнение самого задания. Следующая статья значительной траты времени – баги и недоделки, произошедшие из-за незнания системы (неучтённые страницы, разное отображение при разных условиях и т.д.).

Действия: 1. Рабочий процесс: Изучение используемых платформ в свободное от проектов время. Таск на ознакомление с системой перед началом проекта. Проведение обязательной аттестации на знание системы.

2. Рабочий процесс: Использовать в проекте консультанта с таском «Консультирование» (кроме этого таска он в проекте может не участвовать).

3. PM и HTML кодер: Воспользоваться консультантом, попросить консультации у коллег.


4. Степень зависимости от программно - аппаратной части.

Худший вариант: Высокая зависимость от программно- аппаратной части.

Хорошая практика: Автономная, параллельная работа.

Влияние: Примеры зависимостей, которые отражаются на времени: - зависимость от аппаратной части ПК (Photoshop (несколько одновременно открытых PSD), Dreamweaver (2-3 окна), TopStyle (2-3 открытых файла), проводник (или коммандер), 2-3 открытых браузера (FireFox, IE, Opera) и иногда программа для работы c PHP – вот вполне типовой пример рабочий области). - зависимость от аппаратной части и интернетHTML кодеру в работе требуется видеть моментальный результат своих действий, т.к. иногда вёрстка строится на предположении и результатах того, как ведёт себя дизайн в определенных изменяющихся условиях. Время ожидания результата иногда превышает время на его создание. Когда, даже чтобы увидеть результат самых небольших изменений, необходимо дождаться долгой перегрузки всей страницы (а перезагружает страницу кодер за проект достаточно много раз). - зависимость от действий программиста и программ, связанных с рабочим процессом. Несмотря на то, что SVN (и другие системы контроля версий) призвана не только сохранить код, но и распараллелить разработку, временами приходится вместо разработки возиться с обновлением SVN и восстановлением работоспособности своего хоста после обновления. Это связано с тем, что параллельный разработчик меняет что-то радикальное, скрывает или добавляет часть функциональности влияющей и на работу HTML кодера.

Действия: 1. Рабочий процесс (проектная команда): Обсудить влияние друг на друга и исходя из этого предложить порядок тасков.

2. Рабочий процесс: Приемлемые мощности ПК и скорость интернет.


5. Стадия вступления в проект.

Худший вариант: Кодер вступает в проект, когда ещё не готова часть ключевой функциональности или часть, влияющая на визуальное отображение. Возможны вмешательство или доработки в уже проработанных страницах. Остались не выясненными до конца части сайта.

Хорошая практика: Проект проходит таким образом, что кодер и девелопер работают либо параллельно, либо кодер после девелопера.

Влияние: Регрессии необоснованно забирают время, которое не может быть просчитано в начале.

Действия: 1. Рабочий процесс (проектная команда): Обсудить влияние друг на друга и исходя из этого предложить порядок тасков.

2. Рабочий процесс: Эффективные коммуникации по ходу проекта позволяют избежать регрессий или снизить их количество, избежать багов.

3. PM: Контролирует проект на промежуточных стадиях. Отсутствие контроля со стороны PM в ходе проекта выльется в регрессии, переделку и аврал в конце. Если в начале идёт девелопмент, потом кодинг и натяжка, то перед натяжкой следует проверить результаты девелопмента на соответствие требованиям спецификации и своим представлениям. Как показала практика, отсутствие этого приводит к следующим ситуациям: - время на девелопмент израсходовано, и нет возможности привлечь ресурс для доработки. Приходится отвлекать занятых на другом проекте людей. - нормальный процесс HTML кодинга нарушается. Из-за недоработок приходиться переделывать и доделывать куски проекта, по которым, как казалось, работа завершена. - авральная работа, перерасход рабочего времени, баги.


6. Коммуникации и выяснение возникающих вопросов по ходу проекта с участниками проекта.

Худший вариант: Коммуникации затруднены (между клиентом и PM или участниками команды).

Хорошая практика: С коммуникациями никаких проблем.

Влияние: Затруднение обсуждения оперативных вопросов ведёт к неоднозначному пониманию требований. Если у вас был вопрос, который вы решили самостоятельно, и его решение не совпало с видением клиента, то это приведёт к переделке => потери проектного времени.

Внутрикомандные коммуникации тоже влияют на процесс. Например, использование IM при обсуждении оперативных вопросов часто замедляет общение, т. к. некоторые вещи достаточно тяжело и долго объяснять, и также приходиться делать это сразу с несколькими людьми в нескольких окнах.

Действия: 1. Рабочий процесс: Один из неявных примеров улучшения коммуникаций - словарь рабочего сленга в Wiki. Новый сотрудник без труда может прочитать и понять используемые слова из лексикона коллег. Участники проектной команды должны проявлять инициативу в улучшении коммуникаций (использовать как логические инструменты, так и технические средства).

2. Рабочий процесс: Для проектной группы лучше использовать общий чат, где все участники проекта будут в курсе обсуждения проекта.


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

Худший вариант: Проектная команда не знает требований системы или работы компонентов, отвечающих за дизайн. Приходится переделывать под вновь узнанные требования.

Хорошая практика: Вёрстка учитывает требования системы при натяжке.

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

Пример 1: Не всегда есть возможность скачать текущую версию сайта клиента, поэтому для работы локально приходиться вырывать какие-то части и ставить их на локал. Ещё чаще приходится делать сначала локально, потом после проверки проделывать те же действия на клиенте. Незапланированное время - это повтор тех же действий на клиенте и время, потраченное на устранение разницы (закачка/скачка на/с клиента).

Пример 2: Open Source сильно подвержен ограничениям и условиям. Так в системе OsCommerce содержание категории товаров генерируется жёстко в коде, что может повлечь не только переделку HTML, но даже переделку PHP.

Действия: 1. Рабочий процесс (проектная команда): Обсудить узкие места, изучить систему до старта проекта.

2. PM и HTML кодер: Воспользоваться консультантом, попросить консультации у коллег.

3. Рабочий процесс: Конспектировать решение проблем или сами проблемы в Wiki, создавая базу знаний.


8. Квалификация и опыт. Способность идентифицировать проблему, решить и "законспектировать".

«законспектировать».=== Худший вариант: HTML кодер использует нестабильные решения, не заинтересован в улучшении качества работы, безразличен ктенденциям и техникам.

Хорошая практика: HTML кодер совершенствует технику, интересуется тенденциями. Знакомится с чужим опытом и создаёт собственные наработки.

Влияние: Опытный специалист - ключ к решению любой задачи.

Действия: 1. Рабочий процесс: Популяризировать пользу базы знаний. Культивировать и централизировать материал. Освещать и доводить до сведения, вовлекать.

2. HTML кодер: Использовать прочтённое на практике, не боятся экспериментировать, наблюдать результат. Знакомиться и изучать смежные области знаний, накапливать и синтезировать знания. Предлагать внедрение обкатанных и обдуманных вариантов.

3. HTML кодер: 70% проблем с которыми сталкиваешься в процессе работы уже решал кто-то. Задокументированное решение позволит не только не вспоминать судорожно, как это решалось в прошлый раз, но и избавить от таких мыслей коллег.


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

]]>
Google+
]]>
Личные инструменты
Хочешь еще цитату? Будьте вежливы с ботаниками. Есть шанс, что в один прекрасный день вы будете работать на одного из них.Билл Гейтс
веб-программирование
Просмотры
чтим

Deprecated: Function set_magic_quotes_runtime() is deprecated in /var/www/webproger/data/www/webproger.ru/1c6a72389c0fd92079ac7ae7cd356173/sape.php on line 218 Deprecated: Function set_magic_quotes_runtime() is deprecated in /var/www/webproger/data/www/webproger.ru/1c6a72389c0fd92079ac7ae7cd356173/sape.php on line 224

]]>
Rambler's Top100
]]>
]]>
]]>