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

Итак, получается первый важный вывод: информационная система вторична по отношению к процессу.

Второй вывод, так или иначе следующий из первого - каждая система сильна в какой-либо одной (или нескольких) предметных областях. В этом смысле интересно рассмотреть ту самую пресловутую 1С - она до сих пор воспринимается как "бухгалтерская" система (но, сказать по правде, она, по сути не являясь уже чисто "бухгалтерией" несет в себе много рудиментов того времени). Или, например, HP Service Manager - ее воспринимают как "очень навороченный helpdesk". Хотя из обоих систем можно сделать все, что угодно: от склада до учета осколков метеорита. Весь вопрос только в том, что для решения конкретной задачи лучше и правильнее использовать ту систему, которая содержит в себе наметки на решение этой задачи. Или инструменты ее решения.

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

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

И последний, пятый, вывод: подбирая ИС под задачу при прочих равных стоит выбирать ту, которая имеет больший запас по масштабированию. То есть процессы-то процессами, а про производительность и "потолок" архитектурных возможностей забывать не стоит.

Да, при чем тут закон больших чисел? Да при том, что тут делал для себя review - сколько систем виде, сколько внедрял, сколько разрабатывал. И получилось, что довольно приличное количество. То есть - "большие цифры" в масштабе меня... позволяющие в том или ином виде делать обобщения.

PS Давно не писал про ИТ. С момента, как перестал активно жить ITBlogs - соскучился по теме. Так что наверное в ближайшее время еще попишу об этом.

Не знаю, боян или нет - мне встретилось впервые.

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

то будет странный пост... поток сознания:)

Итак, мы живем в эпоху глобального копипастинга. Копипастингом пишется код. Ооочень часто. Сознаюсь: у меня иногда хватает времени на то, чтобы сеть и кодировать. Так вот, в том, что я скромно именую "моя CMS" примерно 70% "моего" кода, и около 30 - копипастного. Я такой код обычно оформляю в отдельные файлики, складываю его в отдельный каталог, и всегда пишу - откуда стянуто... это не к тому, какой я хороший. А к тому, что когда попадается задачка уровня первого семестра "программирования" технического ВУЗа для непрограммистих специальностей, мне проще погуглив найти решение, чем думать.Времени точно займет меньше. Как показывают наблюдения, я не одинок: знакомые (программисты и другие ИТшные жители) говорят, что копипастится все: от конфигов до кода.

....А как же любимая всеми команда man? - грустно вздохнул серый ослик Иа-Иа.

да, да - и "мире linux" копипастинг тоже набирает обороты. "Не знаешь как? - скопируй"

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

- Где? - спросите вы.

- А вот видел. Не в родной компании, слава Богу. Но - видел. Причем грамотно так вписано в текст,  если бы в свое время не освоил книжку, которая была скопипащена - мог бы и не заметить: талантливый автор документа писал в стиле авторов книги. Видел не по работе - знакомый попросил помочь оценить документацию.

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

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

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

Давно я не писал ничего на ITBlogs. Исправляюсь....

Итак, из разряда "мысли вслух".

Обнаружил (умозрительно) парадокс. Заключается он в том, что чем меньше проект, тем более тщательное и конкретное ТЗ на него должно быть написано.

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

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

Если же вспомнить, что обычно (в правильных случаях - больших проектов) за ТЗ идет ТП, где описывается - КАК сделать все то, что описано в ТЗ, то вроде как возникает еще один повод расслабиться и вздохнуть с облегчением: уж в ТП-то будет описано все, до пресловутого "последнего винтика". Как бы ни так! В самом лучшем случае там будет описано процентов 70 того, КАК надо сделать описанное в ТЗ. 30% - на риски. Суровая правда жизни :)

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

Вот как-то так мыслится :)

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

Коллега выдал: "Любой проект - это сделать из г. конфетку. Причем сроки - кратчайшие".

Добавлю к этому,  что все на вышесказанно обычно накладывается "нехватка прочих ресурсов".

Но при этом проекты делаются, и мы (проектные менеджеры) получаем свою долю "проектного драйва" :)

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

В последнее время много работал, много думал, поэтому в свой блог писал мало. А еще меньше - в блог на IT Blogs. :-)

Сразу же оговорюсь: ниже речь идет о небольших компаниях. Относительно небольших: до 300..500 человек. Плюс-минус человек 200. И, разумеется, совсем не про публичные компании, тип Microsoft или SAP. Там, скорее всего, совсем другие законы.

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

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

Несколько примеров (целиком авторская фантазия, хотя реальных похожих случаев я знаю немало):

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

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

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

Как-то невесело получается...

PS. Это я не про свою работу, это я вообще... о жизни.

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

Недавно (скорее по привычке) читал себе hh.ru - что нового и как оно подается. Может быть, это мне так "повезло", но создалось впечатление, что работодатели начали сходить с ума. Навскидку (если "выжать суть") имеются следующие поразившие меня вакансии:

• Менеджер проекта (с весьма серьезно расписанными обязанностями - то есть менеджера и аналитика в одном флаконе), с дополнительной "повинностью" - поддержка работоспособности сети из 15ПК. Явно тут кто-то чего-то скрывает...
• Менеджер проекта, который сравнивается с су-поваром, в распоряжении которого поварята и прочий "кухонный люд";
• Директор коммерческий, который судя по вакансии, будет являть собой коммерческий отдел "в одном флаконе", со "стартовой заработной платой" в 40 т.р.

Там было еще что-то не менее любопытное, дочитывать не стал. (Ремарка: все компании - некрупные. "Гранды" и "монстры" ни в чем подобном уличены не были).

Если серьезно, то после прочтения страниц 10 вакансий, сложилось такое ощущение, что либо

1. Специалистов нет. Вообще, и хочется привлечь их любыми средствами (но при этом очень хочется сэкономить);
2. Работодатели пытаются вводить "новые методы" для поиска кандидатов;
3. Работодателям все равно, кто на них будет работать.
4. Я чего-то не понял / я просто попал в неурочное время.

В общем, остаюсь в нездоровом недоумении...

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