Что написано пером…

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

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

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

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

Чего мы добиваемся? Мы должны определить на предприятии лицо, сочетающее права и ответственность для дальнейшей работы. Причем это лицо должно обладать достаточным административным ресурсом.

Ошибки из практики:

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

Демо-версия

Старый анекдот: «Однажды святой Петр и дъявол боролись за душу человека. Святой Петр показал душе райские кущи, где пели святые. А дъявол показал душе кабак, где пили вино и обнимали девочек. Душа человека выбрала ад. Сразу исчез кабак, вино и девочки. Появились черти, огонь и сковородки. «А где же обещанное?» — спросила у дъявола изумленная душа. «Это была демо-версия!» — пояснил дъявол».

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

«Чтобы не разочаровываться — не надо очаровываться» — говорила моя мудрая бабушка.

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

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

«Мы с вами будем долго и плодотворно работать!» — это демо-версия. А вот подписанные документы или отказ от их подписания — реальный поступок. Отказ от подписания документов (целей и задач, макета документа и т.д.) — реальный риск получить потом отказ в том, что такие цели, задачи, документы и т.п. были когда-то предметом обсуждения и каких-то решений.

«Хороший человек — не профессия». (С) Ильф и Петров. В работе я предпочту иметь дело с человеком несимпатичным, но умеющим держать свое слово, профессионалом.

Ошибки из практики:

• • Устно озвученные цели через несколько месяцев меняются на иные. Руководитель, обаятельный в начале проекта, становится жестким тираном, угрожающим разными карами. Другой вариант: руководитель остается мягким, добрым, участливым, но ведет свою закулисную игру против вас.
• • Макет документа/отчета, не подписанный заказчиком, переделывается много раз.
• • Задачи, поставленные напрямую пользователями, минуя ответственного за ведение ИТ-проекта, не оплачиваются. Хотя устное согласие руководителя на их выполнение было получено.

Договор договору рознь…

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

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

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

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

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

3. Обязанности заказчика. Теперь в договоре прописываем лицо, ответственное за руководство работ со стороны Заказчика. Это именно то ФИО, приказ на которого уже хранится в нашей папке внедренца. Именно этот человек будет подписывать Задание, ЛУРВ, Отчет и Акт выполненных работ.

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

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

4. Сдача-приемка работ. Проще всего планировать работы на один месяц вперед, что не исключает прогнозное планирование на более длительные сроки. Но на будущий месяц работы должны быть определены с точностью 90%: определены объекты для доработки с подписанным ТЗ (техническим заданием), даты посещения заказчика для обучения, отладки или приемки объектов программного продукта. Все это должно быть отражено в Задании, которое подписывается обеими сторонами.

В течение месяца время, отработанное исполнителем у заказчика, фиксируется в листах учета рабочего времени. Важно подписывать ЛУРВ сразу! В крайнем случае, на следующий день. То, что отложено на более длительные сроки, забывается. И совсем недопустимо откладывать подписание работ на конец месяца. Халтура при таком подходе неизбежна. По окончании месяца копии ЛУРВ прикладываются к пакету документов, который отдается на подпись заказчику. Оригиналы исполнителю лучше оставлять у себя.

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

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

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

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

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

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

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

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

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

Ошибки из практики:

• • В конце месяца внедренец приносит Акт на выполненные работы без расшифровок и документов ежедневного учета. В этом случае заказчик имеет полное право сомневаться в правомерности объемов выполненных работ.
• • Игнорирование в ЛУРВ колонки «Замечания». Если замечаний нет, то слово «нет» должно быть вписано в колонку. В противном случае замечания могут появиться тогда, когда вы этого не ожидаете.
• • Отсутствие подписанного «Задания» может привести к оспариванию необходимости работ, выполненных за месяц. И такое может произойти спустя несколько месяцев…
• • Продолжение работ без письменного мотивированного отказа или подписаного акта также может привести к оспариванию всех последующих работ. Руководство может изменить свои цели, не поставив вас в известность. Подписание акта или мотивированный отказ — это обратный сигнал, позволяющий определить, совпадают ли ваши цели. Это далеко не только формальность. Без подписанного акта ваш шанс получить оплату за свой труд равен нулю.
• • Длительное продолжение работ без оплаты по выставленным счетам даже при наличии подписанных актов может привести к неприятной перспективе судебного разбирательства. Риск остаться без оплаты особенно велик в начале и в конце проекта. Исходя из арбитражной практики, если по договору заказчиком произведена хотя бы одна оплата, договор считается вошедшим в силу. Но много ли франчей или фрилансеров будет подавать в суд на заказчика? И хлопотно, и затратно, и удар по репутации. Вот поэтому мы закладываем в договор ограничения по срокам оплаты счета и возможным действиям в случае отсутствия оплаты. Ведь никто не обязывает вас приостановить работу, вы оговариваете лишь право на это. Для себя мы решили, что можем рисковать только одним месяцем бесплатной работы на заказчика.

Без вины виноватые…

Чтобы быть хорошим пешеходом, надо побывать «в шкуре» водителя автотранспорта. Чтобы быть нормальным исполнителем, хорошо бы знать некоторые методы руководства.

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

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

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

В-третьих, власть ослепляет даже сильных духом. Иной руководитель нуждается не в хорошо сделанной программной системе, а в ежедневном, ежечасном подтверждении своего могущества. Спорить с ним также бесполезно, как и надеяться на убедительность ваших доводов. Только беспрекословное повиновение и готовность принять наказание за ошибочно принятые им решения. «Наказание невиновных и награждение непричастных» — старая формула руководства.

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

Ну, а если вам повезет встретить на внедрении хороших руководителей, то к хорошему вы привыкните быстро.

Удачи вам!!!