Счастливый заказчик, или Как управлять ИТ-проектом, не привлекая внимание санитаров?

05.12.23

Управление проектом - Взгляд со стороны Заказчика

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

Меня зовут Константин Попов. Я руководитель направления компании Т1 Консалтинг, уже семь лет я руковожу проектами ИТ-внедрения. Эти проекты очень часто попадали ко мне по следующим причинам:

  • либо это была какая-то конфликтная ситуация;

  • либо это был проект, где заказчик не знает, чего хочет – так мне говорили;

  • либо мне давали заказчика на развитие, и мне удавалось значительно увеличить с ним объем выполненных работ.

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

 

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

 

Этот доклад для тех, кто сталкивался с ситуациями, которые перечислены на слайде.

  • Вы сдаете работы, и все принято… но далее тишина.

  • А потом вы узнаете, что и разработкой толком не пользуются.

  • И заказчик уже ищет другого исполнителя.

Де-юре проект был сдан, но де-факто результат достигнут не был.

 

 

А еще возникает ситуация, как из анекдота про воздушные шарики, которые и расцветки веселой, и надуваются хорошо, и не сдуваются… Все вроде по ТЗ у шариков, но они не радуют заказчика.

Как разобраться с этой ситуацией?

 

Кто такой счастливый заказчик?

 

 

Для начала давайте рассмотрим, что для нас считается успехом проекта.

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

Интереснее строки, которые идут ниже первой тройки. Это признаки того, что заказчик после сотрудничества с вами счастлив:

  • он получил какой-то карьерный рост или похвалу;

  • порекомендовал вас какому-то знакомому;

  • окупил затраты на ИТ-разработку;

  • советуется с вами о дальнейших ИТ-внедрениях;

  • обращается к вам с какими-то новыми запросами.

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

 

 

Зачем нам делать заказчика счастливым? Когда я думал над этим вопросом, то нашел изречение древнего мыслителя Платона: «Стараясь о счастье других, мы находим свое собственное».

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

 

Чтобы этого добиться, нам нужны четыре составляющие:

  • соответствие целям;

  • правильно выстроенная коммуникация;

  • персонализация обращения;

  • и еще один секретный ингредиент, о котором я расскажу в конце.

 

Цели

 

Начнем с целей.

 

 

У нас есть заказчик. Я решил персонализировать заказчика и выделил три типа:

  • Лицо, принимающее решения ЛПР – гендиректор, фаундер.

  • Бизнес-заказчик – какой-то коммерческий директор, HR-директор и т.д.

  • И наш знакомый ИТ-директор или админ.

У разных типов заказчиков для ИТ-проекта разные цели.

 

 

Почему-то чаще всего считается, что основная цель основателя или гендиректора – это получить прибыль, сократить затраты, повысить рентабельность (ROIT). На это очень часто упирают, в том числе, когда продают гендиректору проект.

 

 

Но на самом деле, прибыль – это не первоочередная цель, и она даже не первого порядка.

  • Первоочередная цель ЛПР состоит в том, чтобы развиваться, внедрять новое, «чтобы сотрудники не закостенели». Этими словами гендир или основатель выражает желание развивать компанию.

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

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

 

 

Идем дальше. Какие цели у бизнес-заказчика – HR или коммерческого директора?

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

 

 

А на самом деле у бизнес-заказчика в приоритете совсем другие задачи:

  • Он переживает за свое место, и ИТ-проект – это для него способ быть в тренде, быть актуальным.

  • Вторая его цель – это карьерные и финансовые перспективы. Он рассматривает успешный ИТ-проект как драйвер карьеры.

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

 

 

И последний заказчик из нашей тройки – это наш друг айтишник, которому мы продаем проект.

Поскольку это «наш» человек – мы с ним разговариваем на одном языке. И считаем, что для него важнее всего внедрить эффективное ИТ-решение.

 

 

Но на самом деле, его цели состоят в другом:

  • Его основная цель – это безопасность ИТ-инфраструктуры. Ему главное, чтобы после того, как вы что-то внедрите, у него ничего не рухнуло.

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

  • Естественно, это поддержание актуальной ИТ-инфраструктуры. Человек оценивает, что его профессиональный и карьерный рост не должен останавливаться, и ИТ-проект, в том числе, работает с этой целью.

 

 

На ИТ-проекте мы должны работать со всеми типами целей одновременно.

Здесь на слайде я еще раз перечислил эти цели, свел их в одну таблицу. Красным я выделил страхи.

Страхи и развитие – это основные цели, которые движут людьми, задействованными в ИТ-проекте со стороны заказчика.

 

 

В качестве примера расскажу кейс проекта:

  • Небольшая семейная компания – сеть торговых точек по продаже дверей.

  • Ильяс и Тимур – совладельцы. Молодые ребята, 30 с небольшим лет. Они хотят развивать компанию.

  • Сергей – коммерческий директор, и Зоя – директор по развитию. Это топы. Они пришли в эту семейную компанию со стороны и поняли, что без внедрения CRM-системы работать нельзя. Но как ее использовать конкретно в этом бизнесе, конкретно в этих магазинах, им было не до конца понятно. Они так и говорили: «Помогите разобраться! Мы знаем, что надо внедрять, но не знаем, зачем».

 

 

Мы с командой проработали все эти типы целей.

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

Далее мы отработали первую цель ЛПР – прогресс от внедрения CRM. Оформили это очень большим количеством мощных совещаний – составили документацию, написали устав проекта. Внедрение шло с вовлечением почти всего руководящего звена компании, хотя половина руководящего звена в этот момент вообще не понимала, о чем идет речь.

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

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

В качестве второй выгоды придумали проект «нестандарт» – проведя мозговой штурм с Сергеем и Зоей.

«Нестандарт» – это нестандартные размеры. Когда к ним в магазины приходили покупатели, у них были двери стандартных размеров – в основном, проем 80 на 200. А приходили люди, которым нужна была дверь в коттедж размером 100 на 220 – таких готовых дверей не было, и человек уходил.

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

Эту прямую выгоду увидели ЛПР и подумали: «Ничего себе, есть какая-то ИТ-система, которая может нам денег принести?!»

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

Мы хорошо поработали, и они периодически возвращаются с вопросом: «А давайте придумаем что-нибудь еще?»

 

Коммуникации

 

От целей перейдем к коммуникациям.

 

Коммуникации используют классическую теорию «канал-способ-сообщение». На примере одной ошибки я расскажу, как работает эта теория, и дам шаблон – как выбрать для ИТ-проекта правильный канал и способ сообщения.

 

 

Представьте, что вам нужно согласовать увеличение бюджета проекта. И вы посылаете письмо ИТ-директору – прикрепляете таблицу с расчетами и обоснованием.

Вопрос: что здесь не так?

 

 

Здесь все не так:

  • Канал в данном случае – не Email, а сам ИТ-директор. Потому что ИТ-директор не будет решать этот вопрос сам, ему нужно идти куда-то дальше. Фактически вы делаете ИТ-директора каналом для передачи вашего сообщения об увеличении бюджета.

  • Способ, которым ИТ-директор согласует нам бюджет – вообще неизвестен. Либо ИТ-директор сделает это докладом, либо отправит ваше письмо, либо подготовит свое.

  • Что касается сообщения – вполне возможно, что он заглянет в кабинет генерального директора, скажет: «Подрядчик просит увеличения бюджета. Он прислал таблицу, но не уверен в ее обоснованиях».

  • Уровень контроля с вашей стороны в данном случае – практически нулевой.

Как же сделать правильно?

  • Нужна встреча в офисе заказчика.

  • Нужно собрать большое серьезное совещание, сделать презентацию.

  • Нужна развернутая информация о ходе проекта, о достигнутых результатах.

  • Таким образом мы сделаем максимально возможное, чтобы решить эту задачу.

 

 

Покажу небольшой шаблон о том, как выбрать для проекта правильный канал и способ сообщения.

Для лиц, принимающих решения:

  • В качестве канала взаимодействия, помимо встреч, очень хороший вариант – чат. Сейчас все владельцы бизнеса стали очень мобильны, и если есть возможность, вы можете списаться с ЛПР по какому-то поводу и решить вопросы в чате.

  • Способ передачи – устав проекта и презентация, в которой нужно выделить главное.

  • С ЛПР вы в первую очередь обсуждаете бюджет, цели и сроки – отсюда вытекают и типы вопросов, которые нужно адресовать Главному.

При общении с бизнес-заказчиком:

  • Желательно проводить встречи и формировать отчеты – это самые лучшие каналы.

  • Для обсуждения нужно составить документ, где подготовить обоснование со всех сторон.

  • Предметом обсуждения могут быть функциональные требования и сроки проекта.

Ну и с ИТ:

  • Можно так же быстро переписываться в чате или написать email.

  • Дать аргументацию тезисно.

  • Сроки и бюджет ИТ-шника мало касаются – для него в основном важны технические и функциональные требования.

 

Персонализация

 

Что я хочу здесь дополнить.

 

 

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

  • вы идете от шаблона;

  • работаете с целями проекта;

  • выстраиваете определенную специфику общения с заказчиком;

  • и в конечном счете получаете персональное обращение.

Как это все понять? Выясняете, спрашиваете. Здесь нет какой-то жесткой теории. Стройте гипотезу, проверяйте ее, и все получится.

 

 

У меня был кейс:

  • Руководитель проекта по личным причинам покинул проект на начальном этапе, и проект перешел ко мне – в этот момент в проекте еще шла подготовка технического задания.

  • Федеральная сеть, CRM, колл-центр, несколько сайтов, интеграции и т.д. – многогранный проект с очень сложной инфраструктурой.

  • Начинаю вести первую встречу и понимаю, что коммуникация не строится – со мной как-то холодно разговаривают. Все это происходило дистанционно: я в Питере, они в Москве.

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

Я обратился к предыдущему руководителю проекта – спросил, что к чему. Он мне посоветовал поехать туда и поговорить с руководителем проекта (с их стороны – ИТ-директором).

Терять мне было нечего. Я решил поехать туда и встретиться в офисе.

 

 

Я позвонил, сказал, что подъеду. Он сказал: «Хорошо. Жду, пообщаемся».

Мы с ним садимся в отдельном помещении, начинаем общаться. Он долго меня расспрашивает: кто я, какие проекты вел и так далее. И через пол часа, когда эти вопросы выдохлись, он у меня спросил: «Так зачем вы приехали?»

Я ему абсолютно честно отвечаю: «Я вообще не понимаю, что происходит в проекте. У нас сложилась какая-то натянутость в отношениях, и мне надо с этим разобраться. Я сюда приехал, чтобы с вами поговорить».

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

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

 

Секретный ингредиент. Матрица «сложно-важно»

 

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

Расскажу, какой смысл я вкладываю в этот термин.

 

 

В первую очередь идет эффект. Знаете, когда показываем заказчику какую-то стандартную функциональность на уровне 2*2=4, а он: «Вау!!» Вроде простенько, но заказчика это восхищает.

Или наоборот: мы пилим сложную кастомную интеграцию – нам очень непросто. Месяц ее пилим, кровь и пот льются, показываем заказчику, а он говорит: «Ну ок. А что вы так долго возились?»

 

 

В чем смысл:

  • Сложно или просто можно сделать с точки зрения исполнителя. Если вы исполнитель или руководитель проекта, вы с этой стороны и будете расставлять приоритеты, ресурсы выделять, акценты выставлять и т.д. Мы, айтишники, берем и оцениваем – сложно это сделать или просто. Отсюда и пляшем. У заказчика нет квалификации для того, чтобы он мог это оценить. Мы ему это транслируем, а ему приходится соглашаться. Он нас выбрал, нам доверяет и нас будет слушаться. И он говорит: «Да. Это, наверное, сложно. Это, наверное, дорого. А здесь просто? Ну да, наверное…» Мы не спрашиваем при этом заказчика.

  • А у заказчика это – «важно» или «не важно». Нужно плясать от того, что для заказчика важно, а что не важно.

Сопоставить наше «сложно/просто» и заказчика «важно/не важно» – это ключевой момент для успеха проекта.

 

 

Мы получаем матрицу, где у нас есть четыре квадранта:

  • Важно заказчику, сложно делать. Отлично. Значит нужен ресурс, желательно с запасом. Следим за сроками – это ключевая точка проекта, приоритет №1.

  • Важно заказчику, а нам просто сделать. Здесь главное не сказать вслух: «Ерунда, сейчас быстро сделаем!» Если вы понимаете, что это важно для заказчика, не нужно торопиться. Проработайте этот вопрос, уделите внимание обучению. Не нужно доводить до заказчика информацию о простоте.

  • Не сильно важно для заказчика, но и сделать просто. Может быть, вам это поможет для сдачи проекта или для каких-то еще задач. Например, вы можете сдать простые и неважные задачи, когда у вас затянулись первые две группы разработки («важно/сложно» и «важно/не сложно»).

  • И последний, самый страшный квадрант. Заказчику не важно, а сделать сложно. Обычно заказчик говорит: «У вас здесь все хорошо сделано, но давайте еще одну фишечку добавим – чтобы сообщение улетало мне в Telegram-канал». А стандартной функциональности такой нет. И он спрашивает: «Ну вы же знаете, как это подключить в Telegram-канал?» И вы киваете, говорите: «Хорошо, сделаем». И кидаетесь выполнять, хотя понимаете, что делать будете долго. Если вы видите, что это сложно и не важно для заказчика, не кидайтесь это выполнять – лучше вообще отговорите его от этой задачи. В крайнем случае, переведите ее на типовое решение. «В стандартной функциональности присутствует отправка на email – вам отправится email-уведомление». Может оказаться, что заказчику этого хватит, и он согласится.

 

 

От этой матрицы «сложно-важно» проистекает практически все:

  • приоритеты проекта;

  • ресурсы проекта;

  • грамотное ТЗ;

  • цели проекта – все что угодно.

Старайтесь анализировать важность задач для заказчика и правильно этим распоряжаться. В этом случае вы получите счастливого заказчика, который вам скажет: «Вы понимаете мои задачи лучше меня». Если вам так говорили, значит, вы интуитивно дошли до этого и интуитивно этим управляете.

 

Резюме

 

Подведем итоги.

 

 

Вся наука о счастливом заказчике заключается в следующем:

  • Понять цели участников проекта. Берем типовые шаблоны, пробуем их, проверяем, выясняем в диалоге, внимательно слушаем;

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

  • Персонализация. Видим реальных людей за этими функциями, общаемся с ними, понимаем их личные цели и приоритеты в проекте;

  • Приоритезируем управление задачами проекта через матрицу «сложно-важно».

Это те инструменты, которые помогают достигать гармонии с заказчиком и делать его счастливым.

 

 

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

  • Первый пункт – очень простой: не переносите встречи. Прошу вас, всегда проводите встречи в назначенное время. Либо меняйте повестку, но проводите встречу.

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

  • Если вы не можете сразу принять решение, хотя бы сразу дайте обратную связь, что вы приняли информацию. Напишите: «Я вас услышал».

  • Обязательно: не допускайте поступления задач от заказчика из более чем двух источников. В идеале должен быть один источник, максимум – два.

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

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

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

  • И последнее – «Управляйте проектом, не привлекайте внимания санитаров». К «санитарам» я отношу юристов и службу безопасности. Не доводите до этого. Как только до этого дошло – все проиграли. Проект рухнул, все стало плохо, ничего хорошего уже не будет. Так что не привлекайте внимание «санитаров».

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event.

См. также

Оптимизация бизнес-процессов Взгляд со стороны Заказчика Внедрение изменений Платформа 1С v8.3 Бесплатно (free)

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

13.08.2024    1111    0    avermakov1986    5    

6

Взгляд со стороны Заказчика Бесплатно (free)

В каждой компании и на каждом проекте есть свои критерии оценки эффективности ИТ-аналитиков. И за формальными методами оценки часто скрываются неочевидные ожидания заказчиков и проектных менеджеров. Расскажем о задачах аналитика на проектах внедрения и возможных способах оценки эффективности аналитиков.

01.08.2024    1230    0    user623528_vergazov    1    

1

Компетенции и навыки РП Взгляд со стороны Заказчика Бесплатно (free)

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

26.02.2024    2994    0    user1270271    0    

13

Взгляд со стороны Заказчика Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

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

22.08.2023    1879    0    user1642712    0    

13

Взгляд со стороны Заказчика Бесплатно (free)

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

20.07.2023    1488    0    user1642712    0    

6

Взгляд со стороны Заказчика Бесплатно (free)

В семнадцатом выпуске подкаста Радио “Аналитик“ обсудили, как представители сфер foodtech и e-com определяют, что пора автоматизировать процессы, на что обращают внимание при выборе подрядчика, что ценят в коммуникациях и как определяют, успешно выполнена автоматизация или нет.

01.05.2023    688    0    Radio_Analyst    0    

1

Взгляд со стороны Заказчика Бесплатно (free)

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

17.04.2023    703    0    Radio_Analyst    0    

2

Взгляд со стороны Заказчика Руководитель проекта Бесплатно (free)

Зачем вообще нужно управление проектом? Надо ли заказчику показывать стоимость управления проектом? И должен ли руководитель проекта сам внедрять 1С параллельно с управлением? На эти вопросы в рамках митапа «Инструментарий РП» ответила руководитель проектов ВЦ «Раздолье» Вера Пикурен.

02.07.2021    3509    0    VeraPikuren    4    

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