Давно прочитал статью "Вы уволили самого талантливого сотрудника. Надеюсь, теперь вы довольны" (https://habrahabr.ru/post/340370/). Прочитал давно, но вот формулировал - что я думаю, достаточно долго.

Почему? Да потому, что нет однозначности... Судите сами. Стиатья - ответ на другую статью. Где говорится о том, что некая компания уволила ведущего разработчика, который стал "звездой", работая 12*7. И который в итоге забил (судя по всему - вынужденно) на все, кроме того, что он сам считал работой - планерки и т.д. Оригинал статьи, на которую пишется ответ - вот: https://startupsventurecapital.com/you-fired-your-top-talent-i-hope-youre-happy-cf57c41183dd (на наглийском). В итоге разрабоотчика уволили, команда напряглась - чтобы закрыть "белые пятна", и всё стало отлично.

Ответ же говорит о том, что уважаемый менеджмент - а ты где был, когда с человеком происходило невесть что? Твоя вина, что не предусмотрел, не рассмотрел... И вроде всё верно. Кроме одного "НО": мягко говоря, очень странной выглядит ситуация, очень.

Есть разработчик, который надеюсь что невольно стал центром вселенной - то есть ответственным за всё. Есть компания, которую до определенного момента это устраивает. Прям сюжет голливудского фильма. Только happy end не предусмотрен сценарием. Или предусмотрен?

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

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

Как думаете?

Статья на Хабре про кроссбраузерную верстку: https://habrahabr.ru/company/htmlacademy/blog/341538/

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

С удовольствием сошлюсь на запись в ЖЖ психотерапевта, которого с удовольствием читаю: https://lual.livejournal.com/464618.html Называется пост "Когда терапия бессильна". И говорится там о как-бы базовых вещах, которые касаются не только терапии, но и вообще - жизни, изменений. Потому что (в моей голове, по крайней мере), терапия и !самоизменения" - эьто близнецы-братья. Не обязательно идти в терапию, чтобы измениться. Но изменения, которые ты сам в себе инициировал - все равно подпадают под "терапия".

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

Как обычно, все началось с того, что на Хабре попалась на глаза статья "ITSM жил, ITSM жив, ITSM будет жить": https://habrahabr.ru/company/alloy_software/blog/341514/

С одной стороны, это статья о том почему ITIL - это хорошо. А с другой... вспомнил пост Павла Потеева. Про то что в чем-то очень похожа жизнь ИТ-директора и жизнь РПО. И там, и там - сервисы, доказательства "нужности" (кстати, ИБ-шники тоже где-то в упряжке, как и change-менеджеры). И подумал - а почему бы не сделать свод лучших практик для РПО? Ведь есть ITIL Foundation, Предосталвние и Поддержка услуг (сейчас возможно что-то поменялось, ITIL-темы не отслеживаю достаточно давно). Так почему нет какого-ниюудь HPOSL (Head of Project Office Service Library)? Не, ну правда - свести туда не много интересных вещей из Prince2, PMBook, а просто некое руководство - делай раз, получи вот, делай два, получи вот...

В защиту идея скажу: так или иначе этим путем идут многие. Например, мы в Адванте запустили курс по базовым практикам Управления Проектами (читает Елена Филипова, всячески рекомендую - как курс, так и тренера). Но мы в общем не единственные - на рынке можно найти множетво интересных курсов, кейсов и т.д. Вот я мечтаю... почему бы не свести всё воедино? С четкой структурой, практической направленностью и описанием сервисов, шагов и подводных камней?

Что думаете?

Я тут исследовал какие есть офисы под Linux, по причине того, что LibreOffice мягко говоря недружественный к документам формата MS Office. Итак, десктопное:

• LibreOffice. Ставится из репозитоиев. Свободный для коммерческого и некоммерческого использования. Совместимость с MS офисом - ну, так. На четыре с минусом. Сайт: http://www.libreoffice.org/
• WPS Office. Скачивается с сайта. Версия для Linux свободна для персонального и коммерческого использования. Совместимость с MS Office - на 5- (не все условное форматирование в Excel переваривает). Сайт: http://www.wps.com
• OnlyOffice. Скачивается с сайта. Версия для Linux свободна для персонального и коммерческого использования. Совместимость с MS Office - на 5. Сайт: https://www.onlyoffice.com/ru

Что удивительно - IBM Lotus Simfony из свободного доступа кажется убрали. А жаль, офис был приличный.

Я активно использую механизм отложенных записей. То есть пишу несколько постов на неделю вперед, и живу спокойно. Но есть одна незадача - при появлении такого поста на сайте, он не появляется в фиде RSS - до тех пор, пока не зайдешь в запись и не пересохранишь её. Впервые я столкнулся с этой проблемой еще на версии 0.6++, и так и жил. Но тут перейдя на последний MaxSite, решил пофиксить и это.

В общем - самостоятельно решения не нашел. Но MAX (Автор одноименной CMS) решение подсказал. Привожу его тут полностью:

Это кэширование rss, которое по умолчанию 24 часа. С отложенной публикацией возникает неопределенность — кэш не в курсе что запись должна быть опубликована. Наверное можно уменьшить время rss кэша, например до 1 часа.

В \shared\type\feed\home.php в конце функция mso_add_cache()

mso_add_cache($cache_key, ob_get_flush());

замените на

mso_add_cache($cache_key, ob_get_flush(), 3600);

Это установит время кэша 3600 секунд.

Сделал, помогло. Публикую, т.к. есть подозрение, что я не один с "этой штукой" мучаюсь.

Очень дельная статья: http://www.e-xecutive.ru/management/practices/1987321-kak-stat-agile-kompaniei-bez-revolutsionnyh-perestroek (Как стать Agile-компанией без революционных перестроек).

Обозначу проблему. Есть, предположим, компания. И комания хочет иметь определенную гибкость на рынке. Один из способов - примнение Agile ("за бортом" оставляю дискуссию о применимости данного метода для конкретного случая, просто - предположим, что такая возможность рассмотрена и принята как одна из основных). Как перестроить компанию? Принудительно "загнать" всех в Agile? Мне кажется, что плохой путь - перестроиться сложно, особенно в части принятия Agile-ценностей, а без этого никуда. В этот смысле с интересом продолжаю наблюдать, насколько доступно из открытых источников, эксперимант Сбербанка по Agile-трансформации. А статья предлагает на мой взгляд хорошее решение (и самое главное, провернное гигантами типа Google и Microsoft) - внедрять гибриды. Идти от цлей, декомпозировать до уровня команд, а там - не важно, какая идеология внутри команды, важен согласованный результат в срок. Что-то в этом есть, согласитесь?