Запуск в эксплуатацию

Технология проектного внедрения

Внедрение корпоративных информационных систем на базе программных продуктов 1С – основное направление деятельности компании Алгоритм Успеха.

Для предприятий среднего и крупного бизнеса требуется эффективный инструмент ведения учета и управления основными бизнес-процессами в компании – информационная система, построенная в соответствии с мировым стандартом ERP (Enterprise Resource Planning System — система планирования ресурсов предприятия).

При внедрении информационных систем ERP класса обычно используется технология проектного внедрения. Технология проектного внедрения предполагает использование методологии управления проектами PM BOOK.

Особенности данной технологии:

  • Определяются, согласовываются и документируются цели и задачи проекта, работы, критерии завершенности.
  • Согласовываются и устанавливаются ограничения проекта: сроки, стоимость, качество.
  • Выявляются возможные риски проекта, анализ их влияния на сроки, стоимость и содержание проекта.
  • Определяется политика реагирования на риски.
  • Разрабатывается проектная документация.
  • Устанавливаются договорные отношения по порядку реализации проекта.
  • Выполняется весь перечень работ по плану проекта и договорных обязательств сторон.

Преимущества использования технологии проектного внедрения:

  • Четкое представление обеими сторонами ожидаемых результатов проекта.
  • Проектирование АСУП и управление проектом осуществляется проектной командой, включающей в себя кроме программистов и аналитиков, Руководителя проекта, Архитектора системы и Технического архитектора.
  • Плановость выполнения работ и получения конкретных результатов.
  • Высокая управляемость по ресурсам, графику проекта, бюджету и качеству.
  • Ответственность за соответствие реального состояния АСУП планируемым показателям несет Исполнитель.
  • Фирмой 1С разработано решение 1С:Управление производственным предприятием. Это комплексное решение для управления бизнесом, разработанное в соответствии с концепцией ERP.

Наиболее полно информация о продукте представлена на сайте фирмы 1С

Этапы проектной технологии:

  • Обследование предприятия клиента.
  • Проектирование системы — включает работы:
    1. По разработке и согласованию Устава проекта;
    2. По разработке и согласованию моделей бизнес-процессов;
    3. По разработке и согласованию технического задания, определяющего детальные требования к системе на уровне функций системы;
    4. По разработке и согласованию план-графика работ по проекту.
  • Технический проект.
  • Реализация технического проекта, тестирование продукта, подготовка к опытной эксплуатации.
  • Запуск и проведение опытной эксплуатации.
  • Ввод системы в промышленную эксплуатацию.
  • Постпроектное сопровождение системы.

Следует отметить, что успешное внедрение проекта — это слаженная и напряженная работа двух команд: Заказчика и Исполнителя. Руководитель проекта со стороны Исполнителя должен быть наделен соответствующими полномочиями для управления проектом со стороны Заказчика.

Более подробно с этапами проектной технологии можно ознакомиться в офисе нашей Компании или на презентации программного продукта.

Мы хотели бы поделиться опытом: того, с чем мы сталкиваемся, и того, что мы кровью и потом наработали с нашими заказчиками – у нас достаточно крупные и проблематичные заказчики – типа ГазпромНефти и Почты России.

То, о чем я буду рассказывать, по большей части актуально для крупных структур, когда у вас есть головная компания и филиалы, ДЗО, которые обладают различной степенью самостоятельности и различным видением одних и тех же процессов, чем сильно усложняют процесс внедрения.

Статья написана по материалам доклада, прочитанного автором на первой конференции инфостарта 2012 года. Она опубликована в журнале Инфостарта №1.

Общие этапы внедрения автоматизированных систем

Общие этапы внедрения автоматизированных систем общеизвестны (обычный PMBOK):

📌 Реклама Отключить

Анализируем требования того, что нужно заказчику, затем проектируем, разрабатываем, тестируем – развертываем у заказчика систему и отдаем ее в эксплуатацию.

Как правило – если проект большой – сделать все это за одну итерацию практически невозможно, потому как у нас на этапе анализа функциональных требований поступает масса изменений. Пользователи не представляют себе, что они получат на выходе через какое-то время – то есть изначальное ТЗ на 400 листов согласовывается по формальному признаку – мало кто способен вникнуть в суть того, что там написано.

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

📌 Реклама Отключить

Технология быстрых результатов

Для решения этих проблем 1С в кризис придумала так называемую «технологию быстрых результатов». На Западе уже давно существует аналог — технология «Гибкие методики разработки» — AGILE. (www.agilemanifesto.org)

  • Люди и взаимодействия важнее, чем процессы и инструменты
  • Работающий код важнее совершенной документации
  • Сотрудничество с заказчиком важнее контрактных обязательств
  • Реакция на изменения важнее следования плану.

Главная идея гибких методик разработки заключается в том, что нам важнее удовлетворенность заказчика, а не следование подписанным планам-графикам, утвержденным техническим заданиям и т.д. То есть, главное для заказчика – получить результат и важнее с ним эффективно работать, нежели выполнять просто контрактные обязательства. 📌 Реклама Отключить

Agile предлагает зациклить разработку — сделать ее непрерывной и многоитерационной, чтобы заканчивая какой-то блок, мы тут же начинали другой.

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

Если посмотреть на структуру этой итерационной доработки (тут приведена схема из какой-то презентации по AGILE), то что мы увидим здесь:

  • первая большая колонка – это общие функциональные требования, которые у нас есть к системе. Мы на каждую итерацию выделяем, либо согласовываем с заказчиком, какой блок мы делаем (это может быть отдельный бизнес-процесс, отдельный функциональный блок), берем его в разработку, в течение какого-то не очень продолжительного периода (2-4 недели) – его реализуем.
  • Обязательно каждый день должно производиться обсуждение результатов работы – грубо говоря, каждый день вся проектная команда утром должна на 15 минут собраться вместе (т.н. stand up meeting) – стоя, не разглагольствовать, быстренько все обсудить. Говорим, что мы сделали за вчерашний день, что мы готовы сделать за сегодняшний, планируем свои действия, чтобы более оперативно управлять процессом.
  • По окончании этого спринта – этой итерации – мы проводим обязательно демонстрацию для заказчика, чтобы заказчик уже увидел, что мы действительно что-то сделали, а не просто полгода сидели и непонятно что разрабатывали.
  • По окончании демонстрации обязательно проводится так называемая ретроспектива – мы должны оглянуться назад и пересмотреть, что мы сделали качественно и наоборот, что у нас не получилось, сделать для себя какие-то отметки, запланировать устранение этих проблем далее, и, может быть – принять меры в своей проектной команде – поменять разработчиков или сделать что-то еще.

Этапы внедрения системы

Далее мне бы хотелось рассмотреть подробнее этапы внедрения системы – какие моменты можно учитывать на этих этапах. 📌 Реклама Отключить

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

Создание центров компетенции

Часто удачным бывает решение выделять так называемые «Центры компетенции» внутри заказчика – если компания большая – десятки тысяч человек – можно выделить из их числа 5-10 человек, которые будут понимать бизнес-процессы по какой-то области – коммерческий учет, бухгалтерский учет, налоговый учет, управленческий учет. И именно эти люди будут разрабатывать эту методологию, непосредственно заниматься тестированием и оказывать консультации пользователям, когда они начинают реализацию этой методологии применять. С поддержкой «Центров компетенций» перенос требований бизнеса на будущую автоматизированную систему будет осуществлен наиболее эффективно. 📌 Реклама Отключить

При поблочном внедрении – концепция «Пилот – адаптация – тираж»

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

Создание проектного офиса

Также важным моментом на этапе анализа функциональных требований (в самом начале проекта) является создание проектного офиса. Это особенно важно, если автоматизация комплексная – внедряется коммерческий учет, управленческий учет (например – по классической схеме – внедряется УПП, ЗУП, Консолидация данных и Система управления НСИ). В задачи проектного офиса будет входить курирование команд разработчиков, которые у вас будут заниматься непосредственно разработкой системы. Даже если подрядчик один – все равно люди разные – тяжело заставить людей говорить друг с другом о том, что один сделал документ в коммерческом учете, значит, в бухгалтерском учете тоже нужно что-то поправить. А когда будет создан орган, это контролирующий – это позволит повысить качество работы 📌 Реклама Отключить

Методы и инструменты контроля проектного офиса:

  • контроль соблюдения сроков проекта в соответствии с планом-графиком;
  • контроль расходования трудозатрат по проекту;
  • контроль над изменениями в проекте;
  • контроль качества управления, а также повышение квалификации руководителей проектов;
  • контроль KPI задействованных сотрудников – замена сотрудников при необходимости;
  • контроль над документированием проекта;

Выбор оборудования

На этапе выбора оборудования – когда мы рекомендуем заказчику, что же ему нужно купить в итоге, есть очень много любителей гнаться за объемами – набрать дисков по 2 ТБ, в сервер воткнуть процессоров по 4 штуки на сервер. Однако, те же HP-шные сервера – если вы возьмете 2-х процессорную машину с топовыми процессорами и 4-х процессорную машину, то у вас 2-х процессорная получится мощнее, потому процессоры будут с более высокой тактовой частотой. 📌 Реклама Отключить

С дисками – то же самое – лучше взять меньший объем, зато не SATA, а SAS диски. А лучше SSD. Дороже – да, зато скорость обмена данными будет достаточно высокая, и вы не упретесь в производительность.

Как это оборудование вообще выбрать?

Проще всего попытаться воссоздать будущую нагрузку на том оборудовании, которое вы собираетесь выбрать для своей системы (попросить у кого-то такое оборудование и запустить на нем, например, стандартный нагрузочный тест для УПП, сделать какую-нибудь групповую обработку по Консолидации данных, в ЗУП-е нагенерировать тысячу сотрудников, и попытаться на них рассчитать зарплату).

Это позволит более объективно посмотреть, как ведет себя оборудование и понять узкие места.

Где взять это оборудование?

HP достаточно ходовой товар, и сервиса по его тестированию вроде нет. Однако партнеры вендоров, производящих сервера IBM или ORACLE очень часто дают эти сервера потестировать. 📌 Реклама Отключить

Вы можете обратиться к партнеру IBM. Он вам выделит для тестирования и систему хранения данных отличную и сервера POWER 7, вы сможете увидеть непосредственно в работе это железо и потом уже принять решение – покупать его или нет. У IBM есть такая отличная структура, называется «Центр инноваций IBM». Она на бесплатной основе может предоставлять оборудование для тестирования, то есть, если вы сомневаетесь в выборе какой-то СУБД, сомневаетесь в выборе какого-то оборудования, и потенциально склоняетесь при этом к покупке оборудования IBM, то вы можете обратиться в «Центр инноваций». Вам бесплатно предоставят тестовый стенд с необходимыми СУБД. Могут даже ORACLE поставить, SQL Server поставить, вы сможете уже конкретно посмотреть, как на них себя поведет система. Еще один интересный момент – они иногда проводят бесплатное обучение по DB2 (правда, на английском языке).

📌 Реклама Отключить

Другой вариант — арендовать на время мощный сервер в облаках Amazon или Azure.

Этап разработки прототипа

На этапе разработки прототипа:

  • не нужно разрабатывать конфигурации «с нуля». Часто бывает, что крупные заказчики хотят какие-то особенные подсистемы, которые ни одно типовое решение не покрывает, и разработчикам приходится что-то делать полностью «с нуля». Лучше взять за основу БСП и применить его в качестве «конструктора с базовой функциональностью». Берете БСП и тут же начинаете реализовывать вашу прикладную бизнес-логику. Используете уже готовые подсистемы ролевой модели, подсистемы управления пользователями – то, без чего не обойтись.
  • Также важно определить ключевые операции изначально, даже до согласования с заказчиком вы понимаете, какие ключевые операции важны для бизнеса, попытаться встроить замеры производительности из БСП, чтобы вы могли на каждом этапе отслеживать динамику изменения этих показателей. Чтобы уже на этапе разработки вы видели, в какие целевые значения мы укладываемся.
  • Для автоматизации нагрузочного тестирования по ключевым операциям обязательно нужно использовать подсистему «Тест-центр». Это достаточно простой инструмент. Есть обучающее видео http://infostart.ru/public/152161/ о том, как встраивать Тест-центр в конфигурацию, как разрабатывать простые тесты и смотреть результаты их выполнения. Несмотря на то, что КИП, в состав которого входит Тест-центр, стоит 84000 рублей, эта конфигурация того стоит. Можно потратиться и получить удобный инструмент, нежели каждый раз изобретать велосипед и пытаться писать нагрузочные тесты.
  • Нужно попытаться хотя бы частично автоматизировать функциональное тестирование. Это должно быть реализовано на этапе разработки прототипа. Однако позже – на этапе сопровождения системы это очень пригодится.
  • Важно привлекать Экспертов по технологическим вопросам. Не обязательно это должен быть человек, у которого есть такой сертификат. Этот человек должен хотя бы сходить на обучение. Достаточно просто вникнуть в то, что рассказывают на трехдневном тренинге по сертификации на статус «Эксперта по технологическим вопросам», прослушать, какие вопросы задаются при сдаче этого экзамена и по результатам этого тренинга мышление немного меняется – люди хотят «свернуть горы». Правда практика немного не стыкуется с теорией и пыл проходит, но – все равно, знания экспертов по технологическим вопросам на этапе разработки прототипа очень важны
  • Важно также генерировать достаточные массивы данных для проверки механизмов. Если вы знаете, что у заказчика 12000 сотрудников, то при разработке тестировочной базы количество тестируемых данных также должно быть соответствующим
  • Придерживаться рекомендаций по стандартам разработки 1С. (давайте уважать друг друга – при разработке в команде это важно)
  • Процесс разработки должен производиться в той же СУБД и ОС, которые будут у заказчика. Не используйте разработку в файловых базах. Если заказчик собирается использовать серверный вариант – для разработки прототипа также обязательно используйте серверную базу. Нет денег на СУБД — используйте бесплатные альтернативы. Для DB2 есть прекрасный вариант – IBM выпустила новую бесплатную версию DB2 Express-C 10.1, у которой повышен объем допустимой оперативной памяти до 4-х Гб. Если мы сравним ее с ORACLE и MSSQL Server (с их аналогичными бесплатными версиями Express-C), то там этот объем памяти равен 1Гб.

Обязательно необходимо всегда использовать управляемый режим блокировки данных и использовать разделение итогов по регистрам (использование управляемого режима блокировки данных дает существенный прирост параллельности работы системы при большом числе одновременно работающих пользователей) 📌 Реклама Отключить

Функциональное тестирование

Расскажу поподробнее о функциональном тестировании:

1С нам сделала огромный подарок тем, что реализовала объектную модель для функционального тестирования. Понятно, что она доступна только для управляемого интерфейса и только для 8.3. Но – на управляемом интерфейсе у нас уже УТ11 и БП3.0. Это уже большой объем функциональности, которую достаточно часто внедряют. Вам никто не мешает вести разработку (работу) в 8.2 – а для тестирования создать отдельную базу, сконвертированную на 8.3, посадить на нее отдельного консультанта, который вам достаточно легко набьет эти тесты (запишет сценарии, сконвертирует эти сценарии в программный код, вы вставите в эти сценарии свои процедуры проверки). При выпуске релизов вы сможете в пакетном режиме запустить свои тесты и проверить работоспособность ключевых механизмов. Это позволит очень сильно сэкономить время в период авральных обновлений.

📌 Реклама Отключить

Выбор СУБД для разработки прототипа

Опять-таки, подробнее о выборе СУБД для разработки прототипа:

Преимущества использования управляемого режима блокировки данных и разделения итогов по регистрам накопления

И диаграмма прироста производительности в случае использования управляемого режима блокировки данных и разделения итогов по регистрам накопления в нагрузочном тесте на 500-600 одновременно работающих пользователей.

Регистрация ошибок платформы

Следующий спорный момент – это регистрация ошибок платформы. Регистрация ошибок конфигурации не интересует – мы все профессионалы, устранить ошибки в конфигурациях мы можем. А в платформе, к сожалению, не можем. 📌 Реклама Отключить

К сожалению, разработчики не любят регистрировать ошибки, нужно указывать регистрационный номер и т.д. Но есть одна уловка. Вы воссоздаете ошибку в тестовом релизе, для которого существует специальная линия поддержки тестовых релизов платформы.

Там не требуется регистрационных номеров, там сидит адекватный человек, который оперативно отвечает. В течение последнего года мы таким образом зарегистрировали порядка 30 ошибок – это эффективно способствовало их реальному устранению.

Запуск в промышленную эксплуатацию

Следующий этап – запуск в промышленную эксплуатацию

  • На этапе запуска в промышленную эксплуатацию необходимо настроить мониторинг загруженности оборудования. Основные параметры (загруженность дисков, загруженность памяти, загруженность процессоров). Это не требует времени и усилий на настройку, но потом – постфактум, когда вы будете разбираться с проблемами, когда вы будете передавать данные разработчику, это позволит своевременно делать определенные выводы
  • Необходимо настроить в целом мониторинг доступности самих серверов с помощью специализированных средств. Например, бесплатные opensource-решения – zabbix, nagios

Этап сопровождения

На этапе сопровождения системы ключевыми моментами является: 📌 Реклама Отключить

  • Проводить нагрузочное и функциональное тестирование перед выпуском каждого релиза. То, что вы разработали на этапе разработки прототипа, вам здесь очень поможет.
  • Необходимо настроить периодический сбор данных краткого технологического журнала и системных представлений СУБД, их консолидацию и анализ. Использовать для постоянного мониторинга ЦУП будет тяжело, потому как он нагружает систему, долго анализирует – полезность полученной информации будет сомнительна. Если же вы будете просто мониторить тяжелые запросы, а потом как-то их агрегировать – будет гораздо эффективнее. Я выкладывал программку на .NET, которая позволяет в многопоточном режиме разбирать технологический журнал, засовывая полученные данные в табличку на MS SQL Server (http://infostart.ru/public/117023/ ). Из этой таблички вы простыми запросами можете увидеть, например, Топ-100 наиболее тяжелых, увидеть их планы выполнения запросов и принять какие-то меры.
  • ЦУП поможет при выявлении проблем в продуктивной базе под существенной нагрузкой
  • Настроить и контролировать выполнение регламентных операций СУБД. Возможно, для контроля того, что регламентные операции СУБД выполняются, будут необходимы дополнительные доработки.
  • Контролировать версии платформы и релизов конфигураций при большой распределенной сети информационных баз. Если у вас распределенная структура, бывает, что в центре 8.2.16, в регионе на первом уровне 8.2.15, а в филиале 8.2.13. В итоге у вас функциональность может по-разному работать, что, конечно, будет вызывать проблемы. Проще сделать в решении какую-нибудь табличку, чтобы система автоматически сконсолидировала информацию о том, какие версии платформы где используются.

Обеспечить качественную обратную связь с конечными пользователями. Имеется в виду не первая линия поддержки (документ не проводится, мышка сломалась, система не открывается). Имеется в виду вторая линия поддержки – сопровождение внедренной системы. Если вы используете для этого Word, Excel, Outlook (консолидируете информацию в почте) – то это неэффективно – вы не можете сделать ни выборку данных, ни предоставить отчетность заказчику по трудозатратам. В нашей компании мы для этих целей разработали так называемую «Система управления инцидентами». 📌 Реклама Отключить

«Система управления инцидентами»

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

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

📌 Реклама Отключить

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

Хочу поделиться опытом разработки и введения ай-ти процессов в проекте. Зачем нужны процессы? Они, отвечают многим разным целям, но в нашем случае основной целью было разграничение ответственности.
Многие программисты согласятся, что когда находят баг в уже работающей системе, вина сваливается на них. А кого же ещё? Ведь они его допустили! В итоге, мотивация понижается, имидж портится, и вообще — те, кто больше всех работает, получает больше всех пинков. А признание получают менеджеры, отдел продаж и прочие…
Месяцев 9 назад меня попросили ввести в один проект процессы. Проект очень большой и стратегический для организации — система собирает, обрабатыет и производит расчёты по всем оценкам всех учеников страны. Каждый год в сентябре начинается операционный цикл, который должен работать как часы, без ошибок и задержек. С января начинаются планирование изменения системы, а операционный цикл тем временем продолжается.
Я — не эксперт в процессах, поэтому всё рассказаное дальше основано на личном опыте. Однако опыт весьма положительный — количество дефектов, с которым система вошла в UAT было равно 0, и, в первый раз за 3 года, UAT началась во время и прошла с sign-off.
Шаг первый — где проблемы?
Первый этап в разработке процесса — установить, что плохого сейчас, и как этого избежать.
С этим вопросом я приставала ко всем — программистам, тестерам, аналитикам, менеджерам и прохожим на улицах. Оказалось что плохо — всё. Непротестированый код приходит в систему когда не надо, что невозможно отследить историю изменений, что непонятно кто за что ответственный, что базы постоянно переполняются, и многое другое.
Выводом этого этапа стал факт, что нужно точное распределение ответственности. Например:
— Когда программист внедряет код, он ответственный за его юнит-тестинг, и за то, что внедрение ничего не испортит
— Когда тестер говорит, что всё работает — ответственность за это решение уже на нём
— Когда аналитик подтверждает, что система годна для UAT — он ответсвенен за функционал
И т.д.
Шаг второй — определить процессы
Дальше я определила процессы, которые буду описывать. Так как система уже разработана, нам понадобился процесс для «изменения» (change request) и бага (defect).
Каждый процесс имеет начальные условия (precondition), шаги (steps) и конечное условие (post-condition). Шагом процессы может быть как простой шаг, так и разветвление, или другой процесс. Каждый процесс и шаг будут иметь свои inputs и outputs.
В процессе «Изменение» начальным условием стало «изменение и бизнесс-спецификация утверждены клиентом «. Это — гарантия того, что изменение нужно, и спецификация соответствует требованию клиента. Что клиент потом не скажет, что мы сделали совсем не то, что он просил, как это часто случалось раньше. Ниже — полная диаграмма процесса «Изменение» и описание его основных под-процессов.
Первым шагом в «изменении» — спецификация. Её готовит программист, ответственный за изменение, и она должна гарантировать ему, что его понимание требования — правильно. Когда аналитик подтверждает спецификацию — это зелёный свет для начала непосредственной разработки. Если по мнению аналитика спецификация неполна или неправильна, она отправляется на правку к программисту. В итоге повышается мотивация программиста и уверенность в том, что он удовлитворит пользовательские требования. Раньше часто случалось, что требования «понятны и так», и программист, сам того не замечая, делает допущения, которые не оправдывют ожидания аналитика и клиента. А теперь мы знаем, что и как мы будем делать.
Следующий шаг — программирование, которое заканчивается юнит тестом. Все объекты хранятся в SVN, при добавлении обязательны комментарии, места изменения кода прокомментированы хотя бы номером версии, и т.д. Так же была введена рекомендация по использованию SVN — когда создаётся новая ветка, когда она сливается с главной и так далее.
После него — внедрение. Как артефакт из него выходит Release Notes, в котором будет весь список изменённых объектов, советы по тестированию и так далее. Перед непосредственным внедрением в живую систему программист должен получить формальное разрешение от аналитика, чтобы изменение не нарушило «операционного цикла». Аналитик должен удостоверится, что код правильный — иногда просто постояв за спиной программиста, демонстрирующего функционал, или просматривая выход данных. После того, как внедрение разрешено, ответственность за влияние на систему на аналитике.
Процессы тестирования и дефекта детализоровать не буду — они есть, наверное, у всех, и всегда очень похоже. В моём случае был сделан акцент на разграничение ответственности, разрешение на внедрение.
Шаг третий — внедрение процессов
Это самое сложное. Тут надо убедить всех и каждого, что эти процессы — серебряная пуля. Потому что если хоть один не будет им следовать — всё насмарку!
Я делала презентации. Сначала главному начальству. Тут без проблем. Потом — аналитикам, которые постоянно задают каверзные вопросы и приходится править, снова и снова. Потом программистам, с которыми ещё хуже — приходиться доказывать, что спецификация нужна, и она совсем коротенькая, а от release notes толку больше, чем затрат.
После того как все убеждены, надо срочно переходить к действию. Я подготовила шаблоны документов, создала библиотеки в sharepoint, чтоб всем сразу было понятно, какой квадратик на диаграме в каком меню сайта.
Заработало!
Шаг четвертый — усовершенствования
По мере использования процесса, появляются новые идеи, как его оптимизировать, что где добавить. Документ процесса — живой документ и надо воодушевлять коллег на внесение изменений — важно, чтоб процесс всех устраивал и подходил для своей цели!
Выводы
Немного бюрократии внесло нужные изменения за эти 9 месяцев. Каждый член команды чувствует себя в относительной безопасности, потому что появилось больше точек проверки и подтверждения. С другой стороны, каждый чувствует ответственность за свою работу, потому что знает, что её качество будет проверено, проверено скоро, и поэтому больше старается. Кроме того, работать в организованой команде, где каждый знает, что он должен и чего нет повышает мотивацию.
Надеюсь, кому-нибудь пригодится мой опыт, а я с удовольствием отвечу на Ваши вопросы!

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *