VII Разработка плана реализации и внедрения проектного решения

Блестящим планам везет на проектировщиков.
Скверным планам везет на исполнителей.
Веслав Брудзинский.

На этом этапе процесс вновь начинает крутиться вокруг руководителя проекта. Снова оценка трудоемкости, определение сроков, согласование объемов, утверждение порядка исполнения и т.п.

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

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

V Разработка плана-графика проектных работ

Чтобы выполнить большой и важный труд, необходимы две вещи:
ясный план и ограниченное время.
Элберт Хаббард

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

Наступает момент, когда в водоворот процессов активно втягивается руководитель проекта. Нет, он и до этого мог участвовать в мероприятиях. Например, связанных с оценкой трудоемкости, определения сроков и т.п., но именно сейчас он получает возможность сполна проявить все свое мастерство планирования и управления.

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

Первое, что руководитель проекта должен включить в план — это свои собственные работы. С протяженностью этой трассы на диаграмме Ганта вряд ли может конкурировать еще какая-то линия. Под ней располагаются, прерывающиеся в некоторых местах, колеи сотрудников проектно-аналитического цеха.

I Вступление

Из хаоса каким-то образом рождается порядок.
Некоторые об этом узнают из газет со значительным опозданием, а некоторые по горькому опыту на месте и в процессе создания этого порядка.
Михаил Булгаков.

Просматривая статьи, посвященные той или иной теме, связанной с созданием программного обеспечения, часто наблюдаю, вот какую картину: узкая тема раскрыта интересно и профессионально, но вот когда задеваются нюансы на стыке, по ту сторону от основного вопроса, чувствуются рассогласованность и провалы в общем понимании процесса производства информационных систем. Разрываются причинно-следственные связи. Иногда, непонимание внешнего окружения обсуждаемого вопроса, вносит искажения в основную тему, ну или по крайней мере, затушевывает некоторые важные моменты, достойные внимания. Когда же вступаешь с автором в полемику, становится очевидным, что для него вопросы, выходящие за рамки его наблюдений и опыта, абсолютно неважны. Он просто упомянул всуе сопредельную тему, а дальше, как говорится, уже не его проблемы. Второй нюанс, на котором я хочу заострить внимание – пренебрежение масштабами замысла. Ведь то, что хорошо для реализации малых проектов, смерть для больших и наоборот. Этот факт часто попросту сбрасывается авторами со счетов. А в результате идут баталии с критиками решения, в которых каждый как бы и прав, но только с точки зрения своей отдельностоящей колокольни. Сами же точки зрения никак не обозначаются сторонами дискуссии, а потому никак не учитываются.

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

С предыдущей частью статьи можно ознакомиться, перейдя по ссылке

III Определение понятия архитектор

Врач может похоронить свою ошибку,
архитектор – разве что обсадить стены плющом.
Фрэнк Ллойд Райт.

Зачастую в ИТ отрасли, говоря об ИТ архитекторе, подразумевают продвинутого разработчика, способного самостоятельно спроектировать, а главное реализовать большую сложную систему. А иногда попросту полагают, что это следующая ступенька в профессиональной иерархии разработчиков. Например, начал молодой специалист свою карьеру разработчика, ему присвоили скромное, но почетное звание Junior. Он учится, развивается профессионально, растет над собой и коллегами, и ему, в качестве компенсации за труд и упорство, торжественно присваивается звание Middle. Но он неугомонный и дальше не останавливается в развитии, совершает ряд подвигов, самоотверженно взвалив на себя ответственность за принимаемые решения. Глядишь, и его уже удостаивают высочайшего звания Sinior. А дальше? А если он не желает почивать на лаврах успеха и хочет развиваться, ему что присвоят под звуки фанфар генеральское звание Архитектора? Так ли это?

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

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

I. Вступление

Архитектура распределяет массы и объемы.
Вдохновение превращает инертный камень в драму.
Ле Корбюзье.

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

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

Одна маленькая, но очень гордая ИТ фирма, работала на субподряде у “монстров” отечественной ИТ индустрии. Начинали свое сотрудничество они еще до кризиса, когда деньги особо не считали, выделяя на разработку столько, сколько нужно. Меряли на глазок, ну примерно вот столько, показывая зазор между большим и указательным пальцами, дающий понять – нужную толщину пачки денег. При таком раскладе, напрягаться с точными расчетами бюджета проекта не было особого резона. Прикинули грубо и побежали. Ошиблись, ну с кем не бывает, технологии все время меняются, заказчик толком объяснить, что ему надо не может. Главное выдержать временные сроки. Чувствуешь, что не успеваешь, привлек еще специалистов и гонишь разработку к сроку. Выходит конечно чуть дороже, но вполне работоспособная схема, всем хватало, и главное голова от проблем особо не болела.

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

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

Недавно я предпринял попытку провести анализ статьи «Начальник, хочу работать из дома», опубликованной на Хабрахабр. Ключевые аспекты выбора статьи – это высокая востребованность самой темы и высокий рейтинг статьи, в частности.

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

В итоге, рейтинг мой статьи разделился почти пополам 37 «против» и 39 «за», собрав больше 200 комментариев, что само по себе подтвердило, что тема в тренде.

Прежде всего хочу выразить благодарность всем принявшим участие в обсуждении.

Беседу №1 можно освежить в памяти, перейдя по ссылке

Иллюзии привлекают нас тем, что избавляют от боли, а в качестве замены приносят удовольствие.
За это мы должны без сетований принимать, когда, вступая в противоречие с частью реальности, иллюзии разбиваются вдребезги.
Зигмунд Фрейд

III Использование Виртуальной реальности

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

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

1. Погружение в комфортную иллюзию, придуманную кем-то

А когда же мы впервые сталкиваемся с ощущениями несуществующего мира? Наверное это все-таки сказки, которые нам читали в детстве. С давних времен, испытывая потребность хотя бы на время убежать от жестокой реальности, в иную: счастливую, справедливую и комфортную, люди придумывали сказки. Хотя справедливости ради, надо заметить, что на некоторых больше действует обратный эффект. Окунаясь в ужасы и страдания, человек вырвавшись обратно в объективную реальность, понимает, что жизнь, по сравнению с прочувствованными ощущениями, не так уж ужасна, а вполне даже сносна, и он еще не плохо устроился, да чего там — повезло просто и все. И даже повзрослев, люди не перестают нуждаться в сказках. Так и тянет добавить сюда фразу «и некоторые козлы этим пользуются…».

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

Статья привлекла меня 3-мя интересными на мой взгляд аспектами: 1) сама тема очень злободневна и статья получила множество комментариев, 2) публикация набрала рейтинг более 100, 3) при этом она не несет в общем-то никаких реальных объяснений, а построена на очень спорных аргументах — лозунгах.

XI Специфицируем требования

Требование — всего лишь временный посредник для решения проблемы реального мира.
«Фабрики разработки программ» [8]

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

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

IX Определение поведения системы.

В очень многих случаях поведение … только потому кажется смешным, что причины его, вполне разумные и основательные, скрыты от окружающих.
Франсуа де Ларошфуко

После того как мы определились с перечнем основных сценариев и сущностей предметной области, необходимо сопоставить их друг с другом.

Цель данной группы работ: на основании выявленных сущностей и процессов, разрабатываемого целевого продукта спроектировать поведение системы, распределив ее по классам.

VIII Определяем сущности предметной области

Все, что видим мы, — видимость только одна.
Далеко от поверхности мира до дна.
Полагай несущественным явное в мире,
Ибо тайная сущность вещей — не видна
Омар Хайям

Определив абстрактные хранилища продукта, мы получаем костяк для построения детальной модели данных. При проектировании структуры сущностей продукта, удобно использовать канонические диаграммы «Сущность-связь» (ERD), логическую диаграмму (Logic Diagram) или диаграмму классов (Class diagram).

Цель этой группы работ — спроектировать модель хранилищ данных для использования в продукте, а также задокументировать сущности системы и способы их взаимодействия.

Теория проектирования такого типа диаграмм детально изложена в литературе, описывающей работу с UML. Например, эта тема очень удачно представлена в [11]. Поэтому остановлюсь лишь на некоторых аспектах, интересных на мой взгляд,.

Об авторских тренингах на тему: «Обучение проектированию ПО» подробнее можно узнать на моем YouTube канале

VII Детализируем процессы, включенные в рамки проекта

Нужно усложнять, чтобы в результате все стало проще,
а не упрощать, чтобы в результате все стало сложнее.
Веслав Брудзиньский

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

Цель данной группы работ: на основании выявленных функций, определить сценарии использования, разрабатываемого целевого продукта.

Об авторских тренингах на тему: «Обучение проектированию ПО. Функции системы» подробнее можно узнать на моем YouTube канале

VI Определяем функции системы и границы проекта

Каждая модель ограничена в своих ответах, но нет ограничения на то, как и что моделирует модель, как нет ограничения на человеческую мысль
Дуглас Т. Росс

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

Цель данной группы работ: максимально полно определить набор функций, который должен выполнять целевой продукт, для удовлетворения выявленных потребностей заказчика. Отобрать те из них, которые, могут быть реализованы в рамках текущего проекта.

Об авторских тренингах на тему: «Обучение проектированию ПО» подробнее можно узнать на моем YouTube канале

IV ОПРЕДЕЛЯЕМ ЦЕЛИ, ПРОЕКТА

Цель не обязательно должна достигаться. Порой это просто направление двигаться дальше.
Брюс Ли.

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

Цель данной группы работ: определить основные задачи, которые ставят перед собой группы заинтересованных лиц, участвующих в проекте.

Пролог

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

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

Теперь я хочу рассказать, как можно качественно сформировать сами требования, ведя Заказчика от его «хотелок», к его счастливому и плодотворному сожительству с программным продуктом, его мечты.
Об авторских тренингах на тему: «Обучение проектированию ПО» подробнее можно узнать на моем YouTube канале

I Вступление

У того, кто никогда не меняет взглядов, обычно нет никаких взглядов.
Альберто Моравиа.

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

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

С другой стороны эта публикация является логическим продолжением моих статей «Где логика? Учимся мыслить системно» и «Социальный Организм — как форма эффективного взаимодействия команды», в которых я стараюсь популяризировать системное мышление в повседневной жизни, в быту и профессиональной деятельности.

Если Вы хотите об этом поговорить, тогда Вам сюда… Надеюсь, что будет увлекательно и не скучно.

С частью 1 можно ознакомиться, перейдя по ссылке
С частью 2 можно ознакомиться, перейдя по ссылке

Использование спецификаций требований в управлении проектом

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

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

Но, естественно есть погрешности и процедура – процедуре рознь, поэтому, для более точного расчета можно использовать коэффициенты сложности для реализуемых объектов. Например, «сложная форма» — 1,5; «обычная форма» — 1; «простая форма» — 0,5. Для каждого типа элемента подбираем свою линейку значений коэффициентов. Полученные таким образом данные можно занести в электронную таблицу и сбить итоговые затраты в человеко\днях или человеко\часах (как Вам удобнее) по подсистемам и проекту в целом.

С частью 1 можно ознакомиться, перейдя по ссылке

Рекомендации по проектированию спецификаций требований с примерами

То, о чем не говорят, каждый понимает по-своему

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

Готовим читателей к знакомству со спецификациями

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

Пример обзора документа:



Для лучшего восприятия контекста разрабатываемой системы, помимо разделов, отобранных нами в структуру документа — как обязательные, я стараюсь включить в текст информацию о целях, которые должны быть достигнуты в результате разработки целевого продукта или его составного модуля. Разработчики все-таки должны осознавать, чего же желает заказчик получить на выходе проекта. Для описания этого раздела подойдут формализованные Потребности заказчика. Похожий раздел есть в большинстве стандартов, например в ГОСТ-34.602-89 [4] он называется «назначение и цели создания (развития) системы».

По мотивам моей статьи, изданной ранее…

Вступление

Получить бы медаль, а уж с обратной ее стороной найдем, что делать.
(Георгий Александров)

В подавляющем большинстве работ, посвященных управлению требованиями, которые мне довелось читать [1], [2], [3] и другие, авторы хороводят вокруг заказчика, акцентируя основное внимание читателей на том, как максимально эффективно организовать работу именно с ним. Ну и конечно, львиная доля труда обычно посвящена вопросам преобразования собранной информации в некие проектные решения, моделирующие разрабатываемую систему, а также оформление их со спецэффектами, бантиками и рюшами. Разумеется это все важно и я ни в коем случае не хочу умолить значение этих аспектов формирования требований, но есть еще и обратная сторона. Ведь дальше требования должны попадать непосредственно в “цех” по производству программного обеспечения. И именно там они, до самого рождения целевого продукта, останутся основным сводом законов и правил, по которым он будет зарождаться и являться миру. Этот факт уже сам по себе определяет важность того, насколько точно требования должны соответствовать интересам специалистов, призванных воплотить их в конечном продукте.

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