Как меня порой "прет" от таких вот тем :)

Что такое самореализация, никто не задумывался? Конечно же, скажут психологи - это, по Маслоу,- реализация своих талантов и возможностей. Правда, никто не скажет, что именно надо делать для реализации этой реализации (простите за тавтологию). Скажут - "хочешь заниматься танцами? - танцуй!". Ну, хорошо, когда человек понимает, чего он хочет. А когда нет? Значит, надо захотеть. А если никак? А значит, надо придумать чего хотеть - и захотеть. Ну и так далее.

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

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

Что получалось в итоге? Да ничего хорошего. Работали, конечно. Но без огонька, без задоринки. Делали свое дело ровно настолько, чтобы претензий не было. Такая "средняя" позиция.

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

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

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

PS Это был очередной неструктурированный поток сознания.

В общем, смотрели на работе на разные системы, которые позволяют рисовать диаграммы и процессы. Что нашлось:

• Dia (http://dia-installer.de/) - opensource десктопное приложение под Linux и Windows. Часть Gnome office.
• Cacoo (http://cacoo.com/) - онлайн редактор диаграмм, на мой взгляд - тяжелый
• draw.io (http://www.draw.io/) - онлайн редактор диаграмм. Быстрый, легкий. Умеет писать диаграммы на Google Drive.

Да, все они с горем пополам умеют экспортировать в SVG - который, в свою очередь может быть конвертнут в VSD. Но, скажем честно, экспорт в SVG - не самая сильная сторона этих редакторов. А вот картинки они хорошо сохраняют.

По мере поступления новой информации список будет дополняться.

Нет, я не тормоз:) И лучшее тому доказательство - что я все-таки сел писать этот пост. Несмотря на то, что времени прошло почти 3 месяца. Но - обо всем по порядку.

23 февраля 2013 года славная компания Яндекс проводила мероприятие под названием "Второй план Б". Я туда подал заявку на спикерство, но - пройдя несколько итераций был забракован, как "не формат". Впрочем, что не делается - к лучшему: 23его я оказался категорически занят. А так на меня и не рассчитывали. В общем, все бы было неплохо, если бы не одно маленькое "но": я готовился, и готовился очень серьезно. Презентация, которая получилась на выходе, мне лично казалась довольно удачной ... в итоге, подумав, решил, что презентация стоит того, чтобы выложить ее тут. В конце концов, она делалась, чтобы стать достоянием общественности. Так почему нет?

В общем, вот: Второй план Б - презентация

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

• Управление проектами - это то, чем занимаются руководители проектов, а не то, что воплощают в себе методологии и программное обеспечение. (Цитата отсюда)
• Проект - это то, что должно быть реализовано целиком. Но если сначала реализовать самое важное, то будет немного проще.
• Не все задачи в проекте самоочевидны;
• План всегда будет скорректирован;
• Эффективный руководитель проектов - тот, который в срок запустил проект, не выйдя за границы бюджета;

В общем, такой общефилософский пост, как бы про работу - но и не про работу. А про жизнь.

Есть такая тонкая штука. Назвается репутация. Ее очень легко потерять - и очень сложно заработать. Репутация в наше время порой важна не менее, чем раскрученный бренд. Например, работает компания с фрилансерами. Честно оплачивает каждую сделанную работу. Потом раз - несколько раз не заплатили, кому-то совсем не заплатили, кому-то - долго задерживали, кто-то уже через суд добился своего. Что в итоге? Когда фирме понадобились новые ресурсы - отказались сотрудничать не только те, кто пострадал - но и масса других людей. Просто потму что репутации больше нет.

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

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

По понятной причине первая категория граждан не очень любит вторую (но с удовольствием пользует в своих целях). 

Есть, правда, третья категория - те, кто гадит и идет по головам. Обычно они обладают "отрицательной" репутацией: "такой танком переедет", "по головам пройдет и не вздрогнет". А также есть еще масса вариантов - как водится, отрезок между -1 и 1 содержит бесконечное множество чисел. Кому-то до репутации дела нет, кто-то, кстати, сознательно старается себе создать хоть какую-тто репутацию. 

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

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

Основной вывод - эффективная удаленная работа возможна! Условие/дополнение: возможна, при наличии адекватных людей как со стороны Заказчика, так и со стороны Исполнителя.

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

Тут надо вспомнить, что в самом безупречном договоре бывают "дыры". Без этого никуда - невозможно в юридическом документе предусмотреть все возможные варианты.... после чего вспомнить про требование "адекватности". Оно в общем имеет два аспекта:

1. "Нормальный режим", когда сервис предоставляется в штатном режиме, то есть подпадает под "SLA" (скобки - потому что SLA может быть совсем не SLA - я писал об этом выше);
2. "Нештатный режим", когда сервис предоставляется "за рамками SLA" - то есть не когда SLA нарушается, а именно, когда требуется что-то, что в "SLA" не входит;

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

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

Получается - "кадры решают все", и в этом был прав Лучший Друг Советских Физкультурников?

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

Есть вещи, которые начинаешь понимать со временем. Вернее, есть вещи, которые, чтобы понять - нужно, чтобы прошло время. Наверное, это такая особенность человеческого мозга - для определенных знаний и умений нужно прошедшее время. Чтобы они разложились "по полочкам" и заняли свое место в упрямых человеческих извилинах :)

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

• чёткая постановка задачи, исключающая двойные и тройные трактовки;
• чётко оговоренные сроки решения задачи, согласованные и подтвержденные исполнителями;
• честность по отношению к подчинённым, руководству и коллегам;
• понимание того, как задача соотносится с общими планами, стратегией и т.д.

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

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

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

Вот как-то так.

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

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

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

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

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

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

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

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