Релиз без задержек

Проект → Релиз без задержек

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

Хочу подробней описать сам этап сдачи проекта Заказчику, какие на нем возникают трудности, самые распространенные ошибки и как можно их избежать. В нашей студии работа над проектом четко разбита на три части:

• Выяснение потребностей, анализ аналогов, создание прототипа.
• Разработка дизайна, программирование прототипа, верстка.
• Сведение верстки с прототипом. Тестирование и наполнение сайта.

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

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

Здесь мы можем столкнуться с рядом проблем:

• Синдром обманутых ожиданий. Возникает в том случае, когда заказчику изначально предоставляли мало информации о проекте, и он был вовлечен лишь в формальные согласования. Это вещь опасная в принципе, потому что порой ведет к полной потере взаимопонимания и конфликту. Об успешной сдаче проекта в срок говорить не приходится.
• Запоздалые корректировки. Когда проект готов с точки зрения разработчика, но заказчик не проверял юзаблити интерфейсов во время внутреннего тестирования. Он может начать вносить свои корректировки на финише проекта. Хотя такие корректировки носят незначительный характер (добавьте фильтр, передвиньте кнопку…) их количество может быть существенно, что затягивает релиз проекта и в свою очередь порождает новые доработки.
• Отсутствие контента на сайте на момент релиза. Заказчик начинает собирать информацию слишком поздно, у него отсутствует понимание структуры информации, а иногда и контент для сайта. Сайт в отсутствии наполнения смотрится как сдутый шарик, что может вызвать претензии о несоответствии результата дизайна. И объяснить, что вопросы наполнения и восприятия неразрывно связанны, бывает затруднительно.
• Низкая компетентность группы поддержки сайта со стороны заказчика. Сотрудники заказчика не готовы к наполнению сайта, потому не знакомы с системой управления и эта задача, как правило, откладывается на день финальной презентации. «Покажите как это работает». Как итог, группа поддержки сайта не может вести наполнение. Что в свою очередь создает у заказчика ощущение неготовности и обеспокоенности. Как следствие - задержу релиза проекта и оплаты.

Эти моменты вносят существенный временной лаг в срок сдачи проекта. Когда со стороны разработчика все готово (задачи по разработке закрыты), а сайт сдается только через месяц. Так как любая из вышеперечисленных причин или (что крайне нежелательно) все сразу имеют место быть. Что же делать, если я хочу сдаться во время? Все просто: менеджер должен руководить процессом и у заказчика, мягко направляя его действия и контролируя сроки, так как компетенция сотрудника со стороны заказчика не всегда достаточна.

Необходимо учитывать следующее:

• У проекта должен быть один руководитель, который принимает решения и отвечает за них. Заказчик должен всегда контактировать с одним человеком со стороны исполнителя. Менеджера на проекте не меняют.
• Держите заказчика в курсе проекта, представляете больше промежуточных результатов. При таком подходе Вы сможете со своей стороны быть уверенным, что все в норме, заказчик чувствует ответственность за решение. При любых разногласиях после, Вы сможет аппеллировать к тому, что результат был одобрен ранее. Так же необходимо письменно фиксировать результаты по окончанию больших этапов (Ex: Cсылаясь на утвержденное ТЗ Вы можете отклонить требования о принципиально новых разработках).
• На переговорах от заказчика также должно быть одно лицо, принимающее решение. Причем этот человек должен быть компетентен в принятии решений.
• В самом начале работ необходимо обсудить сроки начала этапов внутреннего тестирования и подготовки контетна. Составить карту контента и согласовать, кто занимается наполнением и на каких этапах. Это позволит избежать корректировок на финише проекта и наполнить сайт своевременно. Даже если заказчик не сможет подготовить контент, у него появится адекватное понимание ситуации.Это снимет ответственность с исполнителя.
• Нужно выделить время и провести инструктаж группы поддержки сайта со стороны заказчика, чтобы на момент передачи сайта не возникало вопросов. Руководство пользователя должно представлять развернутое описание функциональности, а не формальную отписку. Это поможет снять нагрузку с ваших сотрудников в будущем.
• Все взаимодействия с заказчиком и его командой должен проводить менеджер, разумеется в меру своей компетенции по конкретному вопросу. Но если вы работаете в IT, вы должны быть компетентны. Нельзя допускать конфликтов вашей рабочей команды с командой заказчика, тем более на личном уровне.

Принимая это во внимание, можно сократить временные издержки на финише проекта и сэкономить нервы. А также сделать заказчика своим постоянным клиентом.

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

Zurab

Вернуться к списку постов