Статья к конференции WhaleRider (http://www.whalerider.ru/, выступление 24 сентября 2012 года).

1. Ольга Павлова
www.pavlova.cc
Качество продукта через
управление проектом: что
конкретно делать менеджеру?
Рассмотрим немножко теории — и даже теорий — про качество продуктов и
процессов. Поймём, почему они не имеют никакого отношения к нашей суровой
действительности. Поймаем себя на умолчаниях, душащих качество, и подумаем,
как избавиться от этих вредных привычек. Обсудим, как и что нужно делать на
каждом этапе проекта, чтобы дальше не было мучительно больно. Выявим в
команде борцов за качество и отличим их от недовольных нытиков. Да, и не
скажем, наверное, ни слова о тестировании релизов.
Немного теории для сомневающихся
Раз вы задались вопросом «Как сделать хорошо?» — значит, у вас есть как
минимум один ответ на вопрос «Как, собственно, вообще сделать?». И обычно этот
ответ материализуется как смесь управленческих теорий, жизненного опыта и
волшебных заклинаний.
Опыт и заклинания оставим на сладкое, а сейчас — о самом простом: о теориях.
Давайте сначала инвентаризуем теории, претендующие на управление качеством:
1. Всеобщее управление качеством (TQM). Главная идея: нужно повышать не
только качество продукции, но и качество производственных процессов.
Основной инструмент: развитие персонала, минимизация количественных
показателей и принятие всех решений с ориентацией на качество процесса и
результата.
2. Шесть сигм. Главная идея: нужно минимизировать брак на каждом этапе
производства через уменьшение статистических отклонений ключевых
параметров производственных процессов. Основной инструмент: сквозное и
непрерывное измерение всего, что можно измерить, и поощрение инициатив,
уменьшающих вероятность и величину отклонений от нормы.
http://www.pavlova.cc Страница 1

2. 3. Бережливое производство. Главная идея: нужно минимизировать
производственные потери (деятельность, потребляющую ресурсы, но не
создающую потребительской ценности). Основной инструмент: плавные
производственные процессы без перепроизводства (система «точно вовремя»).
4. Теория ограничений (TOC). Главная идея: нужно повышать скорость генерации
прибыли и уменьшать связанный капитал через подчинение темпа всех
производственных процессов возможностям самого узкого места системы.
Основной инструмент: установление прямой связи локальных показателей
эффективности с двумя глобальными (скорость генерации прибыли и связанный
капитал).
5. Ассоциированная система менеджмента качества. Главная идея: сюрприз-
сюрприз, научно-техническую деятельность тоже можно стандартизировать на
макроуровне. Основной инструмент: стандарт ISO 9000.
Много букв, правда? На самом деле не то чтобы это важные буквы. Вы можете
легко их проигнорировать. Просто вдруг вам для подтверждения собственной
интуиции нужны красивые слова и авторитетные имена — а тут вот, пожалуйста, и
то, и другое в ассортименте, наслаждайтесь.
Особо интересно поискать противоречия между всеми этими заслуженными и
популярными системами. Самых очевидных два:
1. «Всеобщее управление качеством» минимизирует использование
количественных показателей, а «Шесть сигм» — полностью на них опирается.
2. «Теория ограничений» борется с локальными показателями эффективности, а
для «Шести сигм» они жизненно необходимы.
Да, вы правы, автор недолюбливает «Шесть сигм» — но причиной тому весьма
субъективный жизненный опыт. Так или иначе, теории действительно друг другу
противоречат, и при внедрении всё равно придётся думать своей головой.
Вернёмся к нашему желанию найти ответ на вопрос «Как сделать хорошо?» в
конкретном случае конкретной компании. Кажется, что ответ должен быть
развитием ответа на вопрос «Как сделать?». То есть, например, если вы работаете
по Scrum, но результат получается «на троечку», то нужно магически улучшить
Scrum с помощью, например, «Теории ограничений» — и «троечка» превратится в
«пятёрку с плюсом».
На самом же деле связи между этими ответами нет. То есть когда мы начинаем
говорить о качестве, перед нами появляется просто другой класс управленческих
задач, никак не соотносящийся со «сделать вообще». И поэтому эволюции, скорее
всего, не случится: чтобы сделать хорошо, привычные методы и практики придётся
подчинять новым схемам, и это безболезненно не пройдёт.
http://www.pavlova.cc Страница 2

3. Качество — объект управления
Переформулирую мысль предыдущего абзаца: какая бы производственная
культура ни сложилась в вашей компании, повышение её качества — сложная
управленческая задача.
Остановлюсь подробней на этой неприятности. Мы привыкли, что
производственный процесс устраивается как-то сам собой. Ну правда, достаточно
определить цель и упорно к ней идти, чтобы рано или поздно, так или иначе — таки
дойти. Героическими авралами, силой интеллекта лидеров разработки, харизмой
менеджеров и вливаниями инвесторов — так или иначе проекты обычно доживают
до технического запуска.
Поэтому о том, как идёт проект, особо никто не задумывается. Ну, у кого-то иногда
случается внезапное озарение и часть проектных работ формализуется,
регламентируется и шаблонизируется. Обычно такие формализованные процессы
быстро умирают за ненадобностью, особенно на небольших проектах. Лучшая тому
иллюстрация — тотальное нежелание всех участников рабочей группы всерьёз
планировать работы и придерживаться плана проекта.
Проект закончен, языки у всех на плече, «мы пахали», мы герои, победителей не
судят. В следующий раз идём примерно так же — тропинка уже протоптана. И в
следующий, и в следующий… Так складывается производственная культура.
Итак, доминирует аврально-героический метод формирования производственной
культуры. А теперь подумайте — можно ли таким методом улучшить качество?
Качество продуктов, производственных процессов, информационного обмена,
маркетинговой поддержки и т.д.? Если компания создана по принципу «Бросили в
воду — и плыви», то пловцам уже не до красивого стиля: им бы не захлебнуться и
добраться до берега. Не скажу, что все компании такие, но IT — подавляющее
большинство.
Что ж, мы поняли, что улучшения качества снизу — не будет. А значит, придётся
улучшать сверху.
Мамочки, куда я попал?
Улучшать сверху — это не значит, что мы садимся ровно и ждём сигналов от
начальства. Но это значит, что менеджер выбирает систему управления качеством
— и ставит внедрение этой системы выше своих хотелок.
Иначе говоря, первый шаг менеджера к качеству: нужно для себя решить, что
система управления качеством важнее авральной самореализации и «ориентации
на результат».
Результат, повторюсь, и без менеджера никуда не денется. Так уж в IT заведено,
что люди в подавляющем большинстве действительно хотят добиться результата и
сделать свою работу. Убить это желание и развалить проект ещё до технического
http://www.pavlova.cc Страница 3

4. запуска — надо здорово постараться, умельцы редки и ценятся на вес акций
Facebook'а.
Таким образом, дело менеджера — внедрять систему управления качеством.
Здорово повезло, если эту задачу хоть как-то поддерживает начальство. Лучше
всего, если у этого начальства есть своё видение идеала, отличное от «Хочу, чтобы
было, как у Apple/Google/Volvo». Тогда дальше можете не читать — выясняйте, что
это за видение, и работайте над воплощением :)
Вторая по степени везения ситуация — когда уровень производственной культуры
в компании держится на нескольких перфекционистах. Каждый из них в
отдельности может легко свести с ума нетерпеливого и поверхностного
менеджера. Но в целом они транслируют в пространство — и наглядно
демонстрируют в работе — простой принцип: работать надо хорошо. С плеч
менеджера благодаря этим людям падает безумная пропагандистская задача:
доказывать, что тема качества вообще достойна внимания. Перфекционисты-
разработчики борются с халтурщиками своими методами (о которых лучше нежным
управленцам не знать) — прям санитары леса, носите их на руках. Платить за это
счастье придётся подстройкой своих управленческих воздействий под ценных
перфекционистов. Впрочем, это того стоит.
Но обычно менеджер остаётся с проблемой один на один. Нужно, чтобы было
хорошо, но как — решай сам, дорогой. А пока ты решаешь, мы будем работать, как
привыкли: кто-то хорошо, кто-то спустя рукава. Нормальная ситуация в российских
реалиях с их слабой методической культурой и высоким уровнем пресловутой
«ориентации на результат».
А что делать, что делать-то?
Вариантов внедрения системы управления качеством, по большому счёту, два:
эволюционный и революционный.
Революционный — проще некуда: составляем себе стройную схему «Как я буду
контролировать и повышать качество», согласовываем с начальством и внедряем.
Проще всего взять какую-нибудь из вышеперечисленных теорий, слегка
адаптировать под IT и дальше придерживаться её с упорством школьника, вчера
прочитавшего про ООП. Не работает, но весело и все при деле.
Эволюционный, на мой взгляд, несколько эффективней:
1. Вытаскиваем из теорий и практик все принципы и рекомендации по повышению
качества, в которые вы — лично вы — верите.
2. Выбираем какую-нибудь практику, которую можно применить здесь и сейчас.
3. Практикуем в безопасном месте и смотрим, что получилось.
4. Если выглядит убедительно — внедряем конкретно эту практику повсеместно.
http://www.pavlova.cc Страница 4

5. 5. Выбираем следующую практику — и далее по циклу.
Самое сложное здесь, конечно, в том, что за эволюционным методом не стоит
никаких авторитетов и никакого опыта. Всё будет происходить на ваш страх и
риск. Фактически вы строите карточный домик на фундаменте своего авторитета
(и занудства). И никто не даст гарантию, что очередная выбранная ко внедрению
практика не вызовет цепной реакции и не порушит всё, что вы сделали до этого.
Интересно, что оба способа основаны на вере в необходимость решения вопроса
качества управленческими методами. И самое главное, что вам придётся сделать
— поверить в то, что качество важно.
Членам религиозных конфессий (в частности, владельцам iPhone) поверить во что
угодно проще: так сказать, навык уже есть. Атеистам и андроидофилам — трудней,
хотя тоже возможно. Но да, увы, логика тут не работает: первым делом надо стать
адептом религии качества.
Чёрт, какая незадача: мы чуть не забыли, что работаем в IT. Кругом сплошная
логика, аналитика, аргументация и объективность. При чём тут вера? Да какое
значение имеют эмоции для того, чтобы работать в этой почти научно-технической,
левополушарной отрасли?
И тут мы возвращаемся к тому, что, казалось бы, стоило обсудить в самом начале
статьи. К вопросу о том, что такое качество.
Дело в том, что восприятие качества — крайне субъективно. Можно долго искать
(а найдя — даже и использовать) способы численно замерить какие-то отдельные
параметры некоторых составляющих процесса, проекта и продукта. Но в
результате же всё равно всё сводится к простому: нравится или нет, хочу или не
хочу, радует или бесит?
Психологи-экспериментаторы давно показали: люди не способны принимать
решения на основе фактов. Для каждого — даже самого маленького! — решения
нужны эмоции. И чем важней решение — тем меньше в нём логики и больше
эмоций.
Решение о качестве — это решение «хорошо—плохо». Вы хотите, чтобы кто-то
(пользователи, покупатели, начальство, акционеры, журналисты) оценили качество
вашей работы как «хорошо». Это значит, что вы хотите управлять эмоциями
людей.
А это невозможно делать механически, без вкладывания души. Невозможно.
Вам нужно, чтобы все участники проекта (а также его сторонники и противники вне
проектной команды) вложили в работу душу. А как насчёт вашей души? То-то и
оно.
Так что да, первый шаг безумно не-IT-шный — надо поверить.
Для тех, кто ещё не убеждён, привожу альтернативный аргумент. Британские
учёные :) доказали, что управление тем лучше, чем острее фокус менеджера на
http://www.pavlova.cc Страница 5

6. объекте управления. А для того, чтобы в условиях стресса, гонки и постоянных
помех внимание менеджера не соскальзывало с выбранного нами объекта
управления (то есть качества), нужно, чтобы менеджер был к этому объекту
эмоционально привязан. Для чего нет лучше способа, чем вера.
Как поверить в качество?
Прошу тех, кто уже верит, не пропускать этот раздел. Вдруг вера ваша слаба :)
Допустим, вы считаете, что качество вашего продукта на приемлемом уровне. Как
избавиться от этого досадного заблуждения? Вот несколько простых методов:
1. Почитайте, что люди пишут о вашем продукте. Невыразимо просветляющее
упражнение — пара дней работы в техподдержке. Чуть менее травматично, но
тоже неплохо — походить по форумам и блогам.
2. Постойте за плечом пользователя. Можно взять новичка, можно — матёрого
пользователя. Посмотрите, что человек делает и что он не делает.
Поспрашивайте о его обычных задачах в продукте, посмотрите, как он их
решает.
3. Сами станьте пользователем. Речь не о рассматривании интерфейса, а о
реальном использовании системы. Покупайте, пишите, публикуйте, считайте —
если, конечно, можете. В интернет-проектах это обычно несложно. Не
ограничивайтесь online-задачами — например, в интернет-магазине совершите
покупку целиком, а не просто до кнопки «Заказать».
4. Пользуйтесь конкурентами. Это поможет не только увидеть ваши слабые
стороны, но и, наоборот, начать больше ценить сильные. Кстати, и удержит от
поломки якобы никому не нужной (а на самом деле критически важной людям)
функциональности.
Ой, как будет неприятно. Вы будете ругать пользователей — мол, какие они
идиоты. Вы будете игнорировать то, что вам кажется несущественным — а потом
эти мелочи объединятся и станут грызть вашу совесть долгими зимними вечерами.
И поначалу вы будете действовать как робот — но мало-помалу у вас появятся
чувства, эмоции, нормальные человеческие ощущения.
Вот! Поймали! Эмоции и ощущения. Это ровно то, что нам надо: вы наконец смогли
почувствовать, что ваш продукт есть нечто большее, чем логика программы и
ограничения бизнес-процессов. Более того, вам станет в заметной степени
наплевать на «объективные причины» — желание сделать хорошо заглушит все
доводы в пользу того, что это, дескать, невозможно.
Поздравляю. Вы поверили в то, что качество — важно. И теперь готовы влиять на
это качество конкретными управленческими действиями.
Небольшой нюанс: упражнение нужно повторять непрерывно. Поддержка этой
веры — ваша ежедневная работа. А искушений отречься будет изрядно (не стоит,
http://www.pavlova.cc Страница 6

7. знаете ли, недооценивать могущество императора). Так что: пользуйтесь своим
каждый день, рассматривайте чужое раз в неделю, читайте пользовательские
отзывы раз в месяц — и говорите с людьми при каждой возможности.
Вредные привычки
Ну а теперь, наконец, самое вкусное: практические рекомендации. Начнём с
простого — попробуем искоренить свои собственные вредные привычки.
Вот они, эти враги — и методы борьбы с ними:
1. Маркетинговое мышление.
Как выглядит: решения принимаются на основе оценки потребности
большинства; штучные (пусть и экспрессивные) жалобы пользователей
игнорируются; мелкие детали интерфейса не прорабатываются; минорные баги
не чинятся.
Что делать: осознать, что пользователям наплевать на большинство; испугаться
шума в блогах из-за одной, но очень некрасивой ошибки; выработать в себе
уважение к каждому (!) пользователю.
2. Ложь при планировании.
Как выглядит: сроки реализации конкретной задачи навязываются сверху без
учёта возможностей производства.
Что делать: не подписываться под сроками, если ощущаете давление;
согласовывать сроки с производством; регламентировать процедуру
согласования сроков.
3. Отсутствие сдачи-приёмки.
Как выглядит: факт сдачи задачи автоматически означает в глазах
исполнителя её приёмку; возврат на доработку воспринимается как личное
оскорбление.
Что делать: планировать итерации сдачи-приёмки; оперативно выкатывать
список недоработок к исправлению.
4. Озадачивание без контроля.
Как выглядит: задача выдана, но её реализация не проконтролирована;
разборки задним числом вида «А я ещё в мартобре просил тебя сделать».
Что делать: считать контроль исполнения отдельной задачей; ставить
напоминалки; вести учёт в списке дел.
5. Электронная почта.
Как выглядит: заметная часть рабочего времени уходит на электронную почту;
участие в малозначимой переписке; подробные письменные обсуждения; прочая
имитация бурной деятельности.
Что делать: проверять электронную почту не чаще раза в час; вести отдельный
список дел.
6. Много букв в документации.
Как выглядит: солидная пачка бумаги названа «техническим заданием»; никто
http://www.pavlova.cc Страница 7

8. не сверяется с документацией в процессе разработки.
Что делать: не вести документацию; ставить задачу в формате прототипов
интерфейса; не описывать очевидное; ключевые требования умещать на 1-2
страницы A4.
7. Устное целеполагание.
Как выглядит: цели проекта «всем известны», но короткого описания — нет.
Что делать: составить и согласовать документ — обоснование проекта.
8. Игнорирование идиотов.
Как выглядит: странные запросы людей, не имеющих отношения к проекту (но
имеющих влияние в компании), спускаются на тормозах.
Что делать: общаться с ними (обычно они хотят только общения); согласовывать
их хотелки с генеральным заказчиком; найти способ повлиять на их точку
зрения и воспользоваться этим способом.
9. Сокрытие информации.
Как выглядит: работа идёт, но для того, чтобы составить себе впечатление о
происходящем, людям со стороны нужно проявить инициативу и
поинтересоваться.
Что делать: индивидуально активно информировать ключевых сотрудников;
направо и налево рассказывать о проекте.
10. Нерегулярный current state.
Как выглядит: встречи рабочей группы проводятся от случая к случаю.
Что делать: жёстко зашить встречи в календарь; приглашать на встречи
заказчика; письменно фиксировать и публиковать резюме встречи.
11. Невнимание к инициативам.
Как выглядит: предложения рядовых исполнителей игнорируются или
встречаются «в штыки».
Что делать: предлагать исполнителям развить тему (регламентировать, сделать
пробный вариант, провести презентацию или анализ рынка); рассказать об уже
существующих попытках решить задачу и предложить включиться в процесс.
12. Поощрение посредственности.
Как выглядит: плохо сделанная работа принимается из-за недостатка внимания
или времени.
Что делать: отправлять на доработку со списком замечаний; заказывать работу
двум исполнителям одновременно.
13. Невнедрение.
Как выглядит: исполнитель сделал «срочную» работу, которая после этого
попала в длинную очередь на публикацию или внедрение.
Что делать: пользоваться методикой kanban (заказывать только то, что можно
будет сразу опубликовать или внедрить).
14. Микроменеджмент.
Как выглядит: слишком частый контроль прогресса, слишком детальные
инструкции.
http://www.pavlova.cc Страница 8

9. Что делать: детальные инструкции выдавать только после того, как стало ясно,
что самостоятельно исполнитель не найдёт способ решить задачу на должном
уровне качества.
15. Серьёзность.
Как выглядит: агрессивная пропаганда «важности и нужности» решаемых
задач.
Что делать: шутить над продуктом; закладывать «пасхальные яйца» для своих.
16. Недоверие.
Как выглядит: пренебрежительные высказывания о результатах чужого труда и
о возможностях исполнителя в целом.
Что делать: претензии, если они есть, высказывать без обобщений («ты
всегда»), максимально конкретно и конструктивно.
Активности по этапам
В предыдущем разделе мы, как положено порядочным управленцам, начали с себя.
Но рано или поздно придётся перейти к изменению организации труда рабочей
группы проекта. Проще всего коррекция идёт, если её синхронизировать с типовым
производственным процессом, уже принятым в вашей компании.
Все интернет-проекты обычно идут по одной и той же схеме (как бы нам с вами ни
хотелось думать иначе). Этапы этой схемы можно обозначить, например, так:
1. Формирование идеи (созревание проекта, оформление сделки, предоплата).
2. Старт (выделение ресурсов и предварительное планирование).
3. Аналитика (бизнес-требования, анализ рынка, техническая постановка).
4. Проектирование (интерфейс, дизайн, тексты).
5. Разработка (покомпонентное программирование, интеграция, вёрстка).
6. Тестирование (функционал, нагрузки, бета).
7. Запуск (внутренняя презентация, вывод в свет, PR, обработка feedback'а).
8. Сдача в эксплуатацию (доработки, регламентация, сдача-приёмка, обучение,
оплата).
Конечно, эти этапы отнюдь не идут аккуратно след в след, а наоборот, как хотят
заползают друг на друга в произвольном порядке. Обычно это невинное, в
сущности, явление природы приравнивают чуть ли не к стихийному бедствию: мол,
раз всё так запутано и идёт не по порядку, то и планировать работы не нужно и
контролировать их качество не получится.
Это немножко неправда. Смотрите, какая разница, в какой последовательности
идут работы, если они в любом случае должны быть сделаны? Ну вам правда, что
http://www.pavlova.cc Страница 9

10. ли, важно, что разработка начнётся до фиксации бизнес-требований? Вы же не
бросите бизнес-требования на полдороги — они же всё равно нужны в более-менее
цельном виде, правда?
Да, но при чём тут качество? Дело в том, что фокусировка на качестве
промежуточных результатов — один из самых простых (хотя и не единственный)
способ управлять качеством процесса. Особенно в интернет-проектах: ведь
каждая задача (даже монструозная разработка какого-нибудь универсального
движка) либо невелика, либо её можно разбить на несколько задач помельче.
Но ведь важно ничего не пропустить! Все подзадачи, которые нам предстоит
делать на проекте, должны быть учтены могучим ураганом хотя бы в момент
старта. Составить достаточно детальный список задач (план без дат и
взаимозависимостей) — первый шаг к такому учёту.
Какие задачи включать в этот список, а какие нет? Вспомним про качество. Мы
управляем качеством? Да. Значит, список задач (зародыш плана) должен нам
помочь управлять качеством? Тоже да. А какой у менеджера вообще арсенал
инструментов управления? Очень небольшой: менеджер умеет ставить задачи и
принимать результат их исполнения.
Мда, негусто. Но зато на раз-два помогает разобраться, какие задачи нужно учесть
в плане. Ровно те, которые вы собираетесь ставить — и которые будете
принимать. Не больше, не меньше.
Несколько примеров:
1. Тестирование конкретного кейса может быть задачей из плана — если вы
хотите лично проконтролировать, что он работает. А может и не быть — если
это второстепенный кейс, и таких у вас 300 штук уйдёт в отдел тестирования.
2. Прототипирование главной страницы сайта — всегда задача из плана: вы
намучаетесь и с постановкой, и со сдачей-приёмкой. А вот прототипирование
страницы «Наши банковские реквизиты» — почти никогда: сделают, и ладно.
3. Запуск как таковой (включение сайта) — всегда задача из плана. А проведение
пресс-конференции — скорее стихийное бедствие, что тут запланируешь.
Итак, список задач есть. А теперь начинается самое интересное. Как вы
собираетесь контролировать качество их реализации? Есть несколько методов:
1. Повысить качество постановки. Не объём, а качество. Возьмите личную
ответственность за то, чтобы постановка соответствовала вашим ожиданиям:
напишите, проверьте, согласуйте и т.п.
2. Делегировать задачу. Когда за дело отвечает «отдел» — туши свет. Когда за
это же дело отвечает конкретный сотрудник отдела — начинаются чудеса.
Никто, кроме самых уж отморозков, не хочет делать свою работу плохо. Значит,
всё, что в ваших силах — дать работе хозяина. Конечно, так, чтобы хозяин
захотел эту работу выполнить и был горд результатом — но обычно тут дело
нехитрое.
http://www.pavlova.cc Страница 10

11. 3. Спланировать сдачу-приёмку. Никакую работу нельзя сдать с первого раза,
всегда возникают подводные грабли. Планируйте не сами грабли, а итерации их
выявлений: первый вариант — обсуждение — список багов — второй вариант —
… — последний (обычно третий) вариант. На всё это уходит время — но мы же
о качестве?
4. Явно подтверждать окончание задачи. Поставили точку в бизнес-
требованиях — всё, поставили. С этого момента все дополнительные хотелки не
падают автоматом на голову несчастных исполнителей, а становятся вашим
личным геморроем: отметайте, защищайте, обещайте вторую версию, но
держите ответственность за эту поставленную точку. Не факт, что получится,
но надо пытаться.
Вот такая работа с планом. Не безумно сложная, но требующая изрядного
занудства. И понимания: вы боретесь за каждую запятую сейчас — не потому, что
вам так нравится, а потому что только равномерно обеспеченное качество
процесса приведёт к приемлемому результату.
Давайте теперь вернёмся к основным этапам и перечислим ключевые задачи
менеджера, исполнение которых приведёт к повышению качества и процесса, и
продукта:
1. Формирование идеи
1.1. Явно и письменно зафиксировать обоснование проекта: что, зачем и с
какими ограничениями делается.
2. Старт.
2.1. Явно и письменно согласовать имена заказчика и руководителя проекта.
2.2. Письменно составить список задач проекта (зародыш плана).
3. Аналитика.
3.1. Провести презентацию решений конкурентов.
3.2. Лично прочитать и обсудить техническую постановку.
3.3. Явно и письменно составить портрет целевой аудитории.
3.4. Письменно зафиксировать пользовательские ожидания (хотя бы список).
3.5. Требовать коротких документов, не принимать тома постановки.
4. Проектирование (интерфейс, дизайн, тексты).
4.1. Отделить проектирование интерфейса от дизайна.
4.2. Лично сверить интерфейс и дизайн с пользовательскими ожиданиями.
4.3. Лично прочитать все тексты.
http://www.pavlova.cc Страница 11

12. 4.4. Прогнать все тексты через корректуру.
4.5. Наладить контроль работы дизайнера со стороны проектировщика.
5. Разработка.
5.1. Каждые 2-3 дня выяснять current state по разработке.
5.2. Поддерживать постановку в актуальном состоянии.
5.3. Лично отсматривать вёрстку перед отправкой в тестирование.
6. Тестирование.
6.1. Лично прочитать и обсудить постановку на тестирование.
6.2. Индивидуально презентовать бету каждому ключевому бета-тестеру.
6.3. Изолировать разработчиков от дискуссий с бета-тестерами (это не самый
однозначный совет, но я стараюсь так делать).
7. Запуск (внутренняя презентация, вывод в свет, PR, обработка feedback'а).
7.1. Сообщить все публичные даты проектной команде, напоминать регулярно.
7.2. Лично живьём объяснить ключевым представителям заказчика процедуру
запуска.
7.3. Участвовать в обработке feedback'а.
7.4. Хорошие новости о запуске сообщать проектной команде.
7.5. Публично поблагодарить проектную команду (если возможно, каждого
индивидуально).
8. Сдача в эксплуатацию (доработки, регламентация, сдача-приёмка, обучение,
оплата).
8.1. Не забыть про этот этап :)
Конечно, есть и другие практические действия, специфичные для вашего
производственного процесса. Вы сами легко их назовёте. Но всех их объединяет
одно: личный контроль менеджера за процессом и результатом работы.
При должном упорстве и вере в светлое будущее, как и было выше сказано,
производственный процесс рано или поздно подчинится внедряемой вами системе
управления качества.
http://www.pavlova.cc Страница 12

13. Поддержка единомышленников
Ваши единомышленники — это люди, которым нравится делать свою работу
хорошо. То есть большинство.
Вы же с ними на одной стороне баррикад, правда?
А значит, надо быть готовым на кое-какие компромиссы:
1. Поверьте, они правда лучше знают. Особенно разработчики. Довольно часто
менеджеры пытаются влезть в дебри разработки. Наверное, для того, чтобы
почувствовать проект «на кончиках пальцев», ощутить сопричастность к
физическому, так сказать, процессу производства. Управлять скучно и
неприятно — то ли дело руками самому что-то делать. Но знаете, не надо.
Лучше сказать: «Ты лучше знаешь то-то и то-то, а я не понял, поясни,
пожалуйста».
2. Им нужно время. Много времени. Ужас в том, что о времени спрашивают не их,
а вас. И велик соблазн прогнуться и пообещать что-нибудь красивое. Нет. Ваша
работа — не прогибаться в этом вопросе. Поверьте, ускорение производства
начинается отнюдь не с повышенных обязательств (жаль, что тут нет
возможности подробней раскрыть эту тему).
3. Виноватых нет. Если вдруг кому-то и где-то придёт в голову искать виноватых
— соблазнительно свалить всё на исполнителя. Хорошая затея, но
деструктивная: очень расхолаживает, убивает инициативу и желание работать
вообще. Решайте сами, как сделать так, чтобы исполнители не попадали в
виноватые. Подсказка: кругом масса кандидатов.
4. Помогайте договариваться. Исполнителям трудно договариваться даже друг с
другом. А уж с отделом маркетинга… Ищите ростки недопонимания и
устраняйте их всеми силами. Как только контакт налажен — отходите в
сторону, без вас разберутся.
5. Пропагандируйте. Вообще-то обычно в небольшой компании и так всем
известно, кто трудяга, а кто лентяй. Но лишний раз порекламировать чудо-
сотрудника окружающим (особенно директорам) — дело хорошее. Вам ведь
нужно, чтобы ваши единомышленники набирали авторитет. А вот ругать — это
уже не работа, а политика, занимайтесь ею на свой страх и риск.
Интересно, что люди, которые хотят работать хорошо, больше всего на свете ценят
обратную связь. А в обратной связи — конструктивные предложения, которые
помогают им сделать лучше и эту конкретную, и все дальнейшие аналогичные
задачи.
Самый прекрасный подарок, который вы им можете сделать — это помочь
научиться работать лучше. Поэтому не скупитесь на обратную связь и искреннюю
благодарность за хорошо выполненную работу.
http://www.pavlova.cc Страница 13

14. Вот и всё на сегодня. За скобками осталось довольно много нюансов.
Как, например, увязать вопросы качества с вечной нехваткой времени?
Что делать с криворукими уродами (а такие встречаются)?
Можно ли материально поощрять тех, кто хорошо работает?
Есть ли всё-таки способы количественной оценки качества?
Но знаете, все эти вопросы как-то сами собой решаются, если сделать главное.
Так что о них, наверное, в следующий раз — когда вышеописанное станет для вас
набором отскакивающих от зубов банальностей :)
http://www.pavlova.cc Страница 14