{"id":14270,"url":"\/distributions\/14270\/click?bit=1&hash=a51bb85a950ab21cdf691932d23b81e76bd428323f3fda8d1e62b0843a9e5699","title":"\u041b\u044b\u0436\u0438, \u043c\u0443\u0437\u044b\u043a\u0430 \u0438 \u0410\u043b\u044c\u0444\u0430-\u0411\u0430\u043d\u043a \u2014 \u043d\u0430 \u043e\u0434\u043d\u043e\u0439 \u0433\u043e\u0440\u0435","buttonText":"\u041d\u0430 \u043a\u0430\u043a\u043e\u0439?","imageUuid":"f84aced9-2f9d-5a50-9157-8e37d6ce1060"}

Как вести проекты и не облажаться перед заказчиком

Я веду проекты 11 лет. За это время я научилась работать в режиме дедлайна, разбираться в новом вопросе за короткий срок и находить общий язык с разными людьми. Если вы руководите проектами, заключаете договоры, общаетесь с клиентами, скорее всего мой опыт вам пригодится.

Что сложного в управлении проектами

Любой проект начинается с понимания задачи.

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

Нельзя наспех посмотреть документацию, отправить заявку на участие накануне дедлайна и рассчитывать, что все и так сойдет. Если авиакомпания выберет поставщика в качестве победителя, а тот уклониться от заключения контракта или не выполнит договорные обязательства, то авиакомпания отправит жалобу в ФАС и поставщика объявят недобросовестным.

Отсюда универсальное правило - прежде, чем ввязываться в проект, менеджер разбирается в задаче.

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

Ситуация: мне пишет клиент и просит подготовить презентацию "до завтрашнего утра". Работа над таким проектом обречена на провал. Вот самые вероятные причины:

- я не поняла задачу и отправила заказчику не то, что он ожидал;

- я отправила презентацию за несколько минут до начала переговоров заказчика с партнерами, на встрече оказалось, что в тексте допущены значительные ошибки - заказчик взбешен;

- мы не зафиксировали договоренности по оплате и условиям работы, заказчик чего-то не услышал и оплатил только часть ожидаемой суммы;

- презентация получилась сырой и некрасивой.

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

Делю проект на этапы

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

Специалисты выделяют 7 основных моделей ведения проектов: каскадную, гибкую, итеративную, спиральную, инкрементную, «V-Model», «RAD Model». Между собой они отличаются переходом от этапа к этапу и оценкой результата в разных фазах жизненного цикла. Расскажу о трех как о самых популярных.

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

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

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

Я не буду давать рекомендации, когда нужно использовать ту или иную модель управления проектами - возможно, ваша компания вообще не задумывается, какую методологию использует и при этом успешно ведет дела и получает планируемый результат. Жизнь показывает, что эффективность инструментов доказывается эмпирическим путем и ничьи героические усилия не изменят за пару дней налаженный процесс работы.

Соблюдаю проверенные принципы

1. Изучаю задачу и пытаюсь понять "боль" заказчика.

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

3. Фиксирую договоренности: в письме, техзадании и договоре.

4. Выполняю договоренности в указанный срок. Если выполнить не получается, объясняю причины, договариваюсь о новом сроке, приношу извинения.

5. Делю работу на несколько этапов и на каждом прошу заказчика согласовать результат. Если надо, обрабатываю замечания, вношу правки.

6. Довожу начатое до конца. Мне важно, чтобы заказчик получил результат.

7. Если задание творческое, согласовываю у клиента публикацию работы в портфолио или рассказа о сотрудничестве в социальных сетях.

А какими принципами руководствуетесь вы?

0
Комментарии
-3 комментариев
Раскрывать всегда