Интегратор на платформе 1С, который первым адаптирует Agile под Waterfall, усилит свои позиции на крупных проектах 1С

Пролог

Так уж случилось, что методика проектных внедрений на платформе 1С осталась в реалиях 1998-2011 годов и с тех пор не менялась. Я о классическом водопаде. Тем не менее, реалии таковы, что даже на крупнейших waterfall-проектах автоматизации на платформе 1С (я о бюджетах 200 - 600+ млн. руб.) начинают появляться отдельные agile-инструменты и врезки.

От чего бежим?

Привожу неполный перечень слабости существующего водопадного проектного подхода:

1. На ОПЭ (опытно-промышленная эксплуатация) выясняется, что Заказчику нужна другая система по кратно возрастающему бэклогу требований к системе. Значит, издержки, которые интегратор нес на предыдущих этапах, были пустой тратой денег;

2. Из-за п. выше на ОПЭ кратно возрастает потребность в специалистах (разработчиках). Удовлетворить возросший объём интегратор не в силах. Привлекаются разработчики субподрядчиков;

3. Чем больше разработчиков привлекается, тем более удручающая картина с качеством каждого последующего спеца. Мне известные неединичные случаи, когда даже из инкубатора стажеров, которые 2 недели назад открыли жёлтую книгу по 1С в консультанты направляли. Это сказывается на качестве, сервисе и имидже интегратора;

4. Чувствуется риск парадигмы внедренца 1С 1998 - 2011 годов, когда можно было найти некоего спеца, который в одиночку внедрит 1С-ку либо всем всё ответит и по технической, и по функциональной части. Сейчас и бизнес-приложения, и платформа 1С стали комплексными. Возникла потребность координации команды и налаживании коммуникаций, а не единоличной разработке звёздного внедренца-единоличника.
   
   Показательный провокационный вопрос, заданный мне на собеседовании: "Можешь внедрить расчёт себестоимости, получив на входе табличку Excel?" Так можно было спросить до 2011 для Заказчика - розничной неавтоматизированной торговой точки на 1 продавца. В случае нетиповой себестоимости БП, ERP, УХ - нет. Там будет целый пакет документов и работа полноценной проектной команды. Я не ставил своей целью портить отношения, поэтому тактично намекнул на участие в процессе методологов;

5. На ОПЭ Заказчику не разворачивается Helpdesk, держа руку на пульсе реального использования системы и мягко готовя его к заключению хотя бы годового контракта на сопровождение;

6. На ОПЭ, учитывая, что по факту, реальная автоматизация стартует лишь с него, не запускаются ночные автотесты, гарантирующие стабильную работоспособность критического контура и регрессионное тестирование;

7. Качество проектной документации оставляет желать лучшего. Эти тонны макулатуры неизвестно, куда девать и для какого мегамозга они предназначены. Сравните описание какого-нибудь Яндекс сервиса / API и свои проектные документы;

К чему идём?

1. Еще по состоянию на 2014 год (компания Сантехкомплект, моя роль Технический архитектор) мы использовали на проекте Scrum. Но инструментальной базы не было. Scrum был лишь орг. методикой;

2. Инструментальная база появилась году к 2018 (см. доклад Глеба Стального);

3. Обнаружилось противостояние Agile / Waterfall: команды, работающие по Agile, не готовы сотрудничать с Waterfall Заказчиками. Последних в свою очередь отталкивает открытый бюджет. Что делать: Agile либо терять Заказчика? Ответ есть: PMI + Scrum (Scrumban) - когда проект согласуется по классике водопада, но составные подсистемы реализуются по Agile;

4. П. 3 подтверждает то, что отдельные методики и инструменты Agile начали применяться даже гос. Заказчиками (проект крупнейшего энергетического холдинга Интер РАО ЕЭС, моя роль: Технический архитектор). Например, еженедельные релизы, статусные встречи, автотесты, чтобы иметь стабильный контур, отлавливая ошибки до попадания в продуктив;

5. Отдельно отмечу существующие CI / CD конвейеры фирм 1С и КРОК;

6. Но конвейеры из п. выше - это очень дорого (не Lean). Возможно снизить издержки? Да, масштабированием и автовидеоинструкциями (нововведение Vanessa BDD). Предоставляя в первых 3-15 минутах еженедельных статусов автоматически созданные видеоинструкции и обеспечивая таким образом раннюю проверку гипотез, отметая мертворожденное, можно добиться успехов ВкуссВилл в мобайле (кейс с применением Lean Startup и MVP для вовлечения Заказчика с самых ранних этапов Waterfall - проекта);

7. Как это выглядит? До MVP создаётся его критический контур и записывается автовидеоинструкция для статусной встречи. Получаем добро - отправляем в MVP (либо ОПЭ, опытно-промышленную эксплуатацию в терминах водопада; суть в запуске MVP с первых двух недель waterfall-проекта, хотя бы в виде автовидеоинструкций ванильной типовой; затем наполняем её по совету Глеба Стального НСИ, пока готовится функциональность). Очень упрощённо (лишь 30 секунд) подобная видеоинструкция может выглядеть так (и голос, и эффекты автоматически записаны из 1С на основе ~40 строчного скрипта);

Обо мне

1С Product Owner. Мой профиль в LinkedIn