Я тут в последнее время много думал о том, что роль личности - растет. Растет в профессиональной области, растет в области политики, растет везде. Но - политика и "везде" - для меня вещи далекие, а вот профессиональная область...

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

Как показывает опыт неоднократного написания требований таким образом, всегда есть риск чего-то упустить. Причем, это "что-то" обычно имеет тенденцию к выползанию в самый неподходящий момент. Чтобы это исключить, решил я писать "По правильному" - на основе ГОСТов. Есть ведь, в конце концов, такие ГОСТы, как ГОСТ 34.602-89 "Техническое задание на создание автоматизированной системы" и ГОСТ 24.104-85 "АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ УПРАВЛЕНИЯ. ОБЩИЕ ТРЕБОВАНИЯ". Не зря же их умные люди придумывали - оттуда, как минимум, можно вытащить структуру требований.

Хм... как оказалось, "оттуда" можно вытащить не только структуру, но и сами требования. Причем, есть там такие "хитрые" требования, из разряда тех, что "сами собой подразумеваются". Но! Есть одно "но", которое состоит в том, что если систему отдавать на разработку подрядчику, и упустить в договоре эти "мелочи", то результат может оказаться весьма печальным.

Приведу пример. В требованиях, которые попали в ТЗ на некую систему отсутствовала такая сама собой подразумевавшаяся "мелочь", как требования к скорости работы интерфейса. В итоге система получилась весьма тормознутой), что не помешало ее сдать: формально Заказчик был не вправе выдвигать претензии.

В общем, мораль сего спича такова: любите ГОСТы, это разумно :)

Данная статья безнадежно устарела. Оставляена для истории.

Для планирования повседневной работы я использую Sunbird от Mozilla. Замечательный календарь-планировщик с парой недостатков:

• не умеет синхронизироваться с Pocket PC Outlook 2005
• не умеет синхронизировать записи "домашнего" и "рабочего" Sunbird'a.

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

• Аккаунт на Google
• Google сервис календарей
• Плагин к Sunbird или демон для Windows/Linux

Забегая вперед, скажу, что остановился я на первом варианте с плагином - так как второй вариант у меня просто не заработал. Итак, по шагам, в случае плагина:

• Заводим аккаунт на Google (я этот шаг пропустил, так как аккаунт у меня уже есть)
• Создаем на календарном сервисе Google календарь
• Скачиваем sunbird (у меня уже был скачан)
• Скачиваем плагин
• Устанавливаем плагин в sunbird
• Получаем на Google ссылку на календарь (Google в этом смысле просто шикрен: можно получать xml, rss или iCal - я выбрал его)
• Подключаем созданный календарь в sunbird ("Файл" - "Подписаться на удаленный календарь" - "Из сети" - ...)
• В процессе подключения выбираем другой цвет для G-календаря (для наглядности)

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

Теперь об общих впечатлениях: работать с Гугловым календарем через sunbird довольно приятно, правда, есть и ложка жегтя - судя по всему, автоматическое обновление не работает. То есть в sunbird надо периодически нажимать Ctrl-R, а в G-календаре - либо Ctrl-F5, либо жать на логотип.

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

Осталось теперь научиться синхронизироваться с WM2005.

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

Грустно как-то. Неужели так - ВЕЗДЕ?

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

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

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

В общем, жизнь - это вечный поиск компромисса. Во всем.

Кросспост из моего ИТшного блога на ITBlogs.ru

Не могу удержаться... На ITBlogs последний пост Анатолия Тенцера - "Корпоративное айкидо". Рекомендуется к прочтению всем! Особенно - ИТшникам, менеджерам проектов, а также - ТОП менеджерам. Изумительной точности вещь, описывающая тонкости управления проектами. ;)

Блин. Именно так, с большой буквы, с чувством и выражением, с желанием побиться головой. О стену, желательно - не гипроковую. Читаю пресс-релиз/рекламную листовку Некоторой Компании. И медленно ухожу в космос. Во-первых, оттого, что листовка в заголовке говорит об одном, в первом абзаце - о другом, а дальше напоминает известное разводилово - "хотите фен бесплатно? Купите 2 утюга и один порошок для ловли блох". Во-вторых, листовка, отправленная адресно техническому специалисту (да, несмотря на мою любовь к бизнесориентированности ИТ, я - технарь: не стоит об этом забывать) не содержит ровным счетом ничего. Ноль полезной информации. В третьих, она написана на 4 листах А4 довольно мелким шрифтом (один лист А3, напечатанный с 2 сторон и сложенный пополам). Вернее, на 3,5 - т.к. половину листа занимает тот самый заголовок. Текст рассчитан на домохозяек. Причем, даже скорее на (простите, милые дамы) - пародию на домохозяек. На лиц с ограниченным интеллектом... Детские книжки, которые рассчитаны на детей 2..3 лет, гораздо информативнее в плане формирования мировоззрения и донесения информации.

Вопрос. Вернее - несколько. Все риторические.

* неужели PR служба Некоторой Компании не в состоянии договориться хотя бы с продавцами, не говоря о ИТшниках о написании здравого текста?

* неужели в PR службу набирают людей, не способных отличить белого от черного в целом, и к организации эффективных коммуникаций в частности?

* неужели на ЭТИ листовки кто-то ведется?

* если на ЭТО никто не ведется, то как отбиваются затраты на изготовление листовок?

* неужели ЭТО не проходило утверждения перед отправкой в типографию и заказчикам?

К счастью, утешает то, что такого рода материалы все-таки встречаются нечасто. Но, блин, встречаются!

Кросспост из моего ИТшного блога на ITBlogs.ru