Изменения

Перейти к: навигация, поиск
м
Нет описания правки
Следующее сообщение доклада было явно обращено к цифровому миру, представленному на конференции: пойдите навстречу корпоративному миру. Научитесь его понимать и отвечать на его языке. Купить костюм, чтобы одежда не служила препятствием для коммуникации. Он - нуждается в вас, хотя и не умеет коммуницировать. И он - достаточно открыт, ищет инновации, проводится много инициатив по поискам будущего и инновациям, таких как Остров 10-21 или конкурс лидеры России. Более того, на таких мероприятиях как Гайдаровский форум участие бесплатно, а там выступают и присутствуют люди, принимающие решения на уровне государства - и с ними можно поговорить, во всяком случае один раз - но им надо сказать оригинальное, все, что уже где-то было сделано они, скорее всего, не только знают, но и пробовали повторить, и что-то не сработало. А еще - там есть много денег, которые выделяет государство (вроде 1 трлн), а еще деньги есть у самих корпораций.
Сообщение - понятно, более того, сейчас есть массовые движения, успешно сотрудничающие с государством, например, движение Живые города. Другое дело, будет ли оно достаточно интересным для людей из цифрового мира, которые с удовольствием разрабатывают новые высокотехнологичные продукты для того, чтобы отвлечься от этого и существенную часть времени проводить, выстраивая интерфейсы и взаимодействие с тем самым корпоративным миром вместо гораздо более продуктивной своей основной работы. Деньги тут точно не решающий фактор, квалифицированным специалистам их и так достаточно.
Возвращаюсь к содержанию доклада. Структура enterprise-мира была иллюстрирована многоуровневой пирамидой развертывания деятельности: миссия - идея - стратегия - цели+планирование - управление - технологии+производство - продукция+сбыт - деньги. У меня она вызывала возражение, и где-то в середине я понял, в чем именно. Это вытягивание в линейную структуру уровней детализации, которые происходят для разных сущностей - тех, которые OMG Essence называет альфами. Интересно представить пирамиду в этих терминах, и посмотреть на движение по детализации. Потому что параллельное продвижение по нескольким альфам вместо последовательного движения всего проекта по фазам - принципиальное открытие OMG Essence. А еще тут в одну пирамиду сведена структура функционирования, включая управления изменениями и развертывания, а это разные структуры. Но я над пирамидой еще подумаю содержательно - как оно раскладывается, все ли аспекты учтены.
А дальше из рабочей группы можно делать команду. И для этого запускать групповую динамику. А можно и не делать, потому что для многих задач команда не нужна, рабочей группы достаточно. И, более того, у группы есть определенные преимущества в сменяемости состава, скорости формирования и так далее.
Ключевое различия команды
* вместе круче, чем сумма составляющих - неординарные цели
* самоорганизована, автономны по управлению - достижение неординарных целей не организуется снаружи
и так далее, в 8 пар по 4 сегментам, слайд надо будет внимательно посмотреть.
Какие следствия для компании?
* Карты процессов НЕТ, каждая команда создает свои. Как только формализует - станет рабочая группа
* Зато есть карта продукта = карта компетенций = карта команд -- совпадение карт следует из закона Конвея (это мое дополнение)
Когда микросервисов - сотни, то нужна инфраструктура не только для мониторинга, но и для разработки. Например, для быстрого старта разработки нового сервиса, потому что там много нюансов и особенностей, который точно не все знают - это обычно считается редкой операцией для опытных разработчиков, а тут становится массовой. Типовые вещи, например, подключение к нужной базе данных, не заботясь о логинах хочется из коробки. Надо проверить, что разработчик позаботился о метриках мониторинга и алертах. В таком количестве сервисов надо ориентироваться, он лично видел ситуацию, когда три группы разработки пытались реализовать один и тот же сервис, который четвертая уже сделала :)
О том, как это устроено у них - был рассказ. Детали реализации тут не столь важны, презентация интересна как чеклист важных аспектов, о которых стоит подумать и решить системно для всех сервисов, а не делать каждый раз индивидуально. Включая такие вещи, как нагрузочное тестирование и тестирование на первых пользователях. Они не могут запустить сервис на 0.1% пользователей, не взирая на то, что отвалится, они запускают на 10 пользователях и тщательно смотрят, что происходит, а потом - медленно увеличивают. И с нагрузкой - выясняют реальную, а не тестовую нагрузку, тоже аккуратно впродакшн в продакшн доводя ее до предельной и оценивая метрики.
'''Обсуждение'''

Навигация