Yuri Shilyaev. Blog.

Когда я разговариваю с потенциальным менеджером проекта, я всегда задаю вопрос по процессу прохождения проекта. Все хорошие менеджеры рисуют его примерно одинаково, примерно так как написано в хороших умных книжках. Вот примерно как этот процесс должен проходить:

Проект инициирован и идет полным ходом.
Некая проектная документация для него уже составлена и подходит время для отрисовки дизайна. Менеджер ставит дизайнеру задачу, а через неделю забирает 10 прекрасно нарисованных макетов страниц. Дизайнер старался как мог и потому каждый пиксель в данном дизайне продуман и поставлен на нужное место.
Дизайн передается к верстальщику, который погружаясь в код старается заверстать великолепный дизайн дизайнера с точностью до пикселя. На выходе он по документации выдает 20 заверстанных страниц.
После чего дизайн поступает программистам. Которые собирают проект и теперь это уже не просто статичный дизайн — это работающий интернет-сайт.

Казалось бы просто, но.

Когда через несколько недель после начала сборки до проекта добираются тестировщики, они хватаются за голову. В верстке обнаруживается десятки несоответствий дизайну. Баги сыплются на головы программистов и верстальщика. Следя за сборкой, дизайнер погружается в грусть все глубже и глубже, его состояние на границе отчаяния, а дизайн в забвении (как можно положить “это” в портфолио?!). Верстальщик не прекращает попыток фиксить баги, но они появляются быстрее, чем он успевает их читать.

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

Это уже не сказка из умной книги. Это жизнь.

Отчего возникает эта жуткая анархия в сражении за качество? Приведу пример основанный на верстке и дизайне. Думаю, что и программисты без труда найдут подобные же примеры.

Итак.

Когда макеты дизайнера передаются в руки верстальщика, от менеджера следует четкое руководство к действию: “Дизайн рисовал большой профессионал, он обо всем подумал, поэтому мы будем следить, чтобы заверстанные страницы были в точном соответствии с дизайном!” Верстальщик говорит “есть, сер” и начинает резать шаблоны.

Когда он встречает элемент типа:

Он пишет код что-то вроде такого:

<h1>Добро пожаловать на сайт!</h1>

h1 {
font-size: 14px;
color:#000000;
}

Но после он встречает какой-то похожий элемент, в котором, однако, есть отличия. Он помнит о том, что надо четко следовать дизайну… это решение менеджера. Поэтому встречая элемент:

Он, как хороший верстальщик, понимающий каскадную таблицу стилей добавляет новый класс к прежнему элементу:

<div class=”wrapper block“>
<h1>Восстановление пароля</h1>

div.block h1 {
font-size: 16px;
font-weight:bold;
padding:6px 0pt 4px 14px;
margin:0pt;
}

Далее код поступает к программисту. Он четко знает, что верстальщик — профессионал, и тот четко подумал о том, какие ввести стили. Если для заголовков используется h1, то значит надо везде его так и использовать. Когда ему нужно отобразить заголовок на странице он как правильный разобравшийся программист просто обрамляет заголовок тегом h1. Про класс block, который надо было поставить в этом конкретном случае он не знает. Поэтому…

Через какое-то время у верстальщика появляется баг от тестировщиков, которые резонно задают вопрос: “Почему у нас разные заголовки на страницах?”. Верстальщик мужественно проставляет забытый класс block везде где это необходимо.

История повторяется с завидным постоянством по кругу. Но уже с другими блоками, другими персонажами и стилями.

Как разорвать этот порочный круг? Думать еще не время, самое время “фигачить”… но это еще не финал.

Идет следующий виток. По ходу развития системы дизайнеру заказывают другие страницы, где неточностей и “ошибок” еще больше. Верстальщиком пишется еще один CSS код, который накладывается на прежний… но опять же в точном соответствии с дизайном. В результате 2 кода смешиваются, программисты берут любой “работающий” и верстка ввергается в анархию. Однажды, верстальщик вскакивает со своего рабочего места, вырывает клок волос и восклицает: “Это все надо срочно переверстать!”

Результатом чего становится такая ситуация?

Кто-то скажет, что недостаточно документирован процесс. Надо описывать подробно дизайн, потом описывать верстку и т.п. Поклонники стандартов тут же вспомнят про все мыслимые стандарты от W3C, которые должны исправить ситуацию, а “CSS- фреймворки только для этого и придумали”.

Да. Все это верно, но…

Есть великое правило порочного круга постоянного снижения качества:

Качество снижается на этапах передачи работы от одного сотрудника другому.

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

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

“Решения уже приняты “на верху”, где должны были исключить всяческую ошибку” — рассуждают одни разработчики. “Это не моя работа и раз верстальщик сделал так, то так и надо” — думают другие. “Не важно, что сделано уже плохо, главное, что не мной”.

Качество конечного продукта утекает на каждом этапе, как песок сквозь пальцы. QA по сути ищет ответственного за принятие решения по тому или иному грошовому вопросу. Люди, которые в принципе не должны совершать подобных ошибок начинают плодить их каждый день.

Знаете как устроены фабрики по производству обуви в той же Италии?

Идет конвейер, на нем двигаются ботинки. У каждого отдельного работника есть свой четкий участок работы. Если к нему пришел ботинок с плохо проклеенной подошвой, то он не станет приклеивать на него носок, а отложит ботинок, а потом пойдет к начальнику цеха и сообщит о браке. Что сделает “наш” работник? Приклеит носок, потому что качество… не его работа. Для этого у нас есть ОТК. ОТК проверяет в конце конвейера ботинок и выкидывает его как брак. Да от брака мы избавились, но потратили время всего конвейера. Бракованный ботинок получился очень дорогим.

Вот что я хочу сказать:

Бумажки-инструкции, четкое следование административной иерархии — это признаки слабости ума и таланта. По-настоящему талантливые разработчики должны перестать боятся брать на себя ответственность за качество своей работы и команды в целом, они имеют право наслаждаться результатами своей работы. Каждому участнику проекта, будь то верстальщик, программист, дизайнер или QA требуется принимать решения в ходе проекта . Решения на своем уровне, потому что никого выше уже нет. В результате качество проекта будет являться отражением профессиональных решений и профессиональной принципиальности всей команды проекта.

ЗЫ. Люди, которые еще не постигли профессионального дао следует обращаться к своим старшим товарищам за советом.