Внедрение процессов — пошаговая инструкция

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

    Многие программисты согласятся, что когда находят баг в уже работающей системе, вина сваливается на них. А кого же ещё? Ведь они его допустили! В итоге, мотивация понижается, имидж портится, и вообще — те, кто больше всех работает, получает больше всех пинков. А признание получают менеджеры, отдел продаж и прочие…

    Месяцев 9 назад меня попросили ввести в один проект процессы. Проект очень большой и стратегический для организации — система собирает, обрабатыет и производит расчёты по всем оценкам всех учеников страны. Каждый год в сентябре начинается операционный цикл, который должен работать как часы, без ошибок и задержек. С января начинаются планирование изменения системы, а операционный цикл тем временем продолжается.

    Я — не эксперт в процессах, поэтому всё рассказаное дальше основано на личном опыте. Однако опыт весьма положительный — количество дефектов, с которым система вошла в UAT было равно 0, и, в первый раз за 3 года, UAT началась во время и прошла с sign-off.

    Шаг первый — где проблемы?

    Первый этап в разработке процесса — установить, что плохого сейчас, и как этого избежать.
    С этим вопросом я приставала ко всем — программистам, тестерам, аналитикам, менеджерам и прохожим на улицах. Оказалось что плохо — всё. Непротестированый код приходит в систему когда не надо, что невозможно отследить историю изменений, что непонятно кто за что ответственный, что базы постоянно переполняются, и многое другое.

    Выводом этого этапа стал факт, что нужно точное распределение ответственности. Например:
    — Когда программист внедряет код, он ответственный за его юнит-тестинг, и за то, что внедрение ничего не испортит
    — Когда тестер говорит, что всё работает — ответственность за это решение уже на нём
    — Когда аналитик подтверждает, что система годна для UAT — он ответсвенен за функционал
    И т.д.

    Шаг второй — определить процессы

    Дальше я определила процессы, которые буду описывать. Так как система уже разработана, нам понадобился процесс для «изменения» (change request) и бага (defect).

    Каждый процесс имеет начальные условия (precondition), шаги (steps) и конечное условие (post-condition). Шагом процессы может быть как простой шаг, так и разветвление, или другой процесс. Каждый процесс и шаг будут иметь свои inputs и outputs.

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

    image

    Первым шагом в «изменении» — спецификация. Её готовит программист, ответственный за изменение, и она должна гарантировать ему, что его понимание требования — правильно. Когда аналитик подтверждает спецификацию — это зелёный свет для начала непосредственной разработки. Если по мнению аналитика спецификация неполна или неправильна, она отправляется на правку к программисту. В итоге повышается мотивация программиста и уверенность в том, что он удовлитворит пользовательские требования. Раньше часто случалось, что требования «понятны и так», и программист, сам того не замечая, делает допущения, которые не оправдывют ожидания аналитика и клиента. А теперь мы знаем, что и как мы будем делать.

    Следующий шаг — программирование, которое заканчивается юнит тестом. Все объекты хранятся в SVN, при добавлении обязательны комментарии, места изменения кода прокомментированы хотя бы номером версии, и т.д. Так же была введена рекомендация по использованию SVN — когда создаётся новая ветка, когда она сливается с главной и так далее.

    После него — внедрение. Как артефакт из него выходит Release Notes, в котором будет весь список изменённых объектов, советы по тестированию и так далее. Перед непосредственным внедрением в живую систему программист должен получить формальное разрешение от аналитика, чтобы изменение не нарушило «операционного цикла». Аналитик должен удостоверится, что код правильный — иногда просто постояв за спиной программиста, демонстрирующего функционал, или просматривая выход данных. После того, как внедрение разрешено, ответственность за влияние на систему на аналитике.

    Процессы тестирования и дефекта детализоровать не буду — они есть, наверное, у всех, и всегда очень похоже. В моём случае был сделан акцент на разграничение ответственности, разрешение на внедрение.

    Шаг третий — внедрение процессов

    Это самое сложное. Тут надо убедить всех и каждого, что эти процессы — серебряная пуля. Потому что если хоть один не будет им следовать — всё насмарку!
    Я делала презентации. Сначала главному начальству. Тут без проблем. Потом — аналитикам, которые постоянно задают каверзные вопросы и приходится править, снова и снова. Потом программистам, с которыми ещё хуже — приходиться доказывать, что спецификация нужна, и она совсем коротенькая, а от release notes толку больше, чем затрат.
    После того как все убеждены, надо срочно переходить к действию. Я подготовила шаблоны документов, создала библиотеки в sharepoint, чтоб всем сразу было понятно, какой квадратик на диаграме в каком меню сайта.
    Заработало!

    Шаг четвертый — усовершенствования

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

    Выводы

    Немного бюрократии внесло нужные изменения за эти 9 месяцев. Каждый член команды чувствует себя в относительной безопасности, потому что появилось больше точек проверки и подтверждения. С другой стороны, каждый чувствует ответственность за свою работу, потому что знает, что её качество будет проверено, проверено скоро, и поэтому больше старается. Кроме того, работать в организованой команде, где каждый знает, что он должен и чего нет повышает мотивацию.

    Надеюсь, кому-нибудь пригодится мой опыт, а я с удовольствием отвечу на Ваши вопросы!
    Поделиться публикацией

    Комментарии 4

      +2
      Вы прям действовали согласно определению бюрократии: «бюрократия — организация труда защищающая работника от притязаний работодателя». Да ещё и за деньги работодателя :))
        0
        Да, так и сделали.

        Сейчас разработчики тратят по лишнему часу на спецификацию и по лишним пол-часа на release notes, на каждый день разработки.

        За то, мы не тратим дни и недели на устранение неправильной интерпретации требований, не просиживаем ночи, разбираясь, когда, кто и что набардачил, а поставка клиенту послезавтра. Всё документировано, и ясно, кто, когда, зачем и по чьей просьбе внёс изменение — поверьте, это ни раз и ни два было использовано.
        У нас как минимум 20 баз данных в live, и около 9Tb данных (всего). Колличество объектов и изменений — соответствующее — с марта около 180 релисов. У нас очень динамичная система.

        И да, работодатель за это заплатил. Это ему помогло продлить сертификат ISO9001, без которого бизнесу капут.
          0
          А какой коллектив над этим монстром трудится? Количество аналитиков, тестеров и т.д.
            0
            Мой модуль — обработка и подсчёт индикаторов, и генерация аутпутов для других систем. У нас — 6 аналитиков, они же и тестеры, 4.5 девелопера, руководитель проекта и дев манагер (я).

            Есть ещё 2 модуля — data collection and matching, там человек 6 програмеров, и вебсайт для школ — там около 2 девелоперов и тестер. Но у тех модулей свои процессы… пока что :)

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое