-- GTD для в том числе немаленьких организаций
-- программирование масштабного сотрудничества
-- организация -- это про эффективное разделение труда
-- администрирование достижения цели организации
-- управление процессами, проектами, GTD/issue tracking -- это все про одно и то же.
-- маржинализм в организации
-- капиталистическая эксплуатация ограничений
-- органайзер для организации
Я уже столько постингов про это написал, что тут даже не хочу расшифровывать. Нужно будет провести отдельную сессию, чтобы зафиксировать мантру.
Целью настоящего постинга является проброс тропинки от высокоумных размышлений про изобилие бизнес-идей (http://ailev.livejournal.com/484203.html) и определения учебной оргонтологии (http://ailev.livejournal.com/480843.html и http://ailev.livejournal.com/481371.html) к скорейшему написанию учебного софтверного приложения, с использованием которого можно будет изучать правильную бизнес-философию и понятия/терминологию этой самой оргонтологии. Лучше всего определить такое приложение (в маржинальном подходе ;) по сравнению с сегодняшним state-of-the-art в области корпоративных органайзеров.
Ежели поглядеть на сервисы самих 37 сигналов с нашей колокольни, то все они крутятся вокруг той или иной организации GTD. Почему многочисленных приложений 37 сигналов недостаточно, даже с API-"расширениями"?
Эмпирическое правило: когда число записей/объектов превышает 400, для работы с ними нужна база данных. До 400 -- обходитесь электронными таблицами, текстовым редактором и прочими средствами удобной ручной работы -- нечего на малых объемах данных автоматизацию наводить, себе дороже будет. Проблемы начинаются тогда, когда в организации (с точки зрения общего планирования) точно больше текущих 400 tasks, а у одного работника их порядка 150 (по оценке автора GTD). В бизнес-организации примерно из 50 человек в системе issue tracking обычно можно найти 20-50 тысяч работ (уж так обычно получается). В строительных проектах легко находятся сотни тысяч работ, системы управления проектами тестируются на том, как они справляются с перевариванием миллиона работ.
Поэтому я бы условно разделил все средства поддержки администрирования/организации на
1. персональные органайзеры (Outlook, 37 сигналов в части их персональных эккаунтов), и нас они будут мало волновать;
2. бригадные/командные органайзеры (сервисы 37 сигналов, включая в том числе расширения к ним типа http://basecamphq.com/extras), когда цель организации запросто удерживается небольшим коллективом, и вместо workflow поддерживается именно что набор интегрированных "персональных GTD" (интеграция тут -- это когда несколько человек могут осуществлять доступ к чьей-то trusted system).
3. корпоративные органайзеры (наследники SAP и 1С:Предприятия, Primavera и SpriderProject, JIRA и http://www.trackstudio.ru/products-benefits.html) -- когда размер уже таков (скажем, от 20000 tasks в небольшой сервисной компании), что управление им как целым уже имеет значение, а некоторые пользователи системы (те же самые администраторы, или представители клиентов) хотят прогнозов/смет и прогнозов/отчетности выполнения по огромным проектам (скажем, один строительный/машиностроительный проект -- на пару сотен тысяч наполовину предсказуемых в момент его начала tasks). В корпоративных органайзерах уже нельзя обойтись без управленческого учета, поэтому кроме tasks и persons он обязательно имеет дело с деньгами, материалами и так далее со всеми остановками.
Нас интересует третий случай, и можно только (специально и сознательно) надеяться, что "правильный" софт третьего случая можно будет использовать и для первых двух. Итак, мы делаем органайзер для организации ("корпоративный органайзер" мне не очень нравится -- ибо мне кажется, что использовать "правильную бизнес-философию" и органайзер к ней можно будет не только в корпорациях, но и в благотворительных организациях, госорганах, политических партиях, церквях и т.д.). Тут я окончательно признаю, что нужно отдельные имена для нашей административной философии (в частном случае -- бизнес-философии) как совместимого набора правильных административных (в том числе бизнес-) идей, и поддерживающего ее учебно-рабочего софта. Ибо нет имени -- нет предмета.
Почти полгода назад я писал про то, что правильную бизнес-философию может поддержать какая-то система на базе issue tracking (http://ailev.livejournal.com/443213.html), и там приводил в пример JIRA. Буквально вчера я нашел более интересную в этом плане систему -- TrackStudio (http://www.trackstudio.ru). Обязательно обратите внимание на дискуссию http://meatreach.livejournal.com/141410.html, где
meatreach делает попытку простым языком рассказать о сути моих предложений, а maximkr рассказывает на принятые в TrackStudio решения, которые на первый взгляд очень близки к нашим размышлениям.В TrackStudio -- все на свете tasks, и эти tasks можно группировать по иерархическим "папкам" и привязывать к "категориями" (экземплярами, приложениями workflow) (http://www.trackstudio.com/documentation/eSoliaGuide.pdf). Тем самым они получают что-то типа сильно урезанной по возможностям (прежде всего -- числу классификаторов/иерархий: это tasks, users/status, workflow/category, messages) объектной/семантической сети, в терминах которой администраторы могут многое рассказать об организации и принятых в ней правилах появления, выполнения и закрытия tasks. Урезанность по возможностям -- это не столько упрек, сколько сожаление: добавка произвольного числа классификаторов/иерархий позволяет произвольным образом наращивать выразительность системы, но это в TrackStudio, похоже, не реализовано даже на уровне движка (я рад был бы ошибиться).
В приложениях 37 сигналов для task предлагается простейшая двухуровневая категоризация. Задачи бьются на отдельные списки, называемые в разных приложениях по-разному (page в Backpack, project в Basecamp, case в Highrise), и дополнительно могут быть рассортированы в различных dashboard по buckets (например, "сегодняшние", "завтрашние", "на этой неделе", "через неделю", "когда-нибудь"). Это очень хорошо, когда списки задач короткие, и мало кто кроме самих сотрудников озабочен разделением труда между ними. Но как только у вас появляется десяток тысяч tasks, у VIP не будет никакого способа поглядеть на работу "сверху" -- и появляется риск того, что многие и многие сотрудники будут заниматься работой неизвестной полезности для организации, оптимизируя свою загрузку в соответствии со своими собственными целями, а не целями организации. Нужен язык, на котором можно было бы описывать немаленькие организации.
Какая самая главная задача администратора? Выразить в терминах Орглана конкретную организацию, побочным продуктом чего должна быть настройка софтового органайзера на эту конкретную организацию. В Орглане, конечно, есть базовые классы -- task (нужно еще ухитриться перевести это слово -- дело, задача, задание, работа, урок, норма, поручение) и эээ... doer/target/performer (все это словарные значения слова "исполнитель"). В конкретной организации все tasks называются их именами ("послать почту", "ответить на вопрос", "прикрутить гайку"), но не "задача посылки почты", "поручение ответа на вопрос". Другое дело, что категоризация/группировка задач, которые может потребовать конкретная организация -- полностью зависит от администратора, и должна быть полностью настраиваема. При этом никакая категоризация не должна закрывать базовых возможностей работы с задачами:
предварительного их планирования (создание для них WBS или дополнение ими WBS), моделирования (в смысле прогона PowerSim), оценки временных буферов (в смысле критической цепочки и барабана-буфер-веревки http://ailev.livejournal.com/458701.html), учета при исполнении (изменения учетных регистров), а также коммуникации/коллаборации по всем этим вопросам.
Рядом со всей этой механикой должна существовать учетная машинка (чтобы оценить сложность этой задачи, поглядите на описание учетной машинки в 1С -- сразу переходите к разделу "прикладные концепции" и ориентируйтесь на слова "план счетов и проводки", "регистры и движения" и "расчет и журнал расчета"): http://www.computerra.ru/offline/1999/281/2251/ (обратите внимание -- это 1999 год, к этому времени 1С уже был вполне доминирующим продуктом. Немудрено, что он захватил такой большой кусок рынка: ведь 1С это просто виртуальная машина для удачного Учетлана, на котором можно выразить даже безумные правила советско-российского учета. Чтобы повторить такой успех, нам нужно создать виртуальную машинку для Орглана, в том числе связав его с Учетланом -- учет ведь тоже вполне административная функция).
Тем самым нужно выполнить следующую работу:
а) выбрать таки представление для tasks и doers (семантическая сеть? иерархии классов/объектов?).
б) понять, какие еще там есть типы сущностей и обеспечить формальную расширимость их набора (связи=проекции классификаторов в семантической сети? а как это будет объектном мире?).
Далее нам нужно поговорить о классах пользователей софта и соответствующих их интерфейсах:
-- интерфейс администратора (организации!), который должен получить и очень гибкое средство манипулирования всеми объектами системы. Скорее всего, это должен быть двухоконный (с окнами "откуда" и "куда") браузер сущностей, в котором легко отсматривать иерархии и устанавливать связи. Это "время организации труда". У администратора также есть различные способы управления отображением <базы оргзнаний> на отдельные страницы, доступные сотрудникам (да и самому администратору) -- не без умысла назовем это пока Tweak (то есть администратору доступен скриптовый язык).
-- интерфейс сотрудника -- однооконный, формируется участием его в конкретных процессах/проектах/workflow (все просто и удобно, "персональный GTD") -- даже, если сотрудник является менеджером (тот, кто раздает экземпляры tasks, но не администратор, порождающий новые типы tasks=порождающий оргрегламенты. Тут думать еще). Это интрерфейс "времени труда". Понятно, что сотрудники (совместно трудящиеся ;) могут быть совсем разными по требованиям интерфейса, от весьма продвинутых менеджеров до не желающих ничего знать, кроме возможности удобно запостить запрос и быстро получить ответ сотрудников организации-клиента (тем не менее, они вполне сотрудники в рамках общего для двух организаций разделения труда. Это к вопросу о том, что организация -- в глазах смотрящего/администратора, а не проходит по границам юридических лиц или даже границам контрактов).
-- и нужно еще обязательно добавить интерфейс программиста самой системы, ибо программисты тоже люди, и им нужно иметь легкие и быстрые способы доработки системы (например, добавки сущностей в Орглан).
"Внутреннее представление"/<база оргзнаний> сама по себе абстрактна и труднопредставима для сотрудников. Сотрудники предпочитают говорить о своих делах непосредственно в терминах входных/выходных форм. В любой организации, которая начинает пользоваться компьютерным приложением, "способ верстки" становится реальным объектом мира, и мышление сотрудников быстро (или небыстро!) подстраивается под его использование. Движение невидимых сущностей становится движением видимых объектов верстки -- страниц/документов. В какой-то момент в "Электронной России" с тяжелым вздохом отказались от "бездокументарного подхода" в пользу подхода, закрепляющего за проходящими через всяческие (в том числе и human-machine) интерфейсы messages статус документов. И пользователи начинают по факту говорить не в терминах "изменения состояний <базы оргзнаний> и системы учета", а в терминах работы с документами/экранами. На эту тему нужно еще тщательно подумать.
Тем самым, у администратора есть минимум две задачи по настройке органайзера на нужды конкретной организации:
-- выразить сущность организации на Орглане (задав тем самым схему <оргбазы знаний>), и
-- задать отображение <оргбазы знаний> в терминах конкретных экранов, с которыми работают люди. Это весьма, заметим, нетривиальная задача -- ведь администратор не юзабилист, не программист человеко-машинных интерфейсов, не вебмастер и вообще не про компьютерные системы. Но и на предзаданные шаблоны я бы тоже не слишком надеялся. Тут тоже нужно крепко думать.
Не нужно преуменьшать сложность и размытость такого деления. Так, понятие bucket (например, inbox, today, next week, later) в GTD можно вполне считать "внутренней" организационной сущностью. Но есть прямой соблазн рассматривать bucket как просто способ группировки задач при их выводе на какую-то конкретную страницу. Результат внешне будет тем же самым (список группированных задач на странице), реализация же -- совершенно различная.
Все нынешние органайзеры поддерживают асинхронную коллаборацию (что крайне ценно). Особняком стоят "средства для встреч/конференций" (синхронная работа, или "чиста конкретна коллаборация"). Нужно стереть разницу между этими двумя классами приложений: все должно происходить так, как "просто в офисе" -- но с гибкостью доски, мела и тряпки для очно собравшейся группы людей. Асинхронно -- это когда кто-то может сделать пометку на доске, возле которой пока никого нет. Синхронно -- если встретились двое, то пометки все равно делаются, но совместно -- с параллельным очным обсуждением. Компьютерная грамотность -- это про умение записывать свои мысли на самом гибком медиа. Так вот: медиа должно соответствовать и не пасовать, если около его терминалов в разных городах собралось несколько компьютерно грамотных. Приложение должно быть доской, мелом и тряпкой "на стероидах". Похоже, что трехмерная коллаборация тут будет давать некоторое количество очков по отношению к двумерной -- исключительно по emotional broadband причинам. Хотя тут еще можно указать на улучшенный по сравнению с 2D указательный функционал ("вот это число у тебя что означает?" -- и хорошо видно кто куда указывает).
Тем самым для нашего будущего софта можно выделить три уровня интерфейсных решений:
а) поддерживаемое "внутреннее представление" организационной/административной онтологии (объекты и операции с ними) -- и это сейчас главная задача (как выбор самого расширяемого представления, так и фиксация в нем начальной оргонтологии=Орглана, данного нам на этом этапе в абстрактном синтаксисе). Собственно, "двухоконный организационный браузер" как раз должен представлять собой базовое средство редактирования этого "внутреннего представления".
б) интерфейсные решения (группировки сущностей по "страницам", "отчетам" и прочим "документам" и "формам", тэги и табы, ссылки в правильных местах, меню правильного размера в правильных местах, шрифтовые и цветовые решения) -- скорее всего, это Tweak и halo interface. Именно на этом уровне будет решаться, сможет ли сотрудник-гуманитарий воспользоваться системой, или для этого ему нужно предварительно закончить пару курсов мехмата и школу сисадминов. Неочевидно, что интерфейсные решения должны быть обязательно "в браузере", можно думать и о "толстом клиенте" (например, Крокете).
в) коллаборативная "синхронная" среда -- скорее всего, это Croquet (чтобы использовать 3D emotional broadband) и она должна получиться "автомагически", если мы будем использовать Tweak.
Для решения первой задачи нужно
-- писать user stories администратора, для чего придется вообразить и парочку образцовых организаций, которые он администрирует
-- выбрать (или даже разработать) компьютерное представление <оргбазы знаний/базы оргзнаний> и двухоконного браузера для него.