АйболИТ. Болезни ИТ проектов. Часть #2. УкСУС
Пост обновлен 19 мая 2020 г.
Вы не можете за 5 минут найти детальное описание любого требования, которое было реализовано в системе вашей командой?
Вы не можете за 5 минут разобраться во взаимосвязи требований между собой?
Ваш проект превышает объем 4000 часов?
Файлы с ФТ/ТЗ не проходят по лимитам файервола заказчика?
Требования к системе описаны в ворде?
Если вы набрали больше 3 "Да" - поздравляю. У вас - УкСУС.
Привет, дорогой друг. Сегодня мы поговорим о болезнях ИТ проектов. А именно - о таких болезнях, как УкСУС (lat. Устаревшая система управления содержанием). Разберемся, что к чему, как лечить и кто в зоне риска.
УкСУС. Устаревшая система управления содержанием
Болезнь описана в сообществе сравнительно недавно. В общем смысле, болезнью и не является. Скорее, отклонение от нормы, которое ранее отклонением не считалось. Но приводит к системному кризису организма проекта.
Подобное отношение к норме в истории уже происходило:
В 19 веке чернокожих людей не считали равными белокожим. Сегодня такое отношение не считается нормой и подвергается общественному остракизму
До 2019 года считалось, что невозможно управлять страной через телевизор. Сегодня же это норма в менеджменте для всех стран земного шара
Примерно так же до недавнего времени считалось нормой управлять содержанием сложных систем с помощью электронных документов.
Однако сегодня психологи от АйТи признают, что подобный паттерн поведения на проектах объеме более 4000 часов приводит к системной депрессии, кризису и нервному срыву проекта.
Ранее подобные проблемы считались нормой и принимались в обществе как данность. Но в связи с прогрессом ИТ-медицины, информация о возможности излечения подобного недуга и связанных с ним проблем, распространилась по миру и докатилась до России и до самых ее отдаленных углоков. Потому, даже неопытные пациенты спустя месяц наблюдения симптомов с помощью вакцины гугления приходят к ответам на самые сокровенные вопросы.
Возбудители болезни
Имеет не инфекционную природу. Но психологическую.
Если кратко: реализация информационной системы, как правило, лежит на пересечении процессной и функциональной модели. Требования к системе как правило находятся на персечении двух этих моделей. С одной стороны, для поддежания архитектурной целостности системы, требуется сохранить целостность функциональной модели. Это значит, что требования должны быть правильно отражены в функциональной модели системы.
С другой стороны, смысл реализации любой системы - нанести пользу бизнесу, а ингода и бизнес-пользователям. А значит, проверка работоспособности системы производится на основании бизнес-кейсов, которые коррелируют с процессной моделью системы.
Отсюда - проекция этих двух моделей друг на друга порождает высокую сложность поддержки и обновления содержания системы. Добавим сюда ролевую модель, управление разработкой, сервис-деск и управление сроками реализации.
Как следствие, подобные противоречивые импульсы порождают кризис личности и приводят к непоправимым изменениям в психике менеджмента проекта.
Народные методы лечения
Как правило, столкнувшиеся с данной проблемой пациенты практикуют эскапизм - уход от проблемы в угоду четко указанным в договоре пунктам. Что иногда приводит к финансому результату. Но не ведет к повышению уровня счастья в мировом океане, а также вызывает хроническую аллергию на продукт и команду со стороны бизнес-пользователей. Сюда же относится метод лечения путем игнорирования проблем на проекте. Как правило, завершается изгнанием менеджера или команды целиком.
Второй способ борьбы с проблемой - завалить проект людьми. Эта концепция проистекает из гипотезы, что 100 человек могут решить организационную проблему, которую не решили 20. Как правило, такое лечение прерывается в связи с окончанием финансирования.
Особенности лечения
Для снижения рисков провала проекта, необходимо наладить управление содержанием внедряемой системы. Команды, которые принимают данный риск, как правило, сталкиваются с описанными выше симптомами: срыв сроков, бедное содержание, негатив заказчика, невозможность передачи на поддержку, большое количество ошибок, бесконечный беклог от пользователей, бессонные ночи.
Нужно отметить, что лечение не тривиально и произвольно выбранный врач из поликлиники, не имеющий профильной подготовки, может даже навредить организму команды проекта.
Также важна дисциплина в лечении и соблюдение рекомендаций всеми участниками процедуры лечения.
Лечение имеет ряд побочных эффектов, потому не рекомендуется пациентам с нехарактерными симптомами - проекты низкой сложности, отсуствтие разработки, низкая зрелось команды.
Лечение
Для снятие первых симптомов пациенты как правило самостоятельно принимают пилюли тасктрекинга. Производителей довольно много - Jira, Trello, Redmine, самописные продукты на платформе 1С и множество иных.
При обращении к врачам, методы сильно разнятся. Известны следующие стратегии лечения:
1. Стратегия умных западных систем.
Пример - стек технологий Atlassian.
Внедряется collaboration-система Confluense, которая возволяет хранить содержание всего проекта (и портфеля также), проводить обсуждение и согласование.
Более формальное определение: Collaboration — система, отвечающая за электронное взаимодействие людей, но не формализованное, какworkflow, и не просто "архив", как EDMS.
Внедряется Jira, которая решает задачи
Таск-стрекера
Релиз-менеджмент
Планирование спринтов проекта
Описание тест-кейсов
Учет времени (актуально для платных команд внедрения)
Прочие задачи, определяемые ответственным за внедрение и использование данной системы
Более дешевый аналог "all-in-one" - отечественный Битрикс. Имеет более широкий функционал в части CRM, более бедный в части функций collaboration. И вообще, ориентирован больше на продажи и управление малым бизнесом.
2. Стратегия Все и 1Сразу
Стратегия, широко применяемая при автоматизации бек-офиса в странах СНГ. Заключается во внедрении Системы проектирования прикладных решений - решения, производимого и поддерживаемого фирмой 1С.
Класс системы можно определить именно как "Система управления содержанием". Для использования на проектах не-1С невозможна по причина возникновения острой аллергии на пыльцу с цветов желтого цвета.
Решает следующие задачи: управление процессной и функциональной моделью, управление поставками, ролевой модели. Отличительной особенностью является механизм контрольных точек, который позволяет формализовать процесс поставки ценности.
Характеризуется кандовостью итерфейса, отсустствие юзабилити как класса.
Побочный эффект - бюрократизация процесса внедрения.
На рынке имеются узкие специалисты по эксплуатации системы. Их место обитания находится здесь
Не является системой учета задач. Интеграция с любыми известными таск-трекерами отдается на откуп пациентам.
Про пилюли
Сегодня на рынке много пилюль, на коробке которых написано примерно одно и тоже. Управление командами, проектами и вообще. Помните, что курс лечение – дело ответственное и доверять его нельзя кому попало. Но и откладывать нельзя.
Про лекаря
Лекарь должен сочетать в себе ряд характеристик и навыков:
Иметь опыт работы в качестве аналитика, функционального архитектора
Иметь продуктовое видение и видение результата своей деятельности в частности
Понимать стоимость проведения изменений в компаниии
Иметь полномочия на директивные методы проведения изменений
Лекарь может иметь свои наработки и ноу-хау по стратегии лечения, стеку технологий,но они в той или иной мере будут коррелировать с описанными выше стратегиями. Как минимум, идейно.
Не болейте!
В следующий раз поговорим про такую болезнь, как АПОЖ.
Просмотров: 528Комментариев: 0