Блог:Максима Цепкова

Материал из MaksWiki
(перенаправлено с «Blog»)
Перейти к: навигация, поиск

Профессиональный блог Максима Цепкова.

Ранее был на http://blogs.uml2.ru/blogs/maksiq и http://softwarepeople.ru/, затем на сайте компании http://lib.custis.ru/Blog-mtsepkov, а с 19.05.2014 переехал сюда.

Сейчас все посты из старых блогов скопированы на мой сайт, при этом восстановлены посты, утраченные при закрытии портала SoftwarePeople. Полный список статей можно посмотреть в оглавлении блога.

Я в соцсетях

http://www.facebook.com/mtsepkov
http://www.linkedin.com/in/mtsepkov
https://twitter.com/mtsepkov

И у меня есть личный ЖЖ, там путешествия и другие мысли вне ИТ.

Последние посты


2017-11-20: Agile: зачем стоит применять его методы и как именно - выступление на ВОЭ

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


Беседа с Ольгой Гусевой 16.11.2017 на беcплатной online-конференции Великая октябрьская эволюция, которую проводит Анатолий Баляев. Тема — «Agile: зачем стоит применять его методы и как именно».

В современном мире любой успешный тренд покрывается густой пеленой мемов, люди начинают ожидать от него волшебных решений — а потом разочаровываются. Agile — не исключение. Между тем, он появился в IT как средство решение конкретных управленческих задач, с которыми не справился классический менеджмент, и за 15+ лет развития доказал свою успешность — если его методы применяются по назначению. И сейчас он идет в другие отрасли — не потому. что «можно», а потому, что новые вызовы третьей промышленной революции добрались до них. Я расскажу, на какие вызовы и как именно отвечает Agile, какие задачи бизнеса он решает.

Agile vs Gamification - Agile Business-2017 Tsepkov.pdf

В беседе упоминаются мои материалы по Agile, доступные на этом сайте, и, в частности, доклад Agile - ответ на вызовы третьей промышленной революции, а история развития Agile с точки зрения Спиральной динамики с последующей адаптацией к нижним уровням - была в выступлении Agile и игрофикация: за каким менеджментом будущее? (AgileBusiness-2017) (рисунок справа).

В конференции я участвовал третий раз. Конференция преимущественно идет почти месяц по вечерам, но есть и offline-мероприятия. Все записи этого и прошлых лет доступны на сайте конференции, смотрите, там много интересного.

Видео беседы https://youtu.be/pwSFOiGp1LA


2017-11-07: Agile Business Conference - хроники развития Agile в корпорациях

Неделю назад выступал и общался на Agile Business Conference-2017. Это — вторая конференция и сейчас уже можно говорить о достаточно сформировавшемся профиле: это конференция, на которую приходят корпорации, крупные и очень крупные компании чтобы узнать — что происходит с Agile в других сомасштабных им организациях, и что именно им могут предложить. Потому что практически во всех крупных корпорациях сейчас используют или пробуют использовать Agile тем или иным образом. В одних — нацеливаясь на организацию в целом, как делает Альфа-банк. В других — для ведения отдельных проектов, как делает РосАтом. В третьих — для ведение новых разработок, как делает концерн Калашникова. Многие — экспериментируют и ищут свои варианты адекватного использования, и конструируют свои версии.

Если сопоставлять эту конференцию с прошлогодней, то надо отметить, что преимущественно рассказывались другие кейсы с других площадок. И это — естественно, корпорации — медленны, год для них — не срок для получения значимых результатов, о которых можно рассказать. Это касается не только государственных компаний, на конференции был рассказ Wargaming Про Agile-управление портфелем проектов — там характерное время изменений тоже 3-5 лет, не мало. Но вот если смотреть картину в целом, то видно, что в сегменте корпораций идет устойчивое поступательное движение. Со своими победами, поражениями, сменами курса в конкретном случае, но это — не имеет особого значения для продвижения в целом, это про трудности на пути.

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

Agile vs Gamification - Agile Business-2017 Tsepkov.pdf

Мой доклад на конференции '''Agile и игрофикация: за каким менеджментом будущее?''' (AgileBusiness-2017) тоже был посвящен будущему больше чем настоящему. Потому что сравнивать методы, исходя из набора плюсов и минусов можно в контексте сегодняшних задач. А для того, чтобы ответить про будущее, надо положить их в модель этого будущего и посмотреть, насколько они ей соответствуют. И такая модель есть — это развитие общества по Спиральной динамике, уровни которой, с моей точки зрения, хорошо детализируют волны Тоффлера. И в этой картине Agile-манифест соответствует зеленому уровню, а Scrum возник как конструкция управления желтого уровня, которая отсутствует в классическом менеджменте — что и является реальной причиной его успеха. После реального успеха начались попытки его использования на более низких уровнях с адаптацией под соответствующую культуру, часто безрезультатные, которые, собственно, и являются основаниями утверждать, что «Scrum не работает». Конечно, любая организационная конструкция не работает, если не соответствует культуре организации. Как верно отметил Андрей Павленко в своем посте про мой доклад: «Одно из лучших выступлений на конференции и один из лучших слайдов этого выступления. Присмотритесь особо к правой, нисходящей тенденции "адаптации" Аджайла к незрелым уровням спиральной динамики — это же почти исчерпывающий справочник фейлов при "внедрении" Аджайла :)»

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

Слушаю рассказ Shane Hastie (ICAgile) про обучение и сертификацию] Agile. Чем отличаются продажные презентации от системного представления? Тем что в системных люди представляют все поле деятельности, раскрывая его сегменты, в том числе, естественно, обозначая свою практику в них. А Я-центричное продажное представление показывает только собственное поле деятельности. И у Shane Hastie — именно такой рассказ, на карте образования нет ни Scrum ни Kanban… Печалька. Потому что Agile mindset в таком представлении нет, это — обычный продуктовый маркетинг.

В посте — обсуждение о том, что считать продающей презентацией, а что — не считать :)

Асхат Уразбаев представляет исследование Agile в России, провели в этом году. Взяли шаблон VersionOne, который публикует эти исследования по всему миру. Явно идет интерес к Agile вне IT-сектора, и не только в таких композитных сегментах, как телеком и банки. Поскольку исследование первое — нельзя сравнить с прошлым годом. Зато можно сравнивать с тем, как в мире. Что интересно — у нас четверть идет своим путем против всего 8 % на Западе. И вообще — очень много интересного. Читайте отчет, когда его опубликуют — пока он готов, но не сверстан :)

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

Кстати, в комментариях мне рассказали, что российское отделение PMI провело свое исследование про Agile и опубликовало его на пару недель раньше. Интересно сравнить, я пока не делал.

Ksenia Samersova, Wargaming — рассказ опыта Agile в большой организации. Отчасти разочарован докладом. Потому что сначала 25 минут о проблемах большого масштаба, которые вполне понятны. А потом — метафора путешествия, вообще говоря, малой группы людей и простые решения, совершенно несоразмерные поставленной задаче. Ну то есть в метафоре путешествия разговор шел, если не о великом переселении народов, то об эпохе географических открытий, когда Землю исследовали всесторонне. А в рассказе — всего лишь рассказ об организации одной экспедиции.

Что обидно — за докладом явно есть интересное содержание. Потому что взят сложный фреймворк SAFe, который в этом случае (в отличие от ряда других) соразмерен организации и задаче, и реально использован для упорядоченности хаоса. Но то, как это представлено: определили цели, расставили приоритеты — вызывает вопрос: что, во всем Wargaming в течении 5 лет не было ни одного менеджера, который знал, что полезно сделать иерархию целей и расставлять приоритеты? Я из опыта понимаю, что там были проблемы, решить которые было сложно. Но в докладе — не проявлено. Жаль. С другой стороны, может, это и фича, которую дает SAFe: ты можешь наложить его не особо разбираясь в конструкции, и он приемлемо отформатирует хаос? Потому что про сам фреймворк, упорядочивание хаоса показано хорошо, много деталей и процедурных подробностей. Но интересно-то почему именно эти процедуры отформатировали хаос разумным образом, а 3 года альтернативные пути — не смогли? Почему так важно новую бизнес-инициативу не делать сразу, хотя есть заинтересованный Business Owner, а необходимо пройти через митинг раз в две недели? И вот много таких вопросов.

В посте — интересное обсуждение про SAFe и ответ самой Ксении на такую мою оценку выступления.

Anna Obukhova Powerful Powerless Leader. Анна биолог, ушла в IT, менеджмент, а потом вернулась в психологию на уровне биологии, когда механизмы лидерства доводятся до работы мозга. Тема доклада — сопоставление доминантности и лидерства. Доминантность проявляется в клетке, когда среда безопасна и еды достаточно, и ты доказываешь превосходство через агрессию к своим — в клетке нет доступа к внешнему результату. А лидерство — в дикой природе, когда надо искать пищу и защищаться от врагов, вести по неизвестности. С разбором лидерства, характеризуемого ранговым потенциалом, примативность и витальность, определяемых на физиологическом уровне работы мозга. Превосходно.

Доклад был интересен, и разворачивался неожиданной стороной — появился второй пост Anna Obukhova. Лидер: поиск нового + защита своих. Такого человека вы не наймете, он наймет сам. Agile разделил: поиск нового — product owner, защита своих — scrum master, и этим решил проблему дефицита сотрудников. Но — без тоталитаризма, SM на ретроспективе ищет новое или помогает этому. А PO — проверяет безопасность своих предпринимательских идей для команды, экономической или другой. Но это — вторичная компетенция в области главной. Реально — неожиданный разворот доклада, сюрприз-сюрприз!

Сергей Малоземов. Применение Agile в проектах атомной отрасли — рассказан конкретный кейс применения Agile для решения задачи проектирования, вернее, не полного проектирования, а фазы генерации идей. Традиционным образом сделанная адаптация проекта АЭС под европейский требования оказалась слишком дорогой, и потребовалось за 3 месяца придумать способы снижения стоимости при соблюдении требований. И здесь кроссфункциональные команды и открытое agile-общение в сочетании с легкой, но достаточно жесткой scrum-структуризацией процесса сыграли свою роль, результат был достигнут, проработка порожденных идей дало 26 % экономии. Что важно — Agile был встроен в корпоративную среду крупной компании, принципиальных противоречий — не обнаружено, а наоборот, отмечен позитивный эффект от использования. И предполагается это развивать. И для меня — это важный индикатор ментальной готовности корпораций к применению новых методов. И пример — не единичен, например, я недавно узнал на встрече в PMO club, что концерн Калашникова по Agile разрабатывает новые виды оружия.

Кныш Николай и Сергей Щербинин из Райффайзена рассказывают, к чему они пришли в трансформации банка. Интересно, что схему, которую они рассказывали — Chief PO, Tech Lead, Chapter Lead я слышал от Нижегородской компании на тренинге Книберга в 2011: у них было три ветки управления из PO, SM (это chapter-ветвь) и техлидов, и при этом в команды они набирали студентов, силами которых решали весьма сложные разработческие задачи. Правда, компания была не слишком большая, до тысячи человек, однако формально в том, что рассказывал Райффайзен — просто добавили один уровень, потому что у них 60 PO — цифра называлась. Впрочем, это не умаляет ценности доклада Райффайзена.

Алексей Ионов (тренер) и Константин Воронин (Ингосстрах) — про Agile в корпорации. Довольно интересная сборка мозаики под ситуацию, когда компания индустриального общества с соответствующими ему паттернами менеджмента инкорпорирует в себя фрагменты Agile для того, чтобы отвечать на вызов Business Agility. Многие слайды — проблематизируют руководство, подталкивают к переменам, показывая их неизбежность. А решение представляют аккуратно, смешивая новое со старым и сохраняя работоспособность конструкции в целом. При этом в рассказе достаточно интересный мыслительный паттерн: для многих практик Agile мы выходим на корни и аналоги в развитии менеджмента, например, производственный lean или обучающуюся организацию, описанную в пятой дисциплине Питера Сенге и другие. Кстати, композитные конструкции сейчас распространены, Алексей говорит о книгах, которые их описывают: Agile Innovation, Лидер и племя, Драйв Дэниэла Пинка.

И все это — только четверть выступлений, потому что шло три трека параллельно и еще мастер-классы. И в ряде случаев реально приходилось выбирать. Я не попал на выступление Андрея Бадина про Agile в государственных проектах, потому что параллельно был мой собственный доклад, не услышал как дела в Сбербанке и издательстве МИФ, в котором тоже интересный кейс разворачивается, и ряд других. Но будет запись, узнаем.

2017-11-04: книги и материалы по Спиральной динамике, бирюзовым организациям и Agile - как войти в тему

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

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

По Спиральной динамике есть еще интересная статья Марка Розина Путешествие по спирали, в которой он сопоставляет корпоративные культуры уровням Спиральной динамики. Именно он придумал соответствующие уровням названия культур. соответствующих уровням: принадлежности, силы, правил, успеха, согласия и синтеза.

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

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

По Agile. Совсем сложно, потому что нет одной книжки. Основы лучше читать у Сазерленда «Scrum — революционный метод управления проектами», плюс Agile-манифест и принципы. Agile-манифест и Scrum появились 15 лет назад и с тех пор методология и практика — развивались, в частности появился Kanban, и инкорпорирован Lean. Только новые книжки писали для тех, кто знал предыдущие, и не только как теорию, но и как практику. Так что структура — сильно слоистая.

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

А в заключении поста - скрайбинг моего доклада Будущее уже наступило: от Agile к Бирюзовым организациям (Дни PR и маркетинга на Юге 2017).

Agile-Pryug-Scribing.jpg

2017-11-02: встреча по визуальным моделям в Райффайзенбанке - супер!

Вчера был на мини-конференции Райффайзенбанка Использование визуальных моделей в ИТ. Полдня, 150+ участников, 5 выступлений. В трех из них - реальный опыт использования Enterprise Architect в Касперском, Райффайзенбанке и ЛАНИТе. Что надо отметить - опыт очень разный и дополняющий друг друга и это - особенно интересно.

Ира Сурова из Касперского рассказывала, что они используют EA для единообразного ведения требований. В 2010 у них в R&D всех аналитиков собрали в единый отдел по специализации для управления ресурсами, но при этом аналитики работают в проектах, и в каждом проекте - внимание - свой подход к ведению проекта. Определяемый PM. И это - логично, потому что в R&D бессмысленно нормировать процесс. Да и проекты у них очень разнообразные и их много. А прогресс движения проекта - оценивают независимо от внутренней организации. И аналитик должен поддержать тот процесс, по которому работает команда. Аналитики в отделе Ирины отвечают именно за требования, архитектура - прерогатива разработчиков и те ревниво относятся к нарушению границы "если аналитик нарисовал диаграмму классов - она неправильная" (Disclaimer: цитата - неточная, воспроизведена по памяти, и далее - тоже). А по требованиям надо поддерживать текущее состояние продукта и его изменения, потому что для разработчиков важно уметь представлять требования именно в формате задач - что ему надо изменить в системе, а вот для тестировщиков, и для последующей работы - фиксировать состояние системы. И именно поэтому им потребовалась автоматизация, ведение в виде документов просто не позволяло так гибко работать. А тут единицей требований у них является use case, и дальше они их классифицируют по темам и резлизам и делают выгрузку текстовых документов. Потому что разработчикам, оказывается, диаграммы - не нужны, и модель смотреть они тоже не хотят.

Методика, как вести требования и изменения - достаточно тяжелая, у EA тут свои ограничения, с которыми приходится бороться, потому что честной версионности репозитария он не обеспечивает (да, можно хранить репозиторий в svn, но с этим проблемы), и ряд других сложностей. Поэтому методика у них - общая. Но при этом ряд проектов работает с "легкой" версией, используя EA просто как каталог, оглавление use case, а сами требования ведут в отдельных документах. Оглавление при этом испольхуется, потому что EA интегрирован с TFS, в котором отслеживается прогресс движения проектов.

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

Максим Шаломович и Денис Епишев из ЛАНИТ тоже рассказывали про ведение требований в EA, но на примере одного проекта, потому что проекты у них сильно разные и общей практики ведения требований в компании нет. Проекту примерно три года и он развивается, требования часть меняются. Что интересно, они решили ту задачу, которую не получилось сделать в Касперском: они передают разработчикам не выгруженный из EA документ, а саму модель. И архитекторы делают в ней детальный дизайн, а по необходимости - делают выгрузки. И диаграммы на UML разработчики тоже хорошо читают. Внешним подрядчикам тоже могут передать модель, вернее, фрагмент модели, или выгрузку в документ. Что интересно - разработчики уже освоились, и на попытки "срезать углы" и что-то написать в тексте - справшивают "а где модель, так не пойдет". Верифицируют модель на полноту, фиксируют что не проработано - и ставят баги, а не додумывают за аналитиков.

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

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

А Юрий Карабутов и Дмитрий Столяров рассказывали про опыт Райффайзена. Они используют EA совсем по-другому, для описания архитектуры IT-ландшафта банка. В котором 300+ достаточно интегрированных систем, которые непрерывно развивают 50+ команд разработчиков, при этом идет 100+ инициатив одновременно, затрагивающих по нескольку систем. Описание всего этого они и ведут в EA. Структура описания текущего состояния такая.

  • Бизнес-уровень
    • capability - описание бизнес-области
    • service - типа "открытие счета"
    • use case - как именно открывают счета (удаленно, конвейер, бранч)
    • business object
  • Уровень приложений
    • application - отдельная система, строгого определения, что считать отдельной системой нет, опираются на традицию
    • component - от единственной в маленьких системах до 4-уровневой структуры в больших
    • interface - для описания взаимодействия между системами

Проект изменений - Solution создается копированием скриптами в новую модель из описания текущего состояния интересующей части модели, при этом на элемент-источник делают связи. На бизнес-уровне добавляется описание требований, под которыми они понимают пожелания бизнеса разной степени формализации, что, скорее, соответствует нуждам стейкхолдеров (needs), а не requirements. Пожелания ведутся во внешней системе и оттуда импортируются. А дальше для удовлетворения этих пожеланий элементы описания изменяются, добавляются новые, старые помечаются как удаленные, и это все трассируется. При этом регламент изменений - тоже на людях, и консистентность модели поддерживается ночными проверками, выявляющими проблемные объекты, восстанавливающими связи, где возможно, пересобирающими различные сводные диаграммы и отчеты. Такая вот сложная конструкция у них живет и обеспечивает управление IT-ландшафтом банка.

А вот мой доклад Визуальные модели корпоративного приложения (Meetup в Райффайзенбанк 2017-11-01) был не про EA. Он был про различные диаграммы, которые мы использовали и используем в разработке корпоративных приложений для описания бизнес-уровня и для проектирования самого приложения. Для корпоративных учетно-аналитических приложений мы используем собственный шаблон Учетной машины, о котором я рассказывал в ряде докладов, последний из них DDD - модель вместо требований (Максим Цепков на AnalystDays-2014). Шаблон построен на основе Domain Driven Design, в нем используется модель, для описания которой используются диаграммы классов, активности и разработанные нами диаграммы учета. И именно на нем был фокус в моем выступлении, а примеры диаграмм были расширены теми, которые используются для описания архитектуры предприятия и места в нем разрабатываемой системы, а также представления ее через метафору системы. Были примеры диаграмм в свободной нотации, которые, кстати, обычно лучше воспринимаются заказчиками, чем формальные диаграммы, и диаграмм в UML и Archimate, сделанных в Visio и EA. У нас в компании в последних проектах тоже используется, но не он был в фокусе доклада.

И еще один доклад делала Наталья Желнова. Она в режиме демонстрации показывала работу в Bizagi modeler - как от описания бизнес-процесса в BPMN перейти к use case. Правда, на модельном примере - к сожалению, живые проекты, которые она ведет Центре развития технологий Сбербанка она показать не могла.

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

2017-10-29 IT Global Meetup в Питере: в гости ходят не только люди, но и сообщества

Пост на FB

В субботу 28.10 был на очередном #itgm (IT Global Meetup) - это глобальная встреча IT-сообществ Питера, несколько лет назад объединившихся в метасообщество (сообщество сообществ) #piterunited. Эти встречи проходят трижды в год - все сообщества, обычно 500-700 человек, собираются в одном помещении и каждое (которое желает) проводит свой островок с выступлениями. Обычно желающих полтора десятка, вчерашняя встреча не была исключением. Такой формат позволяет выйти за рамки своей специализации и оглядеться вокруг - послушать доклады, пообщаться. Хотя это - возможность, а не обязанность, и многие ее не используют, а предпочитают общаться со своими - так комфортнее. Но со своими-то можно пообщаться и чаще, потому что у большинства сообществ есть еще отдельные встречи.

И вот вчера сообщество тестировщиков SPB SQA Group сделало следующий шаг в общении. Они взяли тему, которая не является узкоспециализированной, а вызывает отклик у многих и устроили на своем островке встречу с другими сообществами, которые приходили в гости. Первый такт было общение с SPb SPM Club в форме обсуждения проблем качества требований - работа в группах, и на старте специально следили, чтобы в каждой группе был минимум один PM, Результатом был список проблем и решений. При этом островок SPM был временно закрыт: ленточка, табличка "менеджеры идут общаться с тестировщиками", и стулья тоже перенесли :)

Второй такт - с СПб СоА (Сообщество аналитиков Санкт-Петербурга), в форме моего выступления про путь от требований до задач, которые надо выполнять. Хотя сценарий был проговорен, само выступление было с учетом того списка проблем, который остался, и некоторые из которых на предыдущем такте снабдили фейковыми решениями "сделать все по правилам". И хотя многое из рассказанного уже было в моих докладах, такого концентрированного рассказа про путь от Needs and Opportunity через Req к Architecture and Design и далее Task - не было. Так что я теперь знаю, о чем делать доклад на следующей #analystdays.

Третий такт - выступление DevOps, Александр Чистяков (Alexander Chistyakov), которым приходится разгребать все те проблемы с требованиями, которые дошли до эксплуатации. Естественно, в эксплуатации возникают проблемы не только с требованиями, но и с реализацией, но в данном случае темой были именно требования. С интересными кейсами...

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

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

Алексей Фёдоров, Ольга Самарина, Тая Толстунова, Ольга Христенко, Люда Ионина, Иван Тречёкас, Юлия Атлыгина, Елена Коренева, Екатерина Гайнутдинова.

2017-10-26 - SECR-2017: Ivar Jacobson и другие

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

На конференции - много умных и опытных профессионалов, и этим она отличается от других. И это - не только докладчики, но и участники, и ряд докладчиков, общаясь со мной, отмечали качество вопросов от слушателей. А еще конференция отличается от других широтой охвата тем, возможностью заглянуть в соседние области, которая, на самом деле, не часто получается. Так устроены многие региональные конференции, задача которых - поднять уровень сообщества в целом. А вот российские преимущественно специализированные - аналитики, java-разработчики, .net-разработчики, интернет-разработка и многие другие. Хотя, тут надо отметить, что ряд конференций интернет-разработки расширяет свою тематику, поскольку web и мобильная разработка сейчас охватывает практически все области IT. И еще широким мероприятием является питерский IT Global Meetup, на котором, кстати, я буду выступать в ближайшую субботу. Возвращаясь к SECR хочу отметить, что широта охвата - увеличивается, хотя формально это, быть может не слишком заметно. Просто отдельные доклады превращаются в секции: в прошлом году пришли аналитики, в этом году - технические писатели и секция TOC и ТРИЗ. И достаточно широко представлены ВУЗы, в том числе региональные, например, из Ульяновска, где ВУЗ тесно сотрудничает с местными IT-компаниями. Интерес ВУЗов и вообще, тез, кто занимается наукой, понятен - SECR имеет статус партнера ACM SIGSOFT и доклады, поданные в форме научных статей (и прошедшие отбор), попадают в электронную библиотеку и индексируются. За лучший научный доклад, кстати, уже несколько лет присуждается премия Бертрана Майера.

Естественным образом, в рамках задачи "заглянуть в смежную область и на мировой уровень", SECR зовет иностранных спикеров. В этом году приезжал Ивар Якобсон, в общем-то человек-легенда. А еще - Эрик Райс, только не тот, который написал про Lean, а тот, который гуру в Usability (их двое, а имена совпадают, поэтому поясняю). И ими число иностранных спикеров не ограничивалось. А еще в этом году был интересный эксперимент: мы предлагали русскоязычным докладчикам делать выступления по-английски. И было достаточно много тех, кто согласился. Одна из целей - сделать конференцию действительно международной и интересной не только для русских участников и спикеров. Потому что иначе спикер, прочитав свой доклад, в общем-то скучает. И вопрос же не только в переводе, но и в слайдах. С другой стороны, для российских докладчиков это получается возможность порепетировать доклад для рассказа на международных конференциях, что тоже ценно. Посмотрим, что из этого выйдет, насколько конференция пойдет в международное русло.

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

→ продолжить чтение…

2017-10-25: Работа с конфликтами и ответственностью в сообществах многих лидеров - выступление на ВОЭ

Беседа с Анатолием Баляевым 24.10.2017 на беcплатной online-конференции Великая октябрьская эволюция, которую проводит Анатолий. Тема - «Работа с конфликтами и ответственностью в сообществах многих лидеров».

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

В конференции я участвовал третий раз. Конференция преимущественно идет почти месяц по вечерам, но есть и offline-мероприятия. Все записи этого и прошлых лет доступны на сайте конференции, смотрите - там много интересного.

Видео беседы https://youtu.be/ay5rlgojBeA


2017-10-19: IT осваивает soft skills по-взрослому - впечатления AnalystDays и ITSpring

Осенний AnalystDays подтвердил то четкое впечатление, которое у меня возникло еще весной на IT Spring: IT интенсивно и глубоко осваивает soft skills. В докладах — не только конкретные техники, но и разные модели сознания и психологии. И это востребовано не только HR или продвинутыми менеджерами, а широким кругом аналитиков и разработчиков. Года три-четыре назад такие доклады на IT-конференции широкого профиля встречались редко и практически не воспринимались. И об этом я буду писать в этом обзоре второй AnalystDays этого года, только что закончившейся в Минске, и апрельской IT-Spring, которая тоже была в Минске и о которой я еще не публиковал отзыва в блоге. Упомяну и весеннюю AnalystDays, которая проходила в Москве, на которой я, правда, был всего один день из двух и поэтому слушал мало докладов — почти весь день общался с участниками после своего доклада. В общем, этим постом я не только делюсь свежими впечатлениями, но и вспоминаю те IT-конференции этого года, о которых еще не публиковал отзывов.

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

→ продолжить чтение…

2017-10-18: Не та нынче молодежь? Нет, она просто другая - и точно не хуже чем раньше!

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

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

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

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

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

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

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

Написано по мотивам обсуждения на FB, опубликовано здесь

IT-Roles - Tsepkov TochkaSborki-2017.pdf

2017-10-11: Спиральная динамика и создание бирюзовых коопераций - встреча в Minsk Knowledge Office

Сегодня был на встрече в Minsk Knowledge Office. Я рассказывал про Спиральную динамику, а потом все вместе обсуждали на конкретном кейсе возможности создания бирюзовых коопераций не в светлом будущем, а в настоящее время. И я хочу поделиться своими впечатлениями со встречи, а заодно - опубликовать презентацию для участников. Видео встречи https://youtu.be/UmWNkova47o

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

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

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

Но основную часть встречи занимал разбор конкретного кейса, который был анонсировал в посте перед встречей. Я хочу отметить, что меня интересует не столько конкретный кейс, сколько возможные сценарии действий и условия, при которых возможна кооперация. Предпосылки тут такие. Сейчас на рынке консалтинга, в частности, в Agile, в работе с ценностями и фасилитации и других, а также на некоторых других рынках, например, в IT, есть достаточное количество участников - небольших компаний, которые внутри устроены как желтые (по Спиральной динамике) самоорганизующиеся команды, быть может с оговорками. Но все они действуют на рынке, который рассчитан на оранжевый интерфейс и потому именно его выставляют. И по этому интерфейсу их находят и заказывают услуги. Дальше в некоторый момент команда-исполнитель может понять, что заказ - не совсем профильный, чего не было видно при начальной диагностике. Именно "не совсем" - то есть ты сам сделать можешь, но качество будет средненькое. В идеальном будущем в этот момент должны сработать некоторые механизмы, привлекающие в кооперацию других исполнителей с более адекватной компетенцией. В настоящем этому препятствует оранжевый контракт, к котором предполагается некоторый результат и компетентность исполнителя по его достижению, и в котором опция привлечения кооперантов не предусмотрена, можно только сделать или отказаться. И ситуация обычно осложняется тем, что у тебя нет надежного кооперанта, которого можно привлечь с гарантией хорошего результата, можно лишь экспериментировать, и сколько надо экспериментов, чтобы получить качество выше среднего - неясно. В общем, тема - интересная и без очевидных решений. Обсуждение дало некоторое количество идей, над которыми буду думать.

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

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

→ продолжить чтение…

2017-10-08: заметки с РИФ-Технологии

RIFtech-logo.jpg

Неделю назад был на форуме РИФ-Технологии в Ульяновске. Ленинский мемориал, 3500 участников, семь параллельных треков выступлений и большая технологическая выставка в холле. И для специалистов и для широкого круга интересующихся, включая школьников. Потому что в Ульяновске проблема: в городе 150+ компьютерных компаний, и им нужны специалисты. А школьники не видят IT-карьеры, а если видят — не подозревают о том, что она возможна в Ульяновске на мировом уровне. И IT-сообщество вместе с региональными властями и системой образования работает над этим, я про этом писал еще несколько лет назад в отчете про Стачку. И приглашение школьников на IT-форумы — часть работы по выращиванию новых кадров.

Я выступал на треке Процессы и управление с рассказом про Роли в проекте — как проектировать разделение ответственности, адекватное особенностям проекта, какие есть типовые варианты, и как разделение ответственности описывать. Передо мной Иван Селевестров рассказывал про Agile.

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

А после обеда был на интересном докладе Сергея Аверина из Acronics «Выбор JS-фреймворка для крупного проекта». Реальная проблема для них - используемые фреймворки предъявляли чрезмерно высокие требования к разработчикам. Для них web-разработка - вспомогательная к тяжелой серверной разработке, по-сути пишется административное приложение. Которое надо не просто написать однократно, а докручивать по мере развития сервиса, и задачи - простые и относительно небольшие: добавление кнопок, отдельных параметров и конфигураций для нового функционала. А те фреймворки (ExtJS, JQuery), которые они использовали - не позволяли это делать, плюс сами приложения были на разных стеках. И они запустили масштабный проект по выбору нового фреймворка, чтобы перейти на него, переписать старые приложения и вообще использовать однородный стек. Проект вели техлиды команд, и в его процессе был практически сделан собственный фреймворк, поняв, что же именно им нужно, но при этом осознав, что развитие будет слишком дорогим. И в результате сделали композитный вариант: добавили к Angular 2.0, который как раз стал гораздо более зрелым к окончанию экспериментов, собственный диспетчер событий, обеспечивающий нужное им взаимодействие и понятность кода, и получили то, что надо. Из важных идеологических вещей отмечен TypeScript. Кстати, весной предыдущая версия доклада была на HighLoad и есть видео.

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

А в заключении - ссылки на мои посты-заметки.

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

О ведении документации - с интересным обсуждением. Еще заметки с РИФ.Технологии. Все-таки разброс используемых технологий часто является большой неожиданностью. Люди в 2017 году говорят, что они видят потенциал confluence и думают о том, чтобы перейти на нее с Word. Мы в CUSTIS используем MediaWiki с 2004 (confluence еще не было), и я уже лет 5 полагал, что вики используют все :) Ан, нет...

Виктор Алексеев А я как не любил вики, так и не люблю. Правда Ворд я тоже не люблю, но меньше
Максим Цепков Ну, люблю или нет - это вопрос личный. А вот технологии коллективной работы на документами - это не вопрос любви.
Асхат Уразбаев Кажется это скорее к уровню зрелости организации
Максим Цепков Ну, да. Просто, оказывается, я сильно переоценивал уровень зрелости IT-компаний, получается... Пост об этом. Ты думаешь, мир уже ого-го где, а он еще не там :(
Асхат Уразбаев Да они же разного возраста
Дмитрий Синяев А когда заказчик заставляет хотя бы Redmine (т.к. бесплатно) завести подрядчика, при этом во всю намекая на Jira - это какой уровень зрелости IT компании?
Максим Цепков Я думал, что в IT организация не может быть столь не зрелой, чтобы использовать Word и (при 10+ сотрудников или проектах больше 2 чел*недель) работать без таск-трекера. И это не вопрос зрелости организации, типа, в отрасли не принято иначе. А оказывается, все не так...
Максим Цепков Не, про wiki погорячился. Все-таки, если над документом работает 1 человек и сам документ не больше 50 страниц, то word может казаться удобнее. Но в посте речь шла о компаниях, которые больше
Arseniy Maslov Maxim Tsepkov чем не нравится Office 365 с Word Online?
Максим Цепков Office 365 - это по идеологии продвинутый GoogleDocs получается. И это - другая парадигма. Я тут ниже с Александром Горником эту тему обсуждаю, и как раз понял, что тут разница именно в парадигмах ведения документов - как есть разница в парадигмах программирования. Я предпочитаю html-wiki парадигму, и wiki люблю без wysiwyg
Александр Горник Вики? Трелло + гуглодоки =). Еще вот есть http://notion.so (только пилотно пробуем пока)
Максим Цепков Гуглодоки - это вариант для небольших автономных документов. Для сложных и долгих проектов - не вариант. А трелло - не про документацию, это ведение дел.
Александр Горник У нас 2 миллиона строк кода, 15000 тестов и 30 разработчиков. Кодовая база с 2008го.
Максим Цепков Круто! Значит вы сумели придумать, как жить именно в таком варианте. А 2м строк кода - это единый проект? Из какой области? И сколько документов (в любых единицах - штуках, килобайтах/мегабайтах)? А организацию работы где-нибудь рассказывали публично?
Александр Горник Да, это один продукт (mindbox.ru). Автоматизация маркетинга. Про организацию работы я рассказывал на аджайл дейс, в этом году буду на agileconf рассказывать. Про документы в объеме не скажу, мы стараемся долгосрочную документацию не держать, только при разработке фичи. Долгосрочное только публичное: help и developers.mindbox.ru
Максим Цепков Да, для краткосрочной googledocs вполне нормально, коллективная работа есть - в отличие от чистого word, ссылки на долгосрочную там тоже делаются. При этом долгосрочная ведется в чем-то еще, описание архитектуры там где- то тоже присутствует. Еще техни...Еще
Александр Горник Help - intercom, в нем суппорты работают и они же отвечают, developers - readme.io. Бэклог к нас в трелло, в карточках эпиков и других где нужно - ссылки на гуглодоки
Ivan Popenko Александр Горник про Notion напиши потом, пожалуйста, как оно.

2017-10-02: Что делать, когда число специализаций превышает размер команды

Специализация в IT все возрастает, и все они нужны в разработке. Раньше достаточно было разработчика широкого профиля вместе с аналитиком, потом появилась специализация на front-end и back-end. А сейчас есть специализации на каждую мобильную платформу, и в целом количество специализаций превышает ограничение численности эффективной команды 7±2. В посте была описана именно такая ситуация, и сейчас я пишу по мотивам обсуждения. Там был дан пример команды.

  1. Аналитик
  2. BackEnd разработчик
  3. Разработчик АБС (Банковская система)
  4. Веб-разработчик
  5. iOs разработчик
  6. Android разработчик
  7. Тестировщик

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

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

→ продолжить чтение…

2017-09-28: как ломаются сложные системы

Выношу из поста на FB, чтобы сохранить ссылку на статью

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

Как ломаются сложные системы

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

Из репоста Никита Зимин Вот это просто вау. Очень близко к тому как я представляю себе работу даже не столь уж сложных систем как например какое-нибудь SaaS приложение.

2017-09-22: Ивар Якобсон приезжает на SECR

Почему я пишу в блоге о том, что Ивар Якобсон приезжает на SECR? Потому что Ивар приезжает второй раз, он уже был в 2013 году и я тогда был на его мастер-классе. И меня поразила энергия, с которой он проводил мастер-класс в свои 70+ лет - это была не просто лекция гуру, это была работа в группах, и он подходил, спрашивал о ходе обсуждения и результатах в конкретной группе (понятно, что участники обсуждали по-русски), давал оценки. А еще меня восхищает в Иваре концептуальное мышление, и, что более важно - его способность к обновлению, способность отказываться от своих же признанных теории и кооперативно(!) делать новое.

SECR-2017-Ivar-promo.png

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

По мотивам моего поста в FB

2017-09-21: встреча в PMOclub

Вчера выступал в #pmoclub, рассказывал об эволюции проектов и руководства ими, тех изменениях которые приносит Agile, и которые придут следом. Было много слушателей, интересное общение.

PMOclub-2017-09-photo.jpg

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

Вынесено из FB, фото Андрея Малахова

2017-09-19: маятник централизация - децентрализация как фактор развития

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

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

В результате получается вот такая схема.

Централизация-децентрализация и культуры Спиральной динамики (Марк Розин).pdf

Эту схему Марк показал в своем выступлении на ПиР-2017, рассказывая о трансформации РосАтома. Которая стартовала в 2005 в красной культуре силы, прошла через централизацию, получив синюю культуру правил примерно к 2011, затем — сильные дивизионы оранжевой культуры успеха к 2016 и сейчас начинает переход к зеленой культуре согласия — эффективно сотрудничающим дивизионам.

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


Источники для интересующихся

2017-09-17: Руководитель проекта - менеджер или специалист?

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

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

При этом сразу был сделан второй шаг: менеджерские компетенции жестко разделили на три: (1) область самоорганизации команды, (2) область помощи команде в организации со стороны Scrum Master, и (3) область менеджера следующего уровня и специализированных служб. И тем самым заблокировали микроменеджмент прямого управления. доказавший еще тогда свою неэффективность, но продолжающий до сих пор оставаться практикой во многих компаниях — не взирая на все призывы теории управления.

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

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

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

2017-09-14: Точка сборки - аналитики Петербурга сделали замечательную конференцию

Сообщество аналитиков Санкт-Петербурга (FB) провели в прошедшую субботу превосходную конференцию ТочкаСборки. Им удалось собрать более сотни участников на платное событие, при этом организация от идеи до проведения конференции заняла всего 4 недели и пришлась на сезон отпусков, август! И это меня очень вдохновляет, особенно потому, что организацией занималось сообщество, а не профессиональный провайдер конференций. Это - реальное свидетельство изменений в мире, о которых я много говорю и пишу, и которые бурно появляются в окружающей действительности сейчас, а не когда-то потом.

Я сам выступал с докладом Роли в проекте: как поделить поляну ответственности (ТочкаСборки-2017), в котором свел воедино и переосмыслил рассказываемое на эту тему на разных конференциях.

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

Пост Алексей Фёдоров жжет на #ТочкаСборки - великолепный интерактив, вывод аудитории на рассказ историй!

Аналитик - это кот ученый на дубе.

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

А серьезно - хорошая картинка про состояние потока, эмоции от задачи в координатах мастерство-сложность.

Пост Ольга Самарина на #ТочкаСборки - хороший рассказ про выявление стейкхолдеров, особенно имеющих косвенное отношение к проекту. Много подсказок, наводящих вопросов, схем для структуризации, много историй и кейсов. Любимый вопрос на интервью "А с кем еще поговорить?" "Вредителей надо знать в лицо и с ними работать". Вопрос "А чем вы занимаетесь?" с выявлением ресурсоемких, но рутинных задач.

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

Пост #ТочкаСборки Григорий Печенкин - замечательная схема графической работы с ожиданиями и целями системы. Рисуем в формате, аналогичном диаграмме use case проблемы. которые должна решить система или цели, которые достигнет, а дальше - те функции, которые должны обеспечить решение задач. И в целом в докладе множество простых интуитивно-понятных схем, не перегруженных нотациями, которые легко использовать в работе. И в конце он показал всего 12 элементов, которых, с его точки зрения, достаточно для 80% случаев! Супер!

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

Ну а это - фото с afterparty.

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

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

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

Это было опубликовано на FB и вызвало обсуждения, в частности в группе Управления проектами

2017-09-09: ПиР-2017 - Россия успешно вступает в мир третьей волны

Пять дней я был на фестивале Практики и Развитие. Если кратко формулировать главный для меня вывод, то фестиваль показал, что российский бизнес достаточно успешно вступает в новый мир, мир третьей волны Элвина Тоффлера. Что меня очень радует, и дальше я расскажу об этом подробнее. Собственно, фестиваль так и назывался «Настоящее будущее». Понятно, что доклады на фестивале были не только об этой теме, было множество различных практик личного и корпоративного развития, потому что фестиваль — это грандиозная встреча тренеров, коучей, косультантов и бизнеса. Но об этом я расскажу меньше, потому что у фестиваля — 14 треков, а я физически мог быть только на одном. А еще отмечу, что у фестиваля — замечательная энергетика, я это ощутил в прошлом году, когда был на ПиРе впервые, и именно поэтому не сомневался, что ехать надо на весь фестиваль, а не отдельные дни. И это — оправдалось.

→ продолжить чтение…

« новейшие ‹ 20 более новых старейшие »