Зацепил пост из ЖЖ про начальников. Вот: "Я б в начальники пошёл, пусть меня повысят" (http://azbukivedi.livejournal.com/259947.html)

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

Задумавшись на предмет эффективного управления, нашел притчу "Одноминутный менеджер" (авторы К. Бланчард, С. Джонсон).В притче говорится о том, что надо сделать, чтобы стать эффективным не только с точки зрения организации, но и с точки зрения сотрудников.

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

PS. Найти текст можно погуглив, или Яндексом. На момент написания статьи первая ссылка в Яндексе - http://www.leader3000.ru/articles/1mm.htm

В тему недавним рассуждениям коллег (Тенцера и Марианны).

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

На самом деле, решения могут быть приняты двумя путями:

• самостоятельно
• при помощи внешних консультантов

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

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

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

Вопрос - учитываются ли рекомендации рядовых специалистов при выборе того или иного ПО? Варианты ответа:

• иногда да (действительно, иногда прислушиваются к специалистам. Весь вопрос в том, что они должны быть действительно СПЕЦИАЛИСТАМИ, а не подмастерьями)
• а оно надо? (как вариант. Часто жизнь складывается так, что мнения рядовых специалистов топов не интересует - сказано поставить и внедрить, извольте исполнять!)
• специалисты должны дать базис для принятия решения (это лично мне ближе; так как учитывается и опыт "снизу", и требования "сверху")

Что еще? Если делать по-умному, то перед тем как выбирать, надо попробовать. В идеале - сделать тестовый запуск на ограниченном числе автоматизируемых процессов (один-два). И поковырять систему недельку-другую. Хорошо? - Да. Но накладно, и требует установки системы, не говоря уже о том, что банально нужны договоренности с разработчиками/поставщиками ПО и люди - тестеры. Тем не менее - весьма любимый мной вариант. Вероятность "обжечься" резко падает по сравнению с "котом в мешке".

Еще один интересный момент. Предположим, есть 10 (а лучше, как в анекдоте - 20) систем, автоматизирующих область Х. Нужно выбрать одну. Что делаем? Классика жанра состоит в том, что строим классическое (простите за тавтологию) сито:

1. Формируем требования (а куда же без них, в конце концов надо представлять, что хочет бизнес-заказчик)
2. Формируем критерии отбора
3. Отбираем пару-тройку лидеров (самый интересный момент, о нем как раз я подробно написал выше)
4. Разворачиваем их
5. Тестируем (имитируем работу пользователей, возможно - с некоторыми допущениями)
6. Делаем орг.выводы
7. Принимаем решение (тоже см.выше).
8. Подписываем договор, и на внедрение (совсем отдельная песня).

Как оно бывает на самом деле - не мне вам рассказывать:) Вопрос - часто ли срабатывает подобная классика? К сожалению, практически никогда. Почему? Да потому, что:

• цели внедрения запросто могут быть не определены;
• требования к продукту существуют в 3..4 головах, причем - разные;
• критерии отбора сформировать невозможно, т.к. непонятно, что выбираем;
• понимания, какие системы можно рекомендовать - нет, так как все равно выберут за нас;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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