Как сделать оценку проекта

Олег Пашинин

Одна из серьезных проблем в проектах – превышение сроков и бюджета. Можно даже сказать, что провальных проектов как бы и нет вовсе, а есть такие, срок которых увеличен до бесконечности, а бюджет пока закончился. Примечательно, что от превышения сроков страдают и исполнитель и заказчик. Заказчик не получает ожидаемого результата, а исполнитель – ожидаемых денег. Казалось бы, общая проблема должна объединять, но она зачастую только создает дополнительные проблемы между сторонами. Как сделать так, чтобы сроки и бюджет всегда выдерживались? Кое-чего в этом направлении нам удалось достичь.

бюджет

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

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

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

Рамки проекта

Первый ключевой момент – проработка рамок. Рамки проекта – это документ, в котором написаны требования заказчика к системе, но не настолько фундаментальный как ТЗ. Функциональные рамки проекта составляет консультант/аналитик – сотрудник проектной команды исполнителя – на основе интервью с ключевыми специалистами заказчика. Рамки проекта – это полное понимание всех задач, которые нужно решить в ходе проекта, но без детализации. Это также перечень задач, которые не будут решены в ходе проекта. Этот вопрос занимает одну-две недели. Столько же может занять согласование и уточнение.

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

Проработка архитектуры

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

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

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

Планирование работ

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

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

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

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

Оценка бюджета

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

Дальнейшие расчеты я, как руководитель проекта, делаю в таблице Excel. Примерно так:

Ресурс

Длительность (мес.)

Загрузка

Единиц

Трудо-

затрат, (час)

Ставка в час

Стоимость (месяц)

Стоимость (без НДС)

РП (Пашинин)

5

0,5

2,5

420

2000 р.

336 000 р.

840 000 р.

Ведущий консультант (Плешкова)

4

1

4

672

1400 р.

235 200 р.

940 800 р.

Архитектор (Шаповалов)

5

1

5

840

1400 р.

235 200 р.

1 176 000 р.

Консультант (Корх)

4

1

4

672

1100 р.

184 800 р.

739 200 р.

Ведущий разработчик (Харитонов)

3

1

3

504

1400 р.

235 200 р.

705 600 р.

Разработчик (Колесников)

3

1

3

504

1100 р.

184 800 р.

554 400 р.








4 956 000 р.

В результате появляется бюджет проекта. На планирование и составление бюджета уходит еще примерно два-три дня.

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

Уточнение рамок, срока, бюджета

В результате проделанной работы мы получили документы:

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

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

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

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

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

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

Управление сроком и бюджетом

Мы выполнили оценку, согласовали бюджет и сроки. Готовы к заключению контракта и выполнению работ. Но необходимо ответить еще на один вопрос – что исполнитель продает заказчику? С одной стороны он продает результат – в контракте содержатся рамки работ, которые обязуется выполнить исполнитель. Это договор типа «fix price». С другой стороны он продает ресурсы – бюджет составляется на основании длительности привлечения ресурсов, то есть «time & materials». Это разные типы взаимоотношений.

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

Суть их заключается в следующем:

1) Исполнитель гарантирует выполнение проекта в оговоренные сроки и бюджет, в случае, если рамки проекта не будут изменены.

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

3) Если в ходе проекта происходит изменение или несоблюдение рамок проекта, но они не влекут изменения сроков и бюджета, то обязательства сторон остаются в рамках контракта.

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

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

Подведем итоги. Ключевые моменты соблюдения бюджета и сроков закладываются в самом начале проекта при проведении оценки и закрепляются в контракте:

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

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

Впервые статья была опубликована на Executive.ru 10 сентября 2010 года в рубрике «Творчество без купюр». Реанонсирована в контентном блоке в рамках специального проекта редакции

Источник изображений: Фотобанк stockphotos

Комментарии
IT-менеджер, Москва
Коллеги. В дыму терминологических споров потерялся один самых интересных вопросов: как управлять объёмом ИТ-проекта. Ведь не секрет, что ввиду молодости отрасли по многом аспектам нет чётких стандартов. Соответственно, понимание, что из себя представляет результат проекта (конечный продукт), у Исполнителя и Заказчика расходятся. Для сближения позиций и используют все упомянутые документы: - ТЗ; - функциональные требования; - функциональные рамки; - предварительное описание объёма проекта; - список автоматизируемых процессов; и т.д. К сожалению, в начале проекта трудно зафиксировать правильный объём, так как Заказчик обычно в общих чертах выставляет требования (автоматизация внутрихозяйственной деятельности, например) а Исполнитель пытается подложить типовое решение. Но это не беда - в процессе прохождения фаз проекта (обследование-проектирование-реализация-тестирование-подготовка к запуску) всё можно уточнить. Беда в том, что почти все договоры fix price. И если в процессе проектирования -моделирования возникают уточнения, очень трудно под них изменить бюджет, так как ТЗ и почее написаны очень укрупнённо и большинство изменений можно протащить бесплатно. Поэтому либо в fix price закладывают риски и цена становится очень высокой, либо ... денег не хватает и Исполнитель теряет прибыль. Очень ценная мысль на старте проекта обязательно указывать, что точно делаться не будет. Но крупным Заказчикам такой подход не нравится. Так что давайте это обсудим, а не то, как называется правильно книжка от PMI. Что касается статьи Олега Пашинина, то меня смутил тезис о том, что если задачи выполнены быстрее, то консультанты всё равно остаются на проекте и что-то там делают. Демотивирующий момент.
Директор по развитию, Беларусь
Олег Кашуба пишет: Что касается статьи Олега Пашинина, то меня смутил тезис о том, что если задачи выполнены быстрее, то консультанты всё равно остаются на проекте и что-то там делают. Демотивирующий момент.
Это не более чем уловка. Известное неписанное правило проектного управления:''Каждая работа занимает столько времени, сколько на нее отпущено расписанием''. По опыту мог бы подправить - не менее чем отпущено расписанием.
Олег Кашуба пишет: К сожалению, в начале проекта трудно зафиксировать правильный объём, так как Заказчик обычно в общих чертах выставляет требования (автоматизация внутрихозяйственной деятельности, например) а Исполнитель пытается подложить типовое решение.
ИМХО, заказчика вообще не должна интересовать трудоемекость и затраты исполнителя. Его интерес - получить то, что называется экономическим эффектом. ПлАчу 1 млн., после внедрения экономлю 2 млн. в год. А типовое оно или нет мне фиолетово. Если хочу получить дополнительную экономию на разработке и внедрении - провожу тендер, можно двухэтапный. Может кто за 1/2 миллиона сваяет. Сколько при этом заработает исполнитель? Его проблемы.
Старший консультант, Москва
Олег Кашуба пишет: Поэтому либо в fix price закладывают риски и цена становится очень высокой, либо ... денег не хватает и Исполнитель теряет прибыль. … Так что давайте это обсудим, а не то, как называется правильно книжка от PMI.
Наши Заказчики и Исполнители ГОТОВЫ идти на указанные высокие риски. Почему готовы? – тоже тема для обсуждения. Похоже, эти вопросы где-то в плоскости бизнес-культуры и я не вижу другого лекарства, кроме конкуренции. В такой ситуации (готовности на высокие риски) любые предварительные этапы по уточнению проекта не избавляют от проблемы, а просто уменьшают последствия риска, что уже есть благо. Возможно... :| PS. ANSI/PMI 99-001-2004 – PMBOK Guide 3-rd Edition ANSI/PMI 99-001-2008 – PMBOK Guide 4-th Edition
Генеральный директор, Москва
Олег Кашуба пишет: смутил тезис о том, что если задачи выполнены быстрее, то консультанты всё равно остаются на проекте и что-то там делают. Демотивирующий момент.
Олег, большое спасибо за внимательное чтение статьи и за то, что обратили внимание на основные ее моменты. Оговорюсь, что в статье речь идет не о типовых проектах - пришел, поставил, настроил, - в которых фикс-прайс обусловлен предыдущим опытом их выполнения (и рынком). Я обратил внимание, что во всех консалтинговых проектах, в которых мне довелось участвовать, проект никогда не выполнялся раньше срока. Наоборот, риск срыва срока всегда был одним из основных. Это происходит по разным причинам, не в этом суть. Но у проектной команды, которая участвует в проекте не первый раз, иллюзий по поводу досрочного выполнения проекта - нет. Их опыт уже говорит о том, что Заказчик стремится сроки занизить, а продавцам, как правило, все равно - лишь бы продать проект. Кроме того, для профессионально ориентированных специалистов, мотивацией является не быстрое выполнение проекта, а решение сложной задачи с высокой степенью неопределенности. Более сильная мотивация по сокращению срока проекта есть у руководства консалтинговой компании, т.к. это дополнительная прибыль. Поэтому принять такое решение тяжело. Но мотивация для этого тоже есть. В случае превышения сроков компания теряет прибыль или даже терпит убытки. Более того, когда летят сроки одного проекта, становится невозможно спланировать сроки следующего. Это существенно влияет на среднегодовую загрузку специалистов. Так вот потери от неравномерной загрузки специалистов выше, чем потенциальная прибыль от выполнения проекта раньше срока. Вернусь еще раз к мотивации самих специалистов. Довелось ли вам когда-нибудь нанимать очень высокого профессионала, особенно в критичной ситуации? Обратите внимание, зачастую люди называют не цену за работу, а цену за свой час. У них нет стремления выполнить работу быстрее, для них ценно их время. Как правило, таймшитовая схема Исполнителю удобна. Фикс-прайс - это интерес Заказчика, чтобы быть уверенным, что он не вылетит за границы бюджета.
Генеральный директор, Москва
Валерий Овсий пишет: Автору цитата из миниатюрки Семена Альтова: «…Постовой: И я про вас никому. Езжайте! Да, когда свернете налево, ну вы-то направо, там проезд запрещен, обрыв. Но вам туда можно.»
Заглянул в ГОСТы. Для любителей казенных формулировок: Рамки проекта - тактико-техническое задание. Стадия ''1. Формирование требований к АС'' Проработка архитектуры - ''Стадия 4. Эскизный проект'' По ГОСТу стадия ''4.Эскизный проект'' идет после стадии ''3. Техническое задание'' (у нас до). Но здесь же: ''Допускается исключить стадию ''Эскизный проект'' и отдельные этапы работ на всех стадиях, объединять стадии ''Технический проект'' и ''Рабочая документация'' в одну стадию ''Технорабочий проект''. В зависимости от специфики создаваемых АС и условий их создания допускается выполнять отдельные этапы работ до завершения предшествующих стадий, параллельное во времени выполнение этапов работ, включение новых этапов работ.'' см. ГОСТ 34.601-90 Так что ничего такого, чтобы брызгать слюной я не вижу.
Researcher, Москва
Олег Пашинин, [COLOR=blue=blue]Цитата: У вашей компании 40 клиентов. Т.е. у каждого клиента вы выполнили в среднем по 25 проектов. Если допустить неравномерное распределение проектов по клиентам, то есть клиенты, у которых вы выполнили, возможно, 100 проектов? 1000 проектов за 12лет работы вашей компании дают около 80 проектов в год (считая с самого первого года работы компании). Но за 2010 год у вас только 2 крупных проекта. Остальные 78 проектов настолько небольшие, что вы о них ничего не хотите сказать? Или если система развертывается в филиальной сети, то количество проектов вы считаете по числу филиалов банка?[/COLOR] Вы показали отличное знание арифметики, но, как и почти все консалтеры, не умеете работать с прикладной информацией. Уточняю, я с 1986 года профессионально занимаюсь разработкой программных систем, работал последовательно в компаниях «Приз», «R-Style», «R-Style Software Lab», «Диасофт», «Новая Афина». Отрасль – Банки и финансовые институты. Так как я от природы человек ленивый ;) , то Вы как великий знаток арифметики, посчитайте, сколько там у меня в день получается, самому интересно! [COLOR=blue=blue]Цитата: Но за 2010 год у вас только 2 крупных проекта. Остальные 78 проектов настолько небольшие, что вы о них ничего не хотите сказать?[/COLOR] Ну прям Детский сад! Я понимаю, что Вам сложно понять, но мы НЕ ВЫВЕШИВАЕМ все свои проекты на сайте!! Замучаемся! Вся информация по проектам находятся в «Проектном Офисе» http://input.newathena.ru Записи только этой недели 21 сентября 2010 г утвердил проект «Деривативные инструменты OIS&FRA», Закзчик «ING Commercial Banking», конец 31 декабря 2010, бюджет $33 000 22 сентября 2010 закрыт и отправлен в архив проект «Зеленый коридор», Заказчик «Bank of Tokyo Mitsubishi», начало 04.05.2010, конец фактический 22.09.2010, плановый 31.08.2010, согласованный перенос сроков, Бюджет итоговый $17 333. Что еще Вам сказать? Я не знаю, большие они для Вас или маленькие? Спрашивайте! Вот только что (12:03) утвердил проект «Опционы, фьючерсы», консалтинговый проект, Заказчик «МДМ-Банк», начало , конец 29.04.2011, бюджет $90 000. Вы спрашивайте, спрашивайте! Только мне не понятно, вроде тема обсуждения Ваша статья! Но Вы ни слова не сказали по поводу моей оценки статьи. Неужто моя персона :oops: интересней, чем заявленная тема :) ?
Генеральный директор, Москва
Олег Пашинин пишет: Так что ничего такого, чтобы брызгать слюной я не вижу.
Извините, но очень неприятно.
Директор по развитию, Беларусь
Сергей Вратенков пишет: Похоже, эти вопросы где-то в плоскости бизнес-культуры и я не вижу другого лекарства, кроме конкуренции.
В этом вся правда :!: В условиях этой самой конкуренции, я как заказчик, выберу компанию которая возьмет на себя больше рисков. И скорее заплачу за два параллельных эсизных проекта - результатами которых будут два ТЗ, чем соглашусь с с расплывчатыми описаниями в контракте что будет ''эсли''. Кстати не забывайте, господин Паншин, что возможно Вам отвечают потенциальные заказчики ;) .
Researcher, Москва
Олег Пашинин, [COLOR=blue=blue]Цитата: Заглянул в ГОСТы. Для любителей казенных формулировок: Рамки проекта - тактико-техническое задание. Стадия ''1. Формирование требований к АС'' Проработка архитектуры - ''Стадия 4. Эскизный проект''[/COLOR] Скажите, с какого бодуна я должен угадывать, что Вы имеете в виду под терминами «Рамки проект» и «Проработка архитектуры» в В А Ш Е Й статье? В Вашей , не моей! Вы читателям загадки загадываете или хотите донести полезную (с Вашей точки зрения) информацию? Предполагаю, что хотите донести…, но тогда разговаривайте с читателями (кому адресуете статью) на языке, понятной им, читателям. Употребляйте те термины, с которыми они (читатели) хотя бы знакомы. Я уж не говорю про архаичные ГОСТЫ и стандарты COCOMO 1981 года на которые Вы ссылаетесь. Ребяты, на улице, посмотрите в окно, 21 век, год 2010!! Слово автоматизация устарело как пишущая машинка. Если Вы до сих пор автоматизируете, то это Ваше горе и проклятие. Сейчас век ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ. Подчёркиваю, ТЕХНОЛОГИЙ. Эти технологии меняют в корне представление о современном производстве. Компьютеры это НЕ средство автоматизации, а элемент, строительный кирпичик любого производства!! Составной элемент! Именно по этой причине, по причине непонимания у Вас и неудачные проекты. Неудачные потому что НЕ НУЖНО НИЧЕГО автоматизировать. Нужно запускать НОВЫЕ ТЕХНОЛОГИИ. Правильно говорит Виталий Амбалов! Заказчик может словами говорить что угодно, но думает он об одном. Как повысить эффективность производства за счёт НОВЫХ ИНФОРМАЦИОННЫХ технологий. И если Вы покажите ему (заказчику) эффект, его выгоду, он разобьётся в лепёшку, но запусти проект и выплатит деньги. Единственно, что мне жаль, так то, что я в свои 62 года это понимаю, а Вы молодые люди НЕ ПОНИМАЕТЕ!
Председатель совета директоров, Москва
Валерий Овсий пишет: ...что я в свои 62 года...
:D :D :D может откроем ветку я супер-стар :!: :!: :!: :D
Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии