Управление проектами. Обработка отраслевой экономической информации на железнодорожном транспорте График сотрудничества с заказчиком

1.1. Взаимодействие с Заказчиками (Основные функции)

1.1.1. Поиск заказов

7.2.3.1. По вопросам информации о продукции

1.1.2. Преддоговорная работа с Заказчиком

Регламентирующие документы

2.2.1.2.1. Преддоговорная работа с Заказчиком СТП-1-01

Требования к системе менеджмента качества ИСО9000:2000 Раздел 7

7.2.1.1. Требования потребителя относительно продукции, включая требования к готовности, доставке и поддержанию

7.2.2.4. Определение возможности достижения соответствия определенным требованиям

// Анализ требований к продукции / Процессы, связанные с потребителем / РЕАЛИЗАЦИЯ ПРОДУКЦИИ

1.1.3. Формирование Технического задания

Регламентирующие документы

2.2.1.2.2. Порядок анализа и заключения контракта СТП-2-01 // Стандарты предприятия предприятия Эллат (СТП) / Документы системы менеджмента качества / Внутренние нормативные документы / Регламенты

Требования к системе менеджмента качества ИСО9000:2000 Раздел 7

7.2.1.2. Требования, не установленные потребителем, но необходимые для предназначаемого или установленного применения // Определение требований потребителя / Процессы, связанные с потребителем / РЕАЛИЗАЦИЯ ПРОДУКЦИИ

7.2.1.3. Обязательства, связанные с продукцией, включая обязательные требования и положения законодательства // Определение требований потребителя / Процессы, связанные с потребителем / РЕАЛИЗАЦИЯ ПРОДУКЦИИ

// Анализ требований к продукции / Процессы, связанные с потребителем / РЕАЛИЗАЦИЯ ПРОДУКЦИИ

7.2.2.2. Подтверждение требований потребителя до их принятия, если потребитель не предоставляет письменного изложения требований // Анализ требований к продукции / Процессы, связанные с потребителем / РЕАЛИЗАЦИЯ ПРОДУКЦИИ

7.2.2.3. Выяснение изменений требований контракта или заказа, отличающихся от ранее представленных (например, при торгах или ссылках) // Анализ требований к продукции / Процессы, связанные с потребителем / РЕАЛИЗАЦИЯ ПРОДУКЦИИ

7.3.1.1. Определение стадий процессов проектирования и/или разработки

7.3.2.2. Применимые законодательные и обязательные требования

7.3.2.3. Применимые данные, полученные от подобных предыдущих разработок // Входные данные для проектирования и разработки / Проектирование и разработка / РЕАЛИЗАЦИЯ ПРОДУКЦИИ

7.3.2.4. Другие требования, важные для проектирования и разработки // Входные данные для проектирования и разработки / Проектирование и разработка / РЕАЛИЗАЦИЯ ПРОДУКЦИИ

7.3.4.1. Оценка возможности выполнения требований

1.1.4. Заключение Договоров

Регламентирующие документы

2.2.1.2.3. Положение о договорной работе с Заказчиком (СТП-3-01) // Стандарты предприятия Эллат (СТП) / Документы системы менеджмента качества / Внутренние нормативные документы / Регламенты

1.1.5. Контроль за выполнением договорных обязательств

Регламентирующие документы

2.2.1.2.3.2. Порядок анализа изменений и внесения изменений в Договорные документы // Положение о договорной работе с Заказчиком (СТП-3-01) / Стандарты предприятия Эллат (СТП) / Документы системы менеджмента качества / Внутренние нормативные документы / Регламенты

2.2.1.2.4.1. Процедура обработки жалоб и претензий Заказчика

2.2.1.2.4.2. Процедура устранения замечаний Заказчика // Положение о корректирующих и предупреждающих действиях (СТП-4-01) / Стандарты предприятия Эллат (СТП) / Документы системы менеджмента качества / Внутренние нормативные документы / Регламенты

Требования к системе менеджмента качества ИСО9000:2000 Раздел 7

7.2.3.2. Обработка запросов, контрактов, заказов, включая изменения // Связь с потребителем / Процессы, связанные с потребителем / РЕАЛИЗАЦИЯ ПРОДУКЦИИ

1.2. Планирование работ по проектам (Основные функции)

1.2.1. Уточнение состава комплекса и объемов разработки

Регламентирующие документы

// Стандарты предприятия Эллат (СТП) / Документы системы менеджмента качества / Внутренние нормативные документы / Регламенты

Требования к системе менеджмента качества ИСО9000:2000 Раздел 7

7.2.2.1. Определение требований к продукции // Анализ требований к продукции / Процессы, связанные с потребителем / РЕАЛИЗАЦИЯ ПРОДУКЦИИ

1.2.2. Планирование обеспечения качества проекта

Регламентирующие документы

2.2.1.2.5. Состав и порядок разработки программы обеспечения качества проекта (СТП-5-01) // Стандарты предприятия Эллат (СТП) / Документы системы менеджмента качества / Внутренние нормативные документы / Регламенты

Требования к системе менеджмента качества ИСО9000:2000 Раздел 7

7.1.1. Установление целей по качеству для продукции, проекта или контракта

7.1.3. Определение действий по проверке и утверждению и критерии приемлемости // Планирование процессов реализации / РЕАЛИЗАЦИЯ ПРОДУКЦИИ

7.2.2.5. Фиксация результатов анализа и последующих прослеживающих действий (см. п.5.5.7) // Анализ требований к продукции / Процессы, связанные с потребителем / РЕАЛИЗАЦИЯ ПРОДУКЦИИ

7.3.1.2. Определение действий по анализу, проверке и утверждению для каждой стадии проектирования и/или разработки // Планирование проектирования и разработки / Проектирование и разработка / РЕАЛИЗАЦИЯ ПРОДУКЦИИ

1.2.3. Формирование частных технических заданий на разработку составных частей комплекса

Регламентирующие документы

2.2.1.2.7. Технология реализации проектов. Этапы и порядок проведения работ (СТП-7-01) // Стандарты предприятия Эллат (СТП) / Документы системы менеджмента качества / Внутренние нормативные документы / Регламенты

1.2.4. Планирование работ по проекту

Регламентирующие документы

Требования к системе менеджмента качества ИСО9000:2000 Раздел 7

7.1.2. Определение потребности в установлении процессов и документации, обеспечении ресурсами и инфраструктурой, специфичными для продукции // Планирование процессов реализации / РЕАЛИЗАЦИЯ ПРОДУКЦИИ

1.2.5. Координация и оперативный контроль выполнения работ

Регламентирующие документы

2.2.1.2.4.3. Процедура корректирующих действий // Положение о корректирующих и предупреждающих действиях (СТП-4-01) / Стандарты предприятия предприятия Эллат (СТП) / Документы системы менеджмента качества / Внутренние нормативные документы / Регламенты

2.2.1.2.6. Положение о планировании работ (СТП-6-01) // Стандарты предприятия Эллат (СТП) / Документы системы менеджмента качества / Внутренние нормативные документы / Регламенты

Требования к системе менеджмента качества ИСО9000:2000 Раздел 7

7.3.4.2. Выявление проблем и выработка предложений о прослеживающих действиях // Анализ проектирования и разработки / Проектирование и разработка / РЕАЛИЗАЦИЯ ПРОДУКЦИИ

7.3.7. Управление изменениями проектирования и разработки

1.3. Разработка конструкторской, программной и эксплутационной документации (Основные функции)

1.3.1. Разработка документации на аппаратную часть комплекса

Регламентирующие документы

2.3.3.3. План работ для отдела разработки и производства аппаратного обеспечения

1.3.2. Разработка программной части комплекса

Регламентирующие документы

2.3.3.4. План работ для отдела разработки и производства программного обеспечения // Программы и планы мероприятий / Организационно-распорядительные документы компании / Регламенты

1.3.4. Анализ и утверждения результатов проектирования

Регламентирующие документы

Требования к системе менеджмента качества ИСО9000:2000 Раздел 7

7.3.3.1. Соответствуют входным требованиям проектирования и разработки

7.3.3.2. Предоставляют надлежащую информацию для операций по производству и услугам (см. п.7.5) // Выходные данные проектирования и разработки / Проектирование и разработка / РЕАЛИЗАЦИЯ ПРОДУКЦИИ

7.3.3.4. Определяют характеристики продукции, являющиеся существенными для ее безопасного и надлежащего применения // Выходные данные проектирования и разработки / Проектирование и разработка / РЕАЛИЗАЦИЯ ПРОДУКЦИИ

7.3.5.1. Соответствие выходных данных входным требованиям // Проверка проектирования и разработки / Проектирование и разработка / РЕАЛИЗАЦИЯ ПРОДУКЦИИ

7.3.6. Утверждение результатов проектирования и разработки // Проектирование и разработка / РЕАЛИЗАЦИЯ ПРОДУКЦИИ

Обучение, Развитие, Тренинги

Ключевые слова:

1 -1

Итак, с чего начинаются взаимоотношения с клиентом ?

Как приходит клиент? Либо он сам обращается, либо нам кто-то рекомендует его, как компанию, которая хочет автоматизироваться.

С чего мы начинаем? Мы не бросаемся к телефону сразу договариваться о встрече - мы начинаем собирать информацию об этой компании .

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

Для чего это нужно? Для эффективной работы, чтобы на основании полученной информации выработать тактику первоконтакта.

Потом происходит первоконтакт . На нем мы, в первую очередь, выясняем :

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

Установление взаимоотношений

Второй этап - это установление отношений с клиентом :

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

Результатом этого этапа является предварительное решение о работе с данным клиентом и формирование положительного образа в глазах клиента.

Хочу остановиться на формировании положительного образа. На основе собранной первоначальной информации мы решаем, кому из наших сотрудников можно доверить представлять нашу фирму на первой встрече с клиентом. Это очень важный момент. Например, если мы отправим на первоконтакт прекрасного специалиста, но у него серьга в ухе, набриолиненный «кок» и т. д., то клиент может посмотреть и сказать: «да ну его!» Такое бывает. Или, например, пришел аккуратненький, подстриженный, в костюме с галстуком, но мальчик лет 20. И клиент смотрит и говорит: «Это же мальчишка, о чем с ним говорить? Как с ними работать - они меня совсем не уважают, прислали ко мне мальчишку!». Поэтому сбор этой информации нужен в том числе и для того, чтобы понимать, кому доверить первоконтакт и как себя вести контактеру, как выстраивать легенду, как преподносить себя.

Выявление лиц, принимающих решения

Следующий очень важный вопрос - это выявление лиц, реально принимающих решения (так называемые ЛПР). Этот этап состоит из двух пунктов:

Выясняется , кто принимает решения по нашему проекту.
И второй пункт - выявляются лица, влияющие на ЛПР .
Что это значит? Например, известно, что решения в компании принимает генеральный директор, а еще у него есть финансовый директор и бухгалтер. Это может быть бухгалтер, который выполняет все, что скажет директор, и сидит тихо в уголочке, а может быть и наоборот, бухгалтер, который говорит директору, что надо сделать вот так и директор его слушается. И если мы изначально выявили, что этот человек имеет влияние на своего директора, то это - наш козырь, следовательно, нужно попытаться установить отношения именно с этим бухгалтером. Я условно сказал, что это бухгалтер - им может оказаться кто угодно (например, начальник отдела продаж или какой-то зам, которому полностью доверяет генеральный директор или собственник компании). Надо устанавливать отношения именно с лицом, влияющим на лицо принимающее решения.

Цель, как вы уже видите, - это выявление ЛПР. И результат - это список ЛПР и лиц, влияющих на ЛПР.

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

Установление партнерских отношений

Следующий этап - установление партнерских отношений .

Мы изначально делаем акцент на двусторонней ответственности : даже в договоре, если это возможно, прописываем не Заказчик-Исполнитель, а «Первая сторона » (это Заказчик) и «Вторая сторона » (это Исполнитель). Правда, иногда какие-то крупные госструктуры говорят, что юридический отдел им этого не разрешает, потому что документы проверяет казначейство, Минфин и прочии. В этом случае мы прописываем стандартные формулировки - «Заказчик и Исполнитель». Но если есть возможность, то - «Первая» и «Вторая сторона».
Всеми силами мы пытаемся донести, что это - совместная работа. Руководители с обеих сторон выступают, как высокие договаривающиеся стороны - именно они решили сделать этот проект автоматизации. Для реализации этого проекта они набирают команду, состоящую как из сотрудников первой стороны, такииз сотрудников второй стороны - это так называемая «Объединенная рабочая группа », которая и делает проект. Естественно, каждая сторона вкладывает в проект свои ресурсы: материальные, технологические, методологические, финансовые - потому что, в общем-то, речь идет о достаточно больших проектах.
Работу объединенной рабочей группы контролирует «Объединенная наблюдательная комиссия» - это высший контролирующий орган, обычно состоящий из топ-менеджмента обеих сторон.
И расписывается ответственность каждой стороны , чтобы сотрудники заказчика понимали, что за проект отвечаем не только мы, но и они. Мы тратим очень много сил и времени, чтобы донести до клиента то, что мы делаем этот проект вместе с его сотрудниками, и что от и от их работы напрямую зависит с каким качеством и особенно, в какие сроки будет выполнен проект.

Ну и результатом этого этапа является фиксация (формальная или неформальная) отношений равных партнеров:

Формальная фиксация - это договор.
А неформальная - это могут быть какие-то служебные документы, в которых мы всегда стараемся прописывать «Первую и Вторую сторону» и их отношения.

Информирование Заказчика о технологии ведения проекта

Следующий этап - это информирование заказчика о технологии .

На крупных проектах у нас, в обязательном порядке, есть «Курс лекций и семинаров по введению в проектную технологию ». В этом курсе лекций мы доводим до сотрудников заказчика, как будет происходить весь процесс проекта:
- Как делается проект по нашей технологии?
- Кто за что отвечает?
- Кто что делает?
- Для чего делаются те или иные действия?
- Для чего нужен тот или иной документ? Что он дает обеим сторонам? (чтобы сотрудникам стало понятно, что партнерские отношения дают преимущества не только нам, но и заказчику).
- При каждом удобном случае мы информируем ЛПР обо всех возникающих в ходе работы проблемах . Для этого у нас есть ряд специальных ежедневных документов - например, «Дневник контактов» или «Ведомость отклонений». И пусть не ежедневно, но через каждые несколько дней руководство заказчика должно с ними знакомиться. А поскольку, как правило, сразу находятся отговорки: был занят, не читал и прочее, то, соответственно, об этом надо постоянно напоминать, может быть, даже смоделировать какие-то ситуации, заставляющие руководство читать эти документы.

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

Организация отношений с Заказчиком

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

Контракт-менеджер - это «плохой». Это может быть отдельный человек или кто-то из топ-менеджеров. Чаще всего функцию контракт-менеджера выполняет руководитель проекта (если он, конечно, в состоянии это сделать). Это человек «Нет» - он может прийти к лицу принимающему решения, и сказать: «у нас по контракту написано вот так, а вы сейчас делаете по-другому, и из-за этого возникает отклонение. Давайте разбираться». Он всегда указывает на недостатки, на несоблюдение технологии, призывает соблюдать документацию - поэтому он всегда «плохой».
А объект-менеджер - это «хороший». Это человек, у которого в силу разных причин сложились хорошие отношения с лицом принимающим решения от заказчика. Может быть, он просто оказался ему симпатичен. Или, например, у них есть какие-то связи (родственные, клановые, дружеские - какие угодно). Главное, что клиент к нему расположен.
Объект-менеджер у нас фактически ведет этот объект. Обратите внимание, это не проект-менеджер, это специальный человек, который занимается тем, что поддерживает хорошие отношения с руководством заказчика , и, когда возникают какие-то острые проблемы, он их сглаживает.
Например, после того, как контракт-менеджер выговорил клиенту о несоблюдении каких-то условий наших договоренностей (это может закончиться, в общем-то, каким-то нелицеприятным для нас разговором), приходит объект-менеджер и начинает успокаивать клиента.
Я не зря сказал, что объект-менеджер называется «хорошим». Обычно говорят, что «хороший парень» - не профессия. Но у нас это профессия. Объект-менеджер - это «хороший парень». Он может не быть специалистом-профессионалом ни в чем, но с ним клиенту хорошо - он пришел, поговорил с ним (может быть, о политике, о футболе и т.п.), и клиенту стало хорошо, у него изменилось отношение. Клиент до этого собирался нам что-то выговаривать, за что-то нас наказывать, но теперь он уже все понимает, ему вообще неудобно с нами плохо говорить.
Вот это - функция объект-менеджера. Он закрепляется за каждым достаточно серьезным клиентом.

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

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

Организация проектных процессов

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

Мониторинг хода проекта;
И принятие управленческих решений по результатам мониторинга.

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

Иногда убедить заказчика работать по нашей технологии бывает очень сложно. Например, у нас был один клиент - очень крупная ИТ-компания. Причем она сама занималась автоматизацией на MS Navision, но в силу определенных причин решила позвать нас, чтобы мы их автоматизировали на 1С. Так вот, работа с ними была настоящим кошмаром - плакали все, и менеджеры, и программисты. Потому что это была очень крупная компания (мы по сравнению с ними мелкие), и они считали, что они все знают, и пытались нас учить. Они постоянно говорили: «ребята, вы не так все делаете, есть же такая-то технология, вы должны делать так». Естественно, это происходило только на уровне среднего звена, руководитель (который был основным собственником и генеральным директором компании), конечно, все прекрасно понимал, и после его вмешательства все решалось, но его очень трудно было достать. А на уровне среднего звена были постоянные проблемы, постоянные попытки научить.

Мы на каждом проекте, в обязательном порядке, стараемся донести до клиента мысль о том, что в своем бизнесе он профессионал (и мы туда, естественно, не лезем), а в вопросах автоматизации - мы профессионалы, поэтому нам надо доверять, и не пытаться указывать нам, что и как делать. Тем более, если нам не просто указывают, а пытаются нас заставить: «давайте сделаем по-другому, потому что я так хочу». Вот эти вещи мы сразу стараемся пресечь. Конечно, «пресечь» - это громко сказано, во всяком случае, постараться достаточно мягко объяснить. Если уж мы согласились на этот проект, решили, что нас он устраивает, ввязались в эту «битву», то теперь, естественно, приходится с этим работать.

Ограничение желаний клиента

Следующий этап - это ограничение желаний клиента . С этим, наверное, сталкивались все (когда начинаются так называемые «хотелки» - еще, еще и еще). Здесь мы поступаем достаточно просто:

Например, когда клиент говорит, что в отведенные рамки бюджета и сроки надо еще сделать вот это и вот это, то начинается достаточно порой, сложная процедура объяснений, как все это работает . Мы напоминаем клиенту о том, что у нас с ним заложен бюджет, выделены люди (объединенная рабочая группа), каждая сторона проекта вкладывает свои ресурсы. Поэтому если возникает дополнительная работа, то требуются дополнительные часы, дополнительные люди. Откуда их брать?
Или если клиент задерживает проект, то и наши, и его люди простаивают, а им платятся деньги. Откуда брать эти ресурсы? Я уже не говорю о том, что эти люди не просто получают зарплату, но и приносят какую-то прибыль компании. Естественно, компания не хочет терять эту прибыль. Достаточно подробно клиенту объясняется, и клиент обычно очень хорошо реагирует.
Мы разъясняем, даем подробную цифровую раскладку - откуда, что, до копеечки. И говорим, что если вы хотите, чтобы мы сделали еще и вот это , то - пожалуйста, это займет столько-то часов, и их надо оплатить . В конце концов, клиент с нами соглашается и либо отказывается от своей "хотелки", либо оплачивает дополнительные часы. Конечно, бывает по-разному - я сейчас немного идеализирую картину.

Здесь я хочу привести еще один пример взаимоотношений. Мы работали с одной очень крупной компанией (они уже были на этапе обслуживания), и там периодически возникали какие-то задания на доработки: например, сделать какой-то мудреный отчет или еще что-то. И вот, главный бухгалтер компании нам поручил определенную работу, и мы ее сделали. А когда пришло время расплачиваться, он сказал: «В общем-то, я ошибся, это все нам совсем не нужно». Но работа-то была сделана, следовательно, надо было заплатить. А он говорит: «Нет, я за это платить не буду, я же не могу пойти к президенту компании и объявить ему, что я дурак, и заказал не то, что нужно». Причем, компания была очень крупная, нефтяная, отношения были хорошие и с ней, и с этим человеком. И мы не стали настаивать - не платит, так не платит. Хотя, из-за этого мы потеряли по тем временам достаточно большую для нас сумму денег (это был 2004 год). В конце года была деноминация (азербайджанский манат отбрасывал нули). И для всех клиентов, которые были у нас на обслуживании, мы делали этот перерасчет в рабочем порядке - никаких дополнительных денег. А вот к этому бухгалтеру (на тот момент с того случая прошло буквально меньше года), мы подошли и сказали: «Помните, вы нам не заплатили? Мы тогда пошли вам навстречу. А сейчас - деноминация. Давайте мы сделаем это небесплатно?» Без вопросов - мы выписали счет, он оплатил.

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

Кто занимается объяснением этого бюджета :

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

Обычно, если цифры расписываются очень подробно, тогда этой раскладки и её объяснения бывает достаточно.

Сдача работ

Сдача работ. Здесь, в общем-то, больших проблем обычно не бывает, потому что процедура сдачи работ у нас очень подробно прописана в соответствующих документах .

Но на этом этапе элемент неформальности (хорошее отношение ), конечно, также облегчает жизнь и нам, и заказчику тоже.

Цель этого этапа - добиться сдачи работ в полном соответствии с правилами, установленными в соответствующих документах, которые являются приложением к договору, подписанному и клиентом, и нами. Соответственно, всегда можно предъявить, что есть такие правила.

Постпроектные взаимоотношения

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

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

Почему это произошло? Потому что не было неформальных взаимоотношений. Мы тогда только что разработали свою технологию проектной документации, и это был клиент, на котором вся эта технология, в полной красе, была продемонстрирована. И когда мы спросили у заказчика: «Хорошо, вы с нами не будете работать - а есть ли какие-нибудь претензии к нам?» И нам сквозь зубы со злостью было сказано: «В том-то и проблема, что никаких претензий мы предъявить не можем - что вам ни скажи, у вас на все есть бумажка, и мы ничего не можем сделать. Нас так не устраивает, и больше мы с вами работать не будем. Другие компании можно попросить что-то сделать дополнительно, а вы отказываетесь - вот у вас бюджет, вот у вас так положено, вот срок. Шаг в сторону - и вы тут же показываете нам бумажку с нашей подписью».

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

Данная статья написана по материалам доклада, прочитанного автором на Конференции Инфостарта IE 2014 29-31 октября 2014 года.

Приглашаем вас на новую конференцию .

Великолепные мероприятия. Технологии и практика event management. Шумович Александр Вячеславович

Процедуры взаимодействия с Клиентами

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

– регистрацию, подтверждение участия. Детально продумайте, как Клиент может сообщить о своем решении участвовать в вашем мероприятии (почта, телефон, факс, сайт, лично) и при помощи чего (анкета, звонок, покупка билета…);

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

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

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

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

(Текст из буклета Eventum)

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

«Если вы желаете направить на мероприятие группу сотрудников, мы будем рады обсудить специальные условия и предоставить вам скидку.

Если вы предпочтете добраться в пансионат самостоятельно, пожалуйста, проинформируйте нас об этом и сообщите номер вашего автомобиля».

Из книги Компетентность в современном обществе автора Равен Джон

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

Из книги Большая книга директора по персоналу автора Рудавина Елена Роленовна

6. З. Документационное обеспечение процедуры аттестации – Только я вам ее не отдам. Потому что у вас документов нету. Мультфильм «Трое из Простоквашино» В перечне документов для аттестации есть составляемые руководителем структурного подразделения отзыв или

Из книги Покажите мне деньги! [Полное руководство по управлению бизнесом для предпринимателя-лидера] автора Рэмси Дэйв

Из книги Настольная книга по внутреннему аудиту. Риски и бизнес-процессы автора Крышкин Олег

Из книги Салон красоты: от бизнес-плана до реального дохода автора Воронин Сергей Валентинович

Активные восстанавливающие процедуры Реафирмирующий (укрепляющий) массаж лицаМассажная методика основана на воздействии на мимические и другие морщины, восстановление тонуса и тургора всех слоев тканей. Массаж построен на технике глубокого локального разминания,

Из книги Управленческая элита. Как мы ее отбираем и готовим автора Тарасов Владимир Константинович

Новшество. Процедуры от GUINOT Процедура «Hydradermie Lift»Целый час отдыха и блаженства для вашей кожи!Долгие лабораторные исследования института GUINOT воплотились в поистине уникальную процедуру Hydradermie lift. Результат – разглаживание мимических морщин и мгновенный омолаживающий

Из книги Развитие потенциала сотрудников. Профессиональные компетенции, лидерство, коммуникации автора Болдогоев Дмитрий

3.10 Эволюция конкурсной процедуры За первым городским конкурсом профессионального мастерства молодых организаторов производства последовали другие. Как городские, так и отраслевые. Появились новые деловые игры и виды заданий. Менялся способ подсчета результатов.

Из книги Практика управления человеческими ресурсами автора Армстронг Майкл

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

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Подобные документы

Аналитический обзор целевой аудитории. Создание и заполнение базы данных с помощью Microsoft Access. Разработка интерфейса и функций рабочей области. Построение форм. Функциональные требования к приложению. Его тестирование по методике чёрного ящика.

дипломная работа , добавлен 09.11.2016

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

дипломная работа , добавлен 20.12.2015

Характеристика деятельности, структуры и функций агентства. Анализ текущей структуры сайта заказа наружной рекламы. Описание функциональной архитектуры и архитектуры данных проектируемого автоматизированного модуля. Проектирование интерфейса пользователя.

дипломная работа , добавлен 22.07.2015

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

дипломная работа , добавлен 27.10.2017

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

курсовая работа , добавлен 20.04.2012

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

дипломная работа , добавлен 03.05.2012

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

дипломная работа , добавлен 19.01.2017

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

Именно для этого случая была придумана методология управления проектами Agile.

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

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

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

Должностные обязанности руководителя отдела разработки

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

Зарплатные предложения и требования работодателей

Среднее зарплатное предложение для руководителя отдела разработки в Москве составляет 150 000 руб., в Санкт-Петербурге - 117 000 руб., в Волгограде - 66 000 руб., в Воронеже - 75 000 руб., в Екатеринбурге - 100 000 руб., в Казани - 75 000 руб., в Красноярске - 90 000 руб., в Нижнем Новгороде - 70 000 руб., в Новосибирске - 85 000 руб., в Омске - 75 000 руб., в Перми - 85 000 руб., в Ростове-на-Дону - 75 000 руб., в Самаре 75 000 руб., в Уфе - 75 000 руб., в Челябинске - 84 000 руб.

Соискатели, впервые претендующие на должность руководителя отдела разработки, должны иметь высшее образование (профильное или техническое), опыт создания программного обеспечения не менее 3 лет. Обязательно знание принципов объектно-ориентированного программирования и методологии разработки ПО (RUP, MSF), необходимы навыки работы с СУБД. Работодателями приветствуется знание нескольких языков программирования. Стартовый оклад начинающих руководителей отделов разработки в Москве составляет от 70 000 до 110 000 руб., в Санкт-Петербурге – от 55 000 до 86 000 руб., в Воронеже и Перми – от 35 000 до 55 000 руб.

Город	Уровень дохода, руб. (без опыта работы на данной позиции)
Москва	70 000 - 110 000	- Высшее образование (техническое / IT) - Знание одного или нескольких языков программирования - Понимание принципов объектно-ориентированного программирования - Знание методологии разработки ПО (RUP, MSF) - Знание английского языка на уровне чтения технической документации - Опыт работы с СУБД - Опыт работы в области разработки ПО от 3 лет Портрет соискателя в 1 диапазоне
Санкт-Петербург	55 000 - 86 000
Волгоград	30 000 - 48 000
Воронеж	35 000 - 55 000
Екатеринбург	47 000 - 74 000
Казань	35 000 - 55 000
Красноярск	42 000 - 66 000
Нижний Новгород	33 000 - 52 000
Новосибирск	39 000 - 62 000
Пермь	35 000 - 55 000
Омск	40 000 - 63 000
Ростов-на-Дону	35 000 - 55 000
Самара	35 000 - 55 000
Уфа	37 000 - 55 000
Челябинск	40 000 - 62 000

От кандидатов с опытом управления отделом разработки более 1 года работодатели ждут прежде всего развитых организаторских и руководящих навыков. Требования вакансий касаются наличия опыта планирования, организации и реализации проектов, разработки технической документации, а также навыков использования инструментальных средств управления проектами. Претенденты на соответствующие вакансии в столице могут рассчитывать на зарплату до 140 000 руб., в городе на Неве – до 109 000 руб., в Воронеже и Перми – до 70 000 руб.

Город	Уровень дохода, руб. (с опытом работы от 1 года)	Требования и пожелания к профессиональным навыкам
Москва	110 000 - 140 000	- Развитые организаторские и управленческие навыки - Навыки по планированию, организации и реализации проектов - Навыки использования инструментальных средств управления проектами - Навыки разработки технической документации Портрет соискателя во 2 диапазоне
Санкт-Петербург	86 000 - 109 000
Волгоград	48 000 - 62 000
Воронеж	55 000 - 70 000
Екатеринбург	74 000 - 94 000
Казань	55 000 - 70 000
Красноярск	66 000 - 84 000
Нижний Новгород	52 000 - 66 000
Новосибирск	62 000 - 78 000
Пермь	55 000 - 70 000
Омск	63 000 - 80 000
Ростов-на-Дону	55 000 - 70 000
Самара	55 000 - 70 000		Уфа	55 000 - 70 000	Челябинск	62 000 - 78 000

Дополнительное образование в сфере IT и опыт постановки полного цикла разработки – таковы наиболее типичные требования к соискателям со стажем управления разработками более 2 лет. Заработок, на который могут рассчитывать такие специалисты, в компаниях столицы достигает 175 000 руб., Санкт-Петербурга – 137 000 руб., Воронежа и Перми – 88 000 руб.

Город	Уровень дохода, руб. (с опытом работы от 2 лет)	Требования и пожелания к профессиональным навыкам
Москва	140 000 - 175 000	- Дополнительное образование в сфере IT - Опыт постановки полного цикла разработки (от ТЗ до сдачи проекта в эксплуатацию) Портрет соискателя в 3 диапазоне
Санкт-Петербург	109 000 - 137 000
Волгоград	62 000 - 77 000
Воронеж	70 000 - 88 000
Екатеринбург	94 000 - 117 000
Казань	70 000 - 88 000
Красноярск	84 000 - 105 000
Нижний Новгород	66 000 - 82 000
Новосибирск	78 000 - 98 000
Пермь	70 000 - 88 000
Омск	80 000 - 100 000
Ростов-на-Дону	70 000 - 88 000
Самара	70 000 - 90 000
Уфа	70 000 - 88 000
Челябинск	78 000 - 100 000

Наиболее высокие зарплаты предлагают руководителям отделов разработки крупные предприятия. Такие работодатели требуют от кандидатов опыта работы в организациях сходного размера не менее 3 лет. Компании, имеющие зарубежных партнеров, отдают предпочтение специалистам, свободно владеющим английским языком. Зарплатный максимум в Москве достигает 300 000 руб., в Санкт-Петербурге – 235 000 руб., в Воронеже и Перми – 150 000 руб.

Город	Уровень дохода, руб. (с опытом работы от 3 лет)	Требования и пожелания к профессиональным навыкам
Москва	175 000 - 300 000	- Опыт управления разработками в структуре крупной компании от 3 лет Возможное пожелание: знание английского языка на разговорном или свободном уровне Портрет соискателя в 4 диапазоне
Санкт-Петербург	137 000 - 235 000
Волгоград	77 000 - 130 000
Воронеж	88 000 - 150 000
Екатеринбург	117 000 - 200 000
Казань	88 000 - 150 000
Красноярск	105 000 - 180 000
Нижний Новгород	82 000 - 140 000
Новосибирск	98 000 - 170 000
Пермь	88 000 - 150 000
Омск	100 000 - 170 000
Ростов-на-Дону	88 000 - 150 000
Самара	90 000 - 150 000
Уфа	88 000 - 150 000
Челябинск	100 000 - 170 000

Портрет соискателя

Среди соискателей должности руководителя отдела разработки большинство составляют мужчины средних лет с высшим образованием. Представительниц слабого пола среди претендентов всего 5%, что является типичным для IT-сферы. 58% соискателей – специалисты в возрасте от 30 до 39 лет. 96% руководителей отделов разработки имеют высшее образование. Каждый третий соискатель свободно владеет английским языком.

Код для вставки в блог

Руководитель отдела разработки

Навыки управления проектами – такое требование часто встречается в вакансиях для руководителей отдела разработки. На деле за этими словами может скрываться намного больше, чем кажется на первый взгляд. ");