Затем оказалось, что эти все продукты ещё и объединены в одно целое: MS Office. Outlook Exchange и SharePoint добавили командности к этому декстопному Офису.
Задача выигрыша в конкуренции на рынке мейкерского софта может быть поставлена таким же образом: какой-нибудь КрупноСофт сделает лучшие в своём классе десктопные продукты для одного целого -- Мастерской (Workshop) и дополнит их средствами интеграции и командной работы.
Легко так поставить задачу, но с этого момента начнутся сложности. Мейкеры бывают очень разные. Если брать киберфизические системы, то разнообразие используемого для их создания софта зашкаливает -- там и 3D CAD, и IDE для программирования контроллеров, никаких жёстко конкурирующих "лидеров рынка" для всего этого разнообразия пока нет. Впрочем, клерки в офисах тоже бывают разные, при этом поначалу никто даже не знал, что один из главных софтов для них -- это электронные таблицы. И базы данных тоже сначала были не слишком внятные (тогда популярны были деревянные, потом CODASYL, реляционки появились сильно попозже). Ничего, устаканилось и унифицировалось. И от многих-многих разработчиков разного офисного софта вдруг оказалось, что это одна фирма -- мелкософт.
Так что с мейкерами нужно будет потрудиться, и сделать тесно работающие между собой декстопные:
-- Логику (Logic), концептуальный моделер + требования + архитектура
-- Форму (Shape), CAD для 3D, куда как-то встроить мультифизическое моделирование
-- Мозг (Brain), IDE для программирования контроллеров
-- Интеграл (Integral), сборочный и наладочный софт -- поддержка правой части V-диаграммы, в том числе и V&V.
А ещё нужно будет воткнуть все эти разные CAD/CAM в достойную PLM/ALM (product/application lifecycle management) систему, то есть обеспечить координацию отдельных инженерных работ в рамках. Сразу ограничимся two-pizza team (команда, которую можно накормить двумя огромными американскими пиццами: 5-12 человек, не больше. Если больше, то накладной расход на координацию будет зашкаливать -- и работать будет трудно и медленно).
Жизнь со времён оформления Офиса тут тоже поменялась: для Мастерской сегодня нельзя быть уверенным, что команда сидит в одной комнате, или даже в одной фирме. Поэтому мы должны сделать распределённую PLM/ALM-систему. Как это сделать, нужно ещё придумать. Распределённый BitKeeper был нарыт линуксовцами где-то в 1998, а начальный релиз Git случился только в апреле 2005. С тех пор распределённые системы управления конфигурацией потихоньку отжирают рынок у централизованных. Проблем нужно решить множество, все эти продукты нужно ещё придумать:
-- Версия (Version), это распределённое управление конфигурацией: PDM (ср.: Autodesk Vault) и софтовая система контроля версий (ср.: Git), каким-то образом в одном флаконе.
-- Изменение (Change), распределённый issue-tracker (ср.: Jira) с шаблонами для возможности фрагментов up-front планирования (ср.: adaptive case management)
-- План (Plan), менеджерский софт -- расчёт и оптимизация потоков по заветам lean 2.0, kanban и т.д.
-- Смена (Relay), распределённый чат с наворотами (ср.: Slack).
-- Доки (Docs), распределённая вики для документирования.
-- Люди (People), работа со стейкхолдерами, помощь в проведении совещаний, вербовке сотрудников (трудно подобрать аналог, но начинать думать можно с CRM).
Это я всё функциональные компоненты описал, по минимуму. Как оно там будет поделено на приложения-модули, и как оно там будет устроено внутри, я пока даже не загадываю. Я просто постулирую тут, что есть:
-- какие-то front-end системы, более-менее индивидуального пользования, АРМ разных разработчиков
-- какие-то back-end системы, более-менее командного пользования, куда втыкаются front-end системы. У этих back-end систем тоже бывают АРМы (инженерных) менеджеров. И эти back-end системы становятся распределёнными.
Это я тут нафантазировал только для того, чтобы потом сделать следующий шаг: представить, как эта классическая архитектура КрупноСофт Мастерской могла бы поплыть в сторону смешанной человеко-машинной архитектуры с вниманием к человеческому "нейро", вниманием к особенностям человека.
Ибо у каждого человека по факту уже есть собственный экзокортекс, киберчасть его психики. У него уже есть свой front-end Тудуйник (ToDoList), у него есть своя собственная почта и заметки, и их как-то нужно одновременно:
-- не смешивать с командными (privacy личных дел, плюс человек участвует во многих командах, включая одну или даже несколько семей -- нехорошо раскрывать их дела друг другу)
-- смешивать с командными, ибо вести много списков дел, почт, заметок и т.д. -- это одному человеку не под силу, человек-то у нас один! Важность поддержки одного списка дел личных и командных подробно обсуждает в своём курсе
cartmendumС персональной стороны приходит ещё софт управления вниманием и деятельностью (персональный ассистент, возможно это просто более разумный Тудуйник -- в этом направлении сейчас много фирм работает, все эти GoogleNow, Siri, VIV развиваются как раз в эту сторону).
Но и со стороны back-end появляется софт ведения совещаний: фасилитация группе полезна, и непонятно, как делиться нейрометрией с групповым фасилитатором (те же соображения privacy и ограничение нераскрытия сведений друг о друге).
Тут я бы пока остановился в своих фантазиях, ибо легко докатиться до нового витка дискуссий о киберкоммунизме. Напомню, что теоретический коммунизм опирался на идею коммун: эдаких больших семей без права на личную жизнь. У коммунистов вопрос обобществления женщин был одним из важных, ибо их по факту приватизация в моногамной семье казалась нарушением принципа коммунальной жизни, а симметричность отношений в голову не приходила, вопрос об обобществлении мужчин как-то не ставился. Я в бытность студентом поизучал этот вопрос в библиотеке, в вузовских курсах научного коммунизма 70-х (когда я этим занимался) почему-то эти вопросы аккуратно были исключены.
Но когда мы выходим на вопросы приватизации-обобществления в коммуну или семью и/или предпринятие экзокортексов отдельных людей, это может оказаться даже более нервным в обсуждении, чем вопросы приватизации-обобществления "своих половинок". И тут нужно вовремя остановиться, чтобы не ввязаться в создание супер-пупер-нейро-интеллектуального софта если не для мейкерской смешанной человеко-машинной коммуны, то для мейкерского колхоза.
В любом случае, нужно разным софтом поддерживать разные части человеческой личности, разные части человеческой психики. Для этого в архитектурных диаграммах мейкерского предпринятия нужно рисовать и архитектуру психики. Моя идея тут -- рисовать эту архитектуру психики в Архимейте (подробней: http://openmeta.livejournal.com/236160.html).
А что, если речь идёт не о мейкерстве, и тем самым не о Мастерской? Если команда занимается чем-то другим? IMHO, если команда чем-то занимается, то всё одно строит систему. Это означает, что софты front-end будут другими, а командный back-end и все связанные с ним проблемы останутся теми же.