Стенограмма вопросов и ответов с конференции для руководителей проектов

(проводилась в марте 2009г)

Вопрос (от начальника отдела ИТ): Руководство хочет, чтобы после автоматизации "все было круто", а что конкретно - он не знает. Как быть?

Это естественно. Роль исполнителя (неважно, внешнего консультанта или внутреннего отдела ИТ) на проекте можно сравнить с ролью хирурга.

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

Дополнение. Давайте все-таки уточним: не точным будет сказать, что заказчик не знает, чего хочет. Заказчик, в большинстве случаев, знает, чего он хочет. И хочет он вполне простых, осязаемых вещей: прибыли, денег, стабильности, предсказуемости и т.п.

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

Это требование к результату/проекту? - смотря на каком этапе. Если такие пожелания возникают на этапе экспресс-обследования, то да, вы можете сказать: "Заказчика интересует вот такая-то область". Если это уже техническое задание (технический проект), то здесь нужно останавливаться и присматриваться к деталям, что же на самом деле скрывается за этими словами.

Вот такой подход нам нужен: если мы чувствуем, что уже пора описывать все детально, то останавливаться на каких-то общих терминах нельзя. И если заказчик сказал: "Я хочу учет", мы начинаем уточнять : "А какой учет? О чем идет речь? В какой форме? Какие контрольные показатели? Какие отчеты вы хвоите получать? С какой оперативностью? От кого? Какие службы задействованы? Обучены они, не обучены?" и т.д. Входящая информация, исходящая, управляющее воздействие - по полной программе…

Вопрос (от автоматизатора-подрядчика): Менеджер запускает проект. Потом увольняется в связи с этим проектом, убивая его - на нем все держалось, собственник нас ненавидит. Как жить дальше?..

Да, вы не предусмотрели эти риски. То, что менеджер увольняется в середине проекта, убивая его - это риск, и этим риском надо как-то управлять. Плохо, что заблаговременно не вышли на собственника. Конечно, вам могли и не предлагать возможность прямого выхода на собственника (никто из менеджеров не взял на себя организацию встречи). Но это именно ваша ответственность - добиться создание полномочного коллективного органа управления для проекта со стороны заказчика. Вы же договора какие-то подписывали? - значит, все-таки могли донести до заказчика свою точку зрения.

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

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

Вопрос (от директора по ИТ): Повысить оперативность, снизить издержки - разве это цели? Разве они критериальны?

Почему же снизить издержки - не цель? Если ее вот так обозначить просто двумя словами "снизить издержки" - тогда это не цель. Почему? - Потому что она недостаточно конкретна (специфична) и у нее нет целевого критерия: какие именно издержки, насколько именно в процентном соотношении мы хотим снизить. У нее нет метрики. Не определено, по какому процессу производится снижение издержек.

Или это вообще по всему предприятию? Если по всему предприятию, то она настольно глобальная, что третьему принципу SMART она не очень отвечает - она не очень релевантна и достижима. Как мы поймем, что мы по всему предприятию снизили издержки ровно настолько именно из-за этого внедрения? Сложно сказать…

То есть такой формулировки конечно мало, чтобы это стало полноценной целью…

А вот когда мы говорим, что мы снизим издержки на 10% по производственному процессу в цехе № 7 из-за того, что у нас информация о производственных заданиях будет поступать сразу к цеховому мастеру, и он сможет регулярно контролировать рабочего - то это очень даже цель.

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

Зачем определять цели? Например, мы сначала специфицировали, что мы хотим повысить оперативность сдачи регламентированной отчетности - сдавать ее на пятый день. А потом инициатор проекта говорит:

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

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

Вопрос (от системного аналитика): Имеет ли смысл фиксировать время бизнес-процессов до внедрения и прогнозировать, сколько он займет после внедрения системы?

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

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

Если какие-то из них входят в цели, тогда их нужно описывать. Если нет, так и не надо его описывать.

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

Вопрос: Кто должен выдвигать требования по проекту? Заказчик? Или нужно формулировать их самостоятельно на основе проведенного интервью?

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

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

Такая стрельба по движущейся мишени. Какие варианты здесь существуют?

Первый вариант - предварительное обучение заказчика

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

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

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

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

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

Второй вариант заключается в том, что мы описываем не процесс, а результат

Если заказчик вам (на своем языке) говорит, что его интересует сокращение сроков исполнения заказов в производстве с 4-х дней до 2-х дней - это прекрасное требование к проекту. И это вы должны теперь сидеть и думать, как это описать в техническом задании.

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

А какие работы, сколько, в каком формате мы должны для него сделать - этого не стоит ожидать от клиента.

Ну, если он вдруг нам это напишет - он молодец, конечно :) Итого - требования всегда будете формулировать вы, после того, как:

позаглядываете в глаза людей

посмотрите на реальные процессы

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

Аналогично, есть ненулевая вероятность того, что и директор (владелец), будет формулировать требования или накладывать ограничения, не сильно соразмерные реальности. Безусловно, все-таки именно заказчик определяет, что должно быть сделано для его бизнеса, но прежде чем взяться за работу, следует проверить требования на непротиворечивость и реальность.

Вопрос: Чтобы клиент понял, чего хочет - надо показывать программу?

В большинстве случаев - как минимум, не помешает.

Но есть случаи, когда это не очень уместно. Вот у вас начальник производства, ему 58 лет, у него на левой руке нет трех пальцев, и вы ему показываете в 1С отчет производства за смену - документ на 10 табличных частей. Я думаю, что этой демонстрацией персонально у него желания купить программу вы не вызовите. Просто показ программы - не панацея. Кроме того, могут быть и такие варианты, что показ программы надо откладывать "на потом".

Вопрос: Лопухнулись, недооценив риски. Как страховаться?

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

Как проверяют самолеты перед полетом? Техники приходит на борт за три часа до взлета, и у каждого есть специальный чек-лист, в котором перечислены пункты - что нужно проверить. И он по этому check-list проходит, проверяет - и отмечает то, что проверил:

Насосы двигателя работают?

Электроосвещение работает?

Аварийное освещение работает?

Приводы работают?

Шасси на месте?
и т.п…

Проверяем - все ли сделано? Если какого-то "крыжика" нет - то "Стоп!" полету…

Аналогично, когда заходим на проект - должен быть check-list. Проверяем: "Ресурсное обеспечение проверили? Да. Провели оценку вероятности того, что уложимся в срок? Да. Мы провели согласование рисков? Да. Мы заложили в контракт сценарии выхода из договора? Нет!". Выявляем неотработанные пункты и если есть пропущенные этапы - "Стоп! Один пункт не выполнен!". И начинаем этим заниматься.

Вопрос: Ожидания могут меняться в ходе работы над проектом, как быть?

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

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

Вопрос: Пример из внедрения. Автоматизировали, в частности, подсистему складского учета. Кладовщики стали работать в 1С и завопили в один голос: "О! Как долго теперь, раньше товар отписывали за пять минут, а теперь столько всего надо правильно заполнить". А при начале проекта не было речи о занижении скорости работы, в том числе и неквалифицированными пользователями. А теперь заказчик вопит: после автоматизации склад встал, терпим убытки!
Как правильно такое разрулить?

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

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

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

Вот пример из практики:

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

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

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

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

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

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

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

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

Вопрос: Пусть даже клиент во всем виноват: "Вы ТЗ подписали? Подписали. Система ТЗ соответствует? Соответствует. Никаких вопросов". Но система работает не так, как нужно заказчику. Что делать, как избежать?

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

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

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

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

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

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

Вопрос: Как доказать неправильность понимания, неточность формулировок, недописанность?

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

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

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

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

Вопрос: Мотивация персонала в проекте может быть низкой. Мы такие ситуации мониторим? И как решаем?

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

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

Какой-то "очень скрытый" саботаж, типа итальянской забастовки, встречается редко. Обычно то, что персонал откровенно "забивает" на проект - видно в большинстве случаев. Поэтому (во-вторых) если это видно, то мы пытаемся понять, почему так происходит, и выдаем какие-то предложения заказчику. Иногда даже в Уставе проекта, в экспресс-обследовании обозначаем, что нужно мотивировать сотрудников, предусматривать меры как поощрения, так и наказания.

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

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

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

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

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

Вопрос: Как ИТРП решает проблему нехватки времени на согласование, отладку? И клиент, и разработчик вечно занятые люди, и интервалы свободного времени зачастую не совпадают.

Ну да, занятые. Просто нужно планировать этот процесс предварительно. То есть не так, что мы написали техническое задание или построили функциональную модель, клиенту отдали, а потом сказали: "Давайте, вперед! 5 дней вам нужно полностью выделить на то, чтобы заниматься только этим". Нет, нужно обязательно планировать и согласовать этот процесс.

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

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

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

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

И там мы выделяем где-то два часа в неделю на совещания, оценку текущего состояния проекта и совещания с этим комитетом.

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

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

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

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

Первая типовая ошибка - это что заказчик говорит, что не надо вообще никаких бумаг, никаких комитетов по автоматизации, давайте сразу ехать: поговорили - сделали…

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

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