Технологичность архитектуры

SECR 2018
Андрей Степенко
траблшутер, Базальт

Этот доклад может быть интересен тем:

– кого волнуют вопросы выполнения обещаний заказчикам, а не подходы как скрыть, что часть продукта не доделана и часть багов не исправлена;

– кто сталкивается не низкой исполнительской дисциплиной дистанционных работников,

– кто собирается двигаться от заказной разработки к продуктовой или консалтингу.

Я рассматриваю устойчивость или технологичность архитектуры, которая в английском языке выражается manufacturability и означает, что ее можно повторять из проекта в проект. Т.е. делать по единому принципу.
Какой контекст учитывается? Существующая заказная и в значительной части продуктовая разработка полагается на большие куски готового и бесплатного кода. (Можно называть это платформами или технологиями.) Это приводит к тому, что сроки выполнения проектов для разных компаний конкурирующих на рынке могут очень сильно отличаться при наличии “библиотекарей”- экспертов кода. Конкуренция может выводить новые “элементы конструктора” готового решения в топ в течение года. Обычно это называют “скоростью обновления технологий”. В данном случае нужно уточнить, И сказать про скорость обновления технологического стека. А поскольку это ключевой процесс, то он должен быть связан с другими наиболее повторяющимися процессами компании.

Такая сложность вынуждает компании заказчиков передавать инфраструктуру и интеллектуальную собственность в компанию-исполнитель и заключать с ними другие договора, нежели ранее. Условия договоров ужесточают требования к готовности к поставке и перепаду мощности, а также другие взаимно противоречивые требования. Эти требования значительно повышают требования к производственной логистике компании-исполнителя.

Так, например существуют совершенно разные циклы кодинга и тестирования для фронэнда и бэкэнда, а проектный характер работы, который приводит к большим колебаниям количества багов вынуждает переходить с аджайла на канбан и обратно по заранее не запланированному расписанию. Вопрос аджайл или канбан или водопад остаются без критериев или подходов к их применению в плоскости «а давайте еще раз попробуем».
ИТ проекты наследуют 2 проблемы известных типов архитектур A и V классификации производственных систем VATI. Упрощенно один тип производственной архитектуры – это сборочные производства, а другой наоборот когда из одного изделия происходит ветвление процесса. Можно назвать это типовой структурой работ или структурой информационного потока.

C одной стороны ограничение всегда будет в начале проекта в разработке архитектуры проекта. С другой стороны, оно всегда будет в конце проекта, когда нужно делать “сборку задач” и проверять соответствие изначальному замыслу.

Согласно теории ограничений Голдрата тип ограничений задает типовые механики работы с ними. А именно координации работ в случае факапов. К сожалению, для ИТ отрасли (и продуктовой и заказной) производственная логистика и прохождение информационных потоков задает сразу 2 типа ограничения. Это производит к гарантированной разбалансировке системы управления. В материальных производствах обычно можно выстроить архитектуру, чтобы был один тип ограничений. (Именно выстроить а не “найти” ограничение.) Поэтому в логике аджайла и канбана мы никогда не найдем решения для интерактивных ограничений. А в логике ТОС и управления качеством она есть.

В докладе предлагается рейтинг, устраняющий конфликт между этими двумя ограничениями. Как правило в ИТ проектах главные люди участвуют и в запуске проекта и в его приемке. Поэтому перегруз этих людей практически гарантирован при нестабильном качестве разработки и непредсказуемых сроках, когда нужно осуществлять контроль или запуск проектов.

Предлагаемые архитектурные принципы учитывают расписание этих “наиболее загруженных ресурсов”. Оценку их участия в разных активностях. Типизация этих активностей и прозрачную систему адаптации и развития компетенций, а также масштабирования компании.

Transcript

1. Технологичность архитектуры или онтология ИТ компании Андрей Степенко andrey@syntez.pro Software Engineering Conference Russia 2018 October 12-13 Moscow
2. Цель доклада 1. Показать новую онтологию разработки программных продуктов 2. Это про архитектуру процессов компании 3. Это про типовую архитектуру процессов управления 4. Это про новое разделение умственного труда
3. В чем новизна? - Синхронизация 1. Разработка – черт ногу сломит. Все что не делаем не получается лучше. 2. Обучение и оценка – все что считаем - не то 3. Рекрутинг (кастинг) – Люди хотят обучния но оно не врастает в разработку
4. Мой опыт 20 лет делаю проекты изменений. ИТ с 2008 года Последние проекты Касперский, Неткрекер и Кастис. Сертифицированный в Goldratt School внедренец ТОС. Конструктор ЭВМ из МИЭТа. Люблю Голдрата и Деминга. Помню что такое: • Тоtal Quality Management и контрольные карты пока не было ИСО. • экстремальное программирование пока не было оджайла. • фидо пока не было "телеграмма« • Пефркарты, дорогое машинное время и люди с «молоточками» Работал финансовым директором и носил деньги в кирпичах. 20 лет занимаюсь цигун. Есть сообщество по ГТД в фейсбуке и куча материалов по ТОС. Научный интерес - информационные ограничения
5. Атака клонов (модных технологий) В Галактическом Сенате смятение. Несколько тысяч групп разработчиков заявило о намерении выйти из проектов аджайл трансформаций. Это сепаратистское движение, возглавляемое таинственным графом Именаусом, заявившим что качество аджайл коучей драматически упало, мешает немногочисленным рыцарям Джедаев попытки сохранить понимание и что вообще происходит в разработке и как его можно измерять. Сенатор Гипофиз, бывший король мыстетоплива, возвращается в Галактический Сенат, чтобы участвовать в голосовании по спорному вопросу создания Экстремальных ИТ полков программистов-криптоанархистов в помощь оставшимся Джедаям. .
6. Тезисы 1. R&D - это стандартизация компетенций (врачи, атисты, спортсмены, военные), а не стандартизация артефактов (результатов) или процессов 2. Больше количество (тысячи активностей) вынуждает фокусироваться управлении архитектурой и интерфейсами, а не отдельными задачами 3. Сборка софта из готовых кусков ведет кого-то к консалтингу, а кого-то… 4. Подстраховку из оценки сроков надо вычищать 5. Ключевое ограничение – экспертиза компании
7. Тезисы 2 1. Знания - это когда несколько человек понимают и дополняют друг друга 2. Ограниченная компетенция начинает и заканчивает продукт 3. Рост компетенций зависит от потока задач и обратной связи (оценки) 4. Можно неограниченно увеличивать мощность разработки 5. Можно увеличивать способность архитекторов видеть больше продукта 6. Точность учета времени не важна, важны приоритеты
8. Тезис юмора Пришло время сказать решительное нет упрощению ИТ разработки до роли программистов. Они-де умные. Сами со всем разберутся по аджайлу, а мы им деньги дадим. Главное набрать умных программистов. Оказывается, что давать денег порочная практика. Нужно разбираться в деталях. Они хххх (редиски) уходят не вовремя с проектов. И еще много чего. Говорят, что в гетерогенных средах есть такая штука как СЛОЖНОСТЬ. Вот мы и разберемся с тем, как ее упростить по самое не балуйся. В помощь 14 пунктов Деминга и 10 смертельных болезней. Даешь канбан! И дажайл! И ещё много технологий хороших и разных к месту и вовремя. (Играет музыка из звездных войн)
9. Проблемы, которые учтены в решении 1. Падение общей экспертизы и неравномерность ее роста 2. Конфиденциальность и передача интеллектуальной собственности 3. Сборка софта из готовых кусков (стек-технологий) 4. Уходят главные люди - некем заменить 5. Балансирование мощности
10. Цели, которые мы достигаем 1. Гибкость мощности (масштабирование) 2. Понимание о чем говорить на совещаниях (LL, scrum). 3. Возможность гибкой перестройки «системы разделения труда» и перераспределения полномочий в пределах одной СРТ при выбытии или появлении новых бойцов. 4. Скорость роста компетенций и синхронизация с системой обучения
11. Что надо (скока стоит)? • Начать считать бюджет времени главных специалистов • Выделять статьи бюджета времени (менять) • Синхронизировать другие активности • Аджайл трасформайшн коуч 
12. Необходимая визуализация • Что такое ограничение по мощности рабочего центра? • Что такое разделение труда? • Как оценить нагрузку, если мы кроссфункциональны? • Другие нетрадиционные специфики
13. Зачем нужна системная прозрачность? • Чтобы было меньше согласований на силе крика • Чтобы все знали какой ресурс ограниченный и как его можно-нужно беречь • Чтобы можно было вежливо синхронизировать «бизнес» и производство • Чтобы появилась уверенность внутренних закономерностей и возможность строить планы • Чтобы можно было «давать зуб» заказчику
14. Типичные возражения • Ну не, мы сами изнутри найдем «коуча» • Ну не, мы не можем тренировать, будем брать готовых • Тайм-шиты это шит и фу • Наши руководители не будут заполнять трекеры • Разработка как и научный труд не может быть измерена. Вообще! В принципе! Никогда!
15. 5 фокусирующих шагов ТОС • Шаг 1 – Определите ограничения системы • Шаг 2 – Максимально используйте ограничение • Шаг 3 – Согласуйте все остальное с принятым решением • Шаг 4 – Увеличьте пропускную способность ограничения • Шаг 5 – Если на предыдущем шаге ограничение было устранено переходите к шагу 1. Но не позволяйте ИНЕРЦИИ стать новым ограничением
16. Что надо (скока стоит)? • Начать считать бюджет времени главных специалистов • Выделять статьи бюджета времени (менять) • Синхронизировать другие активности • Аджайл трасформайшн коуч 
17. А B Ограничение мощности D Ресурс, мин Потребность, мин C Ограничение
18. Ограничение наглядно: задания Ресурс, мин Потребность, мин
19. Кроссфункционал позадачно Ресурс, часов Projects General Area 1 Area 2 Х АдминХ
20. Бизнкс архитектура Профиль потребности РЦ в день/неделя/проект Обучегние user Ресурс Тестирование Обучение новичков Архитектура пр Разбиение на задачи Триаж Дизайн Билд Рекрутинг Мод.Тестипрование Неизвестная шняга Интеграционное тестир-е JUN1 JUN2 Design Senior1 Mid1 MID2 Mid3 Test1 Test2 Jun1 Jun2 Jun3 Jun4 Mid1 Mid1 xxxxx Test 9 BE TL FE TL 6 9 12 15 3
21. Общая нагрузка
22. А еще есть контрольные карты • Модель Кано • Кривая потерь Тагути • 14 пунктов качества • 10 смертельных болезней • Система глубинных знаний • Цепная реакция • Организация как система
23. Классификация VATI V A I T
24. Знаете, что такое виртуальный барабан? V -тип
25. А какие проблемы у ресурса А-вершины? A - тип
26. А что такое интерактивное огранчеие? A - тип V -тип +
27. Принцип конвейера Буфер проекта Проект A Проект B Буфер проекта
28. Принцип конвейера Наибольшая загрузка
29. Принцип конвейера Проект A Проект B
30. Принцип конвейера Проект A Проект B
31. Принцип конвейера Буфер проекта Проект A Проект B Буфер проекта
32. Кто главный в разделении труда • Кто задачет ритм? • Могут ли разные ресурсы задавать ритм в разное время? • Должны ли и что это для управления? • Если разные то какие? • Есть ритма нет, то чем мы управляем? • Если ничем, то как интегрировать части проекта?
33. Организация как система (Деминг)
34. ИТ Организация как система Разработка и модификация R&D Исследование рынка customer development Стек технологий Области жкспертизы Архитектура Производство Тест группы А В С D Контроль компетенций, жизненного цикла, ролей, 3-Σ Высокие нагрузки Hi Load
35. ИТ Организация как система - производство Архитектура Задания Игтеграция Модули Ядро Скрвисы Тестирование А-тип V-тип Задания Задания Задания Задания Задания Задания Тестирование Тестирование Тестирование Тестирование Тестирование Тестирование Тестирование Тестирование
36. ИТ Организация как система - производство А-тип V-тип
38. Цепная реакция Степенко Улучшайте качество вводных (БА) Начнете продавать экспертизу вместо времени и рейтов Останетесь в деле Повысится производительность «архитекторов» За счет меньшего качества переделок и возвратов на предыдущие стадии вы сможете эффективнее использовать своих «архитекторов» Сохраните и умножите количество вменяемых команд готовых с вами работать дольше чем с конкурентами
39. Что надо (скока стоит)? • Начать считать бюджет времени главных специалистов • Выделять статьи бюджета времени (менять) • Синхронизировать другие активности • Аджайл трасформайшн коуч 
40. Цена трансформации • Деминг: «Если вы не готовы прихать сами, то никого не присылайте» • Голдрат: «Помочь компании невозможно в двух случаях. Первый когда ее товары никому не нужны. Второй, когда руководство не хочет меняться.» «Лучшие проекты бывают после того, как заказчик уже обжегся на чьем-то конасалтинге и теперь задумывается кто консультант и какова его роль» • «Чем сложнее представляется проблема, тем проще должно быть ее разрешение»
41. Как измерять то, что измерять нельзя? • Качественные критерии возможны • Управление на основе качества, это управление на основе качественных критериев • Стандартизация качества провалилась • 20 лет – 50% рынка автопрома. Автопром –локомотив индустриальной экономики • Как присваивают очередные звания в армии? Сколько учатся врачи, чтобы получить доступ к телу? Как проводится отбор артистов перед фильмом?
42. Contact Me • Name: Andrey Stepenko • Email: andrey@syntez.pro • Phone: +79265288300 • Facebook/twitter/telegram: art1step • GTD2.0