У вас отключен JavaScript
Для пользования сайтом, необходимо, чтобы JavaScript был включен. Посмотреть как включить, выберите свой браузер:

IT аудит: лучшее лечение-профилактика. Аудит процессов разработки

 

Если уж разрабатывать, то делать это качественно и эффективно.

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

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

 

КОГДА НУЖЕН АУДИТ РАБОЧИХ ПРОЦЕССОВ?

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

 

Первые признаки того, что нужен аудит рабочих процессов:

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

 

 

КАК ПРОХОДИТ АУДИТ РАБОЧИХ ПРОЦЕССОВ?

Чтобы в процессе аудита выяснить, где именно скрыт камень преткновения, и как справиться с его устранением, действуем следующим образом:

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

 

 

ЧТО ВХОДИТ В АУДИТ РАБОЧИХ ПРОЦЕССОВ?

Такой аудит охватывает три важных направления:

  • планирование проекта;
  • управление проектом;
  • разработка проекта.

 

Давайте посмотрим на каждое направление более подробно.

 

 

audit project planning

ПЛАНИРОВАНИЕ ПРОЕКТА

Какие преимущества вы получаете?

После того, как проверены процессы, связанные с планированием проекта, определены слабые места и выполнены рекомендации по необходимым изменениям и улучшениям:

  • процесс становится управляемым, сроки соблюдаются, бюджет уже не нужно бесконечно растягивать;
  • соответственно, сокращаются издержки, связанные с несоблюдением сроков;
  • процессы становятся прозрачными для заказчика: он может планировать развитие продукта и бюджет;
  • запуски проходят успешно / дедлайны не срываются, команда не работает сверхурочно и по ночам, чтобы закончить вовремя, все этапы проекта завершаются своевременно.

 

Что мы проверяем?

  • Высокоуровневое планирование
  • составляется ли план-график (road map), насколько он актуален и реалистичен;
  • какой используется уровень детализации в road map (2 строчки или подробное описание);
  • как фиксируется прогресс, и насколько он прозрачен для представителя заказчика.
  • Управление бюджетом
  • отслеживается ли потраченный бюджет и каким образом;
  • какая доля бюджета не исполняется и по каким причинам;
  • соответствуют ли затраты ожидаемым, если нет, то по каким причинам.
  • Риски
  • каким образом обнаруживаются риски и когда;
  • обсуждаются ли они с представителем заказчика;
  • какие риски команда закладывает изначально;
  • практикуется ли ретроспектива проектов и проверка рисков на предмет того, какие риски возникли и что можно было бы сделать, чтобы этого не случилось.
  • Планирование ресурсов
  • каким образом распределяются ресурсы;
  • кто отвечает за распределение и контроль;
  • насколько планирование соответствует фактическому расходу; корректируется ли планирование ресурсов по мере реализации проекта.

 

 

audit project management

УПРАВЛЕНИЕ ПРОЕКТОМ

Какие преимущества вы получаете?

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

  • представителю заказчика прозрачна динамика процесса, и он может планировать свои действия;
  • минимизируются потери информации;
  • команда работает эффективнее за счет более четкого понимания задач и распределения ответственности, как результат регулярно соблюдаются сроки и рамки бюджета.

 

Согласно результатам опроса разработчиков Stack Overflow (в нем приняли участие 56 033 разработчика из 173 стран) место в топе занимают именно позиции, связанные с управлением проектом.

audit statistics

Источник

 

Что мы проверяем?

  • Текущую документацию
  • проверяем документацию на наличие и актуальность, структурированность, полноту.
  • Тикеты (задачи для разработчиков)
  • где хранятся и как поставлены задачи;
  • однозначно ли они трактуются разработчиком, РМ и клиентом; понятен ли статус каждой задачи в определенный момент времени;
  • если задачи не выполнены (статус “в процессе” (on hold)) – понятна ли причина, почему задача отложена или заблокирована или долго выполняется;
  • есть ли у задачи история;
  • однозначно ли определены исполнители.
  • Коммуникацию
  • как происходит коммуникация и внутри команды, и с представителем заказчика;
  • насколько каждый член команды осведомлен о текущем состоянии проекта;
  • обсуждается ли проект всей командой;
  • прозрачен ли статус для менеджера;
  • как принимаются решения;
  • есть ли удобный и быстрый канал связи;
  • как фиксируются договоренности с заказчиком: насколько заказчику прозрачно, чем занимается команда;
  • как заказчик дает свой фидбэк, как и кому сообщает о своих изменениях;
  • если несколько представителей заказчика: как они договариваются, кто их синхронизирует, какие каналы информации используются;
  • насколько часто происходит общение с заказчиком, есть ли одна точка входа или он общается со всеми по отдельности.

 

 

audit project development

РАЗРАБОТКА ПРОЕКТА

Какие преимущества вы получаете?

Преимущества, получаемые в результате того, что будут проверены все процессы, инструменты и приемы, используемые непосредственно для разработки продукта, очевидны:

  • в продукте становится меньше ошибок;
  • приложение работает стабильнее;
  • производятся более частые релизы.

 

Что мы проверяем?

  • Среду разработки
  • используется ли специальная среда development (среда разработки, в которой работает разработчик в процессе написания кода) и staging (среда, в которой происходит предварительное тестирование приложения), и отдельно production (среда, в которой запускается работающее приложение).
  • Используемые процессы
  • Continuous Integration: непрерывная интеграция, как процесс переноса кода в основной репозиторий после прохождения тестирования;
  • Continuous Delivery: непрерывная поставка обновлений работающего продукта без поломки существующих функций после проверки тестировщиками;
  • Continuous Deployment: непрерывное развертывание новых функций и изменений в вашем приложении автоматически (без вмешательства специалистов).

Например:

Если развертывание (деплой) занимает, в среднем, 15 минут, то в неделю оно отнимет 2,5 часа (2 раза в день).

А для настройки авто-деплоя потребуется потратить всего один раз 3-6 часов (в зависимости от сложности приложения). После этого процесс будет осуществляться автоматически, не требуя более временных затрат. Сэкономленные часы можно будет потратить на другие задачи.

  • Инструмент совместной работы с  кодом (сервис, где хранится исходный код и его версии, который позволяет работать с версиями и поддерживать актуальность исходного кода на любом этапе разработки)
  • проверяем на предмет того, используется ли такой инструмент, и как он используется для минимизации числа ошибок;
  • проверяем актуальность кода.
  • Ревью кода
  • проверяем, используется ли такая проверка в процессе разработки.
  • Тестирование: ручное тестирование и автотесты (сценарии, моделирующие действия пользователя в приложении, для того, чтобы выявить возможные ошибки)
  • проверяем, успешно ли они проходят; если нет, то выясняем в чем причины и т.д.

 

 

ЧТО ВАМ ДЕЛАТЬ С РЕЗУЛЬТАТАМИ АУДИТА РАБОЧЕГО ПРОЦЕССА?

После того, как аудитор работы команды завершит свою работу, у вас на руках останется отчет об аудите с перечнем слабых мест и недочетов, которые были обнаружены в планировании и управлении проектом, а также в рабочем процессе команды разработчиков. А вдобавок к ним еще и рекомендации и предложения по внесению определенных изменений. И все это только с одной целью: показать вам возможности для улучшения самого процесса, а в итоге и конечного продукта.

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

Если вы заинтересовались тем, как проходит процесс разработки вашего IT продукта, или у вас остались вопросы – просто не забывайте, что Umbrella всегда на связи.

 

Фото: Shutterstock.com

 


Ещё

  • CEO компании Umbrella на Agile Days 2018: рецепт эффективного и контролируемого роста команд разработчиков
    CEO компании Umbrella на Agile Days 2018: рецепт эффективного и контролируемого роста команд разработчиков
      22-23 марта в московском Центре Международной Торговли прошла 12-я глобальная конференция по гибкому управлению процессами Ag;)le Days 2018. Одним из спикеров конференции стал основатель и CEO компании Umbrella Станислав Мешков. Мы попросили Стаса рассказать немного о том, как это было. Интервьюер: Привет, Стас! На конференции Ag;)le Days 2018 ты выступал с докладом: “Разработка: увеличь компанию, …
  • IT Лидеры и правители из прошлого: удивительные параллели успеха, которые вы могли не заметить. Часть 2
    IT Лидеры и правители из прошлого: удивительные параллели успеха, которые вы могли не заметить. Часть 2
      В стремлении стать одним из сильнейших лидеров в IT-индустрии, немаловажно обладать рядом определённых качеств, развивая которые вы сможете построить собственную империю. В предыдущей статье вы узнали несколько историй успеха величайших деятелей IT-индустрии, у которых есть, чему поучиться. Сегодня мы расскажем вам о том, что помогает Александру Македонскому нашего времени осваивать новые ниши рынка, и как …
  • IT Лидеры и правители из прошлого: удивительные параллели успеха, которые вы могли не заметить. Часть 1
    IT Лидеры и правители из прошлого: удивительные параллели успеха, которые вы могли не заметить. Часть 1
      Стремитесь завоевать весь мир? Отлично! Вы почти обречены на успех. Как насчёт анализа кирпичиков того победного фундамента, что был заложен в великих и известных всему миру достижениях? Во все времена главной движущей силой была целеустремлённость. Однако чтобы построить могущественную державу, необходимо обладать ещё и рядом определённых качеств – развивая их, вы сможете повторить успех ваших …