Меня зовут Михаил Андреев, я руководитель проектов в компании «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.
Приглашаем на конференции Инфостарта 2025 годаINFOSTART TEAMLEAD EVENT
Не только для разработчиков, но и для руководителей отделов разработки, тимлидов и ИТ-директоров. INFOSTART A&PM EVENT (Анализ & Управление проектами)
Практическая конференция для аналитиков и руководителей проектов 1С. |