2014-05-25: AnalystDays-2014 - ожидаемо высокий уровень

Короткая ссылка: AnalystDays-2014

Ссылки сюда (3) →

О других конференциях

В субботу 24.05 был на конференции AnalystDays-2014 в Москве. Уровень конференции был выше предыдущей, и она собрала больше участников, неожиданно даже для организаторов — около 500 человек. А для аналитиков это много, потому что их не так много в современном ИТ. Web-разработка и разработка небольших проектов обходится без них, функции проектирования выполняют квалифицированные разработчики или дизайнеры интерфейсов. И в некоторых докладах приводили примеры, что спрашивая на форуме об организации процесса «кто должен проектировать интерфейсы» — аналитиков даже не упоминают — про такую специализацию вопрошающий не знает :)

Впрочем, в enterprise-разработке и в больших высокотехнологичных продуктах аналитики востребованы. Правда, там есть другой тренд и о нем тоже говорили на конференции — это все большая потребность в эргономичных интерфейсах enterprise-приложений. Если раньше на это было наплевать совсем, то сейчас положение изменяется. Так что не исключено, что и там аналитиков потеснят UX-специалисты :)

Правда, это может произойти и неожиданным образом (этого на конференции я не слышал, тут мое мнение): в Штатах enterprise все больше уходит на облачные платформы — и в банках и в корпорациях. В банках этому еще способствует требование регулятора на наличие двух географически разнесенных data-центров. А еще таким радикальным способом они решают проблемы исторически накопившегося зоопарка в своем ИТ-ландшафте, переходя от 50-100 приложений к 2-3. При этом становятся востребованными разработчики и аналитики, владеющие не столько предметной областью, сколько конкретной платформой — для проектирования кастомизации этих приложений в точках расширения и подключения оригинальных приложений, в которых содержится know-how конкретных предприятий. А вот UX там будет в объеме, предоставленном платформой.

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

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

Перед обзором докладов — пара слов про организацию конференции. Она проходила в Измайлово, и по сравнению с Инфопространством там не хватало пространства для общения участников рядом с залами. Ну и сами залы были маловаты для такого числа участников, на многих докладах люди стояли — но это организаторы недооценили число участников. А в целом — организация на высоком уровне, что? впрочем, традиционно для серии конференций Влада Орликова (SQAdays, ADD, SPMconf, AnalystDays). После конференции был afterparty, где настоящей находкой был струнный квартет классической музыки — с одной стороны, музыка есть и хорошего качества, а с другой — она не мешает разговаривать и общаться, что, собственно, и является основной целью участия в afterparty для многих.

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

Мой доклад

Из твиттера Максим Цепков на #analystdays рассказывает о Domain Driven Development как Николай Дроздов :) Не очень понятно, но слушать приятно :))) - Alexander Attsik

Начну я со своего доклада, не потому что он лучший, а потому что обзор — мой. И тут будет не оценка, а рефлексивная аннотация. Я рассказывал про метод Domain-Driven Design — о том, как модель на едином языке заменяет традиционные требования, с примерами построения и модели и единого языка для проекта и фреймом модели для корпоративных приложений, разработанном у нас в компании.

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

А если говорить про метод DDD в целом, то у нее есть вторая часть — о прозрачном отображении модели в код. Наиболее простой вариант, с использованием Domain Model и Rich Objects, имеет свои недостатки, которые мы преодолеваем с помощью так называемых технологических рельсов. Об этом я в докладе не говорил совсем, обычно я рассказываю это на разработческих конференциях, последний раз на SECON, но, возможно, стоит сделать об этом доклад, представив материал с точки зрения аналитика.

Доклад на моем сайте http://mtsepkov.org/DDD-req-AnalystDays-2014, а здесь http://mtsepkov.org/Category:DDD - все мои доклады про DDD.

Лучшие доклады по выбору участников

В этом разделе — о трех докладах, которые участниками были признаны лучшими. Авторы получили ценные призы, за первое место был робот-пылесос.

Юлия Ерина. i-Sys. Клинический случай в коммуникациях с заказчиком

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

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

Отмечу, что «клинический случай» в названии идет из метафоры врач-пациент: Заказчик пришел к Вам как пациент к врачу, за решением проблем. И ваша задача — помочь, а не стать пациентом самому. Поэтому при общении с первым типом — помните, кто из вас врач, не разрешайте себя лечить. А со вторыми — не принимайте к себе критику, помните, что у пациента — есть право на истерику, а истерика у Вас — не уместна.

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

Артём Митропольский. Digital Design. Уязвимости мышления

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

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

Татьяна Васильева. CUSTIS. Analyst’s Guide to GUI: Проектирование интерфейсов как элемент системного анализа

Третье место. Таня — из нашей компании и мне приятна такая высокая оценка доклада. Я слушал доклад на прогоне в компании, поэтому на конференции пошел на параллельный доклад Кости Быченкова, а к Тане зашел в самом конце, увидел, что зал переполнен и люди стоят у стен, с интересом слушают и было много вопросов.

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

Что мне особенно понравилось

В этот раздел вынесены доклады, которые оказались для меня неожиданным сюрпризом, хотя их авторов я уже знал как хороших докладчиков. Они превзошли уровень моих ожиданий, выросли, и это — приятно.

Быченков Константин. ООО «Открытый код». Аналитик — первый помощник «большого босса»

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

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

А были варианты с аналитиком — коммуникатором между группой с отдельным тимлидом, и вариант когда аналитик просто внутри команды. Оба работают хуже, потому что аналитик теряет мотивацию. А в первом (посредник) — еще и переходит на сторону заказчика, чрезмерно защищая его интересы.

Основной навык аналитика — вербальный, умение общаться. А остальное выстраивается потом. И из умения общаться выстраиваются люди, которые умеют принимать решения. И Аналитики у него — выстраивают общение с Заказчиком.

• Регулярное взаимодействие с Заказчиком.
• Итерационный подход к разработке, с выпуском готового продукта.

И родилась интересная метафора «Аналитик у Заказчика должен быть ангелом!»"

Что у них не получилось? Не получилось оценить работу аналитика. Не могут отстраивать. Из-за этого он вляпывается в микроменеджмент, плавают роли, все непрозрачно. И в этом есть проблемы, особенно когда надо руководству объяснить.

В целом компания успешно преодолела период роста. За руководителем остались стратегические функции, картина в целом, а аналитики подхватили остальное. При этом личный вклад — невелик. Но они входят в команду, и вместе делают новое — очень роскошно! И компания оправдывает свой слоган «Мы можем все, на что решимся».

Ирина Сурова. ЗАО «Лаборатория Касперского». Шаблоны трассировок бизнес-требований на больших кросс-проектных продуктах

Совершенно роскошный доклад Иры был в переполненном зале, и не случайно. Ирина достаточно подробно показала в своем докладе, как в Касперском управляют требованиями. Именно управляют, а не ведут их наполняя содержанием. Продукты Касперского — сложные и многокомпонентные, а сами компоненты зависят от отдельных общих библиотек и инфраструктурных служб. Например, Internet Security — это около 10 компонент с независимыми командами, и еще 15 сервисов. А релиз надо выпускать точно к сроку, жесткий time-driven development, и требуется достаточно надежно определить состав будущего релиза в этих условиях.

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

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

Инструментом Управления требованиями у них является TFS. Не потому, что он лучший, а потому, что он принят в компании как общая система ведения дел и поддержки разработки — ведения кодовой базы, поддержки интеграции. Поэтому использование его для управления требованиями — логично. Но при этом сами требования, содержательно — ведутся в другом инструменте, Enterprise Architect. Это было принять еще до внедрения TFS, но отказываться они от EA не собираются — Ира перечисляла, что именно в TFS их не устраивает по ведению требований. Основные претензии — к версионированию и нормальной выгрузке в word-документы. Если бы для WorkItem была такая же поддержка версий, как для кода — проблем бы не было, выгрузку, думаю, они бы допилили. Но этого нет, и содержание требование остается в EA.

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

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

Отдельная ветка контроля — учет в релизах требований, исходящие из позиционирования продукта Касперского, такие как «топ-3 по детектированию вирусов». Или требований от юристов. Для поддержки таких требований все продукты должны обладать определенными фичами, заключающимися в исполнении бизнес-требований, и их реализация должна быть вставлена в релизы.

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

Вокруг TFS накручены

• плагин с автозаполнением полей по умолчанию
• кликабельные отчеты
• нотификации по понедельникам
• роботы: проходят по всем требованиям и пушат «берете-не берете». Пишут PM’ы

После доклада был интересный вопрос про унификацию требований. Ответ: для целей управления требованиями это не важно, достаточно, чтобы скоуп проекта был суммой соответствующих item’ов независимо от формы, и совпадал смысл ключевых статусов прохождения.

Антон Семенченко. ISSoft / CoherentSolutions. BDD or DSL как способ построения коммуникации на проекте — опыт комплексного внедрения

Очень интересный для меня доклад о применении DSL, иллюстрированный практическим опытом.

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

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

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

Штука в том, что в обоих случаях для построения DSL со всеми нюансами не нужен топ, достаточно узкого специалиста, занимающегося конкретно этими вопросами. И этот dsl — дает сразу и модель. А еще dsl такого уровня понимает заказчик.

А дальше наличие этих двух частных моделей позволило связать все в единое целое и фактически реализовать систему заново. Да еще сразу предложить бизнес-профит — dsl для конфигурации конечного принтера, что позволило децентрализовать печать и сократить издержки на доставку. Старая система на это рассчитана не была, а добавить — никто не брался.

Если же говорить об общем подходе, то он заключается в следующем. Когда мы строим некоторую модель, то мы сразу разрабатываем DSL для ее конфигурирования. И после реализации это позволяет покрывать систему тестами, используя BDD. И это фишка. А еще dsl дает способ коммуникации и с заказчиком и с разработчиками, и вот это — реально важно, потому что снимает риск неверного понимания задачи. А этот риск — основной.

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

И тоже самое можно делать при реализации простого API к сложной библиотеки, или простого необходимого подмножества сложного протокола — делаешь обертку как DSL, получаешь тестирование и контролируемое развитие.

DSL они обычно используют текстовый, на основе простых файлов. Подсветку синтаксиса сделать легко, библиотек парсинга и кодогенерации — громадное количество. И потому это — дешево. Модель-то все равно делают и реализуют. И если с самого начала рассчитывать на DSL, то накладные расходы — процентов 10.

Просто хорошие доклады

по этим докладам у меня вау-эффекта не было, и про некоторые я могу сказать, что они могли бы быть лучше. Тем не менее, уровень их — высокий, и «хорошие» в названии раздела — не просто политкорректная формулировка.

Григорий Печенкин. Colvir Software Solutions. Горе от системного ума

В докладе были довольно философские размышления о тренде развитии отрасли, и о месте аналитика в ней, исходя из этих трендов. Там было много конкретных кейсов и примеров (местами, на мой взгляд, устаревших, но это не страшно — они иллюстрировали мысль докладчика, а больше от примера не требуется). С моей точки зрения, не хватало систематичности в представлении трендов и кейсов, но, с другой стороны, может быть в таком виде и лучше: тебе представлена картина мира, в которой ты должен самоопределиться сам, а более систематичное изложение может подтолкнуть тебя на конкретный путь.

А пока — мои заметки о представленной картине.

• Многие в отрасли не знают кто такие аналитики. Разработка сайтов и обходятся без них. Аналитики только в enterprise, а доля этого сегмента сокращается.
• Классическая программа аналитиков — требования, usecase и прочее — устарела.
• Определение Автоматизированной системы из ГОСТ. Мы автоматизируем функции, люди — часть автоматизированной системы. И как следствие перекос в функциональное мышление. Пример — сайт гос.услуг. Функции — и непонятно куда придти. Наконец проходим — и обнаруживаем, что услуга не оказывается.
• В современном мире конкуренция смещается от функций к usability. До enterprise это пока не дошло, но уже доходит.
• Классическая модель излишне идеалистична. SRS — список из 8 требований к usecase. Полнота модели и прочее. Так не бывает. В современном мире, в agile разработке Leffingwell формулирует что «User Story не является требованием» — в старом смысле, с теми критериями, что Agile.

Анна Абрамова. ЗАО "НИПК «Электрон». Формирование и согласование структуры требований

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

Кстати, отмечу, что вопрос «как вы работаете с изменением требований» был одним из самых популярных на конференции. Общий ответ был «нормально работаем», с пояснением деталей.

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

А саму структуру требований я тут излагать не буду, смотрите презентацию и сам доклад. Она вполне рациональна, и, думаю, может быть успешно использована в качестве начального шаблона, если у Вас еще не сложилось своего. Важно только помнить (и об этом было в докладе), что структура требований — она не только для аналитиков. В ней есть заинтересованность у многих действующих лиц — руководители, разработчики, тестировщики… А еще структуру требований стоит описать, а не рассчитывать, что ее читатель поймет по документу, и расшифровать термины «не для аналитиков».

Ольга Павлова. «Собака Павлова». Аналитические навыки менеджера по работе с заказчиком: как и зачем?

Задача всех докладов Ольги — пробудить у людей осознанность в своей работе. Темы осознанности, естественно, различаются. А стиль подачи — достаточно жесткий. Одних он раздражает, но до других — доходит и они изменяются. И этот доклад не был исключением. Я слушал кусочек, потому что параллельно шел мастер-класс Димы Безуглого и там тоже было интересно. Так что пересказывать не буду, приведу (неполный) список приемов, которые я записал в конце. Может, он побудит посмотреть доклад.

• Диктофон — реально запись дает чувство собственной значимости
• Доступность документов. Не вам, а заказчику.
• Рефлексивно упоминать документы — чтобы заказчик почувствовал важность
• Коротко ясно и по-русски.
• Рисовать картинки и схемы
• Игрушка, но легкая
• Не просите написать документ, присылайте черновик — порог чистого листа
• Демонстрируйте интерес.

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

Dmitry Bezuglyy. ООО «Системный Подход». Переосмысление роли Аналитика

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

Суть value stream mapping: картируем процесс, а потом убираем мусор. При проведении этого процесса в компании можно выяснить дофига интересного. Например, выяснилось, что в одной компании разные люди (в руководстве) несколько лет по-разному понимали аббревиатуру СА: Системный архитектор или системный аналитик. Отдел СА считал, что они — архитекторы, требования — это не к ним. А отдел БА считал, что раз они бизнес-аналитики, то СА — системные аналитики, и требования — это к ним.

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

Вадим Мустяца. Deeplace. BDD и спецификации эпохи постиндустриализма

У Вадима был вдохновляющий рассказ про проект для Нацбанка Молдовы, в котором целью было принципиально изменить структуру подачи материала на сайте, и изменить отношение людей. Если метафорически — то сделать проект «Слон с крыльями». При этом слон — большой, и если его делать во всей полноте, то в разумные сроки не уложишься. И Вадим рассказывал про последовательные приближения, организацию сотрудничества.

В трехуровневой схеме Card — Conversation — Confirmation, о которой он рассказывал год назад.

• Card. Голос пользователя. Обвешиваем приоритетами, оценкой, проектом и прочее. Важно, что карточка — она легкая.
• Conversation. Обсуждение. На нем проявляются невербальные знания. правда, за этим надо следить.
• Третий этап — подтверждение. Как понять, что мы поняли друг друга правильно.

Упор в докладе был именно на третий этап. Тут идеально — написать тест, но по площади это не реально. А вот по ключевым аспектам системы, с использованием BDD — вполне реально. И они это делают. И получается не просто userstory, а проверяемая в реализации.

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

Надежда Тарасюк. R-Style Lab. О чем молчит стейкхолдер

Блиц. Достаточно много приемов работы со стейкхолдерами и требованиями, выявление дырок и неявных полаганий через сопоставление. Следите за терминологией, ловите новые понятия, представляйте требования в разных видах… Проверяйте доступ на интерфейсе ко всем статусам документам и операциям над ним — о побочных ветках забывают. Контрольные списки.

Отдавайте соломенное чучело на растерзание — метафора ДеМарко. Плюс — менять легче, чем создавать — для заказчика. А тебе сделать чучело легко. Но профессиональные риски!

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

Там где я не был - отчет Тани Васильевой

Опубликовано с разрешения автора

Таня Васильева делала на конференции доклад Analyst’s Guide to GUI: Проектирование интерфейсов как элемент системного анализа

Общее впечатление

О докладах

Не смотря на то, что я умудрилась пропустить самые интересные доклады, в том числе и те, что заняли по результатам голосования первое и второе места (ну хоть третье застала ;)), впечатление от докладов осталось очень положительное. И сильно более положительное, чем от ПрофсоUX'а. Не знаю, в чем уж тут дело: то ли у аналитиков лучше язык подвешен, то ли, как писал Макс, у них завышенные критерии качества, то ли аналитик аналитика видит издалека.

Было несколько докладов про использование прототипов GUI в работе аналитика. Так что я попала в трэнд. Но об этом ниже.

Об организации

Все отлично: четко, пунктуально, задорно, с едой тоже все супер. В перерывах у некоторых персонажей брали интервью на фоне зеленого экрана))

Не могу не описать содержимое бомж-пакета, который выдавали участникам, ибо оно достойно внимания. Чего там только не было! Значок, открытки, блокноты россыпью от разных спонсоров. Шикарный блокнот конференции, где были напечатаны аннотации всех докладов с местом под заметки по каждому. Печатная версия первого выпуска электронного журнала от российского IIBA с прекрасной статьей про профессиональное выгорание аналитиков (в которой присутствует гениальная фраза: "у Вас есть личная жизнь, даже если Вы этого не замечаете"). И, конечно, самое фееричное: "одежка" для айфона, сумка и (!) журнал Lamoda. В общем, нечего мужикам ловить в аналитике.

И не только

Еще было много закадровых дискуссий и общения с интересными персонажами (ну, по крайней мере, у меня). Например, я послушала любопытный холивар между Дмитрием Безуглым ("Системный подход") и Алексеем Борисовым (Deutsche Bank). Спорили на тему нужен ли в проекте аналитик (не как роль, а именно как профессиональная компетенция) и как под этого аналитика выбить бюджет из заказчика. Дмитрий выступал в роли редкостного тролльчины и приводил всякие аргументы в пользу того, что аналитик нафиг не нужен, а Алексей стоически их отбивал в течение минут 30 с видом человека, невозмутимо катящего в гору здоровенную каменюку (используя при этом интонации Слоненка из 38 попугаев). Правильным ответом по Дмитрию было следующее: аналитик в проекте нужен, чтобы определить, что должно быть сделано и это что - именно то, что надо Заказчику. Мне, правда, показалось что мы с Алексеем это говорили, только немного другими словами.

Доклады

Опишу кратко доклады, про которые Макс не упоминал.

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

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

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

Евгений Казяк. Прототипирование мобильных приложений

В основном, докладчик рассказывал про правила (гайдлайны), которые существуют в разработке мобильных приложений: в айосе и андройде есть свои отличные друг от друга правила расположения основных кнопок, работы навигации и т.д. Эти правила надо соблюдать, чтобы у пользователя не случился разрыв шаблона, и он мог пользоваться приложением без использования каких-либо инструкций на чистой интуиции (ибо по статистике, если пользователь не может разобраться в мобильном приложении в течение 15 минут, он его удаляет).

Николай Киреев. Анализ требований на основе динамических HTML-прототипов и UML-моделей

Страшно занудливый дядька, который сделал необъятную презентацию часа на 4 и успел показать из нее процентов 20%. Но опять же было интересно. Рассказывал про то, как он пришел к обсуждению требований с Заказчиком исключительно на кликабельных прототипах GUI (делает он их в Axure): заказчики пугаются и плохо идут на контакт при виде гигантских "текстовиков" с требованиями и UML-диаграмм (+1).

Несогласна с его пренебрежительным отношением к вайерфремам. Объясни словами, что куда переходит, и вот тот же прототип, только сильно дешевле. Другое дело, что если эти слова будут на бумаге, а система будет с большим числом экранов, которые переходят друг в друга по сложной логике, есть риск прийти обратно к гигантскому текстовику.

Алексей Борисов. Agile команда и не-Agile заказчик. Что делать?

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

Мария и Сергей Бондаренко. Аналитик 80-го уровня: способы достижения эффективности (мастер-класс)

Если бы я услышала этот доклад на первом или втором году работы аналитиком, у меня однозначно случился бы вау-эффект, но на восьмом, когда я получила ручками от описываемых граблей и по лбу и по затылку, было скучновато. Обилие не очень интересной информации + 1,5 часа + душный зал = головная боль.

Началось, правда, все с любопытного интерактива: "к доске" вызвали 3 добровольцев, которые должны были согласно инструкциям представлять аналитика-новичка, опытного и крутого спеца. Зал должен задавать им вопросы, а по результатам проголосовать, взяли бы они на работу того или иного аналитика или нет. Результат подтвердил мои ожидания: крутого спеца брать не хотят, потому денег просит слишком много.

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

[ Хронологический вид ]Комментарии

(нет элементов)

Войдите, чтобы комментировать.

— Максим Цепков • 01:00, 26 мая 2014 • нет комментариев