КаБа

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

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

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

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

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

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