• Управление -> Что делать с чужими долгами?

Пример применения "дерева текущей реальности" ("дерева проблем") для анализа ситуации

Схема строится сверху вниз:

• вверху перечисляем проблемы, которые нас беспокоят;
• по каждому блоку с проблемой задаём вопрос "А почему так происходит?", ответ на этот вопрос располагаем ниже, отведя стрелку вверх к блоку с проблемой;
• затем задаём вопрос уже к этим ответам, и так пока не дойдём до "корней".

Весьма жизненный пример:

RACI-матрица — распределение ответственности в процессах

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

• Responsible – ответственный за непосредственное исполнение задачи;
• Accountable (Approver) – отвечающий за корректность и полное выполнение задачи, подтверждает выполнение задачи;
• Consulted – тот (те), с кем проводятся консультации относительно задачи, чьё мнение должно учитываться;
• Informed – информируемый о выполнении задачи;

Пример:

Процесс processname	IT-отдел	Хостинг -провайдер	Бизнес	Бухгалтерия	Сервис -менеджер	Разработчики
Разработка требований	R		C	C	A	I
Дизайн	A		CI	I	R	C
Разработка	A	I	I	I	C	R
Внедрение	A	R	C	I	C	C
Сопровождение	A	R	I		I	C

Ниже перечислено несколько важных факторов, влияющих на успех внедрения ИТ-Продукта внутри организации (т.е. не его продажи, а для своих собственных бизнес-процессов).
Для архитектора/аналитика/разработчика как технаря это может показаться странным (и выбешивающим), но довольно весомая их часть носит социальный и экономический характер.

1. Наличие "политической крыши" в организации = заинтересованных в проекте лиц с реальными рычагами управления и прямого влияния на причастные стороны, с возможностью выделения ресурсов. Если кто сталкивался с т.н. внутрикорпоративными войнами — объяснять не надо.
2. Понятийный аппарат продукта (его объектной модели, архитектуры и спецификаций) должен пересекаться, а лучше — совпадать — с предметной областью, для которой предназначено решение. ИТ-специалист и бизнес-заказчик должны понимать друг-друга, "говорить" на одном языке об одних и тех же сущностях.
   См. концепцию DDD
3. У Продукта должна быть команда (не путать с подчинёнными), а не один-единственный идейный вдохновитель и разработчик (как бывает в небольших организациях).
   Причины:
   • bus factor
   • водиночку очень трудно и времязатратно переключаться с вопросов предметной области на область ИТ-решения. Может привести к выгоранию и забросу проекта.
   • одиночка обладает довольно "узким каналом" генерации идей по сравнению с коллективом.
   • Для Бизнеса связываться с одиночками (покупать у такого Продукт) это всегда высокий риск.
4. У ИТ-решения для Продука должна быть масштабируемая и НЕ переусложнённая архитектура. Звучит банально, однако в реальности мы встречаем очень всякое и даже разное...
5. Заказчик (юрлицо/физлицо) и отдельные ЛПР (лица, принимающие решения) склонны следовать (или имитировать следование) карго-культу.
   Если вы разрабатываете системообразующий Сервис/Продукт для крупного бизнеса, то использование популярных и хорошо зарекомендовавших (надёжность) себя платформ/технологий ("передовые компании X, Y, Z используют технологию A!") будет вызывать больше доверия к проекту со стороны Клиента/Пользователя/Заказчика.
   Серьёзно влияет на вероятность выделения ресурсов под ваш проект.
6. Уникальные фичи Продукта.
   То, чего нет ни у кого. Либо есть, но стоит дорого. Либо есть, но работает не так как нужно (медленно, с ошибками, нестабильно, потребляет много ресурсов, бесит пользователей).
7. Сложность и/или стоимость лицензирования используемых платформ/технологии. Например, решения от IBM, Oracle, SAP и т.п. это дорого (хотя их support может того стоить). Сейчас все смотрят в сторону opensource-решений.

Для IT-продуктов мы можем построить расширенную V-диаграмму:

На V-диаграмме видно сколько всего работ должно быть выполнено до старта нашего проекта.

• Слева — проектирование.
• Справа — действия по окончательной валидации нашего предмета поставки.

Если мы работаем по Agile, то фактически все эти этапы выполняются в рамках работ по каждой пользовательской истории (user story) . Если у нас более длинные итерации, то по этим фазам проходит сразу целая очередь или подсистема.
Соответственно, результаты предшествующего проектирования должны поступить нам на вход (причем, не всегда "самотёком"), а действия по валидации будут вызывать запросы на изменения, поддержку или дефекты, выявленные после поставки.

Более подробная развёртка по времени ЖЦ производства ИС в общем виде:

скачать схему в формате diagrams.net (бывший draw.io)

Этап реализации программного продукта (Процесс 10 из схемы выше) в общем виде выглядит так:

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

Выбирают Waterfall, если заказчик:

• идёт в относительно стандартный проект, который до этого уже делался;
• неплохо понимает, что хочет уже сейчас;
• не готов отдать существенную часть своего времени контролю и плотному общению с технарями;
• важно знать, сколько будет стоить разработка уже сейчас, и важно, чтобы эта была головная боль разработчика, как всунуть качество в ограниченный бюджет;
• важно знать, когда будет завершена разработка, и важно, чтобы подрядчик финансово отвечал за срыв сроков.

Сравнение Waterfall ("Водопад") и Agile ("Гибкие методологии")

RUP (Rational Unified Process) = методология разработки программного обеспечения, идейно развившая "водопадную" модель до т.н. "каскадной".
Была целенаправленно разработана для создания больших программных систем. Автор — компания Rational Software.

RUP использует итеративную инкрементальную модель разработки.
В конце каждой итерации (в идеале продолжающейся от 2 до 6 недель) проектная команда должна достичь запланированных на данную итерацию целей, создать или доработать проектные артефакты и получить промежуточную, но функциональную версию конечного продукта.
Итеративная разработка позволяет быстро реагировать на меняющиеся требования, обнаруживать и устранять риски на ранних стадиях проекта, а также эффективно контролировать качество создаваемого продукта.
Полный жизненный цикл разработки Продукта состоит из четырёх этапов, каждый из которых включает в себя одну или несколько итераций:

Методология RUP не ставит условий по количеству итераций и их распределению по фазам. Концепт фаз и итераций введен для снижения рисков, потребности в ресурсах, задания ритма реализации проекта и предоставления возможности внести требуемые изменения при разработке большой информационной системы.

Основная идея RUP — выдать уже в первых итерациях прототип будущей системы с порцией готовых к использованию / применению бизнес-сценариев.
Так как доставка части Результата проекта (инкремента) осуществляется в конце каждой итерации, это позволяет начать получать выгоду от использования промежуточных версий Результата и возвращать вложения в проект ещё в ходе его реализации.

Новации RUP

1. Бизнес-моделирование и связанные с ним Сценарии Использования (Use Case).
   Сперва разрабатывается бизнес-сценарий использования, где будущая система представляет собою "чёрный ящик", который удовлетворяет все потребности Пользователя/Бизнеса. На его основе разрабатываются системные сценарии использования, описывающие функции системы, которые будут поддерживать выполнение бизнес-сценария.
2. На основе выделенных системных сценариев использования системы принимаются архитектурные решения и выделяются компоненты, которые будут поддерживать бизнес-сценарии и решается будут ли они использоваться совместно для поддержки нескольких бизнес-сценариев или останутся заточенными под конкретный сценарий. (Объектно-ориентированное проектирование и программирование)
3. Наличие выделенных сценариев использования системы позволяет разделить их на первичные и вторичные. Вторичные основываются на результатах выполнения первичных сценариев, которые по большому счёту самодостаточны. Отсюда появляется возможность выделить итерации и разложить реализацию всех сценариев по ним.

Упрощённый концепт RUP:

Каждый бизнес-сценарий разворачивается в системные сценарии использования.
Каждый системный сценарий — в требования к интерфейсам, алгоритмам, данным и не функциональные (производительность, время доступности, скорость ответа...).
На основе выделенных требований определяется будущая архитектура системы и её функциональные модули (сервисные подсистемы).
Подсистемы разбиваются на компоненты.
Компоненты содержат исполняемый код.

Гибкая методология разработки (Agile software development) = серия подходов к разработке ПО, ориентированных на использование итеративной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля.

Гибкий итеративный подход Agile не включает практик, он определяет ценности и принципы, базируясь на т.н. "agile-манифесте":

• Люди и взаимодействие важнее процессов и инструментов
• Работающий продукт важнее исчерпывающей документации
• Сотрудничество с заказчиком важнее согласования условий контракта
• Готовность к изменениям важнее следования первоначальному плану

Подход нацелен на минимизацию рисков путём сведения разработки к серии коротких циклов (итераций), которые обычно длятся 2-3 недели.
Каждая итерация сама по себе выглядит как программный проект в миниатюре и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований, проектирование, программирование, тестирование и документирование.
Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта, подразумевается, что гибкий программный проект готов к выпуску в конце каждой итерации.
Подразумевается возможность заказчика вдруг и неожиданно в конце каждой итерации выставлять новые требования, часто противоречащие архитектуре уже созданного и поставляемого продукта. Такое иногда приводит к катастрофическим "авралам" с массовым рефакторингом и переделками практически на каждой очередной итерации. В итеративном подходе предполагается очень плотное участие заказчика в процессе, он буквально должен жить с командой разработки, а в случае срыва сроков делить с ней риски.

Вот схематическое изображение ЖЦ одного из самых распространённых методов гибкой работы, SCRUM:

Выбирают Agile, если:

• заказчик готов отдать 80%-100% своего времени проекту с полным погружением;
• заказчик обладает достаточной компетенцией и готов погружаться в разработку вместе с технарями;
• заказчик готов разделить риски за срыв сроков или за невысокое качество работы подрядчика;
• заказчик, как и разработчик, отлично понимают, что на данный момент нормально требования не собрать, потому что они еще не продуманы до конца, а работать начинать надо, потому что рынок, бизнес, и всё такое.
• разработчиками являются высококлассные специалисты, за плечами у которых десятки больших реализованных проектов, которые способны в голове за 20 минут набросать диаграмму классов небольшого модуля, тут же прикинуть процессы меняющие их состояния, предположить критические зависимости и т.д. В этом случае можно попытаться обходиться без чётких требований и стадии анализа как таковой

Типичные ошибки при адаптации Scrum

• Проектного менеджера хоть и окрестили Владельцем Продукта, однако он не получил необходимых полномочий и поэтому не вправе формировать видение продукта или менять приоритеты реализации.
  Как и раньше, он вынужден согласовывать каждый свой шаг с руководством, зажат в рамки требований по срокам и объёму работ.
  А значит, скорость принятия решений осталась прежней. Никакого ускорения или адаптации под меняющиеся условия.
• Проектную команду хоть и назвали Scrum-командой, но люди, включённые в неё, по-прежнему могут числиться каждый в своём отделе и подчиняются непосредственно своим линейным руководителям.
  Соответственно, каждый из участников команды прежде всего делает то, что ему поручит его линейный руководитель, а не Владелец Продукта. Как следствие, задачи по продукту будут всегда ниже по приоритету, а значит, скорость реализации продукта, под который "собрали" Scrum-команду, никак не повысится.
• Скорее всего, как и прежде, участники команды будут заняты и в других проектах.
  В то время как Scrum прямо оговаривает: участники команды должны быть выделены в Scrum-команду на 100 % своего рабочего времени, и заниматься только тем продуктом, которые ведет их Владелец Продукта.
  Если люди "поделены на проценты" между проектами/продуктами, то они будут переключаться между ними, что резко снизит как вовлечённость, так и эффективность работы над каждым конкретным Проектом/Продуктом.

Сравнение Waterfall и Agile

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

Основы современного Канбан:

1. Визуализировать поток поставки
2. Ограничивать WIP-лимиты
3. Измерять время выполнения задачи (Lead Time). Минимизировать его.
4. Сделать правила работы явными и известными для всех участников процесса
5. Помогать друг другу
6. Собирать статистику по времени выполнения (Lead Time) разного типа задач для прогнозирования последующих поставок

WIP-лимиты (Work In Progress, WIP) = лимит на количество единовременно находящихся в производстве рабочих элементов. Ограничение незавершённой работы.

Критерии готовности (Definition of Done, DoD) = чёткие и понятные всем критерии, по которым рабочий элемент может считаться готовым после отработки.

Время производства (Lead Time, LT) = время выполнения задачи с момента принятия обязательств до момента поставки.

Обязательство (Commitment) = чётко сформулированное негласное соглашение между заказчиком и сервисом о следующем:

• заказчик желает получить рабочий элемент и согласен принять его поставку;
• сервис готов обеспечить производство и выполнить поставку элемента заказчику;

Канбан-Доска (Board)

Каденции (встречи, митинги)

• Собрание по пополнению (1 раз в неделю).
  Проводится в целях перемещения элементов за точку принятия обязательств (помещения рабочих элементов в систему) и контроля подготовки вариантов рабочих элементов к дальнейшему выбору
• Ежедневная "летучка" (1 раз в день).
  Всё что нужно вместе со всеми посмотреть на доску и определить, что мешает каждой задаче справа налево перейти правее, и чему может помешать она.
• Собрание планирования поставки (с частотой поставки)
  Проводится в целях контроля и планирования поставок заказчикам — выбрать те задачи, которые являются более приоритетными на ближайшую поставку. Происходит также тогда, когда есть какие-то проблемы с поставкой или неопределенность

Роли в Канбане

Менеджер Запросов для Сервиса (Service Request Manager, SRM) несёт ответственность за изучение потребностей и ожидания заказчиков, содействие выбору и приоритизации рабочих элементов на Собраниях по Пополнению.
Другие названия для данной роли: Менеджер Продукта, Владелец Продукта, Менеджер Сервиса.

Менеджер Поставки для Сервиса (Service Delivery Manager, SDM) несёт ответственность за поток работы, в ходе которого выбранных рабочие элементы поставляются заказчикам, за обеспечение проведения Канбан-Митингов и Собрание Планирования Поставки.
Другие названия роли: Менеджер Потока, Менеджер Поставок и даже Мастер Потока.

Стоимость задержки (Cost of Delay)

1. Expedite --> несём потери уже сейчас.
   Делать поставку надо срочно.
2. Fixed date --> начнём нести потери с определённой даты.
   Начинать разработку надо достаточно рано, чтобы обеспечить своевременную поставку.
3. Regular / Standard --> стоимость задержки возрастает постепенно.
   Необходимо обеспечить разумные сроки ожидания поставки.
4. Intangible --> стоимость задержки может оказаться значительной, но в отдалённой перспективе.
   Важно, но не срочно. Планировать поставку когда удобно.

Накопительная диаграмма потока (CFD)