Применение методологии внедрения проектов Майкрософт на проектах внедрения 1С.
Введение и предпосылки.
В свое время мне довелось поработать консультантом по внедрению ERP-системы MS Dynamics AX на одном из партнеров Майкрософт. Опыт был достаточно интересный если учесть, что до этого я 15 лет занимался 1С во всех возможных ролях начиная от программиста, заканчивая руководителем отдела внедрения.
Нужно сказать, что для внедрения ERP-систем Майкрософт использует свою собственную методологию SureStep по которой в обязательном порядке сертифицируются все сотрудники всех партнеров. Методология опирается на идеологию управления проектами PMI, по которой я в своё время сертифицировался. Поэтому SureStep мне что называется «зашла на ура».
Сначала в двух словах зачем всё это нужно и что это даёт на практике. У многих неспециалистов слово 1С часто ассоциируется с низким качеством, ненадёжностью и множеством проблем. Специалисты понимают, что объективно в такой репутации есть и доля вины самой 1С, но лишь очень небольшая. В основном же, на мой взгляд, причина кроется в низком пороге вхождения специалиста в отрасль.
Ведь действительно язык программирования – русскоязычный Basic, классов не так много, и они не сложные. Мне приходилось встречать и бухгалтеров, освоивших простейшее программирование и системных администраторов наловчившихся «поправлять формочки».
С одной стороны, это играет на руку популяризации продуктов 1С. С другой порождает «кривые» внедрения со всеми вытекающими.
Давайте попробуем разобраться почему же у международных ERP-систем сложилась репутация «дорого и качественно», а у 1С наоборот. На мой взгляд корень проблемы даже не в стремлении заказчика сделать по-быстрому и подешевле, оно естественно. Корень проблемы в непонимании и, следовательно, неумении специалиста внедряющего систему объяснить заказчику почему так делать нельзя и как нужно.
Еще одно наблюдение из практики в связи с этим – часто доработки делают сразу программисты со слов конечных пользователей. Это порождает сразу несколько проблем: 1) программист часто очень слабо понимает реальные бизнес-процессы (зачем всё это нужно) и 2) воспринимает слова пользователя как догму – раз бухгалтер сказал добавить колонку журнал документов, значит она ему нужна и это решит его (пользователя) проблему, а значит нужно делать и не рассуждать.
Во многом такая ситуация сложилась объективно из-за очень ограниченного бюджета проектов. С другой стороны, как по мне, то лучше не делать никакой автоматизации, чем делать как попало, тем самым порождая только новые проблемы.
Как сказал один умный человек: если ты сделаешь что-то быстро и неправильно, то все запомнят, что ты сделал неправильно, но никто не вспомнит что ты сделал быстро.
На самом деле источников низкого качества внедрений 1С много (отсутствие или недостаточное тестирование, например), но мы сегодня остановимся именно на проблемах отсутствия методологии внедрения.
Основная часть
Чему же учит SureStep если объяснять «на пальцах»? Прежде всего конечно же документирование и версионность всех шагов процесса внедрения и распределение ролей участников, как со стороны подрядчика, так и со стороны заказчика.
Документ «Функциональные требования».
Самым важным ключевым документом я бы назвал функциональные требования или функциональный дизайн (в оригинале FDD – Functional Design Document). По сути, это описание поведения системы после доработок, написанное на языке пользователя. В документе не должно быть специальных терминов понятных только специалисту (например «Регистр сведений») и в него обязательно должны быть включены сквозные положительные и отрицательные сценарии тестирования с конкретными числовыми примерами.
Документ составляется аналитиком-консультантом, хорошо знающим работу системы и все её параметрические настройки, совместно с будущим пользователем системы.
После того, как документ составлен и согласован, он обязательно утверждает должностными лицами заказчика и подрядчика – как правило это бизнес-архитектор, т.е. сотрудник, который отвечает за функциональные возможности системы в целом, который решает, что делаем, а что нет и если делаем то, как именно и как разные подсистемы увязываются между собой.
Документ крайне важный потому, что именно по нему, и только по нему подрядчик должен сдавать готовые доработки. И если какие-то требований в документ не включены, то обязательно создается новая версия документа и уже в неё вносятся изменения.
Документ «Технические требования».
После утверждения функциональных требований в отдельных случаях разрабатывается документ технических требований или технического дизайна, в оригинале TDD – technical design document. Это по сути классическое техническое задание или спецификация, в котором для программиста и на языке программиста описаны все тонкости реализации. Именно при разработке этого документа разрабатываются, продумываются и анализируются всех архитектурные решения – какой регистр создать, с какими измерениями и ресурсами, структуры документов, справочников и т.п.
В идеале этот документ должен создавать либо технический архитектор проекта, либо старший программист. Именно на этом этапе возникает достаточно точная оценка трудоёмкости доработки согласно функциональным требованиям. И именно по этому документу в будущем специалисты смогут быстро и точно разобраться с архитектурой доработок и понять почему были приняты те или иные архитектурные решения.
Роли в проекте.
Руководитель проекта.
Особо описывать не вижу смысла. Отвечает за успешность проекта. А именно за то, что цели проекта будут достигнуты точно в срок, в рамках оговоренного бюджета и с установленным уровнем качества.
Аналитик-консультант.
Должен в совершенстве знать функционал внедряемой системы, включая все возможные параметрические настройки и их применение. Так же в совершенстве должен знать изнутри бизнес-процессы реального бизнеса и всю терминологию, особенности и понятия пользователей, работающих в данной отрасли.
Именно от его квалификации, опыта и коммуникативных навыков во многом будет зависеть судьба проекта.
Функциональный архитектор.
Отвечает за согласование набора функциональных требований между собой и за определение приоритетность требований пользователей системы. Принимает решение какие требований пользователей будут реализованы, а какие нет и в каком порядке.
Технический архитектор.
Именно этот сотрудник, а не программисты решает как то или иное требование конкретно будет реализовано в системе – с помощью какие объектов, инструментов и т.п. Отвечает за архитектуру решения в целом, за совместимость различных подсистем и объектов между собой.
Программист.
Должен точно, качественно и в минимальный срок реализовать требования документа «Технические требования». По окончании доработок должен проверить их на прохождение тестовых сценариев из документа «Функциональные требования». Если все сценарии в тестовой среде проходятся успешно – сдает доработки консультанту-аналитику.
Тестировщик.
Этой ролью чаще всего пренебрегают в проектах внедрения 1С. А зря. При внедрении АХ доработка считается принятой заказчиком только если есть документальное подтверждение успешного прохождения ВСЕХ шагов ВСЕХ тестовых сценариев. Да, это дорого и долго, но качество возрастает на порядок.
Общие моменты.
Само собой, на проекте должна быть удобная система bug-tracker, в которой создаются ticket-ы по которым можно отследить всю историю каждого вопроса – включая все версии всех документов, плановые и фактически трудозатраты и всю переписку по данному вопросу.
Почему важная версионность всех документов. Простой пример: по одному из требований было 10 версий функциональных требований. Общая трудоемкость доработок составила условно 20 часов, но если любому специалисту показать только последнюю версию требований и попросить оценить доработки, то получится 2 часа. На вопросы «почему так дорого? На что ушли остальные 18 часов» молча высылаю всю историю версий требований и вопросы тут же отпадают потому заказчик зачастую сам не знает, чего хочет, и уговоры консультанта-аналитики ограничится на первом этапе типовым функционалом должного эффекта не имеют. И начинается: «а давайте попробуем вот так! Ой, нет – не то. Давайте обратно как было!». А это всё часы работы специалистов, которые стоят денег.
Да, скажу честно – не все клиенты на внедрение 1С готовы оплачивать все вышеперечисленные работы, но по моим наблюдениями все больше тех, кто уже наступил на грабли и конкретно обжегся на «дешевом» внедрение, переплатил трижды и уже подходит к выбору специалистов, которым готов доверить внедрение 1С особо тщательно. Именно на такие компании рассчитана моя статья, а так же на специалистов, которые хотят повысить качество своих проектов, но не знают как.
Безусловно, в этой статье я затронул лишь крошечную часть аспектов и вопросов, регулируемых методологией SureStep , но и их думаю будет достаточно чтобы повысить свою конкурентоспособность на рынке 1С.
