Этот пост - несколько необычной судьбы :) задуман он был довольно давно, а вот дописать руки дошли только сейчас. Да и жизнь подкинула нового материала в тему - но обо всем по порядку...

Как говорил Великий Классик Винни-Пух, "размышляя над Russian Open Source, меня посетила мысль - а как же и за счет чего живут и выживают разного рода дистрибутивы Linux? Тот же Linux XP, например? Или ASPLinux?"

Возьмем для примера Linux XP. Для тех, кто не в курсе - это коммерческий российский Linux. По цене 1500 руб за десктопную "коробку". (Информация с сайта LXP). По идее, суть проста и понятна: за основу дистрибутива взята Fedora Core, в дистрибутив интегрированы закрытые (или, если угодно - несвободные) компоненты. Выкини их - система перестанет быть коммерческой, получится совсем базовая Fedora. Добавь, и получишь коммерческий Linux XP. (Правда, определенное лукавство в моем утверждении все же присутствует: Linux XP несет на себе модифицированное ядро - угода юзабилити (скрываем от пользователя некоторые папки, верное отображение русских файлов в Nautilus и т.д.) При этом утверждается, что не нарушается GPL, под которой выпускается Fedora. (В баталии о лицензиях я вступать не готов, предположу, что так оно и есть - на старом сайте Linux XP вопросу лицензионной чистоты и законности было уделено довольно много внимания, так как желающих уличить их в нечистоплотности - как минимум половина Рунета. Правда, на новом сайте материалов, касающихся лицензионной политики, законности Linux XP я не нашел;впрочем, тема не о том, так что Бог с ними).

Или другие, "более свободные", дистрибутивы. Те, которые берут деньги за коробку и поддержку (классика жанра бизнес-модели Open Source). Alt Linux, ASP Linux и прочие товарищи, исповедующие принцип доступности дистрибутива без обязательной платы. То есть хочешь коробку, руководство и поддержку - плати, не хочешь - скачивай и пользуйся.

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

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

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

Оригинал и комментарии: ITBlogs.ru

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

И практически в любом проекте объем работ, связанных с кастомизацией, превышает запланированный.

Причин этому можно назвать несколько:

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

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

Российская специфика, однако.

Оригинал и комментарии: ITBlogs.ru

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

Итак, история (с)А.Молль:

Капитан - адъютанту: «Как вы знаете, завтра произойдет солнечное затмение, это бывает не каждый день. Соберите личный состав в 5 часов на плацу, в походной одежде. Они смогут наблюдать это явление, а я дам им необходимые объяснения. Если будет идти дождь, то наблюдать будет нечего, в таком случае оставьте людей в казарме».

Адъютант – сержанту: «По приказу капитана завтра утром произойдет солнечное затмение в походной одежде. Капитал на плацу даст необходимые объяснения, а это бывает не каждый день. Если будет идти дождь, наблюдать будет нечего, тогда явление состоится в казарме».

Сержант – капралу: «По приказу капитана завтра утром в 5 часов затмение на плацу людей в походной одежде. Капитан даст необходимые объяснения на счет этого явления, если будет дождливо, что бывает не каждый день».

Капрал – солдатам: «Завтра в самую рань, в 5 часов, солнце на плацу произведет затмение капитана в казарме. Если будет дождливо, то это редкое явление состоится в походной одежде, а это бывает не каждый день».

Солдат - солдату: «Завтра в самую рань, по приказу капитана, в 5 часов, состоится затмение капрала на плацу в походной одежде. Если будет дождливо, то капитан даст объяснение этому явлению в казарме, что бывает не каждый день».

Забавно? Ага! А теперь - как это бывает «у нас» (в ИТ, то есть).

Совет директоров - секретарю: «Как вы знаете, современные тенденции рынка таковы, что без системы, управляющей отношением с клиентами, то есть CRM, не обходится ни одна серьезная команда. Мы работаем над этим, поэтому завтра, в 11-00, в зале для переговоров состоится собрание заинтересованных лиц, на котором будет объявлено о запуске проекта и объявлены участники команды. Перед сотрудниками выступит президент. Поэтому, если он не вернется из командировки, собрания не будет, а о времени будет сообщено дополнительно. Кстати, надо дать задание в финансовый департамент сформировать бюджет, для чего попросить помочь ИТ департамент».

Секретарь – директору финансового департамента: «По решению совета директоров, современные тенденции рынка изменились. Поэтому мы будем проводить установку CRM и работать над этим завтра, в командировке, после выступления президента в переговорной зале. Вам необходимо подсчитать и обосновать, почему и сколько это стоит, но только если собрания не будет, в противном случае будут объявлены участники команды и повышены клиенты, с участием ИТ департамента».

Директор финансового департамента – менеджеру: «По приказу президента компании, началась командировка наших клиентов в ИТ департамент, поэтому выступит совет директоров, который произведет установку CRM. Мы должны проанализировать возможные затраты в случае проведения указанного мероприятия в переговорной зале».

Менеджер – сотрудникам: «Завтра, после выступления совета директоров, президент нашей компании даст комментарии относительно стоимости установки CRM в переговорной зале, чтобы дать клиентам департамента ИТ возможные затраты. Мы должны проанализировать это».

Специалист фин.департамента - ИТ-специалисту (в курилке): «Завтра в переговорной зале, президент ИТ департамента даст клиентам по CRM, чтобы установить возможные затраты. Вы должны помочь».

...вроде бы - не смешно.

Оригинал и комментарии: ITBlogs.ru

Один из самых тонких моментов при планировании проекта - оценка времени его реализации. Есть мнение, часто приводимое в качестве шутки: "Время, необходимое для реализации проекта в случае аутсорсинга, представляет собой время, заявленное партнерами, умноженное на случайное число в диапазоне от экспоненты до пи". Надо признать, что порой и при самостоятельном выполнении проекта длительность реализации (выполнения) получаются несколько больше заявленной. (На моей памяти были "долгострои", когда время выполнения проекта как самостоятельно, так и внешним подрядчиком, отличалось от расчетного раза в 2. Конечно, два - это не совсем экспонента (e=2,7), но близко. Традиционно возникает вопрос: почему? Или, в другой интерпретации: кто виноват и что делать?

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

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

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

Оригинал и комментарии: ITBlogs.ru

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

Кстати, заказчик обычно был представлен сотрудниками ИТ и бизнес-подразделений, а также руководством - то есть основными потребителями, вдохновителями и эксплуататорами продаваемой идеи/решения. Каждый из них находился в своей проблемной плоскости, соответственно, монологи и дискуссии о конкретном решении проходили, исходя из задач, стоящих перед конкретными подразделениями/пользователями.

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

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

Получается: "не внедряйте, да не внедряемы будете":)

Оригинал и комментарии: ITBlogs.ru

Собеседуя кандидата, натолкнулся на одну любопытную вещь: я просто не понимаю некоторых HR терминов. Например, что такое "активная жизненная позиция"? Или "самореализация"?

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

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

Все эти рассуждения я привожу в основном к тому, что достаточно ли определения на собеседовании только профессиональных качеств? Или надо определять и измерять позицию, харизму, самореализацию (плюс еще ряд подобных параметров)?

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

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

Оригинал и комментарии на ITBlogs.ru

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

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

С другой стороны, нужен ли он, "чистый консалтинг"? Довольно часто можно услышать мнение, что консалтинг сам по себе - порочен, поскольку

1. Разобраться в сути вопроса (предмета консалтинга) сложно, на глубокое понимание предметной области применительно к проблеме заказчика у консультанта уйдет слишком много времени.
2. Консультант - фигура временная. Он уйдет, а "нам с этим жить"
3. Задача консультанта - "снять" как можно больше денег с клиента, а не решить его конкретную проблему

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

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

Вывод получается таков:

1. Консалтинг продается лучше всего в связке с конкретным решением, для реализации которого он и затеян;
2. Консалтинг компрометирует себя предвзятостью; действительно независимый консалтинг - большая редкость. Или вообще не встречается в дикой бизнес-природе как класс.

Замкнутый круг?

Оригинал и комментарии на ITBlogs.ru