Comments 26
Для определения причин конфликтов, самое главное это понимание: никто не хочет напрягаться. А всё новое — это причина напрячься.
Если сотрудники принимают участие в сложном запутанном процессе, но им понятен, при внесении правок в этот процесс, даже если они упрощают его, они будут сопротивляться, и от степени их сопротивления, зависит степень конфликта. С другой стороны если пользователи сами предлагают какое-то изменение, они его понимают и им не надо напрягаться. Но в этом случае придется напрягаться разработчику, чтобы понять его. И он предлагает схемы более понятные ему. Пользователю надо напрячься, чтобы понять что ему предлагают, а он этого не хочет и получаем конфликт.
Я конечно утрирую и упрощаю, но я по своему опыту могу сказать, что с любой стороны баррикады, на любом уровне управления, никто не хочет напрягаться и это является первопричиной конфронтаций.
Разрабу нужен софт чтобы упростить работу. Он посмотрел кучу гайдов по нему. Он ему стал понятен. Он просит админа установить. А админ об этом никогда не слышал. Надо напрячься чтобы узнать как его развернуть. Он материт разраба.
Сотруднику тех поддержки стали прилетать новые проблемы, с которыми он не сталкивался, он винит разрабов в криворукости, потому что ему приходится напрягаться чтобы вникать в новое.
Итак далее. Примеров можно кучу привести.
Если сотрудники принимают участие в сложном запутанном процессе, но им понятен, при внесении правок в этот процесс, даже если они упрощают его, они будут сопротивляться, и от степени их сопротивления, зависит степень конфликта. С другой стороны если пользователи сами предлагают какое-то изменение, они его понимают и им не надо напрягаться. Но в этом случае придется напрягаться разработчику, чтобы понять его. И он предлагает схемы более понятные ему. Пользователю надо напрячься, чтобы понять что ему предлагают, а он этого не хочет и получаем конфликт.
Я конечно утрирую и упрощаю, но я по своему опыту могу сказать, что с любой стороны баррикады, на любом уровне управления, никто не хочет напрягаться и это является первопричиной конфронтаций.
Разрабу нужен софт чтобы упростить работу. Он посмотрел кучу гайдов по нему. Он ему стал понятен. Он просит админа установить. А админ об этом никогда не слышал. Надо напрячься чтобы узнать как его развернуть. Он материт разраба.
Сотруднику тех поддержки стали прилетать новые проблемы, с которыми он не сталкивался, он винит разрабов в криворукости, потому что ему приходится напрягаться чтобы вникать в новое.
Итак далее. Примеров можно кучу привести.
В принципе, мы пишем об этом в статье, когда говорим о дополнительной нагрузке. По моему опыту (может мне везло) я встречал людей, которым интересны их прямые обязанности и неинтересно напрягаться для других, особенно когда своих проблем хватает. В вашем примере с инструментом было бы здорово найти DevOps инженера, который тащится от помощи разработчикам в поиске и установке инструментов, тогда конфликт на этой стадии исчезнет. Но появится конфликт с эксплуатацией, которой придется напрягаться, чтобы с этим инструментом работать.
В списке не хватает SRE. Site Reliability Engineering — как раз про удаление барьера между экслпуатацией и разработкой.
Что такое:
?
зы
Немного утомился от повторения фразы: DevOps (и прочие agile'ы) не про ИТ, DevOps про бизнес.
Бизнесу важно, чтобы нашелся бы человек, который бы сказал, я беру на себя ответственность за работу вот этого (ИТ) сервиса, от начала до конца (проектирование-разработка-внедрение-эксплуатация), и все возникающие при этом вопросы я буду решать здраво, эффективно, с достижением нужного качества. Очевидно, один в поле не воин, и чтобы достичь нужной цели (работа сервиса, который создает нужную ценность, с заданными свойствами) такой человек начинает строить команду, в которой у всех, опять же, одна цель (упомянута чуть ранее). И когда админ понимает, что никому не нужн стабильный сервис, который не создает нужной ценности. И когда разраб понимает, что никому не нужен сервис с новыми классными фичами, но который не работает. Вот тогда и появляется DevOps. (да, DevOps не про pipeline'ы, тесты, контейнеры, rest, и прочее)
разрабатывать внятную стратегию развития своего продукта и управлять конъюнктурой рынка
?
зы
Немного утомился от повторения фразы: DevOps (и прочие agile'ы) не про ИТ, DevOps про бизнес.
Бизнесу важно, чтобы нашелся бы человек, который бы сказал, я беру на себя ответственность за работу вот этого (ИТ) сервиса, от начала до конца (проектирование-разработка-внедрение-эксплуатация), и все возникающие при этом вопросы я буду решать здраво, эффективно, с достижением нужного качества. Очевидно, один в поле не воин, и чтобы достичь нужной цели (работа сервиса, который создает нужную ценность, с заданными свойствами) такой человек начинает строить команду, в которой у всех, опять же, одна цель (упомянута чуть ранее). И когда админ понимает, что никому не нужн стабильный сервис, который не создает нужной ценности. И когда разраб понимает, что никому не нужен сервис с новыми классными фичами, но который не работает. Вот тогда и появляется DevOps. (да, DevOps не про pipeline'ы, тесты, контейнеры, rest, и прочее)
Это значит, развивать продукт по плану, который не потребуется переделывать каждые пару дней. Когда этот план продуман и проработан, базируется на анализе рынка и поведения пользователей. Когда фичи в подавляющем большинстве случаев попадают в точку. Тогда количество внезапных изменений будет сведено к разумному минимуму.
P.S. То, что Вы описываете — это и есть функционал энтерпрайз-архитектора. И да, делать надо именно так, о чем я писал выше:-)
Развивать продукт по плану — этом мечта любого бизнеса. ;)
Некоторые бизнесы довольно неплохо прогнозируются (например, предположу что реновация Москвы детально спланирована на несколько лет вперед).
Что делать тогда, когда планы устаревают раньше завершения их планирования? (например, вы крупный банк, и решили запилить мобильное приложения для мелких предпринимателей. что реально болит у мелких предпринимателей — вы можете только предполагать, т.к. ни вы, ни ваши коллеги из банка мелкими предпринимателями не были)
Некоторые бизнесы довольно неплохо прогнозируются (например, предположу что реновация Москвы детально спланирована на несколько лет вперед).
Что делать тогда, когда планы устаревают раньше завершения их планирования? (например, вы крупный банк, и решили запилить мобильное приложения для мелких предпринимателей. что реально болит у мелких предпринимателей — вы можете только предполагать, т.к. ни вы, ни ваши коллеги из банка мелкими предпринимателями не были)
Нужно провести исследование спроса, проанализировать результаты, конкурентные предложения. Это работа для системного аналитика и опять же энтерпрайз архитектора. Промах, конечно, будет в любом случае — но вот его масштаб и глубина последствий при правильно проведенной аналитической работе значительно мньше и не столь критичны, чем В случае тыкания пальцем в небо. А значит, можно будет не спешить с корректировкой и колличество итераций будет существенно меньше. Хороший план, опять же, всегда будет иметь запас на корректировки;-)
Я был неоднократным свидетелем того, как умные опытные люди долго и тщательно продумывали, планировали, запускали продукт, а после запуска выяснялось неожиданное, и в результате на ходу приходилось переобуваться (и то, потому что умные и опытные, в обратном случае продолжили бы копать по старому плану — «эффект ожидания автобуса» в действии). При этом абсолютное большинство сопричастных ИТ-ников думало: нуу тупые, не смогли очевидное предвидеть.
И да, вдумчиво планировать, анализировать, опрашивать, изучать и прочее нужно. Но в некоторых областях, неопределенность остается даже при всех ухищрениях планирования.
И да, вдумчиво планировать, анализировать, опрашивать, изучать и прочее нужно. Но в некоторых областях, неопределенность остается даже при всех ухищрениях планирования.
Еще раз прочитал абзац про DevOps.
Там ни слова про общую цель.
Увы, DevOps без общей цели не работает.
У вас могут быть автодеплои, докеры, автомониторинги, автотесты, автоконфигурации и прочее, но не быть DevOpsа.
И наоборот, быть DevOps, и отсутствовать автодеплои, докеры, мониторинги….
И у вас наглядные примеры тому. Когда внедряют атрибуты DevOpsа, но не сам DevOps.
Примерно такая же история со Скрамом. Проводим дейли митинги, ретро, ператаскиваем карточки и считаем что у нас Скрам. Тогда как Скрам вертится вокруг идеи самоконтроля, саморазвития на основе непрерывной обратной связи.
Там ни слова про общую цель.
Увы, DevOps без общей цели не работает.
У вас могут быть автодеплои, докеры, автомониторинги, автотесты, автоконфигурации и прочее, но не быть DevOpsа.
И наоборот, быть DevOps, и отсутствовать автодеплои, докеры, мониторинги….
И у вас наглядные примеры тому. Когда внедряют атрибуты DevOpsа, но не сам DevOps.
Примерно такая же история со Скрамом. Проводим дейли митинги, ретро, ператаскиваем карточки и считаем что у нас Скрам. Тогда как Скрам вертится вокруг идеи самоконтроля, саморазвития на основе непрерывной обратной связи.
Ну я всё-таки не разработчик и смотрю со стороны на то, как это внедряют в реальной жизни. Есть там общая цель — прекрасный продукт. Беда именно в том, что эту цель трактуют по-разному. И DevOps, где в первую очередь оно Dev, трактуют её исходя из своей системы ценностей. А у Ops она принципиально другая, о чем я и писал. И подружить одно с другим на низком уровне не получится. Надо подниматься выше, на уровень управления продуктом в целом, и там принимать взвешенные решения исходя из стратегии развития, внимательно выслушивая обе стороны. Этим должен заниматься человек с техническим прошлым как минимум. Не видел еще ни одного бизнесс-заказчика, который бы понимал важность и последствия тех или иных технических решений. Т.е. управлять конфликтом, балансируя интересы сторон на благо продукта и объясняя почему было решено именно так.
Цинично отмечу, что «служба эксплуатации» это не первая, а вторая производная от бизнеса. Первая производная — это «служба разработки». «Служба эксплуатации» создается чтобы сэкономить на девелоперах — за счет найма более дешевых опсов, которые возьмут на себя часть работы девелоперов по поддерке продукта.
Даже когда покупается готовое решение — все равно его кто-то разработал и при этом уже произвел подготовку к передаче в эксплуатацию (что включается в цену). Когда разработка ведется в рамках компании — издержки на передачу в эксплуатацию теоретически должны снижаться, но при возникновении разногласий между разработкой и эксплуатацией — они могут даже увеличится. А дальше бизнес смотрит просто — где меньше затраты — когда девелоперы занимают поддержкой или когда девелоперы передают продукт выделенному отделу эксплуатации.
Вроде бы правильные слова про документирование — на самом деле означают создание дополнительной документации специально для опсов. Вроде как документацию для опсов должны писать опсы, но они не могут, потому что ничего не знают и вешают эту нагрузку на девелоперов. И причина проста — опсы не участвовали в разработке и не разбираются в уже существующей документации и продукте. При этом девелоперы пишут простую и понятную со своей точки зрения документация для опсов, а опсы в ней не могут разобраться и усложняют требования к документированию. А это в свою очередь требует больше времени и в результате увеличивает издержки на передачу в эксплуатацию — потому что девелоперы занимаются не своей основной работой, а писательством на заказ. Ну а дальше — эксперименты направленные на вовлечение в процесс разработки опсов, вплоть до переименовывания их в девопсов.
Даже когда покупается готовое решение — все равно его кто-то разработал и при этом уже произвел подготовку к передаче в эксплуатацию (что включается в цену). Когда разработка ведется в рамках компании — издержки на передачу в эксплуатацию теоретически должны снижаться, но при возникновении разногласий между разработкой и эксплуатацией — они могут даже увеличится. А дальше бизнес смотрит просто — где меньше затраты — когда девелоперы занимают поддержкой или когда девелоперы передают продукт выделенному отделу эксплуатации.
Вроде бы правильные слова про документирование — на самом деле означают создание дополнительной документации специально для опсов. Вроде как документацию для опсов должны писать опсы, но они не могут, потому что ничего не знают и вешают эту нагрузку на девелоперов. И причина проста — опсы не участвовали в разработке и не разбираются в уже существующей документации и продукте. При этом девелоперы пишут простую и понятную со своей точки зрения документация для опсов, а опсы в ней не могут разобраться и усложняют требования к документированию. А это в свою очередь требует больше времени и в результате увеличивает издержки на передачу в эксплуатацию — потому что девелоперы занимаются не своей основной работой, а писательством на заказ. Ну а дальше — эксперименты направленные на вовлечение в процесс разработки опсов, вплоть до переименовывания их в девопсов.
Вот именно об этой позиции я и говорил выше в описании подмены понятий. Разработка это не программисты, а «опсы» это не админы. Взгляните на это, как на процессы создания и дальнейшего обслуживания. В обоих процессах будут участвовать как dev, так и ops, практически всегда. Инфраструктуру не dev'ы готовят, баги не админы исправляют.
Что касается затрат всё не так линейно. Процессы эксплуатации и разработки принципиально разные. Разработка последовательная, итерационная. Эксплуатация же на 80% реакция на случайные события. Задачи сами сильно разнятся. Эффективность в разделении заключается не в цене специалиста, оклады программистов и админов различается не сильнее, чем оклады программистов на разных языках, эффективность достигается за счет специализации и разделения процессов. Что бы все свои задачи решали в оптимальном режиме. Эксплуатация обычно дешевле в месяц за счет объема работы и количества сотрудников.
Документацию на любую разрабатываемую систему, не важно ИТ, или дом, всегда изначально пишет разработчик, а не обслуживающая компания, это проектная документация. Далее те, кто занимается обслуживанием, пишут уже свою, по реальной ситуации. И писать эту документацию должны не программисты, а аналитики, архитекторы, и технические писатели.
Что касается затрат всё не так линейно. Процессы эксплуатации и разработки принципиально разные. Разработка последовательная, итерационная. Эксплуатация же на 80% реакция на случайные события. Задачи сами сильно разнятся. Эффективность в разделении заключается не в цене специалиста, оклады программистов и админов различается не сильнее, чем оклады программистов на разных языках, эффективность достигается за счет специализации и разделения процессов. Что бы все свои задачи решали в оптимальном режиме. Эксплуатация обычно дешевле в месяц за счет объема работы и количества сотрудников.
Документацию на любую разрабатываемую систему, не важно ИТ, или дом, всегда изначально пишет разработчик, а не обслуживающая компания, это проектная документация. Далее те, кто занимается обслуживанием, пишут уже свою, по реальной ситуации. И писать эту документацию должны не программисты, а аналитики, архитекторы, и технические писатели.
К сожалению, сведение все к абстрактным «службам» и взаимодействию между ними приводит к катастрофическим последствиям.
Вообще сталкивался с шикарным случаем — большая международная корпорация, процессы прописаны от и до, все регламентировано и прекрасно формализированно. Разработчик написал некий функционал, но бюрократию не осилил, так что запустил свое творение на одном из шаред дев серверов. Все прекрасно работало, данные генерились даже после увольнения разработчика более года. Пока сервером не перестали пользоваться другие разработчики. Сервер погасили и данные перестали генериться — началось расследование что за фигня. Нашли причину, сервер подняли обратно и начали думать что делать дальше. Решили «продуктизировать» функционал в виде отдельного продукта и досталась эта работа мне. И вот этот проект «продуктизации» занял более четырех месяцев! Протащить готовый функционал через все необходимые процессы с написанием и подписанием всех необходимых документов (спека на функционал была написана оригинальным разработчиком, так что все остальные докумены — производные от нее) — более четырех месяцев!!!
Там в компании вообще все печально — банально выкатить релиз на стейдж это: написать стейдж деплоймент гайд (часа 2-3 с паралельным деплойментом в дев энвайроменте); разобраться кто должен подписать этот гайд в этот раз (часов примерно 5) и создать ревью; пинать подписантов до победного конца (недели полторы-две); подождать очередного планнига опсов (1-4 дня); подождать самого деплоймента (1-2 дня); понаблюдать за деплойментом (до 1 часа) скрестив пальцы чтобы в этот раз опс осилил копипаст из гайда в терминал без самодеятельности (бывали преценденты с заходом на продакшн хост вместо стейджа, при том, что в гайде даже ссш команды с правильными именами хостов прописаны). Для продакшна — повторить.
И когда менеджер по работе с клиентами приходил ко мне с пустяковым запросом — минимальный срок я выставлял в полтора месяца. И пояснял — 20 минут на оформление запроса, 5 минут на изменение в коде, 30 минут на тестирование, две недели на подготовку стейдж деплоймента, две недели на стейдже, две недели на подготовку продакшн деплоймента. Более быстрый процесс — только через аварийный деплоймент с визой руководителя на три уровня выше моего начальника. Оптимизация — невозможна, невовремя созданные ревью документов — закрываются как нарушающие процесс. Подписать ревью быстрее чем за полторы-две недели — только с помощью того самого руководителя на три уровня выше моего начальника, у остальных область накрытия живительного пинка маловата.
Причем раньше было хуже — кьюэи были отделены такой же бюрократической стеной как опсы и добавляли от двух до четырех недель на тестирование. Но удалось их втащить в процесс разработки — с автоматической регрессией и добавленим/изменением кейсов сразу по изменению кода.
Вообще сталкивался с шикарным случаем — большая международная корпорация, процессы прописаны от и до, все регламентировано и прекрасно формализированно. Разработчик написал некий функционал, но бюрократию не осилил, так что запустил свое творение на одном из шаред дев серверов. Все прекрасно работало, данные генерились даже после увольнения разработчика более года. Пока сервером не перестали пользоваться другие разработчики. Сервер погасили и данные перестали генериться — началось расследование что за фигня. Нашли причину, сервер подняли обратно и начали думать что делать дальше. Решили «продуктизировать» функционал в виде отдельного продукта и досталась эта работа мне. И вот этот проект «продуктизации» занял более четырех месяцев! Протащить готовый функционал через все необходимые процессы с написанием и подписанием всех необходимых документов (спека на функционал была написана оригинальным разработчиком, так что все остальные докумены — производные от нее) — более четырех месяцев!!!
Там в компании вообще все печально — банально выкатить релиз на стейдж это: написать стейдж деплоймент гайд (часа 2-3 с паралельным деплойментом в дев энвайроменте); разобраться кто должен подписать этот гайд в этот раз (часов примерно 5) и создать ревью; пинать подписантов до победного конца (недели полторы-две); подождать очередного планнига опсов (1-4 дня); подождать самого деплоймента (1-2 дня); понаблюдать за деплойментом (до 1 часа) скрестив пальцы чтобы в этот раз опс осилил копипаст из гайда в терминал без самодеятельности (бывали преценденты с заходом на продакшн хост вместо стейджа, при том, что в гайде даже ссш команды с правильными именами хостов прописаны). Для продакшна — повторить.
И когда менеджер по работе с клиентами приходил ко мне с пустяковым запросом — минимальный срок я выставлял в полтора месяца. И пояснял — 20 минут на оформление запроса, 5 минут на изменение в коде, 30 минут на тестирование, две недели на подготовку стейдж деплоймента, две недели на стейдже, две недели на подготовку продакшн деплоймента. Более быстрый процесс — только через аварийный деплоймент с визой руководителя на три уровня выше моего начальника. Оптимизация — невозможна, невовремя созданные ревью документов — закрываются как нарушающие процесс. Подписать ревью быстрее чем за полторы-две недели — только с помощью того самого руководителя на три уровня выше моего начальника, у остальных область накрытия живительного пинка маловата.
Причем раньше было хуже — кьюэи были отделены такой же бюрократической стеной как опсы и добавляли от двух до четырех недель на тестирование. Но удалось их втащить в процесс разработки — с автоматической регрессией и добавленим/изменением кейсов сразу по изменению кода.
На самом деле, то о чем Вы говорите, это как раз НЕ налаженный процесс. Я работал в подобных организациях. Обычно такое происходит когда:
а) нет единого собственника системы,
б) процессы построены ITSM теоретиками, ни разу в жизни не участвовавшими в реальной работе регламентируемого процесса.
И вот когда оба фактора объединяются — некие абстрактные «идеальные» процессы начинают считаться священной коровой, человека, который был бы заинтересован в нормальной работе, между эксплуатацией и разработкой просто нет, получается всякая разная фигня. А разруливать её некому.
Суть хороших процессов в том, что бы все происходило быстро и предсказуемо, что бы не забывать ничего важного и не изобретать один и тот же велосипед по нескольку раз в день, а не в сборе подписей в листе согласования.
а) нет единого собственника системы,
б) процессы построены ITSM теоретиками, ни разу в жизни не участвовавшими в реальной работе регламентируемого процесса.
И вот когда оба фактора объединяются — некие абстрактные «идеальные» процессы начинают считаться священной коровой, человека, который был бы заинтересован в нормальной работе, между эксплуатацией и разработкой просто нет, получается всякая разная фигня. А разруливать её некому.
Суть хороших процессов в том, что бы все происходило быстро и предсказуемо, что бы не забывать ничего важного и не изобретать один и тот же велосипед по нескольку раз в день, а не в сборе подписей в листе согласования.
Это реальный процесс, в той форме в которой он самостабилизируется. В той форме которую он приобретает в результате взаимодействия с другими процессами. До единого владельца там толстый-толстый слой линейных менеджеров. В том числе и «прекрасно сертифицированных» специалистов по процессам с «огромным опытом».
Проблема в том, что наличие этого процесса как и других никак не коррелирует с достижением цели поставленной бизнесом. А вот количество попыток достижения цели — коррелирует. Каждый релиз — это попытка, которая дает информацию, что же неверного было в начальных предпосылках. В результате — чем больше было сделано релизов, тем ближе фактический результат проекта к ожидаемому. А это как раз критерий оценки проекта с точки зрения бизнеса.
Проблема в том, что наличие этого процесса как и других никак не коррелирует с достижением цели поставленной бизнесом. А вот количество попыток достижения цели — коррелирует. Каждый релиз — это попытка, которая дает информацию, что же неверного было в начальных предпосылках. В результате — чем больше было сделано релизов, тем ближе фактический результат проекта к ожидаемому. А это как раз критерий оценки проекта с точки зрения бизнеса.
— чем больше было сделано релизов, тем ближе фактический результат проекта к ожидаемому.
Или чем качественнее был проработан способ достижения этого результата изначально, т.е. чем ближе к изначальной цели была каждая попытка. Вы говорите про итерационный метод, я — про качество изначальной проработки итерации. Естественно в жизни к хорошему результату приведут только оба пути одновременно, с первого раза всегда на 100% попадать не получится. Каждая неудавшаяся попытка это либо вред, либо недополученная польза, т.е. при итерационном методе всё равно time-to-market большой, просто по тому, что определиться он завершением работы над фичей, а не выводом в продуктив первой попытки. На анализ в любом случае будет потрачено время, только при итерационном методе тратится время еще и на переделки. Я не говорю, что не надо пробовать. Я говорю, что грамотный аналитик способен предсказать результат очень большого количества попыток. А грамотный энтерпрайз архитектор способен построить систему так, и в первую очередь я про бизнес-процесс, что бы по результатам вывода в продуктив первой же версии фичи потребовались лишь незначительные исправления и доработки логики. В большинстве случаев это в итоге получится быстрее и дешевле. В большинстве случаев итерационный метод скатывается к бессистемному тыканию пальцем в небо, так же как в вашем примере Waterfall скатывается к бюрократии.
Что же касается процесса и единого собственника, то такая орг. структура фактически сводит на нет наличие этого собственника системы. Комментарий чуть выше это очень наглядно показывает — кто то из заказчиков пришел к Вам, а не к собственнику системы. Это делает фигуру собственника совершенно номинальной. По хорошему, должно быть совсем наоборот, это собственник должен бегать за пользователями и выяснять их потребности. Находиться с ними в контакте.
Изначально проработать способ достижения достаточно подробно можно только для тех областей, для которых уже все факторы известны, измерены и их влияние можно учесть. Грубо говоря, когда проектируется здание — проектировщик опирается на наработки кучи НИИ — геологии, материаловедения и т.д. А когда работает аналитик — в ряде случаев он может только предполагать. И подтверждение можно получить только в результате НИОКР (R&D), вот только для разработки софта НИОКР стоит не сильно дешевле обычного процесса разработки. И результат зачастую зависит только от того, как задачу поймет разработчик (да-да, одну и ту же самую задачу можно решить по разному). А расписать задачу до однозначности — требует столько же, а иногда и больше, времени сколько требуется на реализацию разработчику.
Собственно вся индустрия стартапов построена на том факте, что гигантские корпорации с многотысячными штатами, многомиллиардными бюджетами, зрелыми процессами, аналитиками, энтерпрайз архитекторами, «отделами разработки» и «отделами эксплуатации» не в состоянии воспроизвести путь маленькой быстро адаптирующейся команды стартапа за разумное время и с приемлемым бюджетом. Просто потому, что маленькая команда может потыкать пальцем в небо очень быстро и в результате таки нащупать там новый рынок или источник дохода.
У большой системы в принципе не может быть единого собственника. В том бизнес-юните или департаменте или направлении (ага, тайтлы менялись), в котором работал я — работало еще более сотни одних только разработчиков. О некоторых частях системы я имел весьма теоретическое понятие — просто потому, что там изменения происходили чаще, чем я заглядывал в эту часть системы. Или смотришь — идут данные от чего-то с забубенной аббревиатурой, вроде один продукт, глянул на доки — а там еще одна система состоящая из кучи продуктов с не менее забубенными аббревиатурами. (Продуктом мы называли минимальную развертываемую функциональность, чаще всего один, иногда несколько системных пакетов. По факту один продукт мог разворачиваться на кластере в несколько десятков апп хостов и требовать под себя пару-тройку дб кластеров.) К одному человеку все сводилось уже довольно далеко от разработки. И этот человек, условно, собственник — не бегает за пользователями — у него для этого есть отдел продаж. И куча менеджеров для внутренних коммуникаций.
А менеджер по работе с клиентами вообще-то тоже один из непрямых (через несколько слоев линейных менеджеров) подчиненных условного собственника. И ко мне он пришел не напрямую, а получив контакт от моего менеджера. Просто я был одним из знающих свой кусочек системы, берущих на себя ответственность за фичу и умеющих полный цикл — от сбора требований до вывода на продакшн.
Собственно вся индустрия стартапов построена на том факте, что гигантские корпорации с многотысячными штатами, многомиллиардными бюджетами, зрелыми процессами, аналитиками, энтерпрайз архитекторами, «отделами разработки» и «отделами эксплуатации» не в состоянии воспроизвести путь маленькой быстро адаптирующейся команды стартапа за разумное время и с приемлемым бюджетом. Просто потому, что маленькая команда может потыкать пальцем в небо очень быстро и в результате таки нащупать там новый рынок или источник дохода.
У большой системы в принципе не может быть единого собственника. В том бизнес-юните или департаменте или направлении (ага, тайтлы менялись), в котором работал я — работало еще более сотни одних только разработчиков. О некоторых частях системы я имел весьма теоретическое понятие — просто потому, что там изменения происходили чаще, чем я заглядывал в эту часть системы. Или смотришь — идут данные от чего-то с забубенной аббревиатурой, вроде один продукт, глянул на доки — а там еще одна система состоящая из кучи продуктов с не менее забубенными аббревиатурами. (Продуктом мы называли минимальную развертываемую функциональность, чаще всего один, иногда несколько системных пакетов. По факту один продукт мог разворачиваться на кластере в несколько десятков апп хостов и требовать под себя пару-тройку дб кластеров.) К одному человеку все сводилось уже довольно далеко от разработки. И этот человек, условно, собственник — не бегает за пользователями — у него для этого есть отдел продаж. И куча менеджеров для внутренних коммуникаций.
А менеджер по работе с клиентами вообще-то тоже один из непрямых (через несколько слоев линейных менеджеров) подчиненных условного собственника. И ко мне он пришел не напрямую, а получив контакт от моего менеджера. Просто я был одним из знающих свой кусочек системы, берущих на себя ответственность за фичу и умеющих полный цикл — от сбора требований до вывода на продакшн.
;)
яркий пример того, почему devops не про ит, а про бизнес.
с точки зрения ИТ, ситуация выше — идеальная. все регламентировано, все зафиксировано, все риски предусмотрены, ответственность на каждом шаге известна, прозрачные связи с сопутствующими процессами (capacity, event, etc mngt).
одна только проблема — «недалекий» бизнес хочет быстрее и дешевле.
яркий пример того, почему devops не про ит, а про бизнес.
с точки зрения ИТ, ситуация выше — идеальная. все регламентировано, все зафиксировано, все риски предусмотрены, ответственность на каждом шаге известна, прозрачные связи с сопутствующими процессами (capacity, event, etc mngt).
одна только проблема — «недалекий» бизнес хочет быстрее и дешевле.
На самом деле немножко по другому:
Любой процес он не про скорость, любой процесс он про предсказуемость. И чем выше требуется предсказуемость (особенно с учетом, что могли ошибиться в вводных данных) тем выше ответственность на каждом участке — тем более забюрократизирован будет процесс, и тем выше стоимость.
А в IT эта проблема всплывает, так как ошибка из-за незрелого процесса не вносит диких затрат на этапе внедрения. Потому что можно «тяп-ляп и в продакшен» а если чего то DevOps поможет быстренько доставить фикс до заказчика.
И вот бизнес сидит и управляет рисками… толи по-быстрому выкатится и начать грести бабло лопатой пока конкуренты не очухались. Толи waterfall-ить по-черному чтобы снизить потери если что-то пойдет не так.
И да в эпоху облаков и тонких клиентов это таки работает впрочем не везде и DevOps тут ни разу нипричем.
Как пример: компания разрабатывающая прошивки для автомобильных «головных устройств» у которых если что прошивку по воздуху не обновить — и обновление это отзывная компания по всему миру. Там как раз и надо «capacity, event, etc mngt.»
Любой процес он не про скорость, любой процесс он про предсказуемость. И чем выше требуется предсказуемость (особенно с учетом, что могли ошибиться в вводных данных) тем выше ответственность на каждом участке — тем более забюрократизирован будет процесс, и тем выше стоимость.
А в IT эта проблема всплывает, так как ошибка из-за незрелого процесса не вносит диких затрат на этапе внедрения. Потому что можно «тяп-ляп и в продакшен» а если чего то DevOps поможет быстренько доставить фикс до заказчика.
И вот бизнес сидит и управляет рисками… толи по-быстрому выкатится и начать грести бабло лопатой пока конкуренты не очухались. Толи waterfall-ить по-черному чтобы снизить потери если что-то пойдет не так.
И да в эпоху облаков и тонких клиентов это таки работает впрочем не везде и DevOps тут ни разу нипричем.
Как пример: компания разрабатывающая прошивки для автомобильных «головных устройств» у которых если что прошивку по воздуху не обновить — и обновление это отзывная компания по всему миру. Там как раз и надо «capacity, event, etc mngt.»
Со всем согласен, кроме
DevOps не про быструю доставку. DevOps про то, что перед бизнесом за работу одного продукта/сервиса в части ИТ несет ответственность один человек, а если конкретизировать, то за:
— если нужна доступность, то за доступность
— если нужен TTM, то за TTM
— если нужна безопасность, то за безопасность
— и т.д.
Какие при этом используются инструменты, в общем то все равно. Т.е. у вас может не быть быстрой доставки, потому что бизнесу это не нужно, но вполне может быть взрослый DevOps.
DevOps поможет быстренько доставить фикс до заказчика.
DevOps не про быструю доставку. DevOps про то, что перед бизнесом за работу одного продукта/сервиса в части ИТ несет ответственность один человек, а если конкретизировать, то за:
— если нужна доступность, то за доступность
— если нужен TTM, то за TTM
— если нужна безопасность, то за безопасность
— и т.д.
Какие при этом используются инструменты, в общем то все равно. Т.е. у вас может не быть быстрой доставки, потому что бизнесу это не нужно, но вполне может быть взрослый DevOps.
Ну я бы сказал, что даже не перед бизнесом, а перед другими опсами. Вообще я более полутора лет выпрашивал человека от опсов в команду с двумя целями — представлять опсов при разработке каждой фичи в команде и представлять команду при общении с опсами.
Далеко не всегда при разработке учитывается точка зрения опсов (ну или то, что разработчик считает точкой зрения опсов). Особенно без напоминания. И внести изменения в написанную, задокументированную и протестированную фичу через пару месяцев после завершения работы над ней — гораздо сложнее чем поменять ее сразу после написания.
И команда не всегда готова принять запрос на фичу — что при ватерфолле, что при скраме. При ватерфолле команда открыта к запросам только на этапе до фиксирования скоупа. А в периоды релиза — вообще лучше не трогать. При скраме — только в моменты подготовки к планированию. В беклог то запрос добавят в любой момент, но не факт, что запрос будет понятен, а человек умеющий задавать правильные вопросы — будет свободен.
Далеко не всегда при разработке учитывается точка зрения опсов (ну или то, что разработчик считает точкой зрения опсов). Особенно без напоминания. И внести изменения в написанную, задокументированную и протестированную фичу через пару месяцев после завершения работы над ней — гораздо сложнее чем поменять ее сразу после написания.
И команда не всегда готова принять запрос на фичу — что при ватерфолле, что при скраме. При ватерфолле команда открыта к запросам только на этапе до фиксирования скоупа. А в периоды релиза — вообще лучше не трогать. При скраме — только в моменты подготовки к планированию. В беклог то запрос добавят в любой момент, но не факт, что запрос будет понятен, а человек умеющий задавать правильные вопросы — будет свободен.
Ну вот мы с Вами ровно об одном и том же на самом деле. Просто называем это разными словами немного.
Проблема как раз в том, что управления рисками нет. Есть процесс максимально снижающий риски и его начинают применять повсюду. Даже когда он никак не влияет на риски — все равно используют его. И тратить полтора месяца на деплоймент мелкого изменения веб юая доступного только внутренней команде (спонсор проекта имел достаточный вес чтобы запустить процесс релиза с одной единственной фичей) — это весьма неэкономично. Но происходит — потому что опсы предпочитают перестаховаться в связи с незнанием продукта и команды, невозможностью оценить риски из-за своего незнания.
На самом деле не из-за незнания, а из-за нежелания сотрудничать и отсутствие общего руководства, понимающего что происходит и способного настучать по шапке. Того самого собственника системы.
P.S. я своими глазами видел не раз, как мелкое изменение внутреннего интерфейса рушит верстку внешнего. Например из-за неожиданно общих библиотек. Но это скорее вопрос уже к тестированию:-)
P.S. я своими глазами видел не раз, как мелкое изменение внутреннего интерфейса рушит верстку внешнего. Например из-за неожиданно общих библиотек. Но это скорее вопрос уже к тестированию:-)
Sign up to leave a comment.
Процессы разработки глазами эксплуатации. Взгляд с другой стороны баррикад