6912
правок
Изменения
м
→Остальные доклады
{{Conf-Ref}} {{RightNote|[https://www.facebook.com/mtsepkov/posts/1739597376097209 Пост на FB]}}
Перед самыми майскими праздниками завершился [https://analystdays.ru/ru/program/55425 AnalystDays-8] в Санкт-Петербурге. На нем было много иностранных докладчиков, отдельный трек на полных два дня, плюс многие из них еще вели мастер-классы. И вот какое впечатление сложилось у меня от большинства их докладов: они представляют собой взгляд на современность через призму прошлого, вернее, даже не прошлого, а позапрошлого состояния отрасли. При этом отчасти этот взгляд оказывается логичен, хотя упускает важные нюансы.
И дальше возникают такие интересные картины, как в докладе Hans van Loenhoud на слайде справа - я это описывал в своем посте.
[https://www.facebook.com/mtsepkov/posts/1732858620104418 Пост FB] '''Hans van Loenhoud ''' "We use waterfall", и классическая картинка из википедии. Это реплика выдвигающим тезис, будто водопад - никогда не существовавшая система, и потому agile борется с ветряными мельницами. Нет, он - есть, и они его не просто использовали, а продолжают использовать. Но при этом сам водопад сейчас сильно изменился, и это тоже есть - переход от old school к новым практикам.
Во-первых, design и все последующее - погружено в циклы Agile Storm, и этот шторм плавает в окружении Analyze. Во-вторых, на входе нет требований, есть задача помочь клиенту (clients ask for help), мы анализируем ситуацию, предлагаем решения, реализуем и проверяем, что ситуация действительно решена. И это - часть общего перехода from digitalization to digital transformation: from IT-supported to IT-enabled, from Engineered to Designed, from Descriptive to Creative. С выходом в Design thinking.
В коментах к посту была интересное обсуждение с Юрой Солоницыным про методологии и их развитие.
А устно мы обсуждали схему с '''Ириной Суровой''' и выяснили, что на ней - идеальное позиционирование аналитиков: с одной стороны, они защищают мир от последствий agile-шторма разработки, а с другой - наоборот. позволяют разработчикам устроить этот самый шторм при желании. '''Аналитик на страже мира и спокойствия''' :)
[https://www.facebook.com/mtsepkov/posts/1733688293354784 Пост FB] '''Roland Gareis''' Perceiving Business Analysis as a Set of Services. Уход от проектной организации, когда аналитик - член такой команды, в представление BA как сервиса. Только вот из доклада совершенно непонятно, чем такая организация отличается от возврата к старой функциональной структуре. Ну, кроме названия: сервис вместо отдела. Потому что рассказ идет по старому процессу, сформированному под функциональный водопад, слова про SLA - не звучат... И вообще дихотомия: сервис или набор процессов. То есть он и проектную команду воспринимает через призму функционального деления, которое является доминирующей призмой восприятия. Которая просто отсекает все новое, или считает его несущественным.
[https://www.facebook.com/mtsepkov/posts/1733000046756942 Пост FB] Roger Burlton. The Road to Business Agility - старые схемы в новой обертке. Надо быть динамичными, знать свои value chain и перестраивать, и на всех этапах - взаимодействовать и сотрудничать со стейкхолдерами - теми же самыми (supplier, regulator, owner, staff, customer), просто стрелка по-другому названа. И в основе, конечно Business Architecture (Захман - гуру). Именно с ее помощью ищут ресурсы. 4 уровня strategic context - business design - business change - business operate, на каждом - свои циклы. Сценарное планирование и SWOT-анализ и так далее...
Гениальная мысль: чтобы быть гибкими - выделите стабильную часть архитектуры :( В тайминг он не уложился. И заключение - супер. И нужна профессиональная база знаний, и профессиональная дисциплина чтобы работать :( Отмечу, что невзирая на старые схемы, авторы совершенно спокойно попробовали приватизировать бренд Business Agility. В отличие от Agile-манифеста, к их манифесту нельзя присоединиться, это - закрытая вечеринка.
На этом я закончу обсуждение докладов из прошлого и перейду к остальным.
= Остальные доклады =
'''Мой доклад [[Решаем проблему заказчика, а не слепо выполняем задание (AnalystDays-8 2018-04)|Решаем проблему заказчика, а не слепо выполняем задание]] ''' был посвящен выходу при реализации проектов на уровень решения бизнес-проблем, даже если Заказчик изначально просит лишь разработку. И не только на начальном этапе проектирования, но и в ходе самого проекта. Например, при проектировании демо, которое не просто демонстрирует, что сделано, а должно дать релевантную обратную связь о том, решает ли сделанное проблему заказчика, или нет. И на последующих этапах обучения и внедрения.
[https://www.facebook.com/mtsepkov/posts/1732758256781121 Пост FB] '''Анна Чуркина'''. От ПО к Сервисам - кейс карт процессинга, который как сервис предоставляется банкам. Расширение рамки проекта от разработки софта до полноценного предоставления сервисам банков, с учетом потребностей конечных потребителей, которым уже банк предоставляет продукт через их сервис. И в этой широкой рамки - появилось много активностей ранней аналитической работы, в результате многие аспекты вскрываются и дорабатываются не на этапе внедрения, а на этапе проработки продукта. Очень полезно, и, кстати, созвучно моему докладу.