КаБа

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

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

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

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