Интересное в мире

2018-02-18: Холакратия - почему критика часто не интересна

Макс Цепков - блог - вс, 02/18/2018 - 09:48
Мой коммент к посту Обнаружил, что в конце прошлого года "Эксмо" выпустили книгу "Холакратия. Революционный подход в менеджменте". (Правда, у них там, видимо, по принципу "сапожник без сапог" отсутствует фото обложки) - https://eksmo.ru/book/kholakratiya-ITD827626/

Ну и, для поддержания кислотно-щелочного баланса - попалась мне тут занятная критическая статья "Холакратия – это тупик" ...

То, что Эксмо выпустили книгу - прекрасно. На Озоне, где ее можно купить, фото обложки есть и в посте оно оттуда.

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

Итак...

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

Так вот, товарищ эксперт смотрит на холакратию через свою призму традиционного управления - и ничего не понимает. И вот черты этого непонимания, и общий тон - знакомы еще по аналогичным статьям про Agile 10+ лет назад. И разбираться с этим по фактуре - нет смысла, потому что проблема в другом mindset, а он тут явно не сформулирован. Не, по фактуре проблемы тоже есть, это Алексей Ильичев (Alexey Ilyichev) выше написал, но вот смысла в этой дискуссии нет никакого. А на уровне mindset - каждый находится на своем уровне, и для роста должны быть внутренние причины, дискуссия в этом не убеждает ни разу.

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

В любом случае - нынешний этап - не пропаганда для завоевание мира, а сбора единомышленников, которые готовы пойти. А завоевание мира придет с подтвержденным успехом эффективности и распространением метода. Как с Agile для меня маркером успеха стал 2010-2012 года, когда IBM и Microsoft начали работать над переходом на Agile, ломая свою корпоративную культуру. При том, что оба были эффективными лидерами своих рынков. Причина проста: лучшие выпускники американских университетов перестали конкурировать за их оферы, уходя в стартапы со словами "вы, конечно, лидеры, но я выбираю свободу самореализации". И они поняли, что если так пойдет, то они останутся без лучших - и перестанут быть лидерами. И потому начали меняться. То же произойдет с бирюзовыми организациями и холакратией, и успех, естественно, будет не у нынешней первой версии - Scrum тоже прошел долгий путь эволюции до успеха, рядом появились другие методы, в частности Kanban. То же будет и здесь.

Категории: Интересное в мире

Л. Дерек. «Великая химия». Главы из книги

newtonew научпоп - пн, 02/12/2018 - 17:29
Читайте введение и 13 небольших глав о важнейших вехах в истории химии: от способа добычи золота из золото-серебряного сплава, который был открыт в 1 веке до н.э., до выделения в 2004 году физиками Андреем Геймом и Константином Новоселовым одноатомного графена. «История химии, — пишет Лоуи, — это повесть о том, как человечество училось воссоздавать недостающие „инструкции по применению“ для материального мира. Немалое упорство, отвага, ум (и немалая доля здорового сумасбродства) потребовались, чтобы привести нас туда, где мы находимся сейчас. Работая над этой книгой, я старался отдать дань уважения всем, кто сделал это возможным».
Категории: Интересное в мире

2018-02-11: TeamLead Conf - впечатляющий старт

Макс Цепков - блог - вс, 02/11/2018 - 02:29
О других конференциях

Два дня, 08-09.02.2018 был на новой конференции Олега Бунина для тимлидов TeamLead Conf. 474 участника, и два трека очень хороших докладов. Очень высокий уровень по содержанию, по подготовке докладов, по компоновке программы. Я был на многих конференциях, достаточно много знаю в IT, так что ситуация, когда доклады в каждом слоте несут ценную для меня информацию, вызывают размышления - редкость. Тут было именно так. И, надеюсь, дальше будет не хуже. Потому что путь от разработчика к тимлиду - это актуальная тема. Я, кстати, специально не пишу "руководитель команды", потому что современный тимлид - он не классический руководитель. И вообще тимлиды - они очень разные, прежде всего потому, что компании - разные, у них очень разное распределение ответственности и обязанностей между сотрудниками, и, как следствие, очень разные тимлиды. И это разнообразие было в полной мере представлено на конференции.

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

Началась конференция очень грамотной раскаткой докладов: Nikolay Krapivnyy из badoo рассказывал про рост компании от десятка до сотен, а за ним Георгий Могелашвили из Booking.com рассказывает про рост IT от 400 до 1500. Пост на FB.

Пост на FB Nikolay Krapivnyy из badoo. В целом очень интересный рассказ о внутреннем устройстве быстро развивающейся компании, выпускающий два релиза ежедневно, на сложном высоконагруженном продукте с достаточно сложной организацией компании. Спасибо!

Пост на FB Nikolay Krapivnyy из badoo. Характерный штрих по темпам современной разработки. Малое изменение за пару дней, а не несколько часов это проблема. В пару дней надо укладывать мини-проект для рекламной компании, а то окно возможностей закроется. Где в enterprise мыслят в таком темпе разработки?

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

Пост на FB Георгий Могелашвили (Georgiy Mogelashvili) из Booking.com. Были команды с TeamLead и Product Owner, и они решили сделать команды без teamlead - потому что бурный рост, их не хватит. Эксперимент. Получилось. Георгий рассказывает, как разложились обязанности teamlead - решение конфликтов, фидбэк сотрудникам, выставление оценки. Реально интересно. Фидбэк, например, дают парами друг другу по графику. А оценки все ставят всем за круглым столом - и работает без конфликтов. Но все это - не само, bootcamp для команды и помощь на старте. В принципе, автономия сработала. Но возникают проблемы с ротацией сотрудников - сработавшиеся команды откатываются; ростом сотрудников без поддержки и engagement (они измеряли по google research perfect team). В результате teamlead вернулся, но в ограниченном объеме - он подключается только в ситуациях необходимой поддержки. Называется это servant leader. Основной фокус теперь - рост людей, но он отстраивает среду для этого, а не сам это делает. Так что в целом эксперимент говорит о том, что команда без Team Lead работает хуже, чем с ним, однако, автономность возможна, особенно в короткую, а помогать надо точечно.

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

Пост на FB Евгений Россинский Очень интересный рассказ. У них были команды, сформированные по технологиям (backend, web, разные мобилки), где каждый руководитель был экспертом в технологии, подбирал и выращивал специалистов. Но были проблемы с time to market. И они перешли на команды по value stream. Но при этом разработчики в каждой команде правят общий код на каждой платформы, и релизный цикл - тоже по платформам. Поэтому команды по платформам - восстановились. И сформировалась довольно сложная конструкция, которую Евгений и рассказывал со многими деталями и особенностями организации и коммуникаций.

Пост на FB Nina Scheglova из Lazada (Юго-Восточная Азия, технари в Москве, Въетнаме и Сингапуре) рассказывает про матрицу компетенций тимлида. Я тут подумал, что в IT, да и в другой технических отраслях часто смешивают soft skill, как коммуникационные, эмоциональные и другие компетенции, не связанные с профессиональной работой, с профессиональными компетенциями менеджеров. Ведь менеджер - это тоже профессия, и у нее есть свои hard skill.

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

В конце презентации - слайд со ссылками. Матрица тимлида https://goo.gl/zPw4GH еще есть тестировщика, программиста и дизайнера.

В комментариях к посту есть обсуждение содержания матрицы, а еще - обсуждение разницы soft skill и hard skill менеджера, которое я скопирую.

Ekaterina Semenova Hard skills менеджера мы целенаправленно не расписывали - они очень отличаются даже в рамках одной компании. Где-то много-много специфичных инструментов, а где-то - макросы и программирование в Экселе.
Максим Цепков Екатерина, мне кажется, Вы hard skill менеджера понимаете в IT-смысле - как владение определенными IT-инструментами. А я их понимаю по-другому, а именно, как как профессиональные скилы менеджера. Они ведь есть. То есть деление на soft skill и hard skill - не по тому, используются ли какие-то технические средства, а потому, что hard skill связаны с профессией (дисциплиной), а soft skill - от нее не зависят. Менеджер - это профессия, а менеджмент - дисциплина и у нее есть свой набор hard skill, которых учат, обучая менеджменту.
Ekaterina Semenova Теперь я поняла о чем Вы. С такой трактовкой понятий получается довольно интересно. С одной стороны у тимлида должны быть hard skills команды (программирование/ тестирование). И возможно Вы правы, когда разработчик переходит в тимлиды - его скилл, например, коммуникации становится hard skill'ом. Это можно будет обсудить отдельно.
Максим Цепков Там тонко. Возьмем аналитика. У него есть soft skill коммуникации и умение писать тексты, и есть hard skill проведения интервью (с фиксацией результата), в котором коммуникация и написание текстов - важная составная часть. Наверное, что-то аналогичное и здесь.
Ekaterina Semenova Ага. И прокачать можно видимо оба скилла

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

Пост на FB Alexey Kataev skyeng. Вовлеченность обеспечивает общение, а не сидение в одной комнате. Поэтому hangout, камеры и много совместных встреч по работе и даже online-игры.

Пост на FB Alexey Kataev skyeng. Крутая практика работы с тех.долгом - рефакторинг митап. Разработчики вывешивают карточки о всех костылях, которые ему известны. Потому что это - распределенное знание. Дальше уже понятно - обсуждение, превращаем в таски и приоритизируем. А входной митап - круто.

Пост на FB Артур Орлов. 8 стратагем тимлида - клевый доклад о правильных паттернах поведения тимлида, стилизованных под китайские стратагемы. Много уроков - известно опытным, но для тех, кто тимлид недавно - они не очевидны. И подача очень классная.

  • Не стоит бросаться на все амбразуры самому - герой всегда остается один...
  • Когда задачи сообразны навыкам и компетенциям - не возникает обманутых ожиданий
  • Формируй культуру бесстрашных ошибок
  • Разработка и тестирование - одна команда, объединяй, а не разъединяй!

И так далее...

Артур выложил презентацию https://goo.gl/gF7o4q

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

В комментах к посту развернулась дискуссия по этому поводу. Мне кажется, она интересна, и я ее сюда скопирую.

Максим Шаломович На мой персональный взгляд - одно из самых спорных высказываний в докладе. Возможно, спрашивающий и докладчик сильно по-разному понимают документацию.
Максим Цепков Я думаю, скорее, у спрашивающего паттерн, что документировать - это передать знания. Есть такой. Но неверный, это весьма ограничено работает. И Артур это уже знает :)
Артур Орлов Согласен с тем, что высказывание спорное, постараюсь прояснить, свой ответ. Насколько я понял вопрос, он касался документирования знаний по собственно написанному коду, и вот в этом случае, на мой взгляд, она избыточна - код и так должен давать понять что и как он делает. Что касается документации того, что не имеет отражения в коде - то, конечно, она может быть полезной, если понятно, какие задачи она решает. Задокументированный стайлгайд и какие-то базовые принципы, например - очень полезная штука, хоть и не большая.
Максим Шаломович Ну хорошо, давайте конкретизируем. Документированные требования (например, несколько юзкейсов уровня всей системы, "черный ящик", и много юзкейсов уровня каких-нибудь подсистем/компонентов/элементов, "белый ящик")? Документированная архитектура хотя бы уровня структуры, ответственности элементов и интерфейсов взаимодействия? Документированные принципы разработки для отслеживания архитектурных решений a-la тех, что пропогандирует Саймон Браун (для устранения разрыва между моделями и кодом)? Что-то из этого по Вашему мнению и (или) опыту нужно для сохранения и передачи знаний?
Максим Цепков Я вмешаюсь в дискуссию... Тезис был не в том, что документация не нужна. Тезис был в том, что для сохранения знаний необходимо организовывать специальную коммуникацию в команде, когда знания передаются от человека к человеку, а документация сама по себе передачу знаний не обеспечивает. Если мы этот тезис принимаем (а я считаю его справедливым), то вопрос о документации становится вторичным, и ее количество и формы определяются участниками коммуникации - им что-то легче описать, чем запомнить и они это делают.
Артур Орлов Да, все именно так. Собственно, потому мне кажется работающим принцип, что лучшая документация создается тем человеком, которому она понадобилась, он получил ответы на свои вопросы в команде, зафиксировал. Тогда это действительно "работающая" документация )
Максим Шаломович Максим Цепков, я принимаю тезис, несмотря на то, что живу в мире заказной разработки по ГОСТ 34, и вопрос документации для меня, как правило, определяется контрактными обязательствами))) Мне интересно именно из опыта команд, ориентированных именно на сохранение и передачу знаний - какая документация в этом им реально помогала (перечисленные мной в предыдущем комментарии примеры). С одной стороны я понимаю, что архитектурная документация (от HLD до моделей уровня кода) в первую очередь нужна архитектору, поэтому ее с трудом можно назвать эффективным способом передачи знаний от архитектора/аналитика разработчикам (в этом плане совместная работа и шаринг знаний реально должны работать лучше). С другой стороны не могу не заметить, что в крупных распределенных (во всех смыслах) проектах ротация разработчиков и даже лидов довольно высокая. И передача знаний без какого-то персистентного ее хранения (к которому я не отношу голову разработчика :-)), наверное, невозможна. Понятно, код должен быть максимально понятным, но код - это продукт реализации, до которого есть много других шагов (анализ, дизайн - пусть и в максимально легковесном варианте, в рамках гибких ЖЦ). А что еще поможет?
Максим Цепков Я тоже живу в мире заказной разработки, и для части заказчиков мы делаем документацию по ГОСТ или их внутренней нормативке, так что мне это знакомо. Архитектурная документация точно нужна. И ротация разработчиков действительно довольно высокая. Но при этом опыт устная традиция в команде/группе/подразделений является одной из форм живого персистентного хранения. Об этом говорит мой практический опыт в IT, я наблюдаю это у многих заказчиков. Например, составление годовой отчетности ни в одном крупном банке не выполняется по регламентам, хотя они кое-где встречаются, но при этом традиция - живет. А дисциплина Управления знаниями. с которой я знаком, говорит, что это - правильно, что определение, какие знания делать явными и сохранять в артефактах, а какие держать на устной традиции - предмет управления.

Пост на FB Andrew Minkin Учат ответственности стажеров - делают внутренний сервис, через который люди в команде заказывают себе еду в офис :) И они видят, что такое проект в продакшн и зачем надо тестировать. И ущерб конкретный показывают - негатив. Да еще просрочки пробуют вешать на них кормление офиса...

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

В комментариях было обсуждение про эффективность подобной методики.

Эдуард Галиаскаров А практическое воплощение этой умной мысли есть?
Andrew Minkin Могу поделиться опытом как я делаю это в команде. Через несколько месяцев смогу поделиться как я это сделаю в учебном центре. Если конечно у меня получится :)
Эдуард Галиаскаров Интересно, конечно. Я пытался разыграть ситуацию: один студент пишет проектную документацию, другой ее реализует. При этом оценивается только проект, который соответствует проектной документации. В результате стал врагом номер один, похерителем гениев и талантов. Так что пока не решаюсь на повторные эксперименты :)
Игорь Бородихин Нужно измерять эффективность команды с применением этого метода и без, на короткой и длинной дистанции. Может внезапно получиться, что кроме издевательств над джунами (что само по себе неплохо в рамках их профессионального роста) для бизнеса никакого профита такая методика не приносит.
Максим Цепков Игорь, как раз рост джунов и был целью данной методики - потому что все это делали в рамках стажировки кандидатов в компанию. Эффективность стажировки компания меряет - количество и уровень сотрудников, которые пришли в компанию после стажировки против количества трудозатрат сотрудников компании на стажировку. И это - была не первая стажировка, которую компания проводит, так что они смотрят динамику, а эти методы как раз способ обеспечить эффективность для бизнеса.
К сожалению, в социальной сфере нельзя поставить чистый эксперимент: сдублировать команду, потом к одной копии применять некоторый метод обучения, а к другой - его не применять, или применить другой, и дальше сравнить результат. Поэтому такие предложения - не реализуемы.

Пост на FB Начало второго дня #teamleadconf Александр Киселев (Alexandr Kiselev) и Сергей Семенов (Sergey Semenov) - очень правильный доклад про метрики, измеряемые по коду и jira. Идея в индикативных метриках, разработанных под каждую проблему, которые привлекают внимание для разбора ситуации. В докладе - набор проблем и метрики для них. Индивидуальные проблемы - разработчики, которые почти не делают, или наоборот перерабатывают, или не дожимают задачи. Командные проблемы - недостаточно продумывание задачи, неравномерное знание о коде в команде, плохой onboard новых разработчиков, накопление технического долга. У них - стартап готового продукта, который это меряет. Но метрики - понятны, можно и самим мерить :)

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

Да, при разборе в большинстве ситуаций первый шаг - поговорить, понять причину и если действительно проблема - предъявить цифры. Часто цифр оказывается достаточно, люди просто не думают, что таковы потери (а метрики их показывают). Если не помогает - тогда надо думать.

Пост на FB Григорий Петров (Voximplant). Любопытный доклад, смесь физиологии мозга и работы со смыслами. Коммуникация, у менеджера проблема бизнеса из-за сроков разработки или бага, он приносит это сообщение, а разработчика опознает это как "менеджер ругается". Чтобы не было - надо формулировать сообщение так, чтобы оно не опознавалась как социальное взаимодействие двух людей, а как призыв выполнить социально принятый процесс. Например, переоценить сроки, или обсудить проблему. И много разных других приемчиков, включая использование и учет конотаций.

Пост на FB Егор Толстой Performance review в Avito. Масштаб - 1500 оцениваемых, около 10к оценок, в среднем каждого оценивает 9-11 человек. Системе - 3 квартала, один квартал - эксперименты, два квартала по полной. И при этом одна оценка - 10 минут у респондента, 4 часа в квартал. Понятно, что оцениваемый и его менеджер тратят больше. И отдельные метрики, которые показывают, что оценка работает как процесс, позволяет выявить системные сбои (вернее, дает гипотезы о них). Мне довольно интересно сопоставить с нашей, которой уже много лет, и которая развивается. Масштаб у нас сильно меньше. Но вот идея, что главное - не оценка, а развернутый отзыв - она есть и очень важна. Интересно, что в Авито все начинается с самооценки, а еще оцениваемый сам формирует массив профилей ожиданий от него (дает ссылки), по соответствию которым и надо оценивать. И они отдельно разбираются с ситуациями, когда респондент оценивает не по этому профилю. а по собственным ожиданиям. А еще в авито были интересные эксперименты по анонимности: начинали с полностью анонимной обратной связи, и поэтапно двигаются к тому, чтобы сделать ее открытой.

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

Вообще круглый стол был большим и интересным, в телеграм-чате https://t.me/teamleadconf выложены фотки с досок (фиг долистаешь, но можно поиском "круглого стола"). Кстати, сам чат уже переименован в Боль Тимлида и обсуждение кейсов продолжается.

Пост на FB Оценка задач Дмитрий Симонов (Dmitriy V. Simonov) В докладе много про разные скрытые факторы, которые оценку увеличивают и приемы ее уменьшения. Например, devops - профи наладит инфраструктуры выкатки и автотестов, сократив многократно сроки этих этапов. Нет своих - ищите. А терки в команде могут увеличить работы многократно. Например, по поводу правильной расстановки скобок у if. Многое решается регламентами, например, code style. Или по взаимодействию другими командами - чтобы зафиксировать взаимные ожидания.

Пост на FB 1000 и 1 фидбэк Jane Goleva (Lamoda, в inhouse 300 IT-шников). Фидбэк надо Не принимать, но учитывать - это лишь одно мнение. И ты решаешь, насколько измениться. Учила фидбэку в клубе спикеров, где желающие готовились выступать на конференциях. Поэтому фидбэк - публичный и экологичный. Например, правило трех плюсов: не нашел их - молчи. А нашел - можешь высказаться. Но критика - в залоге, что можно улучшить, конструктив, а не негатив. И много-много других мыслей про фидбэк.

Категории: Интересное в мире

2018-02-10: схема storytelling

Макс Цепков - блог - сб, 02/10/2018 - 22:47
Пост на FB

Сергей Гевлич - тот самый, кто придумал объясняшки написал крутую статью про истории с разбором внутренней структуры историй на схеме. И это - очень ценно, что есть схема - потому что с ней можно соотноситься, Я знаю, что многие мои доклады построены не как истории - потому что они про карту мира, а не про поход в этом мире. Но, во-первых, многие - не значит все, а во-вторых, хорошее представление карты мира должно включать в себя истории путешествий, и я их включаю. И теперь у меня есть схема, с которой можно соотноситься. Раньше схемы не было, было просто текстовое описание "идеальной истории" (его же в школе учат, но в сокращенном варианте), с которым соотносить сложно. Это, кстати, как раз про пользу схем.

Категории: Интересное в мире

2018-02-10: вспоминая о зарубежных конференциях...

Макс Цепков - блог - сб, 02/10/2018 - 11:34
Пост на FB

Facebook напомнил: Четыре года назад был на Software Quality Days в Вене. Был у меня такой период, когда я съездил на несколько зарубежных конференций - MODELSWARD в Барселоне, Software Quality Days, потом еще GoToCon в Копенгагене. Интересно было заглянуть, но в целом российские конференции - не хуже и ближе :) Так что дальнейшего развития эта тема не получила. Хотя, может, зря. А отчеты можно посмотреть у меня среди других отчетов http://mtsepkov.org/Conf: MODELSWARD-2013 - первые впечатления, MODELSWARD-2013 - подвожу итоги, Software Quality Days 2014, GoToCon-Cph-2014. А скоро к ним добавиться отчет с #teamleadconf, на которой я был последние два дня.

Категории: Интересное в мире

Вход на сайт