Грань будущего, или Как не зафакапить сроки и остаться в границах проекта

Меня зовут Михаил Андреев, я руководитель проектов в компании «1С-КПД Корпоративные порталы и документооборот».

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

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

Немного спойлеров про доклад.

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

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

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

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

Фиксация границ проекта как основополагающий инструмент избегания рисков

Управление любым проектом заключается в систематической работе по снижению рисков.

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

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

Давайте обозначим основные границы, которые необходимо документировать и хотя бы прописывать в уставе проекта.

Начнем с временных границ.

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

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

• к начислению штрафов, пени;

• к выставлению со стороны заказчика официальных претензий;

• и в конечном итоге приведет к бесконечному циклу итераций согласования и приемки работ.

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

Кроме этого, очень важно фиксировать организационные границы.

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

В условиях Федерального закона №223 заказчик будет вправе вас даже съесть, поскольку такие договоры составляются, как правило, в пользу заказчика.

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

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

Однажды мы на проекте упустили этот момент и оценили заказчику интеграцию между 1С:Документооборотом и 1С:Зарплатой и управлением персоналом по справочнику «Сотрудники» только в рамках типового плана обмена.

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

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

Кроме этого, в уставе проекта или договоре очень важно фиксировать методологический объем проекта.

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

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

Например, мы внедряли информационную систему в строительной организации, а сейчас внедряем в консалтинговой компании. Специфика этих компаний существенно отличается. Даже специфика работы компаний, работающих в одной отрасли, может сильно отличаться. И цепочка согласования в этих компаниях тоже может быть разной: в одной компании 10 согласующих, в другой компании согласующих 2 – это тоже зависит от количества пользователей.

В результате ваши аналитики просто переквалифицируются из реальных аналитиков системы в писателей-фантастов. Это никому на проекте не нужно.

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

Мы прописываем в уставе проекта ландшафт разрабатываемой системы и ответственность за этот ландшафт со стороны заказчика и со стороны исполнителя.

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

• А со стороны исполнителя тоже к определенной дате проводятся работы по созданию хранилища и публикации баз.

Отсутствие фиксации технического объема проекта может привести к тому, что:

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

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

• Или при реализации проекта окажется, что мы не можем задействовать в проекте все запланированные ресурсы, и вместо пяти разработчиков у нас в проекте будет участвовать только двое. Представьте, мы скажем заказчику: «Давайте вести разработку посменно на неактуальных для вас базах. Некий Николай будет вести разработку до 20:00, некий Петр будет вести разработку после 20:00 по ночам и в выходные дни». В итоге мы реализуем проект не за два года, как планировалось, а за пять лет.

Следующее, что нужно зафиксировать – это ограничения проекта в количественном выражении.

Например, если мы внедряем 1С:Документооборот, это может быть:

• количество видов документов;

• количество шаблонов процессов обработки этих документов;

• количество пользователей.

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

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

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

У нас был случай, когда мы внедрялись по технологии Waterfall, а этап разработки заказчик предложил нам проводить по методологии Agile – по Scrum. При этом заказчик не мог не осознавать возможные риски такого подхода, потому что в ходе проекта менялась технология внедрения.

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

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

Все это в основном касается теории. Давайте наконец-то перейдем к практическим кейсам.

Практический опыт составления план-графика. Как мы нарвались на претензию и заплатили заказчику за воздух

Расскажу про реальный кейс, который случился на нашем проекте.

Проект состоял из двух этапов.

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

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

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

Также в рамках этого проекта была задействована интеграция с одной из систем. И заказчик должен был нам предоставить выгрузку из этой системы еще в июне, чтобы мы заранее загрузили в 1С:Документооборот исторические данные согласно этой выгрузке. Но к июню заказчик эти данные не предоставил, и мы их получили только спустя 4 месяца.

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

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

Чему нас учит эта история?

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

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

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

Время – деньги! Кейс про разработку ТЗ, которое вылилось нам в лишний месяц написания кода

Еще один интересный кейс – о том, как некорректно составленное ТЗ вылилось нам в лишний месяц написания кода.

У нас была запланирована интеграция между 1C:Document Management и 1С:Управление производственным предприятием – нужно было внедрить заявки на отпуска и настроить для них миграцию из первой системы во вторую.

Но, поскольку мы не владели тогда кадровым делопроизводством, мы не учли одну особенность – документ «Заявка на отпуск» из 1C:Document Management должен был мигрировать в документ 1С:УПП «График отпусков организации». Но связка должна была быть не один к одному, как мы это прописали в ТЗ, а несколько к одному. То есть пользователи генерируют в 1C:Document Management заявки на отпуска, и вся эта куча заявок на отпуска должна была мигрировать в один документ 1С:УПП разными строками.

Очнулись мы только на сдаче работ – заказчик был немного шокирован, что мы сделали совершенно не то, что он хотел. И в итоге нам пришлось все переделывать.

В том же проекте была вторая особенность – там была также запланирована бесшовная интеграция между 1C:Document Management и 1С:УПП по договорам. Однако при разработке ТЗ мы не учли, что в 1C:Document Management есть два интерфейса – английский и русский. И нам пришлось в 1С:УПП переделывать все формы – переводить их на английский язык. Мы забыли это сделать и тоже только на сдаче работ очнулись.

В итоге это все привело к тому, что вы сейчас видите на слайде.

• Ошиблись в ТЗ.

• Впустую вели разработку в течение двух месяцев.

• Заказчик отказался принимать работы.

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

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

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

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

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

Наверняка многие руководители проектов оказывались в ситуации, когда один департамент говорит одно, второй департамент – совершенно другое, а третий департамент – третье. У меня тоже была подобная ситуация на проекте:

• Юридический департамент сказал: «Кнопка должна располагаться слева на форме».

• Департамент информационных технологий сказал: «Удалите кнопку, она вообще мешает».

• А бухгалтерия сказала: «Какая красивая кнопочка, сделайте ее, пожалуйста, пожирнее».

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

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

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

• И в итоге на сдаче работ мы получаем непринятие работ заказчиком. Вы реализовали, как хотел юридический департамент, а бухгалтерия говорит: «Нет, мы такие работы не примем!»

Рекомендую вам:

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

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

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

Вопросы и ответы

Вы в докладе рекомендовали фиксировать сроки по каждому этапу. Но по моему опыту, на практике это не работает, потому что сроки каждого этапа зависят от объема работ по каждому этапу, а объем работ каждый раз меняется. Как можно зафиксировать сроки каждого этапа, когда мы еще не знаем полный объем работ – он дополняется в результате разработки?

Встречный вопрос: почему у вас меняется объем проекта?

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

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

Лучше быть с заказчиком честным – объяснить ему ситуацию и при необходимости заключить дополнительное соглашение.

Кто конкретно должен определять границы проекта?

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

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

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