КаБа

Всем привет. Я хочу вернуться к публикации своих мыслей об анализе и проектировании информационных систем. Но делать это в Телеграме. Ссылка на канал:  https://t.me/kaba_blog

Где-то года два назад я взял у одного своего друга почитать книжку   "Правила Голдратта" , написанную автором теории ограничений (TOC — Theory of Constraints) Элияху Голдраттом . Я не помню, что меня побудило уцепиться именно за эту его книгу. Но совершенно точно не теория ограничений. Я знаком с ее положениями, может быть не так детально, как многие другие коллеги, но достаточно для того, чтобы для себя решить, что TOC - это весьма удачная попытка формализовать логику принятия решений, основанную на здравом смысле. Ну т.е. чего-то выдающегося я от "Правил Голдратта" не ожидал, но читать почему-то начал. И не зря. В какой-то момент я обнаружил, что Голдратт не просто высказывает весьма интересные мысли, но и еще умудряется попадать в те моменты, которые я для себя считаю ключевыми для развития человека как личности с независимым мнением и способностью принимать нестандартные эффективные решения. Книга начала помогать мне упорядочивать лохмотья моих рассуждений....

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

Недавно я публиковал заметку "Почему проекты умирают. Архитектура" . Там я немного прошелся по тем, кто ее проектирует, но ведь началось все с понимания проектируемого продукта менеджером , точнее с того, что отсутствие этого понимания убивает проект. Но поскольку заметка носила характер выхлопа, картинок в ней не было и ряд коллег отнеслось к ней саркастически, я решил добавить картинку. Я бы не заморочился на нее, сейчас действительно нет времени заниматься рисованием подобных очевидных вещей. Но один кейс, в который пришлось немного погрузиться на протяжении первых недель марта, посеял во мне сомнение в том, что ниже представленная картинка действительно очевидна. Итак, па-бам! Вот она: Глядя на нее, необходимо помнить, что процесс проектирования - это эволюционное движение от абстрактного понимания к конкретным ответам на вопрос "ЧТО?". При этом процесс управления должен не отставать и эволюционировать от абстрактного понимания к конкретным ответам на ...

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

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

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

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

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

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

Хочу высказаться о следующей статье: What is a digital strategy? Mark McDonald Managing Director, Accenture Strategy, Digital Strategy Чем замечательна данная публикация, так это тем, что Марк определяет точку, от которой можно начинать разговор. В данном случае о digital strategy. Марк крут. Он не вплетает в определение и пляски вокруг него всякие новомодные слова, это чистый термин и чистая идея. Здесь нет маркетинга про продать технологию, подход, себя, контору. Другое дело, что продолжение этого разговора неминуемо приведет к необходимости понимания контекста компании, которая в своей strategy делает ставку на digital. Там сразу появляются клиенты (причем все равно, физики или юрики, Марк не сужает действие digital strategy розничным рынком) со всеми вытекающими про коммуникации, маркетинг и все остальное. Но при этом в его понимании digital strategy - это не просто про focus on customer и связанные с этим штуки, направленные на вовлечение, увеличение продаж и удержа...

Agile vs. Waterfall: Which Project Management Style Is Right for You? An infographic by the team at LiquidPlanner Люблю инфографику за ее наглядность. И всегда мечтал написать о том, в чем я ни фига не соображаю. Наконец-то такая возможность предоставилась. С этой картинкой очень сложно поспорить. Да, именно по этим причинам Agile получил право на жизнь как логическое продолжение борьбы с водопадом через совершенствование итеративного подхода. Нет, я конечно знаю, что есть люди, которые верят, что Agile к итеративному подходу не имеет никакого отношения, но лично мне проще упереться в ISO12207 и сослаться на эволюционную модель разработки: Agile - это развитие эволюционной модели. Я просто хотел обозначить для себя некоторые моменты, которые многие при организации проектов и выборе подходов к их выполнению либо забывают, либо не обращают на них внимания: Спор о том, что круче - Agile или водопад, не имеет никакого смысла. Равно как и вера в то, что Agile спасет мир. Тот ...

Я попытался на одной картинке уложить свое понимание термина Digital Strategy. Цель, которую я преследовал - выразить концепцию Digital Strategy через провязку методологий и концепций, так или иначе упоминаемых в разговорах про DS, в единую картину. В основу я положил типовую "слоёнку" информационной системы. Слева перечислил основные идеи и тренды современных ИТ-решений, а справа перечислил методологи и технологии. В результате получилась вот такая картинка: Тут надо сказать, что в полном смысле термина я в Digital Strategy вообще совсем далеко не специалист. То, что здесь нарисовано - это попытка осознания. Поэтому я буду крайне признателен любой обратной связи. UPD: добавил CEO, CMS, BPM. Удалил IT Consulting, поскольку в моем понимании он является частью IT Strategy; добавил Product Management.

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

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

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

Мне нравится проектировать порталы. Я всегда с удовольствием берусь за такие проекты. Мне они интересны тем, что, как правило, создание портала сопряжено с решением разнородных технических задач (таких, как интеграция, управление контентом, публикация, UXD, реализация workflow и т.п.). При разработке порталов основная проблема, с которой мне приходилось сталкиваться, заключается в том, что объем информации, который на них хотят публиковать, достаточно большой для того, чтобы решать задачу разработки требований к порталу "в лоб". Но ее можно прилично упростить, если структурировать содержание портала по типу его формирования. Т.е. если посмотреть на портал, то можно выделить четыре типа публикаций: статический контент; периодически обновляемый контент - контент, который редактируется от случая к случаю, по мере необходимости; динамический контент - контент, автоматически формируемый на основе каких-нибудь внешних данных; сервисы - формы, позволяющие пользователю вв...

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

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

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