Просмотр исходного текста страницы Atlantic Systems Guild 2012

Три дня 28-30.03 был на конференции [http://worldconference.ru/ Atlantic Systems Guild]: Том ДеМарко, Тим Листер, Питер Хрущка, Джеймс Робертсон, Сьюзан Робертсон рассказывали о том, как делать проекты. Блестящий состав участников внушал надежды. К сожалению, они не оправдались. Начали они с того, что мир сильно меняется, и концентрированное изложение изменений мира было вполне впечатляюще, хотя по-отдельности все это знаешь. Мэтры - они в отрасли с 80х. Они пережили пришедшее стремительное изменение 2000-х, осознали его. И сейчас - транслируют это осознание другим людям своего уровня, и на Западе - это, наверное, востребовано. Однако, в России отрасль сформирована в конце 90-х - в 2000-х. У людей нет консервативного багажа прошлого, люди знают об изменениях. Их не надо агитировать, они ожидают идей о том, как в этих условиях эффективно работать. Люди живут в стремительно изменяющейся отрасли и как-то умеют это делать. Так что когда докладчики говорят о том, что есть проблема и нечто нужно менять - слушатели уже знают. какие ответы на это даны, в том или ином виде пробовали и знают о следующем шаге - о проблемах, которые порождены этими ответами. А в докладах - только первый шаг. А он - очевиден.

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

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

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

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

Наверное, это объясняется высоким уровнем самих докладчиков. Потому что когда люди успешно применяют достаточно тяжелые практики за счет личных способностей - им легкие практики не слишком актуальны, тем более, что они видят их ограниченность. Они сосредотачиваются на том, чтобы выделять, раньше обнаруживать неправильные ситуации. И антипаттернов было действительно много. Но, опять-таки, во многом прошлые. А еще - успешные люди не слишком понимают, за счет чего они сами успешно это делают. За счет чего держат в голове и обеспечивают те самые checklist'ы из 20 пунктов, которые показывались - они просто делают это. Они выдают этот список, они умеют находить баланс, чтобы не слишком закапываться - и все.

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

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

= Краткое содержание отдельных слотов =

==Изменение мира==

Неплохое начало с заменой повестки - представиться и встряхнуть. Только заменили позавчерашнюю повестку на вчерашнюю :)

Концентрированный обзор изменений. Скорость проектов и принятия решений, изменение людей, видео, распределенные команды, из людей с разными культурами и проникновение культур - InSynchyng. Технологии - мобильники, HTML5, AppStore. 

Интересно:
* Распределенное внимание
* Бесплатный обед во многих крупных компаниях - средство организовать социальное общение, выдрать людей из конкретных мест.

==Мертвая рыба==

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

==Четкий старт проекта==

Цель - разумная, чтобы проекты не стали мертвыми рыбами и, главное, не родились сразу мертвыми.К сожалению, дальше - известные вещи: что конфликты - рабочая ситуация, их надо решать; что нужны четкие цели и критерии запуска и точка принятия решения; что требования не являются фиксированными, по кругу Goal - Scope - Stakeholders всегда идет движение; что каждое требование должно приносить кому-то пользу, если не нашли заказчика, например, на безопасность - ищите; что каждый раз, когда вы ставите систему, кто-то выигрывает, кто-то проигрывает; про то, что надо ставить цели, и с целями должны быть связаны измеримые индикаторы, которые позволяют найти достижимость.

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

Полезные идеи:
* Два приемлемых завершения: успешная поставка или наоборот, ранее завершение. В MS есть процедура раннего завершения. Плохо, когда во-время не прекращают, причем дух неуспеха уверенно витает.
* Схема заинтересованных сторон. С делением Продукт - Зона влияния продукта (оборудование, смежники) - Предприятие в целом - Окружающий мир. 
* Важно описывать не только что проект делает, но и что он не делает.
* Каждое требование должно кому-то приносить пользу. Безопасность, например. Если никто не откликается - значит вы неправильно сформулировали требование, ищите!
* Удовлетворенность клиента тоже можно мерить - для систем с массовым обслуживанием как срок использования сервиса. Правда тут вопрос про срок измерения.

Здесь начался учебный пример - про банкоматы, начиная с первого банкомата в Лондоне в 1972. Увы, пример очень старый, из другой эпохи...

==Workshop выявление рисков==

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

==Pattern Language==

Это о паттернах и антипаттернах поведения. Adrenaline Junkies ond Template Zombies. 86 паттернов. Правда (вроде) только 6 позитивных, остальное антипаттерны. И, к сожалению в этом изложении это очень похоже на навешивание ярлыков: если поведение неправильное - сделайте из этого антипаттерн с эмоционально окрашенным названием, это отдельно подчеркивали. А это будет сильно мешать конструктивному обсуждению, и вообще деструктивно, это - то, за что я сильно не люблю соционику. Конкретные паттерны местами любопытны, но это в книге. По паттернам потом было задание, и их придумали много - они висели.

==Risk Management==

По-настоящему управлять проектом - это управлять рисками. Взрослые управляют рисками - страховка жизни, занятия спортом для здоровья, а дети - нет. Но почему-то на работе забывают. Я: думаю, это преувеличение - многие взрослые делают это по привычке или по закону, обязательность, или по другим причинам (спорт), что и объясняет забывчивость.

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

И позитивная часть была не слишком конструктивна. Например, про сроки проекта - что там интервал, и кривая вероятности. У Бибичева [http://lib.custis.ru/Пуассоновое_горение_сроков_(Андрей_Бибичев,_AgileDays-2011) блиц на прошлом AgileDays] был лучше и короче. А ситуация, когда сроки ставят раньше scope проекта - вообще рабочая, что бы они не говорили. Метрики тоже якобы понятные - сколько затрачено из бюджета и какая часть value сделана. Только вот вопрос - как это реально оценивать, тут есть много вариантов и подводных камней, вопрос не очевиден, а обойден молчанием. 

Реверанс: популярность agile-разработки в естественном управлении рисками. Потому что видно отставание от графика. Наивняк :) 

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

==Requirements Myths==

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

==Collaboration==

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

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

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

Было несколько забавных отступлений. 
* Важность определений - Аристотелева этика. Аристотель дал понятие определения: надо дать класс, и надо дать отличия внутри класса. Человек - животное со способностью к речь. Я: а над этим издевались - Человек - двуногое прямоходящее без перьев.
* Фон Нейман - объем мозга - 10e20. А Landauer сказал - фиг мы столько запомним. Глаз - 10 Mbps. Год - пи*10e7 с в году - за 50 лет набегает 10e9 c, на полосу пропускания - 10e16 бит только. Дальше он оценил запоминание 2 бита в секунду, так что 2Г за 50 лет.

==The Architectural Imperative== 

Длинное вступление про архитектуру зданий, Сиднейская опера: James Robertson - был архитектором. Потом перешли к IT.

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

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

Был тезис, что структура ПО изоморфна структуре команды. Я: получается, что архитектору надо правильно скомопновать команду? 

Понятный checklist из 13 пунктов про архитектуру, увы стандартный список. И что документация должна быть полной, а еще - короткой. 3 точки зрения: Building Block - structure; Deployment; Runtime view (диаграмма синхронизации); а еще workflow, system use cases - это требования, бизнес-процесс.

Был вопрос - как научить создавать хороший дизайн. Ответ: дизайн - имманентный навык, учить только на собственном опыте + книги - они есть.

==Innovation== 

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

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

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

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

Еще в какой-то момент я понял, что надо разбираться с самим словом "Инновация" и уже в рамках подготовки отчета - сделал это. Так вот, по-английски это "the creation of better or more effective products, processes, services, technologies, or ideas that are accepted by markets, governments, and society" (http://en.wikipedia.org/wiki/Innovation). Они отличают от изобретений, делая акцент именно на использовании, принятии обществом. И явно говорят, что хотя прорывные инновации основаны на Research & Development, это не обязательный признак. А еще явно вводят end-user innovation, основанные на нестандартном использовании имеющихся артефактов конечными пользователями. Классика - Друкер, хотя на Шумпетера тоже ссылаются. Если же смотреть русское использование слова, то есмть отчетливый акцент на прорывных инновациях, дающий элитарность термину и отделяющий от всяких рацпредложений. Кроме того, хотя и говорят (http://ru.wikipedia.org/wiki/Инновация) что инновации должны приносить ценность, рассматривают также альтернативные, частичные определения, где этой ценности нет. В общем, как обычно, понятие размыто и смещено.

==Faster==

Faster - тренд современности, делайте все быстрее. Сначала говорили о системах (человеческих), которые достаточно быстро обзаводятся собственными целями, отличными от целей тех, для которых они были созданы. Правда, тут существенная мешанина понятий возникает. Был пример: Word - пользователи заинтересованы в удобном создании документов, а MS - в покупке новых версий, вот и навязывает. в общем-то, Word сделали не конечные пользователи, а MS, так что все логично.

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

== Matching the Terrain ==

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

Они призывали подбирать процесс к каждому проекту, а это, во-первых дорого, а, во-вторых - невозможно на входе. Это как с использованием design pattern при реализации - тщательно выбирать их для каждой задачи - дорого, но и бездумно применять, особенно сложные - тоже дорого (в эксплуатации вылезет), а на старте проекта их выбрать нереально. SCRUM квантует усовершенствование процесса через ретроспективу, есть другие практики, есть проблемы, но всего этого у докладчиков, увы, не было. Были общие слова про формализм и дисциплину, и увеличение формальной составляющей с ростом числа людей. Но тренд современного мира - в том, что мегакорпорации ломают сложившийся формализм, так что текущий вопрос - именно в поиске баланса.

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

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

== The Admirable Craftsman ==

Их новая книга, которую они пишут совместно. Рассказ был о людях, которые нужны проектам. 
* В каждой области есть человек-катализатор. Он не столько делает работу, сколько помогает другим. Ужасно, что человека никто не награждает, не признает, не ценит. Он формально ничего особо не делает. Люди-катализаторы - нужны реально. И надо, чтобы они были в проектах.
* Технологизатор - тот, кто любит изучать технологию и приносит новое. Или могут и не знать технологию, но все равно, готовы учиться и внедрять. 
* Еще роль - медиатор, тот кто позволяет людям заглянуть за рамки конфликта, понять накал эмоций. Важно, чтобы он был.
Я думаю, это ценно - как практический опыт людей, сделавших много проектов. Кстати, сильно перекликается с Белбиным: технологизатор - это Исследователь ресурсов, катализатор и/или медиатор - Душа компании (teamworker).

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

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


[[Категория:Внешние события]]