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

09.09.24

Управление проектом - Кейсы проектов

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

Меня зовут Михаил Андреев, я руководитель проектов в компании «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

Не только для разработчиков, но и для руководителей отделов разработки, тимлидов и ИТ-директоров.
Место: Москва
Даты: 24-25 февраля 2025 г.

Подробнее

INFOSTART A&PM EVENT (Анализ & Управление проектами)

Практическая конференция для аналитиков и руководителей проектов 1С.
Место: Санкт-Петербург
Даты: 29-31 мая 2025 г.

Подробнее


См. также

Кейсы проектов Работа с заинтересованными сторонами Бесплатно (free)

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

12.07.2024    1040    0    1c-izh    1    

5

Кейсы проектов Бесплатно (free)

В двадцатом выпуске второго сезона подкаста Радио “Аналитик“ обсудили, как проходил запуск Lamoda Sport в части автоматизации, какие специалисты работали над этой задачей и что помогло запуститься в короткие сроки.

28.05.2024    601    0    Radio_Analyst    0    

4

Кейсы проектов Бесплатно (free)

Когда проект ограничен по времени, и уже через два месяца заказчик физически не сможет работать в старой системе, нет времени обкладываться бумажками – нужно быстро подготовить новую систему к переходу. Расскажем о том, как гибкие технологии SCRUM и ТБР помогли за два месяца адаптировать 1С:ERP под существующие бизнес-процессы компании.

07.02.2024    2992    0    izybaevda    18    

16

Кейсы проектов Руководитель проекта Бесплатно (free)

Как определить, что риск проекта высок настолько, что взяться за него – в 99% случаев значит потерять драгоценное время, деньги и другие ресурсы? Как еще до старта определить, что проект в лучшем случае на выходе станет пародией на задуманное, а в худшем – будет сорван? Сформулируем список типовых рисков срывов проекта и постараемся уберечь от ошибок внедренцев и заказчиков.

20.12.2023    4083    0    1СERP    21    

31

Кейсы проектов Бесплатно (free)

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

12.09.2023    1621    0    chat007    0    

5

Кейсы автоматизации Кейсы проектов Кейсы продуктов Программист Руководитель проекта Бесплатно (free)

В управлении проектами нет однозначных рецептов, особенно при взаимодействии с заказчиком из другой страны и другой культуры в проектах перехода из принципиально другой исторической системы. Расскажем об истории крупнейшего международного проекта перехода с SAP на 1С:ERP.

01.09.2023    2182    0    olegminkov    2    

10

Кейсы проектов Программист Бизнес-аналитик Пользователь Руководитель проекта Платформа 1С v8.3 1С:ERP Управление предприятием 2 Оптовая торговля, дистрибуция, логистика Россия Бесплатно (free)

В 2021 году начали проект в дистрибьюторской компании. Имели большой опыт внедрения УПП, но периодически возникали вопросы. Зачем что-то придумали в ERP, что стало менее удобнее, чем было в УПП? Почему нельзя было взять лучшие идеи из УПП и ERP и скрестить их? А идея, что обеспечение нужно выносить из заказов, с каждым новым проектом находила все большее подтверждение. В итоге на этом проекте удалось применить лучшие (на мой взгляд) методические решения, которые мне довелось внедрять в конфигурациях УПП и ERP, в т.ч. подход, что реагировать нужно только на важное (то, как на заре появления ERP Фирма 1С ее позиционировала).

05.07.2023    15480    0    ASchekachev    37    

55

Кейсы проектов Бесплатно (free)

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

15.05.2023    671    0    Radio_Analyst    0    

1
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. bossikd 94 09.09.24 11:25 Сейчас в теме
...пошел искать в интернете что такое "зафакапить сроки"...видимо уже стар.
Оставьте свое сообщение