Atlantic Systems Guild 2012
Общее впечатление
Три дня 28-30.03 был на конференции 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
По-настоящему управлять проектом - это управлять рисками. Взрослые управляют рисками - страховка жизни, занятия спортом для здоровья, а дети - нет. Но почему-то на работе забывают. Я: думаю, это преувеличение - многие взрослые делают это по привычке или по закону, обязательность, или по другим причинам (спорт), что и объясняет забывчивость.
Дальше были пять типичных рисков - у них в книге и на слайде. И были истории о том, как риски не оценивали, и из-за этого следовали провалы проекта, хотя, с моей точки зрения, однозначной оценки там нет. Например, история про Денверский аэропорт, который больше года не могли пустить потому что не могли запустить инновационную систему доставки багажа, а плана Б не было. Но там - мутная история...
И позитивная часть была не слишком конструктивна. Например, про сроки проекта - что там интервал, и кривая вероятности. У Бибичева блиц на прошлом 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).
Идея, что надо визуализировать - это способствует пониманию, помогает увидеть, говорите ли вы об одном и том же, или о разных. Ребенком вы рисовали, тинейджером - перестали. А это - неправильно. Я: и это все знают.
Было несколько баек, а в конце - воспоминания об интересном, что услышали на конференции и попытки предсказать будущее, с предложением залу присоединяться. Но зал не включился.
