Текущая версия на 11:38, 18 мая 2014

В пятницу был на Enterprise Developers Conference, которую проводил CareerLab. Конференция была весьма нетипичная, участники преимущественно представляли inhouse разработку. Впечатления от конференции очень позитивные, на ней было несколько неожиданных докладов. Местами получилось заглянуть во внутреннюю кухню корпоративной разработки, которую не так часто представляют на конференциях, а еще - посмотреть на развитие тренда ALM-средств, которые предоставляет Microsoft не в виде презентаций самих средств (хотя это тоже было), а на опыте их внедрения в крупных разработческих компаниях.

Теперь подробности. Не полные - я был только на одном треке конференции, а их было два. Второй касался мобильной разработки, которая сейчас занимает важное место в отрасли, но все-таки находится вне сферы моих интересов. Пока?

Неожиданные доклады

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

Дмитрий Сатин (Минкомсвязь) Роль пользовательских историй при сдаче проекта

Дмитрий Сатин - известный юзабилист, и ранее работал в UsabilityLab. А сейчас он работает в Минкомсвязи в ранге советника министра. И занимается юзабилити интерфейсов на этом уровне.

Собственно, неожиданное сообщение - в том, что юзабилити сайтов госсектора рассматривается как государственная задача. Потому что она - составляющая в удовлетворенности граждан электронными услугами. А об этом говорил Путин "Демократия и качество государства", а в указе 601 от 07.07.2012 - поставлены конкретные KPI, удовлетворенность услугами и сокращение времени ожидания в очередях, что предполагает, как важную составляющую, usability сайтов. Все это - в контексте достижения глобальной цели: добиться, чтобы граждане говорили "я хочу жить в этой стране".

Они планируют работать по многим направлениям.

• Обеспечить эффективную обратную связь по SMS.
• Подключаться к работе с госзакупками по этим заказам, не через изменение нормативной базы, а через конкретную работу - потому что нормативка в целом есть. Сатин проводил опрос заказчиков, подрядчиков и независимых экспертов - в чем именно проблемы, почему юзабилити результата разработки столь низкое - и с этим будут работать.
• Внедрением стандартов - тут, оказывается, есть задел в виде переведенных ГОСТ Р ИСО 9241-11-2010 и ГОСТ Р ИСО 9241-210-2012. По которым пока решили, что требовать еще не время, надо пропагандировать - тем более, что формальное внедрение никому не нужно.
• Интеграцией в единые порталы, с единой точкой входа. Тут Москва во многом впереди с http://pgu.mos.ru, который во многом служит площадкой для обкатки и дальнейшего распространения опыта.

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

При этом инструменты повышения юзабилити в нынешней ситуации - на уровне учебников, написание userstory по делу, а не в варианте "пользователь открывает форму, заполняет необходимые поля и отправляет документ" - подобные формальные задания демонстрировались. И примеры по изменению таких ситуаций - тоже были. И тут они будут и разъяснять и требовать. Собственно, именно эти примеры и были анонсированы в названии доклада.

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

Игорь Беспальчук (CUSTIS) Прекратите думать о конвейере, или Производство ПО через призму системного подхода

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

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

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

В общем, доклад удался, и не только по моему мнению - я слышал это от других участников, некоторые называли его одним из лучших вместе с докладом Дмитрия Сатина.

Заглянуть в inhouse

Два интересных доклада, которые позволяют заглянуть в крупную корпоративную разработку и посмотреть тренды, которые там сейчас идут. Собственно, именно этим они интересны.

Александр Барахтян (Сбербанк-Технологии) Эффективные стратегии подбора и построения команд в in-house разработке

Александр рассказывал о проблемах привлечения разработчиков и формирования команд в inhouse-разработке. Трендом тут является поворот к тем методам и ценностям, которые достаточно распространились в остальной части отрасли. Потому что деньгами квалифицированных разработчиков привлечь уже невозможно, для них важны другие аспекты.

Что он делает.

• Drive the change - в процессах, технологиях, культуре. Тимлид с 10-летнем стажем думает не ос своем комфорте и зарплате, а о том, как улучшить мир, и ему нужны адекватные вызовы.
• Оградить инженеров от тяжелых процедур. Стараться хотя бы.
• Уникальные задачи. В Сбере - вопрос производительности процессинга, и было много драйва с предложениями.
• Понятная система компенсации. Не всегда можно целиком, но хотя бы понятная модель ценности.
• Ясный путь карьерного роста.

Александр поговорил о способах мотивирования.

• Формальный - бонусная часть зарплаты, по KPI. Плюс - внешняя управляемость. Эффективно на начальном этапе, пока новое складывается. Минус - обивает intrinsic мотивацию, и это жопа. Плюс - ищут способы обхода.
• Субъективные - система оценка при фиксированной большой зарплате и ранжировании непосредственным руководителем. Плюс - работает на внутреннюю мотивацию, человек не думает как бы формально выполнить KPI. Минус - требует механизмов компенсации произвола: переход между командами, внутренний рынок персонала. И это - большая нагрузка на HR.

И в конце были простые рецепты.

• Забота о коллективе
• Коммуникация приоритетов
• Обучение как часть стратегии (включая: объяснить Javadev почему Webspere здесь правильна).
• Интеграция целей ИТ в общие цели предприятия/группы (включая просвещение)
• Коммуникации, бытовые условия
• Обеспеченность средствами производства

Антон Трекин (Дойче Банк) Миграция сложных банковских систем

Антон рассказывал о проекте укрупнения систем расчета рисков, который идет в Дойчебанке - переходе от 30+ систем к нескольким основным. прагматическая цель - устранение дублирования и снижение требуемых вычислительных мощностей, которые реально дороги - потому что расчет рисков - вычислительно сложная задача, а объемы данных велики.

Что важно - рассказ был не с технической, ИТшной точки зрения, а из более высокой рамки бизнес-целей банка. С этой же точки зрения рассматривалось и построение процесса, на примере конкретного этапа проекта, когда определенная часть расчета рисков переносилась из системы А, сделанной на устаревших технологиях в более крупную и современную систему Б. Особенностью являлся перенос по бизнес-продуктам, что позволило переключать группы пользователей. При этом обеспечивается параллельная работа обеих систем вплоть до полного переноса функционала из А, включая отражение результатов расчета рисков из новой системы в старую, необходимых для полноценного функционирования отчетов в старой системе.

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

Асхат Уразбаев (Scrumtrek). Lean в корпоративной разработке. Проблемы и особенности больших проектов

Я выделил этот доклад в отдельную категорию - потому что он отличается от всех остальных. Я бы отнес его к неожиданным докладом, если бы не слушал Асхата на SECR, где он говорил на ту же тему. Но этот доклад - не повторение, а развитие темы.

Асхат рассказывал о настройке процессов в больших проектах. О проблемах, которые возникают, и методах настройки. По месту. Речь не идет о внедрении Agile и SCRUM, более того, он не всегда адекватен реальной потребности проектов по разным причинам. Проводится именно анализ и конкретная подстройка. Тем не менее, общие методы - есть. Для анализа очень помогает нарисовать фактический процесс.

А для оптимизации часто полезно перейти от функциональных команд к feature team, которые содержат всех специалистов. Не всегда повсеместно, однако для важных проектов - да. Начать лучше с одной, посмотреть что будет. При этом, однако, возникает проблема узких специалистов, которых обычно меньше чем требуется, например, по интеграции. Хороший способ - когда они работают как консультанты, передавая умения членам команд, для начала в области типовых задач. Тут как с DBA: настроить БД - это высококвалифицированное умение, а вот добавить таблицу или поле должен уметь любой разработчик, и обеспечить это - не представляет проблемы. Бывают и другие конструкции, когда формируются не консультанты, а команды поддержки, сфокусированные на какой-либо области. например, архитектуре или нагрузочном тестировании, и они обеспечивают ее другим командам как сервис. Или помимо feature team делают виртуальные команды по специализациям. Но важно, чтобы во всех случаях был driver для деятельности, который побуждает к результату.

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

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

ALM от Microsoft

Доклады об ALM от Microsoft касались преимущественно TFS как средства организации работ, а также средств поддержки системы на этапе эксплуатации. Архитектурных средств VS Ultimate в докладах не касались.

Евгений Злобин (Microsoft). Опыт внедрения крупных ALM проектов. Мифы и реальность

Очень интересный доклад, рассказывающий о двух реальных кейсах внедрения TFS в больших разработческих компаниях

• Эволюционное внедрение в Ситроникс
• Революционное внедрение в Лаборатории Касперского

Сначала была совсем небольшая часть, в которой Евгений рассказывал преимущественно о проблемах и мифах - детских и взрослых. А потом - перешел к внедрению в Ситроникс. Эту часть готовил Александр Бирюков из Ситроникс, который не смог приехать, но Евгений в этом процессе участвовал и озвучивал слайды Александра. А потом он передал слово Борису Климову из Лаборатории Касперского.

Надо отметить, что несмотря на различия, в обоих проектах много общего.

• Внедрение было инициировано сверху - руководству компании нужна была однородная система управления проектами для прозрачности процесса и интегрированных отчетов. Если же говорить об уровне команд, то для одних эnо был шаг вперед. а для других - лишь смена инструментария без увеличения функционала - что, естественно, влекло определенный негатив.
• Внедрение было постепенным, с переходом со старых систем на новую с перегрузкой данных. Революционное внедрение в Касперском отличалось более резким переходом по проектам или по группам проектов, но все равно одномоментным не было. Впрочем, для больших фирм это естественно, иначе - невозможно.
• Проводилось обучение сотрудников, организовывалась линия поддержки - потому что инструкций все равно недостаточно. формы были различны.

Александр Яковлев (Microsoft) DevOps: Соединяем разработку и эксплуатацию с помощью Team Foundation Server и System Center

Александр вживую показывал возможности System Server по мониторингу и способы, как зафиксированные там инциденты передаются в TFS разработчикам, как запрашивается информация, как снимать детальные кейсы с помощью IntelliTrace и передавать их. Ценность такой демонстрации - в том, что она реально показывает совместную работу разнородных инструментов, которые в совокупности поддерживают единый процесс. Демонстрируется синергетический эффект совместного применения, который без таких этого распылен по функционалу систем по-отдельности и ускользает от восприятия.

Александр Чеснавский (Microsoft) Корпоративная разработка ПО: рецепты успешной организации процесса

Этот доклад открывал конференцию, но, на мой взгляд, был не слишком удачным. Александр попробовал показать, как ИТшникам убедить бизнес, что ALM-системы - необходимы. С использованием метафор - ресторана, вкусной еды. Но, на мой взгляд, метафоры сильно хромали и, более того, могли быть истолкованы негативно, особенно менеджерами. Та же метафора ресторанного бизнеса - пособий, как открыть ресторан куча, но статистика выживания ресторанов вовсе не позитивная. С моей точки зрения, для начала ИТшникам надо самим осознать необходимость ALM-систем, убедиться в этом. А не просто знать, что ALM - это круто, ново и в тренде. И тогда - они смогут передать свою убежденность бизнесу. А вот этой части - не было.