КаБа

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

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

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

Расскажу вам один случай, о котором узнал совершенно случайно от одного знакомого, с которым вместе работали в старой конторе. Команда делала проект для одного местного Заказчика. Целью проекта была миграция старого приложения на новую платформу. С точки зрения функциональности этого приложения стоит отметить два момента: оно лопатило кучу информации и генерило документы космических объемов. Ко всему этому функциональному многообразию надо было добавить передачу этих феерических объемов информации во внешнюю базу данных. Взаимодействие с внешней базой должно было строиться через ее хранимку, написанную фиг знает кем фиг знает когда. Когда дело подошло поближе к сдаче приложения в эксплуатацию, то оказалось, что производительность его настолько низкая, что использовать его в производстве попросту невозможно. В этот момент пришел Самый Главный Менеджер, сменил руководителя проекта и взял управление в личные руки. Ведущего аналитика упрекли в том, что он не уделил вним...

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

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

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

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

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