Я хотел бы рассказать о проекте, который был и провальным, и успешным одновременно. На середине пути этот проект был однозначно провальным, а к концу он стал успешным – я расскажу о том, как мы этого достигли.
Акцент будет сделан на управленческой части, хотя с точки зрения использования прикладных решений, мой доклад во многом перекликается с докладом Андрея Овсянкина и его подсистемой 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, т.к. у нас удаленная команда разработки. Это открытое приглашение поучаствовать – пишите мне, я вас добавлю без проблем. Единственное условие – участвовать можно только в режиме слушателя, т.е. отключайте микрофон и слушайте, что происходит, не комментируя происходящее.
И третий вариант – это прочитать статьи. Я сделал подборку статей, которая мне помогла, могу поделиться (gleb@stalnoy.ru).
****************
Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2017 COMMUNITY.
Больше статей можно прочитать здесь.
*************
