Наша компания занимается проектами с 2015 года. За это время было, конечно, много успешных кейсов. Но учимся-то мы на чем? Конечно, на своих провалах.
Если сходу говорить, как они выглядели в нашем случае, то выглядело это так: проекты, простите, протухали. Начиналось все бодро, весело, но потом возникал перерыв. Потом смотришь – прошло полтора года, выполнено всего 20% запланированных работ, заказчик уже не помнит, зачем он все это начинал, а твои специалисты активно занимаются другими задачами.
Мы заметили эти симптомы и начали активную работу по исправлению, наверное, еще в 2021 году. Сейчас такого, конечно, практически не наблюдаем. Не обо всех принятых нами действиях я расскажу в статье, но об основных, о главных принципах, которые касаются именно того, как связаны декомпозиция работ по проекту и ее дальнейшее попадание в текст договора.
Главный принцип в том, что можно и нужно использовать текст договора как инструмент управления проектом, как инструмент для прозрачного отношения сторон к работам и для нахождения общего языка. Мой главный принцип заключается именно в этом.
На мой взгляд, принципы прозрачности при декомпозиции работ и принцип нахождения общего языка полезны и находятся в интересах обеих сторон заключения проектного договора.
Мне самому близок продуктовый подход. Но заказчики часто нуждаются в выполнении проекта, чтобы для них выполнили определенный объем работ. Сейчас у нас уже собрана команда, и, как я уже рассказывал, набиты свои шишки. Есть некоторые выводы и лайфхаки, которые мы применяем в работе и которыми хочу с вами поделиться.
Первый контакт с клиентом и работа с анкетой
С чего все начинается? Начинается все с разговора, как правило, телефонного. Первое впечатление о вас складывается в первые пять минут общения: встречают по одежке.
Расскажу, как, на мой взгляд, следует поступать подрядчику. В общем, так ведем себя мы при общении с новым потенциальным заказчиком.
Первое, что нужно сделать, – это, конечно, понять и услышать боль клиента и сегментировать его. Если, например, это вообще не ваш профиль, нужно предложить ему обратиться к партнерам или прямо передать контакт, с его разрешения, вашим партнерам. Например, вы не занимаетесь маркировкой, вы IT-компания, и, соответственно, передаете клиента партнерам, которые в этом деле квалифицированы.
Что делаем мы, если есть запрос на проект? Мы предоставляем анкету. Также считаем, что длинный созвон на час-два, где обсуждаются детали проекта, – это утомительно, сложно и малоэффективно. Гораздо лучше использовать под каждый тип проектов отдельную анкету. Про то, какие у нас бывают типы проектов, поговорим чуть позже.
Если вы видели и сталкивались с типовыми предпроектными анкетами у 1С-франчайзи, то, может быть, знаете, что они просто монстрические. Там огромное количество полей, вкладок и страниц. Так делать не надо.
Если сегмент другой, то есть рассматривают приобретение лицензии на ПО, мы предлагаем демонстрацию, чтобы можно было все проверить вживую. Если это автоматизация бизнеса, предлагается предпроектное обследование бизнес-процессов заказчика.
У нас есть еще такая опция – демонстрация продуктов на данных заказчика прямо на его сервере. Делает ее наш специалист, но на данных заказчика. Многих заказчиков это сразу подкупает. В этом случае мы также просим заполнить анкету. Почему? Чтобы заранее найти общий язык. Чтобы не оказалось, что когда уже звонит технический специалист для выполнения этих работ, возникает недопонимание: заказчик думал, что ему выполнят бесплатный проект. Менеджер заранее все проговаривает, и по ответам анкеты это тоже удобно делать.
К этой статье приложена наша реальная анкета на проект переноса данных 1С. Можно увидеть, что она существенно короче и проще. Понятно, что такой список вопросов удалось составить путем длительной практики. Но и она неидеальна.
Мы недавно обсуждали, например, ситуацию, когда нужен или не нужен онлайн-обмен между двумя базами 1С во время проекта. Если выбрали ответ «нет, не нужен», то несколько последующих вопросов про его условия и детали лучше скрывать. Разумеется, сейчас техническими средствами этого добиться нетрудно. Все-таки лучше, конечно, унифицировать анкету под каждую конкретную ситуацию.
Я уже вскользь несколько раз об этом говорил: на чем мы в этом случае специализируемся? Мы делаем именно проекты переноса данных 1С. Это можно еще назвать техническим переносом данных.
В чем отличие от полноценного внедрения 1С? Нет анализа бизнес-процессов, обучения, какой-то другой помощи с внедрением. Результат работ – это все-таки не функционирующая информационная система на предприятии, а некая база, в которой, допустим, совпадает оборотно-сальдовая ведомость и совпадают остатки.
Такие проекты гораздо легче декомпозировать на типовые этапы. И выполнить их тоже понятнее и проще: здесь подразумевается меньше скрытых работ.
Декомпозиция и типовые этапы проекта переноса
Это типовые этапы именно такого проекта переноса данных:
-
Тестовый перенос остатков и НСИ
-
Тестовый перенос документов, начиная с даты остатков (например, один месяц)
-
Рабочий перенос остатков и НСИ на выбранную дату остатков рабочего переноса (делается после закрытия периода)
-
Рабочий перенос документов за период с даты остатков до текущей даты (тарифицируется за первый месяц и дальнейшие)
Обратите внимание: в зависимости от вида переноса, конфигурации заказчика, объема данных в его базе мы оцениваем каждый отдельный этап.
Первые два этапа – это отладка инструмента под данные заказчика. Третий и четвертый этапы – это уже рабочий перенос, после которого подразумевается, что база 1С используется в эксплуатации.
Что еще к этим этапам часто можно и нужно добавлять? Например, настройку онлайн-обмена и его отладку: чтобы можно было выполнить плавный переход и чтобы данные между базами переносились так, как это требуется предприятию.
Сравнение IT и строительства: методы предварительной оценки работ
Давайте немного отвлечемся от этого вопроса и поговорим про такую интересную метафору, как сравнение IT-отрасли и строительной отрасли.
Наша с вами IT-отрасль – достаточно молодое явление для человечества. А строительством люди занимаются много тысяч лет, может быть, 5 000 лет. За это время разработаны нормы, правила, построены пирамиды.
Интересные аллегории я разложил в таблице. У строителей есть смета, а у нас с вами – бюджет проекта. У строителей есть строительный проект, у нас – техническое задание. У них есть типовые проекты строительства, например домов, а у нас с вами – коробочное программное обеспечение.
Но что дальше? Какой следующий шаг мы можем сделать, если провели такую аллегорию? Мы можем воспользоваться нормировками видов работ и использовать это для предварительной оценки проектов.
О чем я говорю? Эта идея позаимствована из книги Рустэма Валиева «1С:Франчайзи на грани нервного срыва». Автор рассказывает, как они проводят экспресс-оценку работ. То есть как в строительстве: покраска потолка за квадратный метр – такая цена, шпаклевка стен – такая цена и так далее.
То же самое можно и нужно делать на типовых проектах, которые выполняют подрядчики. Либо, если вы находитесь со стороны заказчика и похожие задачи уже ставили для своих подрядчиков, в следующий раз можете подобным образом их оценить: какие виды работ предполагаются, какой объем их предполагается.
В книге Рустэма Валиева рекомендуется в зависимости от сложности конфигурации использовать таблицу поправочных коэффициентов и умножать. За более подробной информацией рекомендую обратиться к автору. Там буквально две-три странички, все очень четко разобрано.
Управление ожиданиями и поиск общего языка
Когда в нашей практике приходит входящий звонок, например, поступает запрос на приобретение какого-то продукта, часто можно заметить одну вещь. Для меня это просто интересный мысленный эксперимент: решение заказчик на самом деле уже принял. Ему нравится продукт, он ему интересен. Он звонит только затем, чтобы понять, что вы существуете, вы реальны, вы более-менее адекватны. И буквально после такого короткого разговора принимается решение о покупке коробочного продукта.
С проектами ситуация другая. Там, я считаю, нужно доказывать свою компетентность каждый день. И самое главное – это управление ожиданиями заказчика. Если вы заказчик, вам тоже нужно управлять своими ожиданиями.
Что я имею в виду? Я считаю, что, если все стороны – порядочные люди и порядочные предприятия, главным критерием для хорошего управления ожиданиями является нахождение общего языка.
Вы можете заметить, что даже внутри вашей компании, иногда даже внутри отдела, люди на самом деле говорят на разных языках. Разные профессии используют разные термины, чуть ниже приведу примеры из реальных документов.
Пока не найден общий язык, пока нет понимания, не будет такого диалога, как у этой кошки с собакой. Именно тогда появляются какие-то двойственные ситуации. На самом деле вы, наверное, в жизни тоже сталкивались с тем, что вторая сторона, если она недобросовестная, может использовать некоторые термины, подразумевающие двойственную трактовку, в своих интересах.
Например, говорить: «А мы думали, что вы сделаете нам то-то, то-то и так-так-так». Или: «А мы думали, что это будет в следующем договоре, а здесь мы выполним какой-то маленький объем работ».
С опытом, с практикой такие вещи, когда вы разговариваете на разных языках, можно предвосхищать. Есть некие слова-триггеры. Понятно, в каждом направлении проектной деятельности они разные. Они работают как red flag: срабатывают, и вы понимаете, что тут надо поговорить поподробнее.
Разбор неоднозначных формулировок и взаимодействие с юристами
Это пример, очень короткая цитата из конкретного ТЗ заказчика:
Вроде все понятно написано: выгрузка такого справочника, выгрузка другого справочника. А что может пойти не так?
Суть в том, что менеджер по продажам, обсуждая это с заказчиком, мог подразумевать, что будет выполнена только разработка инструмента для такой выгрузки данных. А заказчик может подразумевать, что ему эти работы выполнят от и до.
Это нужно дополнительно проговаривать. Эти короткие формулировки нужно более подробно расписывать. Без этого будет возникать недопонимание, и ожидания у сторон проекта, соответственно, будут разные и неудовлетворительные.
Вы мне сможете сказать: «Ну договор-то как-то составили, подписали. А кто вообще должен проверять договоры?» Есть такая отдельная профессия, ее название рифмуется со словом «юмористы».
Некоторые коллеги с болью о них говорят: мол, они все время докапываются до договора, до предмета работ. Но тут у нас с вами получается другая сторона медали.
Юристам сложно понять суть задачи: нужны ли эти работы, как они подразумеваются, правильно ли в договоре описано то, что должно быть сделано.
На изображении реальный кейс. Я ничего плохого про юристов не говорю, и в данном случае это очень толковое обращение от них. Но когда читаешь такой текст, немного попадаешь в замешательство. Появляется следующая мысль: тут надо разобраться, человек говорит на другом языке. Для меня это непривычно и непонятно.
С этими терминами с юридической точки зрения можно ознакомиться, вникнуть и что-то ответить на это обращение. Но нужно напрячься и, как я уже несколько раз иллюстрировал, найти общий язык. Даже юристам приходится писать ответы на их языке.
Практические рекомендации по структуре договора и коммерческому предложению
Если вернуться к теме нашей статьи, можно заметить: речь о том, чтобы собрать кирпичики, то есть выполнить декомпозицию работ проекта, предоставить заказчику выбор. Дальше может быть несколько сценариев: в этом сценарии будут такие этапы работ, а в этом – другие этапы.
И зацементируйте эти кирпичики, то есть скрепите договоренности договором. Метафора такая. Она здесь немного другая, чем когда мы сравнивали параллели IT-отрасли и строительной отрасли.
Какие есть конкретные практические рекомендации от меня и от специалистов нашей компании, которые занимаются подготовкой договоров?
Лучше всего декомпозицию и сценарии выполнения проектов, то есть то, что точно просит заказчик и что предлагают наши специалисты, писать уже на этапе коммерческого предложения. Почему? Потому что, если потом будут изменения, будет легко к этому обратиться.
Тут нужно добавить немного юридических слов. Вообще говоря, по закону в договоре есть такое понятие, как полная стоимость. Есть объем работ, у него есть полная стоимость. Именно так должен выглядеть договор.
Но на практике мы, и, я думаю, многие коллеги тоже, добавляем такой пункт: в случае появления дополнительного объема работ заключается дополнительное соглашение, и работы оплачиваются по такой-то ставке в час. Такой пункт есть у многих IT-компаний.
Что уж говорить: на практике бывает так, что по небольшим задачам без заключения дополнительного соглашения, на основании этого пункта выставляются счета и актируются. Как я уже сказал, юридически это не совсем корректно, но на практике многие это применяют.
Фиксация объемов работ по периодам: выгода для обеих сторон
Какой еще практический совет я хотел бы рассказать из своего опыта? Мы рекомендуем и сами практикуем добавлять в договор такие пункты, как определенный объем работ, сделанный, например, за месяц работы с данными. Например, перенос документов за февраль, перенос документов за март – то есть за один месяц. Или помощь с закрытием месяца по регламентированному учету – тоже за один месяц.
Опять возвращаемся к вопросу, что это не совсем верно с юридической точки зрения. Но это позволяет в ситуации, когда проект затягивается, главбух в марте закрыла прошлый год, в апреле занималась сдачей отчетности, а в мае ушла в отпуск, подстраховать подрядчика. То есть в этой ситуации со стороны заказчика происходит задержка, и подрядчик, соответственно, подстрахован.
А что хорошего в этой ситуации для стороны, которая выступает заказчиком? Мы не раз сталкивались с тем, что на предприятии согласование дополнительного соглашения может занимать две-три недели. И IT-директор сам настаивает на том, чтобы подобные вещи были заранее зафиксированы в договоре, и благодарен за это. Если понадобится производить какие-то работы больше месяцев, этап согласования снова проходить не придется. Ведь это ему придется ногами обходить кабинеты.
Тут я бы добавил поправку: пока не возникнут разногласия.
Работа с изменениями в проекте и сценарный подход
О чем хочу поговорить дальше? Об изменениях проекта, необходимость которых появляется уже в процессе выполнения.
Во-первых, вернусь к тому, о чем говорил. Если на этапе коммерческого предложения предложили несколько сценариев и в разных ситуациях этапы были собраны как из кирпичиков, заказчик сам уже знает, к чему готовиться, если поменял сценарий в процессе.
Давайте на практике, чтобы не было путано. Часто выбирают такой вариант: обращаются, например, в августе и говорят: «Нам нужно перенести все документы за весь текущий год».
Мы с вами уже говорили: каждый месяц тарифицируется. Оценка получается достаточно высокая, потому что за каждый месяц будет определенный объем переноса, выверки данных и закрытия месяца. Ведь это уже закрытые периоды, поэтому стоимость отдельно высокая.
Подрядчик предлагает альтернативный вариант – подождать конца года или закрытия года и так сделать перенос. В чем плюсы? Объем работ существенно меньше. Но заказчик все равно выбирает свой сценарий. Несколько месяцев все мучаются. Понятно, что есть этап внутренней приемки и внешней приемки. Выполнение такого проекта – это всегда обоюдная работа. Нередки ситуации, когда после выполнения таких работ все-таки приходят к сценарию, где переносят только остатки, – к сценарию, который подрядчик изначально и предлагал.
Больших затруднений в этом случае не происходит. Почему? Потому что коммерческое предложение было предоставлено. Как изменится стоимость и какие будут этапы, также известно еще до заключения дополнительного соглашения об изменении объема и стоимости работ.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции Анализ & Управление в ИТ-проектах.