История одного провала внедрения 1С:ERP 2 по классической технологии. С последующим спасением по Scrum

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

Акцент будет сделан на управленческой части, хотя с точки зрения использования прикладных решений, мой доклад во многом перекликается с докладом Андрея Овсянкина и его подсистемой Yellow RabbitMQ. В практике “БИТ:ERP” мы начали использовать эту подсистему именно на этом проекте – на провальных проектах очень многое меняется, и ты учишься на них гораздо больше, чем на успешных.

О проекте

Речь пойдет о реальном проекте внедрения «1С:ERP 2» на сети оптовых нефтебаз и заправок.

Заказчик проекта – АО «Красноярскнефтепродукт» (КНП), организация, имеющая 14 распределительных нефтебаз, обслуживающих почти каждый район Красноярского края. Расстояния между филиалами достигают до полутора тысяч километров. Несмотря на то, что это один регион, расстояния там большие – это накладывало определенную специфику на проект.

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

Проектом занимались мы, направление «Практика “БИТ:ERP”». Коротко об особенностях нашей работы.

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

Коротко о самом проекте – это внедрение практически всех подсистем «1С:ERP» и написание своего модуля учета нефтепродуктов.

Автоматизируемая отрасль имеет определенную специфику, поэтому использовать для учета полностью типовой 1С:ERP невозможно, но участки расчета себестоимости и регламентированного учета мы в конфигурации не меняли. Главной задачей этого проекта была разработка с «нуля» модуля оперативного учета нефтепродуктов, который генерировал уже типовые документы.

Здесь перечислены программные продукты, с которыми нам пришлось работать.

Расскажу про основные вехи проекта:

• В ноябре 2015 года мы бодро и амбициозно начали свою работу. С точки зрения методологии мы использовали классический «каскадный» подход, который всем дорог и близок – большую часть своей сознательной деятельности я внедрял проекты по «каскаду».
• К февралю 2016 мы закончили проектирование. На этом этапе мы в рамках лучших рекомендаций по каскадному подходу использовали прототипирование, потому что увидеть всегда лучше, чем прочитать – мы для своих проектов всегда делаем контрольный пример (или, как его еще называют, функциональную модель).
• Параллельно мы начали разрабатывать – так делают практически в любом проекте по «каскаду». И к апрелю 2016 года мы завершили разработку системы.
• К маю 2016 у нас с точки зрения интегратора уже все было готово: мы завершили проектирование системы, подписали проектное решение, завершили разработку, провели тестирование, получили замечания, исправили их, подписали акты и даже завершили обучение пользователей. Причем, у нас было заложено не только обучение, но и аттестация – мы все это завершили.
  Но была одна небольшая проблема, причем не у нас, а у заказчика. Систему, которую он заказал, спроектировал, согласовал и протестировал вместе с нами, нельзя было запустить в эксплуатацию от слова «никак». Если брать каждый конкретный блок, то в соответствии с изначальной постановкой задачи все работало хорошо, но запустить всю систему целиком было невозможно. И директора филиалов достаточно подробно и живописно, используя богатую ненормативную лексику, на примерах объясняли нам, почему так нельзя сделать. В итоге мы запустили только блок «Казначейство», а по всему остальному заказчик принял решение «откатиться» на исторические системы.
• Потом где-то в течение месяца был перерыв, когда никаких активных работ мы не вели. Заказчик придумывал, как у нас отсудить деньги. Мы с ним вяло дискутировали, спрашивая, какие есть претензии «к пуговицам», на что он отвечал, что «к пуговицам» претензий как раз нет, проблема в том, что система не работает. Так мы и общались. В это время заказчик вел переговоры с другими командами внедрения, и, наверное, понял, что найти свободную команду с опытом внедрения ERP, которая сможет предложить что-то альтернативное, не начиная то же самое еще раз (не проводя заново проектирование, разработку и т.д.) у него вряд ли получится.
• В итоге финансовый директор (спонсор проекта), пригласил нас на встречу и задал достаточно простой вопрос: «Хорошо, а что вы можете предложить?». Надо сказать, что у меня до этого момента ни разу не было ситуации, чтобы система не запустилась вообще. Были случаи, когда «плевали в спину», но систему все равно, сжав зубы, использовали. А здесь возникла ситуация, что время и деньги уже были потрачены, но система в эксплуатацию так и не запустилась. 60% бюджета мы на тот момент уже «съели», было понятно, что на очередной эксперимент заказчик столько же денег уже не даст и сроки были даны короткие. Этих двух моментов было достаточно, чтобы я начал смотреть в сторону Agile и Scrum, потому что там заявлялось, что проект можно сделать в короткие сроки и с ограниченным бюджетом. В итоге заказчику было сформулировано предложение о том, что мы попробуем запустить часть функциональности без увеличения бюджета, и, если система заработает, то с вменяемым увеличением бюджета мы сможем запустить ее целиком.
  В первоначальные сроки мы уже тогда не вписались, потому что запустить систему нужно было в апреле, а мы находились в июне и «машины времени» не существует. Но мы решили, что нужно попробовать, тем более, что деньги еще оставались, и другого выхода ни у заказчика, ни у нас тогда не было. А когда нет выхода – резко стимулируются инновации.
• Дальше все пошло гораздо бодрее. Конечно, были и проблемы – когда ты в ситуации катастрофы внедряешь новую технологию, говорить, что нет проблем – это неправда. Ночью я читал книги и статьи в Google о том, как можно решить наши проблемы, а утром пытался применять прочитанное – в результате получал обратную связь от сотрудников, они мне что-то предлагали. Дальше я опять углублялся в изучение той документации, которая есть в интернете и книгах – это происходило циклически. Всегда оказывалось, что все наши проблемы не уникальны, и их уже лет 10 назад 150 раз обсудили на форумах. Нам это сильно помогало, потому что когда ты формулируешь проблему – этого достаточно, чтобы ее решить. Просто выбираешь потом из нескольких вариантов то решение, которое тебе больше всего нравится, и используешь.

Инструменты

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

Дорожная карта

Начнем с «дорожной карты».

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

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

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

Инструменты взаимодействия внутри команды

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

• Были запрещены любые средства коммуникации, которые использовались до этого: E-mail, Telegram, Viber, WhatsApp – все системы, которые использовались сотрудниками для общения между собой.
• Skype мы оставили только для голоса и видео.
• Все общение мы перенесли в корпоративный мессенджер Slack. Раньше, когда на проект приходил новый сотрудник, он обычно не понимал, что происходило на проекте ранее: кто над ним работал, какие работы велись по его блоку (по «Складу», по «Казначейству», по закрытию месяца) – вообще ничего. Только со временем другие сотрудники, узнававашие, что есть новый консультант и его неплохо бы держать в курсе по вопросам «Казначейства», начинали включать его в копию переписки. Причем, когда в копию добавляли всех сотрудников (чтобы все были в курсе), почтовый ящик превращался в нечто неуправляемое. По нескольким параллельно идущим большим проектам у меня в пике приходило по две тысячи сообщений в день, причем это только по проектам, не говоря уже про все остальные переписки. Ознакомиться с таким потоком сообщений было невозможно. И практически невозможно было отфильтровать все это и понять: что тебе действительно важно и срочно нужно; что просто важно, но не срочно; а что можно и не читать. Slack позволил решить эти проблемы, поскольку он имеет несколько ключевых достоинств:
  • Все общение в Slack можно разбить на тематики. Если у тебя есть система, где все общение разбито по тематическим каналам, и сотрудники при написании сообщений привыкли разграничивать, в рамках какого канала обсуждаются те или иные темы, любой сотрудник может подписаться на интересные ему каналы.
  • В Slack есть гибкая настройка уведомлений, т.е. если тебя лично упомянули, ты получаешь приоритетное уведомление.
  • Есть множество возможностей, которые позволяют фильтровать поток информации и читать только нужные сообщения.
  • Slack устанавливается на телефон, iPad, Android-планшет и т.д. Это очень удобная система, хотя есть аналоги, например, HipChat от Atlassian и множество других продуктов, в том числе и бесплатных, которые позволяют делать то же самое.

Вот так выглядит интерфейс Slack – это скриншот общения по закрытию месяца.

Дальше – Wiki-система. Опять же, Wiki-систем много как платных, так и бесплатных, на все случаи жизни. Мы выбрали Confluence и перешли на документирование системы только в рамках Wiki, т.е. у нас все документы готовятся не в Microsoft Word, а в Wiki-системе Confluence. Причем, Confluence у нас связана с Jira, где с помощью Wiki мы описываем постановку задачи.

Дальше, Jira – в ней мы храним backlog и отслеживаем все задачи. В Jira у нас «живут» все: и разработчики, и консультанты.

Есть несколько правил по ведению backlog’а:

• Первое правило – это то, что все задачи по одному проекту должны быть в рамках одного backlog’а.
• Второе правило – backlog должен меняться, т.е. когда у нас есть список функциональных требований и он с начала до конца проекта не меняется – это неправильно.
• Третье правило – backlog всегда ориентирован на бизнес. Любая задача должна объяснять, какой выигрыш она принесет конкретным пользователям. Если этого не получается, надо очень сильно подумать – нужна ли эта задача, или от нее можно отказаться. Либо нужно переписать эту задачу так, чтобы она несла конкретную пользу. Это – «первое правило бойцовского клуба».
• Но на первое правило всегда есть и второе, которое оправдывает наличие тех редких случаев, когда задача конкретной пользы бизнесу не несет. Это правило касается управления техническим долгом. Здесь наша практика подтверждает общемировые тенденции: 10-20% задач в backlog’е относятся к техническому долгу.

Вот так выглядит реальный backlog с проекта разработки «коробки» «БИТ:MDM». Здесь показан не весь backlog, а только его часть.

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

Как мы планируем спринты

Как мы планируем спринты?

• В начале каждого спринта мы проводим встречу, где планируем задачи на спринт.
• Важный момент – мы сразу начинаем описывать сценарий демонстрации, т.е. сразу определяем, что мы хотим увидеть через одну, две недели.
• Планирование очень удобно проводить в Jira, где ведется список задач. Можно научиться этому самостоятельно – в сети есть множество видеороликов.
• Результаты планирования фиксируются в рамках Wiki-страницы, где описаны:
  • Имя и цель спринта;
  • Его результаты;
  • Ограничения;
  • И сценарий демонстрации.

На слайде показан пример такой Wiki-страницы.

Здесь вы можете видеть скриншот плана спринта с реального проекта – это всем известный Scrum Board. Эта страничка, кстати, является обязательным атрибутом нашего процесса управления проектом. Она должна быть всегда, и каждый пользователь Jira, даже если он в этом проекте не участвует, всегда может с ней ознакомиться. Для нас это своеобразный Best Practices.

Stand-up

Очень важная проблема, о которой нужно рассказать – это ежедневные стендапы (их еще называют «ежедневный Scrum» или «летучка»). Согласно технологии Scrum они должны укладываться в 15 минут. Мы, прочитав все книжки, поняли, что в составе команды должно быть не более семи человек, и разделили один большой проект на несколько команд, но в 15 минут мы ни разу не укладывались.

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

Мы нашли для этого очень простое решение и стали проводить стендапы в «гибридном» режиме:

• Все участники перед совещанием пишут в Slack ответы на вопросы «Чем занимался вчера?», «Чем буду заниматься сегодня?» и «Какие препятствия есть?».
• И на стендапе мы обсуждаем именно то, что должны обсуждать – препятствия к выполнению задач.

После того, как мы это поняли, дело пошло. Мы очень быстро нашли инструмент для Slack под названием Geekbot. Это очень хороший помощник руководителя проекта – аналог администратора, который никогда не болеет, не просрочивает задачи и всегда очень удачно собирает отчеты о текущем положении дел.

• Он стучится в Slack каждому участнику проектной команды и пишет персональное сообщение: «Что ты делал вчера по этому проекту?».
• Кроме этого, он не обидчивый. Если сотрудник занят и не может ему ответить, бот через некоторое время спрашивает опять: «Чем ты вчера занимался?». И так потихоньку с возрастающей регулярностью «достает» сотрудника до начала стендапа.
• Если человек с ботом не договорился, подключается руководитель проекта, который объясняет, что игнорировать бота – это плохо. В любом случае, ситуация «Я забыл сделать отчет» у нас исчезла.
• Чем еще хорош бот – он очень хорошо умеет делать гениальные отчеты и никогда не «косячит» – отчет отображает именно те данные, которые нужно.
• По каждому конкретному проекту автоматически наполняется канал, где для каждого сотрудника четко написано, что он делал.

Если у вас используется Slack – попробуйте этого бота, я всем рекомендую, это очень удобно. А если у вас используются другие программные продукты, обязательно найдите для них что-то аналогичное или сделайте сами. У нас есть идея разработать это на 1С, но пока руки не дошли.

Демо

Как мы проводим демо?

• Первое правило – даже если на демо показывать нечего, мы собираемся и обсуждаем, как так получилось, что за две недели разработки нашего «коробочного» решения нам нечего показать. Конечно, можно придумать множество причин, почему демо не нужно показывать:
  • Например, потому что к нему надо долго готовиться, а если мы не подготовимся, то ничего работающего показать не сможем.
  • Или потому что мы на демо убиваем много времени, а надо кодировать.
  • Если спросить участника проектной команды, почему надо отменить это конкретное демо, он придумает 10 железобетонных причин, каждая из которых в отдельности будет не глупой отговоркой, что «я плохо себя чувствую», а вполне обоснованным, привязанным к бизнесу аргументом – например, что когда проводим демо, мы теряем деньги и т.д.
• Но демо проводить нужно, потому что именно на нем выясняется, что у нас ничего не работает и рассказы о том, что работает – это вранье. Существует «эффект демо» – когда до демонстрации все работало, а на ней вдруг почему-то работать перестало. Разработчик начинает что-то показывать и у него задача за задачей «отваливается», не работает – это производит гнетущее впечатление. Конечно, всегда можно оправдаться, почему это сейчас не заработало, но когда для десяти задач находится десять оправданий – значит, что-то пошло не так.
• Демо мы проводим всегда. И с каждым разом оно улучшается.
• Главный лозунг демо – это «Demo or die», т.е. или «Проведи демо или умри». Демо – это обязательно, дисциплина здесь является ключевым фактором.

«Разбор полетов»

В конце спринта мы проводим «разбор полетов» – так называемую «ретроспективу». На слайде показан примерный порядок такого «разбора».

С чего начать?

С чего начать, если вы хотите применить Scrum?

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

Второй вариант – вы можете поучаствовать в демо (к сожалению в связи со сложностью администрирования процесса от данного варианта решили отказаться) нашего проекта разработки «БИТ:MDM», оно у нас проходит в Skype, т.к. у нас удаленная команда разработки. Это открытое приглашение поучаствовать – пишите мне, я вас добавлю без проблем. Единственное условие – участвовать можно только в режиме слушателя, т.е. отключайте микрофон и слушайте, что происходит, не комментируя происходящее.

И третий вариант – это прочитать статьи. 

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2017 COMMUNITY.