Заказчик и Исполнитель – взаимоотношения как основа успеха проекта

Публикация № 357540

Методология - Управление проектом

35
У себя в компании мы считаем, что очень серьезная доля успеха проекта – это все-таки взаимоотношения с заказчиком. Однако, как мне кажется, на нашем рынке не очень много компаний уделяют внимание выстраиванию системы взаимоотношений. Многие используют в своей проектной работе различные технологии: кто-то использует более формальные подходы, кто-то – более гибкие (тот же Agile и т.п.). Во всех этих технологиях большое внимание уделяется качеству разработки – как разработать, как создать проект. А вот взаимоотношения с заказчиком – как само собой пойдет. У нас в компании системе взаимоотношений уделяется очень большое внимание – и именно об этом я хочу рассказать.

Выстраивание взаимоотношений на начальном этапе

 

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

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

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

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

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

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

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

 

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

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

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

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

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

  

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

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

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

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

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

 

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

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

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

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

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

 

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

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

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

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

 

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

 

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

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

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

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

 

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

 

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

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

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

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

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

 

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

 

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

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

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

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

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

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

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

 

Сдача работ

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

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

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

 

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

 

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

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

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

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

 

******

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

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

35

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо
1. support 4454 11.06.15 23:28 Сейчас в теме
Доклад супер! Столько инсайдов в одном месте!
4. UR1 95 12.06.15 12:27 Сейчас в теме
2. CheBurator 3399 12.06.15 03:36 Сейчас в теме
да, все хорошо.
осталось непонятно кто делает проект. кто конкретно ВКАЛЫВАЕТ над каждой конкретной проблемой. Не обсуждает ее, не решает в какие сроки ее разрулить, а кто конкретно работает. ;-) Пока что фигурировали только топ-менеджеры, руководители проекта, контракт-менеджеры, объект-менеджеры и прочие "менеджеры". Поэтому справедливо, когда клиент считает что и лям - это много, а "автор" рассчитывает на 3-5 лямов... ;-)

так же было бы интересно услышать - каково примерно распредление ресурсов на проекте на решение организационно-административных зи технических задач...
5. UR1 95 12.06.15 12:36 Сейчас в теме
(2) CheBurator,
Тема была про взаимоотношения. А проект делает объединенная рабочая группа (ОРГ). Об этом есть в предыдущей статье.
По поводу 5 или 1 миллиона, я говорил об адекватности восприятия клиента. Есть рынок, цену можно легко проверить.
По поводу распределения ресурсов. Не так просто измерить, т.к. люди выполняющие какие-то административные функции на одном проекте (объект-менеджер), одновременно могут быть консультантами, аналитиками или программистами на другом проекте. Кроме того, это зависит от масштаба проекта. На маленьком проекте, многие административные функции не рациональны. На большом проекте на административные функции может уходить более 10% ресурсов.
khomichevskaya; +1 Ответить
7. CheBurator 3399 12.06.15 14:42 Сейчас в теме
(5) Ответ ни о чем. Мы не говорим о куче проектов. Мы говорим об одном проекте. У проекта есть бюджет. Есть ресурсы. Интересно было бы знать какова в проекте доля ресурсов, приходящаяся на решение административно-организационных задач и собственно на техническое вопрлощение проекта.
9. UR1 95 12.06.15 18:24 Сейчас в теме
(7) CheBurator,
От 3 до 20. Зависит от масштаба проекта.
Хотя все равно не очень понятно. Если на проекте сам руководитель пишет код и проч. Затраты на него считать административными или техническими?
3. genayo 12.06.15 10:05 Сейчас в теме
Ну да, главное не качество продукта, а качество впаривания..
6. UR1 95 12.06.15 12:37 Сейчас в теме
(3) genayo,
Впарить можно один раз. А у нас много клиентов приходит по рекомендации заказчиков.
8. genayo 12.06.15 15:17 Сейчас в теме
(6) Спорный вопрос. Зачастую уровень топменеджеров таков, что они даже не поймут, что им "впарили" продукт с неадекватным соотношением цена/качество, и вполне себе будут довольны и не будут отговаривать других от использования этого продукта. Впрочем, допускаю, что это не ваш случай.
10. UR1 95 12.06.15 18:28 Сейчас в теме
(8) genayo,
Не сталкивались. Обычно это всего лишь вопрос времени, когда именно до руководства дойдет (или им объяснят) что им "впарили".
11. Yashazz 2855 17.06.15 11:41 Сейчас в теме
А проект делает объединенная рабочая группа (ОРГ).

Не смог удержаться: лучше бы это назвать ОПГ - объединённая программистская группа))) Точнее раскрывает суть)

Если по теме - то присоединяюсь к вопросам и вообще взгляду ЧеБуратора на сие.
12. UR1 95 17.06.15 14:05 Сейчас в теме
(11) Yashazz,
ОРГ это не только программисты. Лет 15 назад, мы тоже думали, что главное - это классные программисты и тогда все будет хорошо.
По-моему, на вопросы ЧеБуратора я ответил.
13. &rew 7 18.06.15 14:51 Сейчас в теме
Статья интересная. 5 копеек, если позволите.
Первая сторона - вторая сторона, спорный момент. Путаница будет. Да и приоритеты расставлять, кто первый кто второй как то не комильфо.
Двустороння ответственность в любом договоре предусмотрена, на то он и договор, а не челобитная.
По поводу "Плохой - хороший полицейский" полностью согласен. Схема рабочая, сам использую.
Ставить заказчика на место, мягко, это тоже нужно. Это про то, что начинают учить как работать, особенно веселит, если этим занимается бухгалтер со словами "Чё там отчет делать, из ёкселя скопировать и всё...". Бывает и такое.
По поводу "хотелок", людям нужно объяснять, что это выходит за рамки изначального проекта/тех.задания. Кто везет на том и едут.
Если проект удался, и заказчик доволен результатом, но недоволен что не получилось вас "поюзать", ну его нафиг, неадекват какой-то.
П.С. Структура статьи - просто образец. Прочитав один раз, дальше достаточно по выделенному пробежаться чтобы восстановить статью в памяти.





khomichevskaya; support; +2 Ответить
14. UR1 95 18.06.15 22:29 Сейчас в теме
(13) &rew,
Первая и Вторая стороны - это чистая психология, попытка уравнять. Позиция Заказчика: я плачу деньги и вы будете делать, что я хочу. К счастью, не всегда, но часто. Пока путаницы не возникало. И еще - это, то на что обращается внимание, отход от стандарта.
Да, нужно объяснять про рамки ТЗ, но и с той стороны тоже пытаются объяснять.
Да, неадекват, но компания очень большая и очень известная и кроме обслуживания могли бы быть еще проекты...
О структуре статьи - даже как-то неожиданно. Спасибо!

Оставьте свое сообщение

См. также

Незакрытый проект на 1000 часов 62

Статья no Нет файла Россия Бесплатно (free) Управление проектом

История о незакрытом проекте, о бессонных ночах, о попытках его выгрести, о бесплатной работе, о вселенской боли.

19.09.2019    6929    ogroup    153       

Стратегия выживания в корпоративных войнах 47

Статья no Нет файла Бесплатно (free) Управление проектом

Айтишникам сложно строить карьеру управленца. И все потому, что в их «техническое ДНК» не заложено умение справляться с окружающими их интригами. Однако, поскольку это навык, это можно исправить, считает ИТ-директор в ПАО «Светлана». На конференции Infostart Event 2018 он поделился с коллегами, что и как надо делать, чтобы не погрязнуть в корпоративных интригах и сделать так, чтобы они не мешали выполнению основной работы.

16.09.2019    4099    GSoft    14       

Мастер-класс СППР 39

Статья Программист Руководитель проекта Нет файла Бесплатно (free) Управление проектом СППР

Сергей Наумов, в прошлом разработчик подсистемы бюджетирования в конфигурации «1С:ERP», на мастер-классе конференции INFOSTART EVENT 2018 EDUCATION поделился опытом управления проектами с помощью «1С:Системы проектирования прикладных решений» и показал, как использовать эту программу в работе над разными задачами: для сбора, классификации и хранения требований; для управления разработчиками и консультантами; в качестве системы документирования; в качестве баг-трекера на этапе опытно-промышленной эксплуатации.

30.08.2019    3272    SergeyN    4       

Быстрый старт: минимальный набор автоматизации типовых процессов 21

Статья no Нет файла 1С:Франчайзи, автоматизация бизнеса Бесплатно (free) Управление проектом

Автоматизация дает множество преимуществ бизнесу, но в то же время ее выгода может быть настолько несущественной, что процесс принесет компании больше убытков, чем прибыли. С чего начать эффективную автоматизацию, какие процессы стоит автоматизировать на первом этапе, а какие – лучше оставить на потом, рассказала руководитель разработки систем учета компании «Едадил» Екатерина Золотарева.

16.08.2019    3707    Hissin    18       

Как заработать миллион или История успешного сотрудничества 45

Статья Программист Нет файла Бесплатно (free) Управление проектом

Многие мечтают один раз что-то создать, а потом жить на заработанные деньги до конца своих дней. Но миллионерами становятся не все, их единицы. Среди них – разработчик Андрей Карпов. Человек, который сумел за полтора года заработать 2 миллиона рублей чистой прибыли, поделился с гостями конференции Infostart своими секретами.

05.08.2019    4098    karpik666    77       

Бизнес-аналитика с помощью Power BI 65

Статья Руководитель проекта Нет файла Бесплатно (free) Управление проектом

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

11.07.2019    6357    pbazeliuk    18       

Управление проектами по автоматизации бюджетирования 35

Статья Бизнес-аналитик Руководитель проекта Нет файла УУ Финансовый учет и бюджетирование (FRP) Бесплатно (free) Управление проектом

Автоматизация бюджетирования позволяет максимально эффективно планировать ресурсы предприятия и управлять масштабированием компании. Как учесть особенности бюджетирования, встроить его в процессы стратегического планирования, чтобы получить гибкий инструмент управления и аналитики, рассказал Сергей Наумов на конференции INFOSTART EVENT 2018 EDUCATION.

28.06.2019    3194    SergeyN    1       

Внедрение решений: как выполнять все обязательства в срок в условиях ограниченных ресурсов 22

Статья Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Многие менеджеры вынуждены работать в условиях многоклиентской среды с ограниченными ресурсами. И вовремя сдавать проекты в таких условиях сложно. Как добиться того, чтобы поставки делались без нарушений сроков, рассказал гостям и участникам конференции Infostart Event 2018 управляющий партнер BIPULSE.RU Алексей Васильев.

24.06.2019    2671    sbase    9       

Риск - благородное дело!.. Часть первая 31

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Несколько рекомендаций по управлению рисками в ИТ-проектах.

18.06.2019    3821    MariaTemchina    8       

Мы в ответе за то, чего вовремя не послали. Матрица ответственности в проектах внедрения 31

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

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

31.05.2019    4132    MariaTemchina    23       

Как продать проект в 3 раза дороже и нанести клиенту пользу, выполнив не внедрение... 21

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Практически все российские компании нуждаются не просто в установке 1С:ERP, 1С:Документооборота или какой-то другой программы, а в масштабных организационных изменениях, но мало кто из заказчиков это понимает. Те, кто занимается 1С, могут помочь бизнесу решить его проблемы, а заодно и продать проект внедрения в несколько раз дороже. Как это сделать, на конференции INFOSTART EVENT 2018 EDUCATION рассказал собственник и директор компании «Корада» Алексей Бояршинов.

27.05.2019    4181    cybrat    9       

Устав писать Устав 31

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Ответы на вопросы про то, нужен ли Устав для проектов автоматизации, и если нужен, то зачем?

06.05.2019    4034    MariaTemchina    8       

Как сжать время? 22

Статья no Нет файла 1С:Франчайзи, автоматизация бизнеса Бесплатно (free) Управление проектом Личная эффективность

Как, и зачем измерять задачи в чем-то, помимо часов.

04.05.2019    4705    1c-intelligence    39       

Путь джедая в управлении проектами 1С: умение быть, а не казаться 36

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Чем руководитель проекта “на бумаге” отличается от “настоящего” руководителя проекта, умеющего направлять команду и выдавать ценный результат?

15.04.2019    6764    MariaTemchina    15       

Управление ИТ-проектами, базовый курс, 3 поток. Онлайн-курс с 15 мая по 1 июля 2019 16

Курс Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Отличительная черта курса - органичное сочетание трех вещей: - Теория проектного управления (PMI®+Agile Alliance+Российские ГОСТ+Методологии от 1С)  - Опыт внедрения продуктов 1С (опыт франчайзи и успешных компаний + тренды Infostart Event и Agile Days) - Разбор реальных проблем и рекомендации экспертов по проектам слушателей Мы будем фиксироваться на тех инструментах, которые реально оказываются полезными в практике  руководителей проектов внедрения. 

04.04.2019    9257    infostart    18       

Стыд и Скрам, часть вторая 21

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

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

14.03.2019    7752    MariaTemchina    47       

20 мыслей об ИТ-проектах. Мысль №2. "С какой стороны подойти к новому проекту?" 38

Статья Руководитель проекта Нет файла Бесплатно (free) Управление проектом

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

13.02.2019    4419    chavalah    22       

Стыд и скрам - Чему нас учит Scream Guide 29

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Название "Scream Guide" можно вольно перевести на русский как “Вопль ужаса от того, как Scrum применяют на практике”

12.02.2019    6097    MariaTemchina    20       

Бизнес, не горюй 33

Статья no Нет файла Бесплатно (free) Управление проектом

Про цели автоматизации.

04.02.2019    5772    1c-intelligence    64       

Лучший домик для поросенка, или Что нужно знать руководителю проекта внедрения 23

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

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

31.01.2019    4986    MariaTemchina    0       

Ошибки управленцев: как топ-менеджеров убивает перфекционизм 5

Статья no Нет файла Бесплатно (free) Управление проектом

В преддверии онлайн-конференции «Гнев и слезы руководителя» мы решили заранее познакомить нашу аудиторию со спикерами, причем сделать это через видео-истории. Начнем с видео-приглашения от Миланы Джиджоевой и ее виденья диджитализации рекрутинга в России.

24.01.2019    6139    user809424    11       

Что немцу хорошо, то русскому... Как минимум, небезынтересно. Продолжаем тему Канбан 31

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

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

14.01.2019    6604    MariaTemchina    13       

20 мыслей об ИТ-проектах. Мысль №1. "О незаменимых людях" 62

Статья no Нет файла Бесплатно (free) Управление проектом

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

10.01.2019    8973    chavalah    123       

Где мы взяли флакон? 38

Статья no Нет файла Бесплатно (free) Управление бизнес-процессами (BPM) Управление проектом

История появления и развития методики

26.12.2018    6197    1c-intelligence    7       

Озарение после прочтения макулатуры по проектному управлению 42

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Открываю этой публикацией мини-рубрику "Письма в редакцию". По мотивам очередной статьи на Инфостарте пришло мне письмо на корпоративную почту. Прямо-таки, крик души. С разрешения автора, решила опубликовать публичный ответ. Ибо согласна с автором письма, пишущим: "Я уверен, что не я один такой убогий, кто задается подобного рода "идиотскими" вопросами, но при этом почему-то все молчат, видимо, pmbok с agile-ом поистине творят чудеса молчания..."

19.12.2018    6473    MariaTemchina    24       

20 мыслей об ИТ-проектах, или 20 лет спустя. 53

Статья no Нет файла Бесплатно (free) Управление проектом

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

09.12.2018    5940    chavalah    119       

Памятка руководителя: не играйте с деньгами 83

Статья Пользователь Руководитель проекта Нет файла Бесплатно (free) Управление проектом Личная эффективность Управление персоналом (HRM)

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

05.12.2018    13242    andironenko    128       

Шаг назад и ... шаг назад (классификация внутренних проектов) 34

Статья Пользователь Руководитель проекта Нет файла Бесплатно (free) Управление проектом

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

03.12.2018    5517    capitan    26       

Белая и пушистая рецензия на Чёрную книгу Скрам 31

Статья Бизнес-аналитик Пользователь Руководитель проекта Нет файла Бесплатно (free) Управление проектом

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

26.11.2018    6715    MariaTemchina    40       

Черная книга Скрам 21

Статья Бизнес-аналитик Пользователь Руководитель проекта Архив с данными Бесплатно (free) Управление проектом

Наблюдения менеджера, разрушившего карьеру бездумным применением Скрам. Рекомендации и предостережения.

26.11.2018    5535    356    Selikhovkin    4       

"Черные страницы Scrum", по версии Ивана Селиховкина 21

Статья no Нет файла Бесплатно (free) Управление проектом

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

23.11.2018    7847    Selikhovkin    8       

Памятка руководителя: Будьте оптимистичным или на крайний случай злым 46

Статья no Нет файла Бесплатно (free) Блоги Управление проектом

Следующая статья из цикла Управление персоналом - в этот раз предлагаю обсудить вопросы психологии управления и подчинения. Для тех, кто начинает читать этот цикл с этой статьи, вот ссылка на прошлый материал https://infostart.ru/public/937923/, в конце статьи будут ссылки на все статьи из серии «Памятка руководителя» - читатели просили. Итак, продолжаем работать с персоналом.

22.11.2018    8907    andironenko    43       

Scrum за 5 минут (заметки) 25

Статья no Нет файла Бесплатно (free) Управление проектом

Первый опыт создания статьи в сообществе. Немного о Scrum и нашем знакомстве.

20.11.2018    5097    leobrn    11       

Создание концепции проекта (project scope statement). Курс по управлению проектами, часть 8 30

Статья Системный администратор Бизнес-аналитик Пользователь Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Что такое концепция проекта? Это понятие, близкое по смыслу к техническому заданию (ТЗ). Одно из определений концепции - детальное, целостное описание работ в удобной для команды форме.

19.11.2018    4945    Selikhovkin    1       

Роевой интеллект (Swarm intelligence) как метод управления проектами (анти-утопия) 35

Статья no Нет файла Бесплатно (free) Управление проектом

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

19.11.2018    6282    capitan    41       

Почему внедрение ERP-системы не приносит пользы бизнесу? 87

Статья Бизнес-аналитик Пользователь Руководитель проекта Нет файла Бесплатно (free) Интеграция Управление проектом

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

15.11.2018    15706    rossoxa    62       

Думать некогда, трясти надо - или что такое ретроспектива в Agile 30

Статья Бизнес-аналитик Пользователь Руководитель проекта Нет файла Бесплатно (free) Управление проектом

12-ый принцип Agile-манифеста, как известно, гласит: "Каждый раз в конце заранее определенного интервала времени команда размышляет, как повысить результативность своей работы, и затем вносит коррективы в процессы." Попробуем разобраться, как это стоит, а как не стоит делать на практике. 

13.11.2018    7288    MariaTemchina    16       

Памятка руководителя: В одиночку здесь не выжить 43

Статья Пользователь Руководитель проекта Нет файла Бесплатно (free) Управление проектом Личная эффективность

Продолжаю цикл материалов, в котором рассказываю о своем опыте работы в качестве директора по ИТ. Этот материал будет посвящен теме управления персоналом.

07.11.2018    9255    andironenko    62       

Приоритизировали, приоритизировали, да не выприоритизировали... 28

Статья Бизнес-аналитик Пользователь Руководитель проекта Нет файла Бесплатно (free) Управление проектом

В ответ на классическое требование "сделать всё и сразу" Agile предлагает "сделать сразу, но не всё". В этой статье я хочу поговорить о разных методах приоритизации требований.

30.10.2018    6110    MariaTemchina    47       

Памятка руководителя: Уволь HRа и найди себе хороших сотрудников 67

Статья Руководитель проекта Нет файла Управление персоналом (HRM) Бесплатно (free) Управление проектом

Продолжаю цикл «Памятка руководителя». Эта статья будет на тему поиска новых сотрудников и одной грубой ошибки при проведении собеседования.

29.10.2018    8909    andironenko    35       

Принцип быстрой автоматизации 22

Статья Программист Нет файла Бесплатно (free) Управление проектом

Как выполняется автоматизация в бизнес-программировании?

29.10.2018    6337    1c-intelligence    19       

Опыт внедрения ESB (интеграционной шины) в ПАО "Газпром нефть" 34

Статья no Нет файла Бесплатно (free) Управление проектом

Харитонов Михаил описывает проект по внедрению интеграционной сервисной шины предприятия (ESB) «2iS:Интеграция» на платформе “1С:Предприятие 8” в компании ПАО «Газпром нефть». Проект уникален тем, что это – первое решение, использующее отечественное ПО в качестве полноценной интеграционной шины для столь крупного заказчика с обширным ИТ-ландшафтом. В статье подробно рассмотрена архитектура решения, способы тестирования и масштабирования.

17.10.2018    7353    Mick2iS    8       

#БезОценок, или Как перестать беспокоиться об оценке проекта, всегда успевать в срок и укладываться в бюджет 32

Статья Пользователь Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Считается, что для планирования и принятия решений по проектам их нужно прогнозировать и оценивать. Александр Белов, генеральный директор и руководитель проектов ГК «Белов и партнеры», рассказывает, почему стоит отказаться от оценок.

11.10.2018    5240    AlexWhite    7       

Профессиональные стандарты в ИТ как инструмент кадровой политики организации 21

Исследование Программист Пользователь Руководитель проекта Нет файла Обучение, бизнес-тренинг, курсы ИТ-компания 1С:Франчайзи, автоматизация бизнеса Россия Бесплатно (free) Управление проектом

Представляем результаты нашего нового исследования, посвященного теме профессиональной стандартизации и сертификации в сфере ИТ. Одна из главных задач работы – показать, каким образом профстандарты могут быть полезны в практике управления ИТ-персоналом предприятия.

08.10.2018    7733    39    infostart    4       

Построение высокоэффективной Agile-команды 34

Статья no Нет файла Бесплатно (free) Управление проектом

Меня зовут Асхат Уразбаев, я из компании ScrumTrek. Наша компания помогает внедрять Agile, Scrum, Kanban – гибкие методологии и гибкие подходы. К миру 1С я совсем не принадлежу, но в прошлом я, тем не менее, программист – занимался разработкой на самых разных языках программирования. Помимо основной деятельности у меня было несколько технологических стартапов, в которые я был так или иначе вовлечен. И сегодня мы поговорим о том, как сделать так, чтобы команда была крутой и эффективной.

08.10.2018    5227    askhatu    15       

История одного провала внедрения 1С:ERP 2 по классической технологии. С последующим спасением по Scrum 106

Статья no Нет файла Бесплатно (free) Управление проектом

Статья описывает успешный опыт реализации проекта после перехода от классической технологии «каскада» к методологии Scrum. Автор приводит примеры конкретных инструментов для построения эффективных коммуникаций в команде, ведения технической и пользовательской документации, реализации Scrum-доски, проведения стендапов и т.д. Также в статье даются рекомендации для тех, кто хочет научиться применять Scrum в своей деятельности.

01.10.2018    13349    glebushka    41       

Контракты Agile: как заключать договора в условиях расползания содержания 41

Статья Системный администратор Пользователь Руководитель проекта Нет файла Бесплатно (free) Управление проектом

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

25.09.2018    6828    MariaTemchina    10