Портал №1 по управлению цифровыми
и информационными технологиями

Инженерное мышление в ИТ

IT Skeptic в перерыве между твитами об инаугурации Трампа нашел время поделиться очередной мудростью. Про инженерное мышление в ИТ – распространенное и не сдающее свои позиции, несмотря на 20 лет Agile и бесчисленные тексты про DevOps, заблуждение о том, что ИТ-системы нужно строить так же, как мосты.

«Строительства моста подразумевает, что:

  • Мы предельно точно определим наши требования до сантиметра
  • Затем начертим подробнейшие чертежи с точностью до каждого винтика
  • Затем построим мост в соответствии с чертежами
  • Затем проведем контрольные замеры, подтвердив, что построенный мост полностью соответствует требованиям

Эта песня всем знакома – называется «водопад» (каскадная модель). И сейчас кажется невероятным, что такой путь считался рациональным для построения чего-то настолько сложного, как ИТ-система.

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

Конечно, как многие из вас знают, Agile учитывает эту особенность и представляет разработку ПО как итеративный процесс непрерывного исследования. DevOps расширяет границы применения Agile на весь жизненный цикл систем и услуг, попутно предлагая соответствующий инструментарий. Но инженерное мышление все еще живет в умах многих в мире ИТ, и особенно тяжелые случаи можно видеть как правило в области программного и проектного управления, стратегического планирования. Сохраняте бдительность,»- наставляет Роб.

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

Какие мосты возводили в ИТ вы? 

Напоминаем вам о том, что сразу две книги Роба Ингланда до конца февраля можно приобрести со скидкой 30%.

«Трансформация ИТ в традиционных компаниях»
Учебный курс о кратном ускорении за счёт новой организации работы

Комментариев: 6

  • Сергей

    По моему скромному опыту – жадные, недоверчивые, возможно старые, в основном, гос-заказчики, не признают ничего кроме жестких проектов – разработка по каскадной модели – здесь объясняется жесткими планами и отчётностями (жаг влево-вправо для них – это попытка коррупции). Более продвинутые готовы работать как по проектным моделям-каскадной разработке, так и по гибким методологиям. Здесь объясняется просто – проект – это отдельный договор с какой-то ценой. Разработки улучшений идут или скопом (в рамках договора пост-фактум всё аггрегируется в один документ) или в рамках тех поддержки (не в классическом понимании, а именно как доп.разработки по запросам). С первым типом заказчиков – всё ясно, опыт описывать не интересно. А вот со вторыми так: обычно внедряется стандартное решение с небольшими доработками (предварительно может быть пилот), затем, определённое время выполняют мелкие доработки в рамках тех поддержки – т.к. заказчик закупает пул часов (они могут по всякому расходоваться или сгорать). Через определённое время зреет крупная модификация – всё собирается и описывается в рамках тех.поддержки, а уже сама деятельность стартует в виде проекта(отдельного догора). После идёт развитие.

    Вот так и получается сочетание Waterfall и Agile в рамках одного заказчика

  • Андрей другой

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

    • Илья Рунов

      Андрей, где найти упоминание, что Agile отрицает нормальную документацию, которая описывает "что надо сделать"? Здесь http://agilemanifesto.org/iso/ru/manifesto.html мне найти не удалось. Я текст прочел так, что при выборе между работающим продуктом с неисчерпывающей документацией и неработающим продуктом с исчерпывающей документацией следует выбирать первый вариант. Может быть я не так понял авторов манифеста.

      • Рискую начать очередной холивар (который, сразу хочу оговориться – не поддержу), но считаю важным заметить: то, что сейчас буквально на наших глазах делают Tesla и SpaceX настолько близко к Agile (на мой субъективный взгляд), что космос в пример "сильно-много подумали, затем удачно запустили" приводить как-то не уместно.

  • Илья Рунов

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

    Было бы здорово обнаружить в рядах читателей поста человека, причастного к разработке ПО такого контроллера. Понятно, что аппаратную часть не изменить. Но предусмотрена ли в такой системе хотя бы возможность обновления ПО?

    • Некоторое время назад я читал издание о космонавтике. "Российский космос", наверное, не помню уже. Там публиковали журнал, который вели наши космонавты на МКС. Очень любопытно и поучительно.

      Могу сказать одно: большинство из тех, кто рассуждает о космосе, понятия не имеет как там весело всё устроено 🙂

      И с софтом, и с железом, и с доставкой до станции, и с косяками разработчиков.

      Один вопрос у меня остался: как оно вообще летает?


Добавить комментарий для Олег СкрынникОтменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM