BoatmansHome: АвтоматизированныеСистемы/ДайтеТЗ ...

Boatmans Home Start | Каталог | Изменения | Комментарии | Пользователи | Регистрация | Вход  Пароль:  
Данные материалы созданы для размещения на сайте boatmanshome.ru. Во всех случаях, кроме явно оговоренных в теле материала, автор и обладатель исключительного права - Нужненко Сергей Александрович. Во всех случаях, кроме явно оговоренных в теле материала, для данных материалов разрешено размещение ссылок и цитирование, а так же воспроизведение в личных и учебных целях. Без согласования с правообладателем запрещается для данных материалов или любой части использование в коммерческих целях, а так же распространение, публичный показ, импорт с целью распространения, прокат, переработка, сообщение для всеобщего сведения.
 

Обзор жизненного цикла АС, например, по ГОСТ 34, казалось бы дает исчерпывающие ответы на все вопросы – где брать требования и что делать дальше. Но жизнь оказывается богаче, по этому сегодня мы постараемся рассмотреть все цепочки событий, приводящие нас в итоге к ИТ проекту. Самый главный вопрос – что делать, чтобы (а) на вход разработке все же попало нормальное техническое задание, (б) разработанное ПО внедрилось и (в) принесло ожидаемую отдачу.


Кроме этого рассмотрены вопросы:


Оглавление

Почему так сложно

Для того, чтобы информационные технологии заработали и принесли пользу, в одном месте в одно время должны встретиться как минимум


Все эти компоненты должны подходить друг к другу, иначе «фокус» не получится.


Первый вывод простой: при упрощенном подсчете степени бездефектности итогового результата мы можем перемножить бездефектность по каждой оси.
То есть, если в среднем по каждой оси мы имеем Х% дефектов и 100%-Х качественного объема, то в итоге мы получим (100-Х)^5 – это часть объема системы, который работает правильно.


В цифрах это выглядит так:


Результат пока не впечатляет, так что посмотрим, насколько нам надо поднимать качество:


Если вам кажется, что нет ничего сложного в том, чтобы обеспечить качество в две девятки на каждом классе компонентов АС, давайте навскидку посмотрим, от каких работ зависит это качество:


Это лишь предварительный список. На каждую строчку я могу рассказать не менее одной истории (а кое-где и по несколько), как именно из-за провала этой работы ничего не внедрилось.


Можно видеть, что добиться высокого качества выхода ИТ проекта достаточно сложно. Очень многие операции должны быть выполнены почти идеально, чтобы на выходе заработало хотя бы больше половины системы.
Для справки нормальный уровень дефектности программного кода – 10–20 багов на kSLOC. Если натянуть допущение, что степень дефектности в единицах функционального объема такая же, то мы попадаем на уровень бездефектности 99–98%.
Если допустить, что все остальные работы имеют те же уровни качества (допустим – где-то здесь предел длительной концентрации на больших объемах интеллектуальной работы), то наша упрощенная модель даст нам следующее: бездефектность результата =Y^26, где Y – бездефектность частных результатов.
В числах это вот так:


Между прочим норма ошибок в выпускном сочинении по русскому языку (на зачет) – не более 5 ошибок на 100 слов, то есть как раз бездефектность 95%. Можно видеть, что если нанять «студентов» делать систему, заработает лишь четверть.


Описанные механизмы накопления дефектов дают два следствия:


— Но постойте! — скажете вы — мы же можем не делать водопад и «женить» все эти компоненты не один раз за проект, а много, например, раз в две недели.


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


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


Проектирования


При построении ИТ системы используются несколько фаз проектирования, которые последовательно снижают уровень неопределенности:


Где-то здесь появляются бизнес-требования, или тактико-техническое задание, и/или цели автоматизации путем выжимки из проекта бизнес-процессов в сочетании с бизнес-моделью или проработкой проблемного поля


Где-то здесь появляются варианты концепции системы, оценка стоимости и сроков, решение делаем/не делаем+выделение бюджета
Тут же появляется ТЗ на АС или system scope&project charter/project plan путем небольшой перелицовки выигравшего варианта концепции


Где-то здесь появляется ТЗ на ПО путем небольшой перелицовки техпроекта


Таким образом почти все проектирование находится до решение едем/не едем и до выделения основного бюджета.


Сегодня все уже поняли, что без ТЗ чаще всего получается ХЗ. И именно его пытаются заказать, подразумевая ТЗ на ПО.
Но сколько проектных циклов должно быть выполнено до начала создания ТЗ на ПО – никто не знает и никого особо не волнует.
В такой ситуации проект обычно попадает в ловушку, так как неопределенность (разброс бюджета) при невыполненных предыдущих циклах проектирования составляет от порядка до нескольких порядков.
И единственно условно выигрышная стратегия для ИТ разработчиков — писать ТЗ так, чтобы система или влезла в имеющийся бюджет (если он есть) или писать ТЗ такого объема, за который готов заплатить заказчик.
И это часто далеко от того, что заказчику нужно на самом деле.


Обычно, если отжать воду, диалог складывается так:


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


Таким образом где-то на старте проекта надо найти себя среди проектных циклов – какие уже выполнены, какие еще нет.


Я привожу контрольный список для определения текущего положения нас с вами посреди жизненного цикла ИТ системы.


Фаза проектирования Ключевые вопросы Могут быть документы
Проектирование бизнес-системы или работа с проблемным полем и бизнес-планирование жизненного цикла актива Сколько мы заработаем/сэкономим и на чем (какие механизмы образования отдачи) бизнес-модель, бизнес-план
Проектирование (изменений) бизнес-процессов Какая работа находится в рамках автоматизации, как должны измениться ее KPI Описание бизнес-процессов (разной детализавции), текущие и целевые показатели процессов, Назначение АС и цели автоматизации
Проектирование информационной технологии концептуального уровня Как работа разеделена между машиной и человеком Функции системы (функциональный объем), потоки данных (сущности), логическая модель данных (сущности, связи), концепция системы, vision
Проектирование архитектуры системы концептуального уровня из каких компонентов состоит система, что из них покупное, что заказное, что арендуется, ключевые связи и интерфейсы, сколько это стоит и какие сроки построения системы ТЗ по ГОСТ 34.602, концепция системы, стоимость создания, project plan&system scope
Техническое проектирование
Детальная информационная технология потоки данных с точностью до атрибута, процесс использования системы с точностью до операции сценарии вариантов использования, описания алгоритмов, описания процессов с точностью до операции с указанием участия системы, логическая модель данных с точностью до атрибута, словарь данных
В этом месте уже можно начинать оформлять ТЗ на ПО 
Детальная архитектура системы, Детальная архитектура ПО  здесь наиболее интересно нам – внешний вид интерфейсов пользователя, форматы данных и протоколы обмена между компонентами, особенно в каналах интеграции, остальное уже можно переложить на программистов эскизы интерфейсов, описание интеграционных каналов, всякие архитектурные документы

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


Почему так важно получить решения всех проектных циклов: по тому, что иначе не «поженятся» все классы компонентов системы.

Как заставить заказчика платить за проектирование


Вот ряд идей на этот счет.


Как ни странно, правильно проектируя можно выделить бюжет на проектирование.


В худшем случае потери заказчика — проценты от среднестатистической стоимости системы подобного класса. и он никогда не попадет в ситуацию, где потрачено 90% бюджета, нужно еще 60% от первичнеой оценки и тогда якобы все будет сделано. Но сколько раз повторится эта ситуация никто сказать не может.
С другой стороны заказчик не потеряет проект выгодной автоматизации лишь из-за перезаклада «пугливого» исполнителя, честно заложившего все риски, вызванные объективной неопределенностью, в цену.


Если заказчика устроило соотношение отдачи и вложений, можно работать дальше. С оставшимся полупорядком неопределенности работают уже методами управления рисками: перераспределяют риски по участникам проекта (включая заказчика), страхуют буферами и предупредительными действиями.
Это я к тому, что за желание получить качественный техпроект и только на его основе дать оценку стоимости разработки с точностью ±10% нужно бить по рукам. В конце концов разработчики во-первых должны осознавать, что внутрикомандные риски (сломанные руки, внезапные увольнения, болезни, не подвезли снаряды, и т.п.) гораздо выше 10%, а во-вторых кто-то там тоже должен иметь тестикулы и уметь брать ответственность в ситуации неопределенности.
На вопрос: «а почему бы и нет», есть соображение, что разработка техпроекта без вовлечения самих разработчиков во-первых встанет дороже, а во-вторых все равно получится не очень качественной.


Что это будет в цифрах


В предыдущей заметке я выводил соотношение стоимости создания системы и отдачи от внедрения: отдача за 5 лет должна быть не менее, чем в 200 раз больше бюджета внедрения.
Тогда при стоимости внедрения Х


В деньгах это как-то так:

Стоимость системы, тыс.руб. Бизнес-анализ, тыс.руб. Концепция (и ТЗ), тыс.руб.
100 20 (Проработать рабочий процесс и требования к нему) 3 (изучить прайсы и описания продуктов)
500 100 (Микропроект по описанию процессов со сбором требований) 15 (Отсмотреть демо/документацию)
1000 200 30
10000 2000 (проект по бизнес-анализу) 300 (проект по концептуальному проектированию)
100000 20000 3000

Эти цифры отражают лишь порядок и приведены для обзора соотношений. Необходимо понимать, что на старте и отдача, и оценка стоимости системы известны предварительно, с точностью до порядка. По этому в итоге, с учетом особенностей конкретного заказчика, мы получаем поле для торговли в диапазоне от единиц до десятков процентов от стоимости системы за предпроект в зависимости от того, во что он больше поверит: в прогноз отдачи или в прогноз затрат.
В эту логику вы можете подставить свои цифры, в которые верите вы и ваши заказчики, и получить свои ориентиры.

Проверка реальностью


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


Любое самое качественное проектирование не страхует от всех неожиданностей. Кроме этого стоимость проектирования растет нелинейно с ростом качества результата. Может оказаться, что подъем качества на 1% удваивает стоимость проектных работ. Где-то это выгодно, а где-то нет. На практике аналитические документы почти никогда не доходят до стадии, где ими довольны сами аналитики, так как всегда где-нибудь найдется менеджер, который добьется сокращения сроков аналитических работ, по тому что «а что вы будете там делать так долго?».


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


Размер таких рисков не всегда одинаков и его можно считать пропорциональным степени изменений.
Мы можем разложить риски «несрабатывания проектных решений» по тем же компонентам: железо, софт, информация, люди, процессы.
Так же навскидку можно перечислить и факторы, образующие эту новизну:


Это и есть примерная карта для анализа изменений. По каждой позиции могут быть градации от нет изменений, до все построили с нуля, и даже до «всех уволили и набрали всех новых». Ясно, что риски ошибочных проектных решений так же будут меняться от нулевых до максимальных.
Риски по каждой группе компонентов снижают бездефектность данной оси, что влияет на общую бездефектность системы уже обсужденным выше образом.
Это дает нам простой вывод: если мы строим новые, невиданные доселе, процессы с новыми людьми, автоматизируем их новым заказным решением, то риски такого проекта будут очень большими. Если к 2% дефектов внутренних нестыковок прибавятся еще хотя бы 2% нерабочих в реальности проектных решений, мы вместо 60% системы получим на выходе 35%


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


Кроме приоритетов и итераций мы можем снимать неопределенность по каждой оси отдельно:


Важно помнить, что когда у тебя в руках молоток — все вокруг выглядит, как гвозди. Это значит, что не всегда надо кидаться проектировать и внедрять, иногда надо предлагать дешевую проверку каждого отдельного решения и гипотезы перед тем как будет потрачено много денег на внедрение всех решений в одной системе.


В итоге полный цикл всего, что может случиться с нами при проектировании системы будет выглядеть примерно так:


Можно предложить измерения показателей (или маркетинговые исследования) на практике и уточнение отдачи

Можно предложить пилотирование новых/промежуточных процессов с автоматизацией подручными средствами и с использованием систем быстрого прототипирования
Где-то здесь появляются бизнес-требования, или тактико-техническое задание, и/или цели автоматизации путем выжимки из проекта бизнес-процессов в сочетании с бизнес-моделью или проработкой проблемного поля


Можно провести пилотирование на триальных версиях покупного ПО (если не тебуется дорогая кастомизация)
Можно предложить разработку прототипа с ограниченными функциями и НФТ, затем опытную эксплуатацию


Где-то здесь появляются варианты концепции системы, оценка стоимости и сроков, решение делаем/не делаем+выделение бюджета
Тут же появляется ТЗ на АС или system scope&project charter/project plan путем небольшой перелицовки выигравшего варианта концепции


Здесь можно пойти короткими итерациями с развиваемым прототипом

Где-то здесь появляется ТЗ на ПО путем небольшой перелицовки техпроекта

Повторим


1. ИТ проекты отличаются тем, что слишком много частей должны идеально подойти друг к другу
2. Проектирование позволяет как-то с этим жить, но почти все проектирование находится в предпроекте по отношению к разработке ПО
3. Продать предпроектное проектирование можно, если отталкиваться от прогнозной отдачи проекта, но это требует честно отказываться от проектов с малой отдачей для заказчика
4. Для уменьшения риска построения системы недостаточно одного проектирования — проверить проектные решения можно по частям, чередуя проектные циклы с пилотированием и прототипированием.


 
Файлов нет.[Показать файлы/форму]
Комментариев нет. [Показать комментарии/форму]