Макет или прототип?

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

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

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

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

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

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

Caesar's to Caesar

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

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

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

"What I aspired to be and was not, comforts me"

Вчера побывал по случаю на семинаре Toshio Obi (надо сказать, сам он говорил немного и не слишком оригинально, и большего внимания заслуживало выступление его коллеги Taro Kamioka).

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

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

В качестве одного из подтверждений был приведёт следующий пример - в Японии, по словам докладчиков, около половины ИТ-директоров не имели отношения к ИТ вообще в ходе своей карьеры, т.е. являются абстрактными менеджерами, брошенными "на всё это компьютерное хозяйство". Одновременно велико число японских компаний, где CIO является де-факто вторым лицом в правлении, которому отчитываются (technology), CFO (finance), CAO (asset), CKO (knowledge). Мне это показалось довольно странным, т.к. на мой взгляд пример не подтверждает сказанное, а скорее его опровергает - если ему верить, компетенции в бизнесе ИТ-директору действительно нужны, но берутся эти компетенции из бизнеса же, а не из ИТ.

Ещё один странный аргумент относился к изоморфности ИТ и бизнеса - в силу чего изменения в одном не могут происходить без синхронных изменений в другом. Это тоже скорее серьёзный недостаток ИТ-подразделения, от которого на месте CEO я бы стремился всячески избавиться, а не то что слушать мнение CIO о том, что и где мне нужно поменять. В такой схеме получается, что бизнес фактически находится в заложниках, вряд ли кому это может понравиться.

По ходу обсуждения мельком вспомнили книжку "Does IT matter?" - в том ключе, что на самом деле, мол, автор не совсем прав, но да, сама по себе ИТ-компетенция, конечно, успешного перехода в бизнес не гарантирует. Я счёл это замешательство положительной характеристикой, и, видимо, с книгой стоит ознакомиться.

GNU 25

Стивен Фрай выступает с поздравлением:

Разумеется, иллюстрацией к статье о Фрае в Википедии уже служит кадр из выступления.

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

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

Helicopier

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

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

Презентация проекта на сайте выложена в одном архиве с видео и имеет размер около 50 Мб, поэтому на всякий случай выкладываю её здесь в облегчённом виде:

Механический калькулятор

Карманный арифмометр Curta - видео и подборка фотографий:

Характерные отличия веб-проектов

- Кто такой Карл Маркс?
- Экономист.
- Как наша тётя?
- Нет, наша тётя - главный экономист.