Русский
Конференции для профессионалов индустрии информационных технологий

Цепков Максим Александрович

Главный архитектор решений
CUSTIS
Россия
Москва

Биография:

IT-архитектор, бизнес-аналитик, эксперт и навигатор по миру Agile и бирюзовых организаций.

Проектированием корпоративных и банковских систем занимаюсь 20+ лет, а всего IT 30+. Я убежден, что автоматизация открывает новые возможности для развития, а создавая IТ-системы, мы открываем путь прогрессу и делаем мир лучше.

Работа в больших проектах позволяет сравнивать классический и гибкий подходы. Я знаком с Agile с 2008 года и вижу, что это - способ менеджмента будущего. Я активно участвую в профессиональном IT-сообществе, веду блог на своем сайте http://mtsepkov.org/, вхожу в программные комитеты конференций SECR и Analyst Days, открыт к общению с коллегами на различных площадках и в соцсетях.

Доклады

Решаем проблему заказчика, а не слепо выполняем задание

04.02.2018

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


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

Уровень сложности
Секционный доклад (40 мин)

Тестировщик и DevOps: позволяют ли интерфейсы системы эффективно решать инциденты?

22.10.2017

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


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

Уровень сложности
Блиц доклад (20 мин)

Agile: что надо знать аналитику, чтобы действовать?

13.09.2017

Достаточно регулярно слышишь вопросы, подобные следующему: "У нас в проекте Scrum, мне надо писать тест-кейсы для тестировщиков, и я не понимаю, откуда брать информацию." Когда начинаешь обсуждать, то часто выясняется, что под словом "Scrum" в проекте понимают некоторую оригинальную конструкцию, при этом спрашивающий точно уверен, что именно это - и есть Scrum. Между тем, Scrum и другие Agile-методы - нормированная конструкция, о которой можно прочитать документы, и из которых можно вывести ответы на этот и другие вопросы. Но я не буду представлять документы. Я покажу, как мыслить в логике Agile mindset, получая ответы на этот и другие вопросы. При условии, конечно, что такие ценности Agile-манифеста, как работающий софт, сотрудничество с заказчикам и другие не представляются пустым звуком. Покажу на реальных кейсах от слушателей, решая их проблемы.

Уровень сложности
Мастер-класс (1 ч 30 мин)

Удовлетворенность стейкхолдеров - два разных смысла

13.09.2017

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

Уровень сложности
Блиц доклад (20 мин)

Самоопределяйся технологично!

22.03.2017

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

Уровень сложности
Секционный доклад (40 мин)

Как выбрать для проекта практики проектирования и работы с требованиями

20.01.2017

Методы проектирования и работы с требованиями должны обеспечивать эффективную коммуникацию между всеми членами команды и гибкую разработку софта с возможностью дальнейшей модернизации. Развитие IT накопило богатый набор разнообразных практик, позволяющих достичь этого в проектах разной сложности, масштаба и назначения: user story, use case, BDD, TDD, FDD, DDD, архитектурная работа в SAF, включая и более традиционные подходы. Как всегда бывает с широким набором инструментов, возникает проблема выбора подходящего. Часто просто выбирают знакомый инструмент или пытаются провести сравнение на модельных задачах, но то, что хорошо для небольшой задачи, не всегда подойдет длинному проекту.


В докладе будет сделан обзор различных практик, решаемых благодаря им коммуникационных задач и предполагаемого разделения труда в команде. Также будут представлены способы поддержки развития и модернизации продукта на долгом жизненном цикле. Доклад является развитием моего поста инженерные практики Agile.

Уровень сложности
Секционный доклад (40 мин)

Ответственность за качество в разных ИТ-проектах: в чем она и как ее разделять

31.08.2016

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

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

В докладе будет представлено пространство описания критериев качества и разделения ответственности в проектах, которое мы разберем на подробных примерах.

Выступление развивает темы моих докладов (http://mtsepkov.org) про эволюцию критериев качества (AgileDays-2015) и разделению ответственности (AnalystDays-2015).

Уровень сложности
Секционный доклад (40 мин)

Коммуникация при различной структуре мышления - таксономия против фолксономии

16.03.2016

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


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


Аналитик должен уметь с этим работать, в выступлении я покажу способы работы на основе схемы мыследеятельности и других схем СМД-методологии.

Уровень сложности
Секционный доклад (40 мин)

Разделение ответственности в заказной разработке

02.02.2015

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

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

Уровень сложности
Секционный доклад (40 мин)

Спиральная динамика- понимай ценности и действуй

06.11.2014

Спиральная динамика вошла в мою картину мира осенью прошлого года и дала системный взгляд на многие тренды развития общества и менеджмента в ИТ и за его пределами. О системе в целом я рассказывал на конференции Agile Days , а тут я буду говорить о другом – о том, как она влияет на понимание процессов в компании, отрасли и в мире.

И как она позволяет позиционировать себя в этих процессах, как более осознанно принимать решения.

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

Уровень сложности
Секционный доклад (40 мин)

Разделение ответственности в заказной разработке

29.10.2014
Разделение ролей и ответственности в разработке — одна из самых популярных тем для обсуждений. Причем зачастую участники подобных дискуссий совершенно уверены, что другие просто неправильно понимают круг своих обязанностей, который им достоверно известен. На самом деле никакого «единственно правильного» разделения ответственности не существует — границы надо проводить с учетом особенностей конкретного проекта, поскольку пропорции аналитической работы, технического проектирования, разработки и тестирования в каждом случае разные. За время доклада мы попробуем разобраться, как могут быть распределены функции между ролями в компании-разработчике, между подрядчиком и заказчиком, между ИТ и бизнесом на стороне клиента, и каким образом этим можно управлять. А также обратимся к историческим корням вариантов разделения ролей, поговорим о ключевых особенностях проектов, которые нужно учитывать при проектировании ролевой структуры, и о «тонких местах», возникающих при том или ином разделении.
Уровень сложности
Секционный доклад (40 мин)

DDD - модель вместо требований

01.04.2014
Есть много подходов к работе с требованиями — user story, use case и т. д., — но все они описывают в основном поведенческие аспекты. А что делать, если мы работаем в сфере, где бизнес-требования достаточно сложны и объекты меняют поведение в зависимости от контекста? Domain-Driven Design — подход, превращающий предметную область из «темного леса» в прозрачную систему. Единый язык устраняет трудности перевода между заказчиками, аналитиками, командой разработки и тестировщиками. Это позволяет модели, описанной на этом языке, заменить традиционные требования, которые служат лишь для построения модели, а затем теряют актуальность. Такой подход качественно упрощает процесс проектирования и значительно снижает риски IT-проектов, позволяя бизнес-специалистам заказчика полноценно верифицировать модель системы. А в процессе эксплуатации модель обеспечивает возможность эффективного развития системы на протяжении многих лет вслед за развитием бизнеса заказчика.
Уровень сложности
Секционный доклад (40 мин)

Вы и Заказчик: решаем проблемы, а не отрабатываем требования

28.02.2014
Кто из нас не сталкивался с ситуацией, когда реализованные требования Заказчика оказываются совсем не тем, что ему требовалось? Из-за чего реализацию приходится многократно переделать, если не выбрасывать. В докладе мы расскажем о построении отношений с Заказчиком, нацеленном на решение его проблем, а не на отработку требований. Это не просто рассказ о том, как вам жить, - доклад построен на реальных кейсах, возникающих при взаимоотношениях с Заказчиком. Предложим методы построения отношений, разберем сочетание неформальных и формальных коммуникаций, а также вопросов стоимости и оплаты работ. Еще мы затронем психологическую составляющую на разных этапах проекта. Без этого никак, ведь совместная работа предполагает не формальное взаимодействие, а коммуникации и сотрудничество, с перспективой построения партнерских отношений для совместного создания value. В соавторстве с Андреем Мясниковым и Риной Ужевко.
Уровень сложности
Секционный доклад (40 мин)